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



--

[ message continues ]

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

Hi Eric,


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
--

[ message continues ]

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


--

[ message continues ]

Hi Eric,




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
--

[ message continues ]

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
--

[ message continues ]

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 

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

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.

--

[ message continues ]

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 

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




--

[ message continues ]