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 changing their titles may require making complex changes to shell scripts stored in /etc/grub.d/. This may be improved in the future. In the meantime, those who feel that it would be easier to write grub.cfg directly are encouraged to do so (see Booting, and Shell-like scripting), and to disable any system provided by their distribution to automatically run grub-mkconfig.
6.1 Simple configuration handling
This thread is about GRUB2 and what you think of it. This is also a place that is supposed to unify all discussion regarding GRUB2 itself, that previously has been spread across other threads, more or less in an off-topic fashion.
I have to second what @clatterfordslim said in " 10 reasons why …"
Grub is only on screen for a limited amount of time, usually five seconds
grub is a very sensitive and important piece of software. It pays to leave it alone unless you absolutely have to fix something.
Fiddling with grub for the sake of cosmetics is looking for trouble. If the grub menu allows you to boot your system(s), put up with its sometimes raggy appearence.
Everyone seems fixed on the grub menu, and I agree, it is convenient. But there is another way of using grub.
If you only install grub, and do not configure it ( ie do not run update-grub), then when you boot you get a grub> prompt, at which you can enter commands.
You can boot anything that is bootable that way, even an OS that the notorious os-prober does not find. The commands to use at the grub> prompt are documented here
I doubt that is a valid alternative. As the manual shows in its “easy” examples, starting an OS manually by GRUB command line is extremely daunting and error prone. For booting an OS manually via GRUB CLI, you have to know, where the kernel is located and this is specific to each OS (perhaps even distribution).
And even the “easier” examples, like the Linux one, are not suitable at all, for every day use:
grub> linux /vmlinuz root=/dev/sda1 acpi=off
grub> initrd /initrd
This above snippet only works, if you know what boot arguments the OS needs and what exactly you need to specify. If you don’t, you are out of luck and cannot boot it.
just how does Grub Customizer work, is it proprietary, or is it free to modify?
I have not looked at it closely, but from reading a bit I gather that it overwrites or modifies files in /etc/grub.d , so it modifies the scripts that setup the grub.cfg file in /boot/grub.
The thing that irritates me is that if you let it do that, there is no way to get back to the original pure-grub script files in /etc/grub.d. Other than a full reinstall of linux. So if I were you, I would make a backup copy of all the default files in /etc/grub before I went near grub-custo izer. Then at least you could do a recover if needed.
I dont think it is proprietary?
I wonder could you attack this another way. Go into your Win 8 and see if there is anywhere you could change its label, or add a label, so that os-prober might identify it properly. It might work. You can test it by just running os-prober instead of update-grub.
Well I think grub2 is much less of a problem than os-prober.
So I set out to uncover what I could about this mysterious utility which is used by grub to probe disk partitions for other operating systems.
We might first note that update-grub will only invoke os-prober if there is an line in the file /etc/default/grub saying
GRUB_DISABLE_OS_PROBER=false
If it is missing or set to true , grub will not invoke os-prober and as a result it will only find the OS which ran update-grub.
If you look for os-prober in your system you find no man page, no info , but
which os-prober
locates it in /usr/bin and you can look at it… it is an ascii file… a shell script. There are other parts to it … there are files in /usr/share/os-prober and /usr/lib/os-prober and /usr/lib/os-probes
These are installed files… setup by your distro , in my case Debian.
The original src code of os-prober is on a Github site
If you look at the os-prober code on this site, it differs from the installed code in your system… this is the source used by distro makers to install os-prober in their distro. It includes a Makefile to do customize the install.
But what is really interesting on the Github site is that the README file, which is displayed at the bottom of the Github page, contains documentation for os-prober and another utility called linux-boot-prober which attempts to determine how to boot a linux filesystem.
So, at last, we have some documentation. You can view it on the Github page, or get a copy by downloading the README file.
Cheers
Neville
PS There is another take home message from the os-prober Github site
The last update was 8 years ago. Development has ceased.
As @Akito says, great article.
It is great because it explains how things work, rather than just give recipes.
I had to do a 40_custom file once… Solus put its vmlinuz file in a strange place and grub could not find it. After doing it I realised I could have fixed the problem by making a soft link to vmlinuz in Solus.
But really, your article is the best I have seen
Thank you
Neville
So some issues can be solved by fiddling the OS, rather than customizing grub
Can I cross reference this discussion to an article by @Winston in the post “10 reasons wy debian is better than arch”
Winston sets out how to have 2 grubs maintained by different OS’s
This acts as a safety net. One grub config can be damaged and you can still boot from the other. Good idea.
Neville
Well I think grub2 , and its forebears, legacy grub and lilo, have a design problem.
If I were part of a plan to make grub3, what would I argue for?
Firstly, for multi-boot situations, we do not need a boot loader, we need an OS Manager. What is the difference? Well, an OS manager would be in charge of
booting any nominated OS (ie like the grub menu)… it still needs to be a bootloader
switching between booted OS’s
keeping track of what is on what disk partition
doing backups and snapshots
To do all that an OS Manager would have to be a persistant part of the loaded software. Most likely it would have to live in RAM, in its own space, like the kernel and the user space.
That is a drastic change of memory management, but it is sorely needed.
It would allow one to logout from an OS, and instead of going to the dumb login screen, one would drop back to the OS Manager where one would have an option of , another OS boot, a backup or snapshot, or a shutdown.
Backups need unmounted filesystems. It is a pain using DVD or USB stick, just to get everything unmounted. OS Manager would solve that.
This is different from VM. I know you can boot multiple OS’s with KVM or whatever, but it is a very restricted environment. i am talking about managing hard-installed distros.
So what do you think. Can we plan for a better multiboot environment, and are my concepts Ok or too difficult or whatever?
In this brief post, you have provided a brilliant, precise, detailed, and may I say almost obvious account of PC design strategy that ought to have been implemented at least three decades ago. You also show where the trouble lies by posting your presentation (for lack of an alternative platform?) in what might be one of perhaps the geekiest regions of a forum dedicated to an OS that I suspect is being maintained in a perceived status of not being suitable for “ordinary” computer users.
Am I right in thinking that change in this anti-competitive and therefore anti-innovative situation will require one of the very few major computer and/or chipset manufacturers to risk adopting a new strategy?
I would have thought that any government or inter-governmental agency concerned with medium-term public strategy would be discussing openly the most obvious risks to the present order, such as the absence of technologically independent second sources.
Hi @crl ,
Yes, I am afraid that any change to the design of a bootloader would also require a matching change to the BIOS. Changing a BIOS is not really a big deal technically, but it runs into compatability issues.
and
if it ended up as a ram resident bootloader, that would require significant software design changes especially in the area of memory management.
I see no harm in trying to define what the ideal is., even if realizing it may take a long time or even be impossible, given the technological monopoly situation which you discuss.
And thank you for the kind words. I like the FOSS forum. It is not really dedicated to one OS, it is more centred on free software, and it can only be what the users make it.
@nevj
I want to say it is a pleasure reading your comments and thoughts. You and I sometimes think alike, but your knowledge of the workings of a computer is far superior than of mine. I just use what is at hand to setup a computer, and that in itself is getting harder, due to changing times. What you propose here, will probably never come to pass, but not because of you, but by other big corporations, that have more control over how our computing world will and cannot do. But change is in need of starting somewhere, so why not with you.
No, wrong word. Just different.
You have mastered some of the most difficult hardware related aspects of computing, like partitioning disks, booting,… but you have not had the chance to see software design first hand,
No, I cant do this grub thing alone… too old … I am 77 and a lot of my time is taken up being a carer. But I may be able to inspire someone to look at it.
Did you experience the way computers used to be booted by an operator? There were toggle switches on the console, and the operator toggled the binary bootstrap code in, loaded it to the starting location set in the program address counter, an pressed the go button.
That is basically all that grub, aided by the bios instead of an operator, does.
The key change I want , is to have grub stick around after it has booted some OS., so that it can manage things. No bootloader I know of has ever done that. They all just do their thing and die.
Thanks for the encouragement. We all need it
Neville
@nevj
No I have never experienced that kind of boot up. My first PC was a Gateway running W98
with dial-up modem for internet access. The PC was retired to the attic several years ago.
There is this lovely story about Seymour Cray.
When presiding over the first public showing of the Cray supercomputer, he calmy walked over to the console, and toggled in all 256 binary digits of the bootstrap, out of his head… and it started…
All mainfranes, and most minicomputers ( eg PDP) had toggle switches. Bios only came in with the PC.
Neville
