coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dd effect on cloning of iso file to usb stick


From: Bob Proulx
Subject: Re: dd effect on cloning of iso file to usb stick
Date: Mon, 13 Oct 2014 15:53:00 -0600
User-agent: Mutt/1.5.23 (2014-03-12)

jb wrote:
> Bob Proulx writes:
> >   parted /dev/sdb print
> > ...
> 
> First fdisk:
> 
> # fdisk -l /dev/sdb
> ...
> Device     Boot Start     End Sectors  Size Id Type
> /dev/sdb1  *        0 1171455 1171456  572M  0 Empty
> /dev/sdb2         252   63739   63488   31M ef EFI (FAT-12/16/32)

That looks okay.  fdisk handles it okay.

> Some more (weird) entries:
> 
> # fdisk -l /dev/sdb1

Weird that you would ask fdisk to look at /dev/sdb1 instead of
/dev/sdb which is where the partition table would reside.  There isn't
normally a partition table at /dev/sdb1.

> Any comment on these /dev/sdb1p1 and /dev/sdb1p2 device names ?

Yes.  You don't normally have a partition table at /dev/sdb1.  Looking
there for one is like looking for meaning in clouds and tea leaves.
Something might randomly look like something but it isn't there by
design.

> # fdisk -l /dev/sdb2

Again, there isn't normally a partition table at /dev/sdb2.  What
makes you want to look there for one?  That would normally be the
start of either file system or swap or other data use for that
partition.  The partition table is at /dev/sdb.

> # parted /dev/sdb unit s print
> Model: SanDisk Cruzer (scsi)
> Disk /dev/sdb: 7913471s
> Sector size (logical/physical): 512B/512B
> Partition Table: msdos
> Disk Flags: 
> 
> Number  Start  End     Size    Type     File system  Flags
>  2      252s   63739s  63488s  primary  fat16        esp
> 
> What happened to first partition ?

It was empty and so not displayed.  The above shows basically the same
information as fdisk displayed.  Since fdisk handled it there isn't
anything more for parted to add.  The value for me is when fdisk can't
handle the partition table and then parted usually will be able to do so.

> Some more (weird) entries:
> 
> # parted /dev/sdb1 unit s print

Yes.  Weird that you would try to print a partition table from
/dev/sdb1.  There isn't one there normally.

> # parted /dev/sdb2 unit s print

Same thing again for /dev/sdb2.  Garbage in produces garbage out.

> Somewhat unusual :-)

I think you are still missing the understanding that /dev/sdb is the
entire disk from start to finish of the disk.  One creates a partition
table at the first disk block.  That divides up the rest of the disk
into partitions.  The first partition is /dev/sdb1 and the second is
/dev/sdb2 and so forth.  File systems, swap, other users are placed
into those partitions.  There isn't usually *another* partition table
placed there.

Of course I have to qualify everything with a "normally" or "usually"
and so forth.  Because it is all like a book with blank sheets of
paper.  Normally the title is at the front and chapters in the middle.
But that doesn't prevent someone from writing things into the blank
sheets in an unusual way.  The disk is like that too.  Nothing
prevents someone from copying a disk image which contains a partition
table into a primary partition on a disk.  In that case it will appear
that there are two partition tables.  And that could be applied again
and again.

But that is like copying the contents of one book into the blank
sheets of a blank book.  And then copying another book into its blank
sheets and so on.  Yes you can copy a book that way but you don't
normally find books that have been done that way.  Most books have a
title up front, table of contents, body content in that order.  Disks
are the same way.  Most disks have a partition table dividing up the
disk into partitions.  Then those partitions are used to hold file
system data.

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]