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

Yes, it chinese, but it is old style. Too many strokes. But I'm old enough when the new style was introduced.:smile: I was taught old style in school, introduced new style after I left school.

But always be careful when translating. Translating to English from other languages may mean differently when read by native English speakers, for example, a simple 'you're welcome' is often translated as ''doesn't matter' or 'small thing' from french or italian, 'please' from german, 'don't be polite' from chinese, 'return' from indonesian and do on. And of course there can be major gaffes like trying to say 'ashamed' in indonesian.

And there is this story/joke about Nixon asking Mao how often he has elections. Mao replied, 'every night.' I hear his translator was fired. Okay, bad joke.

[edit] - it is the new style. but when writing, we often use even shorter forms, anyway we seldom write anymore - all typing, so we don't need to know how to write and many young chinese forget how to write.


"findmnt" is a great find :slight_smile:
Thank you gohlip. I enjoy reading your boot comments. Especially 'efi'.
New computer, first time with 'efi' . A challenge.

1 Like

Just here to say my deepest thanks! You saved my -rear end- with your Uefi specific trouble shooting!

Thank you so very much! I was already about to give up as the system on its own would just not boot without the detour over the liveUSB

thanks thanks thanks

1 Like

What if I have two outputs that are the same:

grub> search.file /etc/manjaro-release
hd0,msdos1 hd0,msdos1

I'll type these outputs out later when on my desktop (on my phone now).

More info at error: file `/boot/grub/i386-pc/normal.mod` not found..

Use them both! One at a time.. :laughing:
What else can you do? :man_shrugging:

1 Like


1 Like

Hi @gohlip.
Do your instructions only concern using livecd v17.01?
Or can any version work?
I have issues with a broken bootloader on my laptop and would like a link to an image of the version you mention so that I may attempt to fix it.

Thank you in advance.

Any version above that will work.
I had included the latest version that I had tested to make sure this works.
Apparently, I had edited this out (in my many edits) and I'm not aware that I had edited this information out.
Thanks for pointing this out.

Just FYI, previous versions (prior to 17.0.1) needed some adjsstments to the parameters to make it work for newer versions. (At least 3 times adjustments were made). The last adjustment was made with grub versions changing rapidly (not the iso adjustments) but the final grub version made it such that we still make it work with menu_auto_hide). But don't worry about it. I just like to explain things.


Thank you for your prompt reply.

When I get round to actually working on it - I'll be sure to tap you for any help if I need it.

Have a good day.

1 Like

Latest amendment in first post.
Short summary - Change grub to grub-vanilla.

grub-vanilla is now in stable branch. Strongly recommend all to change to grub-vanilla, even for those who want a hidden grub menu. It's less problematic. Faster, Easier, and Simpler.
grub-vanilla will be less error prone and the possibility of getting into boot problems will be vastly reduced. We'll still get into problems with people using grub-customizer or manually changing /etc/grub.d/. But using grub-vanilla will be a great step in getting grub to behave as grub should.
There is almost no difference from upstream grub.

Some more details -

  1. remove all grubenv entries. This should do.
sudo rm /boot/grub/grubenv
sudo grub-editenv /boot/grub/grubenv create
  1. The existing /etc/default/grub will be used after grub-vanilla is installed.
    You might want to check if you want to keep original settings.
  2. For those wishing to have the original manjaro theme (instead of the black and white text grub menu), at /etc/default/grub (but existing /etc/default/grub will have these anyway, if you haven't removed it).

For those who want to have a 'classic' black/white text, comment out both lines (default settings will replace - GRUB_TERMINAL_OUTPUT commented out will be 'console')


Default is 'menu'. Meaning if not specified (or commented out) in /etc/default/grub, it defaults to 'menu'. For whose who want hidden menu, specify it to 'hidden' That's it. But I'd personally recommend 'countdown' instead. Try it for yourself.

  1. Press 'esc' key from hidden or countdown menu to get to the menu. NOT any other key like 'shift' or 'F8'. That's for the ■■■■

  2. btrfs and f2fs
    For those on btrfs and f2fs, Do not use GRUB_SAVEDEFAULT=
    GRUB_DEFAULT= can still be used as this does not use grubenv.
    And btrfs and f2fs do not need /boot to be in a separate partition.
    Just do not use GRUB_SAVEDEFAULT=


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.

Forum kindly sponsored by