boot sequence discussion
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!
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
On 8/27/07, Rich Edelman <rcedelman@comcast.net> wrote:
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).
Well, if you don't have some kind of filesystem compiled into the kernel, how would you load a module from... a filesystem?
On 8/28/07, Monty J. Harder <mjharder@gmail.com> wrote:
Well, if you don't have some kind of filesystem compiled into the kernel, how would you load a module from... a filesystem?
My naive and ignorant presumption is that initfs sets up the file system structure at a higher level -- perhaps the virtual file system that linux uses to make all the file systems behave the same -- rather than going through the whole dance of pretending that the data in question is really on some kind of external media that has to be mounted and so on. Not alert enough at this point to construct a nice metaphor.
On 9/2/07, David Nicol <davidnicol@gmail.com> wrote:
My naive and ignorant presumption is that initfs sets up the file system structure at a higher level -- perhaps the virtual file system that linux uses to make all the file systems behave the same -- rather than going through the whole dance of pretending that the data in question is really on some kind of external media that has to be mounted and so on. Not alert enough at this point to construct a nice metaphor.
VFS doesn't take away the lower level of mounting a file system, it's a layer of abstraction that hides the details of the process. (This is a Very Good Thing, because it allows the code for managing files, directories, pipes, etc. to be written once at the top layer, a second layer to handle logical representation schemes, and a lower layer to work with the physical hardware.) There's still got to be a device, a driver, and the low-level code that knows about the actual representation of the filesystems on whatever media they occupy.
VFS doesn't take away the lower level of mounting a file system, it's a layer of abstraction that hides the details of the process. (This is a Very Good Thing, because it allows the code for managing files, directories, pipes, etc. to be written once at the top layer, a second layer to handle logical representation schemes, and a lower layer to work with the physical hardware.) There's still got to be a device, a driver, and the low-level code that knows about the actual representation of the filesystems on whatever media they occupy.
initfs appears (from the configuration dialog) to be its own ittybitty fs that reads cpio archives. From memory. Possibly in-place. I think that could live entirely in your second layer.
participants (3)
-
David Nicol -
Monty J. Harder -
Rich Edelman