Re: Problems with grub-reboot/savedefault/default=saved

[Colin Watson]

On Wed, Dec 16, 2009 at 02:28:03PM -0800, Jordan Uggla wrote:
> 1: grub-reboot doesn't restore the default after rebooting, making it 
> effectively equivalent to grub-set-default. This is because the 
> savedefault functionality currently saves the entry you boot from as the 
> new default even when grub-reboot is used. Because of problem #2 there is 
> no way ( outside manually editing the grub.cfg ) to use grub-reboot without 
> savedefault functionality also enabled ( and thus no configuration where 
> grub-reboot isn't broken ). I've added a patch for this to 
> the bug report @ http://savannah.gnu.org/bugs/?28161 and as the first patch 
> attached to this email.

Applied with a slight tweak, thanks.

> 2: Setting GRUB_DEFAULT=saved in /etc/default/grub also enables savedefault 
> functionality. There are many people who would want to use grub-reboot and 
> grub-set-default without savedefault. The second patch adds a separate 
> variable, GRUB_SAVEDEFAULT, for enabling savedefault.

How would this interact with setting GRUB_DEFAULT to something other
than "saved", and doesn't 00_header.in also need to be changed to
actually use the saved entry (it won't be used unless you have
GRUB_DEFAULT=saved)?

In my mind, GRUB_DEFAULT was overloaded for this for a good reason; but
perhaps I'm simply not understanding what you mean, so would you mind
explaining further how you'd like to see the whole thing laid out?

> 3: Savedefault functionality currently adds two lines ( one setting a 
> variable, the other saving it ) to every menu entry and with my patch for 
> fixing grub-reboot, an if statement as well. This clutters the menu entries 
> and makes it hard to write and maintain custom menu entries with 
> savedefault. The third patch moves this to a function "savedefault" defined 
> in 00_header so entries just have to have "savedefault", like in grub 
> legacy. And if the implementation of savedefault needs to change, custom 
> menu entries will still work unmodified.

Makes sense. Applied.

> 4: Even with the first grub-reboot fix the default is still not restored 
> when grubenv is not writable ( /boot on lvm for example ). Since 
> grub-reboot can't work without a writable grubenv it's at least safer to 
> boot into the "real" default instead of the "temporary" default. The 
> fourth patch sets default=$prev_saved_default if save_env fails. 
> Grub-reboot ( the utility ) should also complain when grubenv isn't 
> writable by grub. What is the best way to determine that grubenv likely is 
> or isn't writable by grub?

I don't understand why /boot on LVM should mean that grubenv is not
writable. The point of grubenv is to be a short chunk of contiguous
reserved disk space which can be written by GRUB without needing any
special filesystem intelligence. Surely LVM doesn't split up those 1024
bytes into different physical extents?

> 5: Since grub2 uses menu entry titles for savedefault instead of numbers, 
> the default kernel booted won't be changed when the user installs a new 
> kernel. Using titles instead of numbers is good, but an unfortunate 
> consequence that users may not realize ( and was not true with savedefault 
> in grub-legacy ) is that if users set GRUB_SAVEDEFAULT=true they will never 
> actually boot any updated kernels unless they select them manually at the 
> grub menu. This could lead to not getting security updates for the kernel, 
> and with major upgrades could cause serious problems when the old kernel 
> doesn't work with newer userland components like Xorg. I can't think of a 
> good way to solve this problem.

IIRC GRUB Legacy (or at least Debian's update-grub, once upon a time)
handled this by having a special "default" entry at the top of the Linux
kernel list. Would it be worth introducing this to grub-mkconfig?

-- 
Colin Watson                                       address@hidden