Re: nash, initrd, cpio...
Ok. Now I clearly see the advantages of using cpio instead of an ext2
filesystem.
It seems like when initrd is a cpio archive then "init" is executed
instead of "linuxrc". So I converted my FC3 initrd cpio archive into an
ext2 (just to test, I understand I should switch to the cpio way). I
changed "init" into "linuxrc" and though it would do it.
But it did not.
The ext2 (linuxrc) version jumps to the new root fs but init complains
about missing parameter (runlevel) and quits.
Do you know what's happening?
Comparing red hat 9 (ext2 way) and fedora 3 (cpio way) I changed the end
of the initrd sequence, replacing
switchroot /sysroot
by
echo 0x0100 > /proc/sys/kernel/real-root-dev
pivot_root /sysroot /sysroot/initrd
It now works fine but I don't really understand why...
I'm booting on usual /dev/hda# so why should I report the kernel that
the real-root-dev is 0x0100 (which corresponds to the first ram disk)?
Now I have the solution but I'm frustrated not to understand it! :'|
Gildas
Le jeudi 24 février 2005 à 13:05 +0000, Luciano Miguel Ferreira Rocha a
écrit :
On Thu, Feb 24, 2005 at 09:15:08AM +0100, Gildas Bayard wrote:
>
> Does anyone knows who I should ask about nash and cpio initrd support?
> (see my yesterday post)
fedora users list? This is for questions regarding the development of
the distribution.
> Documentation is often out of date and I could not find any information
> about why does FC3 changes initrd format from ext2 fs to cpio archive...
Cpio brings many advantages:
1. you create an initrd directly from your working copy by using a
simple command:
find . | cpio -co | gzip -9 > ../new-initrd
(don't forget the option -c to cpio)
instead of:
dd if=/dev/zero of=img bs=1k count=16k
mke2fs -f img
tune2fs -c0 -i0 img
mount img /mnt -o loop
rmdir /mnt/lost+found
cp -a files /mnt
umount /mnt
gzip -9 < img > new-initrd
2. The files will be extracted to a tmpfs, so it will consume only the
space the files use, and can grow accordingly to free ram and swap. the
initrd image is limited by the size it was created with, and will
consume that full size.
(and no space wasted on filesystem structures and old data)
3. no need to complex filesystems and block devices in the kernel
4. there is a libc in development designed for booting the system
(loading modules, configuring network, mounting filesystems, etc)
5. you can append several cpio archives together. the boot process will
extract all files.
6. unified boot process (linuxrc, init, etc)
7. etc. I'm not an expert :)
You can find a cpio archive that boots with support for lvm, ext3,
busybox and other stuff in:
http://users.gil.di.uminho.pt/strange/initrd-e2tools.img
(modules in the image are for kernel 2.6.10-1.1110_FC4)
Regards,
Luciano Rocha