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

Thanks, @gohlip.

So just installing grub-vanilla will replace manjaro's grub package?

May I confirm that the next steps after installation will be:

  1. remove all grubenv entries,
  2. adjust /etc/default grub if and as needed
  3. sudo grub-install /dev/sda [since I'm on legacy boot]
  4. sudo update-grub

Yes. Remember to 'grub-install' ( and update-grub) after that. That command is in the first post as well, but I (shamefully) forgot this myself when I changed 2 Manjaro OS to it. :stuck_out_tongue:

Yes the steps 1 to 4 are sufficient.
To be accurate step 1, is just for house-cleaning, good to remove 'scruff' in grubenv. If left alone, it does nothing. And if GRUB_SAFEDEFAULT is there in step 2, it will generate its safedefault grubenv at 'update-grub'.

Before grub-quiet, I tried to say that upstream-grub is better in hiding grub menu than grub-quiet itself. So it is with this grub-vanilla.

Cheers, wongs.

1 Like

Thanks. Not intending to hide grub menu, though.

In recent times I've found my custom.cfg entries for other distros no longer having a countdown (to the booting of the default menu entry), and I suspect it's because I'm using the configfile method of booting into/running the grub.cfg files of those distros from Manjaro's grub, which has changed significantly.

I'm guessing it's the settings in /etc/default/grub that have changed.

I will be happy to return to a very normal grub, and get my countdown timers back.

Oh, okay. When I was checking on grub-quiet, and I'm not a coder, I recall that when there's certain values in boot_indeterminate (or boot_success), the mechanism extend or change the TIMEOUT values either to zero or to something very long (60 secs +). That may be it (and also explain why some people see a long black screen BSOD).

That period, away from the forum, also help me question why I am doing things that do not affect me at all (as you know I use my own grub, so my own grub.cfg). It's a 'nirvana' moment.:rofl:

Aha! Yup, some of my other distros showed a 60s countdown even after I edited their grub file and updated grub from within that distro. Puzzled me no end.

But now, that long countdown is also gone. The grub menu just stays on indefinitely until I actually select a menu entry to boot into.

Anyway, I'll see what happens after I change to grub-vanilla.

If the no-countdown persists, I'll start a new thread and post my current grub settings.

I did notice that a few grub entries using multiboot instead of configfile (I was trying out new things) which booted into core.img of that other distro preserves its own grub settings.

Ya, I like to hear from you, particularly too if your problem is solved.
And good luck.

ps: BTW, another method, instead of using configfile is using multiboot, details at 2nd post here. I use multiboot to test other OS's and tell people whenever if there's problems to use configfile when their grub's kaput.

...this would be a nice title. :rofl:

1 Like

@gohlip, Did you see my edit to my post above about multiboot and core.img! I added that just as you posted your last comment.

I confirm that multiboot and core.img still work to run the grub settings of those other distros regardless of the weirdness of Manjaro's grub.

Well, except Fedora 30. Argh.

Yes. Good. That's because multiboot use that destination OS grub (and settings) while configfile use the originating grub settings with the destination grub entries.

That is another catastrophe waiting to happen. The folks there are trying to steer towards systemd-boot. With F30, they are making grub all in $esp. Its grub.cfg is placed in $esp, not /boot. If you do configfile, try to see if there is a grub.cfg in its $esp, there may be 2 grub.cfg. One in /boot and another one in /boot/efi. See if the configfile to the one in /boot/efi works. Oh remember to 'insmod fat'.

Back to the catastrophe.. I have several Manjaro's and you have many OS's. As written in my bootctl topic, if the $esp is /boot, multiple 'same distro' OS's will have problems, not to mention same named kernels like ubuntu and linux mint or kaos, Antergos and Arch. But I manage because I have grub (and refind :rofl:) at the same time. Furthermore, fat32 does not allow for symlinks. And will not boot OS's whose kernels/efi files are not in that same $esp. And... more :rofl:

I don't have Fedora for a long long time. I am sad that Suse had turned from a great distro ... to Novell, to whatever and had to take scraps of parts from Fedora (same as for Mageia). Anyway... let us know how it goes for your F30.

1 Like

That is another catastrophe waiting to happen. The folks there are trying to steer towards systemd-boot. With F30, they are making grub all in $esp. Its grub.cfg is placed in $esp, not /boot. If you do configfile, try to see if there is a grub.cfg in its $esp, there may be 2 grub.cfg. One in /boot and another one in /boot/efi. See if the configfile to the one in /boot/efi works. Oh remember to 'insmod fat'.

I got confused.
The multiboot core.img way was fine. It was the configfile method that didn't work at first because F30 had made changes to grub that were adverse to people on MBR boot. It didn't generate grub.cfg after I upgraded from F29 to F30 with its resultant new kernels. So trying to boot into F30 for the first time using the configfile way gave me an error message.

With the multiboot way, I was able to boot into the last kernel I was using in F29, but then I discovered the next dubious direction taken by F30 when I tried to update grub - F30 disabled by default the ability to generate grub with the grub2-mkconfig command. :frowning:

Thankfully a forum member here showed me how to enable the mkconfig command again.

So there is no grub.cfg in /boot/efi. It's still in the /boot/grub2 folder. The main issue now is whether, after a kernel upgrade, F30's grub will auto generate grub.cfg like it used to, or will I have to manually use the mkconfig command after every kernel update.

IIRC, manual generation was needed the first time I updated after enabling the workaround. I seem to recall that upon first reboot after that said update, the first kernel in the grub menu was not the latest one. But I couldn't be certain and I just did a mkconfig anyway without confirming the issue.

Today, I tried to confirm this once and for all but there were no kernel updates. I'll post when I know for sure.

It will be worse to people on UEFI.

But see this website on bios-legacy.
Need to put in /etc/default/grub
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!



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

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.

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!

Forum kindly sponsored by Bytemark