Hi, Tested on VirtualBox : not tested on real pc Description of problem: After update Mageia 6 to kernel-desktop-4.14.40-1.mga6-1-1.mga6, boot is too slow. Some errors at boot (systemd-networkd, and 2 others services) Version-Release number of selected component (if applicable): kernel-desktop-4.14.40-1.mga6-1-1.mga6 How reproducible: Prepare VirtualBox Steps to Reproduce: 1. Install kernel-desktop-4.14.40-1.mga6-1-1.mga6 2. Reboot 3. See it's slow
CC: (none) => email
CC: (none) => friAssignee: bugsquad => kernel
Please clearify: is it boot of host or guest that is slow? Both host and guest use kernel 4.14.40? Are you using all kernel updates? Which virtualbox version? You may want to try the vbox version in testing, Bug 22930
Hi We have some users on MLO who have the same problem. It seems that they use module r8169 for their network card. cf : https://www.mageialinux-online.org/forum/topic-25127-2+la-derniere-mise-a-jour-peut-poser-des-problemes.php
CC: (none) => jeanmichel.varvou
My Host is Gentoo. Mageia is the Guest ! The network card used in the virtualbox is a Intel Pro 1000 MT (driver e1000)
there crash with impossibility to open the session! Indeed, no icon ctrl alt f2 inactive ! [sudo] Mot de passe de marco : -- Logs begin at jeu. 2018-05-10 23:46:47 CEST, end at sam. 2018-05-19 18:52:03 CEST. -- mai 19 17:30:17 localhost.localdomain /etc/sysconfig/network-scripts/ifup-eth[1237]: Device enp0s29u1u2 does not seem to be present, delaying initialization. mai 19 17:30:18 localhost.localdomain /etc/sysconfig/network-scripts/ifup-eth[1312]: Device wlp0s29u1u2 does not seem to be present, delaying initialization. mai 19 17:30:18 localhost.localdomain systemd[1]: Failed to start LSB: Bring up/down networking. mai 19 17:30:18 localhost.localdomain cupsd[1399]: Missing value on line 158 of /var/cache/cups/job.cache. mai 19 17:30:18 localhost.localdomain cupsd[1399]: Missing value on line 642 of /var/cache/cups/job.cache. mai 19 17:30:18 localhost.localdomain cupsd[1399]: Missing value on line 1121 of /var/cache/cups/job.cache. mai 19 17:30:18 localhost.localdomain cupsd[1399]: Missing value on line 1134 of /var/cache/cups/job.cache. mai 19 17:30:18 localhost.localdomain cupsd[1399]: Missing value on line 1147 of /var/cache/cups/job.cache. mai 19 17:30:18 localhost.localdomain cupsd[1399]: Missing value on line 1160 of /var/cache/cups/job.cache. mai 19 17:30:18 localhost.localdomain cupsd[1399]: Missing value on line 1173 of /var/cache/cups/job.cache. mai 19 17:30:18 localhost.localdomain cupsd[1399]: Missing value on line 1518 of /var/cache/cups/job.cache. mai 19 17:30:18 localhost.localdomain cupsd[1399]: Missing value on line 1531 of /var/cache/cups/job.cache. mai 19 17:30:18 localhost.localdomain cupsd[1399]: Missing value on line 2916 of /var/cache/cups/job.cache. mai 19 17:30:26 localhost.localdomain /hp-systray[3782]: hp-systray[3782]: error: option -s not recognized mai 19 17:30:52 localhost.localdomain sddm-helper[5145]: pam_systemd(sddm-greeter:session): Failed to create session: Refusing activation, D-Bus is shutting down. mai 19 17:30:53 localhost.localdomain kernel: watchdog: watchdog0: watchdog did not stop!
CC: (none) => marcounet
In real its hanging on the login
CC: (none) => gerdroscher
Created attachment 10175 [details] Bullrich-boot
and here is the journalctl --> https://www.file-upload.net/download-13137442/Bullrich-journal.txt.html
(In reply to Gerd Roscher from comment #5) > In real its hanging on the login In comment #4, I see a line: mai 19 17:30:52 localhost.localdomain sddm-helper[5145]: pam_systemd(sddm-greeter:session): Failed to create session: Refusing activation, D-Bus is shutting down. In your logs, you alternately used the old and the new kernel. I see sddm-helper/pam_systemd errors when the new kernel is used: 1) Until 09:16:51 Old kernel (4.14.30-desktop-3.mga6): no such errors 2) New kernel (4.14.40-desktop-1.mga6) gives: Mai 19 09:18:16 localhost sddm-helper[1676]: pam_systemd(sddm-greeter:session): Failed to create session: Failed to activate service 'org.freedesktop.login1': timed out Mai 19 09:18:50 localhost sddm-helper[2142]: pam_systemd(sddm:session): Failed to create session: Failed to activate service 'org.freedesktop.login1': timed out Mai 19 09:53:44 localhost sddm-helper[6413]: pam_systemd(sddm-greeter:session): Failed to create session: Failed to activate service 'org.freedesktop.login1': timed out 3) 09:57:30 old kernel, no such errors 4) 09:58:23 new kernel, those errors again: Mai 19 09:59:36 localhost sddm-helper[2186]: pam_systemd(sddm-greeter:session): Failed to create session: Failed to activate service 'org.freedesktop.login1': timed out Mai 19 10:00:10 localhost sddm-helper[2492]: pam_systemd(sddm:session): Failed to create session: Failed to activate service 'org.freedesktop.login1': timed out 5) 10:10:01: old kernel, no such errors I don't know how the kernel version can make a difference here CC'ing basesystem and sddm maintainers. I'm not sure this is the same issue as the issue of the original reporter, though! If Adrien_D supplies logs, we may need to split this bug report!
CC: (none) => basesystem, kde, marja11
(In reply to Gerd Roscher from comment #7) > and here is the journalctl --> > > https://www.file-upload.net/download-13137442/Bullrich-journal.txt.html Please attach the logs to this bugreport.
CC: (none) => tmb
Created attachment 10177 [details] Gerd's journalctl output from when the new kernel was installed until some boots later. (In reply to Thomas Backlund from comment #9) > (In reply to Gerd Roscher from comment #7) > > and here is the journalctl --> > > > > https://www.file-upload.net/download-13137442/Bullrich-journal.txt.html > > > Please attach the logs to this bugreport. I may have been unclear when telling him how to compress them, Bugzilla still wouldn't accept his attachment when he tried again. I'll attach them for him. @ Gerd/Bullrich I had renamed your file, so it had the bug number at the beginning of the name. $ ls -alh 23060_Bullrich-journal.txt -rw-rw-r-- 1 marja marja 1,2M mei 20 12:13 23060_Bullrich-journal.txt It was compressed with xz from 1,2M to 61K like this: $ xz 23060_Bullrich-journal.txt $ ls -alh 23060_Bullrich-journal.txt.xz -rw-rw-r-- 1 marja marja 61K mei 20 12:13 23060_Bullrich-journal.txt.xz and that compressed file is what I'm now attaching.
CC: (none) => bequimao.de
I can confirm on my laptop too. It is not only slow, but I have multiple service failures, CUPS, Bluetooth and even logind. When the login window appears (sddm), it is not of correct size, something seems to be wrong with the resolution, so xorg may be also behaving in a funny way. Trying to login into fvwm2 takes 1min, the system cannot be shutdown afterwards, neither by poweroff, neither by the shutdown button on sddm. Suspending does not occur neither. Reverting to kernel 4.14.30, everything works fine!
CC: (none) => eatdirtPriority: Normal => High
bug 23066 was filed about network (wlan) problems with the new kernel. I don't know whether all mentioned issues here and the one in that report have the same cause or not, so I won't close it as duplicate.
same here after update to kernel 4.14.40 but only on my virtual guests. Journal with the following errors: --------------------------------------------------------------- Mai 20 23:37:12 xxxxx.xx dbus[710]: [system] Activating systemd to hand-off: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service' Mai 20 23:37:12 xxxxx.xx kernel: audit: type=1100 audit(1526852232.689:84): pid=2025 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_listfile,pam_unix acct="root" exe="/usr/sbin/sshd" hostname=xxxxx.xxxxx.xx addr=192.168.1.130 terminal=ssh res=success' Mai 20 23:37:12 xxxxx.xx kernel: audit: type=1101 audit(1526852232.689:85): pid=2025 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_tcb acct="root" exe="/usr/sbin/sshd" hostname=xxxxx.xxxxx.xx addr=192.168.1.130 terminal=ssh res=success' Mai 20 23:37:12 xxxxx.xx kernel: audit: type=1103 audit(1526852232.689:86): pid=2023 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_listfile,pam_env,pam_unix acct="root" exe="/usr/sbin/sshd" hostname=xxxxx.xxxxx.xx addr=192.168.1.130 terminal=ssh res=success' Mai 20 23:37:20 xxxxx.xx dbus[710]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out Mai 20 23:37:20 xxxxx.xx systemd-logind[2022]: Failed to enable subscription: Failed to activate service 'org.freedesktop.systemd1': timed out Mai 20 23:37:20 xxxxx.xx systemd-logind[2022]: Failed to fully start up daemon: Connection timed out Mai 20 23:37:20 xxxxx.xx systemd[1]: systemd-logind.service: Main process exited, code=exited, status=1/FAILURE Mai 20 23:37:20 xxxxx.xx audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Mai 20 23:37:20 xxxxx.xx systemd[1]: Failed to start Login Service. Mai 20 23:37:20 xxxxx.xx systemd[1]: systemd-logind.service: Unit entered failed state. Mai 20 23:37:20 xxxxx.xx systemd[1]: systemd-logind.service: Failed with result 'exit-code'. Mai 20 23:37:20 xxxxx.xx systemd[1]: systemd-logind.service: Service has no hold-off time, scheduling restart. Mai 20 23:37:20 xxxxx.xx systemd[1]: Stopped Login Service. Mai 20 23:37:20 xxxxx.xx systemd[1]: Starting Login Service... Mai 20 23:37:20 xxxxx.xx kernel: audit: type=1130 audit(1526852240.639:87): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Mai 20 23:37:20 xxxxx.xx kernel: audit: type=1130 audit(1526852240.639:88): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Mai 20 23:37:20 xxxxx.xx kernel: audit: type=1131 audit(1526852240.639:89): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Mai 20 23:37:20 xxxxx.xx audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Mai 20 23:37:20 xxxxx.xx audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Mai 20 23:37:37 xxxxx.xx dbus[710]: [system] Failed to activate service 'org.freedesktop.login1': timed out Mai 20 23:37:37 xxxxx.xx sshd[2023]: pam_systemd(sshd:session): Failed to create session: Failed to activate service 'org.freedesktop.login1': timed out Mai 20 23:37:37 xxxxx.xx sshd[2023]: pam_unix(sshd:session): session opened for user root by (uid=0) ------------------------------------------------------------------------------- with the old kernel 4.14.30 all works fine.
CC: (none) => dieter
There is a new kernel-4.14.42-1.mga6 in updates_testing, please test that one...
I did not have the problem described in this bug I did not find a bug for kernel-4.14.42, but tested now it runs OK on my workstation, no regressions noted.
(In reply to Thomas Backlund from comment #14) > There is a new kernel-4.14.42-1.mga6 in updates_testing, please test that > one... Boot stopped after «Started command schedulder», but boot is not slow. I have a problem with graphical interface i think now
Created attachment 10179 [details] Boot kernel 4.14.42
kernel-4.14.42-1.mga6 x86-64 is also not working, its hanging on the login rpm -qa --last | head kernel-desktop-latest-4.14.42-1.mga6.x86_64 Mo 21 Mai 2018 09:49:20 CEST kernel-desktop-4.14.42-1.mga6-1-1.mga6.x86_64 Mo 21 Mai 2018 09:29:53 CEST meta-task-6-2.1.mga6.noarch Mo 21 Mai 2018 09:29:50 CEST sddm-0.14.0-13.2.mga6.x86_64 So 20 Mai 2018 01:24:04 CEST mc-4.8.20-1.mga6.x86_64 So 20 Mai 2018 01:24:04 CEST kernel-desktop-4.14.40-1.mga6-1-1.mga6.x86_64 Sa 19 Mai 2018 09:16:11 CEST cpupower-4.14.40-1.mga6.x86_64 Sa 19 Mai 2018 09:16:11 CEST rootcerts-java-20180411.00-1.mga6.noarch Do 17 Mai 2018 17:14:59 CEST rootcerts-20180411.00-1.mga6.noarch Do 17 Mai 2018 17:14:59 CEST lib64lm_sensors4-3.4.0.git20180318-1.mga6.x86_64 Do 17 Mai 2018 17:14:59 CEST
After installing VirtualBox Additions with CD (instead of Mageia's RPM), graphical start. The boot is correct with 4.14.42 I retry with 4.14.40 : always slow The boot on 4.9.35 is faster than 4.14.42 But with 4.14.42 in the VirtualBox problem dissappear
I have tested 4.14.42-1-desktop, updated together with microcode-0.20180425-1 and kernel-firmware-nonfree-20180518-1 from non-free/update_testings (not a typo, microcode is from 20180425). No progress :( logind failed at boot, CUPS failed, Bluetooth, power management, exactly as for 4.14.40! Cheers.
(In reply to Chris Denice from comment #20) > I have tested 4.14.42-1-desktop, updated together with > microcode-0.20180425-1 and kernel-firmware-nonfree-20180518-1 from > non-free/update_testings (not a typo, microcode is from 20180425). > > No progress :( logind failed at boot, CUPS failed, Bluetooth, power > management, exactly as for 4.14.40! > > Cheers. Can you attach journalctl log of working 4.14.30 and non-working 4.14.42 so we possibly can see where it fails ?
Created attachment 10180 [details] latest journalctl compressed latest journalctl compressed from 2018-05-21
Created attachment 10181 [details] Excerpt of journalctl from Qemu/KVM Tested on a Sony Vaio E Series notebook - Intel i5 4Core Host: kernel driver radeon, Radeon HD 7550M/7570M/7650M [root@mag6-final ~]# uname -a Linux mag6-final 4.14.42-desktop-1.mga6 #1 SMP Sun May 20 23:25:51 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Everything looks ok - no regression found Guest Mageia 6 on qemu/kvm kernel 4.14.42-desktop-1.mga6 kernel driver virtio-pci DE Gnome does not boot into a working desktop. Virt-manager no virtual console with Send key Ctrl + Alt + F2 If I boot the same kernel in recovery mode, log in as root, and then type [Ctrl D] to continue without any command, the system boots into a functional desktop. Previous kernel 4.14.34-1 is working fine on same guest. Ulrich Beckmann
Here we go. For kernel-4.14.42, the following occurs: Failed service visible on the screen at boot time: logind, upower, cups, modemmanager, bluetooth. I cannot get to a console with CTRL+ALT+FX, sddm login windows has wrong resolution but I can log into fvwm2 waiting for a while Doing a su takes also a long time... but I can finally do a journalctl -b -0 :) Attached the two logs gotten by journalctrl -b -0, for 4.14.30 and 4.14.42. Cheers.
Created attachment 10182 [details] output of journalctrl -b -0 for kernel 4.14.30
Created attachment 10183 [details] output of journalctrl -b -0 for kernel 4.14.42
(In reply to Ulrich Beckmann from comment #23) > Created attachment 10181 [details] > Excerpt of journalctl from Qemu/KVM > > Tested on a Sony Vaio E Series notebook - Intel i5 4Core > Host: > kernel driver radeon, Radeon HD 7550M/7570M/7650M > ... > Guest Mageia 6 on qemu/kvm > kernel 4.14.42-desktop-1.mga6 > kernel driver virtio-pci > Tested now kernel 4.14.42-desktop-1.mga7 in a Cauldron installation on the same machine and the same kernel on Qemu/KVM, KDE Plasma. Host is Fedora 28. Everything is working fine. Cloned the virtual machine as of comment#24 and tested under host Fedora 28 and got the same issues as documented in comment#24. Ulrich
correction Cloned the virtual machine as of comment#23 and tested under host Fedora 28 and got the same issues as documented in comment#23. Ulrich
I confirm that all my 'real' AMD machines are very slow when booting in 4.14.40. The consequence is that several systemd units like 'rtkit' and 'login' never start. The system is unusable. Booting with previous 4.14.30 kernel is OK.
CC: (none) => richard
In my case (fully virtualized environment running on vmware vsphere), one virtual machine is running apparently fine with 4.14.40, while another machine has problems starting systemd-logind (I have yet another one I don't dare to reboot). Apart from the longish time to login and the fact that systemctl only works as root, I see no other adverse effects. This is the output of journalctl -xe mai 22 12:20:43 ftpserver systemd[1]: Starting Login Service... -- Subject: Unit systemd-logind.service has begun start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-logind.service has begun starting up. mai 22 12:21:08 ftpserver dbus[2921]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out mai 22 12:21:08 ftpserver systemd-logind[3024]: Failed to enable subscription: Failed to activate service 'org.freedesktop.systemd1': timed out mai 22 12:21:08 ftpserver systemd-logind[3024]: Failed to fully start up daemon: Connection timed out mai 22 12:21:08 ftpserver audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed mai 22 12:21:08 ftpserver audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=succes mai 22 12:21:08 ftpserver audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success mai 22 12:21:08 ftpserver systemd[1]: systemd-logind.service: Main process exited, code=exited, status=1/FAILURE mai 22 12:21:08 ftpserver systemd[1]: Failed to start Login Service. -- Subject: Unit systemd-logind.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-logind.service has failed. -- -- The result is failed. mai 22 12:21:08 ftpserver systemd[1]: systemd-logind.service: Unit entered failed state. mai 22 12:21:08 ftpserver systemd[1]: systemd-logind.service: Failed with result 'exit-code'. mai 22 12:21:08 ftpserver systemd[1]: systemd-logind.service: Service has no hold-off time, scheduling restart.
CC: (none) => luca
Same here. Mageia 6 virtualized under KVM, after an update to 4.14.40 started experiencing the above issues. From what I've learned, the update somehow renders unusable the D-Bus system (and thus the majority of systemd-related services). Yet couldn't figure out the exact mechanism yet. 4.14.42 shows exactly the same. PS for testing purposes I highly recommend mkosi: https://github.com/systemd/mkosi It will give you a (minimal) bootable Mageia image in less a minute, and then you can boot into it with qemu-kvm.
CC: (none) => mitya
CC: (none) => choucroot
This is weird... there must be some timing issue somewhere... I cant reproduce on my server, workstation or laptop :/ There is a 4.14.43-1 now in testing, does that work any better ? If not, does it also happend with kernel-linus-4.14.43-1 (from testing)
Happens also here on my laptop - Thinkpad X260 Boot very slow, at last sddm gets up and accepts user password. Plasma desktop starts only to wallpaper&mouse cursior. After forcing poweroff (keeping power button down more than 5 sec) the next boot seems to be OK. And so on in turns...
CC: (none) => jyri2000
CC: (none) => mandriva
Also, regarding timing issues.... does kernel-server behave differently ?
I am using kernel-server (sorry for not telling it in comment #30, I only reported it to the mailing list).
I can confirm this issue on Intel Celeron J1900 (non-virtualized) with standard desktop kernel too: slow startup and some services (e.g. login,...) not started or timed out. A few messages: systemd[1]: Failed to start Login Service. systemd[1]: systemd-logind.service: Main process exited, code=exited, status=1/FAILURE systemd-logind[900]: Failed to fully start up daemon: Connection timed out systemd-logind[900]: Failed to add match for JobRemoved: Connection timed out systemd[1]: Looping too fast. Throttling execution a little. systemd[1]: Looping too fast. Throttling execution a little. systemd[1]: Looping too fast. Throttling execution a little. systemd[1]: Failed to subscribe to NameOwnerChanged signal for 'org.freedesktop.UPower': Connection timed out systemd[1]: Failed to subscribe to NameOwnerChanged signal for 'org.freedesktop.login1': Connection timed out
CC: (none) => mageia
(In reply to Thomas Backlund from comment #32) > There is a 4.14.43-1 now in testing, does that work any better ? Yes, kernel 4.14.43-1 seems to boot OK! Thanks!
kernel-server-4.14.43-1 also seems to boot fine and it is able to start systemd-logind, however it required to uninstall microcode-0.20180312-1
(In reply to Luca Olivetti from comment #38) > kernel-server-4.14.43-1 also seems to boot fine and it is able to start > systemd-logind, however it required to uninstall microcode-0.20180312-1 Yeah, sorry about not pointing out that… if you would have had nonfree updates testing enabled, it would have pulled in the updated nonfree microcodes and firmwares at the same time
I installed the updated microcode package and - the first time it booted fine - subsequent reboots still had the error (systemd-logind not starting) I uninstalled microcode again but it still fails. I guess the problem is still there, but being a timing issue/a race somewhere, it doesn't manifest itself every time (hence my other machine booting fine even with 4.14.40). It's also possible that the time it booted fine it was 4.14.30 (since I set that as default in grub), but I'm quite sure that I manually selected 4.14.43.
I installed kernel-lins-4.14.43-1 and I booted it 5 times, everything is fine (though right now it has some problem rebooting, it is stuck trying to stop winbind).
I'm not sure if this helps: yesterday 4.14.40 was fine when 4.14.30 was bootet before and the system was not switched off. I'll give kernel-desktop-4.14.43-1 a try after lunch.
too bad that the 4.14.40 kernel has not been pulled from updates with all the affected users (same here) :-/
CC: (none) => lohmaier+mageia
(In reply to Christian Lohmaier from comment #43) > too bad that the 4.14.40 kernel has not been pulled from updates with all > the affected users (same here) :-/ It wont be removed, because it does not affect everyone and fixes several important bugs and security issues… Does 4.14.43 work for you?
4.14.43 does NOT work on J1900, it still fails to start several services!
(In reply to Marc Krämer from comment #45) > 4.14.43 does NOT work on J1900, it still fails to start several services! can you provide more infos ? like which services fails to start, etc.
It is the same as in the first posting: systemd-logind[893]: Failed to add match for JobRemoved: Connection timed out systemd-logind[893]: Failed to fully start up daemon: Connection timed out systemd[1]: Failed to subscribe to NameOwnerChanged signal for 'org.freedesktop.UPower': Connection timed out [...] systemd[1]: Looping too fast. Throttling execution a little. (this repeats several times) Attaching full journal-log (in reverse order)
Created attachment 10186 [details] full journal-log 4.14.43 (in reverse order)
Please test kernel-desktop-4.14.43-1.1.mga6 from: http://ftp.free.fr/mirrors/mageia.org/people/tmb/mga6/bugs/23060/
Keywords: (none) => NEEDINFO
(In reply to Thomas Backlund from comment #49) > Please test kernel-desktop-4.14.43-1.1.mga6 > (or desktop506 or server, depending on what you normally use) > from: > > http://ftp.free.fr/mirrors/mageia.org/people/tmb/mga6/bugs/23060/
I tested the server variant from the link in comment #50 The first and second boot were fine, but with the third reboot the problem resurfaced. $ uname -a Linux ftpserver 4.14.43-server-1.1.mga6 #1 SMP Thu May 24 19:54:51 EEST 2018 x86_64 x86_64 x86_64 GNU/Linux I noticed this while booting, I don't know if it's relevant: [ 34.031599] random: crng init done [ 34.031806] random: 7 urandom warning(s) missed due to ratelimiting (though one subsequent boot, working fine, still shows the same message)
After two more failed boot attempts I'm back to kernel linus
The same with 4.14.43-server-1.1.mga6. However I've noticed a weird thing - normally, the boot is stuck at "Started D-Bus System Message Bus", which is then followed by timeouts and service failures. However, if at this moment you press any key(s) 10+ times, the boot will go on as if nothing happened! Sounds crazy, but the result is very stable. I've reproduced it a dozen times under qemu-kvm and VirtualBox. Initially, I've discovered it when I tried to scroll back the output with Shift-PgUp, but then it turned out that virtually any key works, including Shift alone. Hope this helps somehow.
(In reply to Dimitri Jakov from comment #53) > The same with 4.14.43-server-1.1.mga6. > > However I've noticed a weird thing - normally, the boot is stuck at "Started > D-Bus System Message Bus", which is then followed by timeouts and service > failures. However, if at this moment you press any key(s) 10+ times, the > boot will go on as if nothing happened! Sounds crazy, but the result is very > stable. I've reproduced it a dozen times under qemu-kvm and VirtualBox. > Initially, I've discovered it when I tried to scroll back the output with > Shift-PgUp, but then it turned out that virtually any key works, including > Shift alone. Hope this helps somehow. ok, that somewhat confirms my next possible suspect... nws kernel to test coming up tomorrow...
CC: (none) => julien.moragny
(In reply to Thomas Backlund from comment #54) > ok, that somewhat confirms my next possible suspect... Does it have something to do with RNG and entropy? Seems like we're running into the early entropy depletion issue, which the "crng init done" is a sign of. There are tons of info in Google on that, we're not the first. Arch Wiki is useful (as always): > In above example, the system has long reached its default boot target before the kernel gathered enough entropy to initialize the pool. Due to systemd requiring entropy at an early stage, it may happen though that the pool is depleted in the boot process without further kernel warnings. > The random number generator gathers environmental noise from device drivers and other sources into an entropy pool. https://wiki.archlinux.org/index.php/Random_number_generation I suspect that in 4.14.40 something has changed in the mechanism of entropy collection, and virtualized hardware can't provide enough entropy anymore. Pressing keys just helps the system to obtain enough entropy and go on. (Yet I can't figure out how to tackle this in a general way.)
There is now a 4.14.43-1.2.mga6 available at the same place to test...
https://unix.stackexchange.com/questions/442698/when-i-log-in-it-hangs-until-crng-init-done Did we have CVE-2018-1108 fix backported from 4.16?
(In reply to Dimitri Jakov from comment #57) > https://unix.stackexchange.com/questions/442698/when-i-log-in-it-hangs-until- > crng-init-done > > Did we have CVE-2018-1108 fix backported from 4.16? It landed in upstream 4.14.39... It's that which I have reverted in the 4.14.43-1.2.mga6 build
No luck with 4.14.43-1.2.mga6 :( tried the kernel-server variant, all the same
BTW installing haveged helps, as suggested on StackExchange. It confirms we've likely run into the same issue
There is now a 4.14.43-1.3.mga6 with more fixes available at the same place to test...
Congratulations! you've finally squashed it :) Everything boots smoothly, the "crng init done" appears after console login, but it doesn't block any system process (just like it supposed to work I guess)
(In reply to Jüri Ivask from comment #37) > (In reply to Thomas Backlund from comment #32) > > There is a 4.14.43-1 now in testing, does that work any better ? > > Yes, kernel 4.14.43-1 seems to boot OK! Thanks! Was too optimistic about that... :( Hope I can say now: Yes, kernel 4.14.43-1.3 seems to boot so far OK! Thanks!
I booted kernel-server 4.14.43-1.3 5 times in a row with no problem (well, the first time it couldn't automount my nfs home directory, but that happens from time to time).
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=23085
Adding the 3 reporters of possible duplicates bug #23066 and bug #23085 to the CC List of this report, because it is here that logs are asked and new kernels to be tested are announced.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=23066CC: (none) => d.nigbur, kriks, yohonet
Pleae test that 4.14.44-1 in updates_testing still works for you all...
Hello, It seems ok for me, on two real hardware (AMD) that previously have the "slow" issue. The compilation of dkms nvidia module is also ok. I use these packages : - kernel-server-latest-4.14.44-1.mga6 (update-testing) - kernel-server-4.14.44-1.mga6-1-1.mga6 (update-testing) - kernel-server-devel-4.14.44-1.mga6-1-1.mga6 (update-testing) - microcode-0.20180425-1.mga6.nonfree - radeon-firmware-20180518-1.mga6.nonfree
I have been having this issue with all of the 4.14.X series of released kernels. The most recent kernel that still boots for me is kernel-desktop-4.9.56-1.mga6-1-1.mga6. Every new kernel released since that version does not pass the boot message: "Checking for new hardware". There is a continual loop through the messages: (1 of 3) A start job is running for PowerTOP autotuner (2 of 3) A start job is running for LSB: Bring up/down networking (3 of 3) A start job is running for LSB: Wait for the hotplugged network to be up If I wait the full five minutes for the start job timer to time out, the system is unusable. At that point rebooting the system via Ctl-Alt-Del goes through a similar cycle until it eventually shuts down. I downloaded and installed kernel-desktop-4.14.44-1.mga6-1-1.mga6, cpupower-4.14.44-1.mga6, kernel-firmware-nonfree-20180518-1.mga6.nonfree, and microcode-0.20180425-1.mga6.nonfree. The same symptoms as describe above are seen when booting kernel-4.14.44. I am uploading the output from lspci as well as the kernel-4.14.44 boot log. Would be great to get this issue sorted out.
CC: (none) => scott
Created attachment 10193 [details] lspci output for XPS15 lspci output for system that cannot boot any kernel released since 4.9.56
Created attachment 10194 [details] Boot log from kernel-4.14.44 on XPS15
Created attachment 10195 [details] Boot log from kernel-4.9.56 on XPS15 For comparison with the kernel-4.14.44 boot log on this system
From my side with kernel-server-4.14.44-1.mga6-1-1.mga6 on boot after reached target socket 5 second wait. Then everything works fine Tested on kvm qemu guest who has trouble on kernel 4.14.40 Tested on intel atom (not virtual) who has trouble on kernel 4.14.40 installed packages kernel-server-latest-4.14.44-1.mga6 (update-testing) kernel-server-4.14.44-1.mga6-1-1.mga6 (update-testing) kernel-firmware-nonfree-20180518-1.mga6.nonfree (nonfree-testing) microcode-0.20180425-1.mga6.nonfree (nonfree-testing) radeon-firmware-20180518-1.mga6.nonfree (nonfree-testing)
Hello, happy to have found this bug. I've got a brix (bxbt-1900 [1]) with doesn't start with 4.14.40. The journal show errors related to crng and multiples services don't start. kernel-desktop-4.14.44-1.mga6 solve the problem. Thank you. regards |1]https://www.gigabyte.com/Mini-PcBarebone/GB-BXBT-1900-rev-10#sp
(In reply to Scott Karns from comment #68) > I have been having this issue with all of the 4.14.X series of released > kernels. The most recent kernel that still boots for me is > kernel-desktop-4.9.56-1.mga6-1-1.mga6. Every new kernel released since that > version does not pass the boot message: "Checking for new hardware". There > is a continual loop through the messages: > > (1 of 3) A start job is running for PowerTOP autotuner > (2 of 3) A start job is running for LSB: Bring up/down networking > (3 of 3) A start job is running for LSB: Wait for the hotplugged network to > be up > This is because of a reference to an non-existing interface: network[1364]: Bringing up interface eth0: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device eth0 does not seem to be present, delaying initialization. /etc/sysconfig/network-scripts/ifup-eth[1637]: Device eth0 does not seem to be present, delaying initialization. > If I wait the full five minutes for the start job timer to time out, the > system is unusable. At that point rebooting the system via Ctl-Alt-Del goes > through a similar cycle until it eventually shuts down. > > I downloaded and installed kernel-desktop-4.14.44-1.mga6-1-1.mga6, > cpupower-4.14.44-1.mga6, kernel-firmware-nonfree-20180518-1.mga6.nonfree, > and microcode-0.20180425-1.mga6.nonfree. The same symptoms as describe above > are seen when booting kernel-4.14.44. > > I am uploading the output from lspci as well as the kernel-4.14.44 boot log. > Would be great to get this issue sorted out. This is not the same issue as this bug... In your case the brcmfmac driver crashes.... kernel: BUG: unable to handle kernel NULL pointer dereference at (null) kernel: IP: call_commit_handler.part.10+0xc/0x30 kernel: PGD 80000004a90c9067 P4D 80000004a90c9067 PUD 49e048067 PMD 0 kernel: Oops: 0000 [#1] SMP PTI kernel: Modules linked in: bnep msr snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel snd_hda_codec_realtek kvm snd_hda_codec_generic irqbypass iTCO_wdt intel_cstate iTCO_vendor_support mei_wdt nls_utf8 nls_cp437 vfat fat dell_laptop intel_uncore snd_hda_intel intel_rapl_perf brcmfmac snd_hda_codec psmouse fuse snd_hda_core input_leds dell_wmi brcmutil snd_hwdep dell_smbios dcdbas wmi_bmof snd_pcm i2c_i801 cfg80211 snd_timer cdc_ether btusb snd usbnet uvcvideo btrtl btbcm btintel soundcore rtsx_pci_ms r8152 joydev videobuf2_vmalloc bluetooth videobuf2_memops videobuf2_v4l2 mii videobuf2_core memstick videodev idma64 virt_dma mei_me mei tpm_tis intel_lpss_pci media intel_lpss ecdh_generic tpm_tis_core rfkill tpm intel_pch_thermal battery intel_hid thermal fan kernel: int3403_thermal sparse_keymap int3402_thermal acpi_pad int3400_thermal ac acpi_thermal_rel processor_thermal_device shpchp int340x_thermal_zone intel_soc_dts_iosf nfsd auth_rpcgss oid_registry nfs_acl lockd grace nvram evdev sunrpc sch_fq_codel efivarfs ipv6 crc_ccitt autofs4 hid_multitouch usbhid uas usb_storage dm_crypt nouveau crct10dif_pclmul rtsx_pci_sdmmc crc32_pclmul xhci_pci mmc_core crc32c_intel ghash_clmulni_intel xhci_hcd aesni_intel usbcore rtsx_pci nvme aes_x86_64 crypto_simd cryptd glue_helper mxm_wmi nvme_core i2c_hid ttm serio_raw hid usb_common wmi i915 video button i2c_algo_bit drm_kms_helper drm dm_mirror dm_region_hash dm_log dm_mod kernel: CPU: 5 PID: 1691 Comm: wpa_supplicant Not tainted 4.14.44-desktop-1.mga6 #1 kernel: Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 1.6.1 12/11/2017 kernel: task: ffff927fa8348000 task.stack: ffffbc80027c4000 kernel: RIP: 0010:call_commit_handler.part.10+0xc/0x30 kernel: RSP: 0018:ffffbc80027c7d78 EFLAGS: 00010202 kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 kernel: RDX: 0000000000000001 RSI: ffff927fbdd65a60 RDI: ffff927fa84a0000 kernel: RBP: 0000000000008b14 R08: 0000000000025a60 R09: ffffffffc0c10dcf kernel: R10: fffff886125f66c0 R11: ffffffffc0c0e560 R12: ffffbc80027c7df0 kernel: R13: ffffffffb50eadc0 R14: 00007ffd6439dfd0 R15: 0000000000000000 kernel: FS: 00007f03e11a2780(0000) GS:ffff927fbdd40000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000000 CR3: 00000004976be004 CR4: 00000000003606e0 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 kernel: Call Trace: kernel: wext_handle_ioctl+0x75/0xd0 kernel: dev_ioctl+0xe9/0x540 kernel: ? sock_ioctl+0x124/0x2c0 kernel: sock_ioctl+0x124/0x2c0 kernel: do_vfs_ioctl+0xa2/0x600 kernel: ? __schedule+0x3c5/0x860 kernel: SyS_ioctl+0x74/0x80 kernel: ? exit_to_usermode_loop+0x70/0xb0 kernel: do_syscall_64+0x6e/0x120 kernel: entry_SYSCALL_64_after_hwframe+0x3d/0xa2 kernel: RIP: 0033:0x7f03df7cf747 kernel: RSP: 002b:00007ffd6439dfc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 kernel: RAX: ffffffffffffffda RBX: 00007ffd6439e02a RCX: 00007f03df7cf747 kernel: RDX: 00007ffd6439dfd0 RSI: 0000000000008b14 RDI: 0000000000000004 kernel: RBP: 00000000013c1260 R08: 0000000000000000 R09: 0000000000000001 kernel: R10: 000000000001cff0 R11: 0000000000000246 R12: 00000000013c1260 kernel: R13: 0000000000000005 R14: 0000000000000000 R15: 0000000000000004 kernel: Code: 00 00 48 89 ee 4c 89 e8 e9 5b ff ff ff b8 ed ff ff ff eb ab 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 87 e0 01 00 00 <48> 8b 00 48 8b 00 48 85 c0 74 0b 31 c9 31 d2 31 f6 e9 6e ab 24 kernel: RIP: call_commit_handler.part.10+0xc/0x30 RSP: ffffbc80027c7d78 kernel: CR2: 0000000000000000 kernel: ---[ end trace 498118200f290279 ]---
(In reply to Thomas Backlund from comment #74) > In your case the brcmfmac driver crashes.... > does it work any different if you boot with "nopti" on kernel command line" ?
(In reply to Scott Karns from comment #68) > (1 of 3) A start job is running for PowerTOP autotuner I think powertop --auto-tune can do something bad to your hardware settings. Try to disable it with "systemctl disable powertop.service". Here I have tested the desktop 4.14.44 version in HP6450B, all is Ok.
CC: (none) => lists.jjorge
(In reply to Thomas Backlund from comment #75) > (In reply to Thomas Backlund from comment #74) > > > In your case the brcmfmac driver crashes.... > > > > > does it work any different if you boot with "nopti" on kernel command line" ? No joy when I added "nopti" to the kernel boot command line. I had already removed one troublemaker, /etc/sysconfig/network-scripts/ifcfg-eth0, after which I rebuilt initrd and tried booting 4.14.44 with "nopti" added to the kernel boot command line. As expected, the issue with eth0 is gone, but I am still unable to boot kernel 4.14.44. Thank you for reaching out on this issue. I'll continue searching for a solution.
@Scott, what hardware (CPU) do you use? Maybe the problem arises from slow / small CPUs like Celerons. On my other PC 4.14.40 worked fine, only on the Celeron it does not work. And here we know about simulated CPUs on KVM etc. Unfortunately I don't have the celeron available, so I can't test 4.14.44 :-(
(In reply to José Jorge from comment #76) > (In reply to Scott Karns from comment #68) > > (1 of 3) A start job is running for PowerTOP autotuner > > I think powertop --auto-tune can do something bad to your hardware settings. > Try to disable it with "systemctl disable powertop.service". > > Here I have tested the desktop 4.14.44 version in HP6450B, all is Ok. Thanks for the suggestion, José, but there was no significant change after disabling powertop.service. I'm coming to think the real culprit is indeed the stupid Broadcom WiFi hardware+driver, as noted by Thomas.
(In reply to Marc Krämer from comment #78) > @Scott, what hardware (CPU) do you use? Maybe the problem arises from slow / > small CPUs like Celerons. On my other PC 4.14.40 worked fine, only on the > Celeron it does not work. And here we know about simulated CPUs on KVM etc. > Unfortunately I don't have the celeron available, so I can't test 4.14.44 :-( Marc, I don't think it's a slow CPU, this laptop has an Intel Core i7-6700HQ running at a base clock rate of 2.6GHz.
4.14.44-desktop-1.mga6 (from Core Update Testing) has solved the 4.14.40 issue on my NUC NUC5CPYH (CPU Intel Celeron CPU N3050 @ 2.16GHz, GPU Mesa DRI Intel(R) HD Graphics 400 (Braswell) ) Regards
*** Bug 23085 has been marked as a duplicate of this bug. ***
*** Bug 23090 has been marked as a duplicate of this bug. ***
CC: (none) => d.kalweit
I installed kernel-server-4.14.44-2.mga6 from "Core updates testing" (bug #23075) and it boots fine.
(In reply to Ulrich Beckmann from comment #23) > Created attachment 10181 [details] > Excerpt of journalctl from Qemu/KVM > > Tested on a Sony Vaio E Series notebook - Intel i5 4Core > Host: > kernel driver radeon, Radeon HD 7550M/7570M/7650M > [root@mag6-final ~]# uname -a Linux mag6-final 4.14.44-desktop-2.mga6 #1 SMP Mon May 28 22:35:45 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Everything is fine. No regression found. > Guest Mageia 6 on qemu/kvm > kernel 4.14.42-desktop-1.mga6 > kernel driver virtio-pci > > DE Gnome does not boot into a working desktop. > Virt-manager no virtual console with Send key Ctrl + Alt + F2 > > If I boot the same kernel in recovery mode, log in as root, and then type > [Ctrl D] to continue without any command, the system boots into a functional > desktop. > > Previous kernel 4.14.34-1 is working fine on same guest. > > Ulrich Beckmann [root@mag6-gnome-vm ~]# uname -a Linux mag6-gnome-vm 4.14.44-desktop-2.mga6 #1 SMP Mon May 28 22:35:45 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux [root@mag6-gnome-vm ~]# [root@mag6-gnome-vm ~]# systemd-analyze Startup finished in 1.403s (kernel) + 11.195s (userspace) = 12.598s [root@mag6-gnome-vm ~]# dto. The issue is resolved with kernel 4.14.44-desktop-2.mga6. Ulrich
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0263.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
For those of you that hit the slow boot, would you mind testing the 4.14.60-1 kernel in testing (just built so its still mirroring out) I have re-enabled the fixes for CVE-2018-1108 that caused the slowdown as a fix was added in upstream 4.14.60 that should help... But I'd like confirmations that the fixes actually works as I cant reproduce the issue myself
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Hi Thomas and others ive just upgraded to 60 on all my systems from 56. at 56 i dont expirience this bug. at 60 i do, including some of the symptoms spoken about on this bug. for example slow book up systemctl login service not starting 1920x1080p desktop goes low resolution, around 1024 can enter password in login greeter but black screen , mouse still moves but never moves on from black screen. cntr-alt-f4 just blinking cursor. only way out is to power off. i can post my journal logs if you want, they are allready on discuss. but much the same as others are seeing. back to 56 and everything is OK. i did think it might be related to wifi , as that was updated at the time, and ive also saw wifi firmware issues, one time i disabled wifi laptop came up ok on 60. so i thought the current iwwifi firmware may be the cause as im also long time now been getting the wpa supplimant firmware issue on the intel 7260. im not sure looking here how related the wifi is. perhaps otheres can try. im running the 60 kernel on my threadripper without any issues at all. so this problem is on my asus ux31a laptop, which has been modified with a new SSD and a new 7250 duel band wireless. regards peter winterflood
CC: (none) => peter.winterflood
correctio: ive just upgraded to 60 on all my systems from 56. ive upgraded my aus ux31a and have the problem, ive upgraded one other and dont
update. id not noticed that after the last time i updated my 586 test platform, (44) kernel that it was also doing this, as i dont often switch this on. booted it back to 30 and its OK. updated to 60 and then 62 today after todays 62 qa call, and same. laptops not seeing 62 yet but will test as soon as its mirror is reflecting 62 in updates , but i already suspect 62 will affect ux31a like it is 586. my 586 is an msi 6763 also sold as packard bell. with nvidia agp 7300 and 3.2 gig pentium 4
Can confirm above 586 host msi ms-6763 with nvidia 304 driver and 4.14-56 also works fine. theres clearly an issue in 44 60 and 62 that is not happening in 56. perhaps others with this issue could confirm. regards peter
on my Brix (see comment #73), with kernel-desktop 4.14.62-1 ; boot is again very slow with some service failing to start and message regarding crng in the log. regards Julien
(In reply to Julien Moragny from comment #92) > on my Brix (see comment #73), with kernel-desktop 4.14.62-1 ; boot is again > very slow with some service failing to start and message regarding crng in > the log. > > > regards > Julien Ok, thanks for testing ... that means we need to revert it again :/ And probably keep it so ... a 4.14.62-2 is coming up...
kernel-4.14.62-2.mga6 is now available in testing
kernel 4.14.62-2 works like a charm :) (Brix BXBT 1900) thanks. regards Julien
confirmed kernel 4.14.62-2 works fine with my asus ux31a will confirm later the same on my 586 test host regards peter
Like a charm on laptop i7 & virtualbox 5.2
(In reply to Julien Moragny from comment #95) > kernel 4.14.62-2 works like a charm :) (Brix BXBT 1900) (In reply to peter winterflood from comment #96) > confirmed kernel 4.14.62-2 works fine with my asus ux31a (In reply to rexy from comment #97) > Like a charm on laptop i7 & virtualbox 5.2 Assuming that is still the case with latest kernel in updates, kernel-4.14.78-1.mga6, so closing as fixed. PLease reopen if needed.
Resolution: (none) => FIXEDStatus: REOPENED => RESOLVED
[marco@localhost ~]$ uname -r 4.14.78-desktop-1.mga6 works fine with ls11-hr packard bell