Initramfs Ubuntu

Initramfs is a solution specified for the 2.6 series of Linux kernel. The idea is that there are several installation magics implemented in the kernel that can be just as conveniently implemented in userspace. At an initial glance, it's only slightly distinct from a classic initrd.

Some key points of initramfs are mentioned below:

• CPIO archive, hence, no file systems at all are required in the kernel. Simply, the archive is unpacked into the ramdisk.
• The unpacking implements before do_basic_setup is run. It means that the files of firmware are present before the drivers of in-kernel load.
• Instead of calling prepare_namespace the userspace init is normally called. All root device findings and the setup of md implemented in userspace.
• The initramfs could be created directly into the kernel by including it in an EMF archive upon the .init.ramfs section name.
• An initramfs could be deformed. Offering an initramfs to a kernel with the classic initrd mechanisms leads to being unpacked together with the initramfs that is created into the kernel.
• All root device magic naming goes away. Developing udev into an initramfs specifies that the exact similar appearance of the /dev tree could be used during the boot sequence. It should resolve the SATA failures majority that is found in which an install can be accomplished, but the initrd can't boot.

Detailed Information of Initramfs

Initramfs is used as an initial root filesystem that our system has access to. It is used to mount the actual rootfs which includes all our data. The initramfs contains several modules required to mount our rootfs. But we always could compile our kernel for having these modules. Would be required the initramfs? The answer to it is 'relies on our system'.

A few system configurations require a user space utility for provoking the kernel to appropriately configure the devices. For example, cryptdevices: they require having a password through the user. The password appealing utility being a utility of userspace, but the rootfs can't come up until the userspace utilities are present. The initramfs acts as a mediator in between providing a temporary rootfs which has carry the utilities of user space required to mount the actual rootfs.

Where do these utilities of the userspace come from?

These utilities of the userspace required to mount an actual rootfs come from our rootfs. When we build an initramfs with the commands, i.e., "mkinitramfs" or "update-initramfs". These commands will copy these utilities through the place in which they are contained to a temporary directory.

For example, the cryptsetup (binary) comes from the cryptsetup (package). This binary is contained in the /sbin/ directory. Thus, if we install the package here is what will happen:

• Adds any file in our /usr/share/initramfs/hooks/ - for example, cryptroot. These files are run when we enter update-initramfs. We will see that this hook will copy cryptsetup through the /sbin/cryptsetup directory to the initramfs/sbin/cryptsetup directory when we look at this "cryptroot" script.
• Also, it calls update-initramfs automatically.

So, all packages that potentially can configure our root device, have a "hook" script which is run when we run mkinitramfs or update-initramfs so as to contain the essential utilities of the user space in our rootfs. Generally, the "update-initramfs" is called if we install a package that is capable to configure our root device.

For example, if we install the "cryptsetup" package, no matter if our root device has been encrypted or not, the package installation will call update-initramfs which would execute the script, i.e., "hook" installed (if the package was already installed).

When our root device relies on a module (that is not compiled within the kernel) like a module_must_be within the initramfs for our root device to be recognized at boot time. Generally, the modules are installed in the /lib/modules/<kernel-version>/ directory when we install a package of the kernel.

Although, when we make compile any kernel manually, it's necessary for calling to make modules_install (which will install the compiled module within the /lib/modules/<kernel-version>/ directory) and pursue it by "depmod" (which generates a modules.dep and a map file within the /lib/modules/<kernel-version>/ directory).

We are needed to update our initramfs (or make a new one when it is a newer kernel) by calling "mkinitramfs" or "update-initramfs" after this step. Our root device would not be recognized at boot time if we forget these steps.

Note: This similar command's scheme uses in the case if we separately compile a single module (rather than installing a package of the Ubuntu kernel).

Now the following is how the initramfs runs. The initial process for getting control is a process, i.e., init. Procedurally, the init process can invoke many other scripts kept within the initrd. The scripts reside within the dir scripts in our initramfs. The dir script is further categorized into the below dirs:

• init-top
• init-premount
• boot-top (our crypt scripts run here, e.g., for asking the user password)
• boot-premount
• boot
• boot-bottom
• init-bottom

Here, the boot is substituted by remote or local relying on whether our rootfs is remote or local. It is the script that will mount our rootfs on the initramfs/root/ directory. init-bottom scripts are run sequentially if everything goes well then the boot-bottom. Then, init grabs the control back and implements the below things:

• init moves the /sys directory to the /initramfs/root/sys from initramfs (in our actual rootfs).
• It moves the /proc directory to the /initramfs/root/proc directory.
• It calls run-init to execute the actual init in our actual rootfs reside in the /root directory. run-init implements something, i.e., chroot to the actual rootfs and then runs the init reside in the /bin or /sbin/ directories or whatever user claimed as the boot parameter.

If something doesn't go well while mounting our rootfs, then a recovery task is tried out and when it also fails then a console is illustrated to the user for intervention (manual).

Several packages determine where their scripts must go. But every script that is essential to mount our rootfs require to essentially reside in {init-top, init-premount, boot-top, boot-premount}

