How to Unwind Grub Customizer

[pbear]

Recently, I set up a multi-boot test box in VirtualBox to test boot tools. As already had set up, decided to give Grub Customizer a whirl, both to see how well it works and how difficult to unwind, the latter being a complaint sometimes lodged in threads about the app. Short answer: Pretty cool app. Not brain surgery to unwind, but more difficult than it ought to be. Helps if you know what to look for. That's where this tutorial comes in.

Installation. After years of user requests, Grub Customizer was added to the Ubuntu repo as of 19.10. Included with 20.04, so presumably will be available for Mint 20. Meanwhile, can install from PPA: ppa:danielrichter2007/grub-customizer. Easy-peasy.

Backup files. Mentioning second, but before installing GC, I took the precaution of backing up etc/default/grub and the /etc/grub.d sub-directory. The former is the main user configuration file, the latter has the scripts update-grub uses to assemble grub.cfg, which is the file used at boot to create the menu. I put the backup in /root (the home folder of user root), but it could have gone anywhere, including a USB drive. Main thing I wanted was a backup stored someplace other than the /etc/grub.d folder. Cheap insurance, I recommend doing it.

Customize Grub. The test box I used has four OSs: Win10, Mate 19.1, Ubuntu 20.04 and MX Linux 19.. To give the app something to do, move Windows to top of list, correct Mate's name (called Ubuntu by scripts), default boot = last-system-used, disable auto-boot, and set a picture. Click Save. Reboot, yup, there's my menu, no countdown. Kinda hard to read, though (because of the picture); edit to use magenta for selection, with white background (masks the picture), then dark grey for the rest of the list; save and reboot. Nice menu. Most of this can be done manually, but a lot easier with GC (and changing boot order is pretty difficult otherwise).* No wonder GC is popular.

* Can be done with a custom.cfg or 40_custom file (see tutorial), but not something most newbies are going to want to tackle.

What happens at file level. Now let's look under the hood. What is GC doing? Need to know, so if uninstall, we can restore the original system (or be confident it has been restored). This is what /etc/grub/d looks like by default, i.e., before installing GC:

Code: Select all

00_header  05_debian_theme  10_linux  20_linux_xen  20_memtest86+  30_os-prober  30_uefi-firmware  40_custom  41_custom  README

After installing GC and making the customizations above, /etc/grub.d looks like this. Per FAQ, GC relies on proxy scripts for many functions. The original scripts are saved in a backup folder, as is etc/default/grub, the entire /boot/grub directory and a few other files.

Code: Select all

00_header        10_linux_proxy      31_linux_proxy  33_memtest86+_proxy  35_memtest86+_proxy  37_uefi-firmware  41_custom  bin               README
05_debian_theme  30_os-prober_proxy  32_linux_xen    34_os-prober_proxy   36_os-prober_proxy   40_custom         backup     proxifiedScripts

If you're familiar with the Linux file system, that's not particularly complicated or difficult to understand. Instead of eight standard scripts, I now have thirteen, most of which are GC's proxy scripts. Notice the sub-folders bin, backup and proxifiedScripts. Here's what's in those:

Code: Select all

/etc/grub.d/bin:
grubcfg_proxy

/etc/grub.d/proxifiedScripts:
linux  memtest86+  os-prober

/etc/grub.d/backup:
boot_grub  default_grub  etc_grub_d  RESTORE_INSTRUCTIONS

/etc/grub.d/backup/boot_grub:
fonts  gfxblacklist.txt  grub.cfg  grubenv  i386-pc  locale  unicode.pf2

/etc/grub.d/backup/boot_grub/fonts:
unicode.pf2

/etc/grub.d/backup/boot_grub/i386-pc:
[omitted, same *.mod files, etc. as usual]

/etc/grub.d/backup/boot_grub/locale:
en_AU.mo  en_CA.mo  en_GB.mo  en@quot.mo

/etc/grub.d/backup/etc_grub_d:
00_header  05_debian_theme  10_linux  20_linux_xen  20_memtest86+  30_os-prober  30_uefi-firmware  40_custom  41_custom  README

Pretty tame, eh? And, makes even more sense if you're looking at it in File Manager.

Unwind and Uninstall. Suppose I want to uninstall GC. The website is vague on how to handle this and while there is a file in the backup folder called Restore Instructions, it's only six lines long. Common sense says to me, the first step is to revert the Grub menu. That's an option on the Edit menu; also a prominent button on the main dialogue box. As with all changes in GC, only takes effect when saved. Checking /etc/grub.d, I see the proxy scripts have disappeared and the original scripts restored. Makes me feel better. Go ahead and uninstall, apt purge grub-customizer. Reboot.

First thing I notice is that my picture is still on the menu. Turns out this didn't get reverted. Indeed, the original etc/default/grub file wasn't restored. Copy available in the backup folder, so no good reason, just an oversight. Copy the backup to /etc/default and run sudo update-grub. Reboot. Back to pre-GC. Still stuff left behind, especially the backup folder in /etc/grub.d. Delete that manually. Only other holdover file I see is /boot/grub/grubenv, which sets the environment block. Harmless, I leave it alone. All things considered, not as clean an unwind as one would like, but not bad.

