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.
1. scripts/local-top/lvm looks as if it only tries to execute vgchange if the root device is /dev/mapper/dev/root (or /dev/root), which it should not be. But something is trying to execute vgchange, and it appears to be this script from the logs. The system that is not working uses lilo; the one that is working uses grub. scripts/functions includes parse_numeric(); in some cases this sets ROOT=/dev/root and mknod /dev/root. However, either an empty ROOT or /* should skip this. 2. scripts/local-top/md accesses all the drives through their traditional names, meaning that evms will be unable to access the drives after the md script runs. The evms script that precedes it should run evms_activate if root is /dev/evms/xxxx. Background info: in 2.6 kernels only evms or the kernel can own a device; whoever gets there first wins. There is a patch to disable this feature, reverting to the less safe 2.4 behavior. I have not applied that patch. 3. The higher-level script/local has this ----------------------------- # Get the root filesystem type while [ ! -e "${ROOT}" ]; do panic "ALERT! ${ROOT} does not exist. Dropping to a shell!" done eval $(fstype < ${ROOT}) [ "$quiet" != "y" ] && log_begin_msg "Running /scripts/local-premount" run_scripts /scripts/local-premount [ "$quiet" != "y" ] && log_end_msg if [ ${readonly} = y ]; then roflag=-r else roflag=-w fi # FIXME This has no error checking modprobe -q ${FSTYPE} # FIXME This has no error checking # Mount root mount ${roflag} -t ${FSTYPE} ${ROOT} ${rootmnt} ---------------------------------------------- The log doesn't have (at least that I noted) the ALERT! message, suggesting that there is a value in $ROOT and it points to something on the file system. But the subsequent errors are consistent with it being /dev/root which can't be opened. If fstype failes, the FSTYPE is not set and the modprobe line becomes "modprobe -q", which produces the error message shown on the log. The mount wouldn't work. The FIXME's indicate the lack of error checking at those two steps. In short, if /dev/root (or /dev/mapper/dev/root) is getting passed in as ROOT, it would explain the logs. But it shouldn't be getting passed in. conf/conf.d/root sets ROOT= but init's subsequent part of /proc/cmdline looks as if it should pull in the correct value. Finally, a couple clarifications of previous post. The log in my initial post includes a line consisting only of ,pimt" Something must have hit the keyboard; ignore it. Second, On Fri, Mar 17, 2006 at 07:40:58PM -0800, Ross Boylan wrote: > Having looked more closely at some of the internals of the package, I > want to highlight one fact: the device with the new root is > /dev/evms/newroot, and it could be pretty much anything. I mean /dev/evms/anything. I'm not sure if non-/dev/evms entries are possible. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]