Re: dual booting, was Re: Stupid question
On Mon 14 Feb 2022 at 10:18:13 (+1100), David wrote:
> 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 :)
Ditto in this response.
> > > 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.
(I've responded to this post itself.)
> 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.
> $
I must think about that with respect to my PC that has three Debians,
one booting with UEFI- and two with BIOS-mode. Of course, I can currently
boot all three in either mode, and even update-grub, but grub-install
might cause problems if run in the wrong mode.
I was considering how to convert a BIOS-mode installation into a
UEFI one (I'm posting that in another thread), but I could just
leave the two BIOS ones with no grub at all.
> 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.
(I like "learned helplessness"!) True, but the upside of posting
only the "official" automated way is that you don't have to support
it. As you suggested above, a customised method would really require
a polished HOWTO, were I to recommend it.
> 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.
Yes, I've certainly used the GRUB_DEFAULT for the NextBoot
facility in the past: when fsck'ing a device took ages, NextBoot
would automatically select a forcefsck boot when the BIOS turned
the machine on (again, automatically) in the morning. And
GRUB_CMDLINE_LINUX is still useful for adding system-dependent
tweaks, like libata.force=3.00:disable on a broken machine
and video=960x540 on a laptop with unusable resolution.
But I run a shell script on any new grub.cfg that automatically
makes all the changes I want (like UUIDs → LABELs). I'll probably
stick with that until I dispose of the last non-UEFI machine,
and then consider Felix's post from a while back:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 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
>
Cheers,
David.
Reply to: