Rich Freeman posted on Fri, 05 Aug 2011 21:04:50 -0400 as excerpted: > On Fri, Aug 5, 2011 at 8:42 PM, William Hubbs <willi...@gentoo.org> > wrote: >> On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote: >>> How does the tool that creates an initramfs know which files to copy >>> from /usr and /var anyhow? >> >> My understanding is that nothing gets copied from /usr and /var, and >> it doesn't have to. >> >> Here is my basic understanding of how the boot sequence works: >> >> 1) rootfs is mounted on /. Rootfs contains the contents of the >> initramfs. > > Ok, so the initfs is typically in /boot, though it need not be. It > needs to be someplace the bootloader can find it, and with grub legacy > that typically means on a bare hard drive partition, or one using md > raid-1 with older metadata. The initramfs doesn't need to find itself - > the bootloader loads it into ram and passes its address to the kernel > when executing it.
With a personal knowledge caveat similar to that of williamh's, I believe tha above to be incorrect. AFAIK, the distinction between initrd and initramfs is the following: initrd: An initrd is a file separate from the kernel, so yes, the bootloader needs to know about and pass its information to the kernel. initramfs: An initramfs, as alluded to in the quote from the documentation in an earlier post, is a cpio archive appended to the kernel image itself -- no separate initrd file, and the kernel knows to look for the compressed image as loaded into memory after the end of the kernel code itself. At kernel build time, if this feature is configured the kernel make process will check to see if a suitable prebuild cpio archive is available and append it to the kernel image if so. If the cpio archive is not available yet but there's a configuration for building it, it'll be built, then appended to the kernel image. As such, the bootloader doesn't need to point the kernel at the initramfs since the kernel already knows where to find it as loaded into memory as part of the kernel image file, and certain kernel commandline options (AFAIK root=, init=) that would normally apply to the initrd if one was used, apply to the final "realroot" instead. An initramfs thus has less "to go wrong", since it's appended to the kernel image as part of the same file at build time, so the two are always kept together. While it's still possible that the kernel fails to update its initramfs image at build-time, once that's correct, the boot loader can't accidentally be pointed at the wrong initrd, since an initramfs becomes part of the same kernel file as the kernel image itself. (I've read that it's possible to have both an initramfs as appended to the kernel image, and an initrd as configured on the kernel command line by the boot loader, thus effectively creating a three-stage boot, initramfs, initrd, realroot. I've no idea whether that's true or not, but the idea of trying to keep track of what belongs in one vs. the other strikes me as way more complex than it'd be worth for most gentoo users, altho I can see that it might be useful for users of binary distros with prebuilt kernel images, who wish to do additional stuff in an initrd, without messing with the prebuilt and presumably supported kernel image as distributed by their distro, with its own prebuilt initramfs appended. It could also be useful for certain gentoo users, for instance those doing remote-boot kernels with the basics applying to most instances found in the initramfs, while any necessary configuration specific to only a subset could be loaded as an initrd.) >> 2) the init program inside the initramfs is run. >> 3) This init program will mount the real /usr and /var. > > So, this is the chicken and egg bit that led to the question about how > the tool that creates initramfs knows what to copy from /usr, etc. If > /usr can be mounted without any files from /usr, then clearly booting > without /usr mounted shouldn't be a problem (just mount it early). If > it does need files from /usr, then the initramfs has to contain those > files since /usr isn't mounted yet. > > The answer isn't that complicated - the tool just knows what files are > needed from a hardcoded list/etc. No quibbles with this or the rest of what you wrote, and indeed, I agree that the question needed asked/answered. (It still hasn't been answered in any detail, but I'm not sure if that was the intent of asking the question. The general "it's hardcoded" answer is sufficient at a suitably high level.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
