On Monday 27 August 2007 14:14, David Nicol wrote:
according to the initrd documentation, the purpose of initrd is to pre-load the correct modules in a more reliable way than modprobe. Mkinitrd flatly refuses to run against the nonmodular kernel I have built.
I'm also a little bit surprised that things in /sbin aren't all statically linked any more; I think that requirement went away some time ago.
There's this "initial ramdisk" thing now that looks really exciting: apparently you list files or directories and those things get cpio-ed up and bundled right with the bzImage, which strikes me as an excellent way to put together a pocket router or a good rescue disk image:
Never mind a rescue filesystem, just copy this file to your boot partition and add a rescue option in grub.conf!
You might want to try 'mkinitramfs' instead of 'mkintrd'. I'm not a fedora person, but give it a shot.. that's what I use on my LFS systems here at home.
As of kernel 2.6, initial ramdisks have been deprecated... the trend now is toward an initial ram fs. Ramdisks meant you needed to have some kind of filesystem (usually ext2 or cramfs) compiled into the kernel (instead of being available as a module). As stated above, the ramfs is just a gzipped cpio archive. The boot parameter is the same, but how it is handled is slightly different. With an initrd (disk image), the kernel looks for a file called /linuxrc to run, and with a ramfs (cpio archive), the kernel looks for a file called /initrd to run. I think it will fall back to /linuxrc. In both cases, however, the end result (after any modules are loaded) is to exec /sbin/init. (/sbin/init must be exec'd because both /linuxrc and /init run as PID 1, which is the PID that /sbin/init must run as.)
Anyway.. if needed I'll happily post my mkinitramfs script and you can use that.
Rich