Ok... 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". Example: cat /proc/partitions | while read major minor blocks name do : done and while read major minor blocks name do : 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 thing? > > 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 > Mike -- 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!
Description: This is a digitally signed message part