| Summary: | Mageia Faster Boot Would be Great! | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Ezequiel Partida <ezequiel_partida> |
| Component: | Release (media or process) | Assignee: | Base system maintainers <basesystem> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Normal | CC: | ouaurelien, sysadmin-bugs |
| Version: | Cauldron | ||
| Target Milestone: | Mageia 9 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
|
Description
Ezequiel Partida
2021-01-09 09:26:27 CET
Yeah. Faster boot time will be here when we ditch all init.d rc script for starting services and when network will be set by Network Manager, not the old initscripts. In the meantime, you could see which service delays the boot process by do: $ systemd-analyze blame This will tell you what make boot longer. If you can, disable such services. Don't disable network.service as long as you rely on Drakx-net applet to set network. CC:
(none) =>
ouaurelien Not sure really where to assign this. By the way, I do think this improvement can't be done for M8 now. Set milestone to M9. Put it to release, not really a RPM request. Therefore, I advice users to put here output of "$ systemd-analyze blame" to see where we should go to improve boot time. Component:
New RPM package request =>
Release (media or process) (In reply to Aurelien Oudelet from comment #1) > Yeah. Faster boot time will be here when we ditch all init.d rc script for > starting services and when network will be set by Network Manager, not the > old initscripts. Now that you mentioned.. I did see that a lot of services where executed on LXLE and boom!! It was booted! Now I know!.. ;-) > In the meantime, you could see which service delays the boot process by do: > > $ systemd-analyze blame > > This will tell you what make boot longer. > If you can, disable such services. > Don't disable network.service as long as you rely on Drakx-net applet to set > network. (In reply to Aurelien Oudelet from comment #2) > Not sure really where to assign this. > By the way, I do think this improvement can't be done for M8 now. > Set milestone to M9. > Put it to release, not really a RPM request. > > Therefore, I advice users to put here output of "$ systemd-analyze blame" > to see where we should go to improve boot time. Mageia 8 Rocks! I thing M9 would be amazing! Regards @ Ezequiel, Have you tried this: $ systemd-analyze blame to let know us what delays the boot process on your machine? Example: $ systemd-analyze blame 14.230s systemd-journal-flush.service 5.425s network-up.service 4.792s systemd-udev-settle.service 3.080s packagekit.service 2.928s dkms-autorebuild.service 1.545s udisks2.service 1.543s home.mount 1.260s lvm2-monitor.service 856ms systemd-random-seed.service 740ms shorewall.service 727ms mandriva-everytime.service 718ms systemd-fsck@dev-disk-by\x2duuid-73b3802f\x2df451\x2d4a9a\x2d8cb0\x2dc12621c8e45c.service 711ms systemd-fsck@dev-disk-by\x2duuid-03894e8a\x2d50d0\x2d4026\x2da829\x2d5c2fe72657f9.service 640ms network.service 555ms fwupd.service 453ms systemd-tmpfiles-setup.service On my system, very fast boot, but it is delayed by systemd-journal-flush.service because it is loaded on the same time systemd wants to mount /var and as long as my /var partition is on a rust-spinned drive... I know it is a side effect... having a NVMe for / and /var somewhere else... but it is my choice... In facts, the only other things that delays the boot process are: 5.425s network-up.service 4.792s systemd-udev-settle.service and: 2.928s dkms-autorebuild.service dkms-autorebuild.service is loaded early and blocks boot for about 3 sec. Too long. But, it is needed here as I use a dkms enabled graphic driver (nvidia) but, it should note take so looong because there nothing to do this time: no rebuilding (no new kernel, no new driver) systemd-udev-settle.service is deprecated and should be removed... not for M8... This is responsible to permit all coldplug devices to be recognized by udev... but it not necessary on modern hardware (no ISA...) and it is needed by all dmraid / lvm stuff that I don't have on my systems. Also, many average Desktop users will not have, because by default, our installer does not autosetup LVM partitions for newer installation, it uses basic partitions. (Contrary to Fedora) I could gain 4,7 sec here. and network-up.service is waiting to be online so it blocks boot process for 5.5 sec. But here it is fast for an old-initscript... I really wonder if NetworkManager will be as fast as it on my system. But, under many circumstances, NetworkManager will be faster than old initscripts... so... maybe. Regarding this, I could gain nearly 13 seconds for booting... Note that these services are launched each after one, not in parallel like other .service in systemd because they are needed by other one. So, I am patient, I do other stuff while this is booting. And it is not so loooong... But, I wonder what is going on your system. Assigning. This should no longer seen in Bugsquad. Assignee:
bugsquad =>
basesystem (In reply to Aurelien Oudelet from comment #6) > Example: > $ systemd-analyze blame > 14.230s systemd-journal-flush.service > > 5.425s network-up.service > > 4.792s systemd-udev-settle.service > > 3.080s packagekit.service > > 2.928s dkms-autorebuild.service > > 1.545s udisks2.service > > 1.543s home.mount > > 1.260s lvm2-monitor.service > > 856ms systemd-random-seed.service > > 740ms shorewall.service > > 727ms mandriva-everytime.service > > 718ms > systemd-fsck@dev-disk-by\x2duuid- > 73b3802f\x2df451\x2d4a9a\x2d8cb0\x2dc12621c8e45c.service > 711ms > systemd-fsck@dev-disk-by\x2duuid- > 03894e8a\x2d50d0\x2d4026\x2da829\x2d5c2fe72657f9.service > 640ms network.service > > 555ms fwupd.service > > 453ms systemd-tmpfiles-setup.service > > On my system, very fast boot, but it is delayed by > systemd-journal-flush.service > because it is loaded on the same time systemd wants to mount /var and as > long as my /var partition is on a rust-spinned drive... I know it is a side > effect... having a NVMe for / and /var somewhere else... but it is my > choice... > > In facts, the only other things that delays the boot process are: > 5.425s network-up.service > > 4.792s systemd-udev-settle.service > > and: > 2.928s dkms-autorebuild.service > > dkms-autorebuild.service is loaded early and blocks boot for about 3 sec. > Too long. But, it is needed here as I use a dkms enabled graphic driver > (nvidia) but, it should note take so looong because there nothing to do this > time: no rebuilding (no new kernel, no new driver) > > systemd-udev-settle.service is deprecated and should be removed... not for > M8... > This is responsible to permit all coldplug devices to be recognized by > udev... but it not necessary on modern hardware (no ISA...) and it is needed > by all dmraid / lvm stuff that I don't have on my systems. Also, many > average Desktop users will not have, because by default, our installer does > not autosetup LVM partitions for newer installation, it uses basic > partitions. (Contrary to Fedora) > I could gain 4,7 sec here. > > and > network-up.service is waiting to be online so it blocks boot process for 5.5 > sec. > But here it is fast for an old-initscript... I really wonder if > NetworkManager will be as fast as it on my system. But, under many > circumstances, NetworkManager will be faster than old initscripts... so... > maybe. > > Regarding this, I could gain nearly 13 seconds for booting... > Note that these services are launched each after one, not in parallel like > other .service in systemd because they are needed by other one. > > So, I am patient, I do other stuff while this is booting. And it is not so > loooong... > But, I wonder what is going on your system. Thank you for the info Aurelien. Mageia 8 is getting even faster to boot specially with SSD. Would it be to dificult to make them work in parallel like Kubuntu? I did some test and Kubuntu boots in around 5 seconds vs 13 mageia 8. Just asking! ;-) Hello Everyone, The new mageia 9 boot system is great.. Thanks for listening. Regards Status:
NEW =>
RESOLVED |