On Mon, 14 Feb 2022 at 05:27, Andrei POPESCU <andreimpope...@gmail.com> wrote: > On Du, 13 feb 22, 11:01:48, David Wright wrote:
TLDR: On the topic of grub automatic configuration 1) suggestions how to avoid it 2) why I prefer to do that Disclaimer: contains generalisations and lacks full justifications of points made. This is just a brain dump of some thoughts that some people might find useful alternative options. I don't have time to polish it into a nice piece of considered writing. If you disagree with something, that's fine. I'm just offering an alternative perspective, not trying to change your mind :) > > Typically, one would have a primary, "master" linux system which would > > be used to write an MBR pointing to itself. The other, legacy system > > would have its grub.cfg kept up-to-date, but would never touch the > > MBR by running grub-install. > Another option (at least with MBR, didn't try this with GPT) is to tell > the Installer to install GRUB in the partition instead of the MBR, and > then manually install another GRUB instance to the MBR with a > handcrafted config that is chain-loading the GRUBs in the partitions. And yet another option for avoiding bootloader conflicts in multiboot setups (at least with MBR, didn't try this with GPT) is to avoid installing the os-prober and/or grub-update machinery on all but one of the linux installs. This can be done (in the installer expert mode, and maybe the others) by skipping the "install grub" step and choosing "install without a boot loader". It's provided for a good reason :) The installed OS will run fine without grub, provided that you ensure that there is a bootloader somewhere else that can start it. That's your job now! After booting, if you want to you can even install a constrained version of grub that lacks the grub-update machinery, by installing the package 'grub-pc-bin' instead of 'grub-pc'. It too is provided for a good reason :) As the maintainer says: $ apt show grub-pc-bin [...] It can be installed in parallel with other flavours, but will not automatically install GRUB as the active boot loader nor automatically update grub.cfg on upgrade unless grub-pc is also installed. $ When grub2 first was released I avoided it for years! I do not like the automation that generates the grub.cfg file so full of human-unfriendly content, compared to grub version 1. The automation is fine if it works and gives results you like, so you can ignore it. It is a heroic programming effort and I'm sure it handles all sorts of situations that I've never considered. However I was/am multibooting various OS, and I didn't like to watch helplessly while os-prober made all kinds of inappropriate decisions on my systems and update-grub mangled my boot menus. The idea of automation is worthy, but it seems to me with grub2 that years later one downside is that we have moved to a situation of learned helplessness. Now we have people in the situation like Hans, where we have to explain the grub automation as if it is the only possible way to do things. And no-one dares to touch their grub.cfg anymore because it's overwheming. Even though most of that overwhelming content is very much not necessary, it is a primary deterrent causing people to avoid configuring the bootloader menu themselves. People ask about how to tinker with the tiny bit of configuration that grub exposes [1], and we don't dare to recommend that they throw it all away because we've all become reliant on the automation. And explaining the alternative is too hard. And if that automation breaks for some reason, like Stella had a while back, then in general everyone is helpless because it's too hard to give instruction on how to write their own grub.cfg and recover. I suppose I could write something for the wiki but I'm too lazy or too busy, and therefore part of the problem. Plus multiboot is quite unfashionable, other people like to advocate more modern methods with VM and such. I prefer not to become reliant on infrastructure that I can avoid (I do use VM for throwaway tasks). And these days I'm not multibooting disk partitions, I'm multibooting logical volumes inside one huge LUKS container that I only need to create once and provide one password for at boot. I like having all my multiboot filesystems easily mountable from everywhere, it helps me manage them collectively with scripts. Eventually I dug a little bit deeper with grub2. I experimented by writing my own simple grub.cfg. When that worked, the next step was to learn ways to prevent that effort being blown away by the automation at every update, as described above. Thee are other ways to do this too [2]. I persevered and I eventually learned to love grub2. It has some amazing features. Once you can get it to stop imposing its default behaviour on you, it's a powerful ally. For instance, it contains a full scripting language [3]. The authors wanted a control language, so they built a shell-like parser into it. Do you know that you can write functions in grub!!! The autogenerated grub.cfg files could be greatly simplified by using that feature, if someone had time to implement that. My grub.cfg files are quite complicated, but they are things of beauty (to the beholder, haha) now because I use functions to contain all the complexity. And what used to be a "stanza" for each OS is now a single line of configuration values. Also worth reading [4]. A couple of useful commands to get started playing with hand-rolled grub configuration files: grub-script-check grub-emu And this is the long story of how I learned to love grub2. And why I love open-source software. Now, time to stop writing this and work on other things :) [1] I think that's in /etc/default/grub but not sure because I don't have that file [2] /etc/grub.d/README [3] https://www.gnu.org/software/grub/manual/grub/grub.html#Shell_002dlike-scripting [4] https://www.gnu.org/software/grub/manual/grub/grub.html#Multi_002dboot-manual-config
