Regression: grub - Error 18 when using savedefault (feisty/edgy)

Since I installed grub from Dapper no more problems appeared.

BTW
I never had any problems like this with hoary, breezy or dapper on this machine.

Some additional info:

Mainboard/BIOS:
ASUSTeK Computer INC.
MED 2001
REV 1.xx
Award Modular BIOS v6.0
ASUS MED 2001 ACPI BIOS Revision 1009
06/12/2001-VT694X-MED 2001

$fdisk -l
Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot Start End Blocks Id System
/dev/hda1 * 1 192 1542208+ b W95 FAT32
/dev/hda2 193 714 4192965 b W95 FAT32
/dev/hda3 715 975 2096482+ b W95 FAT32
/dev/hda4 976 9729 70316505 f W95 Ext'd (LBA)
/dev/hda5 976 1913 7534422 83 Linux
/dev/hda6 1914 2015 819283+ 82 Linux swap / Solaris
/dev/hda7 2016 3008 7976209+ 83 Linux
/dev/hda8 3009 8575 44716896 83 Linux
/dev/hda9 8576 9729 9269473+ c W95 FAT32 (LBA)

$sudo cat /proc/ide/ide0/hda/geometry
physical 16383/16/63
logical 65535/16/63
$sudo cat /proc/ide/ide0/hda/capacity
156301488
$sudo cat /proc/ide/ide0/hda/model
WDC WD800JB-00JJA0

I found a similar bug in Debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356863

Machine is Fujitsu Scaleo 600 there.

What does running
/usr/bin/sudo dmidecode | grep -C 3 -i date
say?

/usr/bin/sudo dmidecode | grep -C 3 -i date
says:
BIOS Information
        Vendor: Award Software, Inc.
        Version: ASUS MED 2001 ACPI BIOS Revision 1009
        Release Date: 06/12/2001
        Address: 0xF0000
        Runtime Size: 64 kB
        ROM Size: 256 kB

Hmm. Sometimes old BIOSes can't boot files past the 1023rd cylinder. What can happen is that initially after the install, all the data needed by grub to boot falls below that limit. However it could be that after installing a new kernel/upgrading your distro has caused some of the needed data to be beyond cylinder 1023 and thus a problem occurs.

I am working on the idea that BIOSes after a certain date won't manifest this problem...

I forgot to mention, this might be related to bug #9006 .

But I could boot it again by simply using an older version of grub _without_ any change to the disks. Additionaly my root is entierly above cyl. 1023 as you can see here:

$sudo fdisk -l

Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot Start End Blocks Id System
/dev/hda1 * 1 192 1542208+ b W95 FAT32
/dev/hda2 193 714 4192965 b W95 FAT32
/dev/hda3 715 975 2096482+ b W95 FAT32
/dev/hda4 976 9729 70316505 f W95 Ext'd (LBA)
/dev/hda5 976 1913 7534422 83 Linux
/dev/hda6 1914 2015 819283+ 82 Linux swap / Solaris
/dev/hda7 2016 3008 7976209+ 83 Linux
/dev/hda8 3009 8575 44716896 83 Linux
/dev/hda9 8576 9729 9269473+ c W95 FAT32 (LBA)

$LANG=C df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda7 7.5G 4.6G 2.6G 65% /
varrun 189M 100K 189M 1% /var/run
varlock 189M 0 189M 0% /var/lock
procbususb 10M 140K 9.9M 2% /proc/bus/usb
udev 10M 140K 9.9M 2% /dev
devshm 189M 0 189M 0% /dev/shm
lrm 189M 20M 170M 11% /lib/modules/2.6.17-11-generic/volatile
/dev/hda8 42G 24G 17G 60% /home

Kurt:

An excellent point regarding the start of the partition. Clearly the 1023rd cylinder problem can't be to blame.

This happens on feisty to (grub 0.97-20ubuntu3)

Meanwhile I changed my partitions for some other reason and created a boot partition too at this opportunity.

Further I found this today:
http://www.gnu.org/software/grub/manual/html_node/Stage2-errors.html
[Error] 18 : Selected cylinder exceeds maximum supported by BIOS
    This error is returned when a read is ttempted at a linear block address beyond the end of the BIOS translated area. This generally happens if your disk is larger than the BIOS can handle (512MB for (E)IDE disks on older machines or larger than 8GB in general).

So I made my system use /dev/hda3 (which is entirely below 8GB) as /boot and reinstalled grub from feisty (doing grub-install /dev/hda too) today.

Now, lets see if it happens again ...
(booted successfully by now)

My new partition table:

sudo fdisk -l

Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot Start End Blocks Id System
/dev/hda1 * 1 192 1542208+ b W95 FAT32
/dev/hda2 193 714 4192965 b W95 FAT32
/dev/hda3 715 733 152617+ 83 Linux
/dev/hda4 734 9729 72260370 f W95 Ext'd (LBA)
/dev/hda5 976 1913 7534422 83 Linux
/dev/hda6 1914 2015 819283+ 82 Linux swap / Solaris
/dev/hda7 2016 3008 7976209+ 83 Linux
/dev/hda8 3009 8575 44716896 83 Linux
/dev/hda9 8576 9729 9269473+ 83 Linux
/dev/hda10 734 975 1943802 b W95 FAT32

