boot device order troubleshooting without an initrd
Jan Kundrát
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 technical argument about why.
Anyway, I'm looking for any input. I'd much appreciate if you could Cc
me on replies, as I'm not subscribed to the list.
Have fun,
-jkt
[1]
http://www.kernel.org/pub/linux/kernel/people/gregkh/lkn/lkn_pdf/ch09.pdf
--
cd /local/pub && more beer > /dev/mouth
Arjan van de Ven
Jan Kundrát <j...@gentoo.org> wrote:
> 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
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Mike Waychison
> On Mon, 19 Apr 2010 00:29:54 +0200
> Jan Kundrát<j...@gentoo.org> wrote:
>
>> 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
>
>
> 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...
>
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=5b5b6f5192af5c3fa30fe605e8842c62421adbd4
Jan Kundrát
> 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.
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
the computer case, completely inaccessible to the user at runtime.
> 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...
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
skit...@apache.org
[Warning: kernel newbie speaking!]
Without an initrd, the options for the root= kernel parameters are only those supported in init/do_mount.c:
1. root=MAJOR:MINOR
2. root=integer where integer is MAJOR<<n + minor
3 root=/dev/xxx
(well, apart fron "mtd" and "ubi" options).
Unfortunately, all of these options are sensitive to hardware changes, ie device enumeration order. So I
think that right now the answer to your question is: no, you can't get what you want without an initrd.
And I doubt that changes to the linux device-enumeration code "to be consistent with the BIOS" would be accepted.
Perhaps one thing that could be reasonably easily supported is:
root=gptguid
where gptguid is the id of a partition on a GPT-formatted disk. With msdos partition tables, partitions do not
have unique identifiers; Windows does puts a 32-bit "windows nt disk signature" field in the MBR, which could
possibly be used but it isn't really standard. However the GPT format (part of the EFI standard) mandates a
unique GUID be assigned to every partition which sounds like an excellent way to specify the location of the
root fs.
I *think* that it would be a matter of enhancing the "struct hd_struct" held by "struct gendisk" to store this
info when scanning a GPT partition table, then enhancing do_mount.c to check the root param against these values.
See: http://en.wikipedia.org/wiki/GUID_Partition_Table
Thoughts?
If this sounds sane to people, I would be keen to have a go at implementing this. Are there any specific
people or lists that should be cc'd when discussing this?
Regards, Simon
Robert Hancock
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.
Pavel Machek
> As it happens, I've been looking into this issue recently.
> [Warning: kernel newbie speaking!]
>
> Without an initrd, the options for the root= kernel parameters are only those supported in init/do_mount.c:
> 1. root=MAJOR:MINOR
> 2. root=integer where integer is MAJOR<<n + minor
> 3 root=/dev/xxx
> (well, apart fron "mtd" and "ubi" options).
And nfs?
> Unfortunately, all of these options are sensitive to hardware changes, ie device enumeration order. So I
> think that right now the answer to your question is: no, you can't get what you want without an initrd.
>
> And I doubt that changes to the linux device-enumeration code "to be consistent with the BIOS" would be accepted.
>
If it is clean enough... why not?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html