Hi folks,
I'm looking for a way to pass a correct "root" parameter to the kernel
from the bootloader, independently on the number of attached disks. My
machine (VIA EPIA SN-1800) has four SATA ports and one CF card slot. The
CF slot is visible as an IDE device. The BIOS is configured for booting
from the CF card, and Grub2 has absolutely no problems booting the kernel.

The problem I'm facing is that if there are no SATA disks attached, my
CF card gets called /dev/sda, while if I attach two SATA drives, the CF
card gets called /dev/sdc. I can solve that "in userspace" without much
problem thanks to udev's names like
/dev/disk/by-id/scsi-SATA_ELITE_PRO_CF_..., but I have no idea about how
to pass the correct "root" argument to the kernel. If I use
"root=/dev/sda1", kernel will boot if and only if I don't have any SATA
devices attached; on the other hand, having two SATA drives attached
requires "root=/dev/sdc1". I've tried to use the by-id naming, but it is
apparently provided by udev much later in the "boot process", and the
document by gregkh [1] doesn't mention it, either.

I have disabled modules, and don't use initrd. Such a setup has worked
for me for a few years. Not having modules enabled makes me feel
"safer", and I have not ever needed an initrd, so far. If I was using
initrd, I'd probably be able to use the "root=LABEL=foo" stuff.

Relevant part of `lspci`:

00:0f.0 SATA controller: VIA Technologies, Inc. SATA RAID Controller
(rev 20)
00:0f.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 07)

I'm attaching full dmesg, as the output seems to be interleaved from
more drivers, and I'm afraid I'd skip something if I tried to include
only relevant parts. The kernel I'm using is 2.6.32-gentoo-r1.

What I'm looking for is an advice if it's possible to tell kernel to
"use the BIOS-provided HDD ordering". I suspect I'm likely going to be
told "you are supposed to use initrd"; if that is the case, I'd love to
see a ...
[ message continues ]

On Mon, 19 Apr 2010 00:29:54 +0200


so the problem is that the boot order you want is pretty much opposite
from what "normal" people want.
AHCI sata before CF slots is pretty much the right thing and what most
people will use.... most people will have their OS on AHCI SATA, and
occasionally stick in some photo card or whatever.... and they'd ask
the flipside question basically.


We could have pretty evil things in the kernel, so that we'd deal with
multiple root= lines in the kernel, one by one trying them until one
sticks. Right now we don't.... but if you make a clean enough patch
it might even pass the review here...


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--

[ message continues ]

Multiple root devices here may help..  I recently added support for 
enumerating multiple root devices to kinit in klibc to work around some 
configuration issues on our servers.

http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=5b5b6f5192af5c3fa30fe605e8842...
--

[ message continues ]

On this particular motherboard, the CF slot is soldered to the bottom
side of the PCB, so it is normally situated between the motherboard and

If the ordering stays the same and such patch existed, I should probably
use something like
"root=/dev/sdf1,/dev/sde1,/dev/sdd1,/dev/sdc1,/dev/sdb1,/dev/sda1". Now,
 I'd guess this would break as soon as I attempt to boot with a USB
flash device present (I'm assuming it will be enumerated after the CF
card, right?).

So, in short, what I'd love to see is a special device alias which would
mean the "BIOS-provided boot device". Would such an approach be
reasonable? Is it possible at all?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[ message continues ]

The BIOS EDD information may provide information that would be useful 
for this. However, it seems not all systems implement it, and it's also 
not trivial to map the information it provides all the way back to 
figure out what actual device node to use. It gives you something like 
"BIOS INT13 device 0x80, which was presumably the boot device, is a SATA 
drive on port blah of PCI device blah", and then you have to dig up 
which device instance that is, look up the port it gives you, hoping the 
driver's port numbering is the same as whatever the BIOS used, then 
figure out what disk device that is, etc. And the whole thing is 
assuming the BIOS actually gave you correct information, which is far 
from certain.

It's possible to do all that, but that sort of logic likely doesn't 
really belong in the kernel, which means - you guessed it - an initrd. 
And in that case it's likely easier to just use mounting by label or 
UUID and avoid all the complexity.
--

[ message continues ]