NSLU2-Linux
view · edit · print · history

HowTo.MountDisksByLabel History

Hide minor edits - Show changes to markup

June 19, 2010, at 03:04 PM by Kees Moerman -- Minor readability change in my previous update
Changed lines 117-118 from:

Note: the below section is no longer needed for Debian Lenny 5.0.4 (bug solved). You can just use the APEX tool (apex-env command) without worry about the MTD block, to add the root disk by label as described in the above section. Next, reflash the flash (takes also care of the actual flashing) with the command update-initramfs -k all -u

to:

Note: the below section is no longer needed for Debian Lenny 5.0.4 (bug solved); you can just use the APEX tool (apex-env command) without worry about the MTD block, to add the root disk by label as described in the above section. Next, reflash the flash (takes also care of the actual flashing) with the command update-initramfs -k all -u. End of note.

May 10, 2010, at 03:04 PM by Kees Moerman -- Note on root file system bug solved in Lenny
Added line 110:

[@

Changed lines 112-113 from:
to:

@]

Added lines 117-118:

Note: the below section is no longer needed for Debian Lenny 5.0.4 (bug solved). You can just use the APEX tool (apex-env command) without worry about the MTD block, to add the root disk by label as described in the above section. Next, reflash the flash (takes also care of the actual flashing) with the command update-initramfs -k all -u

November 10, 2008, at 01:08 PM by john -- i wasnt sure..
Deleted lines 116-117:

