Creating a new os-independent grub 2 bootloader

bios-legacy/msdos grub2 bootloader


o Create a partition, preferably in ext2 [1]
150 MB is lots of space- usual size is less than 50 MB [2]
o Boot up to OS where the bootloader version is selected [3]
o At terminal, mount and install

sudo mount /dev/sdax /mnt
sudo grub-install --boot-directory=/mnt/boot /dev/sda

o Create a grub.cfg and add to this partition’s /boot/grub/grub.cfg

footnotes-
[1] - better than ext4 or ext3 for this purpose - all can be used
[2] - this partition will henceforth be known here as /dev/sdax
[3] - can be from any linux distro or we can download from upstream
Of course, when you boot this OS, it must be in bios-legacy.

6 Likes

uefi/gpt grub 2 bootloader


o Create a partition, preferably in ext2 [1]
150 MB is lots of space- usual size is less than 50 MB [2]
o Optionally, label this partition [4]
o For clarity, in this example,
I will use $esp partition as /dev/sda2 [5]
and Bolt partition as /dev/sda10 [4]
o Boot up to OS where the bootloader version is selected [3]
o At terminal, sudo mount /dev/sda10 /mnt sudo mount /dev/sda2 /mnt/boot/efi sudo grub-install --target=x86_64-efi --efi-directory=/mnt/boot/efi --bootloader-id=<whatever name> --boot-directory=/mnt/boot --recheck --debug

For installing this grub bootloader to a removable medium like an external drive. it is important to add “–removable” to the install line like this

sudo grub-install --target=x86_64-efi --efi-directory=/mnt/boot/efi --bootloader-id=<whatever name> --boot-directory=/mnt/boot --removable --recheck --debug

2 things to note for removable medium…
(1) If we don’t put in this ‘’–removable" parameter when installing, when we pull out this media and try to boot, the (uefi) bios may report an error because the drive is no longer there. But if the removable is always connected, there will be no error.
(2) To boot from this removable medium when it is inserted, you must select this at the (uefi) bios otherwise it will continue to use the ‘hard drive’ default bootloader.

o Create a grub.cfg and add to this partition’s /boot/grub/grub.cfg

[edit] - I removed the “label” part because I realised most people do not use labels.
I use labels in all my partitions and I am used to using it, so this edit is, I think necessary.
And this edit uses /mnt (instead of /media/Bolt) to mount. Will work fine.

footnotes-
[1] - better than ext4 or ext3 for this purpose - all can be used
[2] - this partition will henceforth be known here as /dev/sdax (labelled as ‘Bolt’)
[3] - can be from any linux distro or we can download from upstream
Of course when we boot this OS, it must be in uefi boot
[4] - here I will use label=Bolt (never use generic names like ‘boot’, ‘grub’, etc…)
[5] - $esp partition is in fat32 format and in this case I assume it is existing
But you can create a new $esp partition if you like (I have 4 - for windows, bootctl, the linux common one and this one)
[6] --bootloader-id= use a name that is different, not ‘manjaro’, ‘ubuntu’, etc. your name is fine.

4 Likes

Sample grub.cfg


Create a grub.cfg. Just need only 2 sections
One for set up.
Another for the entries.
An optional video section for grub themes (between setup and entries)

Set up Section

  ############################### set up ###############################

set root='hd0,msdos1'
search.fs_uuid xxxxxxxxxxxxxxxxxxxxxxxx root
set prefix=($root)/boot/grub

set gfxpayload=1280x1024x32
gfxmode=1280x1024x32

default=0
timeout=15

menu_color_normal=white/blue
menu_color_highlight=yellow/blue
####################### begin entries #######################




########################## end ############################

notes:
o uuid - the uuid above is for the new partition (ext2)

Video Section (optional)
Add a theme like this.

Entries Section

 ####################### begin entries #######################


