Differences
This shows you the differences between two versions of the page.
|
ass:cursuri:02:theory:01 [2023/07/15 14:41] radu.mantu created |
ass:cursuri:02:theory:01 [2023/07/19 11:08] (current) radu.mantu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== Ramdisk ==== | + | ==== Initial ramdisk & rootfs ==== |
| - | After performing the initial setup, Linux will try to fork into User Space by starting the **init** process. For this to happen, the kernel first needs to load a //root filesystem//. The location of this //rootfs// is specified as part of the kernel's command line arguments: | + | When Linux tries to boot into User Space, it does so by starting the **init** (PID=1) process from several well-known locations (e..g: ''/usr/sbin/init'', etc.) For this to happen, the kernel first needs to load a //root filesystem//. The location of this //rootfs// is specified as part of the kernel's command line arguments: |
| <code bash> | <code bash> | ||
| Line 8: | Line 8: | ||
| </code> | </code> | ||
| - | Notice in this example how the ''root'' variable is not ''/dev/sda'' or ''/dev/nvme0n1'', but instead a Logical Volume (i.e.: an intermediate representational layer that abstracts the backing storage devices -- see figure below.) Although the kernel has LVM support, the drivers may be compiled as modules to be loaded after booting into User Space. This puts us in an awkward position where we need the LVM drivers to access the //root// partition but the modules are located on the very same //root// partition. | + | Notice in this example how the ''root'' variable is not ''/dev/sda'' or ''/dev/nvme0n1'', but instead a Logical Volume (i.e.: an intermediate representational layer that abstracts the backing storage devices -- see figure below.) Although the kernel has LVM support, the drivers are likely to be compiled as modules, to be loaded on demand when the user requires them, rather than increasing the size and complexity of the kernel with features that the majority of users do not need. This puts us in an awkward position where we need the LVM drivers to access the //root// partition but the modules are located on the very same //root// partition. |
| {{ :ass:laboratoare:02:tasks:lvm.png?750 |}} | {{ :ass:laboratoare:02:tasks:lvm.png?750 |}} | ||
| Line 14: | Line 14: | ||
| <b>Figure 1:</b> Abstraction of storage mediums under LVM. | <b>Figure 1:</b> Abstraction of storage mediums under LVM. | ||
| </center></html> | </center></html> | ||
| + | |||
| + | The solution is to add an //initial ramdisk//: a disk image that is loaded in RAM at the same time as the kernel. The kernel will view this region in RAM as a storage device, without needing extensive driver support (e.g.: NET_FS). This minimal disk image should contain all kernel modules and tools required to gain access and mount the real //rootfs//. Once the //initramfs// is mounted at ''/'' and the real //rootfs// is mounted at another location (e.g.: ''/mnt/''), the **init** process will use the ''pivot_root()'' system call to switch around the two mount points. As a result, the real //rootfs// will then be mounted at ''/'', making the //initramfs// safe to unmount from ''/mnt/'' and clear from RAM. | ||
| + | |||
| + | During ARM development, such ramdisks are often used for prototyping purposes. Once we ensure that the Linux kernel successfully boots to User Space, we may consider writing a partition table to the eMMC memory. | ||