[ Update, 9th November 2008: I didn't found this bug in last daily image of Debian distribution ]

November 09, 2008, at 07:57 PM by john -- comment
Added lines 117-118:

[ Update, 9th November 2008: I didn't found this bug in last daily image of Debian distribution ]

August 18, 2008, at 02:02 PM by fcarolo -- fixed false wikilnks
Changed lines 35-37 from:

Choose labels that use characters that are legal in filenames. In particular I suggest not using the "/" character in labels since it breaks the /dev/disk stuff described below. This is an interesting point because I believe that RedHat? may have standardised on using "/" as the label on the root filesystem; this works for them because they use an alternative "LABEL=" syntax instead of /dev/disk.

OpenWrt uses the same "LABEL=" syntax as RedHat?. So the "/etc/fstab" entries will differ from the Debian entries below.

to:

Choose labels that use characters that are legal in filenames. In particular I suggest not using the "/" character in labels since it breaks the /dev/disk stuff described below. This is an interesting point because I believe that RedHat may have standardised on using "/" as the label on the root filesystem; this works for them because they use an alternative "LABEL=" syntax instead of /dev/disk.

OpenWrt uses the same "LABEL=" syntax as RedHat. So the "/etc/fstab" entries will differ from the Debian entries below.

Changed lines 72-74 from:

I believe that these symlinks are all created by udev. You should be able to see the labels that you've just added under /dev/disk/by-label. If you prefer cryptic UUIDs? to human-readable labels for some reason you can use the links in /dev/by-uuid. The /dev/by-path links may provide a way to refer to a disk by the hub port that it is connected to, if that is useful to you.

to:

I believe that these symlinks are all created by udev. You should be able to see the labels that you've just added under /dev/disk/by-label. If you prefer cryptic UUIDs to human-readable labels for some reason you can use the links in /dev/by-uuid. The /dev/by-path links may provide a way to refer to a disk by the hub port that it is connected to, if that is useful to you.

August 18, 2008, at 04:15 AM by stanley_p_miller --
Changed lines 86-87 from:

Or for OpenSlug:

to:

Or for OpenSlug: (You may have to label the partitions on another system)

February 10, 2008, at 12:44 PM by BWare -- OpenWrt config added
Added lines 37-39:

OpenWrt uses the same "LABEL=" syntax as RedHat?. So the "/etc/fstab" entries will differ from the Debian entries below. NOTE: I haven't tested the 'root' label, as my boot device is connected directly to the slug and does not change disk ID.

Changed lines 86-87 from:

I suggest checking to see if you have any other files in /etc that use /dev/sd. I didn't find any.

to:

Or for OpenSlug:

Changed lines 89-92 from:
  1. grep -R 'sd[ab]' /etc
to:

proc /proc proc defaults 0 0 LABEL=root / ext3 noatime 1 1 LABEL=swap none swap sw 0 0 LABEL=data /data ext3 noatime 0 0

Changed lines 95-103 from:
to:

NOTE: The 'root' entry is untested as stated in the previous note

I suggest checking to see if you have any other files in /etc that use /dev/sd. I didn't find any.

# grep -R 'sd[ab]' /etc
February 10, 2008, at 12:36 PM by Reedy Boy -- ##
Changed lines 114-117 from:
  • /dev/mtdblock4; check the partition number in /proc/mtd (look for Ramdisk), strip the 16-byte header and change the endianness.
  • slugimage -u; you want the ramdisk.gz file. No header to strip, not sure about endianness.
  • /boot/initrd.img, if you haven't previously changed it. No header to strip, endianness is correct.
to:
  1. /dev/mtdblock4; check the partition number in /proc/mtd (look for Ramdisk), strip the 16-byte header and change the endianness.
  2. slugimage -u; you want the ramdisk.gz file. No header to strip, not sure about endianness.
  3. /boot/initrd.img, if you haven't previously changed it. No header to strip, endianness is correct.
February 10, 2008, at 12:36 PM by Reedy Boy -- ##
Changed lines 125-128 from:
  1. * Package using slugimage and then upslug2. I'm not sure about padding or endianness requirements if you do this.
  2. * cat into /dev/mtdblock4. In this case you need to prepend a 16-byte header containing the length in the first four bytes (big endian), pad with zeros to the length of the mtd partition and byte swap. I suggest sanity-checking the first few bytes using od -x | head to see if the format (especially length and endianness) looks the same as your current /dev/mtdblock4 contents. Zero-padding seems to be essential as junk after the end of the gzip data can make the kernel decide that it is not looking at an initramfs.
  3. * Use flash_kernel. I've not looked at this.
to:
  1. Package using slugimage and then upslug2. I'm not sure about padding or endianness requirements if you do this.
  2. cat into /dev/mtdblock4. In this case you need to prepend a 16-byte header containing the length in the first four bytes (big endian), pad with zeros to the length of the mtd partition and byte swap. I suggest sanity-checking the first few bytes using od -x | head to see if the format (especially length and endianness) looks the same as your current /dev/mtdblock4 contents. Zero-padding seems to be essential as junk after the end of the gzip data can make the kernel decide that it is not looking at an initramfs.
  3. Use flash_kernel. I've not looked at this.
February 10, 2008, at 12:35 PM by Reedy Boy -- move out
Changed lines 125-128 from:
  • Package using slugimage and then upslug2. I'm not sure about padding or endianness requirements if you do this.
  • cat into /dev/mtdblock4. In this case you need to prepend a 16-byte header containing the length in the first four bytes (big endian), pad with zeros to the length of the mtd partition and byte swap. I suggest sanity-checking the first few bytes using od -x | head to see if the format (especially length and endianness) looks the same as your current /dev/mtdblock4 contents. Zero-padding seems to be essential as junk after the end of the gzip data can make the kernel decide that it is not looking at an initramfs.
  • Use flash_kernel. I've not looked at this.
to:
  1. * Package using slugimage and then upslug2. I'm not sure about padding or endianness requirements if you do this.
  2. * cat into /dev/mtdblock4. In this case you need to prepend a 16-byte header containing the length in the first four bytes (big endian), pad with zeros to the length of the mtd partition and byte swap. I suggest sanity-checking the first few bytes using od -x | head to see if the format (especially length and endianness) looks the same as your current /dev/mtdblock4 contents. Zero-padding seems to be essential as junk after the end of the gzip data can make the kernel decide that it is not looking at an initramfs.
  3. * Use flash_kernel. I've not looked at this.
Deleted lines 129-130:
February 10, 2008, at 12:35 PM by Reedy Boy -- go back again
Changed line 105 from:
#update-initramfs
Generating /boot/initrd.img-2.6.18-3-ixp4xx
to:
  1. update-initramfs: Generating /boot/initrd.img-2.6.18-3-ixp4xx
Changed lines 107-109 from:
#Flashing kernel
done.
#Flashing initramfs
done.
to:
  1. Flashing kernel: done.
  2. Flashing initramfs: done.
February 10, 2008, at 12:35 PM by Reedy Boy -- again
Changed line 105 from:
  1. :update-initramfs: Generating /boot/initrd.img-2.6.18-3-ixp4xx
to:
#update-initramfs
Generating /boot/initrd.img-2.6.18-3-ixp4xx
Changed lines 107-109 from:
  1. :Flashing kernel: done.
  2. :Flashing initramfs: done.
to:
#Flashing kernel
done.
#Flashing initramfs
done.
February 10, 2008, at 12:34 PM by Reedy Boy -- tweak to last
Changed line 105 from:
  1. update-initramfs: Generating /boot/initrd.img-2.6.18-3-ixp4xx
to:
  1. :update-initramfs: Generating /boot/initrd.img-2.6.18-3-ixp4xx
Changed lines 107-109 from:
  1. Flashing kernel: done.
  2. Flashing initramfs: done.
to:
  1. :Flashing kernel: done.
  2. :Flashing initramfs: done.
February 10, 2008, at 12:34 PM by Reedy Boy -- try improve
Changed line 105 from:

update-initramfs: Generating /boot/initrd.img-2.6.18-3-ixp4xx

to:
  1. update-initramfs: Generating /boot/initrd.img-2.6.18-3-ixp4xx
Changed lines 107-109 from:

Flashing kernel: done. Flashing initramfs: done.

to:
  1. Flashing kernel: done.
  2. Flashing initramfs: done.
January 21, 2008, at 12:11 AM by DMH -- Just clarifying parameters to reader
Changed lines 25-26 from:
to:

Where -L specifies the name you'll be assigning the drive (in this case, "root")

January 05, 2007, at 11:25 AM by Phil Endecott -- Note that kernel command line root= parameter is still ignored after update-initramfs fix
Changed lines 100-101 from:

At the time of writing the Debian / NSLU2 distribution has a bug which will cause the root disk that you specify on the kernel command line to be ignored. The problem is inside the initramfs. To fix it, simply set the root filesystem in a new /etc/initramfs-tools/conf.d file and recreate the initramfs:

to:

At the time of writing the Debian / NSLU2 distribution has a bug which will cause the root disk that you specify on the kernel command line to be ignored. The problem is inside the initramfs. You can work around this by setting the root device in a new /etc/initramfs-tools/conf.d file and recreating the initramfs. The kernel command line root parameter will still be ignored.

Changed lines 109-111 from:

If you use a custom initramfs, or for some other reason can not use update-initramfs, here is an outline of how to fix the bug manually. For more details of how to manage initramfs files, have a look at BuildImage. You probably need to do most of this as root as otherwise the cpio archive that you create will have the wrong ownership information on the files.

to:

If you want to fix it so that the kernel command line parameter is not ignored, or if you use a custom initramfs or for some other reason can not use update-initramfs, here is an outline of how to fix the bug properly. For more details of how to manage initramfs files, have a look at BuildImage. You probably need to do most of this as root as otherwise the cpio archive that you create will have the wrong ownership information on the files.

January 01, 2007, at 03:49 PM by lorentey -- Add simpler workaround for mkinitramfs bug
Changed lines 100-101 from:

At the time of writing the Debian / NSLU2 distribution has a bug which will cause the root disk that you specify on the kernel command line to be ignored. The problem is inside the initramfs. Here is an outline of how to fix the bug. For more details of how to manage initramfs files, have a look at BuildImage. You probably need to do most of this as root as otherwise the cpio archive that you create will have the wrong ownership information on the files.

to:

At the time of writing the Debian / NSLU2 distribution has a bug which will cause the root disk that you specify on the kernel command line to be ignored. The problem is inside the initramfs. To fix it, simply set the root filesystem in a new /etc/initramfs-tools/conf.d file and recreate the initramfs:

  1. echo "ROOT=<Your root device>" > /etc/initramfs-tools/conf.d/my-root-device-hack
  2. update-initramfs -k all -u

update-initramfs: Generating /boot/initrd.img-2.6.18-3-ixp4xx

  1. flash-kernel

Flashing kernel: done. Flashing initramfs: done.

If you use a custom initramfs, or for some other reason can not use update-initramfs, here is an outline of how to fix the bug manually. For more details of how to manage initramfs files, have a look at BuildImage. You probably need to do most of this as root as otherwise the cpio archive that you create will have the wrong ownership information on the files.

December 13, 2006, at 08:40 PM by Peter Enzerink -- more emphatic about restart
Changed lines 36-38 from:

At this point I suggest rebooting, as the kernel may not be fully aware of the labels until the affected filesystems are remounted. Or something like that.

to:

At this point you should reboot, as the kernel will not be fully aware of the labels until the affected filesystems are remounted.

December 08, 2006, at 06:59 PM by Scott Carpenter -- spelling
Changed lines 93-94 from:

For Debian / NSLU2, chaning the kernel command line is described on ChangeKernelCommandLine. Currently it's a bit complicated. You need to add a parameter something like:

to:

For Debian / NSLU2, changing the kernel command line is described on ChangeKernelCommandLine. Currently it's a bit complicated. You need to add a parameter something like:

Changed lines 100-101 from:

At the time of writing the Debian / NSLU2 distribution has a bug which will cause the root disk that you specify on the kernel command line to be ignored. The probalem is inside the initramfs. Here is an outline of how to fix the bug. For more details of how to manage initramfs files, have a look at BuildImage. You probably need to do most of this as root as otherwise the cpio archive that you create will have the wrong ownership information on the files.

to:

At the time of writing the Debian / NSLU2 distribution has a bug which will cause the root disk that you specify on the kernel command line to be ignored. The problem is inside the initramfs. Here is an outline of how to fix the bug. For more details of how to manage initramfs files, have a look at BuildImage. You probably need to do most of this as root as otherwise the cpio archive that you create will have the wrong ownership information on the files.

November 27, 2006, at 02:00 PM by Phil Endecott -- Final formating fixes (preview definitely broken)
Added line 84:

[@

Changed lines 86-87 from:
to:

@]

November 27, 2006, at 01:56 PM by Phil Endecott -- More formatting changes
Added line 22:

[@

Changed lines 24-25 from:
to:

@]

Added line 28:

[@

Changed lines 32-33 from:
to:

@]

Changed line 43 from:

[=

to:

[@

Changed lines 66-67 from:

=]

to:

@]

Added line 75:

[@

Changed lines 80-81 from:
to:

@]

Changed lines 91-92 from:

For NSLU2, chaning the kernel command line is described on ChangeKernelCommandLine. Currently it's a bit complicated. You need to add a parameter something like:

to:

For Debian / NSLU2, chaning the kernel command line is described on ChangeKernelCommandLine. Currently it's a bit complicated. You need to add a parameter something like:

November 27, 2006, at 01:52 PM by Phil Endecott -- Formatting fixes (preview is broken?)
Changed lines 7-8 from:

This page is written with NSLU2 in mind. It is probably somewhat applicable to other NSLU2 software distributions. Users of other distributions, please add comments.

to:

This page is written with Debian / NSLU2 in mind. It is probably somewhat applicable to other NSLU2 software distributions. Users of other distributions, please add comments.

Added line 39:

[=

Changed lines 62-63 from:
to:

=]

Changed lines 92-93 from:

At the time of writing the NSLU2 distribution has a bug which will cause the root disk that you specify on the kernel command line to be ignored. The probalem is inside the initramfs. Here is an outline of how to fix the bug. For more details of how to manage initramfs files, have a look at BuildImage. You probably need to do most of this as root as otherwise the cpio archive that you create will have the wrong ownership information on the files.

to:

At the time of writing the Debian / NSLU2 distribution has a bug which will cause the root disk that you specify on the kernel command line to be ignored. The probalem is inside the initramfs. Here is an outline of how to fix the bug. For more details of how to manage initramfs files, have a look at BuildImage. You probably need to do most of this as root as otherwise the cpio archive that you create will have the wrong ownership information on the files.

November 27, 2006, at 01:51 PM by Phil Endecott -- Create this page
Added lines 1-110:

How to mount disks by label

The order in which USB devices are initialised at boot time is somewhat random. This is problematic in the case of disks as the SCSI drive identifiers (sda, sdb etc) normally used to refer to them in /etc/fstab are allocated sequentially. One way to avoid this problem is to give labels to each of the filesystems and to refer to them using those labels in /etc/fstab.

If your slug always seems to power on with its drives in the same order, you may just be lucky. Maybe next week you'll add a new peripheral and it will all change. In my case I replaced a failed flash drive with a new one and subsequently the two drives swapped around on each boot.

This page is written with NSLU2 in mind. It is probably somewhat applicable to other NSLU2 software distributions. Users of other distributions, please add comments.

The basic procedure is as follows:

  1. Add labels to your filesystems.
  2. Change /etc/fstab to use the labels.
  3. Change the kernel command line to use a label for the root disk.

Adding labels to filesystems

Note that the labels apply to partitions, not to disks.

For ext2 and ext3 filesystems you can use the tune2fs program to add labels:

  1. tune2fs -L root /dev/sda1

For your swap partition you can set a label using mkswap, but you need to swapoff first:

  1. swapoff -a
  2. mkswap -L swap /dev/sda2
  3. swapon -a

Choose labels that use characters that are legal in filenames. In particular I suggest not using the "/" character in labels since it breaks the /dev/disk stuff described below. This is an interesting point because I believe that RedHat? may have standardised on using "/" as the label on the root filesystem; this works for them because they use an alternative "LABEL=" syntax instead of /dev/disk.

At this point I suggest rebooting, as the kernel may not be fully aware of the labels until the affected filesystems are remounted. Or something like that.

/dev/disk

Have a look at /dev/disk:

  1. tree /dev/disk

/dev/disk |-- by-id | |-- usb-JetFlash?_TS1GJFV30_DZPCOJC7 -> ../../sdb | |-- usb-JetFlash?_TS1GJFV30_DZPCOJC7-part1 -> ../../sdb1 | |-- usb-JetFlash?_TS1GJFV30_DZPCOJC7-part2 -> ../../sdb2 | |-- usb-USB_2.0_Flash_Disk_a86144e24194b3 -> ../../sda | `-- usb-USB_2.0_Flash_Disk_a86144e24194b3-part1 -> ../../sda1 |-- by-label | |-- data -> ../../sda1 | |-- root -> ../../sdb1 | `-- swap -> ../../sdb2 |-- by-path | |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sdb | |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sdb1 | |-- pci-0000:00:01.2-usb-0:1:1.0-scsi-0:0:0:0-part2 -> ../../sdb2 | |-- pci-0000:00:01.2-usb-0:2.5:1.0-scsi-0:0:0:0 -> ../../sda | `-- pci-0000:00:01.2-usb-0:2.5:1.0-scsi-0:0:0:0-part1 -> ../../sda1 `-- by-uuid

    |-- 71b2f940-7e96-4e4f-be18-d712073780b8 -> ../../sdb2
    |-- 72ff7f86-243d-4e8f-91cd-40540a60cc1c -> ../../sdb1
    `-- 950b2fb6-9a1e-4bce-85a7-bb796a96a061 -> ../../sda1

I believe that these symlinks are all created by udev. You should be able to see the labels that you've just added under /dev/disk/by-label. If you prefer cryptic UUIDs? to human-readable labels for some reason you can use the links in /dev/by-uuid. The /dev/by-path links may provide a way to refer to a disk by the hub port that it is connected to, if that is useful to you.

/etc/fstab

You can now edit /etc/fstab to refer to partitions using their labels instead of the hard-coded /dev/sd names. Mine now looks like this:

proc /proc proc defaults 0 0 /dev/disk/by-label/root / ext3 noatime 1 1 /dev/disk/by-label/swap none swap sw 0 0 /dev/disk/by-label/data /data ext3 noatime 0 0

I suggest checking to see if you have any other files in /etc that use /dev/sd. I didn't find any.

  1. grep -R 'sd[ab]' /etc

Kernel command line

The kernel doesn't look in /etc/fstab to find the root partition, because /etc/fstab isn't mounted at that time. Instead, the root partition is specified on the kernel command line using the root= parameter; if nothing is specified a default is used.

For NSLU2, chaning the kernel command line is described on ChangeKernelCommandLine. Currently it's a bit complicated. You need to add a parameter something like:

root=/dev/disk/by-label/root

Root filesystem bug

At the time of writing the NSLU2 distribution has a bug which will cause the root disk that you specify on the kernel command line to be ignored. The probalem is inside the initramfs. Here is an outline of how to fix the bug. For more details of how to manage initramfs files, have a look at BuildImage. You probably need to do most of this as root as otherwise the cpio archive that you create will have the wrong ownership information on the files.

  1. Get your existing initramfs archive from either
  • /dev/mtdblock4; check the partition number in /proc/mtd (look for Ramdisk), strip the 16-byte header and change the endianness.
  • slugimage -u; you want the ramdisk.gz file. No header to strip, not sure about endianness.
  • /boot/initrd.img, if you haven't previously changed it. No header to strip, endianness is correct.
  1. Unpack: mkdir tmp; cd tmp; zcat ../mtd4.bin | cpio -i
  2. Now fix the bug. Just move conf/param.conf to conf/conf.d/default_root. Leave an empty file in conf/param.conf.
  3. Repack: find . | cpio --quiet -o -H newc | gzip -9 > ../new-mtd4.bin
  4. Reflash. Either:
  • Package using slugimage and then upslug2. I'm not sure about padding or endianness requirements if you do this.
  • cat into /dev/mtdblock4. In this case you need to prepend a 16-byte header containing the length in the first four bytes (big endian), pad with zeros to the length of the mtd partition and byte swap. I suggest sanity-checking the first few bytes using od -x | head to see if the format (especially length and endianness) looks the same as your current /dev/mtdblock4 contents. Zero-padding seems to be essential as junk after the end of the gzip data can make the kernel decide that it is not looking at an initramfs.
  • Use flash_kernel. I've not looked at this.
  1. Cross fingers and reboot.
Page last modified on June 19, 2010, at 03:04 PM