Bugzilla – Bug 555323
zypper dup did not update menu.lst at all
Last modified: 2010-01-06 12:41:45 UTC
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1.5) Gecko/20091103 SUSE/3.5.5-2.1 Firefox/3.5.5 I had followed the instructions in http://en.opensuse.org/Upgrade/11.2 to upgrade my openSUSE 11.1 for x86-64 to 11.2. Just before rebooting, I decided to check whether /boot/grub/menu.lst had been correctly updated. It turns out it wasn't updated at all - it still referenced the old 11.1 kernel entries only. So if I rebooted at this point, my desktop would not have booted up. I ended up reinstalling kernel-default, kernel-default-base packages via rpm -ivh --replacefiles --replacepkgs, and that added new kernel to menu.lst. Reproducible: Didn't try Steps to Reproduce: 1. 2. 3.
Hi,Vadim,could you please attach y2logs according to http://en.opensuse.org/Bugs/YaST. Thanks.
Created attachment 327683 [details] Required y2logs attached
Josef, please check /var/log/zypp/history. It says # 2009-11-13 13:43:01 kernel-default-2.6.31.5-0.1.1.x86_64.rpm installed ok plus gives a few tens of lines of other output.
It looks like adding bootloader is not invoked at all. How exactly you update? via zypper dup? or something different? I need this info to reproduce it. Especially if yast run during your update.
I've followed instructions on http://en.opensuse.org/Upgrade. First, I've added "commit.downloadMode = DownloadInAdvance" to /etc/zypp/zypp.conf, then I executed "YAST_IS_RUNNING=instsys zypper dup". Also, I've upgraded my home PC to openSUSE 11.2 using the same steps, and hit the same issue again.
Did you execute SuSEconfig after the 'dup'? (it's needed when YAST_IS_RUNNING=instsys is used)
Yeah, that is root of problems. if you specify YAST_IS_RUNNING=instsys then perl-Bootloader is in another mode and don't write changes immediately, but to specified file and which must be then runned. Really not good idea to speicify it on running system which need to update bootloader configuration. I add it to that wiki page. So bug is invalid, as when you simulate instsys then behavior is changes and menu.lst is not updated (because you cannot modify menu in instsys, but on target machine). Jano - I think it doesn't help in this case as pbl need more variables defined by yast2-bootloader and afterwards yast2-bootloader run pbl delayed update.
Yes, I did execute SuSEconfig. stal-dev-lx1:~ # history | grep -C1 YAST 556 cd /tmp 557 YAST_IS_RUNNING=instsys zypper dup 558 SuSEconfig
OK, closed as invalid and add to wiki big warning, as simulating inst-sys cause serious problem to update bootloader. Thanks for report
Josef, what about using YAST_IS_RUNNING=1 ? Does that make a difference?
(In reply to comment #11) > Josef, what about using YAST_IS_RUNNING=1 ? Does that make a difference? Yes, perl-Bootloader checks only instsys value... and Überhack is if you use DELAYED_RUN_UPDATE_BOOTLOADER=yes Then perl-Bootloader think that he run delayed update. But as I said it is hack and internal implementation which should not be official way.
Sorry for a silly question, but how is one supposed to perform a distribution upgrade using zypper dup if bootloader config is not updated? Isn't that a showstopper? Or am I missing something here?
(In reply to comment #13) > Sorry for a silly question, but how is one supposed to perform a distribution > upgrade using zypper dup if bootloader config is not updated? Isn't that a > showstopper? Or am I missing something here? of course zypper dup works. what doesn't work is if you run YAST_IS_RUNNING=instsys zypper dup because it simulate upgrade from instsys and not on running system
Forgive me if I'm missing something here, but the YAST_IS_RUNNING=instsys was a workaround suggested on the wiki to avoid crashing X clients during installation. However, this workaround causes the bootloader config to not be updated, so a warning was added to the wiki. Wouldn't it be more prudent just to suggest to people that they enter runlevel 3 before executing zypper dup? Then they don't have to use the YAST_IS_RUNNING workaround, and don't have to worry about the bootloader not being updated.
Well, many people (most) do not have to switch to runlevel 3, they can successfully run zypper dup while using the graphics environment. So, yes, we can recommend to switch to runlevel 3, but only as a workaround to the crashing X problem. OTOH, we can probably change the suggestion in the wiki to YAST_IS_RUNNING=1 instead of YAST_IS_RUNNING=instsys (if that works around the crashing X problem).