I have a bootable USB HD based on Slackware 11, using the 2.6.21.3 kernel.

If I edit fstab as follows, the USB HD will successfully boot to a computer with internal IDE drives.

/dev/sda1 / ext3 defaults 1 1
/dev/sda2 /home ext3 defaults 1 2
/dev/sda3 swap swap defaults 0 0

And if I edit fstab as follow, the USB HD will successfully boot to a computer with an internal SATA drive.

/dev/sdb1 / ext3 defaults 1 1
/dev/sdb2 /home ext3 defaults 1 2
/dev/sdb3 swap swap defaults 0 0

However, the purpose of the USB HD is to be able to take it to any computer without knowing, in advance, how it is configured. (Editing fstab isn't going to work.)

So, I tried labels.

The fstab contains lines such as
LABEL=SOLD_ROOT_USB / ext3 defaults 1 1
LABEL=SOLD_HOME_USB /home ext3 defaults 1 2
LABEL=SOLD_SWAP_USB swap swap defaults 0 0

This works just fine on the IDE only computer. But when I visit the SATA computer that has Windows on /dev/sda1, I get the following.

/sbin/e2fsck:Bad magic number in super-block while trying to open /dev/sda1

/dev/sda1:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

This computer also has Linux (Slackware 11, 2.6.21.3) on the SATA drive. So, I can boot Linux and successfully execute
# e2fsck LABEL=SOLD_ROOT_USB

So I edit the first line in fstab to use /dev/sdb1 and boot.
Turns out it was time to check the fs. e2fsck identified the partition it was checking as SOLD_ROOT_USB.

Once booted, I find that /home is mounted with SOLD_HOME_USB still in fstab. I can umount and mount /home successfully.

If I try to fsck LABEL=SOLD_ROOT_USB, I get warned that /dev/sdb1 is mounted. Seems it's the correct label.

The problem with the name only seems to happen during boot and after the root fs is already mounted ro.

Finally here's a blkid dump in case that helps
/dev/sda1: TYPE="ntfs"
/dev/sda8: UUID="f7ae0cb6-c167-418e-b247-34b43603ca19" TYPE="ext2" LABEL="HUGH_TEST"
/dev/dvd: TYPE="iso9660"
/dev/sdb3: TYPE="swap" LABEL="SOLD_SWAP_USB" UUID="496df4d5-a1a7-4ce8-a37d-cf3804b4d0b8"
/dev/sdb2: LABEL="SOLD_HOME_USB" UUID="9a6f145d-ed9b-4abc-866c-8c139dfa7f40" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda9: UUID="f88a7cbe-ac10-4266-8eb1-9d7792edc1b0" SEC_TYPE="ext2" TYPE="ext3" LABEL="HUGH_TINY"
/dev/sda2: TYPE="ntfs"
/dev/sda3: TYPE="ntfs"
/dev/sda5: UUID="fb198432-1dab-45a9-b36b-ed003c2c8e48" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda6: UUID="727127da-4c7f-4dc1-9114-12944b2140f4" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda7: UUID="2fb4777e-afaf-47a3-b518-9ab47683f3a9" SEC_TYPE="ext2" TYPE="ext3"
/dev/cdrom: TYPE="iso9660"
/dev/sda10: TYPE="swap" LABEL="SWAP_HD" UUID="5367bc10-9160-4e99-83dd-66b5c184afac"
/dev/sdb1: LABEL="SOLD_ROOT_USB" UUID="780b0f7c-285d-45a2-8da8-ac8d6b195cd5" SEC_TYPE="ext2" TYPE="ext3"

Update. The problem is inconsistent.

I just tried booting computer A (SATA) and then computer B (pure IDE). They both worked. But then I went back to the SATA box and it failed, trying to check sda1 (when it should be sdb1).

So, some of the time it works and some of the time it doesn't?

I'd put a sleep in there to give the usb drivers time to load but the root fs is already mounted read-only. The drivers are clearly running.

Looks to me like you need to boot with an initrd so all the drivers can register before trying to mount /.

You might try using rootdelay= in your bootloader line instead. Or you might put use '/dev/rootfs' as the boot device and depend on the bootloader line to specify the drive.

Thanks. I'm already using an initrd and rootdelay.

I'll read more about rootfs.

In the meantime, I solved the problem a different way. I had already determined the eventual root partition by using a tag file. The fs was already mounted rw. So, I updated its fstab file, on the fly, with the correct /dev/sd?? entry.

So, I don't need more help but am still interested in learning more about the problem. It still seems odd that ext2fs believes it finds the label and "thinks" it points to a different drive.

Anyway, thanks for the reply.

My Archlinux system works very similarly. I use persistent block device naming, via /dev/disk/by-label, and here's why.
GRUB, at least on my machine sees hd0,0 as the first boot device according to the BIOS, but udev seems to want to make this drive sdb1..NOT sda1, IF I have an additional SATA drive installed. What this boils down to is that, at least on my machine, hd0,0 is NOT necessarily sda1. If I have additional drives hooked up, I can either make the kernel line root=/dev/disk-by-label/archlinux -or- root=/dev/sdb1, even though GRUB is pointing to hd0,0 in both cases. So, the key for me, is not so much the persistent block device naming, but more the GRUB numbering scheme being in sync with my BIOS boot device ordering. So..as long as I have GRUB pointing to the right drive according to my boot order, I use disk labeling, which spares me from having to tweak menu.lst every time I change around my harddrives. (Which is often for me) Hope this helps.
More info here: http://wiki.archlinux.org/index.php/..._device_naming