sahinakkaya.dev/_posts/2022-03-03-never-get-trapped-in-grub-rescue-again.md

70 lines
5.7 KiB
Markdown
Raw Normal View History

---
title: "Never Get Trapped in Grub Rescue Again!"
date: 2022-03-03 03:46:00 +0300
2024-08-04 20:13:42 +02:00
classes: wide
tags: linux grub partition uefi
---
Anytime I install a new system on my machine, I pray God for nothing bad happens. But it usually happens. When I reboot, I find myself in the "Grub rescue" menu and I don't know how to fix things from that point.
I go into the live environment and run some random commands that I found on the internet and hope for the best.
![me trying to fix grub](/assets/images/grub-rescue/random-bullshit.jpg)
What a nice way to shoot myself in the foot! But this time is different. This time, I f\*cked up so much that even the random commands on the internet could not help me. I was on my own and I needed to figure out what is wrong with my system. Let me tell you what I did:
I decided to install another OS just to try it in a real machine. I wanted to shrink one of my partitions to create a space for the new system. I run `fdisk /dev/sdb`, the very first message that it tells me was
> `This disk is currently in use - repartitioning is probably a bad idea. It's recommended to umount all file systems, and swapoff all swap partitions on this disk.`
Yes, it just screams ***"Do not do it!"*** but come on. I will not try to shrink the partition I am using (`sdb3`). So it should not be a problem. I ignored the message and shrink it anyway. No problem. Installed and tested the new OS a little bit. Time to reboot and hope for the best. And of course it did not boot. What would I even expecting?
![ah sh\*t here we go again](/assets/images/grub-rescue/cj.png)
As always, I booted into a live environment and run `boot-repair` command. It was always working but this time... Even after finishing the operation successfully I could not boot into neither Arch nor Ubuntu (the two systems I had previously).
2022-03-03 18:10:16 +01:00
Arch was originally mounted in `sdb3` and Ubuntu was in `sda2`. Considering the fact that I only messed with `sdb`, I should be able to boot Ubuntu, right? Well, yeah. Technically I did boot into Ubuntu but I didn't see the login screen. It was dropping me into something called *"Emergency mode"* which just makes me panic! `sudo update-grub`... Nope. Nothing changes. Arch does not boot and Ubuntu partially boots.
Let me tell you what the problem was and how my ignorance made it worse:
2022-03-03 18:10:16 +01:00
- While installing the new system, I saw a partition **labelled** *"Microsoft Basic Data"*. I deleted it thinking it is not required because I don't use W\*ndows. It turns out, it was my *boot* partition for Arch, just labelled incorrectly... Big lolz :D But we will see this is not even important because I had to rewrite my boot partition anyway.
- My Arch was installed in `sdb3`. When I created a new partition and installed the new system, `sdb3` was shifted to `sdb5` even though I did not ask for it. But the grub configuration to boot my system was still pointing to `sdb3`. That was the reason why Arch does not boot. It was trying to boot from `sdb3`. So I had to recreate grub configuration and reinstall grub to fix it. I run the following commands that I found [here](https://www.jeremymorgan.com/tutorials/linux/how-to-reinstall-boot-loader-arch-linux/) in a live Arch environment:
```bash
mkdir /mnt/arch
mount -t auto /dev/sdb5 /mnt/arch
arch-chroot /mnt/arch
mount -t auto /dev/sdb4 /boot/efi
os-prober
grub-mkconfig > /boot/grub/grub.cfg
grub-install --efi-directory=/boot/efi --target=x86_64-efi /dev/sdb
exit
reboot
```
And it fixed my grub. I can now boot into Arch, hooray!
- Ubuntu was not still booting properly. I checked the logs with `journalctl -xb` and saw something related with `sdb`. Ubuntu was installed in `sda2`, why `sdb` should be a problem? Then I remembered something. Back in times when I was using Ubuntu, I was using `sdb1` as a secondary storage. So I had a configuration where it automatically mounts `sdb1` on startup. Since I messed with `sdb1` , it was failing to mount it. I opened `/etc/fstab`, and deleted the related line. Bingo! It started booting properly.
![i am something of a hackerman myself](/assets/images/grub-rescue/hackerman.jpg)
- I started feeling like Hackerman, and I said to myself *"You know what, Imma fix everything."* I had a very sh\*tty grub menu with useless grub entries from old systems that I don't use anymore. The UEFI also had the same problem. It had ridiculous amount of boot entries that most of them are just trash.
![the pictures i took while trying to figure out which boot options are useless](/assets/images/grub-rescue/shitty-uefi.jpg)
These are the pictures I took for reference while trying to figure out which boot options are useless. Sorry for the bad quality. I didn't think I would use them in a blog post.
2022-03-03 18:10:16 +01:00
- While trying to fix the previous problems, I've spent enough time in the `/boot/efi` directory that make me understand where these grub entries are coming from. There were a lot of files belong to old systems. I simply deleted them and updated grub. All of the bad entries were gone. I want to draw your attention here: *I did not search for how to delete the unused grub entries. I just knew deleting their directories from `/boot/efi` will do the job. I am doing this sh\*t! (Another hackerman moment :D )*
- In order to delete useless boot options from UEFI menu, I used `efibootmgr`. I searched for it on the internet, of course!
```bash
efibootmgr -v # Check which entries you want to delete, say it is 0003.
sudo efibootmgr -b 0003 -B # This will delete third boot option.
```
And finally! I know everything about how all these work. Another shady part of Linux is clear for me. Now:
![Give me a ruined computer and an Arch ISO, and I shall fix it for you.](/assets/images/grub-rescue/quote.jpg)