Bugzilla – Bug 929594
Boot failure after applying online updates
Last modified: 2015-06-30 07:44:04 UTC
I know this could be hard to track down, but you should at least be aware of it, as unbootable systems are pretty hard for most users to recover. And it's also a security issue as you're posting security updates that may not be effective in a number of cases. I applied a large number of online updates in a batch. One of the updates was to a newer kernel, 3.16.7-21. When it got to that part of the installation process, it failed because /boot was full. (It is 128M. Everything else is on LVM2 via LUKS.) So I manually deleted the oldest kernel, 3.16.6-2, and its initrd from /boot, then hit retry, then all was good. On the next reboot, the only GRUB2 menu item for Linux was pointing to the kernel that I had deleted :/ Fortunately I was able to edit the command line within GRUB2 and simply use "vmlinuz" and "initrd", with no version info. The symlink had updated correctly, but evidently I had been booting the older kernel for a while, as I already had a newer one installed, 3.16.7-7, but was not using it at the time that I applied this recent update. So it appears to be a bootloader configuration issue. The new kernel booted fine, the symlinks were updated fine, but GRUB2 is directly referencing a particular kernel version that no longer exists. It never got updated with either of the online updates that were applied since 3.16.6-2. I'm not sure if the full /boot has anything to do with it. I suspect that is irrelevant. It's just the reason that I discovered I was using an older kernel than the most recent one installed. This probably also explains all the problems I was having with VirtualBox not having a kernel module available. I was not running the kernel that matched the kernel package that was installed.
I would guess that this is related to the post-install scripts of kernel failing due to lack of disk space and then the bootloader menu not getting updated. Could you check /var/log/YaST2/perl-BL-standalone-log as well as libzypp logs to find out whether perl-Bootloader was called at all? Alternatively, attach the files (together with the particular kernel version which you have updated to).
I'm going to need you to be more specific about finding the info in the libzypp logs. But, I think this probably answers your question anyway. grep bootloader /var/log/YaST2/perl-BL-standalone-log bootloader_entry was called as: add desktop 3.16.6-2-desktop vmlinuz-3.16.6-2-desktop initrd-3.16.6-2-desktop bootloader_entry: This is function add_entry() bootloader_entry was called as: add desktop 3.16.6-2-desktop vmlinuz-3.16.6-2-desktop initrd-3.16.6-2-desktop bootloader_entry: This is function add_entry() bootloader_entry: This is (wrapper) function update_bootloader bootloader_entry: This is (wrapper) function update_bootloader bootloader_entry was called as: add desktop 3.16.7-7-desktop vmlinuz-3.16.7-7-desktop initrd-3.16.7-7-desktop bootloader_entry: This is function add_entry() bootloader_entry: This is (wrapper) function update_bootloader bootloader_entry: This is (wrapper) function update_bootloader bootloader_entry was called as: remove desktop 3.4.73-3.gfdb3905-desktop vmlinuz-3.4.73-3.gfdb3905-desktop initrd-3.4.73-3.gfdb3905-desktop bootloader_entry: This is function remove_entry() bootloader_entry: This is (wrapper) function update_bootloader bootloader_entry: This is (wrapper) function update_bootloader bootloader_entry was called as: add desktop 3.16.7-21-desktop vmlinuz-3.16.7-21-desktop initrd-3.16.7-21-desktop bootloader_entry: This is function add_entry() bootloader_entry: This is (wrapper) function update_bootloader bootloader_entry: This is (wrapper) function update_bootloader bootloader_entry was called as: remove desktop 3.16.6-2-desktop vmlinuz-3.16.6-2-desktop initrd-3.16.6-2-desktop bootloader_entry: This is function remove_entry() bootloader_entry: This is (wrapper) function update_bootloader bootloader_entry: This is (wrapper) function update_bootloader
So, the calls seem to be correct. Can you, please, attach the full files so that we can have a deeper look?
Created attachment 633232 [details] /var/log/YaST2/perl-BL-standalone-log As requested.
You will need to tell me the exact file name and path if you want the libzypp logs. As I said, be more specific. I don't know how every subsystem works, or I probably would have fixed it myself and told you the solution :)
If I may make a suggestion, having a default bootloader entry that uses the vmlinuz and initrd symlinks would have been a lot more reliable. Why are we going to all this trouble to keep updating the menu with the specific kernel version, when there's only one entry anyway?
It looks very strange like if there is no bootloader proposed and used for updating. Can you please upload content of /etc/sysconfig/bootloader?
Created attachment 633291 [details] /etc/sysconfig/bootloader I believe this was an update to a previous openSUSE, and it's conceivable that the boot-loader was already mostly working and didn't get installed on the final OS install for some reason.
The loader type in the file says "none" - which means that you manage bootloader configuration on your own. Therefore, the behavior is correct. To make future kernel updates work for you, set it to your used bootloader (most likely "grub2")
yes, we have problem with upgrade in os13.2 . Please use yast2 bootloader and set bootloader to grub2 or grub2efi what fits your needs. Thanks for report and sorry for caused problems. It is already fixed in TW, but for 13.2 we cannot do DVD modification.
Further info. I just upgraded another system from 13.1 to 13.2, using "zypper dup". It now has no bootloader configured under YaST2. It was using Grub v1. Now I see that Grub v1 is not listed as an option, so I'm guessing Grub was uninstalled as part of the update. I was never given any warning that I no longer had a bootloader configured. Why was I using Grub 1? I couldn't get Grub 2 to boot. I tried again and again and gave up. So it would have been nice if Grub 1 hadn't gone away like that. Maybe I can make Grub 2 work, but assume for a moment that I haven't noticed that I have no bootloader configured. Now I have the same issue that was described at the start of this report. The system silently continues to run with the old kernel from before the upgrade, and it never updates. Please don't mark this invalid again. There is a problem affecting everyone who follows your "supported" upgrade path with a bootloader that is going to be silently removed during the update.
(In reply to Darren Freeman from comment #11) > Further info. > > I just upgraded another system from 13.1 to 13.2, using "zypper dup". It now > has no bootloader configured under YaST2. yes, yast2-bootloader no longer support grub1, but you can still manage to use it, just without yast. So if you use zypper dup, then it usually just works and only if you need modification you need to upgrade to grub2 and manage it yourself. More user friendly message in y2-bl that grub1 is no longer support is tracked as different bug number. > > It was using Grub v1. Now I see that Grub v1 is not listed as an option, so > I'm guessing Grub was uninstalled as part of the update. I was never given > any warning that I no longer had a bootloader configured. It is configured, just y2-bl cannot handle it. > > Why was I using Grub 1? I couldn't get Grub 2 to boot. I tried again and > again and gave up. So it would have been nice if Grub 1 hadn't gone away > like that. If you report your scenario and problem we can look at it. Only think I am aware of is bigger space needed for stage 2 that cause in not so common cases problem. > > Maybe I can make Grub 2 work, but assume for a moment that I haven't noticed > that I have no bootloader configured. Now I have the same issue that was > described at the start of this report. The system silently continues to run > with the old kernel from before the upgrade, and it never updates. Only if you run yast2-bootloader, otherwise it is automatic updated to new kernel by perl-bootloader. As I said this problem in yast2 bootloader is covered by bug#923458 > > Please don't mark this invalid again. There is a problem affecting everyone > who follows your "supported" upgrade path with a bootloader that is going to > be silently removed during the update. It should not be silently removed. If you do not run yast2-bootloader it should just work without any issue. If it is not case, I will need logs to see what happens. So marking as dup for UX problem that y2-bl do not nicely report that old grub1 configuration is used. *** This bug has been marked as a duplicate of bug 923458 ***