lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C728145.4030808@Free.fr>
Date:	Mon, 23 Aug 2010 16:10:13 +0200
From:	Eric Valette <Eric.Valette@...e.fr>
To:	linux-kernel@...r.kernel.org
Subject: Please add generic support for root=UUID= at kernel parameter command
 line (LABEL, BYID maybe also)

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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