Latest grub package (0.97-1ubuntu4) breaks /sbin/grub-reboot

[Peter Whittaker]

Running a dual-boot system, grub-reboot is the most convenient way to temporarily boot into "the other" OS without maintaining multiple /boot/grub/menu.lst files (especially with regular kernel updates); as of yesterday grub-reboot no longer works.

Until yesterday (20060217), grub-reboot worked fine; according to Synaptic history, grub was changed from 0.95+cvs20040624-17ubuntu7 to 0.97-1ubuntu4 on that day.

/sbin/grub-reboot calls grub as:

default="$1" ; shift
grub --batch $@ <<EOT
savedefault --once --default=$default
quit
EOT

When invoked by grub-reboot, grub reports:
$ grub-reboot 10
Probing devices to guess BIOS drives. This may take a long time.

    GNU GRUB version 0.97 (640K lower / 3072K upper memory)

       [ Minimal BASH-like line editing is supported. For
         the first word, TAB lists possible command
         completions. Anywhere else TAB lists the possible
         completions of a device/filename. ]
grub> savedefault --once --default=10

Error 27: Unrecognized command
grub> quit

Either restore the grub functionality used by grub-reboot, or modify grub-reboot to use appropriate current functionality.

[Robert Millan (zeratul2)]

tags 254475 unreproducible
thanks

On Tue, Jun 15, 2004 at 12:40:46AM +0200, martin f krafft wrote:
> Package: grub
> Version: 0.94+cvs20040511-1
> Severity: normal
>
> Neither grub-reboot, nor manually telling grub to
>
> savedefault --default=1 --once
>
> or
>
> savedefault --once --default=1
>
> make grub boot the second stanza. In fact, savedefault doesn't seem
> to work at all.

It works for me. Did you update the stage files and re-load GRUB after the
savedefault feature was added?

--
Robert Millan

"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."

 -- J.R.R.T., Ainulindale (Silmarillion)

[madduck (madduck)]

also sprach Robert Millan <email address hidden> [2004.06.23.2025 +0200]:
> It works for me. Did you update the stage files and re-load GRUB
> after the savedefault feature was added?

No. Does it say anywhere that I have to? Or do you mean: did
I install the latest Grub?

If not, then what should I do after editing menu.lst?

  recopy the stage files
  rerun grub-install

?