Partition table entries are not in disk order

It happend again right when trying to boot the first menu entry for the second time and each time after that.

Manual booting from grub command line worked without problems, but at command savedefault it sayed :
  Error 27: command not recognized

Booting an alternative entry with same kernel worked too.
(There is no savedefault)

After I disabled
   echo savedefault --default=$menuentry |
   /usr/sbin/grub_bin --batch
in some extra script in /etc/acpi/suspend.d which I have allready there since dapper and doing
   sudo grub-install
grub worked normal again. (tried one time so far)

So, the bug seems to be broken/missing support of command savedefault in /usr/bin/grub and/or grub boot-loader itself.

Changing summary

I am using Feisty most recent beta. Decided the first time to hibernate. Seemed to work. As i restarted I got grub error 18 and no way to reactivate Grub. Tried all including root (hd0,0) and install (hd0). and anything I found in our forums. All responded correctly, only the /boot/grub/stage2 is not to find.
Hope that there is a solution to get the hd0 back to work.
I run amd64 generic. Any question welcome. How to get the hibernate info out and to start new without to lose the data?

Webmania:
That is more of a support request. I recommend asking that question over on https://answers.launchpad.net/ on the mailing lists/forums or in IRC (http://www.ubuntu.com/support/CommunitySupport ).

THANK YOU, I WILL DO SO, BUT PLEASE READ BELOW AND IF POSSIBLE GIVE ME YOUR
THOUGHTS ABOUT IT:
I guess its more a general question for Kubuntu/Ubuntu. I used the latest
Kubuntu Beta disk with System recovery, REINSTALLED GRUB, and as result my
MBR was destroyed..after I rebooted. I Tried a lot of utilitis (even from
Windows) to recover that MBR but no way. All utilities explained that hd0
starts incorrectly not at 0 but 63.... And no way to fix that. So I
reformed my HD and did set Kubuntu fresh. Lost a lot. Its real pity that
there is not such nice system recovery system as under windows. Why by
the... under Ubuntu it is not possible to set a new system without to use a
new partition? If there is a partition prior used by (k)ubuntu then it
should be possible to copy the system again. Sure some programs needs
afterwards new installed, but data losses would be avoided. Will post that
tomorrow also under support as it is incredible that such a good Linux
system is unable to restore systems without data losses. A new partition for
any setup is a bad joke I think.

On 4/12/07, Sitsofe Wheeler <email address hidden> wrote:
>
> Webmania:
> That is more of a support request. I recommend asking that question over
> on https://answers.launchpad.net/ on the mailing lists/forums or in IRC (
> http://www.ubuntu.com/support/CommunitySupport ).
>
> --
> Regression: grub - Error 18 when using savedefault (feisty/edgy)
> https://bugs.launchpad.net/bugs/79578
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Webmania:
If this issue is repeatable I strongly advise you to file a separate bug. It would be wonderful to know what causes this situation to occur and the steps required to rectify it without having to reformat.

I did reformat! Tried all I could find at the forums, then I tried the
latest Beta disk (system recovery) and installed an new Grub, rebooted and
no more HD to find.... MBR destroyed and then I tried several HD recover
programs with no way to get the MBR restored. HD refused to accept repair
actions.... So I reformatted with PartLogic and setup Kubuntu again. Thats
why I don't hope that I will enter again a new Error 18.... Will file a bug
later today for sure.

On 4/13/07, Sitsofe Wheeler <email address hidden> wrote:
>
> Webmania:
> If this issue is repeatable I strongly advise you to file a separate bug.
> It would be wonderful to know what causes this situation to occur and the
> steps required to rectify it without having to reformat.
>
> --
> Regression: grub - Error 18 when using savedefault (feisty/edgy)
> https://bugs.launchpad.net/bugs/79578
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I'd like to point out that this also happens to me on Feisty on an ext3 root partition, since I deleted and re-added the file /boot/grub/default on a large partition. I'm not qualified when it comes to file systems, but maybe this is related to the fact that in the original setup, the file was contained within a BIOS-translatable address space, and I re-created it somewhere outside this address space.

To give proof, I'd have to move the existing file somewhere to the beginning of the file system, but I fail to see how.

I think I now verified the last assumption. I copied a file that has been created very early on the FS (in this case "menu.lst"), and moved it to "default", overwriting the problematic file. Then I recreated "menu.lst" using cp from "default", and sanitized "default" grub-set-default. Now the boot process works fine again.

Just to add that I've also had the same problem as Christian Neumair - namely a Grub error 18 on 7.04 due to trying to access the default file.

A more helpful error message would be good - I went through all sorts of things before I worked out what was causing it.

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

I had the same problem yesterday on intrepid. I have a very simple installation of Kubuntu and Windows 2000. After using grub-reboot and booting into windows savedefault fails with grub error 18. removing savedefault command allows the machine to boot into ubuntu again.

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. If you could test the current Ubuntu development version, this would help us a lot. If you can test it, and it is still an issue, we would appreciate if you could upload updated logs by running apport-collect <bug #>, and any other logs that are relevant for this particular issue.