Using livecd v17.0.1 (and above) as grub to boot OS with broken bootloader

It will be worse to people on UEFI.

But see this website on bios-legacy.
Need to put in /etc/default/grub
GRUB_ENABLE_BLSCFG=false
and then
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

As for UEFI, and as I mentioned earlier,
there is another grub.cfg generated in $esp and moving all the grub and kernel things to it.
I suspect that as Fedora is moving people towards systemd-boot, they are making those using grub towards having kernels and grub to its $esp and later on make that /boot rather than /boot/efi, and migrate to systemd-boot.

There's nothing wrong with systemd-boot. In fact, I think it better than rEFInd, but not for multi-OS's users like you and I. With one OS, I think it is superb.

Anyway, I personally think linux OS's that mess up other linux OS's are conceited. It is not as if they are offering an alternative choice. Its okay to have their own package manager or change DE preferences but making common shared packages incompatible or broken is wrong. Like windows thinking they own our computer.

IIRC grub will copy grub.cfg to efi folder, when you install for "removable". Which answers

you might do the trick/workaround, if you re-install grub (as removable) after each update-grub.

What does that mean?

I'm on MBR boot.

For EFI systems, removable systems (on external disks) have to install a copy of grub.cfg to the external disk $ESP, IIRC. I maybe wrong, I have several memory leaks... :slightly_frowning_face:

1 Like

Several? :joy::rofl:
Welcome back, partner.
ps: I'll keep calling you petsam.

1 Like

So....not relevant to my MBR system?

Looks like I may have to grub2-mkconfig after every kernel update.

It needs to be done manually each time. F30 is my second-boot [though these days it's months between my "visits" to it coz Manjaro is just so much better to use, for me], & i can't tell you the number of times i did an F30 update, then straightaway told it to reboot, coz i am so used to Manjaro doing the mkconfig work automatically for me, then immediately realising too late that i forgot to run the command so that once it's rebooted i have to log back into it, then do the command, then reboot again... then log back into Manjaro & run update grub there in order for the new F30 kernels to appear in my Manjaro grub menu. Sigh. Manjaro has really spoiled me!

2 Likes

Thanks.

That's why you need custom grub entries that read directly the grub.cfg or core.img file of fedora or any of your other distros, without the need to regenerate Manjaro's grub whenever those other distros have kernel upgrades.

1 Like

@wongs,
I think I mentioned this, while configfile is great for people whose grub is kaput and multiboot (core.img or core.efi) is great for using that destination OS grub directly (and not kaput), my own way of booting OS's is directly booting the kernels itself. (I like simple and straight, just like my personality :smile:).

Arch, KaOS, Antergos regenerate/reuse vmlinuz-linux and initramfs-linux.img, booting these just point to these files. Others use sym-links to the root partition like vmlinuz and initrd.img so for these, I point to them. Manjaro use neither of these, so I create a sym-link for them.
ln -sf /boot/vmlinuz-5.3-x86_64 /boot /boot/vmlinuz-manjaro
ln -sf /boot/initramfs-5.3x86_64.img /boot/initrmafs-manjaro.img
And point to these.

At no point in my 'own' grub do I need to modify, change or 'update' with any kernel change in any OS either.

Thought I'd share one more time with you.
Cheers.

1 Like

There are more then a few Off topic posts here re. grub-vanilla should these be split off ?

One more:

Just got around to installing grub-vanilla on my slap-top and desk top. .. works fine remembers other distro fine. Like many including @wongs I like to see the boot roll by, no quiet here.
My background is NSFW ... :man_shrugging:

i.e. /boot/grub/grubenv

Thanks folks!

First of all, thank you so much! @gohlip Weren't it for this post, I wouldn't be able to repair my Manjaro partition after a firmware upgrade.

I tried to follow the "Simple Configfile Method", but I had to adapt it, because it didn't work out-of-the-box. Thus I share my use case.

My problem was caused by a firmware upgrade of my Asus UX310, that had been forcefully installed by the bully Windows Update. The upgrade switched on secure boot, and secure boot removed the GRUB/Manjaro EFI entry. I restored the Manjaro EFI entry as described here, but still the new entry did not work: my BIOS refused to boot GRUB and ran Windows instead.

Then I tried to restore GRUB using the chroot method, but it was not sufficient: the culprit was not GRUB itself, but the .efi file in the EFI partition. Probably it was not necessary to restore GRUB at all, I don't know.

Then I found this post, and I tried to follow the Simple procedure, booting from a recent USB install media, but I get stuck on the first command:

grub> search.file /etc/manjaro-release  root

it gave me an error! Maybe due to a different version of GRUB in my USB media, who knows.

Here is how I finally solved:

  1. Boot from a recent Manjaro USB installation media. Notice that I had to enable an obscure BIOS option named CMS in order to boot from USB.
  2. In the first boot menu, do not press 'c'. Instead, I selected the menu item Detect EFI Bootloaders. I navigated to Manjaro pre-existing .efi file, which should be something like EFI/Manjaro/grubx64.efi, and I ran it. This is exactly the bootloader that BIOS was refusing to run: my installation media was able to run it instead! My Manjaro partition booted "as usual"!
  3. Then I had to fix the efi entry so that BIOS would run it. I followed the guide in @gohlip's first post under UEFi - additional commands:

I hope it helps. It is a condensed version of what I actually did, because I've had other problems caused by an incorrect handling of subvolumes in my BTRFS root partition (my own fault)... which would deserve a post on its own!

Glad you fixed it and thanks for the details in using the 'detect efi file' at the install menu.

You said you had error at..

It may be a typo, but since you've got it working, you can try this command again. You do not need to use the live install usb, but you can use the grub prompt of your grub menu.
If there is an error, please let us know the error message.

Cheers.

Here is what I get, even using my main GRUB menu:

error: no such device: /etc/manjaro-release.

I assume you are now in manjaro OS.
At terminal

ls /etc/manjaro-release

Do you get
[1]

ls: cannot access '/etc/manjaro-release': No such file or directory

Or do you get
[2]

/etc/manjaro-release

If you get [2],
Now do this at grub prompt

grub> search.file /etc/manjaro-release

Any output?

If you get [1], you have a problem (somewhat) where this file is not created.
Or you have a bios that has not picked up all the devices (disks)
In which case,
grub> ls
will show the devices that the bios has picked up. Check if that device (with Manjaro) is listed.
If listed, do again
grub> search.file /etc/manjaro-release

If disk is listed and still have error, something's wrong. Tell us.

1 Like

BTW, I don't recommend 'detect efi files' which is like using 'multiboot' (booting core.efi) is that both that efi file and grub.cfg must be working (inferred in post 56).

At Manjaro terminal:

gives me [2]: the file exists and contains the text Manjaro Linux.

Instead in GRUB:

gives me the same error as before: no such device.

gives me my only SSD (hd0) and its partitions (hd0, gpt1) through (hd0, gpt6).

My Manjaro partition is /dev/sda5, which should correspond to (hd0, gpt5), which is listed. It is a BTRFS partition: may it be the reason why GRUB doesn't find it?

Now you tell us. {slaps head}

No. Just that it needs a different path to get to it. {@/; or @/ subvolume/}
Look at your grub entry. It is there.
I don't use btrfs anymore. (Just tested it, don't like it, so I don't use it).
Goodbye.

At last, we've found the culprit!

Just for future reference: if you use BTRFS, you have to look for

grub> search.file /@/etc/manjaro-release root

I don't know if the following commands should be modified, too.

Not necessarily. Some btrfs users use subvolumes (/@root, /@boot/....)
/@root/etc/manjaro-release

That's one of the main reasons people use btrfs (some uses it for snapshots and recovery)
So... it depends how that user sets it up.
It may be
grub> search.file /@root/etc/manjaro-release
and then the linux line will be
grub> linux /@boot/vmlinuz-xxx.xx rw
grub> initrd /@boot/initramfs-xxx.xx.img

But as said, I don't use btrfs anymore.

1 Like

Yes you're right!

My BTRFS partition is managed by Snapper, thus @ is the "current" subvolume, while @snapshots/# are the old snapshots. Assuming that I want to boot the latest version of OS, I have to mount /@/...

Thank you again @gohlip!

1 Like

Forum kindly sponsored by