The packages generally have more than one script which requires to be run at the booting time. These multiple scripts generally have an order of sequence that requires to be followed.

For example, say that a P package contains two S1 and S2 scripts to be run at the booting time for system configuration. S1 requires to be run after S2 and before root could be mounted- when say S1 and S2 support in configuring a root device. Hence, then S1 can be kept inside init-top when it doesn't rely on anything else and S2 can be kept inside init-premount when it doesn't rely on anything else other than the S1 script.

There are no other limitations on where we can keep our scripts other than this common thumb rule.

It implies that several scripts from distinct packages in a similar dir like init-premount _may_be irrelevant to each other in the running sequence. Hence, they can be run parallelly. It is what we decide for exploiting within the event-based initramfs.

Important: The scripts in a similar directory can also be related to each other.

The sequence is determined by a file which is known as "order" resided in that dir. There can be scripts in distinct directories which are irrelevant in terms of execution sequence and they can be run in parallel as well. We need to recognize these scripts.

The only aim of an initramfs is for mounting the root file system. It is a complete collection of directories that we would see on a general root file system. It's bundled into one cpio archive and shrank with one of many compression algorithms.

The boot loader can load the kernel and the image of initramfs into memory and begins the kernel at the boot time. The kernel will check for the existence of the initramfs and, when seen, mount it as / and executes /init. Typically, the init program is a shell script.

Important: The process of boot takes longer, significantly possibly longer, when an initramfs is applied.

The modules of the kernel are the largest reason to include initramfs for almost all distributions. In a normal distribution, there are several unknowns like disk layouts and filesystem types. In a way, it is the LFS opposite in which the system layout and capabilities are known and the kernel is built normally. In this situation, the initramfs is needed rarely.

There are just four main reasons to include an initramfs within the environment of LFS: loading the rootfs from the LVM logical volume, loading it through a network, including an encrypted rootfs in which a password is needed, or for the comfort of describing the rootfs as a UUID or LABEL. Anything else means that a kernel wasn't properly configured.

Installing busybox-initramfs in Ubuntu 20.04

In this article, we will learn how we can install busybox-initramfs in the 20.04 version of Ubuntu. busybox-initramfs is a standalone shell setup for standalone shell setup of initramfs.

Introduction to busybox-initramfs

Busybox associates tiny versions of several common utilities of UNIX into one small executable. It offers minimalist substitutes for the most basic utilities we would usually see on our desktop system (i.e., tar, mount, mv, cp, ls, etc.).

In Busybox, the utilities generally have lesser options as compared to their full-featured cousins of GNU. Although, the options that are added offer good functionality and act very much like their counterparts of GNU. Busybox-initramfs offers a common standalone shell that gives only the common utilities required for the initramfs.

Installing busybox-initramfs with apt-get

We need to update the database of apt with the help of apt-get. We can use the following command:

After updating the database of apt, we can now install busybox-initramfs with apt-get by executing the below command:

Installing busybox-initramfs with apt

We need to update the database of apt with the help of apt. We can use the following command:

After updating the database of apt, we can now install busybox-initramfs with apt by executing the below command:

How do we start Ubuntu using initramfs?

We may encounter several problems not properly restarting the OS is one of them while using our computer. There are several solutions for solving booting issues, a few can get quickly be repaired, and for a few, we require reinstalling the whole operating system.

Also, Ubuntu may greet us with the same issues, and the "initramfs" issue is one of them. It's a booting issue of Ubuntu and appears due to bad sectors and bad blocks inside the memory which don't permit OS boot.

Our system includes several essential files, so a problem like this can be a bit distressing. But we do not need to worry because this write-up concentrates on how to resolve the "initramfs" problem and normally boot Ubuntu. So, let's start:

How to resolve the "initramfs" problem in Ubuntu?

We are already in recovery mode which means that we can enter commands and implement different operations if our screen shows an "initramfs" error. We can enter "exit" for getting the information of the error.

Important: We may not receive the information of the error all time we enter "exit".

Initramfs error appears when our start-up disk gets infected as discussed above. We may have more than one disk attached to see them, we can use the following command:

Or

The partitions can be checked by the name of /dev/sdb, /dev/sda, or any other. For fixing the "initramfs" issue, we will use a utility, i.e., "fsck" which is also called "file system consistency check". It will check the issues of the file system and fixes them. We need to follow the syntax which is mentioned below:

For example, if any partition is by the /dev/sdb name, then the command will be as follows:

Click on the "Enter" button, the command will eliminate all bad sectors through memory automatically. Click "y" under getting prompt. We can simply consider the "-y" option along with the command for preventing the prompts:

If we have more than one partition, we can inspect them with the help of the command which is mentioned above. The command will not anything print if the partition is free from bad sectors. The system will now take some time for analyzing and repairing the infected portion of our memory. We need to type the following command once it's done:

We can enter "exit" if a reboot doesn't work. Here we go, the problem has been erased and Ubuntu will normally be booted.