Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

[Eric Valette]

Hi,

I just bought an new external disk enclosure with e-sata/USB2 connector 
to replace an old USB2 only external disk enclosure.

My internal drive is a small SSD because I use the small factor PC as a 
home theater and do want silence and fast boot. I build my own kernel to 
put only what I need in and also boot somehow faster.

I use grub2 (up to date) as a loader. As soon as I power on the external 
sata disk, the system does not boot because hardware designer add the 
great idea to put the internal sata connector on ata3 whereas the 
external e-sata is wired on ata2.

consequence is that root file system is on sda1 when no external drive 
is connected and sdb1 when the external drive is connected.

As my grub setup was having a root=/dev/sda1 command line parameter and 
it was advertised everywhere that root=UUID=xxxxx was now supported, I 
changed the line to discover that this only work if an initramfs was 
loaded because support is done entirely in used space! Reading 
init/do_mounts.c made it very clear.

I find it extremely curious to have to add an initramfs to support 
dynamic drive identification, especially when the BYID value is 
displayed during boot message.

The boot loader cannot do a better job than the kernel and its life may 
be even worse as bios value for the same disk may change according to 
boot disk priorities.

Any hint comment? Any other way to avoid using a ramdisk? Please CC me 
as I'm not subscribed.

-- eric

Re: Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

[Phil Turmel]

(Adding cut CC...  sorry about the duplicate)

Hi Eric,

On 08/23/2010 10:37 AM, Eric Valette wrote:
> Hi,
> 
> I just bought an new external disk enclosure with e-sata/USB2 connector to replace an old USB2 only external disk enclosure.
> 
> My internal drive is a small SSD because I use the small factor PC as a home theater and do want silence and fast boot. I build my own kernel to put only what I need in and also boot somehow faster.
> 
> I use grub2 (up to date) as a loader. As soon as I power on the external sata disk, the system does not boot because hardware designer add the great idea to put the internal sata connector on ata3 whereas the external e-sata is wired on ata2.
> 
> consequence is that root file system is on sda1 when no external drive is connected and sdb1 when the external drive is connected.
> 
> As my grub setup was having a root=/dev/sda1 command line parameter and it was advertised everywhere that root=UUID=xxxxx was now supported, I changed the line to discover that this only work if an initramfs was loaded because support is done entirely in used space! Reading init/do_mounts.c made it very clear.
> 
> I find it extremely curious to have to add an initramfs to support dynamic drive identification, especially when the BYID value is displayed during boot message.
> 
> The boot loader cannot do a better job than the kernel and its life may be even worse as bios value for the same disk may change according to boot disk priorities.
> 
> Any hint comment? Any other way to avoid using a ramdisk? Please CC me as I'm not subscribed.

Your only alternative is to set up your root partition as an mdraid volume (single-disk raid0 perhaps), mark it type 'fd' so the kernel can auto-assemble it, and specify "root=/dev/md1" (or whatever minor number you set it up as).

Of course, adding an mdraid shim in between your bare device and the filesystem can reduce performance and/or data integrity for no other gain, and slow booting by the time taken examining all partitions.

I actually set up the above once when the ide => libata change-over was pending, since I was determined to NOT use an initramfs.  It worked, but I don't recommend it.

I recently converted all of my other auto-assembly mdraid systems to initramfs w/ the new dracut tool.  Simple, flawless (for me), and fast.

HTH,

Phil

Re: Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

[Eric Valette]

On 08/23/2010 11:56 PM, Phil Turmel wrote:
> (Adding cut CC...  sorry about the duplicate)
>
> Hi Eric,

Hi Phil

I found a solution myself using the grub embedded "search --fs-uuid". I 
do it once the linux boot partition and also on one partition of the 
external disk. If the search on the external disk report an error, I 
know root=/dev/sda1 else root=/dev/sdb1. But I really think this should 
be linux job!

I also converted my /etc/fstab to LABEL=foo /foo syntax.

Now I'm really puzzled grub2 as a "search by fs uuid" command that linux 
is unable to deliver for the root device!

I have seen read hat patch for supporting this feature ext2 as early as 
in 1999!

-- eric

Re: Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

[Phil Turmel]

Hi Eric,

On 08/26/2010 11:32 AM, Eric Valette wrote:
> I found a solution myself using the grub embedded "search --fs-uuid". I do it once the linux boot partition and also on one partition of the external disk. If the search on the external disk report an error, I know root=/dev/sda1 else root=/dev/sdb1. But I really think this should be linux job!

Although this works now, there's no guarantee this will continue to work.  What if you plug in an eSATA enclosure that has a port multiplier and two disks?  I think you'll find your root device on /dev/sdc1.  Or maybe someday a robust scheme for simultaneous probing will be adopted (for faster booting, presumably), and the order will vary from boot to boot.

> I also converted my /etc/fstab to LABEL=foo /foo syntax.

That's good.

> Now I'm really puzzled grub2 as a "search by fs uuid" command that linux is unable to deliver for the root device!

