GRUB2 Customiser

[Akito]

Follow-up to the whole GRUB topic in this forum.

GRUB Customisation

As previously discussed. Customising GRUB2 seems to be a huge pain in the ass and the biggest buzzword in the GRUB customisation world, is obviously and undeniably Grub Customizer. Even the official GRUB manual admits, that configuration is complex and hard to do. grub-mkconfig does have some limitations. While adding extra custom menu entries to the end of the list can be done by editing /etc/grub.d/40_custom or creating /boot/grub/custom.cfg, changing the order of menu entries or chang…

GRUB2 Command Explanation or Example needed

I again hit a wall in a manual. Even if you really take the time to read a manual, that might still sometimes be useless or not as useful as it should be. This apparently does not happen to me only. I need an example of gptsync usage. NOT this gptsync! I need an example for the one from GRUB2. The manual tells me, I can provide up to 3 partitions as arguments to the command. How are the partitions identified? By location? By name? By label? By UUID? How? At least, there won’t be some Li…

Rename a grub entry

[update-grub] Is there a way to rename the /dev/sdb1 from Windows 10 to Windows XP in the grub entry menu?

I would like to gather ideas regarding the inner workings of a proper GRUB Customiser.

We have established already, that the all too well known GRUB Customizer is definitely not as great as it seems. It probably has lots of fans, but it does come with its own set of issues, even creating new problems!

Please, contribute some ideas on how a GRUB Customiser application would look like, that you would happily use frequently and without a doubt.

One of the things I would like to see most are more backup options. For example, a backup of the original GRUB configuration should be taken, before the GRUB Customiser app is applying any modification. This way, the backup can be restored, when uninstalling the GRUB Customiser tool.
Ideally, before each configuration, a snapshot (backup) of the current configuration should be taken. This way, the user would be able to revert to each state, at will.
This is the safest and probably best way of handling the GRUB modification situation.
Even if the app does not modify a lot or tries to be as gentle as possible, such backup options will always prevent a bad emergency situation, where your GRUB is absolutely destroyed, perhaps even irreversibly so, as it is the case with GRUB Customizer, at this point.

As already hinted in the previous paragraph, the app should also be as gentle as reasonable, when modifying the GRUB configuration eco-system. It shouldn’t create further bloat and complicate things even more. GRUB2 on its own is already a huge complicated mess!

So, these are my biggest ideas, among other smaller ones.

What ideas do you have?
What kind of app would you happily use frequently to customise your GRUB2?
What should the app be able to do and what should it not do?

[nevj (Neville Jackson)]

@Akito

What ideas do you have?
What kind of app would you happily use frequently to customise your GRUB2?
What should the app be able to do and what should it not do?

I think we might clarify what we mean by customize
In order of difficulty

1. Make the grub menu pretty
2. Change entries in /etc/default/grub… this is relatively easy and is unlikely to break grub
3. Re-order the files in /etc/grub.d … this is easy an will reorder the menu entries
4. Change the 40_custom entry in /etc/grub.d … this is difficult… you need to learn to write a custom script.
5. Diagnose a problem … see the grub-mkrescue command

If we mean all of that, it is a big ask

There seems to be an illusion that a gui customizer might dispense with the need to understand how grub works. It will not help much with that, but it may help with guided access to the files to be configured, and some degree of protection against mistakes.

So what should a customizer app do and not do?
I say work within the grub2 configuration file setup, dont add extra files or alter the way grub2 works… then if something breaks, you can always fix it by hand… that should not be difficult, anything you can do by hand at the command line can be built into a customizer.

What about using the grub> prompt.? I think we need to exclude that.
There are heaps of options and most of them are unused and/ or poorly documented… The average user can do without these

And can I cross reference this to that other post
“Grub customization”
where I argued for a differnt approach altogether for bootloaders
The problem exists because GNU are doing nothing to further develop grub2.

Neville

[Akito]

@nevj

There seems to be an illusion that a gui customizer might dispense with the need to understand how grub works.

I’m convinced, it’s not an illusion, if you are only customising what millions of people need to customise:

1. Menu Entry names.
2. Menu Entry order.

