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
On Mon, 23 Aug 2010 16:10:13 +0200
Eric Valette <[email protected]> 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...
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
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
On Mon, 23 Aug 2010 13:11:15 -0700
"H. Peter Anvin" <[email protected]> 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 :)