Description of problem: After an upgrade from an up-to-date Mageia 1, the boot process never ends. The Plymouth screen never disappears and the log behind always stops at the following lines : --------- Started USB legacy proc File System [ OK ] Using "/etc/ld.so.conf.d/standard/GL.conf" to provide "gl_conf" [ OK ] --------- Plymouth displays the Mageia logo that shows new bubbles after some long time, but looks stuck. The boot process never ends, and the X server and KDM are never launched. I have to wait some time for TTY2 to offer login to launch X and KDE myself. My cauldron is up-to-date according to the repositories. If a fresh install is always a better thing, no doubt it would be better if an upgrade could be done smoothly. Version-Release number of selected component (if applicable): systemd-44-12.mga2.x86_64 How reproducible: At each boot. Steps to Reproduce: 1. Take an up-to-date Mageia 1 (without backports) 2. Change it's medias to Cauldron 3. Update and reboot. Thank you in advance.
Using a VM, I have not seen this with my last tests, what's your graphic card ?
CC: (none) => mageia
Intel 82Q963/Q965 Integrated Graphics Controller
Just fyi, on my i586 system, using a live cd iso, this is where I see a roughly 4 minute delete, meaning roughly 6 minutes from grub to the asking for language. On an install done from the live cd, I get about a 2 minute delay. Thomas, how long are you waiting?
CC: (none) => davidwhodgins
I am waiting forever. This never moves or changes. This is why I go to TTY2 and type startx. I have noted that TTY2 becomes available about two minutes after these last bootlog lines appeared. I guess the boot process hangs just after the TTYs are started.
And by going to TTY2, I mean moving to it and waiting for the possibily to enter my user name and password. It takes about two minutes to see the message telling me to enter my IDs after he hit the last two bootlog messages.
OK, this looks like you have a deadlock in your boot cycle and systemd has just dropped the job that should start the X server to break the cycle. Basically the same issue as bug #5262 Now that particular issue should now be fixed, but that's not to say there are not other problems still present. Please see the debug steps here (and in future comments): https://bugs.mageia.org/show_bug.cgi?id=5262#c24 Please attach both dmesg outputs and also check the "systemctl show prefdm.service | grep ActiveEnterTimestamp" and "ls -l /etc/systemd/system/default.target" values. Cheers.
systemctl show prefdm.service | grep ActiveEnterTimestamp shows the following : ActiveEnterTimestampMonotonic=0 (in both TTY and graphical environment) ls -l /etc/systemd/system/default.target shows the following : lrwxrwxrwx 1 root root 36 mai 21 17:38 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel5.target
Created attachment 2355 [details] DMESG log file
Created attachment 2356 [details] Hang screenshot Please note that I actually have a DIFFERENT systemd bootlog, depending on when I press the Escape key to see the boot messages appearing : If I press Escape at the *beginning* of the boot process, the last systemd messages are the ones you can read in my first post. If I press Escape after a longer time, I see other messages as on the attached screenshot. In otherwords, I have different systemd messages depending on when I display them in the boot process.
(In reply to comment #7) > systemctl show prefdm.service | grep ActiveEnterTimestamp shows the following > : > ActiveEnterTimestampMonotonic=0 > (in both TTY and graphical environment) Yup, this is indicative that it didn't even attempt to start the graphical service as I expected. Sadly, I don't think you followed the instructions properly and did not appear to include the relevant kernel command line options needed to debug the issue. Please go back and read the comments on the other bug again (you'll see the same mistake was made there too initially! - not sure if I'm not being clear enough in my request? - feel free to ask for clarification if needed) As for the screenshot, that's not a hang, and the boot process is officially finished as far is pid 1 is concerned, so that's perfectly expected. We do however need to find out what is causing the ordering cycle on your machine - the proper debug from dmesg with the correct kernel command line arguments should do the job (and remember I need both dmesg output and the contents of /var/log/dmesg immediately after boot). Thanks.
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Still valid for Mageia 2.
Version: Cauldron => 2
Created attachment 2402 [details] Debug boot log2
Attachment 2355 is obsolete: 0 => 1
Created attachment 2403 [details] Debug boot log1
Keywords: NEEDINFO => (none)CC: (none) => sander.lepikVersion: 2 => CauldronWhiteboard: (none) => MGA2TOO
@Thomas, Can you find out what package is providing the file: /etc/init.d/arpd? You appear to have this initscript installed (either that or it's a native systemd unit), but I cannot see this file included in any package we ship. If you disable the arpd service (systemctl disable arpd.service) you should be able to boot fine.
It w
Darn... this issue was indeed caused by arpd, a very old package from Mandriva 2010.1. It is now removed and booting fine.
Ok cool, should we add an obsolete somewhere or close this bug as it ?
Just doing some housekeeping. This bug can be closed as we found the problem.
Status: NEW => RESOLVEDResolution: (none) => INVALID