--
Please do not CC me when replying to lists; I read them!

 .''`. martin f. krafft <email address hidden>
: :' : proud Debian developer, admin, and user
`. `'`
  `- Debian - when you have better things to do than fixing a system

Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

[Robert Millan (zeratul2)]

On Wed, Jun 23, 2004 at 11:08:48PM +0200, martin f krafft wrote:
> also sprach Robert Millan <email address hidden> [2004.06.23.2025 +0200]:
> > It works for me. Did you update the stage files and re-load GRUB
> > after the savedefault feature was added?
>
> No. Does it say anywhere that I have to? Or do you mean: did
> I install the latest Grub?
>
> If not, then what should I do after editing menu.lst?
>
> recopy the stage files
> rerun grub-install

Yes.

--
Robert Millan

"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."

 -- J.R.R.T., Ainulindale (Silmarillion)

[Peter Whittaker (pwwnow)]

Running a dual-boot system, grub-reboot is the most convenient way to temporarily boot into "the other" OS without maintaining multiple /boot/grub/menu.lst files (especially with regular kernel updates); as of yesterday grub-reboot no longer works.

Until yesterday (20060217), grub-reboot worked fine; according to Synaptic history, grub was changed from 0.95+cvs20040624-17ubuntu7 to 0.97-1ubuntu4 on that day.

/sbin/grub-reboot calls grub as:

default="$1" ; shift
grub --batch $@ <<EOT
savedefault --once --default=$default
quit
EOT

When invoked by grub-reboot, grub reports:
$ grub-reboot 10
Probing devices to guess BIOS drives. This may take a long time.

    GNU GRUB version 0.97 (640K lower / 3072K upper memory)

       [ Minimal BASH-like line editing is supported. For
         the first word, TAB lists possible command
         completions. Anywhere else TAB lists the possible
         completions of a device/filename. ]
grub> savedefault --once --default=10

Error 27: Unrecognized command
grub> quit

Either restore the grub functionality used by grub-reboot, or modify grub-reboot to use appropriate current functionality.

[Peter Whittaker (pwwnow)]

Also occurs in 0.97-1ubuntu5.

[Otavio Salvador (otavio)]

Source: grub
Source-Version: 0.97-6

We believe that the bug you reported is fixed in the latest version of
grub, which is due to be installed in the Debian FTP archive:

grub-disk_0.97-6_all.deb
  to pool/main/g/grub/grub-disk_0.97-6_all.deb
grub-doc_0.97-6_all.deb
  to pool/main/g/grub/grub-doc_0.97-6_all.deb
grub_0.97-6.diff.gz
  to pool/main/g/grub/grub_0.97-6.diff.gz
grub_0.97-6.dsc
  to pool/main/g/grub/grub_0.97-6.dsc
grub_0.97-6_i386.deb
  to pool/main/g/grub/grub_0.97-6_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Otavio Salvador <email address hidden> (supplier of updated grub package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 28 Mar 2006 23:12:45 -0300
Source: grub
Binary: grub-disk grub grub-doc
Architecture: source i386 all
Version: 0.97-6
Distribution: unstable
Urgency: low
Maintainer: Grub Maintainers <email address hidden>
Changed-By: Otavio Salvador <email address hidden>
Description:
 grub - GRand Unified Bootloader
 grub-disk - GRUB bootable disk image
 grub-doc - Documentation for GRand Unified Bootloader
Closes: 254475 293722 341106 341995 342590 353691 353725 355870 357286 357287
Changes:
 grub (0.97-6) unstable; urgency=low
 .
   [ Otavio Salvador ]
   * Applied patch from Colin Watson <email address hidden> to fix segfaults
     in hardware that has NX bit available (amd64, for example).
     (closes: #293722)
   * Remove comment from grub-reboot since we'll have savedefault --once
     back :-D
   * Applied patch from Frans Pop <email address hidden> to invert
     convert_kernel26 logic. (closes: #353725)
   * Change build-dependencie for amd64. (closes: #357287, #357286)
 .
   [ Leandro Dorileo ]
   * Reimplementation of savedefault --once. Now it reads and writes to
     /boot/grub/default.
     (closes: #254475, #341106, #341995, #353691, #355870, #342590)
Files:
 241ba38731a93b52a520ea3dc3f20446 934 admin optional grub_0.97-6.dsc
 3517a7dba99e920408be0bb07a38952d 61082 admin optional grub_0.97-6.diff.gz
 49a4681dab9378585420b2cc2722965a 365796 admin optional grub_0.97-6_i386.deb
 7383ad7d939fef98ed27c6a5aaecc365 236698 admin optional grub-disk_0.97-6_all.deb
 0d547baae2dedb1068bbd9f4d5808a2e 267276 doc optional grub-doc_0.97-6_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEKe1wLqiZQEml+FURAvdSAKCAGvC1zW6IxMF/kFYPfTa45fHVkACePBLG
RsyrLitg8M+6iVUpejMJ0Lw=
=Q7wk
-----END PGP SIGNATURE-----

[Matt Zimmerman (mdz)]

Fix available in Debian

[Michael Vogt (mvo)]

Thanks for your bugreport.

The upload of grub_0.97-1ubuntu9 should fix this problem.

Cheers,
 Michael

[Peter Whittaker (pwwnow)]

I've just tried this a couple of times - grub still picks the first kernel in the list instead of the one I've specified using grub-reboot.

FWIW, at least there are no error messages anymore - but the overall behavior is still in error, since grub boots the wrong kernel.

Here is a "screen capture" showing what happens at the command line:

    $ sudo grub-reboot 2
    Password:
    Searching for GRUB installation directory ... found: /boot/grub
    Probing devices to guess BIOS drives. This may take a long time.

           [ Minimal BASH-like line editing is supported. For
             the first word, TAB lists possible command
             completions. Anywhere else TAB lists the possible
             completions of a device/filename. ]
    grub> savedefault --once --default=2
    grub> quit

    Do you want to reboot now? [y/N] y

I choose yes, grub-reboot reboots the system without further informational or error messages, but instead of the 3rd kernel on this (3-1=2), I get the first one. FWIW, I've attached my /boot/grub/menu.lst.

Also FYI, this system is no longer dual-boot, Windows was toasted a long time ago, so this isn't pressing, but it is annoying.

All of this on a ThinkPad A20m, Edgy (Linux EdgeKeep-PC001 2.6.17-10-386 #2 Fri Oct 13 18:41:40 UTC 2006 i686 GNU/Linux), grub 0.97-11ubuntu14.

[Peter Whittaker (pwwnow)]

Not sure what status to use: The fix doesn't address the problem, it isn't "unconfirmed", and it is bad netiquette to confirm one's own reports. Ergo, "needs info", as in I need info about what status to use! :->

[qtaro (icsolution)]

1) I also have this problem, I can run the command with 0.97-1ubuntu9, but after it reboots, grub still asked which os to boot. I think it might be due to /sbin/grub-set-default , as mentioned in here:

http://sidvind.com/wiki/GRUB:_Boot_another_OS_once

2) if you fix it, do you think you could add a "-c" or "--confirm" so it won't prompt me if I really want to reboot it? now it asked y/n, very annoying. Let me know if I should file a RFE(request for enhancement).

thanks.

[Modestas Vainius (geromanas)]

reopen 254475
found 254475 0.97-21
block 354003 by 254475
thanks

Hi,

sorry, but the bug is still not fixed or was reintroduced. When executing the
command below in the grub shell (# grub) (when debian is up & running)

  savedefault --once --default=<number>

it does indeed modify /boot/grub/default, but the problem is that grub seems
to no longer use this file when selecting the default title. I
rm'ed /boot/grub/default and grub still knew on the next boot which title had
been previously savedefault'ed (last booted).

I have "default saved" in /boot/grub/menu.lst and "savedefault" statements
in /boot/grub/menu.lst work as expected, because grub selects the previously
booted title as default on the next boot. It's just that savedefault in the #
grub shell does not work. Neither does grub-reboot.

#254475 blocks #354003 because kdm uses the following code to set default
title for the next boot:

----
commitGrub( void )
{
        FILE *f;
        int pid;
        static const char *args[] = { 0, "--batch", "--no-floppy", 0 };

        if (sdRec.bmstamp != mTime( GRUB_MENU ) &&
            setGrub( sdRec.osname, &sdRec ) != BO_OK)
                return;

        args[0] = grub;
        if ((f = pOpen( (char **)args, 'w', &pid ))) {
                fprintf( f, "savedefault --default=%d --once\n",
sdRec.osindex );
                pClose( f, pid );
        }
}
-----

[Modestas Vainius (geromanas)]

notfound 254475 0.97-21
close 254475 0.97-6
unblock 354003 by 254475
thanks

Hi,

sorry, the bug is fixed, I failed to do the steps below properly:

>recopy the stage files
>rerun grub-install

Why aren't they automated somehow?

[Otavio Salvador (otavio)]

Modestas Vainius <email address hidden> writes:

> notfound 254475 0.97-21
> close 254475 0.97-6
> unblock 354003 by 254475
> thanks
>
> Hi,
>
> sorry, the bug is fixed, I failed to do the steps below properly:
>
>>recopy the stage files
>>rerun grub-install
>
> Why aren't they automated somehow?

It's dangerous since it can make the system unbootable and then we
prefer to leave it to the user.

--
        O T A V I O S A L V A D O R
---------------------------------------------
 E-mail: <email address hidden> UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

[Peter Whittaker (pwwnow)]

Marking as "needs info" because there really isn't a "grr, it still doesn't work" status.

I've just tried this under Feisty (grub 0.97-20ubuntu3 ) and grub-reboot does not perform as advertised: /boot/grub/default DOES get updated, but the system DOES NOT boot into the desired OS, it still boots into the "top of the list".

debbugs #254475 mentions having to run more commands after running grub-set-default in order for that command to work. Perhaps this is the problem with grub-reboot: It DOES NOT run more commands, it simply asks the user if they wish to reboot. If the user chooses YES, then nothing useful happens - the system reboots but into the wrong OS.

Please refer to the following "capture":

$ uname -a
Linux EdgeKeep-PC001 2.6.20-5-generic #2 SMP Sat Jan 6 14:50:47 UTC 2007 i686 GNU/Linux
$ grub-reboot -v
grub-reboot 0.01
$ su
root@EdgeKeep-PC001:/home/pww# head -1 /boot/grub/default
0
root@EdgeKeep-PC001:/home/pww# grub-reboot 2
Searching for GRUB installation directory ... found: /boot/grub
Probing devices to guess BIOS drives. This may take a long time.

       [ Minimal BASH-like line editing is supported. For
         the first word, TAB lists possible command
         completions. Anywhere else TAB lists the possible
         completions of a device/filename. ]
grub> savedefault --once --default=2
grub> quit

Do you want to reboot now? [y/N] n
root@EdgeKeep-PC001:/home/pww# head -1 /boot/grub/default
0:2
root@EdgeKeep-PC001:/home/pww# tail -5 /usr/sbin/grub-reboot
echo -n "Do you want to reboot now? [y/N] "
read REBOOT
case $REBOOT in
  y*|Y*) reboot ;;
esac
root@EdgeKeep-PC001:/home/pww# exit
$

The default file is updated, and we see the user is asked if they wish to reboot. We also see that if reboot is selected, we go there directly, without running any additional commands (and the only grub or other system administration commands in grub-reboot are the call to grub to set the default and reboot - so there's nothing else to run!).

(The comments in the debbugs report appear to contradict the on-line gnu grub manual, since the latter implies - if not states explicitly - that running grub-set-default $theEntryYouWant is enough to get the right one booted.)

It all comes down to this: Should grub-reboot be all there is to it?

If yes, then grub-reboot should run all commands necessary to set the "next to boot OS" as specified on its command line.

If no, then grub-reboot should not ask the user whether they wish to reboot, it should tell them what they have to do.

[Pascal De Vuyst (pascal-devuyst)]

Peter Whittaker wrote:
> Marking as "needs info" because there really isn't a "grr, it still
> doesn't work" status.

As the bug reporter you should not set bug status "Needs info". Needs info is used by bug triagers to ask additional information to be able to reproduce the problem if the bug reporter has not provided enough information.
Needs info is not meant for asking questions to developers.

If somebody else (in this case qtaro) has the same problem then this bug can be marked "Confirmed". Confirmed means the bug can be reproduced by somebody else. This also ensures that the bug is applicable to Ubuntu in general, and not an accidental problem with the reporter's system.

Developers normally only look at confirmed bugs, they don't have time to ask for extra information: this is the task of a bug triager.
Bugs marked as "Needs info" are likely to be ignored by a developer since this indicates that the bug has not enough information to reproduce it.

As a member of the Ubuntu BugSquad please read about status in https://wiki.ubuntu.com/Bugs/CommonTasks.

This bug should be marked as "Confirmed" since qtaro has the same problem.

[Peter Whittaker (pwwnow)]

On Sun, 2007-01-21 at 14:42 +0000, Pascal De Vuyst wrote:
Peter Whittaker wrote:
> As the bug reporter you should not set bug status "Needs info".

Pascal, please read my comments again. The status before I made the change *was* confirmed (it was marked this way by someone else who had been able to confirm this). I marked it as "needs info" because there is no good status to reflect the status of this bug: The upstream version is marked as "fix released" and the fix fixes nothing.

With status "grub (ubuntu) Confirmed" and "grub (Debian) Fix released", how likely is it that it will receive any more attention?

If one reads the upstream bug report and the GNU manual, one gets conflicting ideas as to the correct course of action. We need to determine the correct course of action to determine how to fix the bug (and perhaps the bug fix is to eliminate grub-reboot from Ubuntu - that's legitimate).

As for asking questions of the developers, well, isn't asking questions a legitimate conversational tool (refer to "helping with bugs" re reports being a conversation with the developers), a legitimate form of discourse and inquiry?

The released fix doesn't work. There is no good status for this. What should we do?

There is apparent disagreement over the correct course of action. Is the bug report not an appropriate forum for that discussion?

[Ian Jackson (ijackson)]

Peter Whittaker writes ("[Bug 31915] Re: Latest grub package (0.97-1ubuntu4) breaks /sbin/grub-reboot"):
> With status "grub (ubuntu) Confirmed" and "grub (Debian) Fix released",
> how likely is it that it will receive any more attention?

If the bug were important, we could spend some effort cross-porting
the fix from Debian.

> The released fix doesn't work. There is no good status for this. What
> should we do?

Are you saying that the bug is not fixed in Debian ? Are you a Debian
user ? If you are a Debian user and the bug is still present in the
Debian version (ie, the Debian BTS is inaccurate) then you should use
the Debian BTS to inform Debian of this.

`grub (Debian) Fix released' means that Debian think they have fixed
it (although `Fix released' is probably optimistic since I presume
that this corresponds to a fixed version being in sid or perhaps
etch; Launchpad does not fully capture all of the version-specific
information available in Debian).

`grub (ubuntu) Confirmed' means that we think the bug is still present
in Ubuntu.

Ian.

[Peter Whittaker (pwwnow)]

I agree that that's what it should mean, but I believe this bug stopped receiving attention after comment #3, which suggested that grub_0.97-1ubuntu9 fixed the problem (which it didn't).

