Bug 212649

The old and outdated --once patch should be put out to pasture for these reasons:

 - as noted above, then documentation would reflect the actual functionality

 - putting this in grub.conf is more self-describing than requiring a manual
grub shell hack

 - one could actually know what entry will be rebooted next by a simple cat
/boot/grub/default whereas with the old --save patch it's hidden inside the
binary stage2

Please toss that old crap out for F9+. Or...if there really are valid
dependencies, at least stop patching out the more modern upstream
savedefault/fallback functionality.

I've just been trying to setup a nice robust multi-boot system with
fallback in fedora 10, and I see there is still no grub-set-default
command. It would sure be nice if I didn't spend a long time
believing the grub info docs only to discover all that stuff was
patched out (at least that's how I interpret comment #1 above).

grub-set-default is used to temporarily set a default for next boot such as the functionality in old LILO.  This command is needed again, it's still present in other linux distros that use Grub such as Fedora, this is not just a "nice to have", it's needed.  For example, it is used to test a grub default for a one-time boot, especially in datacenter environments, if a default does not work, then the old default takes over at the next boot, so a reset can be done, and the system is back to normal.  this is how LILO worked in older distros.

You can do the equivalent of grub-set-default in the existing fedora grub,
but the documentation in the info files has nothing to do with the
commands grub supports to achieve this.

For instance:

savedefault --stage2=/boot/grub/stage2 --default=2 --once

this will make the default boot be entry #2 just for the next boot.

The "help savedefault" command in grub has all the documentation
I've been able to find on it.

I don't know if fedora 13 will be going to grub2 by default, but if
so, the entire universe will be stood on it's head then, rendering
this issue moot :-).

I'm an RHCE, this workaround is no big deal for me, however my contention is that this command is STILL documented in grub's man pages, and is still the accepted practice on other distros, therefore Red Hat should have never had made the decision to remove the command arbitrarily.  Further, the key here is to make linux easier to administer for new administrators and more consistent with the package's providers, as well as more consistent with the accepted documentation via the man pages.  Not to mention that Red Hat contains many scripts and shortcut commands that allow you to accomplish one administrative task with one command, where another distro forces you to run the individual commands (several commands to accomplish an admin task that Red Hat automates with one much easier and time saving command).  The original command with the package needs to be re-included.

Does anyone know the correct form for the savedefault command in grub.conf.

savedefault --stage2=/boot/grub/stage2 --default=0

works from the grub cli.

The same command in a grub.conf stanza does NOT work. These also don't work:

savedefault --stage2=/grub/stage2 --default=0
savedefault --stage2=(hd0,0)/grub/stage2 --default=0
savedefault 0
savedefault --default=0

With some more messing around, I also found odd behavior with --once

If you at the first stanza (that is, you've booted up in default=0),

savedefault --stage2=/boot/grub/stage2 --default=1 --once

works. That is, the next reboot will take you to the second stanza, the second reboot will go back to the first stanza.

But, if the second stanza has ANY savedefault, even pointing to the first stanza, such as  savedefault 0, the second reboot will not go back to the first stanza, but continue with the second.

I'm dealing with a remote server. Undocumented or poorly documented behavior on controlling the boot loader is quite scary. Especially where it isn't the behavior described in the upstream manual or docs.

> I'm dealing with a remote server.

I certainly don't know how to get it to work from inside
a grub.conf file, but I have a similar remote server, and
I just have scripts on the default boot system to run grub
manually and do the savedefault, then run reboot, which gets
me to the new system one time, then when I reboot it, I'm back to
the default system again, where I can run my script to feed
commands to grub and boot a different system.

It always takes two reboots to get to the system you really
want running, but it seems to work OK (as long as you aren't
in a big hurry :-).

Having the boatloader's documentation inconsistent with the actual implementation is a bad and really scary joke. Please patch GRUB in whatever crazy way you like but *only* if you also patch the documentation accordingly and keep the two consistent with each other. Come on, we are talking about bells and whistles here!

I obviously meant:

> Come on, we are NOT talking about bells and whistles here!    

Sorry for the noise. This is what happens when you mess with how systems boot... not.

This is still an issue in FC13 and looks to be a definite issue in EL6 (at least the beta) and possibly FC14.  

My hack (once realizing the included documentation was worthless and finding this BR) for now (boot Windows so I can VNC in and reboot back to Linux) is:

#!/bin/sh
let WINBOOT=`grep ^title /boot/grub/grub.conf | grep -n Windows | cut -f 1 -d :`-1
echo Booting $WINBOOT - `grep ^title.\*Windows /boot/grub/grub.conf`
echo "savedefault --stage2=/boot/grub/stage2 --default=$WINBOOT --once" | grub
# EOF

(where I obviously have "Windows" in the title for that entry).

If there is a good reason to remove grub-set-default and not use a /boot/grub/default file, then the documentation (.info) should at least be updated so people don't waste time pursuing methods that have been patched out of the upstream code.

I'm an FC14 user and just spent some time searching for this command.  It's probably true that many users will not change their boot settings.  But we are talking about Linux here - many users will indeed do so (as I just have because I have problems with the latest kernel), and while it's simple enough to reboot once to get a default saved, this would have been a nice convenience to have.  It's probably not a good idea to invite people to experiment with custom grub scripts.

At the grub prompt can you enter the command

savedefault --default=N

> At the grub prompt can you enter the command...

This does not help when your server is far away from you: the typical "grub-set-default" use case.

If you are in front of the console then you typically do not even bother with "grub-set-default" in the first place; you just use the damn console instead.

could this be a workaround to find out next boot? (it works for me at least :)

# xxd /boot/grub/stage2 |grep 0000200 |awk '{print $8}'

>This does not help when your server is far away from you: the typical
"grub-set-default" use case.

He wasn't very specific - you use the savedefault command with the grub binary from within linux:

# echo "savedefault --default=N --once" | grub --batch

Then only the next boot will be item N; you can just do "reboot" after running the above line.

 grub2-set-default exist , but if you want boot always the same entry 
you may add 
#cat /etc/default/grub
GRUB_DEFAULT="Windows" (for example my entry to always boot)

see bug #742720 , for the spaces problem .

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

David, as per your Comment 19, which command should be documented as a workaround for the absence of grub-set-default? Comment 4, 16, or another? (Assuming their syntax is broad enough for documentation purposes.) I can't detect any primacy amongst them. 

Or do you mean another command not provided here?

Created attachment 600060 [details]
Change for the documentation in the package

re: comment #11 + #24... FWIW, thx for the documentation update... at the very least it will make it clearer for people still dealing with this version of grub

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause - the documented command was planned but not yet developed when we initially shipped this software, and wound up being implemented in a different way
Consequence - the documented behaviour was not what wound up being shipped
Fix - update the package documentation to reflect shipped behavior
Result - users should be able to read the right documentation now.

VERIFIED in grub-0.97-13.10.el5

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0087.html

you fucking cunts.

Why am i pissed off? Because I'm here, having my time wasted, 10 years after this clusterfuck first reared its ugly head. 10 fucking years.


So this is the answer is it?:
  echo "savedefault --default=N --once" | grub --batch

Well, where is it documented? Why the fuck does this page:
  https://www.gnu.org/software/grub/manual/legacy/Booting-once_002donly.html
STILL refer to grub-set-default, when grub-set-default does not exist?

This bug was raised for el5.

Why the fuck is there still no proper documentation for the grub in el6, 10 years later?