Re: mkinitrd update discussion/survey

I have a couple things that I do, you may like them, you may hate them.
But I like 'em.  They may not be entirely responsive to the questions
asked, but I get the impression you're contemplating booting, and it's
rare that anyone does that.

1)	I keep a busybox and basic tools on my /boot partition (/dev/hda1),
	and boot with root=/dev/hda1 init=/linuxrc.  my linuxrc will (first)
	e2fsck my root partition and then mount it (just seems like the
	right order to me, though most distros seem to disagree).  Also
	allows any kind of raid/encryption/nfs/whatever root to work
	much more easily than I've ever managed with an initrd.  And it
	might be useful just to offer an 'initpart' as a debugging tool,
	and once the bugs are out, make a ramdisk out of it.

2)	Rather than the rather painful sequence described in the kernel
	docs for the pivot root, where one closes fds 0,1,2 etc, and
	basicly takes pains to get devfs unused, I prefer just doing:

	cd /mnt/root
	pivot-root . boot
	mount --move boot/dev  dev
	mount --move boot/proc proc
	mount --move boot/sys  sys


3)	Although I have not yet entirely implemented it, I have always
	wanted to set up (especially my servers at the office) with
	busybox, basic tools, and dropbear sshd.  If e2fsck fails, or
	any of the annoyances that could cause the boot process to hang,
	just bring up a network, fire up an sshd, and start sending mail
	to anybody who might be able to fix it.

	Since I normally keep my boot partition unmounted ( unless I'm in
	the process of rebuilding the kernel or monkeying with grub ) I
	figure I'm pretty safe from e.g. power outages ... since I
	only have to drive if /boot fails.

4)	Also on my presonal 'things to break list':  An encrypted root
	partition, a boot partition as described above, but it always
	brings up sshd -- which allows the admin of the system to ssh
	in and enter the passphrase for the root partition.

	Most of the texts I've read on encrypting root claim that you
	either have to store the passphrase on the disk, or drag your
	meatware across town if the power goes down, but I don't think it's
	so.

	Anyway, once the passphrase is entered and the fix is in, just
	tell the system to continue (in an unspecified and murky mystical
	way ... I guess one could start sshd in debug mode, so it exits
	after each connection) and it completes the boot process.

5)	For what it's worth, I find the following setup elegant ... many
	may disagree:

	/boot/2.6.10/vmlinuz
	/boot/2.6.10/modules/...
	/boot/2.6.10/config
	/boot/2.6.10/System.map

	Symlinks to the normal spots.

6)	One last thing ... I find it annoying to accidentally build
	my kernel into root:/boot/xxx/yyy instead of boot:/xxx/yyy
	because I have failed to mount boot ... so I've gotten in the
	habit of using chattr +i for all my mount points ... that way,
	I get an error instead of confusion.

Well, that's everything I do that's weird when I boot linux.  Except the
stuff with the chicken.  I'm not ready to tell the world about that. :)

