http://bugzilla.suse.com/show_bug.cgi?id=960517 http://bugzilla.suse.com/show_bug.cgi?id=960517#c1 Jiri Srain changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jimc@math.ucla.edu, | |jsrain@suse.com Assignee|jsrain@suse.com |mchang@suse.com Flags| |needinfo?(jimc@math.ucla.ed | |u) --- Comment #1 from Jiri Srain --- I would be surprised if GRUB didn't install itself. What's the content of your /etc/default/grub_installdevice ? Does it point to MBR of the right disk? If it points elsewhere, it is likely that GRUB updates its stage1 in the specified location and the system boots just because GRUB being installed to MBR sometime in the past... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960517 http://bugzilla.suse.com/show_bug.cgi?id=960517#c3 --- Comment #3 from Jiri Srain --- I think that the file explains your behavior, especially in contrast with grub2-install /dev/sda you mentioned above. My assumption as that after installation, MBR was occupied with the generic code, which loads boot sector of the partition with the active flag, and this boot sector contained GRUB. Then, from some reason, you ran grub2-install /dev/sda for the first time, which replaced the generic code in MBR with GRUB, however, you did not change the configuration file. Then, when GRUB got upgraded, it updated itself in the boot sector (according to the configuration file), but since there is no update of the generic MBR code, there was no need to update it. However, since you ran grub2-install /dev/sda, the code in MBR pointed to stuff which belonged to GRUB version you just removed. Detecting this is not really possible - even if there is GRUB code in MBR, it may belong to other instance of GRUB on the same machine, which chainloads your system, and therefore reinstalling it would break such set-ups. I think that you should either adjust GRUB configuration file to install to MBR on next update, or restore the generic booting code in your MBR. Then, I believe, GRUB updates should work for you. Michael, did I miss anything? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=960517 http://bugzilla.suse.com/show_bug.cgi?id=960517#c5 James Carter changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from James Carter --- @Jiri, @Michael, thanks very much for the explanation. I changed the drive to (hd0), which gets the correct drive on all my work and home machines. I restored the saved image of v13.1 on my virtual machine, edited /etc/default/grub_installdevice, and was able to upgrade it and survive the reboot afterward. Some people boot off a disc other than the first, or a USB stick, or a tamper-resistant CD. I had a machine once with four discs that would enumerate them in a random order. In that case a device path like /dev/disk/by-id/ata-ST9750420AS_5WS4F4QQ is more reliable. The reason I switched to the root partition's boot sector was, I noticed that the installer's default was that way, and I just left the default in place. Bad move. I've set the bug's status to resolved. -- You are receiving this mail because: You are on the CC list for the bug.