Cannot Boot from Grub after Tumbleweed upgrade

I started with Tumbleweed based on the past year. Then, just now (6 hrs ago) I changed the repos as specified here: openSUSE:Tumbleweed installation

It seemed to go OK when I did the zypper dup, about 2000 packages arrived and installed themselves etc, etc…
I checked in /etc/SUSE-brand and see this:

openSUSE
VERSION = 13.2

On reboot I got this:

Booting openSUSE 13.1
Loading Linux 3.17.1-1...etc etc-desktop
error: premature end of file /boot/vmlinuz/-3.17.1-1.g5 etc etc desktop
Loading initial ramdisk
error: you need to load the kernel first
Press any key to continue....
Failed to boot both default and fallback entries
Press and key to continue.......

Pressing a key, or not pressing any key and waiting: both lead to an opaque screen and it hangs

I can boot up with Super Grub2 live CD. The new Tumbleweed works nicely, but the bootloader from the installation doesn’t work. I have reinstalled Grub using the Yast interface. The problem persists.
I can boot many kernels (that were installed over the past year by Tumbleweed) using the Super Grub disk, but I cannot boot from the openSUSE loader.

Any thoughts?
Thanks

Apparently the kernel file is truncated.
Maybe your /boot is full?
Although I think there’s another thread with exactly the same error message, so maybe there’s a more general problem at the moment…

You should be able to boot any of the other installed kernels via “Advanced Options” in the boot menu.
Does that work?
Try to remove that kernel and reinstall the latest kernel then:

sudo zypper rm kernel-desktop-3.17.1
sudo zypper in -f kernel-desktop

Thanks for thoughts.

Just a few:

kernel-desktop-3.15.3-37.1.g42bf625.x86_64
kernel-desktop-devel-3.17.0-50.1.gc467423.x86_64
kernel-desktop-3.16.3-49.3.gd2bbe7f.x86_64
kernel-desktop-3.15.2-36.1.gfb7c781.x86_64
kernel-desktop-3.15.1-34.1.gee8dd2b.x86_64
kernel-desktop-3.15.4-38.1.g2b59ae6.x86_64
kernel-desktop-3.15.0-33.2.g9194b64.x86_64
kernel-desktop-devel-3.16.3-49.1.gd2bbe7f.x86_64
kernel-desktop-3.15.5-39.1.g01d2774.x86_64
kernel-desktop-3.16.3-49.1.gd2bbe7f.x86_64
kernel-desktop-3.15.1-34.2.gee8dd2b.x86_64
kernel-desktop-devel-3.16.3-49.3.gd2bbe7f.x86_64
kernel-desktop-3.11.6-4.1.x86_64
kernel-desktop-3.15.8-43.1.g1bbc06d.x86_64
kernel-desktop-3.15.6-40.1.gfdb2dde.x86_64
kernel-desktop-3.17.0-50.1.gc467423.x86_64
kernel-desktop-3.15.6-41.1.gedc5ddf.x86_64
kernel-desktop-3.15.0-33.1.g9194b64.x86_64
kernel-desktop-devel-3.17.1-1.2.g5c4d099.x86_64
kernel-desktop-3.15.1-35.1.g3289da4.x86_64
kernel-desktop-3.16.1-46.1.g90bc0f1.x86_64
kernel-desktop-3.15.8-44.1.g258e3b0.x86_64
kernel-desktop-3.11.10-11.1.x86_64
kernel-desktop-3.17.1-1.2.g5c4d099.x86_64

So I did this removal:

opensuse131:/home/john # zypper rm kernel-desktop-3.17.1-1.2.g5c4d099.x86_64
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following package is going to be REMOVED:
  kernel-desktop-3.17.1-1.2.g5c4d099 

1 package to remove.
After the operation, 216.1 MiB will be freed.
Continue? [y/n/? shows all options] (y): y
(1/1) Removing kernel-desktop-3.17.1-1.2.g5c4d099 ...............[done]