Leaving aside discussion of our overloaded "confirmed" state, there is an open question of "correct" behavior. Naively, grub-reboot should cause the next boot to be as requested, but the discussion in the debbug around the behavior of grub-set-default suggests the debian version of grub may be diverging from the behavior described in the GNU manual. This may be my misinterpretation, that's all too possible.

Should we fix grub-reboot or remove it? Which is the right direction?

[qtaro (icsolution)]

I vote for "fixing it"!

It's very convenient command.

[baiti (baiti)]

On a running Debian Etch system:

If I do a "grub-set-default 1" the file /boot/grub/defaults
shows a "1" as the first character.

If I then do a "grub-reboot 0" and exit the grub shell without actually
rebooting, and then look at /boot/grub/defaults it shows "0:0" as the
first three characters.

The way I read the sources it should read "1:0" which means the next
reboot should boot entry "0" and the next after that should go back to "1".

As a matter of fact, if I manually (with vi) change /boot/grub/defaults
to read "1:0" and then I do a regular reboot, then it boots "0" and the
next time it goes back to "1".

--
Friedemann Baitinger <email address hidden>

[baiti (baiti)]

have spent some time debugging the problem. I believe I have found two bugs:

The file /boot/grub/default was opened in read-only mode:

fopen(file, "r");

