Bug#357538: immediate cause of problem diagnosed
On Sun, 2006-03-19 at 19:35 -0800, Ross Boylan wrote:
> I've looked at the initramfs image and tried to trace through
> execution by inspection (I'm not at the machine). I may be off base,
> but here's what I noticed. In short, it looks as if the root
> parameter of /dev/evms/newroot in lilo.conf is not making it to the
> scripts that run off the ramdisk.
>
I've verified this at run (or boot) time. /proc/cmdline has "root=fe06"
not the "root=/dev/evms/newroot" from lilo.conf. As a result, the evms
scripts don't think evms is in play, and never run evms_activate. lilo
has resolved the partition name to a BIOS address (I guess); that's fine
for lilo, but not great for others.
In general, I don't think there's any guarantee that the root= option
will resolve to anything at the time lilo is run; it might only be
visible after the evms_activate in the new environment.
parse_numeric() has code that deals with this case, but it doesn't solve
the evms problem.
I'm less sure what the solution is, or even who is misbehaving. It
looks like a lilo problem. Possible solutions include
1. don't use lilo
2. use lilo but pass explicit kernel options with append=. I'm not sure
if that would work.
3. change lilo to preserve the value given to it in the root= parameter,
at least with initrd.
4. work around this in initramfs-tools, or maybe in evms.
5. other.
Anyone who is confident should feel free to reassign or reclassify this
bug. My next step will probably be to switch to grub.
Again, these issues appear to be evms-specific. They may affect other
ramdisk generators, however.
P.S. I had a lot of unsuccessful attempts to build my own initrd to
diagnose the problem, and ultimately hacked /usr/share/initramfs-tools/
to get the value of /proc/cmdline output. Then I ran update-initramfs.
Any pointers on this would be great.
Reply to: