22nd August 2018 3:27 am
Broken Bootloaders and Occam's Razor
From Wikipedia:
Occam’s razor is the problem-solving principle that the simplest solution tends to be the right one.
My PC has a dualboot with 2 Operating Systems, Linux Mint and Windows 10. These two love to bicker and fight when it comes to booting the PC, such as Safe Boot in the BIOS favoring the Windows bootloader over GRUB or otherwise trying to override a Linux liveboot. Even so, I still keep it this way. Linux is for work, professional and personal, and Windows is for play (and any work that can’t be done on Linux).
So the input of the commodore 64 perceptron was put off today for a little computer fixing time, these OSes at each other’s throats again. A few days ago a brown-out occured in the house, shutting off my PC. The thing is a monster that I built myself, but its software can sometimes be a jenga tower ready to topple over.
When I turned my PC back on I found GRUB in shambles. That is to say it couldn’t find, well, itself. So instead of giving me a handy list of loaders to choose from it just went straight to GRUB Rescue, a black screen/white text shell some people have the gall to call ‘powerful’. No, the rescue terminal is no BASH, not by a long shot.
This wasn’t the first time I’ve seen this screen. When I first built my PC this happened when I tried to load into the old Mint 17 I already had installed on my C Drive. I had to manually start up the GRUB menu from the rescue terminal in order to get into Linux to make sure everything was in order. Unfortunately, this time it wasn’t so simple.
Trying to do what I did before I hit hurdle after hurdle. First, all my drives were unknown filesystems, meaning I had to comb through the lot of the drives to find the one where my Linux was hiding. From there I had to set up the root and tell GRUB where normal.mod was. Except it kept trying to look for normal in /boot/grub/i386/.
This was confusing consider I had a 64 bit machine, x86, not a 32 bit one. In fact, I could even ls my way into /boot/grub/ to find normal.mod hiding in a folder called /x86_64-efi/. So the file was there but grub was, for some reason, looking in the wrong spot.
Combing through the internet, I began a tangled web of trying to fix this issue. I created a liveUSB of Linux Mint so I could use the terminal to reinstall grub but I needed to mount my C drive to the /mnt/ folder in root but it’d claim to not be able to find a file at a specific location despite the fact I had a file explorer open and I was staring right at the file it said it couldn’t find right where it said it couldn’t find it.
In my mad scramble for a solution to this increasingly maddening problem, I stumbled across a very short post in response to someone else tangled in the web of chaos that was GRUB messing up:
Easier just to use Boot-Repair. Boot Repair -Also handles LVM, GPT, separate /boot and UEFI dual boot.: https://help.ubuntu.com/community/Boot-Repair
As it turns out, a tool called Boot Repair existed. You could load up the iso into a USB stick like a Linux liveboot, and it even had a cute little mini-desktop where you could check your drives before running a two-click wizard that instantly fixed it.
I rebooted and everything worked. GRUB menu worked just fine, both OSes boot a-okay.
Terminals and file crawling and errors that make no sense while combing through forum post after forum post…
versus a USBstick and two clicks.
Occam’s Razor holds true, as it turns out. It’s just a shame it also makes me feel like a proper idiot.
~Nicko