Later we're trying to write to it. In addition, the function
"read(&line, -1)" doesn't seem to do what it is supposed to do. "line"
always has garbage afterwards", needless to say that the two values we
later want to sscanf() out if it never get a value assigned so they stay
at the static initialized values of "-1". I don't know where
"read(&line, -1)" really reads from and where its prototype is declared
nor what library implements it but it definitely doesn't do what it is
supposed to do.

Here is a patch that I have verified that it really works:

--- builtins.c.orig 2007-01-28 16:46:18.000000000 +0100
+++ builtins.c 2007-01-28 18:33:17.000000000 +0100
@@ -3574,16 +3574,16 @@
    default_file[i] = 0;
    grub_strncat (default_file + i, "default", DEFAULT_FILE_BUFLEN - i);

- if(!(fp = fopen(default_file,"w")))
+ if(!(fp = fopen(default_file,"r+")))
      {
        errnum = ERR_READ;
        goto fail;
      }

- read(&line, -1);
-
+ fgets(line, bytes, fp);
+
    sscanf(line, "%d:%d", &curr_prev_default, &curr_default);
-
+
    if(curr_default != -1)
      new_prev_default = curr_default;
    else
@@ -3599,6 +3599,7 @@
    else
      sprintf(buf, "%d\n", new_default);

