I have used grub-customizer for quite a while, but I understand it is “poison” if you manage to install it on Manjaro. So, I asked myself, what else may I do as a replacement? We children don’t like having our toys taken away without a replacement (hopefully better) toy.
So I looked at this article and it talked about using manjaro-chroot instead of the vanilla chroot. But I got this:
# manjaro-chroot /mnt /bin/bash
-bash: manjaro-chroot: command not found
Thinking this article couldn’t be that old or off base, I searched for it:
pacman -S manjaro-chroot
error: target not found: manjaro-chroot
Any of you fine folks help me out with this one? Or is the article due for revision?
I did, the article is the closest thing I found to “what we propose you do if a tool you had used (grub-customizer) is suddenly yanked away because it was breaking our installations.” This was a year ago it was removed from the repos and the article walks you through the steps required to do WITHOUT grub-customizer. They are fairly clear steps, written fairly clearly, but include two stoppers and the article could mention the resolution for people that have used grub-customizer in the past. I am still searching for a better explanation as to why grub-customizer actually breaks Manjaro, often things like that hark back to incomplete or fuzzy documentation. Seen it before, seen it at RedHat, seen it at Microsoft (especially common), and I understand why this happens in GNUPL environments. Technical people aren’t always the best technical writers; it’s unfortunate but true.
ouch. Thank you for the manpage, do you have a better answer to the question “Why does grub-customizer break (only) Manjaro grub?” Or is your life too consumed with pointing out what you consider rookie mistakes? I have used ubuntu for a few years, only recently tried out Manjaro, and … well, was wondering what happened to a tool I used fairly regularly in the “U”-niverse. Guess I will read on though. Bad assumption that manjaro-chroot was needed because grub-customizer wasn’t available.
So maybe you could handle an additional question: why do we need to chroot when doing a clean grub-install? And although I checked, not totally sure I understand what manjaro-chroot does that chroot doesn’t (doc I cited mentioned something about scanning for other OSes (which update-grub does?).
It doesnt…it breaks lots of grubs. Its a terrible tool.
Huh? What is with the attitude?
In some cases to gain access to a system when grub-customizer [or anything else] broke it so extremely that you cannot access the system by normal means.
(you boot from another system, chroot into the broken one to fix things)
Automates the process so that the instruction to an end user is pretty much manjaro-chroot instead of all of this:
root # mount /dev/sdyC /mnt
With a BTRFS filesystem, you should note that the subvolumes must be mounted. That would be in such a case:
root # mount -o subvol=@ /dev/sdyC /mnt
Then - if applicable - mount boot
root # mount /dev/sdyB /mnt/boot
Then - if applicable - mount efi
root # mount /dev/sdyA /mnt/boot/efi
Create the chroot environment and use bash as shell
root # manjaro-chroot /mnt /bin/bash
Thank you for the very comprehensive reply. No offense meant on the thing about the rookie, I was just pointing out that I’ve been using grub customizer more years than I care to remember, being a) lazy and b) from the world of windows. Although no stranger to non GUI world, a lot depends on the accuracy of Man pages and other supporting documentation such as web pages, clearly the user Community is a huge element for learning ‘the ancient art of doing things in Linux’, which seems to rely a lot on complete comprehension of five or six individual Man pages, and someone intelligent enough to put that information together. I’m going to look into the possibility of contributing to the Wiki page around manjaro-chroot and around grub customizer and why it was redacted. Thanks for the valuable input!
Great reading, grab a popcorn and a decaf indeed! There is some confusion in my mind (I am always playing with dual/triple/quad boot) with Windows being the “sacred cow.” Like anything though, if you have good backups of everything you care about and don’t mind reinstalling … Anyway, there’s a machine that I almost tossed on the recycle bin, ASUS T100HA mini-transformer, that I decided to use as a sacrificial test lab. It does have a USB 3.1 port, so I confined most of my boot/grub testing to a cheap ($20) USB 3.2 pen drive with 128 GB; actually boots faster in all than the mmcblk0 device soldered on and has twice the storage. I then shrank the mmcblk0 device from within Windows yielding 20 GB of free space and went looking for the smallest footprint OS, landed on Manjaro XFCE (second to Lubuntu but I wanted to try Arch).
What I was noticing, it isn’t just the folders under EFI/ or efi/ that you see when you hold down the Esc key on this T100; there are also numerous EFI partitions that seem to be stored in Firmware. In Windows, you run bcdedit /enum firmware, compare that with bcdedit /enum and now you see that some boot managers can read the firmware, and some can only read the efi boot sectors selected from the ‘device selection’ screen or pre-boot. Only way I have found to clean out the firmware was with the Windows 10 installation media. Boot Repair from that media seems to fail 90% of the time, but a “clean install” meaning wipe out all partitions, leaves a 100MB (waaay too small for modern Linuxes) EFI partition, but it does seem to have the capacity to zero out all firmware entries at the same time. Any way to do this in an all-Linux environment?