Re: [gentoo-catalyst] How is initrd built?

[Paul Smith]

%% Chris Gianelloni <wolf31o2@g.o> writes:

  cg> Actually, what rocket means in that catalyst has no built-in
  cg> support for unionfs.  To get unionfs, you need to use gk_mainargs
  cg> (or gk_kernargs) --unionfs.

Oh, OK.  Yeah, I already found this in the new genkernel, and did do it
in livecd.conf (I thought I mentioned that in one of my mails).

  cg> You will also probably want livecd/bootargs: unionfs...  unless
  cg> you know the device you want, in which case you can do
  cg> livecd/bootargs: unionfs=/dev/sda1 (or whatever).

I'm actually using GNAP to create the ISO, so I override the kernel boot
params there and don't need this.

  cg> Yeah, livecd/bootargs is new in the _pre series.  I even documented it
  cg> in the template spec files... ;]

That's a good enhancement though! :-).

  >> 0) mkdir -p /newroot
  >> 
  >> 1) Create a tmpfs at /memory
  >> 
  >> 2) Create a unionfs at /union, where the only item in the union is
  >> /memory (mounted RW)
  >> 
  >> 3) Init /newroot (make directories, copy over /dev/null and /dev/console)
  >> 
  >> 4) Find the cdrom and mount it as /newroot/mnt/cdrom
  >> 
  >> 5) Mount the squashfs as /newroot/mnt/livecd (read-only)
  >> 
  >> 6) Add /newroot/mnt/livecd to the unionfs after the tmpfs (/memory)
  >> 
  >> 7) Create /union/proc and /union/sys
  >> 
  >> 8) Pivot_root to make /union the new /.
  >> 
  >> 9) Clean up the old root (in /tmp/.initrd)
  >> 
  >> 10) chroot . 'exec /sbin/init' (basically).

Hold on a second...  I just discovered something that I don't understand
at all.  The behavior above, in particular steps #8 & 9, is not actually
what happens.

If you look in the linuxrc you'll see it has an option to be invoked one
of two ways: where $0 is "/init", and where $0 is "/linuxrc".  Depending
on which one is used the script exhibits different behavior... very
different, in some cases.  Like, the "/init" branch doesn't use
pivot_root at all; it just does a chroot.  The whole end cleanup is very
different.

I've been thinking that the livecd is booting with $0 == "/linuxrc", but
in fact it's not: $0 == "/init".

Can someone give me an idea of where this ($0) is set up (it's not init=
on the boot line because my boot line says init=/linuxrc--but it must be
the kernel somehow because it execs the shell so it would set argv[0]),
and what the purpose is between the different behaviors, and why you'd
choose one over the other?

  cg> AFIAK, /mnt/cdrom would need to be done before the pivot_root,
  cg> too.  So you can't move that to later.

True, but you could do one of two things:

 a) Mount it in /unionfs/mnt/cdrom in the first place, not in
    /newroot/mnt/cdrom.  By the time we mount the cdrom we already have
    a /union filesystem created and working.

OR

 b) Try to "mount --move" it from /newroot to /union once the unionfs is
    set up.


I looked at (a) and while I think it would work, it would involve a lot
of changes.  Although the value of CHROOT is set to $NEW_ROOT (or $UNION,
if we're using unionfs) early in the script, almost all the commands
after that continue to use $NEW_ROOT explicitly rather than $CHROOT.
Sometimes this probably makes sense (such as mounting livecd) but in
other cases it doesn't, so much (such as in mounting cdrom).  I think
these variables need to be rationalized somewhat, so $CHROOT is used
instead of $NEW_ROOT where appropriate.

There are other things that probably don't hurt, but aren't required
either.  For example, even in the unionfs case the code still
initializes $NEW_ROOT with a bunch of stuff that is never needed, and
then is just cleaned up again afterwards.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@××××××.com>           HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
-- 
gentoo-catalyst@g.o mailing list