The 4.12.9 stable kernel update contains a number of important fixes across the tree.
Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:
sudo dnf upgrade --refresh --advisory=FEDORA-2017-4b4c022807
Please login to add feedback.
0 | 1 | Test Case kernel regression |
This update has been submitted for testing by jforbes.
This update has been pushed to testing.
karma: +1
Works for me, x86_64, GNOME (CPU: Core2 Quad Q8400, RAM: 8 GiB, GPU: RV635).
works for me
works for me (F25, Gnome, x86_64) but as kernel regression test never comes to an end. System boots up in text mode until the greeter appears (plymouth never shows up).
no regressions noted
Not working for me (F25,KDE,x86_64): the system hang exactly as booting with kernel 4.12.8
Fedora 25, KDE, NVIDIA official driver, x86_64. Not working. Same problem as kernel 4.12.8-200. When booting the system freezes for about 2 minutes in the gray initial screen (with the thirt dot lighted), then it resume to the dracut textual shell. The last working kernel was 4.11.12-200.
@minnoce did you realize the recent warning of KDE upstream about the newest nvidia drivers beside that out-of-tree drivers don't bother Fedora at all and 4.11 is EOL so 4.12 must go out anyways because of the security updates https://blog.martin-graesslin.com/blog/2017/08/warning-nvidia-driver-384-69-seems-to-be-broken-with-qtquick/
@hreindl yes. Actually I'm using the (older) 384.59 version of NVIDIA drivers.
After some investigation, I've found that this new kernel has some problem with Linux RAID (software). In the "rdsosreport.txt" log file generated at boot time (in the dracut emergency shell) I found errors about not finding the disk devices and in the "lsmod" output is not listed any RAID kernel module (raid0, raid1).
no raid errors here - verify that your kernel line has the proper rd.md.uuid lines which is the case on my machines starting with 2014 or so
linux16 /vmlinuz-4.12.9-200.fc25.x86_64 root=UUID=b935b5db-0051-4f7f-83ac-6a6651fe0988 ro divider=10 audit=0 rd.plymouth=0 plymouth.enable=0 rd.md.uuid=b7475879:c95d9a47:c5043c02:0c5ae720 rd.md.uuid=1d691642:baed26df:1d197496:4fb00ff8 rd.md.uuid=ea253255:cb915401:f32794ad:ce0fe396 rd.luks=0 rd.lvm=0 rd.dm=0 zswap.enabled=0 elevator=cfg selinux=0 net.ifnames=0 biosdevname=0 clocksource=hpet noisapnp noresume hibernate=no kaslr nf_conntrack.acct=1 printk.time=0 nmi_watchdog=0 consoleblank=0 acpi_osi=Linux vconsole.font=latarcyrheb-sun16 vconsole.keymap=de-latin1-nodeadkeys locale.LANG=de_DE.UTF-8 LANG=de_DE.UTF-8
[root@rh:~]$ cat /proc/mdstat Personalities : [raid10] [raid1] md2 : active raid10 sda3[0] sdc3[1] sdb3[3] sdd3[2] 3875222528 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]
md0 : active raid1 sdc1[1] sda1[0] sdb1[3] sdd1[2] 511988 blocks super 1.0 [4/4] [UUUU]
md1 : active raid10 sda2[0] sdc2[1] sdb2[3] sdd2[2] 30716928 blocks super 1.1 256K chunks 2 near-copies [4/4] [UUUU]
Yes. I confirm your hypotesis. For some reason I had the wrong UUID for one of the "rd.md.uuid"'s and the rebuilded initramfs had problems finding the RAID device. I corrected the UUID in the kernel lines and now all is working fine with new 4.12 kernels.
I don't understand why Fedora need grub kernel lines with explicit UUIDs. What about auto-finding file systems? But that's another story...
Thanks!
This update has been submitted for stable by jforbes.
This update has been pushed to stable.