Finding a rootfs by LABEL or UUID not working

[Charlie]

Hello,

I have multiple USB sticks on one bifferboard, so for reliable booting
I'll need to use one of the LABEL or UUID rootfs locating methods. I
can't seem to get either of them to work though.

The boot process gets as far as:

Waiting for root device LABEL=foo...

I see the USB sticks being recognised and the partitions listed, but
the matching labels/uuids are never noticed.

kernel:
2.6.30.5-bifferboard-pipe (root@FURNA) from
http://blog.famzah.net/2009/11/20/running-debian-on-bifferboard/

cmndline settings:
console=uart,io,0x3f8 init=/etc/preinit root=UUID=deadbeef-dead-beef-
dead-beefdeadbeef rootwait ubi.mtd=rootfs
console=uart,io,0x3f8 init=/etc/preinit root=LABEL=foo rootwait
ubi.mtd=rootfs

I've verified the labels and uuids are correct with tune2fs/blkid.

Does anyone know what I might be doing wrong here? Do I need a
different kernel? (and built-in initramfs)

Thanks!

Charlie

[nicolas le falher]

Hi,

I have no experience with the usb boot, but Openwrt has package for external rootfs on usb : http://wiki.openwrt.org/doc/howto/extroot
Maybe it's easiest to use.

Nicolas

[d1savowed]

Charlie,

I doubt this will work.... IIRC the LABEL or UUID entries under /dev
are populated by udev (it adds entries under /dev/disk/by-uuid etc),
so for this to work you would need an initrd with udev present, and
then get it to pivot root over to your actual USB stick.

In theory it should be possible to create an initrd, attach it to the
end of the kernel, and get it to boot with it, however its no doubt a
lot of hard work :-(

[Charlie]

Thanks for the replies so far.

Yes, udev in an initrd fits my understanding of it, but I'm hoping
someone has already done this!

I'm also hoping to avoid OpenWRT, that'll probably make my entire
project more awkward. I have everything but this LABEL/UUID booting
working already with Debian.

Perhaps it'll just be easier if I use a single USB stick.

[Andrew Scheller]

Afraid it doesn't really help much, but did you already look at
https://groups.google.com/group/bifferboard/search?group=bifferboard&q=uuid
?

There's some *very old* initrd info on the wiki
https://sites.google.com/site/bifferboard/attic/linux-on-flash-howto

Lurch

[Charlie]

On Feb 8, 2:10 am, Andrew Scheller <ya...@loowis.durge.org> wrote:
> Afraid it doesn't really help much, but did you already look athttps://groups.google.com/group/bifferboard/search?group=bifferboard&...
> ?

I did, I didn't find anybody else talking about doing this.

> There's some *very old* initrd info on the wikihttps://sites.google.com/site/bifferboard/attic/linux-on-flash-howto

Ah... that looks useful. I'll try building another kernel and putting
udev into the initramfs.

Thanks!

[Adam Pribyl]

On Tue, 7 Feb 2012, Charlie wrote:

Thats it. The supplied initram images do not support LABEL or UUID
mounting. But, you still may supply root=/dev/sdaX to kernel in biffboot
and then modify the /etc/fstab on this partition to use LABELs. At
remounting the root and other partitions the system will use LABELs.

> Thanks!

Adam Pribyl

[Andrew Scheller]

> Thats it. The supplied initram images do not support LABEL or UUID
> mounting. But, you still may supply root=/dev/sdaX to kernel in biffboot
> and then modify the /etc/fstab on this partition to use LABELs. At
> remounting the root and other partitions the system will use LABELs.

The OP said "I have multiple USB sticks on one bifferboard, so for

reliable booting I'll need to use one of the LABEL or UUID rootfs
locating methods."

so I think the problem is that the /dev/sdX values get randomly
assigned to the different USB devices at power-up. And he probably
doesn't want to replicate his rootfs onto each device ;-)

Lurch

[biff...@yahoo.co.uk]

I remember a patch somewhere, I think it might have been a generic
kernel patch from an earlier version of OpenWrt. It included a series
of instructions to mount a volume and load a file. I think it was
about 15-20 lines long (these things tend to be a lot more complicated
in kernel land than in a user process), however doing this when the
system is in single-user mode is a lot easier than at other times. I
guess it must be possible to use code like that to look for a marker
file on one of the USB sticks and then all you have to do is change
the kernel command-line to use the correct device. I'm not sure if
the command-line is 'read-only' but you're not changing it's length if
you just want to change /dev/sda to /dev/sdb.

The other interesting way might be to mess with the kernel code that
allocates the device name, to make it serve up /dev/
device<vendorID><DeviceID> which will (unless you're unlucky!!) be a
way of distinguishing the two disks.

regards,
Biff.

[Charlie]

On Feb 8, 3:06 pm, "biffe...@yahoo.co.uk" <biffe...@yahoo.co.uk>
wrote:

That's a nice idea, but it would limit me to using only a particular
vendor and device. I'll need to buy more USB sticks later to replace
failed ones and it's unlikely that I'll end up with exactly the same
IDs!

I did think of copying the rootfs to both USB sticks, but that defeats
the purpose of having two. I may as well just use one and this UUID/
LABEL mounting problem goes away. :)

[Andrew Scheller]

> the purpose of having two. I may as well just use one and this UUID/
> LABEL mounting problem goes away. :)

LOL, the classic "throw more resources at it" (i.e. a bigger flash
stick) solution to the problem ;)

Lurch

[biff...@yahoo.co.uk]

Thinking about this some more, the correct way to do this is to
specify the boot flag for the partition you want to boot from, and
make sure it's not set for the second disk (using fdisk). There must
surely be a way for the kernel to determine if the boot flag is set
when it enumerates the partition tables, probably simpler than reading
any marker files or UUIDs etc...

Still have the problem of telling the kernel to boot from the right
one though!

[d1savowed]

Charlie,

The way I have got round this previously (as I quite frequently run
multiple USB disks connected to the BB) is to disable Asynchronous
SCSI Scanning in the kernel. This does require you to essentially roll-
you-own, but means that when the mass storage devices are detected, it
will go through them in the order on the USB bus, rather than
whichever finishes first. With this disabled, you should find that /
dev/sda is always the same device etc.