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 >