Sometimes, even setting a GRUB2 theme is not an issue in some cases, if someone else already did the work for you.

So, if you don’t need to do any advanced scripting or advanced GRUB2 configurations in general, besides re-ordering and re-naming menu entries, then you are fine without knowing anything about GRUB2.

@nevj

I say work within the grub2 configuration file setup, dont add extra files or alter the way grub2 works… then if something breaks, you can always fix it by hand…

The program should be there, to make the user never need to edit anything by hand. That’s the point of the program. It should be the entire interface the user has to see. It is supposed to replace manual editing altogether.

@nevj

What about using the grub> prompt.? I think we need to exclude that.
There are heaps of options and most of them are unused and/ or poorly documented… The average user can do without these

The program wouldn’t be able to access the GRUB2 prompt anyway, because it is run inside Linux, so it cannot access what happens before Linux is booted up.
That said, the CLI commands are all configurable inside the GRUB2 configuration eco-system. So, no need to use the GRUB2 prompt, in the first place. It’s only meant to be used in an emergency situation.

@nevj

where I argued for a differnt approach altogether for bootloaders

Are you referring to the part where you said, that the user should enter boot commands manually by hand?

[nevj (Neville Jackson)]

@Akito

@nevj

where I argued for a differnt approach altogether for bootloaders

Are you referring to the part where you said, that the user should enter boot commands manually by hand?

No, not that.
The bit about having grub stick around after the boot, so you could drop back to it and boot something else. That is what the multiboot user needs… Probably too futuristic.

 not an illusion

Well maybe a ‘false hope’.
Yes if it is simplified the way you suggest

1. Menu Entry names.
2. Menu Entry order.
   we may well be able to realize it.

I neglected to mention the edit option on the menu itself. When you move to an item you can type ‘e’ and edit the corresponding info in the grub.cfg file. That is useful for a temporary fix, but it will be wiped when you do update grub. I used it tonight to find out why Void would not boot after an update. It turns out that if Void updates the kernel, the version of vmlinuz changes, and Void does not make a soft link like Debian, so grub can not find the new vmlinuz. So I have to update-grub every time Void upgrades the kernel version.

Keep on with this. There is an opportuniy here to fix something
Neville

[Akito]

@nevj

I neglected to mention the edit option on the menu itself. When you move to an item you can type ‘e’ and edit the corresponding info in the grub.cfg file.

I’ve used that a couple of times in my life.
It is extremely error prone. Just mistyping a little word breaks the whole boot and you have to restart the computer.

It’s good enough for an emergency situation, but not useful for anything beyond such a situation.

@nevj

Keep on with this. There is an opportuniy here to fix something

Indeed.

[nevj (Neville Jackson)]

@Akito

It is extremely error prone. Just mistyping a little word breaks the whole boot and you have to restart the computer.

Yes, not very user friendly. I just shoild have noted it for completeness.

Back on the futuristic stuff. Do you think grub could be run as a process within linux? Probably not… it must have some hardware dependent code which means it has to own the machine while it runs.

[Akito]

@nevj

Back on the futuristic stuff. Do you think grub could be run as a process within linux?

Yes, it could be. But it wouldn’t be the same thing with the same capabilities. GRUB2 is meant to boot any operating system, even the ones explicitly incompatible with GRUB2 (Windows, for example).

Therefore, it must be run on a much lower level.

@nevj

it must have some hardware dependent code which means it has to own the machine while it runs.

It’s not so much hardware dependent. It’s just so independent of operating system types, that it must be run on a much lower level, i.e. EFI level or at least in the area.

[nevj (Neville Jackson)]

@Akito

It’s not so much hardware dependent. It’s just so independent of operating system types, that it must be run on a much lower level, i.e. EFI level or at least in the area.

Thank you. I will think about it.
I think you should only need to invoke grub once… to start the first OS. Then you should be able to start a different OS without going back to the Bios and using grub again.
Not VM. Just swap in another OS overwriting the first.
It would be easier if the kernel was not monolithic. Then you could have one small module that was permanent, and the rest swapable.

[Akito]

Does anyone else have suggestions?