Bug 144688

I had the same problems after first stage of installation of beta2.

The strange thing: I booted the recovery system, chrooted to the installed system and called "grub-install /dev/hda" without changing any configuration file. This made it working...

Same problem (and workaround) while updating beta2 -> beta3 :-(

However, a non-booting system is (at least) a major problem - many users don't know what to do in this case.

The problem reappeared when updating from beta3 to beta6 :-((

This time, I saved the MBR before and after manually running "grub-install /dev/hda" as described in comment #1.

Here is the result:

--- mbr-grub-broken-dump      <-- non-working state after installation stage 1
+++ mbr-grub-working-dump     <-- working state after running grub-install
@@ -1,15 +1,15 @@
 0000  eb 48 90 d0 bc 00 7c fb  50 07 50 1f fc be 1b 7c  ëH.ÐŒ.|û P.P.üŸ.|
 0010  bf 1b 06 50 57 b9 e5 01  f3 a4 cb be be 07 b1 04  ¿..PW¹å. ó€ËŸŸ.±.
 0020  38 2c 7c 09 75 15 83 c6  10 e2 f5 cd 18 8b 14 8b  8,|.u..Æ .âõÍ....
 0030  ee 83 c6 10 49 74 16 38  2c 74 f6 be 10 07 03 02  î.Æ.It.8 ,töŸ....
-0040  ff 00 00 80 8a b6 7c 00  00 08 fa 90 90 f6 c2 80  ÿ....¶|. ..ú..öÂ.
+0040  ff 00 00 20 01 00 00 00  00 02 fa 90 90 f6 c2 80  ÿ.. .... ..ú..öÂ.
 0050  75 02 b2 80 ea 59 7c 00  00 31 c0 8e d8 8e d0 bc  u.².êY|. .1À.Ø.ÐŒ
 0060  00 20 fb a0 40 7c 3c ff  74 02 88 c2 52 be 81 7d  . û| @|<ÿ t..ÂRŸ.}
 0070  e8 36 01 f6 c2 80 74 56  b4 41 bb aa 55 cd 13 5a  è6.öÂ.tV ŽA»ªUÍ.Z
 0080  52 72 4b 81 fb 55 aa 75  45 a0 41 7c 84 c0 78 3e  RrK.ûUªu E| A|.Àx>
 0090  75 05 83 e1 01 74 37 66  8b 4c 10 be 05 7c c6 44  u..á.t7f .L.Ÿ.|ÆD
 00a0  ff 01 66 8b 1e 44 7c c7  04 10 00 c7 44 02 01 00  ÿ.f..D|Ç ...ÇD...
 00b0  66 89 5c 08 c7 44 06 00  70 66 31 c0 89 44 04 66  f.\.ÇD.. pf1À.D.f
 00c0  89 44 0c b4 42 cd 13 72  05 bb 00 70 eb 7d b4 08  .D.ŽBÍ.r .».pë}Ž.
 00d0  cd 13 73 0a f6 c2 80 0f  84 e8 00 e9 8d 00 be 05  Í.s.öÂ.. .è.é..Ÿ.
 00e0  7c c6 44 ff 00 66 31 c0  88 f0 40 66 89 44 04 31  |ÆDÿ.f1À .ð@f.D.1

This is the only difference that appeared in the first MB of my harddisk.
(If you need more context, just ask.)

/etc/grub.conf would be nice, as well as /boot/grub/menu.lst.

Created attachment 71627 [details]
/etc/grub.conf

Created attachment 71629 [details]
/boot/grub/menu.lst

passwords masked with *** ;-)

The grub.conf is fairly bogus. It installs *two* bootloaders -- almost!
Both share stage2 of the current system, which cannot work.

This grub.conf was autogenerated? That code is definitely buggy.

regarding passwords: the kern of MD5 is found to be non-zero, and collisions were produced, but an inverse function is not yet known ;-)

(In reply to comment #7)
> This grub.conf was autogenerated? That code is definitely buggy.

I never edited it manually IIRC - but the problem may be caused by an earlier SUSE release. On my 10.0 system (cloned for the 10.1 update) the /etc/grub.conf is:

root (hd0,4)
install --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0) /boot/grub/stage2 
    0x8000 (hd0,4)/boot/grub/menu.lst
install --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0,4) /boot/grub/stage2 
    0x8000 (hd0,4)/boot/grub/menu.lst
quit

> regarding passwords: the kern of MD5 is found to be non-zero, and collisions
> were produced, but an inverse function is not yet known ;-)

brute-force?
But maybe I'm just too paranoid ;-)

I now tried an update twice, both time it worked fine. Seems not to be a general problem -> reduce to major

Handing over to perl-Bootloader to check the grub.conf writing

hm, looks like new entries are always appended to grub.conf 

Code looks fine. As we could not reproduce the problem, I will close the bug here.

Our guess is that the original system has been copied from somewhere else (hda5?)
and new entries have been added correctly be yast2 bootloader

I will upgrade to beta8 tomorrow and would like to test with a "known good" grub.conf.

Can you give me an example, please? How would a valid grub.conf for hda7 look like?

I changed my grub.conf to the following (taken from a fresh 10.1 installation):

    setup --stage2=/boot/grub/stage2 (hd0,6) (hd0,6)
    quit

and grub worked after updating beta6 to beta8. The broken grub.conf really seems to be the reason of the problem.

BUT:
My other machine running a fresh 10.0 installation (+ YOU updates) has the following broken /etc/grub.conf:

root (hd0,1)
install --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0,1) /boot/grub/stage2 
    0x8000 (hd0,1)/boot/grub/menu.lst
install --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0) /boot/grub/stage2 
    0x8000 (hd0,1)/boot/grub/menu.lst
quit

Since I got a broken grub.conf on two completely different 10.0 installations (one was an update with full package selection on my laptop, the other was a fresh minimal installation on an older desktop machine), you should really check (and fix) the grub.conf on update.

Please note, that the latter grub.conf in comment #13 is perfectly ok.
The only thing it does is writing to the partition boot record _and_ the
master boot record.

The broken one from the attachment in comment #5 orders to write two different
bootloaders to different partitions pointing to two different menu file.

I already checked and reviewed the code that alters the grub.conf together with another collegue. The code is ok an there´s no way to work around pilot errors
like the above, sorry.

Torsten could you please have a second look at my statement about the grub.conf
above, thanks. 

Indeed, the grub.conf in comment #13 is perfectly valid. IIRC the rule is that if you choose to ruin your MBR by installing a stage1 into it, a second path to the stage2 is started from the boot/root partition to ease eventual recovery, after a sane generic MBR has been restored.

Also no more problems in 10.1 final or 10.2 (beta and final) -> VERIFIED