mirror of
https://github.com/cirosantilli/linux-kernel-module-cheat.git
synced 2026-01-23 02:05:57 +01:00
initrd in desktop
This commit is contained in:
16
README.adoc
16
README.adoc
@@ -1526,12 +1526,26 @@ The main ingredients to get this working are:
|
||||
+
|
||||
It is also possible to compress that image with other options.
|
||||
* `qemu -initrd`: make QEMU put the image into memory and tell the kernel about it.
|
||||
* `CONFIG_BLK_DEV_INITRD=y`: Compile the kernel with initrd support
|
||||
* `CONFIG_BLK_DEV_INITRD=y`: Compile the kernel with initrd support, see also: https://unix.stackexchange.com/questions/67462/linux-kernel-is-not-finding-the-initrd-correctly/424496#424496
|
||||
+
|
||||
Buildroot forces that option when `BR2_TARGET_ROOTFS_CPIO=y` is given
|
||||
|
||||
https://unix.stackexchange.com/questions/89923/how-does-linux-load-the-initrd-image asks how the mechanism works in more detail.
|
||||
|
||||
==== initrd in desktop distros
|
||||
|
||||
Most modern desktop distributions have an initrd in their root disk to do early setup.
|
||||
|
||||
The rationale for this is described at: https://en.wikipedia.org/wiki/Initial_ramdisk
|
||||
|
||||
One obvious use case is having an encrypted root filesystem: you keep the initrd in an unencrypted partition, and then setup decryption from there.
|
||||
|
||||
I think GRUB then knows read common disk formats, and then loads that initrd to memory with a `/boot/grub/grub.cfg` directive of type:
|
||||
|
||||
initrd /initrd.img-4.4.0-108-generic
|
||||
|
||||
Related: https://stackoverflow.com/questions/6405083/initrd-and-booting-the-linux-kernel
|
||||
|
||||
==== initramfs
|
||||
|
||||
initramfs is just like initrd, but you also glue the image directly to the kernel image itself.
|
||||
|
||||
Reference in New Issue
Block a user