I have OS 12.2 on two machines, a laptop and a [basically] headless server. Everything is fine on the laptop, but often times when I perform an updated on the server, it breaks GRUB.
The first time everything was working fine, I did a “zypper up”, numerous packages were installed, then I rebooted. On boot, GRUB wouldn’t even load, as if the installation had been corrupted. I had to boot to rescue mode and run grub2-install to fix it, after which everything was fine.
Then a few days ago, I did another “zypper up”. I know the kernel was updated this time, but didn’t notice everything else. On boot, GRUB loaded, but apparently the .cfg wasn’t updated because it was still trying to boot the old (and now non-existant) kernel. I had to boot to rescue mode and run grub2-mkconfig to fix it, after which everything was fine.
hese aren’t severe problems and are relatively easy to fix, however this means that every time I update the server and restart it I have to ping it for the next couple of minutes to make sure it comes back up. And if it doesn’t, I have to go fish out a keyboard, monitor, and mouse to fix the problem.
Any ideas what would be causing this?
The server setup is pretty straight forward. It’s the only OS on the machine, MBR on sda, swap on sda1, / on sda2 of the boot drive, /home on an Adaptec RAID (/dev/sdb).
In all cases where I was able to get actual diagnostic the reason was, YaST2 configuration did not match actual configuration. I.e. if you manually install grub2 on different drive. Or start with legacy grub and manually install grub2 (including using methods to recover grub documented on this site).
What I do notice, however, is that grub2 is reinstalled whenever “mkinitrd” is run. I don’t much like that, as it breaks things, but I manage to live with it. And yes, that practice seems to have started with 12.2
Here’s what it breaks: On my laptop, I have it default to Windows boot and use the Windows boot manager to start linux. For this to work, Windows needs a file containing the boot sector. Due to the reinstall of grub2, that boot sector becomes invalid (stale). So I have to recreate that boot sector file after any update that runs “mkinitrd”. After doing updates, I usually check with
ls -ltr /boot/grub2
and look at the time stamp of the last output line to see if it has today’s date.
Let me say that it is my opinion you are getting your self in trouble by using zypper dup and up after the the distro is already at the right version and causing GRUB to be reloaded as if it was not there before. Have a look at this tutorial on the subject here:
In particular, pay attention to the usage of repository priorities in his examples. If you must use zypper up or dup, make sure the proper method has been followed. Here is how I do it from YaST (in KDE):
To fully upgrade, I would do the following tasks for openSUSE 12.2 using KDE:
Go to YaST (Enter Root Password) / Software / Software Repository and specify the URL addition of the Packman Repository “http://packman.inode.at/suse/openSUSE_12.2/” excluding the quotes if not already done.
Go to YaST (Enter Root Password) / Software / Software Management and select Options and check Allow Vendor Change.
Again, still in Software Management select Package / All Packages / Update if newer version available and press the Accept button on the bottom right.
YaST also works from terminal with no GUI being loaded. zypper refresh & zypper update can also be used from terminal. So, not using zypper dup and up after openSUSE is installed has saved me from the problems you are having. You may feel you know better, but you do seem to be having a problem!
Nothing has changed in the grub setup since the initial install. The only relatively big change in the machine’s setup since install was the configuration of the RAID at /home (/home initially lived on the boot drive with everything else, after install I migrated /home onto the RAID. Perhaps adding this new device somehow through off YaST2’s configuration?
“zypper up”, not “zypper dup”. These are just regular system updates, not a distro upgrade. I was under the impression that both zypper and YaST use the same back end to do the updates, so it shouldn’t matter which path is taken.
I don’t see what repo priorities would have to do with grub.cfg not being modified during a kernel update, but I’ll look into it. The only non-standard repo I have is packman anyway, and all of the same commands work fine on the laptop.
I just checked the bootloader config in YaST and for some reason it has the boot loader location set to a custom boot partition at /dev/sde2 (no MBR, no root partition, just /dev/sde2)! I wonder why YaST is under the impression that that’s where the boot loader lives? There is no sde in the system, just sda and sdb. I switched it to MBR and the root partition, hopefully that fixes it up.
Run “update-bootloader --refresh”. Does it output any error? And yes, it may screw up you configuration again - it is exactly what is run when you do kernel update.
It looks like that was it (see above post). Switching the bootloader location back to sde2 results in an error when running “update-bootloader --refresh” (no drive for sde2, go figure). With the bootloader set to MBR and root partition “update-bootloader --refresh” gives no error.
Thanks for the help, I’m pretty confident the problem won’t resurface now.
Blocklist in file system is unreliable and has always been. Even if reinstallation of bootloader on kernel update is skipped, it still breaks when grub2 itself is updated.
In this case I think that building minimal core.img that contains embedded script to load “real” grub2 would be more robust. If you are interested, contact me offline.