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

[Jordan Uggla]

On Tue, Jan 5, 2010 at 3:08 AM, Colin Watson <address@hidden> wrote:
>> 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)?

That's correct. Perhaps GRUB_SAVEDEFAULT=true should imply GRUB_DEFAULT=saved?

( if [ "x${GRUB_DEFAULT}" = "xsaved"  -o x${GRUB_SAVEDEFAULT} =
"xtrue" ] ; then GRUB_DEFAULT='${saved_entry}' ;  )

> 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?

I am not set on a single layout ( I'd like input from others on
exactly how this should work ). But I do think that it should be
possible to use utilities like grub-set-default and grub-reboot
without also enabling savedefault. As an example use case:

Jane has a server with two boot options, one is a well tested, known
working, configuration and the other is a system for experimenting.
When she has physical access to the server she can select the
experimental option and if anything goes wrong she can reboot into the
stable configuration if needed. When she is administering the server
remotely though, she needs to be sure that she won't completely lose
access to the server if the experimental system fails to boot ( or
bring up the network connection / ssh properly ).

Because of this problem, Jane always wants the safe configuration to
be the default so that if anything goes wrong she can simply power
cycle the machine and fix things from the working system ( I'm not
sure why it's so common that people have the ability to remotely power
cycle but no remote access the console to be able to use the grub
menu, but every person I have talked to that uses grub-reboot is in
such a situation ). If she is in the safe configuration and wants to
remotely switch to the experimental one she uses grub-reboot to
temporarily change the default. Note that she never wants to change
the default permanently, but that's what savedefault will do if she
selects the experimental boot option from the grub menu ( rather than
grub-reboot ) and safedefault is being used.

I would guess, though I have no data to back it up, that in fact most
grub-reboot users do not want to use savedefault.

>> 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?

Recently Vladimir has talked about having submenus ( one debian menu
with separate kernel versions in a submenu for instance ) which will
probably help solve this problem.
-- 
Jordan Uggla ( Jordan_U on irc.freenode.net )