If your laptop/PC/virtual machine running Linux is booting straight to BIOS, it might indicate there’s something wrong with your boot partition (/boot). In this post I’m going to learn you a thing or two about fixing said /boot partition and recovering a broken Linux system.
Before we start, let me say just one thing – no all steps are necessary for all boot issues; think about applying any of them.
Rescuing the Penguin
- To begin, create a Linux Live CD or USB. To do that, download a iso containing Linux Live OS (ArchLinux, Ubunutu, Fedora Workstation – all of these are capable of live boot). You can create Live USB stick using Rufus on Windows or dd command on Linux/MacOS. In case of a VM, attach the Arch/Ubuntu/Fedora iso file to its Disk Drive.
- Plug your Live USB/CD into the affected machine and select it as a boot device in BIOS/UEFI.
- Once you’re in, connect to the network and open up terminal (if you’re using a distro with GUI). On non-GUI distros (Arch), you can use
wifi-menucommand to connect to a Wi-Fi network. IN Arch’s case, remember to run
dhcpcdto get the IP configuration from DHCP or configure a static IP address and default route with
- Now we need to mount the OS with the broken
/bootpartition on our Live OS. To do that, firstly we need to figure out the partitioning of the OS in question.
fdisk -lto view all the drives and partitions detected by the Live OS (if your not logged in as root, remember to add
sudoswitch before the command:
sudo fdisk -l); the output will look similar to this:
Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 4BEA7577-501A-43AC-A861-4C4CF6FC4EB3
Device Start End Sectors Size Type
/dev/sda1 2048 2099199 2097152 1G EFI System
/dev/sda2 2099200 211814399 209715200 100G Linux filesystem
/dev/sda3 211814400 421529599 209715200 100G Linux filesystem
/dev/sda4 421529600 466593791 45064192 21.5G Linux filesystem
/dev/sda5 466593792 500118158 33524367 16G Linux swap
Let’s break it down: on this file system we’ve got a drive called sda with 5 partitions: sda1, sda2, sda3, sda4 & sda5. As I’ve installed this system myself, I know exactly what part of the OS is on which partition:
If you are unsure what’s on each partition on your disk, you can try mounting them individually to
sudo mount /dev/sda1 /mnt) and then browsing the
There are some simple rules how to identify different partitions:
– if the partition contains only files such as
linux.img.cnfand folders such as
linux– it’s probably a
– if the partition contains folders such as
varetc. – it’s the
– if the partition contains folders named after the existing users (
user2etc.) – it’s more than likely it’s
– if the partition contains strange folders and files (with even stranger extensions) – it’s
– if you won’t be able to browse the partition – it’s
Once you know how your partition scheme looks like, we can get to mounting.
- Firstly, mount the root partition to
/mnt. In my example, the command for this is:
mount /dev/sda2 /mnt
- Then, proceed with mounting other partitions. In my example, I had to run the following (order doesn’t matter after mounting
mount /dev/sda1 /mnt/boot
mount /dev/sda3 /mnt/home
mount /dev/sda4 /mnt/var
- As you’ve probably noticed, we do not monut the
/swappartition during the recovery process. Do not try to do that.
- Firstly, mount the root partition to
Bringing the broken OS back life
- Having all the partitions mounted, we can chroot into the broken OS. Chrooting basically changes the default location for the Live CDs root user, which makes the whole recovery process much easier. You can imagine chrooting as “logging in” to the broken OS without actually booting it.
- Now comes the real fixing phase. When I’m troubleshooting broken
/bootpartitions on Linux boxes, I like to re-install kernel just in case there’s something broken and update the system. In most distributions this can be easily done with the package manager. In my (Arch) example this command is:
pacman -Syu linux
- After reinstalling the kernel and updating the system, we can focus now on the boot loader. In my opinion, easy solutions are always better than the hard ones, so we are going with the easy route here as well.
Re-grubbing the GRUB
- Booting a Linux system is usually done through a boot loader and on most Linux boxes the boot loader in use is GRUB2. We will begin the troubleshooting by re-installing it (substitute
pacman -Swith your package manager of choice):
pacman -S grub
- Next, we need to run
grub-installcommand. This will perform some initial GRUB configuration on the
/bootpartition. Don’t worry if you had GRUB installed before – all the settings will be overwritten.
BIOS based systems:
grub-install --target=i386-pc /dev/sda
UEFI based systems:
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
- Lastly, we can run the GRUB auto-configuration command; it will scan the whole disk drive looking for potential OS’es and create boot records for them. In 99 out of 100 Linux systems, there’s nothing else you need to do.
grub-mkconfig -o /boot/grub/grub.cfg
There we go – you’ve learned something today. You can now safely reboot the Linux box and disconnect the Live Linux media; your system should boot up ok now.
Read all other the posts of the "Quickie" series in the archive