The key word here is "unable".  The maintainers aren't *unable* to do this.  They are *unwilling* to do this.  I don't recall the precise discussion, but basically it boils down to the fact that early userspace (aka initramfs) can do this efficiently, and it needs to be supported in initramfs for other reasons, so it is pointless to duplicate this code in the kernel.  I'm sure block folk will chime in if this isn't a fair representation (my apologies in advance if so).

Try dracut.  Seriously.  It's lean and mean just for this use-case, and you'll be protecting yourself against future changes in the block layer.  And you can put root=LABEL=foo on your kernel command line to match your fstab.

Usage (from your kernel source dir):

$ make
$ make modules
# make modules_install
# make install
# dracut [-v] [-f] '' `make kernelrelease`

HTH,

Phil

Re: Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

[Eric Valette]

On 08/26/2010 09:53 PM, Phil Turmel wrote:

>
>> Now I'm really puzzled grub2 as a "search by fs uuid" command that linux is unable to deliver for the root device!
>
> The key word here is "unable".  The maintainers aren't *unable* to do this.  They are *unwilling* to do this.  I don't recall the precise discussion, but basically it boils down to the fact that early userspace (aka initramfs) can do this efficiently, and it needs to be supported in initramfs for other reasons, so it is pointless to duplicate this code in the kernel.  I'm sure block folk will chime in if this isn't a fair representation (my apologies in advance if so).
>
> Try dracut.  Seriously.  It's lean and mean just for this use-case, and you'll be protecting yourself against future changes in the block layer.  And you can put root=LABEL=foo on your kernel command line to match your fstab.


This is a rather bizarre argument as because of this situation
	1) the code is duplicated between the initramfs and the real disk
	2) the initramfs has to be rebuild each time a new kernel is done
	3) The tmpdevfs is also a dupplicate somehow

Never mind.

-- eric

Re: Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

[Matthias Schniedermeyer]

On 27.08.2010 13:59, Eric Valette wrote:
> On 08/26/2010 09:53 PM, Phil Turmel wrote:
>
>>
>>> Now I'm really puzzled grub2 as a "search by fs uuid" command that linux is unable to deliver for the root device!
>>
>> The key word here is "unable".  The maintainers aren't *unable* to do this.  They are *unwilling* to do this.  I don't recall the precise discussion, but basically it boils down to the fact that early userspace (aka initramfs) can do this efficiently, and it needs to be supported in initramfs for other reasons, so it is pointless to duplicate this code in the kernel.  I'm sure block folk will chime in if this isn't a fair representation (my apologies in advance if so).
>>
>> Try dracut.  Seriously.  It's lean and mean just for this use-case, and you'll be protecting yourself against future changes in the block layer.  And you can put root=LABEL=foo on your kernel command line to match your fstab.
>
>
> This is a rather bizarre argument as because of this situation
> 	1) the code is duplicated between the initramfs and the real disk

I don't really get what you mean.
But binary duplication isn't the issue, source-code duplication is.
I'd count an initramfs to the binary category. It is "compiled" more or 
less literaly.

> 	2) the initramfs has to be rebuild each time a new kernel is done

Only when you use kernel-modules, otherwise you should be fine for "some 
time".

> 	3) The tmpdevfs is also a dupplicate somehow

No.

devtmpfs uses tmpfs or ramfs as backing-store. And it doesn't really 
duplicate udev either, as it only does the bare minimum needed to get 
the computer to the point where udev can do the rest. Like when you have 
a root filesystem with no /dev at all.
(Which was kind of an chicken & egg-problem before.)





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

Re: Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

[Eric Valette]

On 27/08/2010 18:37, Matthias Schniedermeyer wrote:

> I don't really get what you mean.
> But binary duplication isn't the issue, source-code duplication is.
> I'd count an initramfs to the binary category. It is "compiled" more or
> less literaly.

binary duplication is a waste of space (SSD are'nt cheap) and time. 
Plus, you have a real duplication for the fs-search in grub/lilo/add 
your favorite evolved boot loader there.

>> 	3) The tmpdevfs is also a dupplicate somehow
>
> No.
>
> devtmpfs uses tmpfs or ramfs as backing-store. And it doesn't really
> duplicate udev either, as it only does the bare minimum needed to get
> the computer to the point where udev can do the rest. Like when you have
> a root filesystem with no /dev at all.

I know. But It could do just a bit more find creating the 
/dev/disk/by-uuid/foo where foo is the one given ib root=UUID=foo


--eric

Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

[Eric Valette]

Hi,

I just bought an new external disk enclosure with e-sata/USB2 connector 
to replace an old USB2 only external disk enclosure.

My internal drive is a small SSD because I use the small factor PC as a 
home theater and do want silence and fast boot. I build my own kernel to 
put only what I need in and also boot somehow faster.

I use grub2 (up to date) as a loader. As soon as I power on the external 
sata disk, the system does not boot because hardware designer add the 
great idea to put the internal sata connector on ata3 whereas the 
external e-sata is wired on ata2.

consequence is that root file system is on sda1 when no external drive 
is connected and sdb1 when the external drive is connected.

