[ Following up on the older discussion... ]
tg@debian.org wrote:
kilobyte wrote:
At this point, I'd just enable os-prober unconditionally, and think of a
Erm, *no*?!
os-prober corrupts data when called (in virtualisation/emulation
guests, at the very least).
Steve wrote:
I'm also pondering tweaking things in d-i to re-enable os-prober if
the system looks like it might have some other OS installed. Yes, I
But what if the system has *both* other OSes installed *and* is
used as virtualisation host (when booting Debian) at the same time?
You’ll still get data corruption of unrelated data (VM guests).
I consider that inacceptable, but apparently YMMV…
And this debate is exactly the problem. There is no single good answer
here, and two different sets of people will lose, depending on what we
choose as a default:
* (Potentially new) users install Debian as part of a dual-/multi-
boot system and now (as os-prober is disabled by default) they
don't get an option to boot the other OS(es) easily. I've seen
situations like this before, and I understand that people worry
here: "OMG what happened to the Windows system I still need?"
* People with currently-running guests potentially end up with data
corruption problems when updating grub on the host.
What I've done now is:
1. Added debconf handling for enabling/disabling os-prober in
/etc/default/grub to make it easier to handle things.
2. Made some *limited* tweaks to grub-installer, the d-i component
that sets up GRUB. It already runs os-prober in a massively
over-complicated way (see below).
If *that* os-prober run detects other OSes installed, we will now
use the new grub debconf setting to enable os-prober on the new
system. If no other OS is detected during installation, we will
disable os-prober there.
Either way, the user will be prompted about os-prober *at a low
priority* so that they can override things via preseed or answering
the question in d-i expert mode.
I think this is the best route forward, from the available options. If
you're in the tiny set of people running Debian on a dual-boot *and*
running guests while you update grub then you'll need to manage that
on your own: disable os-prober and come up with your own method of
adding extra boot options (or similar). /etc/grub.d is designed for
this kind of thing if you need it.
The current set of options here with grub and grub-installer are
*huge*, and IMHO the code is getting impossible to follow or
maintain. :-(
*After bookworm*, I plan to take a machete to grub-installer and do
some long-needed cleanup.
1. There's currently support in grub-installer for doing a *one-off*
os-prober run and adding a semi-hard-coded list of other OSes found
there, then not running os-prober in future on the installed
system. This is going away; I'm not convinced that it's *ever*
worked proparly and of course it doesn't deal with future changes
to the system.
2. I'm planning on killing support for grub-legacy, which is *way*
overdue. It's been dead upstream for over a decade already...
For GRUB itself:
1. We have a *lot* of patches on top of upstream GRUB, which makes it
hard to keep in step with security updates etc. I hope to find time
to rationalise things, following on from work that Colin was doing
earlier.
2. I'd like to simplify options more and reduce the number of packages
we ship here too. Let's see...
--
Steve McIntyre, Cambridge, UK.
steve@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it
note stuck to the mini-bar saying "Paul: This fridge and
fittings are the correct way around and do not need altering"
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)