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

Re: [PATCH] mkinitrd rescue mode - now crypto


	Time for a variation on a theme.  I'm also in the middle of doing some
similar type stuff in initrd.  Modified the subject to reflect a change
in direction

On Mon, 2005-06-06 at 14:06 -0400, Peter Jones wrote:
> On Thu, 2005-06-02 at 13:06 -0400, Jeffrey Layton wrote:
> > This does increase the memory profile of the initramfs by about 1.5M.
> > Isn't that memory freed after the switchroot occurs, though?

> It isn't currently freed.  There's a plan for how to free it within the
> switchroot command, but I haven't had the time to implement it.

	Ouch!  I thought the kernel was suppose to be doing this already.
Wasn't that what the big discussion was on the kernel mailing list about
"Double free of initramfs" back in March?  So, if we add stuff to the
initrd, we just have to delete it all before calling switchroot?  Not
freeing that memory seems like a bug.

	I'm using this for a more sophisticated scenario.  Basically, I'm using
it to run with my laptop hard drives totally encrypted, including the
root and swap partitions, through dm_crypt and booted from a USB
pendrive/key/flash/whatever (possibly CD-Rom as well).  To accomplish
that, I needed to add cryptsetup and busybox to the initrd (plus any
modules for USB for any USB devices like USB keyboards and SCSI if I
want to mount the flash while in initrd space).  Busybox needed to be
rebuilt with a few different options, like adding losetup (so I can
decrypt a luks encrypted keyblob image) and switching from msh to ash
(msh is borked - gag).  Then just add a single line hook into the "init"
nash script to run "crytpsetup.sh" which was also added into bin (and
cryptsetup.sh has an optional drop to shell for doing maintenance on the
crypto from initrd).

	Only reason I seem to need nash at all, right now, is for the
"makerootdev" command and the "switchroot" command (busybox has
pivot_root, but not switchroot, and I can ignore the "setquiet" noise).
With those two functions, I could dump nash entirely and operate totally
from busybox with a minimal increase in size.  Which raises some other
questions regarding busybox...

	Originally, I was using the static busybox from the Adios bootable CD
flavor of FC (based on FC3).  That was built with ash and wasn't much
bigger than nash (about 10K larger).  If I could eliminate nash, the
size difference would have been relatively small.  But, busybox doesn't
have that "makerootdev" or mount by LABEL= (AFAICT) or switchroot, so
it's an add on, rather that a replace.  Sigh...  Then I tried switching
to the stock FC version of busybox.  Static version, built from the
SRPM, is over twice as large as the Adios version (gag!)...  I yet
haven't gone through it, option by option, to figure out just WHAT is
bloating busybox like that.  But I had to modify busybox anyways, since
neither version included losetup, which I definitely needed.

	Busybox in Fedora Core seems to be built with msh and not ash.  But
I've found several normal "sh" type things that work just fine under
"ash" but just flat out don't work properly in "msh".


	cat /proc/partitions | while read major minor blocks name


	while read major minor blocks name
	done < /proc/partitions

	Under msh, the first iteration in the loop works and I get the correct
values.  All subsequent iterations return null in all the variables
although the number of iterations is correct.  That's not the only
instance of normal "sh" type structures that fail on msh but work with
ash.  I also had some troubles with some odd VARBLE=`command` type
substitutions that didn't seem to do the right thing.  So it seems like
msh is buggy.  So I rebuilt the FC flavor of busybox to dump msh and add
ash and add ash as sh.  And the scripts then work once again.  And
busybox got smaller (a bit smaller).  Ok...  So msh is busted for
certain legitimate sh constructs and it's fatter than ash.  Why is msh
being used instead of ash?  What does msh do (I can't find ANY doco on
msh) that ash doesn't?  There must be something good and useful about it
or why would it be there?

	Right now, I've got a script that runs the stock "mkinitrd" called to
add the appropriate modules to be loaded.  It then unpacks the resulting
initrd archive and adds cryptsetup (which is already static) and the
static busybox, plus my files and finally hooks init to call the crypto
script.  Then I repack the initrd file and it's done.  I'd definitely
like it to be smaller and I'm definitely going to add some rm's in there
to get rid of anything other than nash in bin before running
"switchroot" but it's now working rock solid.  Any idea when the
switchroot thing will be fixed to completely free up the initramfs

> > If you update to a new kernel, and that kernel isn't detecting your 
> > drives correctly, then that is very difficult to troubleshoot once you
> > boot to a rescue kernel.

> How often is that a real problem?  I don't think I've seen any
> significant number of bug reports on this in recent memory.

	In my case, with encrypting the drives, I'm into this area every time
my laptop boots.  I travel internationally for speaking engagements and
we consider this an important feature.  I'm also working up a talk for
some Linux shows (maybe LinuxWorld where I regularly speak) and groups
on doing this.  There seems to be some significant interest, judging
from comments I've heard back from the Atlanta Linux Enthusiasts group,
especially after some of the headlines about stolen laptops and lost
hard drives resulting in confidential information (like customer and
client data) leaking out.  :-)

	I'll be making the various scripts publicly available once I get past a
few cleanups and write some maintenance scripts and get past my first
talk on the subject (July 14 in Atlanta as things stand right now).

> -- 
>         Peter

 Michael H. Warfield    |  (770) 985-6132   |  mhw WittsEnd com  
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Attachment: signature.asc
Description: This is a digitally signed message part

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