^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ===========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) Ramfs, rootfs and initramfs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) ===========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) October 17, 2005
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) Rob Landley <rob@landley.net>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) What is ramfs?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) --------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) Ramfs is a very simple filesystem that exports Linux's disk caching
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) mechanisms (the page cache and dentry cache) as a dynamically resizable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) RAM-based filesystem.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) Normally all files are cached in memory by Linux. Pages of data read from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) backing store (usually the block device the filesystem is mounted on) are kept
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) around in case it's needed again, but marked as clean (freeable) in case the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) Virtual Memory system needs the memory for something else. Similarly, data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) written to files is marked clean as soon as it has been written to backing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) store, but kept around for caching purposes until the VM reallocates the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) memory. A similar mechanism (the dentry cache) greatly speeds up access to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) directories.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) With ramfs, there is no backing store. Files written into ramfs allocate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) dentries and page cache as usual, but there's nowhere to write them to.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) This means the pages are never marked clean, so they can't be freed by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) VM when it's looking to recycle memory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) The amount of code required to implement ramfs is tiny, because all the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) work is done by the existing Linux caching infrastructure. Basically,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) you're mounting the disk cache as a filesystem. Because of this, ramfs is not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) an optional component removable via menuconfig, since there would be negligible
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) space savings.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) ramfs and ramdisk:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) ------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) The older "ram disk" mechanism created a synthetic block device out of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) an area of RAM and used it as backing store for a filesystem. This block
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) device was of fixed size, so the filesystem mounted on it was of fixed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) size. Using a ram disk also required unnecessarily copying memory from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) fake block device into the page cache (and copying changes back out), as well
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) as creating and destroying dentries. Plus it needed a filesystem driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) (such as ext2) to format and interpret this data.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) Compared to ramfs, this wastes memory (and memory bus bandwidth), creates
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) unnecessary work for the CPU, and pollutes the CPU caches. (There are tricks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) to avoid this copying by playing with the page tables, but they're unpleasantly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) complicated and turn out to be about as expensive as the copying anyway.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) More to the point, all the work ramfs is doing has to happen _anyway_,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) since all file access goes through the page and dentry caches. The RAM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) disk is simply unnecessary; ramfs is internally much simpler.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) Another reason ramdisks are semi-obsolete is that the introduction of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) loopback devices offered a more flexible and convenient way to create
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) synthetic block devices, now from files instead of from chunks of memory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) See losetup (8) for details.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) ramfs and tmpfs:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) ----------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) One downside of ramfs is you can keep writing data into it until you fill
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) up all memory, and the VM can't free it because the VM thinks that files
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) should get written to backing store (rather than swap space), but ramfs hasn't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) got any backing store. Because of this, only root (or a trusted user) should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) be allowed write access to a ramfs mount.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) A ramfs derivative called tmpfs was created to add size limits, and the ability
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) to write the data to swap space. Normal users can be allowed write access to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) tmpfs mounts. See Documentation/filesystems/tmpfs.rst for more information.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) What is rootfs?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) ---------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) Rootfs is a special instance of ramfs (or tmpfs, if that's enabled), which is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) always present in 2.6 systems. You can't unmount rootfs for approximately the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) same reason you can't kill the init process; rather than having special code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) to check for and handle an empty list, it's smaller and simpler for the kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) to just make sure certain lists can't become empty.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) Most systems just mount another filesystem over rootfs and ignore it. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) amount of space an empty instance of ramfs takes up is tiny.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) default. To force ramfs, add "rootfstype=ramfs" to the kernel command
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) line.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) What is initramfs?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) ------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) All 2.6 Linux kernels contain a gzipped "cpio" format archive, which is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) extracted into rootfs when the kernel boots up. After extracting, the kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) checks to see if rootfs contains a file "init", and if so it executes it as PID
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) 1. If found, this init process is responsible for bringing the system the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) rest of the way up, including locating and mounting the real root device (if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) any). If rootfs does not contain an init program after the embedded cpio
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) archive is extracted into it, the kernel will fall through to the older code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) to locate and mount a root partition, then exec some variant of /sbin/init
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) out of that.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) All this differs from the old initrd in several ways:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) - The old initrd was always a separate file, while the initramfs archive is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) linked into the linux kernel image. (The directory ``linux-*/usr`` is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) devoted to generating this archive during the build.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) - The old initrd file was a gzipped filesystem image (in some file format,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) such as ext2, that needed a driver built into the kernel), while the new
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) initramfs archive is a gzipped cpio archive (like tar only simpler,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) see cpio(1) and Documentation/driver-api/early-userspace/buffer-format.rst).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) The kernel's cpio extraction code is not only extremely small, it's also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) __init text and data that can be discarded during the boot process.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) - The program run by the old initrd (which was called /initrd, not /init) did
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) some setup and then returned to the kernel, while the init program from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) initramfs is not expected to return to the kernel. (If /init needs to hand
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) off control it can overmount / with a new root device and exec another init
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) program. See the switch_root utility, below.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) - When switching another root device, initrd would pivot_root and then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) umount the ramdisk. But initramfs is rootfs: you can neither pivot_root
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) rootfs, nor unmount it. Instead delete everything out of rootfs to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) with the new root (cd /newmount; mount --move . /; chroot .), attach
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) stdin/stdout/stderr to the new /dev/console, and exec the new init.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) Since this is a remarkably persnickety process (and involves deleting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) commands before you can run them), the klibc package introduced a helper
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) program (utils/run_init.c) to do all this for you. Most other packages
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) (such as busybox) have named this command "switch_root".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) Populating initramfs:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) ---------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) The 2.6 kernel build process always creates a gzipped cpio format initramfs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) archive and links it into the resulting kernel binary. By default, this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) archive is empty (consuming 134 bytes on x86).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) The config option CONFIG_INITRAMFS_SOURCE (in General Setup in menuconfig,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) and living in usr/Kconfig) can be used to specify a source for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) initramfs archive, which will automatically be incorporated into the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) resulting binary. This option can point to an existing gzipped cpio
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) archive, a directory containing files to be archived, or a text file
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) specification such as the following example::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) dir /dev 755 0 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) nod /dev/console 644 0 0 c 5 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) nod /dev/loop0 644 0 0 b 7 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) dir /bin 755 1000 1000
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) slink /bin/sh busybox 777 0 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) file /bin/busybox initramfs/busybox 755 0 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) dir /proc 755 0 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) dir /sys 755 0 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) dir /mnt 755 0 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) file /init initramfs/init.sh 755 0 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) Run "usr/gen_init_cpio" (after the kernel build) to get a usage message
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) documenting the above file format.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) One advantage of the configuration file is that root access is not required to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) set permissions or create device nodes in the new archive. (Note that those
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) two example "file" entries expect to find files named "init.sh" and "busybox" in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) a directory called "initramfs", under the linux-2.6.* directory. See
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) Documentation/driver-api/early-userspace/early_userspace_support.rst for more details.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) The kernel does not depend on external cpio tools. If you specify a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) directory instead of a configuration file, the kernel's build infrastructure
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) creates a configuration file from that directory (usr/Makefile calls
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) usr/gen_initramfs.sh), and proceeds to package up that directory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) using the config file (by feeding it to usr/gen_init_cpio, which is created
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) from usr/gen_init_cpio.c). The kernel's build-time cpio creation code is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) entirely self-contained, and the kernel's boot-time extractor is also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) (obviously) self-contained.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) The one thing you might need external cpio utilities installed for is creating
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) or extracting your own preprepared cpio files to feed to the kernel build
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) (instead of a config file or directory).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) The following command line can extract a cpio image (either by the above script
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) or by the kernel build) back into its component files::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) cpio -i -d -H newc -F initramfs_data.cpio --no-absolute-filenames
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) The following shell script can create a prebuilt cpio archive you can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) use in place of the above config file::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) #!/bin/sh
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) # Copyright 2006 Rob Landley <rob@landley.net> and TimeSys Corporation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) # Licensed under GPL version 2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) if [ $# -ne 2 ]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) echo "usage: mkinitramfs directory imagename.cpio.gz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) exit 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) fi
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) if [ -d "$1" ]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) echo "creating $2 from $1"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) (cd "$1"; find . | cpio -o -H newc | gzip) > "$2"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) else
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) echo "First argument must be a directory"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) exit 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) fi
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) .. Note::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) The cpio man page contains some bad advice that will break your initramfs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) archive if you follow it. It says "A typical way to generate the list
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) of filenames is with the find command; you should give find the -depth
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) option to minimize problems with permissions on directories that are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) unwritable or not searchable." Don't do this when creating
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) initramfs.cpio.gz images, it won't work. The Linux kernel cpio extractor
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) won't create files in a directory that doesn't exist, so the directory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) entries must go before the files that go in those directories.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) The above script gets them in the right order.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) External initramfs images:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) --------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) If the kernel has initrd support enabled, an external cpio.gz archive can also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) be passed into a 2.6 kernel in place of an initrd. In this case, the kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) will autodetect the type (initramfs, not initrd) and extract the external cpio
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) archive into rootfs before trying to run /init.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) This has the memory efficiency advantages of initramfs (no ramdisk block
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) device) but the separate packaging of initrd (which is nice if you have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) non-GPL code you'd like to run from initramfs, without conflating it with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) the GPL licensed Linux kernel binary).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) It can also be used to supplement the kernel's built-in initramfs image. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) files in the external archive will overwrite any conflicting files in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) the built-in initramfs archive. Some distributors also prefer to customize
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) a single kernel image with task-specific initramfs images, without recompiling.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) Contents of initramfs:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) ----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) An initramfs archive is a complete self-contained root filesystem for Linux.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) If you don't already understand what shared libraries, devices, and paths
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) you need to get a minimal root filesystem up and running, here are some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) references:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) - https://www.tldp.org/HOWTO/Bootdisk-HOWTO/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) - https://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) - http://www.linuxfromscratch.org/lfs/view/stable/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) The "klibc" package (https://www.kernel.org/pub/linux/libs/klibc) is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) designed to be a tiny C library to statically link early userspace
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) code against, along with some related utilities. It is BSD licensed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) I use uClibc (https://www.uclibc.org) and busybox (https://www.busybox.net)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) myself. These are LGPL and GPL, respectively. (A self-contained initramfs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) package is planned for the busybox 1.3 release.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) In theory you could use glibc, but that's not well suited for small embedded
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) uses like this. (A "hello world" program statically linked against glibc is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) over 400k. With uClibc it's 7k. Also note that glibc dlopens libnss to do
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) name lookups, even when otherwise statically linked.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) A good first step is to get initramfs to run a statically linked "hello world"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) program as init, and test it under an emulator like qemu (www.qemu.org) or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) User Mode Linux, like so::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) cat > hello.c << EOF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) #include <stdio.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) #include <unistd.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) int main(int argc, char *argv[])
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) printf("Hello world!\n");
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) sleep(999999999);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) EOF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) gcc -static hello.c -o init
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) echo init | cpio -o -H newc | gzip > test.cpio.gz
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) # Testing external initramfs using the initrd loading mechanism.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) qemu -kernel /boot/vmlinuz -initrd test.cpio.gz /dev/zero
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) When debugging a normal root filesystem, it's nice to be able to boot with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) "init=/bin/sh". The initramfs equivalent is "rdinit=/bin/sh", and it's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) just as useful.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) Why cpio rather than tar?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) -------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) This decision was made back in December, 2001. The discussion started here:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1538.html
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) And spawned a second thread (specifically on tar vs cpio), starting here:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1587.html
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) The quick and dirty summary version (which is no substitute for reading
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) the above threads) is:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) 1) cpio is a standard. It's decades old (from the AT&T days), and already
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) widely used on Linux (inside RPM, Red Hat's device driver disks). Here's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) a Linux Journal article about it from 1996:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) http://www.linuxjournal.com/article/1213
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) It's not as popular as tar because the traditional cpio command line tools
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) require _truly_hideous_ command line arguments. But that says nothing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) either way about the archive format, and there are alternative tools,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) such as:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314) http://freecode.com/projects/afio
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) 2) The cpio archive format chosen by the kernel is simpler and cleaner (and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) thus easier to create and parse) than any of the (literally dozens of)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318) various tar archive formats. The complete initramfs archive format is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) explained in buffer-format.txt, created in usr/gen_init_cpio.c, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) extracted in init/initramfs.c. All three together come to less than 26k
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) total of human-readable text.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) 3) The GNU project standardizing on tar is approximately as relevant as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324) Windows standardizing on zip. Linux is not part of either, and is free
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) to make its own technical decisions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) 4) Since this is a kernel internal format, it could easily have been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) something brand new. The kernel provides its own tools to create and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329) extract this format anyway. Using an existing standard was preferable,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) but not essential.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) 5) Al Viro made the decision (quote: "tar is ugly as hell and not going to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) supported on the kernel side"):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1540.html
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) explained his reasoning:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) - http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1550.html
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) - http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1638.html
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) and, most importantly, designed and implemented the initramfs code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) Future directions:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) ------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) Today (2.6.16), initramfs is always compiled in, but not always used. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) kernel falls back to legacy boot code that is reached only if initramfs does
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) not contain an /init program. The fallback is legacy code, there to ensure a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) smooth transition and allowing early boot functionality to gradually move to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) "early userspace" (I.E. initramfs).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) The move to early userspace is necessary because finding and mounting the real
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) root device is complex. Root partitions can span multiple devices (raid or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) separate journal). They can be out on the network (requiring dhcp, setting a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) specific MAC address, logging into a server, etc). They can live on removable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) media, with dynamically allocated major/minor numbers and persistent naming
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) issues requiring a full udev implementation to sort out. They can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) and so on.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) This kind of complexity (which inevitably includes policy) is rightly handled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) in userspace. Both klibc and busybox/uClibc are working on simple initramfs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) packages to drop into a kernel build.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366) The klibc package has now been accepted into Andrew Morton's 2.6.17-mm tree.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) The kernel's current early boot code (partition detection, etc) will probably
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) be migrated into a default initramfs, automatically created and used by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369) kernel build.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags