13.1: System won't boot after today's patches/upgrades from Apper

Hi all

This morning Apper offered a number of patches to apply. I didn’t review them all in detail but i did notice that there was a kernel upgrade and Nvidia driver upgrade. I (foolishly perhaps) just OK’d them and since that the system won’t boot. i did manage to get running via failsafe on a previous kernel version.

I suspect some Nvidia/kernel version conflict but don’t know how to resolve it.

This may help?

 fred@linux-txck:~> rpm -qa | grep -E 'kernel|nvidia'kernel-desktop-3.7.10-1.28.1.x86_64


I guess that’s the kernel that didn’t boot?
kernel-xxx-base is a minimal package with most modules removed, so is not useable on a standard desktop system as drivers for most of your hardware are missing.
Install kernel-desktop-3.11.6 (without “base”) instead.

For the reason why kernel 3.11.6 is need, see also this thread: http://forums.opensuse.org/showthread.php/498610-Update-nvidia-331-67-to-331-79-needs-default-kernel


Those are from 12.3. Remove them.
And please post your repo list to check whether you maybe have some old repo left that should be removed:

zypper lr -d

I had the same issue with my setup, never recovered and now rebuilding from scratch.
couldn’t even start in fail safe, the machine just booted to a blinking cursor and nothing else.

was thinking into moving to XenServer setup but after trying it out decided to come back to OpenSuse + Xen config. running full after install update now, will see if all is well when I get home tonight :slight_smile:

Well, booting a kernel-xxx-base won’t work in failsafe/recovery mode either, as the drivers for most of your hardware are missing as I said, like network card, harddisk controller, you name it.
This is not a graphics driver only issue.

But you should have more than one kernel installed by default since 12.3.
So you should always be able to successfully boot the other kernel (i.e. not the same kernel in failsafe/recovery mode) in such a case.

zypper lr -d

| Alias | Name | Enabled | Refresh | Priority | Type | URI | Service

1 | Google_Chrome | Google Chrome | No | Yes | 99 | rpm-md | http://dl.google.com/linux/rpm/stable/x86_64 |
2 | Mono_for_Windows | Mono for Windows | No | No | 99 | rpm-md | http://download.mono-project.com/download-stable/openSUSE_11.4 |
3 | nVidia Graphics Drivers | nVidia Graphics Drivers | Yes | Yes | 99 | rpm-md | ftp://download.nvidia.com/opensuse/13.1/ |
4 | opensuse-guide.org-repo | libdvdcss repository | No | No | 99 | rpm-md | http://opensuse-guide.org/repo/12.2/ |
5 | packman.inode.at-suse | Packman Repository | No | No | 99 | rpm-md | http://packman.inode.at/suse/12.2/ |
6 | repo-non-oss | openSUSE-13.1-Non-Oss | Yes | Yes | 99 | yast2 | http://download.opensuse.org/distribution/13.1/repo/non-oss/ |
7 | repo-oss | openSUSE-13.1-Oss | Yes | Yes | 99 | yast2 | http://download.opensuse.org/distribution/13.1/repo/oss/ |
8 | repo-update | openSUSE-13.1-Update | Yes | Yes | 99 | rpm-md | http://download.opensuse.org/update/13.1/ |
9 | repo-update-non-oss | openSUSE-13.1-Update-Non-Oss | Yes | Yes | 99 | rpm-md | http://download.opensuse.org/update/13.1-non-oss/ |
linux-txck:/home/fred #

Please, use CODE tags around computer text you post. It is the # button in the tool bar of the post editor.

Looks ok. You could remove those repos for 11.4 and 12.2, but they don’t cause any problem as they are disabled anyway.
You might want to change the URLs of 4 and 5 to 13.1 though and enable them again to get full multimedia support, but that’s not related to the topic of this thread…

So that 12.3 kernel and nvidia driver is a left-over from upgrading I suppose?
As I said, you can remove those packages, but they shouldn’t cause a problem either.

But please remove kernel-desktop-base!

OK will do. But I’m still don’t know what to do to solve my problem. The system was working yesterday so presumably the kernel version was OK then. I’m not sure how to check what kernel is failing; it might be the ‘base’ version you mention but I don’t know that for sure. uname currently says:

fred@linux-txck:~> uname -r

As I said, uninstall kernel-desktop-base and your problem should be solved.
You might have to re-install the nvidia driver as well though.

The system was working yesterday so presumably the kernel version was OK then. I’m not sure how to check what kernel is failing; it might be the ‘base’ version you mention but I don’t know that for sure.

Well, what does the menu entry for the failing kernel say?
Maybe increase Grub2’s resolution in YaST->System->Boot Loader->Boot Loader Options first if you cannot read it, AFAIK Grub2 only detects 640x400 on nvidia cards (on some at least).

If that’s a version 3.11.6, it is kernel-desktop-base obviously.

fred@linux-txck:~> uname -r

That’s the one that works, right?

I’ve just looked at the bootloader setup in yast and it looks like this:


The fourth line is the one which successfully booted; the default first line was the failing one, and the corresponding failsafe (line two) failed also. Perhaps the update changed the first two lines?
Anyway, it seems that removing the first two lines (3.11.6) and moving the default to the current third line ( should work.

By the way, do you happen to know if the forum’s email notification is working OK? I’m subscribed to this thread for immediate emails but none are arriving.

Those two lines are a 3.11.6 kernel as you can see.
The only 3.11.6 kernel you have installed is kernel-desktop-base, so that’s why those two entries don’t boot.

And yes, the update installed kernel-desktop-base.
I guess this is another case of libzypp’s SoftLocks behavior.
You probably uninstalled kernel-desktop-3.11.6 manually once. So that got added to /var/lib/zypp/SoftLocks, and now YaST doesn’t want to install it automatically any more (because you explicitely uninstalled it, so to say). The nvidia-uvm-kmp package requires kernel 3.11.6 though, so YaST takes kernel-desktop-base instead (which in the end is kernel-desktop as well, just with fewer modules/drivers).

Anyway, it seems that removing the first two lines (3.11.6) and moving the default to the current third line ( should work.

Just uninstall kernel-desktop-base as I already said a few times.
This should remove those lines as well.

YaST will want to install kernel-desktop-3.11.6 then to fulfill the dependencies, just let it do that. (if not, you probably should install it yourself, as YaST might want to install a completely different kernel 3.11.6, f.e. -default, and the corresponding nvidia-uvm-gfxG03-kmp package)
It’s not the kernel version that gave you problems, but the fact that it was kernel-desktop-base instead of kernel-desktop.

Normally, the highest versioned kernel should be at the top and booted by default.
In your case kernel-desktop-base might have been sorted on top because it is different from kernel-desktop, I don’t know.
Could of course also be a bug in grub legacy/perl-boot-loader.

You should be able to change the order manually though in YaST IIRC. (I’m only using grub2 since it got default in 12.2 nearly two years ago)

By the way, do you happen to know if the forum’s email notification is working OK? I’m subscribed to this thread for immediate emails but none are arriving.

I don’t know why they are not working, but I am not getting any notifications either.

OK I used yast to remove the kernel-desktop-base as you proposed (several times! :slight_smile: ) and as you predicted it has installed 3.11.6-4-desktop in its place.

So now the bootloader shows 3.11.6 desktop as the default & failsafe, with the 3.11.10-11 desktop versions relegated to positions 3 & 4, and 3.11.10-7 at position 5. I’m sure 3.11.6 will be fine as the default, but is there any value in using 3.11.10 instead?

(And kernel-desktop-base has been added to SoftLocks).

OK, so grub legacy apparently lists them in order of installation, unrelated to the actual version.
Well, as I said, I think you can change the order in YaST->System->Boot Loader, so I would move 3.11.10-11-desktop (and its failsafe variant) to the top manually.

I’m sure 3.11.6 will be fine as the default, but is there any value in using 3.11.10 instead?

Well, 3.11.10 is newer and contains a lot of bug fixes.
If you have/had no problems with 3.11.6, you can just use that as well if you want to.
When the next kernel update is released, you’ll probably use that then anyway…

Btw, the dependency issue with the nvidia packages (which got you kernel 3.11.6 installed in the first place) has been fixed already, it might still take some time until the fixed packages appear in the repo though.
After the next nvidia update, you should be able to uninstall kernel-desktop-3.11.6 completely again, which would also remove the entries in the boot menu.

(And kernel-desktop-base has been added to SoftLocks).

That is ok and caused by the fact that you explicitely uninstalled it.
It’s done to prevent recommended packages getting installed again and again after you uninstall them. But this “feature” has been removed in Factory already as it can cause unexpected behavior, especially in the case of KMP packages (as you experienced yourself).

I’ve not quite “got” this yet. If the Nvidia drivers (for now) need 3.11.6, how is it I can use 3.11.10 successfully at all?

This is how KMP packages are designed to work:
They are available/you install them for one particular kernel version, and filesystem links get created to all other installed kernels.
This makes it unnecessary to update a KMP package when there is a kernel update. Of course this only works as long as the kernel versions are compatible enough. That’s (one of the reasons) why there won’t ever be an update to kernel 3.14 f.e. on a standard openSUSE 13.1 installation.

And the nvidia driver itself does not need kernel 3.11.6 exactly.
It’s just that the RPM package (nvidia-uvm-gfxG03-kmp in particular) had a too strict dependency by mistake, i.e. it tells your update software that it requires kernel-3.11.6 exactly which isn’t true in fact.

That’s very clear. Thanks again for your help.