Ubuntu/Mint/Kali Boots to Initramfs Promp in BusyBox

In this text we’ll present how to resolve issues that happen when a pc working Linux Ubuntu/Mint/Kali doesn’t boot or drops to a busybox immediate through the initramfs initialization. The consumer can entry and use solely the initramfs command immediate.

Initramfs is the preliminary tmpfs-based file system in the RAM that doesn’t use a separate block gadget. Like the initrd, it incorporates instruments and scripts to mount file methods prior to calling init positioned in the foundation file system.

Ubuntu Linux boots to BusyBox initramfs prompt

Repairing a damaged Ext4 Superblock in LInux

If Ubuntu crashes right into a busybox through the initramfs initialization, there could also be a broken superblock on the disk.

everal superblock copies are stored in Linux. To recuperate a system in case this drawback happens, you want to boot from the rescue picture/disk/Live CD and run the terminal immediate. After booting, enter the next command in the terminal:

# sudo fdisk -l|grep Linux|grep -Ev 'swap'

The command returns the details about your quantity:

/dev/vda2 4096 83884031 83879936 40G Linux filesystem

Remember the quantity identify and specify it in the next command:

# sudo dumpe2fs /dev/vda2 | grep superblock

The command will present the checklist of backup superblocks:

dumpe2fs get backup superblock

We will use the second backup superblock to substitute the broken one (you should use any superblock besides Primary). Check the disk utilizing the backup superblock:

# sudo fsck -b 98304 /dev/vda2 -y

If you get this output:

fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
/dev/vda2 is mounted.
e2fsck: Cannot proceed, aborting

Unmount the quantity:

# umount /dev/vda2

After efficiently changing the superblock, you’re going to get a message like this:

fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
/dev/vda2 was not cleanly unmounted, test pressured.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking listing construction
Pass three: Checking listing connectivity
Pass Four: Checking reference counts
Pass 5: Checking group abstract data
Free blocks depend mistaken for group #231 (32254, counted=32253).
Fix? sure
Free blocks depend mistaken for group #352 (32254, counted=32248).
Fix? sure
Free blocks depend mistaken for group #358 (32254, counted=27774).
Fix? sure
/dev/vda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vda2: 85986/905464576 information (Zero.2% non-contiguous), 3904682/905464576 blocks

Then unmount the boot media and restart your pc. Everything ought to work correctly.

Fsck Boot Error: Unexpected Inconsistency

The second variant of the initramfs (BusyBox) subject consists of the next message in the terminal window:

The root filesystem on /dev/sda1 requires a guide fsck.

linux busybox UNEXPECTED INCONSISTENCY, filesystem /dev/sda1 requires a manual fsck

If you don’t see it, attempt to enter (initramfs) exit in the terminal window. The error might seem after you do it…

The message will present a quantity that that requires working a guide disk test. Run the next command in the initramfs immediate:
# fsck /dev/sda1 -y
After the disk test is over, restart your pc and ensure that Linux boots accurately.

Alert!  /dev/quantity Does Not Exist

Fstab Issue

You can see the next error when booting the Linux host:

ALERT! /dev/sda1 doesn't exist. Dropping to a shell.

busybox initramfs /dev/sda1 does not exist. Dropping to a shell

You might have simply put in your Linux or your host has some fstab issues. The most frequently the issue happens when a system is put in from a USB drive. The system might present an error of any quantity. Like in the primary case, we’ve to boot from the rescue/boor Linux media and do some actions. Check the disk UUID utilizing this command:
# sudo blkid

The system will return one thing like this:

/dev/sda2: UUID="36cce3d5-cbdb-46f4-adbf-3f9aaa01d729" TYPE="ext4" PARTUUID="fea4dab1-4e12-4327-85c6-76ade18f64e1"

Here we see that the system should boot from sda2, however truly it tries to boot from sda1.

Mount the quantity to any listing, for instance:

# sudo mount /dev/sda2 /mnt

When you see /dev/sda2 in the /mnt listing, discover the file /and so on/fstab there and modify the road containing /dev/sda1 as follows:

UUID=36cce3d5-cbdb-46f4-adbf-3f9aaa01d729 / ext4 errors=remount-rw Zero 1

Save the file. Unmount the quantity from /mnt and reboot. If the issue was associated to the mistaken quantity identify, the server would boot.

Also, you possibly can resolve this drawback by booting in the emergency mode. Remount the foundation listing as learn/write:
# sudo mount -o remount,rw /
Then change fstab and restart the server.

Hardware Problem

On some motherboards, SATA ports might get random numbers. It might also trigger the error described in the earlier part. To repair it, it’s essential to edit the grub bootloader.

Boot in the emergency mode or from a Live CD and edit the /boot/grub/grub.cfg file.

In the road that determines the boot quantity, for instance:

Linux /boot/vmlinuz-Four.15.Zero-70-generic root=/dev/sda1 rw quiet elevator=noop fsck.restore=sure

Replace the trail to the disk by its UUID:

Linux /boot/vmlinuz-Four.15.Zero-70-generic root=UUID=36cce3d5-cbdb-46f4-adbf-3f9aaa01d729 ro quiet elevator=noop fsck.restore=sure

grub.cfg replace volume name to UUID

Check Also

How to Use Native SSH Client in Windows 10?

The built-in SSH shopper appeared in Windows 10 and Windows Server 2019. Ssh.exe can be …

Leave a Reply

Your email address will not be published. Required fields are marked *