menuentry  'LXQT    Too  sda10' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-31f7dc62-237d-4b3d-afee-a97c558a8dbd' {
    insmod part_msdos 
    insmod ext2
    set root='hd0,msdos10'
    search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos10 --hint-baremetal=ahci0,msdos10 31f7dc62-237d-4b3d-afee-a97c558a8dbd
    linux    /boot/vmlinuz-manjaro root=UUID=31f7dc62-237d-4b3d-afee-a97c558a8dbd quiet splash rw
    initrd    /boot/intel-ucode.img /boot/initramfs-manjaro.img
}



menuentry  'Plasma  Eoo  sda8' --class kde --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-5a4d7104-bf96-4bb7-9f38-d7f407a631fb' {
    insmod part_msdos 
    insmod ext2
    set root='hd0,msdos8'
    search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos8 --hint-baremetal=ahci0,msdos8  5a4d7104-bf96-4bb7-9f38-d7f407a631fb
    linux    /boot/vmlinuz-manjaro root=UUID=5a4d7104-bf96-4bb7-9f38-d7f407a631fb quiet splash rw
    initrd    /boot/intel-ucode.img /boot/initramfs-manjaro.img
}


menuentry  'Net     Joo  sda7' --class gear --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-b2e92717-e41a-4406-8dc6-4b68c1150d65' {
    insmod part_msdos 
    insmod ext2
    set root='hd0,msdos7'
    search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-baremetal=ahci0,msdos7  b2e92717-e41a-4406-8dc6-4b68c1150d65
    linux    /boot/vmlinuz-manjaro root=UUID=b2e92717-e41a-4406-8dc6-4b68c1150d65 rw
    initrd    /boot/intel-ucode.img /boot/initramfs-manjaro.img
}



 ########################## end ############################

Note: If you noticed, I’ve used vmlinuz-manjaro and initramfs-manjaro.img
instead of the usual vmlinuz-4.6-x86_64 and initramfs-4.6-x86_64.img

That’s because I created sym-links like this whenever I installed a new kernel.

sudo ln -sf /boot/vmlinuz-4.6-x86_64 /boot/vmlinuz-manjaro
sudo ln -sf /boot/ initramfs-4.6-x86_64.img /boot/initramfs-manjaro.img

This sym-link creation is not necessary whenever the kernel gets updated, like from 4.6 rc2 to 4.6 rc3.
Only when we install a new kernel, like kernel 4.7.
I do this because there is no need to modify or touch this grub.cfg at all whenever there is a new kernel.
For other distros, there is already a sym-link generated with new kernels and so I point to the sym-links also.

3 Likes

Additional Entries


A few things first.

search line
search can look for 3 things.
uuid, label and file.

search --no-floppy --fs-uuid --set=root <uuid>
search --no-floppy --label --set=root <label>
search --no-floppy --file --set=root <file>

The syntax can be -u, -l and -f
and search.fs_uuid search.fs_label search.file are aliases for the commands.
and ‘set’ if unspecified is for setting as root

So this line is similar to our familiar first line above.
search.fs_uuid xxxxxxxxxxxxxxxxxxxxxxxx root

linux line
Now linux line too requires that we specify which partition we select as ‘root’, typically exemplified by
linux /boot/vmlinuz-manjaro root=UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxx quiet splash rw

We can use label instead like
linux /boot/vmlinuz-manjaro root=LABEL=xxxx quiet splash rw
or plain device map like
linux /boot/vmlinuz-manjaro root=/dev/sdxy quiet splash rw
which is very unreliable.

But uuid numbers are of course impossible to memorize and device mapping unreliable.
So I have used mainly labels here in this section of “modifying entries” to boot. If we choose to permanently ‘anchor’ a particular entry, then we should use its uuid instead.

