Why haven’t I gotten the new kernel when other people apparently have (see bug 965356) and I carried out all updates? The result is that I still can’t open Chromium, which a new update was supposed to allow, but other people can open it now. What I have now, according to uname -r, is 3.16.7-32-desktop. The bug says we should have 3.16.7-35-desktop (bug 965356 comment 45). Do I have to wait for the next time the kernel is updated for any reason, are there instructions somewhere on how to get and install the new kernel myself, or should I report the selectivity of updating as a bug in itself?
I’m currently getting the latest kernels from the “normal” Update Repository: <http://download.opensuse.org/update/13.2/>
The current 13.2 kernel on this machine is:
> uname -r
3.16.7-35-desktop
>
The Change List indicates the following changes made in 2016:
| Fr 05 Feb 2016 13:00:00 CET| tiwai@suse.de| - kABI fix for addition of user_namespace.flags field (bnc#965308,
|—|—|
bnc#965356).
- userns: Allow setting gid_maps without privilege when setgroups
is disabled (bnc#965308, bnc#965356). - userns: Add a knob to disable setgroups on a per user namespace
basis (bnc#965308, bnc#965356). - userns: Rename id_map_mutex to userns_state_mutex (bnc#965308,
bnc#965356). - commit 7400518|
| Do 28 Jan 2016 13:00:00 CET| mhocko@suse.cz| - x86/mm: Add barriers and document switch_mm()-vs-flush
synchronization (bnc#963767, CVE-2016-2069). - commit 8cf960e|
| Di 26 Jan 2016 13:00:00 CET| jslaby@suse.cz| - n_tty: Fix unsafe reference to “other” ldisc (bnc#961500
CVE-2016-0723). - tty: Fix unsafe ldisc reference via ioctl(TIOCGETD) (bnc#961500
CVE-2016-0723). - commit c6de32b|
| Di 26 Jan 2016 13:00:00 CET| acho@suse.com| - Bluetooth: ath3k: workaround the compatibility issue with xHCI
controller (bnc#907378). - commit 4301e68|
| Mo 25 Jan 2016 13:00:00 CET| jeffm@suse.com| - Delete patches.fixes/tulip-quad-NIC-ifdown.
The original bug that this patch fixed was addressed in 2004, in v2.6.10
(6379dd57 of linux-2.6-bk), but pci_disable_device was still required to
shut down the device.
Commit c321f7d7c87 in v3.14 added the pci_disable_device at the end of
tulip_remove_one just far enough out of context so that this patch still
applied. - commit e740751|
| Mi 20 Jan 2016 13:00:00 CET| jlee@suse.com| - KEYS: Fix race between read and revoke (bnc#958951,
CVE-2015-7550). - commit 79cfa19|
| Mi 20 Jan 2016 13:00:00 CET| mkubecek@suse.cz| - sctp: Prevent soft lockup when sctp_accept() is called during
a timeout event (CVE-2015-8767 bsc#961509). - commit 9a27648|
| Mi 20 Jan 2016 13:00:00 CET| jlee@suse.com| - patches.fixes/keys-fix-leak.patch: (bnc#962075, CVE-2016-0728). - commit f3cfd9f|
| Di 19 Jan 2016 13:00:00 CET| tiwai@suse.de| - KVM: x86: update masterclock values on TSC writes (bsc#961739). - commit c2d11b3|
| Mo 18 Jan 2016 13:00:00 CET| tiwai@suse.de| - NFS: Fix a NULL pointer dereference of migration recovery ops
for v4.2 client (bsc#960839). - commit 0bddaca|
| Mo 04 Jan 2016 13:00:00 CET| oneukum@suse.com| - Input: aiptek - fix crash on detecting device without endpoints
(bnc#956708). - commit d63cc64|
Assuming that zypper has refreshed properly, YaST and PackageKit should present the new kernel from the 13.2 Update Repository.
Yes, the 3.16.7-35 kernel is in the update repo, since nearly two weeks.
$ zypper se -s kernel-desktop
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
--+----------------------+------------+-------------+--------+---------------------
i | kernel-desktop | package | 3.16.7-35.1 | x86_64 | openSUSE-13.2-Update
i | kernel-desktop | package | 3.16.7-32.1 | x86_64 | openSUSE-13.2-Update
v | kernel-desktop | package | 3.16.7-29.1 | x86_64 | openSUSE-13.2-Update
v | kernel-desktop | package | 3.16.7-24.1 | x86_64 | openSUSE-13.2-Update
v | kernel-desktop | package | 3.16.7-21.1 | x86_64 | openSUSE-13.2-Update
v | kernel-desktop | package | 3.16.7-7.1 | x86_64 | openSUSE-13.2-Update
v | kernel-desktop | package | 3.16.6-2.1 | x86_64 | openSUSE-13.2-1.28
...
$ rpm -qi kernel-desktop
Name : kernel-desktop
Version : 3.16.7
Release : 35.1
Architecture: x86_64
Install Date: Tue 23 Feb 2016 10:28:03 CET
Group : System/Kernel
Size : 226288753
License : GPL-2.0
Signature : RSA/SHA256, Die 09 Feb 2016 17:33:36 CET, Key ID b88b2fd43dbdc284
Source RPM : kernel-desktop-3.16.7-35.1.nosrc.rpm
Build Date : Die 09 Feb 2016 17:28:00 CET
Build Host : cloud127
Relocations : (not relocatable)
Packager : http://bugs.opensuse.org
Vendor : openSUSE
URL : http://www.kernel.org/
Summary : Kernel optimized for the desktop
Description :
This kernel is optimized for the desktop. It is configured for lower latency
and has many of the features that aren't usually used on desktop machines
disabled.
Source Timestamp: 2016-02-07 18:32:21 +0100
GIT Revision: 832c7762adff5863353fd7333956f179287def0f
GIT Branch: openSUSE-13.2
Distribution: openSUSE 13.2
Maybe you do have it installed, but somehow configured your boot loader to boot an older one?
Please post a list of your installed kernel packages:
rpm -qa kernel-*
And also post your repo list:
zypper lr -d
Solved for me. I didn’t have time yet to get to it, but a new openSuse update came out and that fixed it. The long list of changes shown in the GUI didn’t say it would update the kernel but it did say something about the kernel and when updating was done Linux warm-booted from the . . . 35 . . . kernel and Chromium opened. So the problem is solved. Then I ran rpm as above and got a list of 18 kernel files and ran zypper as above and got a short list that probably is due to the newest update. I assume all is okay. If this didn’t happen to anyone else, no bug report regarding the update process is warranted. Thank you for the help.
You probably want to enable the purge-kernels.service. That should get rid of older kernels…
Either in YaST->System->Services Manager, or via:
systemctl enable purge-kernels.service
I tried via YaST, but still had 18 kernels. With purge-kernels.service already loaded, clicking Start/Stop didn’t fix it. Then I found the thread <https://forums.opensuse.org/showthread.php/498104-Purge-kernels-not-working>, but this is getting too complicated for the time I have, so I’ll leave the kernels and trust that future openSuse updates will handle kernels correctly, especially since, with so many, it likely did at least until recently.
Yes, kernels will only be removed after a new one is being installed.
To force it, run “/sbin/purge-kernels” manually, or “touch /boot/do_purge_kernels”…
I have a small question regarding kernel updates in general
Can I perform two kernel updates in the same session (openSUSE-2016-136 and openSUSE-2016-256) or is it better to reboot after the first kernel update?
IMO do the boot there are things that happen on the first boot of a new kernel that may not be good to skip
Thank you. I will do it this way.
That is not correct.
There is absolutely nothing special that happens on the first boot of a new kernel, except that purge-kernels.service is started to clean up the installed kernels.
But this can just as well be started if 2 new kernels have been installed in the meantime… You might just end up without the kernel you used previously because it is uninstalled in that case (with the default settings), so you cannot switch back to that in case of problems.
Why I said it. purge kernel is run and with 4 I for one am not sure what may happen. best to do it step by step. Also initdr is run and though less likely to be a problem unless you are short on space. Still say that doing one at a time is prudent.
What happens is that it will uninstall all outdated kernels according to the settings.
Doesn’t matter how many you installed since the last time.
Also initdr is run
No.
mkinitrd is run when a kernel is installed, not when it is booted the first time…
and though less likely to be a problem unless you are short on space.
Shortage of space might indeed be a problem of course, especially if you use a separate /boot/ partition.
After all, you will have more than the usual 2/3 kernels installed until the next boot.