On 16:01 Thu 07 Jul     , Paul Smith wrote:
> %% 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.
Initramfs's are special as in they eliminate many of the workarounds
that are present in an initrd.  You no longer need to specify init= on
the command line.  In fact the kernel ignores it when an initramfs is
detected.  Also the kernel expects the initial script to be called init.
So genkernel renames the linuxrc file to init inside the initramfs.
Because the script is called init the value of $0 is set to /init.

Initramfs are also different in that they no longer pivot_root and then
chroot.  You can just chroot directly.  The differing code is to handle
this behavior difference.  Ultimately its much simpler than worrying
about the pivot root.

> 
> 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 would lean toward --move if it works, but it will need to be tested.
> 
> 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.

Alot of this unionfs code is an after thought and so it was implemented
in such a way that it was minimally impacting to the normal booting
method.  Overtime I hope to have things cleaned up as we discover issues
and/or convert entirely to this boot method.

> 
> 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.

Again see the above comment about code impact and that will explain why
things are as they are.  

If you find a working solution for you that boots the system with or
without unionfs support please make a patch and we will look to have it
included.

Thanks.
> -- 
> -------------------------------------------------------------------------------
>  Paul D. Smith <psmith@...>           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
> 
>