Hi. I've experimented with creating a minimal installation of MGA6 by removing packages, disabling services and so on. Using LightDM and Openbox, it uses about 110-111MB ram, with conky running. Total number of packages installed is now 1178. Was also able to uninstall all the Plymouth packages and the boot time in vmware is now approx 15 seconds. This is with 2 cores enabled and 2GB ram. On the host machine, the boot takes a lot longer. Especially from the time the bootsplash disappears until the login window shows up. Is there a way to optimize this to speed things up? Cheers, Stig
I think don't think uninstalling plymouth gave most of the time gain, I think it is mainly all the services that used to start while booting, and that you disabled. Anyway, you can attach log.txt that is the result of running, as root: journalctl -b > log.txt maybe we can easily find one or more culprits :-)
Keywords: (none) => NEEDINFOCC: (none) => marja11
Marja. You are right. I gained a lot by disabling services and such, but also gained a few seconds by removing Plymouth. Like I mentioned, it "hangs" a little while with a "Hold" message before the DM launches. Will attach a log on the next reboot of my computer. Cheers, Stig
Created attachment 9743 [details] journalctl -ab
Looks like it spends quite a while here: Oct 22 09:55:00 monster ifplugd(enp3s0)[1257]: Program executed successfully. Oct 22 09:55:00 monster kernel: userif-2: sent link down event. Oct 22 09:55:00 monster kernel: userif-2: sent link up event. Oct 22 09:55:19 monster chronyd[934]: Selected source 129.240.2.6 Oct 22 09:55:21 monster network-up[1484]: Waiting for network to be up[FAILED] Oct 22 09:55:21 monster systemd[1]: Started LSB: Wait for the hotplugged network to be up. And the date reminds me to call my sister for her birthday :-) Cheers, Stig
I haven't found time to read the attachment yet, sorry, but do you think it is a duplicate of bug 21055 ?
(In reply to Marja van Waes from comment #5) > I haven't found time to read the attachment yet, sorry, but do you think it > is a duplicate of bug 21055 ? Hi Marja. It is related, because I'm trying to hunt down the causes for the long boot time. This time around I found that having Plymouth enabled/installed made the boot take more time.
(In reply to Stig-Ørjan Smelror from comment #6) > (In reply to Marja van Waes from comment #5) > > I haven't found time to read the attachment yet, sorry, but do you think it > > is a duplicate of bug 21055 ? > > Hi Marja. > > It is related, because I'm trying to hunt down the causes for the long boot > time. ok I keep forgetting about the nice tools systemd has for that :-( Instead of reading the journalctl -b output, it is easier to run (as root) e.g. systemd-analyze blame https://www.freedesktop.org/software/systemd/man/systemd-analyze.html > > This time around I found that having Plymouth enabled/installed made the > boot take more time. How much time exactly? I'm curious whether that matches the output of, as root: systemd-analyze blame | grep plymouth
Created attachment 9751 [details] systemd-analyze-blame.txt
# systemd-analyze blame | grep plymouth 227ms plymouth-read-write.service 146ms plymouth-start.service 44ms plymouth-quit-wait.service 44ms plymouth-quit.service
Created attachment 9752 [details] systemd-analyze-blame-2.txt Marja, as you may see from the last log, it is the network that spends a lot of time during boot. I fired up MCC, went to Network & Internet -> Manage different network profiles -> Advanced (at the bottom). There I disabled - Firewall settings - Firewall settings (IPv6) - Proxy settings I have no need for these settings, but others may... As you can see from the second log, it is now mandriva-everytime.service that spends a lot of boot time. In my case, 20 seconds. Cheers, Stig
Hi Stig, Is this bug still valid? I hadn't assigned it to anyone, because I didn't know whom to assign it to :-[ Maybe I should have assigned it to the base system maintainers, because they have the best understanding of how to improve systemd's handling of several services, even when systemd isn't the culprit, but a Mageia tool or another package is.
I think it still i valid, but because I've tweaked my systems I don't see it much these days. Will close it since it doesn't look like anybody has the time to tweak the boot process. Perhaps M7 will see some improvements. CHeerio! Stig
Status: NEW => RESOLVEDResolution: (none) => WONTFIX