Which command performs this operation?

Completely Clueless · 02-24-2013, 08:14 AM

Hi gang,

I've been away from Linux for 18 months and have forgotten a couple of things (my advanced age, no doubt, doesn't help). What is the bash command which lists all volumes physically attached to the system whether mounted or not?

Thanks, CC.

shivaa · 02-24-2013, 08:19 AM

Try following:

Code:

~$ dmesg
~$ df -h
~$ fdisk -l
~$ cat /etc/fstab
~$ cat /etc/mtab

Check manuals of commands also:

Code:

~$ man <command_name>

Completely Clueless · 02-24-2013, 08:26 AM

Hi all,

For the purposes of imaging a 4Gb SD card containing a Raspberry Pi operating system to an 8Gb usb stick in such a way as to be able to reload the O/S in its original, bootable format to the card from the stick if needed, would the following command do the job?

Code:

# dd if=/dev/sda of=/dev/sdb bs=4096 conv=noerror notrunc

And should both card and stick be unmounted when running this operation?

I'm a bit rusty so thought I'd best check first...

shivaa · 02-24-2013, 08:43 AM

Yes, it will.

Code:

dd if=/path/to/sd_card of=/path/to/usb_stick bs=4096 conv=noerror notrunc

But once let's know that does SD card contain a 'single bootable disk image of the OS' or extracted content of the OS or anything else?

Completely Clueless · 02-24-2013, 08:56 AM

Quote:

Originally Posted by shivaa

But once let's know that does SD card contain a 'single bootable disk image of the OS' or extracted content of the OS or anything else?

Not quite sure what you mean. The SD card I wish to image contains an installation of Raspbian Linux which the Raspberry Pi boots from. That's all.

shivaa · 02-24-2013, 09:14 AM

Quote:

Not quite sure what you mean. The SD card I wish to image contains an installation of Raspbian Linux which the Raspberry Pi boots from. That's all.

I simply mean, what's content of SD card? Does it contain a single file (with .iso as file extension) or lots of files?

suicidaleggroll · 02-24-2013, 09:43 AM

Quote:

Originally Posted by Completely Clueless

What is the bash command which lists all volumes physically attached to the system whether mounted or not?

That would be "fdisk -l"

rknichols · 02-24-2013, 09:52 AM

To get more info about volumes with recognizable content, you can use blkid. For example:

Code:

# blkid
/dev/sda2: LABEL="F12root" UUID="51160411-a0bb-40e8-bac0-bedd7ff57c09" TYPE="ext3" 
/dev/sda5: LABEL="F12usr" UUID="68cfc1a8-5298-48d1-bc6e-fa412f79e082" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda6: LABEL="F12var" UUID="43a87d4c-5aea-4eb2-b595-77593f99e788" TYPE="ext3" 
/dev/sda8: LABEL=":/srv" UUID="e1ddf9ba-01b5-404b-a2f1-401744fc3587" TYPE="ext3" 
/dev/sda10: UUID="F3fL1l-vHhM-qdT9-2QK4-oeZU-AN3m-1owI18" TYPE="LVM2_member" 
/dev/sda11: UUID="nQdat7-9xF4-Jp11-9kTu-pJIp-10AQ-YBPbMU" TYPE="LVM2_member" 
/dev/mapper/swap01: UUID="bee77b2d-6bd3-4831-b464-e5a6548c2628" TYPE="swap" 
/dev/sdb1: UUID="5866c8fa-3daf-4840-8ddc-02a8d7b5cd33" TYPE="crypto_LUKS" 
/dev/sdb2: UUID="e37ae7b0-085f-4e91-b74a-575d265f60b9" TYPE="crypto_LUKS" 
#

Completely Clueless · 02-24-2013, 10:10 AM

Quote:

Originally Posted by shivaa

I simply mean, what's content of SD card? Does it contain a single file (with .iso as file extension) or lots of files?

The fact that it's a card with a Raspbian system on it that runs on a Pi would indicate that it's NOT a single file .iso image, would it not? This is why I don't really understand your question...

Completely Clueless · 02-24-2013, 10:11 AM

Quote:

Originally Posted by rknichols

To get more info about volumes with recognizable content, you can use blkid. For example:

Code:

# blkid
/dev/sda2: LABEL="F12root" UUID="51160411-a0bb-40e8-bac0-bedd7ff57c09" TYPE="ext3" 
/dev/sda5: LABEL="F12usr" UUID="68cfc1a8-5298-48d1-bc6e-fa412f79e082" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda6: LABEL="F12var" UUID="43a87d4c-5aea-4eb2-b595-77593f99e788" TYPE="ext3" 
/dev/sda8: LABEL=":/srv" UUID="e1ddf9ba-01b5-404b-a2f1-401744fc3587" TYPE="ext3" 
/dev/sda10: UUID="F3fL1l-vHhM-qdT9-2QK4-oeZU-AN3m-1owI18" TYPE="LVM2_member" 
/dev/sda11: UUID="nQdat7-9xF4-Jp11-9kTu-pJIp-10AQ-YBPbMU" TYPE="LVM2_member" 
/dev/mapper/swap01: UUID="bee77b2d-6bd3-4831-b464-e5a6548c2628" TYPE="swap" 
/dev/sdb1: UUID="5866c8fa-3daf-4840-8ddc-02a8d7b5cd33" TYPE="crypto_LUKS" 
/dev/sdb2: UUID="e37ae7b0-085f-4e91-b74a-575d265f60b9" TYPE="crypto_LUKS" 
#

Ooh. That's nifty. Not seen that command before.
The one I had in mind was fdisk -l which the guys above correctly identified.

Completely Clueless · 02-24-2013, 05:19 PM

Oops! Just noticed I made a typo. Should be:

Code:

# dd if=/dev/sda of=/dev/sdb bs=4096 conv=noerror,notrunc

Some authorities say that the source drive should never be mounted for this operation; others say neither source nor target should be. Anyone super-knowledgeable care to settle the question?

suicidaleggroll · 02-24-2013, 09:00 PM

Quote:

Originally Posted by Completely Clueless

Oops! Just noticed I made a typo. Should be:

Code:

# dd if=/dev/sda of=/dev/sdb bs=4096 conv=noerror,notrunc

Some authorities say that the source drive should never be mounted for this operation; others say neither source nor target should be. Anyone super-knowledgeable care to settle the question?

The target definitely shouldn't be mounted, I don't think it makes a difference if the source is mounted or not.

rknichols · 02-24-2013, 10:44 PM

The source should not be mounted read/write (read-only is OK) or the target will end up with a mildly corrupted filesystem that needs an fsck to clean it up. (Try running "fsck -f -n" on a mounted filesystem if you want to see what to expect. Do not leave off the "-n" or fsck will be very unhappy with you.)

Completely Clueless · 02-25-2013, 03:41 PM

Well in that case it's clear that neither drive should be mounted, then. Next question that arises is: how does the file system get corrupted?? I'm guessing dd isn't the culprit here, so what is?

rknichols · 02-25-2013, 06:11 PM

While a filesystem is mounted read/write, the on-disk metadata is not in a totally clean state. One fairly obvious case is files that have been deleted but are still held open by some process. These will show up in fsck as orphaned inodes (inode is busy, but is not linked from any directory), and fsck will dutifully recover these and put them in lost+found. For any file that is open for writing, the only true copy of the inode state is in memory, not on the disk, and that is true for block allocation maps and group descriptors as well. At a minimum, the "needs_recovery" flag will always be set in the super block.