+ rewind(fp);
    fprintf(fp, buf);

  fail:

--
Friedemann Baitinger <email address hidden>

[baiti (baiti)]

sorry for the noise ... but I have to report additional findings as the
patch above really has some side-effects.

The previous version of my patch opened the /boot/grub/defaults file in
"r+" mode so I could read the initial values, do a "rewind(fp)" and
write the new values. Unfortunately the "grub-reboot" script keeps to
append new comments and disclaimer lines, effectively making the file
grow and grow.

So the only thing that really works here is to open the file read-only,
read the initial values, then close it and reopen it in "w" mode which
truncates it to zero before we write to it. Now we write the new "x:y"
values and let the script to its job of adding comment lines and
disclaimers.

Also, the original code added a newline where "grub-set-default" didn't
have one. Not a big deal, shouldn't change the functionality but it
isn't the same layout as before anymore.

To make a long story short, here is a new patch which *should* do the
job now as expected:

--- builtins.c.orig 2007-01-28 16:46:18.000000000 +0100
+++ builtins.c 2007-01-28 21:25:29.000000000 +0100
@@ -3574,16 +3574,17 @@
    default_file[i] = 0;
    grub_strncat (default_file + i, "default", DEFAULT_FILE_BUFLEN - i);

- if(!(fp = fopen(default_file,"w")))
+ if(!(fp = fopen(default_file,"r")))
      {
        errnum = ERR_READ;
        goto fail;
      }