As my grub setup was having a root=/dev/sda1 command line parameter and 
it was advertised everywhere that root=UUID=xxxxx was now supported, I 
changed the line to discover that this only work if an initramfs was 
loaded because support is done entirely in used space! Reading 
init/do_mounts.c made it very clear.

I find it extremely curious to have to add an initramfs to support 
dynamic drive identification, especially when the BYID value is 
displayed during boot message.

The boot loader cannot do a better job than the kernel and its life may 
be even worse as bios value for the same disk may change according to 
boot disk priorities.

Any hint comment? Any other way to avoid using a ramdisk? Please CC me 
as I'm not subscribed.

-- eric

Re: Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

[Florian Mickler]

On Mon, 23 Aug 2010 16:10:13 +0200
Eric Valette <Eric.Valette@Free.fr> wrote:

> Hi,
> 
> I just bought an new external disk enclosure with e-sata/USB2 connector 
> to replace an old USB2 only external disk enclosure.
> 
> My internal drive is a small SSD because I use the small factor PC as a 
> home theater and do want silence and fast boot. I build my own kernel to 
> put only what I need in and also boot somehow faster.
> 
> I use grub2 (up to date) as a loader. As soon as I power on the external 
> sata disk, the system does not boot because hardware designer add the 
> great idea to put the internal sata connector on ata3 whereas the 
> external e-sata is wired on ata2.
> 
> consequence is that root file system is on sda1 when no external drive 
> is connected and sdb1 when the external drive is connected.
> 
> As my grub setup was having a root=/dev/sda1 command line parameter and 
> it was advertised everywhere that root=UUID=xxxxx was now supported, I 
> changed the line to discover that this only work if an initramfs was 
> loaded because support is done entirely in used space! Reading 
> init/do_mounts.c made it very clear.
> 
> I find it extremely curious to have to add an initramfs to support 
> dynamic drive identification, especially when the BYID value is 
> displayed during boot message.
> 
> The boot loader cannot do a better job than the kernel and its life may 
> be even worse as bios value for the same disk may change according to 
> boot disk priorities.
> 
> Any hint comment? Any other way to avoid using a ramdisk? Please CC me 
> as I'm not subscribed.
> 
> -- eric
> 
> 
> 


I'm not exactly shure, but isn't the search command in grub2 what you
want?

http://forums.linuxmint.com/viewtopic.php?f=46&t=38599

You can let grub2 figure out which drive is which and pass the right
devices to the kernel...

Re: Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

[H. Peter Anvin]

On 08/23/2010 01:05 PM, Florian Mickler wrote:
> 
> I'm not exactly shure, but isn't the search command in grub2 what you
> want?
> 
> http://forums.linuxmint.com/viewtopic.php?f=46&t=38599
> 
> You can let grub2 figure out which drive is which and pass the right
> devices to the kernel...
> 

Fantastic!   So when grub2's idea of device naming doesn't match what
the kernel ends up with, it will cause all kinds of odd failures.

This really needs to be done by Linux.  As far as doing this stuff in
the kernel, one of the major motivations for klibc was to be able to do
this kind of stuff without having to have people write kernel code, but
klibc integrated into the kernel build didn't get enough support to
actually make it in -- it still exists and is maintained as a standalone
system, and it's possible to write a very small initramfs with it.

	-hpa

Re: Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

[Florian Mickler]

On Mon, 23 Aug 2010 13:11:15 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> On 08/23/2010 01:05 PM, Florian Mickler wrote:
> > 
> > I'm not exactly shure, but isn't the search command in grub2 what you
> > want?
> > 
> > http://forums.linuxmint.com/viewtopic.php?f=46&t=38599
> > 
> > You can let grub2 figure out which drive is which and pass the right
> > devices to the kernel...
> > 
> 
> Fantastic!   So when grub2's idea of device naming doesn't match what
> the kernel ends up with, it will cause all kinds of odd failures.
> 
> This really needs to be done by Linux.  As far as doing this stuff in
> the kernel, one of the major motivations for klibc was to be able to do
> this kind of stuff without having to have people write kernel code, but
> klibc integrated into the kernel build didn't get enough support to
> actually make it in -- it still exists and is maintained as a standalone
> system, and it's possible to write a very small initramfs with it.
> 
> 	-hpa

hehe, indeed. I didn't think it through :) 

Re: Please add generic support for root=UUID= at kernel parameter command line (LABEL, BYID maybe also)

[Eric Valette]

On 23/08/2010 22:05, Florian Mickler wrote:

> I'm not exactly shure, but isn't the search command in grub2 what you
> want?
>
> http://forums.linuxmint.com/viewtopic.php?f=46&t=38599
>
> You can let grub2 figure out which drive is which and pass the right
> devices to the kernel...
>

It helps finding the grub root partition, not how linux kernel will name 
it. It replaces the classical root=(hd0,0) command. BTW grubs always 
works and find the /boot/grub partition and load linux but linux does 
not manage to find init.

But thanks for helping anyway.

--eric