Alan,
You were correct on your warning tome....
> >McAfee and no vaccine has yet been developed. This
> >virus simply destroys Sector Zero from the hard disk,
> >where vital information for its functioning
> >are stored.
HAHAHA, Microsoft did not listen to me 10 months ago!
I warned then that they had a sercurity hole!
> >This virus acts in the following manner: It sends
> >itself automatically to all contacts on your list
> >with the title "A Virtual Card for You". As >soon as
> >the supposed virtual card is opened, the computer
> >freezes so that the user has to reboot.
> >When the ctrl+alt+del keys or the reset button are
> >pressed, the virus destroys Sector Zero, thus
> >permanently destroying the hard disk.
This is a LIE, it does not destroy the drive, only the partition table.
Please recally the limited effects of "DiskDestroyer" and "SCSIkiller"
This is why we had the flaming discussion about command filters.
Cheers,
Andre Hedrick
Linux ATA Development
Sorry Andre, but this one's a hoax.
http://service1.symantec.com/sarc/sarc.nsf/html/Virtual.Card.for.you.html
On Tue, 6 Mar 2001, Andre Hedrick wrote:
> > >This virus acts in the following manner: It sends
> > >itself automatically to all contacts on your list
> > >with the title "A Virtual Card for You". As >soon as
> > >the supposed virtual card is opened, the computer
> > >freezes so that the user has to reboot.
> > >When the ctrl+alt+del keys or the reset button are
> > >pressed, the virus destroys Sector Zero, thus
> > >permanently destroying the hard disk.
On Tue, Mar 06 2001, Andre Hedrick wrote:
> > >This virus acts in the following manner: It sends
> > >itself automatically to all contacts on your list
> > >with the title "A Virtual Card for You". As >soon as
> > >the supposed virtual card is opened, the computer
> > >freezes so that the user has to reboot.
> > >When the ctrl+alt+del keys or the reset button are
> > >pressed, the virus destroys Sector Zero, thus
> > >permanently destroying the hard disk.
>
> This is a LIE, it does not destroy the drive, only the partition table.
> Please recally the limited effects of "DiskDestroyer" and "SCSIkiller"
>
> This is why we had the flaming discussion about command filters.
But I might want to do this (write sector 0), why would we want
to filter that? If someone a) uses an email client that will execute
java script code (or whatever) and b) runs that as root (which
he would have to do, surely no ordinary user has privileges to send
arbitrary commands) then he gets what he deserves.
--
Jens Axboe
On Tue, 6 Mar 2001, Mike Dresser wrote:
> Sorry Andre, but this one's a hoax.
>
> http://service1.symantec.com/sarc/sarc.nsf/html/Virtual.Card.for.you.html
Well I am happy it is a hoax, because Alan pressed into my forhead that
this old-war would come back to haunt me.
Cheers,
Andre Hedrick
Linux ATA Development
On Tue, 6 Mar 2001, Jens Axboe wrote:
> But I might want to do this (write sector 0), why would we want
> to filter that? If someone a) uses an email client that will execute
> java script code (or whatever) and b) runs that as root (which
> he would have to do, surely no ordinary user has privileges to send
> arbitrary commands) then he gets what he deserves.
Jens we are not going there....the filter is the only way known to jam
unknown commands, and you missed the point of the issue then and I think
you still miss it. "arbitrary commands" + wrong hander is lock-up.
Everyone can do this, and that is fine. I will not stop the drive-command
ioctl from issuing a drive-data command, you win!
Regards,
Andre Hedrick
Linux ATA Development
On Tue, 6 Mar 2001, Andre Hedrick wrote:
> On Tue, 6 Mar 2001, Jens Axboe wrote:
>
> > But I might want to do this (write sector 0), why would we want
> > to filter that? If someone a) uses an email client that will execute
> > java script code (or whatever) and b) runs that as root (which
> > he would have to do, surely no ordinary user has privileges to send
> > arbitrary commands) then he gets what he deserves.
>
> Jens we are not going there....the filter is the only way known to jam
> unknown commands,
Erm... the hoax "virus" was about writing to the first sector of the disk,
overriding the partition table. If "write data" is an "unknown command",
HTF am I supposed to store data on my HDD? :P
> and you missed the point of the issue then and I think you still miss
> it. "arbitrary commands" + wrong hander is lock-up. Everyone can do
> this, and that is fine. I will not stop the drive-command ioctl from
> issuing a drive-data command, you win!
Hrm. I like the idea of being able to filter out dodgy commands from
hitting the drive: there's a difference between the Unix philosophy of
"enough rope" and the NT approach of everything having a landmine on top
with a big red button marked "press this and see!" :)
James.
On Tue, 6 Mar 2001, James A. Sutherland wrote:
> > Jens we are not going there....the filter is the only way known to jam
> > unknown commands,
>
> Erm... the hoax "virus" was about writing to the first sector of the disk,
> overriding the partition table. If "write data" is an "unknown command",
> HTF am I supposed to store data on my HDD? :P
One-liner: It is stupid to issue a data-command using a non-data-handler.
Andre Hedrick
Linux ATA Development
On Tue, Mar 06 2001, Andre Hedrick wrote:
> > But I might want to do this (write sector 0), why would we want
> > to filter that? If someone a) uses an email client that will execute
> > java script code (or whatever) and b) runs that as root (which
> > he would have to do, surely no ordinary user has privileges to send
> > arbitrary commands) then he gets what he deserves.
>
> Jens we are not going there....the filter is the only way known to jam
> unknown commands, and you missed the point of the issue then and I think
> you still miss it. "arbitrary commands" + wrong hander is lock-up.
I'm perfectly aware of the handler issue. So make it part of the
user space taskfile interface in a nice way, done and done. And I
knew I shouldn't have replied to this, the last thing I want to do
is start another flamewar :-)
So EOD from me.
--
Jens Axboe
> So EOD from me.
ditto...
Andre Hedrick
Linux ATA Development
From: "Jens Axboe" <[email protected]>
To: "Andre Hedrick" <[email protected]>
Cc: "Alan Cox" <[email protected]>; "Linus Torvalds"
<[email protected]>; <[email protected]>
> > This is a LIE, it does not destroy the drive, only the partition table.
> > Please recally the limited effects of "DiskDestroyer" and "SCSIkiller"
> >
> > This is why we had the flaming discussion about command filters.
>
> But I might want to do this (write sector 0), why would we want
Jens, and others, I have noted a very simple data killer technique that
at LEAST works on Quantum SCSI drives as of a couple years ago and some
other earlier drives I felt could be sacrificed to the test. You can write
as many blocks at once as SCSI supports to the drive as long as you do
*NOT* start at block zero. If you write more than 1 block to block zero
the drive becomes unformatted. The only recovery is to reformat the
drive. The data on the drive is lost for good. I found no recovery for
this. I have, to my great chagrin, discovered this twice, the hard way.
Once on a large Micropolis harddisk I was working with in the block zero
area for partitioning purposes. And the other time when I was attempting
to make a complete duplicate of a 2G Quantum SCSI disk to another identical
2G SCSI disk. I ended up writing a script for the process that wrote one
block to block zero and then proceeded to use large blocks for the rest
of the disk, using dd under 2.0.36 at the time.
If this problem still exists the lowest level drivers in the OS should
offer protection for this problem so people working at any higher level
do not see it and fall victim to it.
{^_^} Joanne Dow, [email protected]
Joanne, since a SCSI drive contains a processor (one of the small
computer systems that are interfacing) it requires that the local
personality data be stored in non-volatile storage someplace.
Most drives used a dedicated area of the drive surface, which was
SUPPOSED to be inaccessible to any outside process. If you were
able to muck with that sector or sectors, then it was REAL EASY
to make the drive terminally unusable. But as I say, you should
not be able to directly reach that area.
Since ATA drives are generally also small self-contained systems
who differ from SCSI drives mainly in the details of the interface
protocols, they probably suffer from the same problem.
But you ain't supposed to be able to get at that area...
Harvey
On Tue, 6 Mar 2001, J. Dow wrote:
> From: "Jens Axboe" <[email protected]>
> To: "Andre Hedrick" <[email protected]>
> Cc: "Alan Cox" <[email protected]>; "Linus Torvalds"
> <[email protected]>; <[email protected]>
>
> > > This is a LIE, it does not destroy the drive, only the partition table.
> > > Please recally the limited effects of "DiskDestroyer" and "SCSIkiller"
> > >
> > > This is why we had the flaming discussion about command filters.
> >
> > But I might want to do this (write sector 0), why would we want
>
> Jens, and others, I have noted a very simple data killer technique that
> at LEAST works on Quantum SCSI drives as of a couple years ago and some
> other earlier drives I felt could be sacrificed to the test. You can write
> as many blocks at once as SCSI supports to the drive as long as you do
> *NOT* start at block zero. If you write more than 1 block to block zero
> the drive becomes unformatted. The only recovery is to reformat the
> drive. The data on the drive is lost for good. I found no recovery for
> this. I have, to my great chagrin, discovered this twice, the hard way.
> Once on a large Micropolis harddisk I was working with in the block zero
> area for partitioning purposes. And the other time when I was attempting
> to make a complete duplicate of a 2G Quantum SCSI disk to another identical
> 2G SCSI disk. I ended up writing a script for the process that wrote one
> block to block zero and then proceeded to use large blocks for the rest
> of the disk, using dd under 2.0.36 at the time.
>
> If this problem still exists the lowest level drivers in the OS should
> offer protection for this problem so people working at any higher level
> do not see it and fall victim to it.
>
> {^_^} Joanne Dow, [email protected]
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
----------------------------------------------------------------------------
Harvey Fishman |
[email protected] | A little heresy is good for the soul.
718-258-7276 |
Harvey,
That is not the case Joanne is pointing out.
The SCSI low-level format glue performed by the HOST gets destroyed
If you write to LBA Zero. ATA only suffers the lose of the partition
table and that can be recovered, but SCSI needs that information to know
where everything else is on the drive.
You know I really do not care anymore that people can screw themselves,
and that Linux has choosen the road of pure UNIX, user beware. After the
last battles, I encourge stupidity, because the no IOCTLS will require you
know how to use the hardware rules completely, and if you compose the
wrong command because you can not/will not understand the rules of IO and
use the interface improperly, tough.
On Wed, 7 Mar 2001, Harvey Fishman wrote:
> Joanne, since a SCSI drive contains a processor (one of the small
> computer systems that are interfacing) it requires that the local
> personality data be stored in non-volatile storage someplace.
> Most drives used a dedicated area of the drive surface, which was
> SUPPOSED to be inaccessible to any outside process. If you were
> able to muck with that sector or sectors, then it was REAL EASY
> to make the drive terminally unusable. But as I say, you should
> not be able to directly reach that area.
>
> Since ATA drives are generally also small self-contained systems
> who differ from SCSI drives mainly in the details of the interface
> protocols, they probably suffer from the same problem.
>
> But you ain't supposed to be able to get at that area...
>
> Harvey
>
> On Tue, 6 Mar 2001, J. Dow wrote:
>
> > From: "Jens Axboe" <[email protected]>
> > To: "Andre Hedrick" <[email protected]>
> > Cc: "Alan Cox" <[email protected]>; "Linus Torvalds"
> > <[email protected]>; <[email protected]>
> >
> > > > This is a LIE, it does not destroy the drive, only the partition table.
> > > > Please recally the limited effects of "DiskDestroyer" and "SCSIkiller"
> > > >
> > > > This is why we had the flaming discussion about command filters.
> > >
> > > But I might want to do this (write sector 0), why would we want
> >
> > Jens, and others, I have noted a very simple data killer technique that
> > at LEAST works on Quantum SCSI drives as of a couple years ago and some
> > other earlier drives I felt could be sacrificed to the test. You can write
> > as many blocks at once as SCSI supports to the drive as long as you do
> > *NOT* start at block zero. If you write more than 1 block to block zero
> > the drive becomes unformatted. The only recovery is to reformat the
> > drive. The data on the drive is lost for good. I found no recovery for
> > this. I have, to my great chagrin, discovered this twice, the hard way.
> > Once on a large Micropolis harddisk I was working with in the block zero
> > area for partitioning purposes. And the other time when I was attempting
> > to make a complete duplicate of a 2G Quantum SCSI disk to another identical
> > 2G SCSI disk. I ended up writing a script for the process that wrote one
> > block to block zero and then proceeded to use large blocks for the rest
> > of the disk, using dd under 2.0.36 at the time.
> >
> > If this problem still exists the lowest level drivers in the OS should
> > offer protection for this problem so people working at any higher level
> > do not see it and fall victim to it.
> >
> > {^_^} Joanne Dow, [email protected]
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> ----------------------------------------------------------------------------
> Harvey Fishman |
> [email protected] | A little heresy is good for the soul.
> 718-258-7276 |
>
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035 Web: http://www.aslab.com
On Wed, Mar 07, 2001 at 12:32:08PM -0800, Andre Hedrick wrote:
> The SCSI low-level format glue performed by the HOST gets destroyed
> If you write to LBA Zero.
This is simply not true. I write to SCSI disk's block 0 all of the time
and never loose data. Obviously, you can lose the partition information
if that is where it is kept. I've also never had trouble with SCSI
disks correctly writing multiple sectors starting at block zero. This
includes older Quantum drives.
Then run this and see if you live.
On Wed, 7 Mar 2001, Craig Ruff wrote:
> On Wed, Mar 07, 2001 at 12:32:08PM -0800, Andre Hedrick wrote:
> > The SCSI low-level format glue performed by the HOST gets destroyed
> > If you write to LBA Zero.
>
> This is simply not true. I write to SCSI disk's block 0 all of the time
> and never loose data. Obviously, you can lose the partition information
> if that is where it is kept. I've also never had trouble with SCSI
> disks correctly writing multiple sectors starting at block zero. This
> includes older Quantum drives.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035 Web: http://www.aslab.com
On Wed, 7 Mar 2001, Andre Hedrick wrote:
>
> Harvey,
>
> That is not the case Joanne is pointing out.
> The SCSI low-level format glue performed by the HOST gets destroyed
> If you write to LBA Zero. ATA only suffers the lose of the partition
> table and that can be recovered, but SCSI needs that information to know
> where everything else is on the drive.
>
> You know I really do not care anymore that people can screw themselves,
> and that Linux has choosen the road of pure UNIX, user beware. After the
> last battles, I encourge stupidity, because the no IOCTLS will require you
> know how to use the hardware rules completely, and if you compose the
> wrong command because you can not/will not understand the rules of IO and
> use the interface improperly, tough.
[SNIPPED...]
You can read/write/trash LBA zero all you want with SCSI. It contains
only user (your) data. The disk drive contains a RCT (reconstruction and
caching table). The entries in this are built up during the format-unit
command. If you interrupt the power at just the right instant during
a format-unit, you can corrupt this table and make the drive unusable.
It is highly unlikely that you'd be able to crowbar the supply at just
the right instant, even if you designed the drive and knew what it
was doing at every instance.
This is not something you could do with software. SCSI talks SCSI, there
are no SCSI commands that say "corrupt the RCT". So a virus, although
it can blow away all user data, and can initiate a format-unit command
(BIOS function code 7), can't get at anything that will disable
the drive.
That said, the format-unit command takes some interesting parameters.
One of them is a defect list. It is possible to format the drive so
that all cylinders are "defective"!! Of course this goes away when
you format the drive without such a defect list.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
On Wed, Mar 07, 2001 at 01:15:46PM -0800, Andre Hedrick wrote:
>
> Then run this and see if you live.
Well, I ran it, the disk lives. The typescript is appended below.
Interestingly, scsikiller didn't cream the partition table like I
expected. However the dd if=/dev/zero of=/dev/sdc certainly did.
I've been using dd to copy entire disks for 18 years. Not just SCSI,
but SMD, IPI and IDE. I've never had a problem with multi-sector writes
starting at any sector on drives. Unless there is a bug in the
drive's firmware, about the only thing you can do software wise to
a SCSI disk is to interrupt a format command, which can leave things
messed up a bit until the next format.
Script started on Wed Mar 7 14:55:00 2001
bells# fdisk /dev/sdc
Command (m for help): p
Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 1 553 4441941 83 Linux
Command (m for help): q
bells# dd if=/dev/sdc of=sdc.part bs=512 count=1
1+0 records in
1+0 records out
bells# cat scsikiller.c
/* scsikiller.c */
#include <sys/ioctl.h>
#include <sys/fcntl.h>
#include <scsi/scsi.h>
struct cdb6hdr{
unsigned int inbufsize;
unsigned int outbufsize;
unsigned char cdb [6];
} __attribute__ ((packed));
int main (int argv, char **argc)
{
int fd;
unsigned char tBuf[526];
struct cdb6hdr *ioctlhdr;
if (argv != 2) exit(-1);
fd = open (*(argc+1), O_RDWR );
if (fd < 0) exit (-1);
memset(&tBuf, 0, 526);
ioctlhdr = (struct cdb6hdr *) &tBuf;
ioctlhdr->inbufsize = 512;
ioctlhdr->outbufsize = 0;
ioctlhdr->cdb[0] = WRITE_6;
ioctlhdr->cdb[4] = 1;
return ioctl(fd, 1, &tBuf);
}
bells# cc -o scsikiller scsikiller.c
bells# scsikiller /dev/sdc
bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
100+0 records in
100+0 records out
bells# fdisk /dev/sdc
Command (m for help): p
Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 1 553 4441941 83 Linux
Command (m for help): q
bells# dd if=sdc.part of=/dev/sdc
1+0 records in
1+0 records out
bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
100+0 records in
100+0 records out
bells# dd if=/dev/zero of=/dev/sc bs=512 count=100
100+0 records in
100+0 records out
bells# fdisk /dev/sdc
Device contains neither a valid DOS partition table, nor Sun or SGI disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Command (m for help): q
bells# dd if=sdc.part of=/dev/sdc
1+0 records in
1+0 records out
bells# fdisk /dev/sdc
Command (m for help): p
Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 1 553 4441941 83 Linux
Command (m for help): q
bells# ^Dexit
Script done on Wed Mar 7 14:57:35 2001
Andre Hedrick writes:
> That is not the case Joanne is pointing out.
> The SCSI low-level format glue performed by the HOST gets destroyed
> If you write to LBA Zero. ATA only suffers the lose of the partition
> table and that can be recovered, but SCSI needs that information to know
> where everything else is on the drive.
Joanne Dow wrote:
> > Jens, and others, I have noted a very simple data killer technique that
> > at LEAST works on Quantum SCSI drives as of a couple years ago and some
> > other earlier drives I felt could be sacrificed to the test. You can write
> > as many blocks at once as SCSI supports to the drive as long as you do
> > *NOT* start at block zero. If you write more than 1 block to block zero
> > the drive becomes unformatted. The only recovery is to reformat the
> > drive. The data on the drive is lost for good.
Hm, it is not yet April 1st.
But then, Joanne keeps pet dragons, I believe.
Perhaps writing to sector 0 of a SCSI drive is harmless
in case one does not keep such animals?
Andries
On Wed, Mar 07, 2001 at 02:35:56PM -0800, Andre Hedrick wrote:
> So basically you are pointing out that there is now a sequencer reject in
> linux? Because this used to effect and wipe drives, but you are showing
> that Linux now does scsi commands check for execution on the /dev/sdxx?
Nope, there is a "sequencer reject" is not present. SCSI drives do not store
sensitive, driver controller private, information in a user accessible
location.
Now, it may be possible to really mess up a drive with the write buffer
command to attempt to download new firmware. One hopes that the
manufacturers include some sanity checking to prevent short firmware
writes, bad checksum, etc from rendering the drive useless.
Typically what happens is that the user confuses a partition table overwrite
with the drive having been rendered useless. Of course, there is always
a chance for firmware bugs, but I've never been bit by one.
So basically you are pointing out that there is now a sequencer reject in
linux? Because this used to effect and wipe drives, but you are showing
that Linux now does scsi commands check for execution on the /dev/sdxx?
On Wed, 7 Mar 2001, Craig Ruff wrote:
> On Wed, Mar 07, 2001 at 01:15:46PM -0800, Andre Hedrick wrote:
> >
> > Then run this and see if you live.
>
> Well, I ran it, the disk lives. The typescript is appended below.
> Interestingly, scsikiller didn't cream the partition table like I
> expected. However the dd if=/dev/zero of=/dev/sdc certainly did.
>
> I've been using dd to copy entire disks for 18 years. Not just SCSI,
> but SMD, IPI and IDE. I've never had a problem with multi-sector writes
> starting at any sector on drives. Unless there is a bug in the
> drive's firmware, about the only thing you can do software wise to
> a SCSI disk is to interrupt a format command, which can leave things
> messed up a bit until the next format.
>
>
> Script started on Wed Mar 7 14:55:00 2001
> bells# fdisk /dev/sdc
>
> Command (m for help): p
>
> Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
> Units = cylinders of 16065 * 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/sdc1 1 553 4441941 83 Linux
>
> Command (m for help): q
>
> bells# dd if=/dev/sdc of=sdc.part bs=512 count=1
> 1+0 records in
> 1+0 records out
> bells# cat scsikiller.c
> /* scsikiller.c */
> #include <sys/ioctl.h>
> #include <sys/fcntl.h>
> #include <scsi/scsi.h>
>
> struct cdb6hdr{
> unsigned int inbufsize;
> unsigned int outbufsize;
> unsigned char cdb [6];
> } __attribute__ ((packed));
>
> int main (int argv, char **argc)
> {
> int fd;
> unsigned char tBuf[526];
> struct cdb6hdr *ioctlhdr;
>
> if (argv != 2) exit(-1);
>
> fd = open (*(argc+1), O_RDWR );
> if (fd < 0) exit (-1);
>
> memset(&tBuf, 0, 526);
>
> ioctlhdr = (struct cdb6hdr *) &tBuf;
>
> ioctlhdr->inbufsize = 512;
> ioctlhdr->outbufsize = 0;
> ioctlhdr->cdb[0] = WRITE_6;
> ioctlhdr->cdb[4] = 1;
>
> return ioctl(fd, 1, &tBuf);
> }
> bells# cc -o scsikiller scsikiller.c
> bells# scsikiller /dev/sdc
> bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
> 100+0 records in
> 100+0 records out
> bells# fdisk /dev/sdc
>
> Command (m for help): p
>
> Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
> Units = cylinders of 16065 * 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/sdc1 1 553 4441941 83 Linux
>
> Command (m for help): q
>
> bells# dd if=sdc.part of=/dev/sdc
> 1+0 records in
> 1+0 records out
> bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
> 100+0 records in
> 100+0 records out
> bells# dd if=/dev/zero of=/dev/sc bs=512 count=100
^^^^^^^^^^
I assume typo ??
> 100+0 records in
> 100+0 records out
> bells# fdisk /dev/sdc
> Device contains neither a valid DOS partition table, nor Sun or SGI disklabel
> Building a new DOS disklabel. Changes will remain in memory only,
> until you decide to write them. After that, of course, the previous
> content won't be recoverable.
>
>
> Command (m for help): q
>
> bells# dd if=sdc.part of=/dev/sdc
> 1+0 records in
> 1+0 records out
> bells# fdisk /dev/sdc
>
> Command (m for help): p
>
> Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
> Units = cylinders of 16065 * 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/sdc1 1 553 4441941 83 Linux
>
> Command (m for help): q
>
> bells# ^Dexit
>
> Script done on Wed Mar 7 14:57:35 2001
>
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035 Web: http://www.aslab.com