[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#357538: further analysis points to possible failure to pass root= parameter

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

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!"

	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

	# 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
Something must have hit the keyboard; ignore it.


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

Reply to: