Bugzilla Bug 182818

I have a gentoo based hosted server with serial access.  I find it very useful
to pop an unpacked minimal boot CD on a spare partition in order to use it to
rescue the system if I damage it.

Right now there is a small "bug" in the standard initrd distributed with
2007.0.  The chain of events is as follows:

- It only tests for install media in /dev/hdX and /dev/sdX (ok and some USB
drives, etc)
- Doesn't test any /dev/mdX or /dev/evms/xx partitions
- Can't work around it using cdroot=/dev/mdX because this forces the script to
deliberately for the partition to mount as iso9660 (which obviously fails
unless it is a real CD)

I fixed this by making a small change to the initrc.scripts file.  Changes are
documented at the bottom of here:
http://gentoo-wiki.com/HOWTO_LiveCD_on_disk

Patch is as follows:
--- initrd.scripts.old      2007-06-21 20:25:25.000000000 +0100
+++ initrd/etc/initrd.scripts   2007-06-21 20:55:44.000000000 +0100
@@ -77,7 +77,7 @@
                                        mount -r -t auto ${x}
${NEW_ROOT}/mnt/cdrom \
                                                > /dev/null 2>&1
                                else
-                                       mount -r -t iso9660 ${x}
${NEW_ROOT}/mnt/cdrom \
+                                       mount -r -t auto ${x}
${NEW_ROOT}/mnt/cdrom \
                                                > /dev/null 2>&1
                                fi
                                if [ "$?" = '0' ]
@@ -362,6 +362,8 @@
        DEVICES="$DEVICES /dev/ubd* /dev/ubd/*"
        # iSeries devices
        DEVICES="$DEVICES /dev/iseries/vcd*"
+       # MD and EVMS devices (eg Booting from HD partition)
+       DEVICES="$DEVICES /dev/evms/md/md* /dev/evms/sd* /dev/evms/hd*
/dev/md*"
        # The device was specified on the command line.  Shold we even be doing
a
        # scan at this point?  I think not.
        [ -n "${CDROOT_DEV}" ] && DEVICES="$DEVICES ${CDROOT_DEV}"
----------

I think its pretty self explanatory even if it gets slightly mangled pasting
here.


Any comments on this?  Any reason not to incorporate this in future
genkernel/livecd initrds?

Having made either of these small changes I can then boot my server in rescue
mode and even access any MD, LVM or EVMS drives.  


Reproducible: Always

Steps to Reproduce:

Yes, we cannot use -t auto everywhere, for a reason.  It causes lockups under
some  circumstances which are much more common than someone trying to boot the
LiveCD media on a non-CD, which isn't supported by Release Engineering, at all.
 Your solution is therefore mostly correct, btu we'll need to figure out
something else to do than setting auto on the second mount.  Needless to say,
it isn't a "bug" so much as "done on purpose to keep systems from locking up at
boot which is much less desirable than not being able to boot the minimal image
from a partition"... ;]

I hear what you are saying, but notice that it *only* stops using -t auto *if*
you specifically name a device to use.  For normal boots its still using the -t
auto...

I kind of tackled the issue on two fronts here.  The second part of the patch
simply adds a number of less common locations to search for partitions to boot
- they are also right at the end of the list of options so we should find the
USB sticks, etc right at the beginning anyway.  

Perhaps some heuristics are in order here?  Or perhaps try each mount twice,
once with -t auto and later with iso9660? (or vice versa)

Is the minimal CD different to the normal cd then? Having a CD which can be
used for rescue boots is quite a common use for gentoo livecds.  Would be nice
to try and support some more corner cases?

Can you add REAL_ROOT to the start of the device search list in
initrd.scripts:bootstrapCD?

This would allow the normal search sequence to be overridden with a known
intended location.

We could do that, but we'd also still need -t auto. I was thinking about this,
and perhaps we can just add an extra kernel commandline option (maybe
domountauto) that switches the iso9660 to auto for the small number of cases
where it's needed. Then, you could just add 'cdroot=/dev/md2 domountauto' to
the kernel commandline to get the intended effect. Does this work for everyone?

+1 from me.

I've just committed a variation on my idea to SVN. There is a new kernel
commandline parameter supported by the linuxrc: cdroot_type=foo. This defaults
to iso9660 but can be overriden with something like "cdroot_type=auto",
"cdroot_type=vfat", or even "cdroot_type=vfat,udf,ext2,foo,bar". With the next
gk release, you'll be able to use "cdroot=/dev/evms/foo cdroot_type=auto" to
accomplish what you want to do.

From the way it is currently in x86, the -t iso9660 is only invoked
specifically if the 'cdroot=/dev/xxx' form is used, giving rise to the
CDROOT_DEV variable holding a value.  It looks like most of the device
searching functionality is operating on the basis of unintended consequences.

If CDROOT_DEV contains a value this gets appended as the last of the list of
potential CD bootstrap devices.    When each of the other devices is tried, it
is with -t iso9660 which is likely to fail, of course.  Finally the loop
reaches the intended device (by virtue of it being appended to the list in
bootstrapCD).  There is a comment in the code that suggests that this bit of
code has been mangled.  It says:

