[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re-enabling os-prober for live images?



[ 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"


Reply to: