用户工具

站点工具


jaysnote:ramfs_rootfs_initramfs

差别

这里会显示出您选择的修订版和当前版本之间的差别。

到此差别页面的链接

两侧同时换到之前的修订记录 前一修订版
后一修订版
前一修订版
jaysnote:ramfs_rootfs_initramfs [2018/11/19 13:51]
jaylee
jaysnote:ramfs_rootfs_initramfs [2018/11/19 18:35]
jaylee
行 49: 行 49:
   - The old initrd was always a separate file, while the initramfs archive is linked into the linux kernel image.  (The directory linux-*/usr is devoted to generating this archive during the build.)   - The old initrd was always a separate file, while the initramfs archive is linked into the linux kernel image.  (The directory linux-*/usr is devoted to generating this archive during the build.)
  
-  - The old initrd file was a gzipped filesystem image (in some file format, +  - The old initrd file was a gzipped filesystem image (in some file format,such as ext2, that needed a driver built into the kernel), while the new initramfs archive is a gzipped cpio archive (like tar only simpler,see cpio(1) and `Documentation/early-userspace/buffer-format.txt`).  The kernel's cpio extraction code is not only extremely small, it's also __init text and data that can be discarded during the boot process.
-    such as ext2, that needed a driver built into the kernel), while the new initramfs archive is a gzipped cpio archive (like tar only simpler, +
-    see cpio(1) and Documentation/early-userspace/buffer-format.txt).  The kernel's cpio extraction code is not only extremely small, it's also __init text and data that can be discarded during the boot process.+
  
   - The program run by the old initrd (which was called /initrd, not /init) did some setup and then returned to the kernel, while the init program from initramfs is not expected to return to the kernel.  (If /init needs to hand off control it can overmount / with a new root device and exec another init program.  See the switch_root utility, below.)   - The program run by the old initrd (which was called /initrd, not /init) did some setup and then returned to the kernel, while the init program from initramfs is not expected to return to the kernel.  (If /init needs to hand off control it can overmount / with a new root device and exec another init program.  See the switch_root utility, below.)
行 63: 行 61:
 The 2.6 kernel build process always creates a gzipped cpio format initramfs archive and links it into the resulting kernel binary.  By default, this archive is empty (consuming 134 bytes on x86). The 2.6 kernel build process always creates a gzipped cpio format initramfs archive and links it into the resulting kernel binary.  By default, this archive is empty (consuming 134 bytes on x86).
  
-The config option CONFIG_INITRAMFS_SOURCE (in General Setup in menuconfig, +The config option **CONFIG_INITRAMFS_SOURCE** (in General Setup in menuconfig,and living in usr/Kconfig) can be used to specify a source for the initramfs archive, which will automatically be incorporated into the resulting binary.  This option can point to an existing gzipped cpio archive, a directory containing files to be archived, or a text file specification such as the following example:
-and living in usr/Kconfig) can be used to specify a source for the initramfs archive, which will automatically be incorporated into the resulting binary.  This option can point to an existing gzipped cpio archive, a directory containing files to be archived, or a text file specification such as the following example:+
  
 ```bash ```bash
行 79: 行 76:
 ``` ```
  
-Run "usr/gen_init_cpio" (after the kernel build) to get a usage message documenting the above file format.+Run `"usr/gen_init_cpio"(after the kernel build) to get a usage message documenting the above file format.
  
-One advantage of the configuration file is that root access is not required to set permissions or create device nodes in the new archive.  (Note that those two example "file" entries expect to find files named "init.sh" and "busybox" in a directory called "initramfs", under the linux-2.6.* directory.  See Documentation/early-userspace/README for more details.)+One advantage of the configuration file is that root access is not required to set permissions or create device nodes in the new archive.  (Note that those two example "file" entries expect to find files named "init.sh" and "busybox" in a directory called "initramfs", under the linux-2.6.* directory.  See `Documentation/early-userspace/READMEfor more details.)
  
-The kernel does not depend on external cpio tools.  If you specify a directory instead of a configuration file, the kernel's build infrastructure creates a configuration file from that directory (usr/Makefile calls scripts/gen_initramfs_list.sh), and proceeds to package up that directory using the config file (by feeding it to usr/gen_init_cpio, which is created from usr/gen_init_cpio.c).  The kernel's build-time cpio creation code is entirely self-contained, and the kernel's boot-time extractor is also +The kernel does not depend on external cpio tools.  If you specify a directory instead of a configuration file, the kernel's build infrastructure creates a configuration file from that directory (`usr/Makefilecalls `scripts/gen_initramfs_list.sh`), and proceeds to package up that directory using the config file (by feeding it to `usr/gen_init_cpio`, which is created from `usr/gen_init_cpio.c`).  The kernel's build-time cpio creation code is entirely self-contained, and the kernel's boot-time extractor is also (obviously) self-contained.
-(obviously) self-contained.+
  
-The one thing you might need external cpio utilities installed for is creating or extracting your own preprepared cpio files to feed to the kernel build +The one thing you might need external cpio utilities installed for is creating or extracting your own preprepared cpio files to feed to the kernel build (instead of a config file or directory).
-(instead of a config file or directory).+
  
 The following command line can extract a cpio image (either by the above script or by the kernel build) back into its component files: The following command line can extract a cpio image (either by the above script or by the kernel build) back into its component files:
行 130: 行 125:
 ## Contents of initramfs: ## Contents of initramfs:
  
-An initramfs archive is a complete self-contained root filesystem for Linux. +An initramfs archive is a complete self-contained root filesystem for Linux.If you don't already understand what shared libraries, devices, and path you need to get a minimal root filesystem up and running, here are som references:
-If you don't already understand what shared libraries, devices, and path ou need to get a minimal root filesystem up and running, here are som eferences:+
  
 * http://www.tldp.org/HOWTO/Bootdisk-HOWTO/ * http://www.tldp.org/HOWTO/Bootdisk-HOWTO/
行 139: 行 133:
 * http://www.linuxfromscratch.org/lfs/view/stable/ * http://www.linuxfromscratch.org/lfs/view/stable/
  
-The "klibc" package (http://www.kernel.org/pub/linux/libs/klibc) i esigned to be a tiny C library to statically link early userspac ode against, along with some related utilities.  It is BSD licensed.+The "klibc" package (http://www.kernel.org/pub/linux/libs/klibc) is designed to be a tiny C library to statically link early userspace code against, along with some related utilities.  It is BSD licensed.
  
-I use uClibc (http://www.uclibc.org) and busybox (http://www.busybox.net) +I use uClibc (http://www.uclibc.org) and busybox (http://www.busybox.net) myself.  These are LGPL and GPL, respectively.  (A self-contained initramf package is planned for the busybox 1.3 release.)
-myself.  These are LGPL and GPL, respectively.  (A self-contained initramf ackage is planned for the busybox 1.3 release.)+
  
-In theory you could use glibc, but that's not well suited for small embedde ses like this.  (A "hello world" program statically linked against glibc i ver 400k.  With uClibc it's 7k.  Also note that glibc dlopens libnss to d ame lookups, even when otherwise statically linked.)+In theory you could use glibc, but that's not well suited for small embedde uses like this.  (A "hello world" program statically linked against glibc is over400k.  With uClibc it's 7k.  Also note that glibc dlopens libnss to do name lookups, even when otherwise statically linked.)
  
-A good first step is to get initramfs to run a statically linked "hello world" +A good first step is to get initramfs to run a statically linked "hello world" program as init, and test it under an emulator like qemu (www.qemu.org) or User Mode Linux, like so:
-program as init, and test it under an emulator like qemu (www.qemu.org) o ser Mode Linux, like so:+
  
 ```c ```c
行 153: 行 145:
  
 include <stdio.h> include <stdio.h>
- 
 include <unistd.h> include <unistd.h>
  
行 168: 行 159:
 ``` ```
  
-When debugging a normal root filesystem, it's nice to be able to boot with "init=/bin/sh" The initramfs equivalent is "rdinit=/bin/sh", and it' ust as useful.+When debugging a normal root filesystem, it's nice to be able to boot with "init=/bin/sh" The initramfs equivalent is "rdinit=/bin/sh", and it' just as useful.
  
 ## Why cpio rather than tar? ## Why cpio rather than tar?
行 212: 行 203:
 "early userspace" (I.E. initramfs). "early userspace" (I.E. initramfs).
  
-The move to early userspace is necessary because finding and mounting the real root device is complex.  Root partitions can span multiple devices (raid or separate journal).  They can be out on the network (requiring dhcp, setting a specific MAC address, logging into a server, etc).  They can live on removable media, with dynamically allocated major/minor numbers and persistent naming issues requiring a full udev implementation to sort out.  They can be compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned, +The move to early userspace is necessary because finding and mounting the real root device is complex.  Root partitions can span multiple devices (raid or separate journal).  They can be out on the network (requiring dhcp, setting a specific MAC address, logging into a server, etc).  They can live on removable media, with dynamically allocated major/minor numbers and persistent naming issues requiring a full udev implementation to sort out.  They can be compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned,and so on.
-and so on.+
  
 This kind of complexity (which inevitably includes policy) is rightly handled in userspace.  Both klibc and busybox/uClibc are working on simple initramfs packages to drop into a kernel build. This kind of complexity (which inevitably includes policy) is rightly handled in userspace.  Both klibc and busybox/uClibc are working on simple initramfs packages to drop into a kernel build.
jaysnote/ramfs_rootfs_initramfs.txt · 最后更改: 2021/06/22 23:14 (外部编辑)