# The device was specified on the command line.  Shold we even be doing a
# scan at this point?  I think not.

The code then goes on to append the value of CDROOT_DEV to DEVICES whereas the
logic of the preceding comment is that DEVICES should just be set to contain
the single value specified.

Is it really the intended behaviour for the script to try a whole bunch of
devices that have not been specified prior to the one that has been specified
in a manner which assures lots and lots of failed attempts at mounting
non-iso9660 partitions as iso9660 partitions?

I've managed to get a workaround with the simplest of patches adding REAL_ROOT
to the start of the device search list.  This sidesteps the existing (weird)
CDROOT behaviour, without me having to delve into the reasons for it being the
way it is.

You're mostly right. The -t iso9660 comes into play when you boot with
'cdroot', not 'cdroot=foo'. In most cases, the scanning makes sense. However,
in the case of 'cdroot=foo', scanning does not make sense, as the comment you
quoted suggests. I've made the following change in SVN:

- # The device was specified on the command line.  Shold we even be doing a
- # scan at this point?  I think not.
- [ -n "${CDROOT_DEV}" ] && DEVICES="$DEVICES ${CDROOT_DEV}"
+ # The device was specified on the command line, so there's no need to scan
+ # a bunch of extra devices
+ [ -n "${CDROOT_DEV}" ] && DEVICES="${CDROOT_DEV}"

Created an attachment (id=139479) [details]
Use REAL_ROOT to select the block device containing the livecd identifier and
loop file for CDROOT boot from disk or flash media

I have attached the aforementioned simple patch.

That fix of the search behaviour looks like what was originally intended by the
writer of the comment.

cdroot=foo is the only case which invokes -t iso9660

cdroot on its own invokes -t auto

This is absolutely fine with me and messing with this would break pretty much
every embedded type build.  By just adding any real_root=foo value at the start
of the cdroot search string, you can get the behaviour that Ed was seeking in
the first place.

--- generic/initrd.scripts      2007-12-28 03:34:25.000000000 +0000
+++ generic/initrd.scripts      2007-12-28 03:34:04.000000000 +0000
@@ -381,7 +381,7 @@
 bootstrapCD() {
        # Locate the cdrom device with our media on it.
        # CDROM DEVICES
-       DEVICES="/dev/cdroms/* /dev/ide/cd/* /dev/sr*"
+       DEVICES="${REAL_ROOT} /dev/cdroms/* /dev/ide/cd/* /dev/sr*"
        # USB Keychain/Storage
        DEVICES="$DEVICES /dev/sd*"
        # IDE devices

Your patch doesn't really make sense. In order to use your patch, you'd have to
use "cdroot real_root=/dev/foo/bar" instead of just "cdroot=/dev/foo/bar". It's
also "more" of an abuse of an existing parameter than using cdroot=.

I still don't understand where you're coming from. The only time the -t iso9660
thing is used is in findmediamount() (which was findcdmount() in previous
versions), which is only called from bootstrapCD(), which is only called when
${CDROOT} = '1', which is true with either "cdroot" OR "cdroot=foo".

Okay, I lied. What I described is the current behavior in SVN, but I see what
you're talking about going back a few revisions. However, I'm not sure this was
intended behavior, because it really doesn't make sense.

With current SVN, if the old -t auto behavior is needed, you can still get it
with 'cdroot_type=auto'.

Yes.  I was commenting on the x86 stable branch and 2007.0 livecd as specified
by the originator.  Agreed that it doesn't make sense.

I'm a bit of an amateur and this bug-sleuthing thing, so I'm not geared up on
SVN at all.

This area of functionality has been shifting around a fair bit and is for all
intents undocumented.  From the hint you have given about what is coming with
current SVN versions, this is all set to change again.  At least this time I
will have a heads up.  This one has kept me up until 4 in the morning.

In genkernel-3.4.9_pre6 it is still current usage to have "cdroot
real_root=/dev/nfs" for PXE booting of livecd images, so "cdroot
real_root=/dev/foo" for hard disk hosted images has felt consistent.

Well, for the most part, we don't care about *anything* in the portage tree, as
far as code is concerned.  We're only interested in SVN.  If there's a bug in
something in the tree, check SVN.  If the bug still exists, file a bug report
(or comment on an existing one, if it's already open)... If the bug doesn't
exist anymore, it'll be "automagically" fixed in the next genkernel version. 
Basically, SVN is always "ahead" of what's in the tree and what's in the tree
is static and unchanging.  Once a tarball has been rolled, that version is
"done with" and we're on to the next one.  As such, we don't look back at
things like "2007.0" as that is old software (in our eyes) and we look to the
future.  When we look back at older releases, it's always to make sure we've
resolved bugs or made things better.  We almost *never* look at the actual code
and try to base anything on it, as it is likely SVN has changed that code
already and we'd waste a lot of time (as you're starting to notice).

Thanks for all the bug-hunting.  It *really* is appreciated.  Don't take any of
the above as anything more than informational.  That was my only intention.

This should be resolved in genkernel 3.4.9, which will be hitting the tree
shortly.  If this is still an issue with that version, please REOPEN this bug
(or comment, if you cannot REOPEN it).