Re: dual booting, was Re: Stupid question
On Mon, 14 Feb 2022 at 05:27, Andrei POPESCU <andreimpopescu@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
Reply to: