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