God damn email program ate my post! Thank god for grep....
=====================================================================
Subject: [patch] initrd-archive: untar and mkfs.minix initrd support. Please test.
(You can't say I wasn't thorough enough with this submission : > )
Version: Made against 2.0.32, patches clean with .32 and .33. (probably
much lower as well)
Changed Files:
linux/Documentation/Configure.help
linux/drivers/block/Config.in
linux/drivers/block/rd.c
linux/drivers/block/rd.mkminix.c (new)
linux/drivers/block/rd.untar.c (new)
linux/fs/filesystems.c
linux/init/main.c
First look:
2 new compile time options
New kernel CLP - initrd_archive=
What it does:
Adds two new sub features to initrd on boot support.
initird_archive provides untar support and allows the root to be in a tar.gz
instead of one of those nasty raw image files. To use this you first make a
raw image file as you normally would have done, (make an fs on it)
but don't put any files in it. Compress it down with gzip. Then pad it with
zero's up to an even KiloByte range. Now take your root.tar.gz file and
cat them together. Spec this file as the initrd file for the boot loader to
load. On the kernel option append line, spec initrd_archive=[int] which is
the number KB of the rawimage file (or more specificly the root.tar.gz files
offset from the beginning of the file) See below for an example if
you can't follow this.
Boot the disk (or whatever you are using). The empty raw image part will be
used to create the filesystem on /dev/ram0. When the root is mounted the
remaining archive will be extracted to it (before INIT is even called)
The sub feature to initrd_archive, is initrd_archive_autofs. This takes the
above one step futher. Appending initrd_archive=minix, will have the kernel
dynamically create a minix filesystem on /dev/ram0 at boot time. No raw
image file is needed AT ALL. Simply spec a normal tar.gz file and it will be
extaracted right after the root is mounted.
Everything is backwards compatable. With both compiled in specing
initrd_archive=[int] will fall back to the combo file approach, and specing
initrd_archive=0 (or excluding it) will let you use those ugly images again.
I expect autofs to be used the most. The former gives you the flexablity
of other filesystems, etc. Also note that the beginning raw image CAN have
files in it, and then a second tar. Why you would need this, I dunno, but
it's there if you do.
Why are these features important:
For anyone making a boot disk it's a time saver.
For project's like linux-router it's a god send. The disk we make are
fully self contained. Ever try to incrementally back up a raw image on
the fly? Hehe, good luck. Up until this point we were using a quasi-image
system with a raw boot strap image that mounts the boot medium and
extract the archive. Very ugly. On top of this a .tgz is typically smaller
then a raw image. The addition of both of these features results in only a
2K bigger zImage. This alone is reason enough to switch from raw images if
space is tight.
Where to get and how to test:
This diff and future versions will be made available @
ftp://ftp.psychosis.com/pub/linux-router/
If you are linux-router user I have also made available beta1's initrd.rgz
in .tgz format so you can try using the autofs feature.
The easiest way to test to a take a previous boot disk you have a convert it
over. Distribution install/rescue disks for instance. Syslinux is the boot
loader of choice but someone please try LILO for me.
The most important things to look for is untar file intergrity and
permissions!
Also bare in mind this is the first release and also my first attempt at a
kernel hack. (And at Unix programming in general. What a way to start, eh?)
As important as it is to test for general functionality I need a few gurus
to look through my code and try and pick out any major stupids I might have
made. Suggestions for improvement are always welcome.
Known Bugs:
If they're were known they'd be fixed : >
The only things you could consider a bug -
Untar creation time.
It may be offset from GMT incorrectly. I'm not sure if this is even fixable
since we are doing this so early in the kernel. It may also be related to
the box I made the archives on. Let me know your results.
Can't have a path longer then 100 chars. Oh well, that's tar.
Future:
I would like to see if this can be moved into stable once it has been tested
more thoroughly. 100% of the code is ifdef'ed against initrd at boot
support, and 95% of that is ifdef'ed against the 2 specific features. It's a
pretty safe addition....
In any event once this code get's solidified I will add these features to
2.1. I'm also considering revamping a bit of the rd code, and maybe even
bzip2 support for initrd images(????)
Shell example:
Let's make one with ext2 for a 8MB ramdisk
dd if=/dev/zero of=rawfs bs=1024 count=8192
mke2fs rawfs
gzip -c9 rawfs >rawfs.gz
ls -l rawfs.gz
-rw-r--r-- 1 root root 8417 Jan 10 06:34 rawfs.gz
#pad it above 9K
dd if=/dev/zero of=initrd.trd bs=1024 count=9
cat initrd.trd >>rawfs.gz
#Trim it to an even 9K
dd if=rawfs.gz of=initrd.trd bs=1024 count=9
#Combine files
cat root.tar.gz >>initrd.trd
#We made root with something like 'tar cvf - * | gzip -c9 >root.tar.gz'
#With syslinux, the syslinux.cfg would have a line like this
append="load_ramdisk=1 initrd_archive=9 initrd=initrd.trd
root=/dev/ram0 ramdisk_size=8192"
#An autofs setting that uses a normal tar.gz (no images at all)
#and a default 4096K ramdisk
append="load_ramdisk=1 initrd_archive=minix initrd=initrd.tgz root=/dev/ram0"
-------------------------------------------------------------------------
http://www.psychosis.com/emc/ Elite MicroComputers 908-541-4214
http://www.psychosis.com/linux-router/ Linux Router Project