On Tue, Jan 25, 2005 at 12:59:28PM +0800, Chris Hamilton wrote:
> Since the current mkinitrd seems to be broken, I have been looking around trying
> to see what other people are doing.  I realize this turns out to have
> importance on more than just a 2.4-2.6 module support update.  So I would like
> input from everyone before I just start randomly working on it.
> 
> Below is my current requirements list, please discuss/comment on these:
> 
> ###############
> Need a kernel installer that also installs correct initrd for the new kernel
>   Should safely store old kernels (space constraints?) move old kernel
>   down in boot options - may make into 2 actions install versioned
>   kernel/initrd, move boot options/links around
> 
> Make an initrd builder that supports
>   mknode, devfs, udev
>   raidtools, mdadm, lvm1&2, evms
>   all filesystems(if modules)
>   optionally uses cramfs not just gzip
>   cdrom, usb, etc. boot support
>   net/nfs root
>   2.4 and 2.6+ kernels
>   gets modules from:
>     static module loading from specified file
>     current running modules from lsmod
>       and their parameters from modules.conf or in a modprobe.conf file
>   not dietlibc, please -maybe klibc
>   a smart linuxrc option ie.
>     strict load order/parameters or a hotplug option
>   selinux
>   crypt filesystems
> 
> 
> ####################
> Below are the notes I made from a survey of the latest released mkinitrd's I
> could find.  Please excuse my ignorance on some issues.  This was done by going
> through the packages file by file and glancing at the code.  Somethings I try
> to interpret, others I just note when there are differences/strangeness.
> 
> Notes:
> Suse (mkinitrd-1.1-7.src.rpm):
>   mkinitramfs-kinit.sh
>     uses udev, very much 2.6 only
>     does static reloading of md devices after device creation
>       relies on udev/hotplug loading correct devices here I think
>       what about recursives?
>     mknodes fb0 and fb1
>     mknodes isdn,ppp,net stuff for nfs root, iscsi
>     (why udev and mknode? - does udev need that?)
>     no root discovery
>     then it does selinux, iscsi, nfs, regular mount/fsck root, init
>     uses /root as / aliases, appears to load init after cleanup
>     it appears to be dynamically loading modules?
> 
>   mkinitramfs-hotplug.sh
>     just loads udev
> 
>   mkinitramfs
>     splash screen loader option
>     runs with static kernel loading only
>     uses different kernel names for some archs
>     it does multiple kernel/initrd - why??
>     does ldd for needed libs
>       they have optimize and reg libs, pick reg for safety
>       what is linux-gat and what other libs does this use?
>     uses /etc/modprobe.conf and modprobe to get dependency list
>     ACPI DSDT table loader
>     doesn't use dietlibc!! and can use dynamic or static insmod
> 
>   mkinitrd.spec
>     just a simple install
> 
>   new-kernel-pkg
>     loads kernel into bootloader
>     only does lilo, grub, zipl
> 
>   installkernel
>     standard
> 
>   mkinitrd
>     code repeats mkinitramfs it appears so check its notes
>     glibc/klibc option for binaries
>     net setup
>     s390, power, x86 compatible
>     linuxrc built inside, is shell based
>     does all filesystem work in linuxrc, supports everything
>     ugly and huge
>     but all output appears to be shell based, need to see
>     no crypt?
> 
>   Nothing in the packages specifies how the other scripts integrate and when
> 
> 
> mandrake (mkinitrd-3.5.18-14mdk.src.rpm):
>   mkinitrd.spec
>     uses dietlibc
>     standardish, everything is patches to mkinitrd
> 
>   uses nash which is an initrd specific shell/busybox w/devfs support
>   uses grubby for grub,  lilo,  elilo,  and yaboot boot loaders
> 
>   uses loadinitrd which has a newt/ncurses prompt for initrd second bootdisks
> 
>   installkernel
>     standard
> 
>   mkinitrd
>     can make scsi,raid,lvm modules optional -- for space
>     preload,builtin,with modules -- preload list before modprobe.conf
>       builtin assumes in monolithicly, with is after modprobe.conf
>     uses /etc/modprobe.conf for module loading
>     can pick initrd fs ie. cramfs and compression
>     nopivot option
>     ACPI DSDT support
>     fstab reader for root
>     some bloat-ie. makes sure ataraid off in 2.6 sata kernels
>     module dependency by modules.dep parsing
>     usb/forceusb mdk specific options
>       ie. loading usb modules to make usb boot devices
>     where is cryptofs support?
>     how does it support space?
> 
>   special net specific mkinitrd package
>     uses ulibc, devfs, nfs, busybox, and udhcp to have
>     etherboot(using mknbi) supported net module initrd
>     includes wlan-ng wireless
> 
> 
> redhat (mkinitrd-4.2.0.3-1.src.rpm):
>   similar setup as mandrake as mandrake copied
> 
>   mkinitrd
>     same cli options as mandrake - minus forceusb (appears no specific usb boot)
>       adds udev support
>     s390 support
>     crypto loop support?
>     how does it support spacr?
> 
>   grubby in redhat supports s390 zipl
> 
> 
> debian (initrd-tools_0.1.76.tar.gz):
>   initrd-tools the default package
>     /etc/mkinitrd/modules used instead of modprobe.conf to hold modules
>     mkinitrd.conf
>       specifies options that other mkinitrd get cli passed/integrated
>       ie. make image command, library path, busybox added in
>       probe to find root using fstab
>       and whether to install all modules, most needed to find root, specific
>       modules and dep, or none
> 
>     mkinitrd
>       specifically does work for raidtools and mdadm in scanning for root
>       dmcrypt support
>       code seems pretty clean considering root search effort
>         though it contains embedded lists of modules ie. most module list
>       2.4 and 2.6 support
>       udev not supported?
> 
>     uses dash shell
> 
>     linuxrc.conf is where?
> 
>   other initrd packages - bootcd/gibraltar for bootdisks
>     bootcd
>       bootcdmkinitrd
>         assumes running kernel is one for cd
> 	specifically loads modules just to get to cd
> 
>     gibraltar
>       same idea as bootcd, though well documented and supports usb bootdisks
>       uses uclibc for busybox
> 
> 
> slackware (10):
>   simple mkinitrd that just copies a static root system/busybov
>     and modules to initrd - no real advanced capabilities as usual
> 
> ----------------------------------------------------------------
> Mail by Ambiguous Computer Computer Ltd. an open source company.
> http://www.ambigc.com
> _______________________________________________
> rock-devel mailing list
> [email protected]
> http://www.rocklinux.net/mailman/listinfo/rock-devel

-- 

---
Don't blame me, I voted libertarian.