Manual Unwind. An important limitation on my test is that I only ran GC once, then more-or-less immediately uninstalled. It's a test box. Where folks report trouble is when using for an extended period of time, through numerous kernel updates and so on. Suppose GC has stopped working. What does one need to do to get back to pre-GC? The backup folder has a file called Restore Instructions. All it says, though, is to restore /etc/default/grub and the original scripts in /etc/grub.d. Both necessary steps, of course, but there's more to it than that. Moreover, instructions say to use gksu, which was deprecated in Ubuntu 18.04, more than two years ago. No mention of deleting the proxy scripts. No mention of update-grub. Worst of all, overlooks that the backup copies of the grub scripts have had their executable flag removed, so they no longer work when restored. Feeble.

I doubt many users in the app's target audience would have any idea how to fix this. These commands, run in Terminal, worked for me:

Code: Select all

apt purge grub-customizer
sudo cp /etc/default/grub /etc/default/grub-customizer
sudo cp /boot/grub/grub.cfg /boot/grub-customizer.cfg
sudo cp /etc/grub.d/backup/default_grub /etc/default/grub
sudo mkdir /etc/temp
sudo cp /etc/grub.d/backup/etc_grub_d/* /etc/temp
sudo rm -r /etc/grub.d/*
sudo cp /etc/temp/* /etc/grub.d/
sudo chmod +x /etc/grub.d/*
sudo rm -r /etc/temp
sudo update-grub

Second and third lines save copies of those two files for reference. The rest restores the original files, then deletes the backups and updates Grub. FYI, I was able to restore my test box with these commands, but can't promise they work in all cases, as I tested only one. If you made backup copies of the original files as suggested above and restore those, that should be pretty much foolproof.

Purge and reinstall Grub. Suppose it's worse than that. Not only has GC stopped working, so has update-grub. Probably doesn't happen often, but know of at least two cases reported on the Forum. Now we have to pull out an advanced tool: purge and reinstall of Grub. See Ubuntu Help. Relatively easy to do, provided you're still able to boot. Exact steps depend on whether using BIOS or UEFI. If not sure, run ls /sys/firmware (those are "Ls"); will report three words or four; if one of them is efi, you're in UEFI, if not you're in BIOS or legacy mode.

BIOS instructions. Run apt purge grub-common; will be prompted to confirm removal of boot loader. Then run apt install grub-pc os-prober. Select destination for boot loader when prompted (tap space key to select). Unless you have a very good reason, install to the device, not the root partition.

os-prober us removed by purge but only a recommended package on reinstall, so specifying additionally. Same with shim-signed for UEFI.

UEFI instructions. Similar, but the packages to install are a little different. Run apt purge grub-common, then apt install grub-efi-amd64-signed os-prober shim-signed. Select destination for boot loader if prompted (but probably won't be).

If all else fails, chroot. This is rare. Indeed, I've only heard of one case. OTOH, not all problems get reported on the Forum and I don't notice all that are. Suppose you can't even boot. Ooh, maybe have to reinstall. Probably not. Again, have to know whether using BIOS or UEFI. If you have a boot partition (why?), that also has to be mounted (sudo mount /dev/sdxn /mnt/boot); add as a second step for BIOS, a third step for UEFI. If not familiar with chroot, just cross your fingers and follow the steps (use copy-and-paste). It's this or reinstall, so might as well give it a shot. Start by booting a live session of the same version of Mint as is installed on the system; set up an internet connection, open Firefox, and open this thread for reference.

BIOS. For illustration, assume system partition is sda1. Modify if yours is different. As with regular purge-and-reinstall, you'll be prompted at some point to confirm the boot loader should be removed, and also where to install the new one.

Code: Select all

sudo mount /dev/sda1 /mnt
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
sudo cp /etc/resolv.conf /mnt/etc
sudo chroot /mnt
apt purge grub-common
apt install grub-pc os-prober
exit
sudo umount -R /mnt

UEFI. For illustration, assume system partition is sda2 and the EFI partition is sda1. In a dual boot system with Windows, those might be sda5 and sda2.

Code: Select all

sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
sudo cp /etc/resolv.conf /mnt/etc
modprobe efivars
sudo chroot /mnt
apt purge grub-common
apt install grub-efi-amd64-signed os-prober shim-signed
exit
sudo umount /mnt/boot/efi 
sudo umount -R /mnt

Closing. The tutorial ended up being longer than expected. Notice there are four separate solutions, for progressively more difficult cases. Most people should be fine with the simplest solution: Revert the Grub menu before uninstalling Customizer, then clean up a few loose ends. Done.

[Pjotr]

Interesting; thanks for taking the time to investigate and report. I'm sure that this clearly written tutorial will come in handy occasionally, for victims of Grub Customizer.

Just one qualification I disagree with: I most certainly don't find it a "pretty cool app".

The main problem with Grub Customizer in a nutshell: as long as it works as expected, all is fine.

But when there is a problem, removing it and trying to boot without it can create big difficulties. Even though your tutorial will probably be a big help for solving those difficulties.

That's the downside of the thick layer of complexity that Grub Customizer adds. And for what? For a few things, most of which are non-essential, that can usually also be done without adding a thick layer of complexity....

Grub Customizer may look easy and nifty, but can mess up a vital part of your operating system. Your bootloader is as vital as it gets: after all, a system that won't boot any more, is useless.

[darbydoo]

Thx for this excellent tutorial, worked great

[Moem]

The question about this subject by Scy can now be found here: viewtopic.php?f=42&t=371296
As stated at the top of the page, please don't add support questions to tutorials. Thanks!