You are not logged in.

#1 2008-08-12 17:32:41

roog
Member
Registered: 2008-08-12
Posts: 7

disk by uuid

In Grub, the root device is specified by UUID, example:

kernel /boot/vmlinuz26 root=/dev/disk/by-uuid/8def79a8-3257-4412-a9d3-fe95a55fcb06 ro

After I built my custom kernel, which doesn't need an initrd, booting using UUIDs no longer worked (I got a kernel panic saying that it could not mount the root fs). Using the traditional /dev/sdX way works fine however.

Please can someone verify that the usage of UUIDs is only necessary when using an initrd (because the initrd might change the /dev/sdX naming)? If it's not, then in what way do I need to change my kernel config so it can handle UUIDs?

Thanks!

Last edited by roog (2008-08-13 05:42:53)

Offline

#2 2008-08-12 18:42:07

vogt
Member
From: Toronto, Canada
Registered: 2006-11-25
Posts: 389

Re: disk by uuid

It might be helpful to 'diff' the kernel config you made, and the one for the vanilla arch one.

Presumably you have not included whatever is necessary for uuids in your kernel. When you run your new kernel, does blkid (as root) show the root having the same uuid as with the other kernel?

Offline

#3 2008-08-12 18:45:00

roog
Member
Registered: 2008-08-12
Posts: 7

Re: disk by uuid

Yes, blkid gives me the same UUIDs as the standard ARCH kernel.

Last edited by roog (2008-08-12 18:45:25)

Offline

#4 2008-08-13 02:17:59

vogt
Member
From: Toronto, Canada
Registered: 2006-11-25
Posts: 389

Re: disk by uuid

roog wrote:

Please can someone verify that the usage of UUIDs is only necessary when using an initrd (because the initrd might change the /dev/sdX naming)? If it's not, then in what way do I need to change my kernel config so it can handle UUIDs?

The need for uuids is because they are a naming system that almost guarantees that that uuid belongs to that partition: if you reformat that partition, then you can't boot the new partition using a uuid, since that isn't the same partition. /dev/sdx naming would try to boot the new one.

That is more an issue if you have multiple disks and switch them, or if you have two hdd controllers whose modules cannot be loaded in a predefined order (people see this more often with which network device is eth0, which is eth1), or if the driver changes between releases to call a disk /dev/sda instead of /dev/hda, or some other scheme.

In any case it is a more robust system to use uuids, but the other way works too!

The code that goes into the ata_piix might have some info, though something might pop up when you run diff (vimdiff?) on your config and arch's config.

Offline

#5 2008-08-13 05:38:51

krisvek
Member
Registered: 2008-04-19
Posts: 20

Re: disk by uuid

i noticed a difference when trying to compile using both the PKGBUILD provided in the wiki under "Custom Kernel Compilation with ABS" and the one provided with ABS (the offical one).  The wiki one pulled down 2.6.26.2 whole, while the ABS one pulled down 2.6.26 and then patched it to .2 with patches sources from archlinux.org, SO... the Arch guys may have made some patches that fixed an issue with udev or somesuch.  When I compiled with the wiki one, it couldnt find anything with the uuid, but the ABS PKGBUILD worked fine.

Offline

#6 2008-08-13 06:33:17

roog
Member
Registered: 2008-08-12
Posts: 7

Re: disk by uuid

Thanks for your help!

Doing a diff gives me a lot of differences (which makes sense, since the ARCH kernel comes with a lot of modules I don't need), but as far as I can tell none of them has something to do with UUIDs. The documentation of ata_piix doesn't help either.

As krisvek noticed it might have to do something with the ARCH patches. However, I guess those are the ones found here and they don't say anything about UUIDs. Krisvek, did you use an initrd or not?

I'm not sure but I think that the udev hook of an initrd is responsible for creating the UUID symlinks and not some kind of kernel module. Since I'm not using an initrd and the kernel is booted straight away, those links are not created yet (they will be created later in the boot process by udev) and therefore booting the kernel using the root=/dev/disk/by-uuid parameter doesn't work.

Is this correct?

Last edited by roog (2008-08-13 07:17:21)

Offline

Board footer

Powered by FluxBB