kgrubeditor MIR

Bug #262309 reported by Jonathan Riddell
4
Affects Status Importance Assigned to Milestone
kgrubeditor (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Revision history for this message
Jonathan Riddell (jr) wrote :

Moved to main to make it in for Feature Freeze.

Revision history for this message
Harald Sitter (apachelogger) wrote :

Subscribed ubuntu-mir to the report.

Revision history for this message
Loïc Minier (lool) wrote :

I wonder a couple of things on this MIR:
- "process apt data": I grepped the source on apt and didn't find anything relevant; is this true? Perhaps a leftover from copying a MIR of another package?
- I see the package handles the "DEBIAN AUTOMAGIC KERNELS LIST" block, but it doesn't call update-grub; I suspect it tries to update generated data itself; this doesn't sound right as its current behavior might not be aligned with update-grub's and it might derive even more if we change update-grub (e.g. "last good boot"); what do you think?
- Ubuntu uses the "uuid" command in menu.lst on new installs to select the root device; I don't think this command is handled, only "root" seems to be handled
- does the tool support GRUB2 in degradated mode, or not at all? Will it support GRUB2? We had discussions about supporting GRUB2 at UDS, and we'd like to offer it as an option during installation on jaunty -- NB: I think it would be good enough if kgrubeditor were to claim that it can't edit GRUB2's configuration when an user running GRUB2 tries to open the config

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 262309] Re: kgrubeditor MIR

On Thu, Dec 18, 2008 at 09:34:43AM -0000, Loïc Minier wrote:
> I wonder a couple of things on this MIR:
> - "process apt data": I grepped the source on apt and didn't find anything relevant; is this true? Perhaps a leftover from copying a MIR of another package?
> - I see the package handles the "DEBIAN AUTOMAGIC KERNELS LIST" block, but it doesn't call update-grub; I suspect it tries to update generated data itself; this doesn't sound right as its current behavior might not be aligned with update-grub's and it might derive even more if we change update-grub (e.g. "last good boot"); what do you think?

I agree that, if this package doesnt provide something we can do
through update-grub its usually a better maintenance approach to do
that instead of revinventing the wheel. How easy would it be to fix
the package to use update-grup instead?

 - Alexander

Revision history for this message
Martin Pitt (pitti) wrote :

Moved back into universe due to unresolved issues. Incompatibility with our standard grub configuration seems like a serious issue to me.

Changed in kgrubeditor:
status: New → Incomplete
Revision history for this message
Martin Pitt (pitti) wrote :
Revision history for this message
Konstantinos Smanis (ksmanis) wrote :

Automagic support is being worked on, but here are my two cents: the Automagic and update-grub framework is really inflexible. I mean, you can't properly edit/remove an automagic entry or else a warning message with an ackward default action will pop up, confusing most new users.

I will add proper support for Automagic in kgrubeditor (plus support for the uuid command), but in my opinion, something should really be done about this issue.

Btw, uuid and quiet are no standard GRUB commands. Does Kubuntu use a modified version? If so, is there any documentation for this commands? Plus, I would appreciate Automagic documentation other than that in menu.lst (comments).

Revision history for this message
Loïc Minier (lool) wrote :

Artemis, I agree with your points; the long term solution is probably in GRUB 2's scripting support, but we're stuck with GRUB 1 and update-grub for a long while still. :-/

uuid is to set the command to set the root device from an UUID; I think the plan is to move to the "root" command and pass an UUID as argument (which I think is supported in Debian's GRUB 1 or GRUB 2, not sure); the uuid command is an Ubuntu-ism and isn't supported in Debian at this point.

The quiet command is also an Ubuntu specific patch; it's used to disable some of GRUB's output. Having worked a little on this myself, I need to say GRUB's boot progress messages are a bit chatty when you try to achieve a clean boot experience (think OSX). This patch is probably going to stay for a while.
  There's something weird though, quiet_boot seems to be the default; I suspect we could drop the actual command calls and use quiet 0 / quiet 1 command instead of the current useless "quiet" in menu.lst. You're welcome to file bugs / patches on this topic if you like, I think we could much improve this option and general chatiness of grub during initial boot.

You can find some bits of documentation on the automagic feature in the update-grub(8) man page.

Revision history for this message
Martin Pitt (pitti) wrote :

Closing due to inactivity. Please reopen if you still want/need this and the identified problems were fixed. Thank you!

Changed in kgrubeditor (Ubuntu):
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.