Then I rebooted and got exactly the same message except now the reference to premature end of file is referencing kernel-desktop-3.17.0-50.1.gc467423.x86_64 (earlier it was 3.17.1)
So it still fails to boot from the openSUSE loader but is OK via SuperGrub2 CD

More thoughts?

Then I did

 zypper in -f kernel-desktop

The kernel 3.17.1.1.2 was installed
I rebooted
Problem persists

Well, that’s quite a lot! :wink:
Is this on purpose?
Maybe you should enable purge-kernels.service?
This is fixed to work with Tumbleweed kernels in the meantime.

Then I rebooted and got exactly the same message except now the reference to premature end of file is referencing kernel-desktop-3.17.0-50.1.gc467423.x86_64 (earlier it was 3.17.1)
So it still fails to boot from the openSUSE loader but is OK via SuperGrub2 CD

The same kernels fail that work fine with SuperGrub2 CD?
Then it seems to be a problem with grub itself.

Are you using grub or grub2?
On what kind of file system is your /boot?
Try to reinstall the boot loader with YaST (just enter YaST->Boot Loader and click on OK).

Maybe you should file a bug report.

Is this on purpose?

It’s a lot of kernels because there were many in Tumbleweed over the past year and I didn’t bother to purge (and IIRC purge was broken?)

On what kind of file system is your /boot?

it’s a directory in root partition which is ext4

Maybe you should enable purge-kernels.service?

OK I switched it onand now I have just two in the 3.17 range

john@opensuse131:~> rpm -qa | grep kernel-desktop
kernel-desktop-devel-3.17.0-50.1.gc467423.x86_64
kernel-desktop-3.17.1-1.2.g5c4d099.x86_64
kernel-desktop-3.17.0-50.1.gc467423.x86_64
kernel-desktop-devel-3.17.1-1.2.g5c4d099.x86_64

At this point I rebooted and it failed again so I used again Super Grub2 Disk and It booted

Are you using grub or grub2?

the answer is here:

john@opensuse131:~> rpm -qa | grep grub
grub2-branding-openSUSE-13.2-9.1.noarch
grub2-x86_64-efi-2.02~beta2-25.1.x86_64
grub2-snapper-plugin-2.02~beta2-25.1.noarch
grub2-i386-pc-2.02~beta2-25.1.x86_64
grub2-2.02~beta2-25.1.x86_64
grub-0.97-201.1.x86_64

I’m now going to back up the whole root partition (which includes /boot), using rsync. .
Then use a CD external to rename /boot so It can’t be seen for what it is
Then I’ll boot to this iso that I downloaded: openSUSE-Factory-DVD-x86_64-Snapshot20141102-Media.iso (it’s a Tw install DVD) and then ask it to do an upgrade and restrict the upgrade to boot stuff. And see what happens there. Should be entertaining.

Well I pretty much did that, uninstalled the sus kernel, put in a “debug” kernel, and uninstalled everything Grub , and deleted the directory /boot, and unloded all repos. Then I mounted the iso for DVD install of Tumbleweed as a repo. and I installed grub and that iso’s desktop kernel.

the /boot was all rebuily nicely, then I rebooted and got the error again.

I have a nice Tumbleweed except I have to boot with the CD.

Well I see I started working on this about 11 hours ago.

Finally it boots unaided after I directed in Yast Bootloader setup to write generic code in the MBR and boot from MBR.
I have no idea why the default needed to be changed in my case.
I think that even though it’s technically working, this is absolutely not a case of “solved” because it should work the way it is default-installed, not just because I fiddled with it for 10 hours.

Anyway, no more time for this, have to make up for a lost day and move on.

As indicated, it has been fixed in Factory’s dracut package half a year ago, and I submitted the fix to 13.1 (i.e. the old Tumbleweed as well) a few weeks ago.