- read(&line, -1);
-
+ fgets(line, bytes, fp);
+ fclose(fp);
+
    sscanf(line, "%d:%d", &curr_prev_default, &curr_default);
-
+
    if(curr_default != -1)
      new_prev_default = curr_default;
    else
@@ -3595,10 +3596,16 @@
      }

    if(once_only)
- sprintf(buf, "%d:%d\n", new_prev_default, new_default);
+ sprintf(buf, "%d:%d", new_prev_default, new_default);
    else
- sprintf(buf, "%d\n", new_default);
-
+ sprintf(buf, "%d", new_default);
+
+ if(!(fp = fopen(default_file,"w")))
+ {
+ errnum = ERR_READ;
+ goto fail;
+ }
+
    fprintf(fp, buf);

  fail:

--
Friedemann Baitinger <email address hidden>

[Otavio Salvador (otavio)]

# Automatically generated email from bts, devscripts version 2.9.27
reopen 254475

[dorileo (ldorileo)]

Hi Friedemann

Your changes has been applied to grub and is going to be present in the next
release. Thanks for your help on it.

--
Dorileo

On Sunday 28 January 2007 20:35, Friedemann Baitinger wrote:
> sorry for the noise ... but I have to report additional findings as the
> patch above really has some side-effects.
>
> The previous version of my patch opened the /boot/grub/defaults file in
> "r+" mode so I could read the initial values, do a "rewind(fp)" and
> write the new values. Unfortunately the "grub-reboot" script keeps to
> append new comments and disclaimer lines, effectively making the file
> grow and grow.
>
> So the only thing that really works here is to open the file read-only,
> read the initial values, then close it and reopen it in "w" mode which
> truncates it to zero before we write to it. Now we write the new "x:y"
> values and let the script to its job of adding comment lines and
> disclaimers.
>
> Also, the original code added a newline where "grub-set-default" didn't
> have one. Not a big deal, shouldn't change the functionality but it
> isn't the same layout as before anymore.
>
> To make a long story short, here is a new patch which *should* do the
> job now as expected:
>
> --- builtins.c.orig 2007-01-28 16:46:18.000000000 +0100
> +++ builtins.c 2007-01-28 21:25:29.000000000 +0100
> @@ -3574,16 +3574,17 @@
> default_file[i] = 0;
> grub_strncat (default_file + i, "default", DEFAULT_FILE_BUFLEN - i);
>
> - if(!(fp = fopen(default_file,"w")))
> + if(!(fp = fopen(default_file,"r")))
> {
> errnum = ERR_READ;
> goto fail;
> }
>
> - read(&line, -1);
> -
> + fgets(line, bytes, fp);
> + fclose(fp);
> +
> sscanf(line, "%d:%d", &curr_prev_default, &curr_default);
> -
> +
> if(curr_default != -1)
> new_prev_default = curr_default;
> else
> @@ -3595,10 +3596,16 @@
> }
>
> if(once_only)
> - sprintf(buf, "%d:%d\n", new_prev_default, new_default);
> + sprintf(buf, "%d:%d", new_prev_default, new_default);
> else
> - sprintf(buf, "%d\n", new_default);
> -
> + sprintf(buf, "%d", new_default);
> +
> + if(!(fp = fopen(default_file,"w")))
> + {
> + errnum = ERR_READ;
> + goto fail;
> + }
> +
> fprintf(fp, buf);
>
> fail:

--
Dorileo

[Otavio Salvador (otavio-ossystems)]

Source: grub
Source-Version: 0.97-24

We believe that the bug you reported is fixed in the latest version of
grub, which is due to be installed in the Debian FTP archive:

grub-disk_0.97-24_all.deb
  to pool/main/g/grub/grub-disk_0.97-24_all.deb
grub-doc_0.97-24_all.deb
  to pool/main/g/grub/grub-doc_0.97-24_all.deb
grub_0.97-24.diff.gz
  to pool/main/g/grub/grub_0.97-24.diff.gz
grub_0.97-24.dsc
  to pool/main/g/grub/grub_0.97-24.dsc
grub_0.97-24_i386.deb
  to pool/main/g/grub/grub_0.97-24_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Otavio Salvador <email address hidden> (supplier of updated grub package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 20 Mar 2007 23:37:46 -0300
Source: grub
Binary: grub-disk grub grub-doc
Architecture: source i386 all
Version: 0.97-24
Distribution: unstable
Urgency: high
Maintainer: Grub Maintainers <email address hidden>
Changed-By: Otavio Salvador <email address hidden>
Description:
 grub - GRand Unified Bootloader
 grub-disk - GRUB bootable disk image
 grub-doc - Documentation for GRand Unified Bootloader
Closes: 254475 411109 412334
Changes:
 grub (0.97-24) unstable; urgency=high
 .
   [ Leandro Dorileo ]
   * Changed grub-set-default to search for grub dir if rootdir is not
     informed. Closes: #411109, #412334
   * Applied changes from Friedemann Baitinger <email address hidden>
     to savedefault-once. closes: #254475
Files:
 632cfbc563a7c7ddb9c21350263d390f 896 admin optional grub_0.97-24.dsc
 d16ece5ef325044a3094862b15e3d2bf 75176 admin optional grub_0.97-24.diff.gz
 77c7c1b88b070fb2b3c226d61da70aca 374792 admin optional grub_0.97-24_i386.deb
 6f3e3a5796cd4af191e5e2a1f609cea9 244250 admin optional grub-disk_0.97-24_all.deb
 b538a383eb95e62668a5f6e4caa0ed64 272404 doc optional grub-doc_0.97-24_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGAJslLqiZQEml+FURAnirAJ416A0WMX7D7g09QUZqbZHOdbkHuACfevcF
qqw4KZsog47MP9SlTotxsII=
=qPxJ
-----END PGP SIGNATURE-----

[Olivier Bonvalet (olivier-bonvalet)]

Hello,

I'm not sure it's a bug or "a feature" : with etch and Grub 0.97,
grub-reboot seems to only works well if "default" is set at "saved" in
menu.lst.

But on sarge and grub 0.95, grub-reboot works without this (I had
"default 0"
and was able to boot on 1 with grub-reboot, for example).

Is this a bug or not ?

Thanks
Olivier

[Rolf Leggewie (r0lf)]

I can also confirm both the problem (debian edgy, grub version 0.97-11ubuntu14) and that Ian did a fine job of explaining the intracacies of launchpad and the semantics as understood by ubuntu ;-)

Copying over some information from debian bug 254475
* you need to have "default saved" in your menu.lst, not "default $somenumber"
* you can achieve the desired behaviour by putting "$numberyouwanttobootnext:$numberofdefaultboot" into /boot/grub/defaults
  as Friedemann Baitinger wrote on Jan 28, 16:30:18
* debian fixed this by applying a patch that Friedemann Baitinger sent on Jan 28, 21:35:29. I suppose ubuntu could do the same.

[Wouter Stomp (wouterstomp-deactivatedaccount)]

This was fixed in 0.97-24

[Rolf Leggewie (r0lf)]

I am happy to verify Wouter's claim. The version 0.97-29ubuntu4 in gutsy indeed is free from this issue.