Now this is mostly for squashing the recently announced critical:
x86, x32: Correct invalid use of user timespec in the kernel (CVE-2014-0038)
I will write a better advisory tomorrow, but so you can start testing:
Steps to Reproduce:
i586 virtualbox, installs and boots fine to X. Nothing tested beyond.
When testing these alternative kernels (-linus, -rt, -tmb, -vserver) it is necessary to use the dkms driver packages, dkms-nvidia* and dkms-fglrx etc. rather than the pre-built kmod packages such as nvidia-current-kernel-desktop-latest.
Pre-built kmod packages only support the specific kernel they are built for, which forms part of the package name.
Dkms packages actually build the driver on the next boot for whichever kernel you are using. It means the first boot after installing the new kernel will take longer than expected. Allow it to complete, normally a minute or couple of minutes, depending on your hardware. You can see it building if you remove "splash quiet" options from the kernel command line or press escape as it boots so you can see the text. It shows and a series of dots ". . . . ."
This kernel update provides an update to 3.12.9 and fixes the following
critical security issue:
Pageexec reported a bug in the Linux kernel's recvmmsg syscall when called
from code using the x32 ABI. An unprivileged local user could exploit this
flaw to cause a denial of service (system crash) or gain administrator
The -rt patch has been updated to -rt11.
For other changes, see the referenced changelog:
Kernel did not boot--no further disk activity after initial (vmlinuz?--it disappears quickly) image command. Screen blanks and no further activity.
(In reply to Bill Wilkinson from comment #4)
> Kernel did not boot--no further disk activity after initial (vmlinuz?--it
> disappears quickly) image command. Screen blanks and no further activity.
Does the one from core/release boot?
The release kernel boots to the login screen, but does not completely start KDE. I haven't tried with other desktops.
Seems there were some issues with upstream -rt11, wich should be fixed in -rt13,
so rpms for test are now:
Update request: kernel-rt-3.12.9-0.rt11.1.mga4 =>
Update request: kernel-rt-3.12.9-0.rt13.1.mga4Source RPM:
After installing the devel package, I tried some brutal testing approach regarding dkms:
# rpm -qa | grep dkms | xargs urpme
# urpmq dkms- -Y | xargs urpmi > dkms.log 2>&1
It installs all the dkms packages we have. Most of them are ok but I get error messages. If they're not related to kernel-rt (nvidia-current is), I guess I'll have to open bug reports against those dkms packages, but I'd like a confirmation.
Full log attached.
If someone wants to do the same, I detected the failed builds with:
$ cat dkms.log | grep "for more information"
List of the failed builds:
cc1: erreur fatale: /lib/modules/3.12.9-0.rt13.1.mga4/build/include/linux/version.h : No such file or directory
/var/lib/dkms/zd1211/184.108.40.206-0.r67.7.mga4/build/src/zd1205.c:34:26: erreur fatale: linux/config.h : No such file or directory
/var/lib/dkms/lzma/4.43-34.mga4/build/uncomp.c:64:4: erreur: implicit declaration of function Ã¢kfreeÃ¢ [-Werror=implicit-function-declaration]
/var/lib/dkms/syntek/3.0.0-4.mga4/build/stk11xx-v4l.c: In function Ã¢v4l_stk11xx_register_video_deviceÃ¢:
/var/lib/dkms/syntek/3.0.0-4.mga4/build/stk11xx-v4l.c:1503:11: erreur: Ã¢struct video_deviceÃ¢ has no member named Ã¢parentÃ¢
/var/lib/dkms/fsam7400/0.5.2-3.mga4/build/fsam7400.c: In function Ã¢common_proc_initÃ¢:
/var/lib/dkms/fsam7400/0.5.2-3.mga4/build/fsam7400.c:331:4: erreur: implicit declaration of function Ã¢create_proc_entryÃ¢ [-Werror=implicit-function-declaration]
/var/lib/dkms/lirc-extra/0.9.0-10.1.mga4/build/drivers/lirc_wpc8769l/lirc_wpc8769l.c: In function Ã¢irq_handlerÃ¢:
/var/lib/dkms/lirc-extra/0.9.0-10.1.mga4/build/drivers/lirc_wpc8769l/lirc_wpc8769l.c:364:3: erreur: implicit declaration of function Ã¢generic_find_next_le_bitÃ¢ [-Werror=implicit-function-declaration]
config.status: error: cannot find input file: `Makefile.in'
make: *** No rule to make target '/var/lib/dkms/ipt_NETFLOW/1.8-4.mga4/build/Makefile'.
The kernel you are installing for is a PREEMPT_RT kernel!
The NVIDIA driver does not support real-time kernels. If you
are using a stock distribution kernel, please install
a variant of this kernel that does not have the PREEMPT_RT
patch set applied; if this is a custom kernel, please
install a standard Linux kernel. Then try installing the
NVIDIA kernel module again.
*** Failed PREEMPT_RT sanity check. Bailing out! ***
Created attachment 4976 [details]
dkms install log
FYI with the same version kernel-vserver, the same builds fail, except:
There's one more, dkms-acpi_call, but I think it failed too with kernel-rt (I didn't follow exactly my own procedure, I installed it there before all the others)
Well, all of those dkms errors are specific to the dkms package in question, most of them simply are not updated / fixed to work with 3.12 series kernels.
the issue between -rt kernel and nvidia-current is a nvidia-current we used to have a special patch in nvidia-current that I seem to have dropped between upgrades/downgrades mess :/
I will restore it when I push nvidia-331.38 to updates_testing as we can switch back to that driver now when the real cause for the nvidia app hang has been found.
So theese dkms issues does not prevent the validation of this kernel as it's not at fault, the broken dkms-* ones need to be fixed or dropped.
for -vserver kernel, we usually dont let dkms problems block validation, as it's a special kernel for server installs where you dont really use any dkms packages...
If I can fix it to work for both "normal" and vserver kernels I do, but if I have to choose, its more important that the "normal" kernels works...
Thanks Thomas. Testing mga4 i586 complete.
(In reply to Samuel VERSCHELDE from comment #10)
> There's one more, dkms-acpi_call, but I think it failed too with kernel-rt
> (I didn't follow exactly my own procedure, I installed it there before all
> the others)
dkms-acpi_call probably does not build on any kernel, AFAIU it has been deprecated by bbswitch. I still have to clean it up though, it was a Requires of bumblebee when Simple imported it.
Installing it on my real computer, apart from the nvidia module not building, it booted fine.
I don't know why, my KDE session wasn't restored: kmail, firefox and konsole were not started. I rebooted into the desktop kernel with "reboot" so that KDE doesn't save that new empty session, and after reboot I get all my apps restored as usual.
I'll try kernel-rt from release and see if it's the same.
MGA4-32-OK advisory =>
MGA4-32-OK advisory MGA4-64-OK?
The weird behaviour with KDE session not restoring opened apps is there with kernel-tmb too and kernel-rt from release, so not a regression. Might occur when the nvidia driver isn't running, maybe.
One question not directly related to this update: what could cause the nouveau driver to load on kernel-tmb-desktop instead of nvidia, whereas kernel-desktop loads nvidia... dkms-nvidia built the module for both of them. Is that something you'd like to dig, tmb?
Regarding kernel-rt, testing mga4 64 complete.
Update validated, advisory already uploaded.
Please push to 4/core/updates
MGA4-32-OK advisory MGA4-64-OK? =>
MGA4-32-OK advisory MGA4-64-OK
It's possible the dkms nvidia actually failed to build. This is what we discovered earlier and occurs if there are kernel-source packages installed prior to installing the new kernel. The symlinks in /lib/modules/<kernel> are set incorrectly. If that's the case then it's an old drakx patch which has now been removed and the fix will be included in the next kernel updates.
Also, after defaulting to nouveau IINM it's necessary to manually change it back to nvidia with XFdrake. Configure the card and OK back to menu and it should offer to use/install the proprietary nvidia driver again.
dkms can also become messed up when kernels are removed, the dkms builds are not cleanly removed before kernel removal, which can cause issues if re-installing the same kernel again.
A workaround for that is to remove the dkms package and reinstall it (bug 10771)
The driver didn't fail to build (with kernel-tmb-desktop), the module is available but can't be loaded because nouveau is already in place, that's what I don't understand since with kernel-desktop nvidia is loaded instead of nouveau.