You maybe have to enable it though, so that it is run at boot.

the answer is here:

john@opensuse131:~> rpm -qa | grep grub
grub2-branding-openSUSE-13.2-9.1.noarch
grub2-x86_64-efi-2.02~beta2-25.1.x86_64
grub2-snapper-plugin-2.02~beta2-25.1.noarch
grub2-i386-pc-2.02~beta2-25.1.x86_64
grub2-2.02~beta2-25.1.x86_64
grub-0.97-201.1.x86_64

Well, not really.
This only shows what packages you have installed. But not which boot loader you are actually using…

I can only guess that you had non-generic boot code in the MBR from some older installation. This loaded grub’s actual boot loader code from the wrong place on your hard disk (i.e. not the currenlty installed one, but some older version, maybe even partially overwritten already) which caused the problem.
Overwriting the MBR with generic boot code fixed it then of course, as now the grub boot loader code is loaded from the active partition, where it is installed too.

To clarify: if you install grub to the MBR (and you probably did at some point), it writes code to the MBR that loads the rest of grub by specifically reading the sectors on the disk where the files are located (there’s not enough place in the MBR to include file system code).
The generic boot code just reads the boot sector from the active partition and executes it. This in turn loads the rest of grub then.

(1) Thanks for thoughts. Makes me feel better about the validity of the fix.
(2) I got the kernels cleaned up after you mentioned purge-kernels.service

You’re welcome.

At least that’s the only thing I can imagine, considering that installing generic MBR code fixed the problem.
And I haven’t ever heard of a similar problem either.

(2) I got the kernels cleaned up after you mentioned purge-kernels.service

Yes.
But to have it clean up automatically after a kernel update, you have to enable the service. Apparently you didn’t have it enabled, otherwise you wouldn’t have that many kernels left.
Check the status with “systemctl status purge-kernels.service”. If it says “disabled”, run “sudo systemctl enable purge-kernels.service”.
Or use YaST->System->Services Manager for both.

But I think I already told you that in another thread some time ago anyway, when Tumbleweed was still the old Tumbleweed (based on 13.1) and that bug did still exist in 13.1’s mkinitrd package. :wink:

Something broken in my Tumbleweed. purge-kernels is permanently enabled and inactive. I can reset them in Yast and click to make-it-so, but then I get this next time I boot:

opensuse131:/home/john # systemctl status purge-kernels.service
purge-kernels.service - Purge old kernels
   Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; enabled)
   Active: inactive (dead)
           start condition failed at Sat 2014-11-08 10:03:50 AEST; 3min 44s ago

Yes, of course it is inactive.
It is just a script that gets run, does its work and exits. Then it is inactive. It’s no daemon that keeps on running.

The important part is that it is “enabled”.

It will then get started on boot whenever a new kernel has been installed. If not, you see this “start condition failed” status message.
The start condition for the script is that a new kernel has been installed, so to say. This is signalled by the kernel package in creating a file /boot/do_purge_kernels during installation. If the purge-kernels.service sees this file, it runs the script /usr/bin/purge-kernels to clean up the kernels.

Clear now? :wink:

I had it in my mind that it would run like e.g. nmb, but I had never stopped to give it a thought. Now that you mention it, it’s obvious.

I’ve the same problem, how do you restrict the upgrade only to boot stuff?

I’ve seen this before, when experimenting with GRUB / GRUB2. Installed GRUB in MBR, then switched to GRUB2 and have it not installed in MBR. I remembered because of the messages re. the kernel image.

but this happend after repository change & update and I wasn’t playin around with grub at all. but how to update only boot stuff? is Live CD wnough or I need full DVD image and do I need to chroot from that Live session ?

“This happened” you said. Not sure what “this” is. Are you unable to boot into your installation?

I mean the problem you’ve = you’ve to load kernel first…

I did this in Yast and the problem went away

http://paste.opensuse.org/images/07218979.png

07218979.png