After all, creating labels is quite easy using gparted or a simple command like
e2label device [ label ] (#for ext fs)

A helpful command to select (rather, set) a uuid is probe
probe -u $root --set=abc
It can also ‘set’ its label
probe -l $root --set=xyz
but I doubt anyone can forget what he/she labels his/her partition.


So let’s start.
Oh, a reminder that all grubs work on all linux distro’s (and more), whether they originate from the distros themselves. It’s just the content and parameters of their entries.

Direct boot
Easy. Just type in the linux and initramfs and boot.
Here I still use sym-links, but typing the actual vmlinuzes and initramfs’s is not too difficult either.
Use “(tab)” (my original tab goes missing on this bbcode thingy) to help autocomplete. Well, intel-ucode - type in if you desire, but if just to boot in and repair, there’s no need to be that picky.

menuentry "Label - Vmlinuz-Manjaro " {
    insmod part_msdos
    insmod ext2
    search --no-floppy --label --set=root xxxx
    linux /boot/vmlinuz-manjaro root=LABEL=xxxx rw
    initrd /boot/initramfs-manjaro.img
}

Chainload
(The original one - we will encounter another ‘chainload’ in uefi which is not actually)

menuentry "Label - Chainloader " {
    insmod part_msdos
    insmod ext2
    search --no-floppy --label --set=root xxx
    chainloader +1
}

The least reliable and my last of my choice.
No further comment.

And typically used for Windows

menuentry "Windows C "  {
    insmod part_msdos
    insmod ntfs
    set root='(hd0,msdos1)'
    drivemap -s (hd0) ${root}
    chainloader +1
}

Note the above has a drivemap command which is necessary for booting windows more reliably in 2 or more disks situation. Oh, typically in sda1. And to segue into windows boot, here’s my preferred direct booting of Windows.
Windows - ntldr

menuentry "Windows 10" {
  insmod ntfs
  search --set=root --fs-uuid xxxxxxxxxxxxxxx
  ntldr /bootmgr
}

For Windows XP, the command is different

menuentry "Windows XP" {
  insmod ntfs
  search --set=root --fs-uuid xxxxxxxxxxxxxxx
  ntldr /ntldr
}

Multiboot
What these commands do is to boot up directly (not really chainload) core.img or core.efi of the OS’s.
It’s like using the OS’s direct grub and grub.cfg itself. Note the commands are different in bios-legacy and uefi.

menuentry "Multiboot --bios-legacy" {
               search --set=root --label xxxx
               multiboot /boot/grub/i386-pc/core.img
     }
menuentry "Multiboot --uefi" {
               search --set=root --label xxxx
               chainloader /boot/grub/x86_64-efi/core.efi
     }

One possible disadvantage of using this (I personally like this the most and I use this for testing the OS bootloader) when recommending this method to others is that when there is a problem, there is a likelihood that the first sector is already defective (moving partitions, resizing, etc) and this method to boot could fail for these reasons.
A simple way to remedy the faults is just to "grub-install’ again.
Another more ‘surgical’ way to repair core.img is

grub-install --no-bootsector but this applies for grub version 2.02~beta3 - not in Manjaro yet - and for bios-legacy.

Configfile
What this do is to use the bootloader of the current grub menu but replace the grub.cfg (and therefore entries) of the selected target OS.

menuentry "Label - Configfile " {
    insmod part_msdos
    insmod ext2
    search --no-floppy --label --set=root xxx
    configfile /boot/grub/grub.cfg
}

This would be my preferred recommendation for people who cannot bring up the bootloader of the selected OS but can have other OS’s bootloader or at least a grub prompt.

Hope this topic is useful and good luck.
Cheers.

Reference
Grub Manual

3 Likes

You’re somehow the God of grub here, gohlip :smile:

Bukan Budi, cuma biasa saja. :slight_smile:
(just an ordinary guy)
And…oh… you spelt my name wrong.
It’s G…O…H. :grinning:

& so, the empty one (Notes) is for what, “master of grub” :wink: ?

Okay, G…O…H :wink:

May I clarify that in " --set=root xxx ", the xxx should be the UUID number or the /dev/ partition number?

1 Like

it looks like (because of 3 ‘x’) it is the name of your device with your root partition, e.g. sda, sdb, sdc, …

1 Like

If “search --no-floppy --label --set=root xxx”, then xxx is [label]
As per above [quote=“gohlip, post:4, topic:3150”]
search linesearch can look for 3 things.uuid, label and file.

search --no-floppy --fs-uuid --set=root <uuid>
search --no-floppy --label --set=root <label>
search --no-floppy --file --set=root <file>

The syntax can be -u, -l and -f
[/quote]
Hope this clarifies.
Cheers.

ps: search --file can be very useful too, like in search $isofile, /boot/intel-ucode, …
ps: search command does not use /dev/sdxy
we can ‘set root’ (instead of search) with
set root=(hdx,y)
But it is not recommended.
You see this ‘set root=(hdx.y)’ in all grub entries but always search line is below this ‘set root’ line and therefore supercede it.
Try it out. Go put in a wrong (but valid) (hdx,y) and it will still get you to the right partition as spelled out by the search line. That’s what makes grub so …er, usable dependable.

1 Like

I install my bootloader on a separate partition with a couple commands.
This may help someone not to create a grub.cfg manually:

Notes:

  • this is working on my BIOS/MBR system, I don’t know if UEFI/GPT needs extra stuff.

  • manjaro ships a customized grub, which can boot other systems as well, but other systems’ grub may not boot manjaro: this happens with this method (if applied from within another distro) just like happens during fresh installs.

Assuming sdaX to be grub partition:

$ sudo mount /dev/sdaX /mnt
$ sudo grub-install --boot-directory=/mnt/grub/ /dev/sda
$ sudo grub-mkconfig -o /mnt/grub/grub.cfg
1 Like

Yep. It will work.
Except I recommend you change the uuid of the grub.cfg to the new “separate boot partition”

Thanks for the input. Cheers.

1 Like

Following on from successfully adjusting my grub menu entries in my UEFI laptop and finding the configfile method really effective,

(documented here:


)

I finally got round to trying out the configfile method on my multi-distro MBR/legacy boot PC. I set out my experience here.

Manjaro XFCE runs the controlling grub on my PC.

I have a custom.cfg file with chainloader entries for other distros, but that only works for distros where I was able to install grub bootloader onto the root partition of a particular distro. Some distros didn’t really allow grub to be written to root, or had installers that I wasn’t so familiar with so I chose not to install a bootloader at all. If no bootloader was installed, you couldn’t chainload from Manjaro.

That led to the inconvenience of having to run the update-grub command in Manjaro whenever those distros had new kernels installed, so that Manjaro could detect the new kernels and update the controlling grub.

However, even if Manjaro grub detected the new kernels, some distros’ main entry in Manjaro’s grub menu might not be the latest kernel.

When you opened the “advanced options” submenu for these distros, the different kernel entries would not have version numbers nor are they in descending order. That meant I would have to expand each entry in the submenu with “e” to check on which was the latest kernel. Examples of such distros: Korora, Void. For both of these, I didn’t install bootloader at all.

Then I had PCLinuxOS, which had been installed when they were still using legacy grub. Previously I was able to chainload from Manjaro to the legacy grub but not for quite a few months now.

So:

  • install the grub2 package on these distros (if not already installed),
  • run update-grub command in these distros to generate an up-to-date grub.cfg file.
  • no need to write the bootloader to root partition or MBR with the grub-install command (which might not be allowed or might have to be force installed)

That’s sufficient for the configfile entries in my Manjaro custom.cfg file.

Very convenient. I should have done this sooner!

2 Likes

@gohlip, thought I'd reply here instead of in the "using livecd as grub" thread, as it was getting a little off-topic there.

I've long bookmarked this thread for examination and tips for my custom grub entries. I just never got down to setting up a separate partition just for a bootloader because I didn't think it would save me that much time.

My custom.cfg file entries work in general for me, without any need to update controlling grub (Manjaro) when kernels change in my other distros.

I save a copy of my latest custom.cfg file in my Data partition. If I ever wipe Manjaro from the PC, I'll just assign another distro to control grub, and dump the custom.cfg file into that distro's /boot/grub.

Problem distros:

Fedora from version 30 onwards: only now is this an issue, and even then, it's just a matter of generating the grub.cfg file after kernel updates.

Solus: I'm probably partially to blame for this. When I first tried to install Solus on my PC from live USB, the installer would only proceed as a UEFI install and then stalled due to errors (of course I had no EFI partition). Didn't realise at that time the BIOS had been set for live USB to prefer booting as UEFI rather than legacy.

So what I did was to use gparted to copy over my successful Solus installation on my old laptop, and paste it into a partition on my desktop. It was fine at first since Solus stored their kernels in the normal place in /boot.

But then they decided to use clearboot, and that's when things got messy. Their kernel and img files are now in /usr/lib64/kernel. A normal update-grub in Manjaro cannot find the Solus kernels and img files in this new location. I'm not sure I could remove Solus' clearboot without messing things up. Grub no longer exists on the install.

So whenever I update Solus, I do what you do for Manjaro, and create symlinks for the current- and lts- img files, in /usr/lib64/kernel. There are already symlinks in said folder for the current- and lts- kernels.

My custom.cfg file then points to those symlinks. What you do in your independent bootloader, I do in the custom.cfg file, and I don't see how it would save me time to have an independent bootloader.

Void Linux does not use generic references to current and LTS kernel and image, nor does it have symlinks to generic kernel/img names. Seems inconvenient to create symlinks all the time whenever there is a kernel upgrade (which is often). Better to just update grub and let Manjaro grub read Void's grub.cfg file.

Yes, I'm aware you're doing this and there should be no problem this way either.

Good idea. I was about to say the benefit of having a separate dedicated grub is nothing can nuke it. Not windows or any linux OS.

Fedora 30 - I have no fedora, I am asking you to inform us about how it goes about it. Thinking more about UEFI in Fedora 30 as they are planning some weird things with grub.

Solus - I also have Solus. In bios-legacy, like ubuntu, debian...they have a sym-link to root partition, not /boot partition. They are, as in ubuntu, debian....vmlinuz and initrd.img. Check it out again. I just point to these sym-link and they boot okay with latest kernel.

Manjaro sym-links - we need to regenerate sym-links only when we upgrade the kernel , like from linux52 to linux53. Any upgrade, say from linux53 5.3rc6 to linux53 5.3rc7 don't need to regenerate sym-links. The latest linux53 will be booted. I have several manjaro's; I do not find this inconvenient, but of course, it will be good if manjaro has sym-links (the first request I made to manjaro - none fulfilled - intel-ucode, msdos uefi....) Hope this clears up.

Cheers.

I know. That's why it's still convenient if you want to symlink for Manjaro. You don't often have to do it . The kernel name remains the same that series.

It's not so convenient if I want to symlink for a distro like Void since I have to do it every update as every kernel even in the same series will have different numbers. I also have to do it every update for Solus, because I could have sworn there is no symlink in root (due to how I pasted my laptop Solus onto a partition in the PC). I'll check on this again tonight.

But since ManjaroXFCE controls grub, I actually don't need to symlink at all (although my custom.cfg file does have a configfile entry for Manjaro in case I change controlling grub) as every update it will normally update-grub.

My Manjaro Budgie install is booted from a custom.cfg entry.

1 Like

I don't have Void or know anything about it. Okay, I hear from you it has different number for each kernel upgrade.

And yes, if using configfile or multiboot, there is also no need to change anything.
But I like to boot up directly. Kind of....uhm, straightforward. :slightly_smiling_face:
And no messy grub.cfg (grubenv, if..then...elif...) to navigate.
And no wrong grub or config to contend with.
If required, special parameters can be put at the OS entry.
And always boot.

Forum kindly sponsored by Bytemark