Mageia forum

Two small, but irritating issues with Mageia 7.1 KDE:
Mageia is really slow at booting up.
Yakuake will not automatically hide at startup. I have to F12 Yakuake every startup to get it out of the way until I need it.

Please keep the golden rule in mind: only one problem per thread.

For the slow boot, please post the output of the following commands as root:

Code: Select all: systemd-analyze blame --no-pager systemd-analyze critical-chain systemd-analyze plot > boot.svg

and attach the resulting file boot.svg here (from the last command)

OK, will do.

Code: Select all: # systemd-analyze blame --no-pager 10.677s udisks2.service 6.415s network-up.service 6.266s network.service 5.256s systemd-udev-settle.service 4.617s polkit.service 4.451s shorewall.service 3.954s mandriva-everytime.service 3.425s dev-sdd2.device 3.262s cups.service 2.001s chronyd.service 1.957s upower.service 1.718s avahi-daemon.service 1.713s bluetooth.service 1.685s rtkit-daemon.service 1.683s systemd-logind.service 1.673s dbus.service 1.339s mga-bg-res.service 905ms resolvconf.service 764ms systemd-udevd.service 748ms preload.service 717ms media-win_c.mount 603ms dkms-autorebuild.service 589ms systemd-journal-flush.service 565ms media-win_c2.mount 560ms systemd-journald.service 526ms systemd-tmpfiles-setup-dev.service 444ms fedora-loadmodules.service 438ms systemd-fsck-root.service 429ms plymouth-quit.service 427ms fedora-readonly.service 420ms shorewall6.service 387ms numlock.service 300ms mdmonitor.service 299ms systemd-fsck@dev-disk-by\x2duuid-5d2652d7\x2da7dd\x2d4c21\x2d8c24\x2d9c7b56c67486.service 242ms msec.service 233ms dmraid-activation.service 232ms partmon.service 218ms systemd-sysctl.service 203ms systemd-udev-trigger.service 198ms acpid.service 188ms systemd-user-sessions.service 184ms dev-mqueue.mount 183ms sys-kernel-debug.mount 178ms boot-EFI.mount 177ms systemd-rfkill.service 177ms systemd-tmpfiles-setup.service 174ms gpm.service 169ms plymouth-quit-wait.service 166ms lvm2-activation-early.service 127ms proc-sys-fs-binfmt_misc.mount 121ms mdmonitor-takeover.service 89ms dev-hugepages.mount 88ms user@1000.service 85ms kmod-static-nodes.service 66ms dracut-shutdown.service 65ms systemd-tmpfiles-clean.service 60ms lvm2-monitor.service 58ms lvm2-activation.service 58ms dev-disk-by\x2duuid-10a999da\x2d6111\x2d4ae3\x2d8589\x2d1540e97f2dc1.swap 53ms home.mount 50ms systemd-update-utmp.service 47ms systemd-random-seed.service 43ms systemd-modules-load.service 41ms plymouth-read-write.service 40ms systemd-remount-fs.service 17ms systemd-vconsole-setup.service 17ms user-runtime-dir@1000.service 16ms plymouth-start.service 11ms systemd-update-utmp-runlevel.service 4ms tmp.mount 3ms sys-fs-fuse-connections.mount

Code: Select all: # systemd-analyze critical-chain The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. graphical.target @1min 46.942s └─udisks2.service @1min 36.264s +10.677s └─basic.target @1min 36.205s └─mandriva-everytime.service @1min 32.251s +3.954s └─dkms-autorebuild.service @1min 31.646s +603ms └─local-fs.target @1min 31.644s └─tmp.mount @1min 31.640s +4ms └─systemd-journald.socket @1.491s └─-.mount @1.489s └─system.slice @1.489s └─-.slice @1.489s

Code: Select all: systemd-analyze plot > boot.svg

Didn't return anything

Interesting, I have only recently started using distros with systemd... I can see that there are things that systemd is useful for.

globetrotterdk wrote:
Code: Select all
systemd-analyze plot > boot.svg

Didn't return anything

doktor5000 wrote:and attach the resulting file boot.svg here (from the last command)

Well, the time between bootloader until initrd is finished (where kernel is loading) is already 1:30 min which is quite unusual. Could be an hardware issue, or also some kind of timeout.

Would be helpful if you could add some information about your hardware and also attach full journalctl logs after a fresh boot, as root run the following command

Code: Select all: journalctl -ab > /tmp/journal.log

and then later attach /tmp/journal.log here.

OK, here it is.

doktor5000 wrote:Would be helpful if you could add some information about your hardware

There's a timeout for what seems like your swap partition for nearly 1:30 min:

Jul 04 17:24:07 localhost systemd[1]: Mounted /media/win_c.
Jul 04 17:24:09 localhost systemd[1]: systemd-rfkill.service: Succeeded.
Jul 04 17:25:30 localhost systemd[1]: dev-disk-by\x2duuid-dca4ac33\x2dfed2\x2d4400\x2db605\x2d3e2cecc6a321.device: Job dev-disk-by\x2duuid-dca4ac33\x2dfed2\x2d4400\x2db605\x2d3e2cecc6a321.device/start timed out.
Jul 04 17:25:30 localhost systemd[1]: Timed out waiting for device /dev/disk/by-uuid/dca4ac33-fed2-4400-b605-3e2cecc6a321.
Jul 04 17:25:30 localhost systemd[1]: Dependency failed for /dev/disk/by-uuid/dca4ac33-fed2-4400-b605-3e2cecc6a321.
Jul 04 17:25:30 localhost systemd[1]: Dependency failed for Swap.
Jul 04 17:25:30 localhost systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'.
Jul 04 17:25:30 localhost systemd[1]: dev-disk-by\x2duuid-dca4ac33\x2dfed2\x2d4400\x2db605\x2d3e2cecc6a321.swap: Job dev-disk-by\x2duuid-dca4ac33\x2dfed2\x2d4400\x2db605\x2d3e2cecc6a321.swap/start failed with result 'dependency'.
Jul 04 17:25:30 localhost systemd[1]: dev-disk-by\x2duuid-dca4ac33\x2dfed2\x2d4400\x2db605\x2d3e2cecc6a321.device: Job dev-disk-by\x2duuid-dca4ac33\x2dfed2\x2d4400\x2db605\x2d3e2cecc6a321.device/start failed with result 'timeout'.

Please add the output as root of

Code: Select all: lsblk -f cat /etc/fstab cat /proc/cmdline

Code: Select all: $ lsblk -f NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT sda ├─sda1 vfat BOOT 29FB-CCD0 ├─sda2 ext4 87ba21b7-672d-49e4-b70c-3c9e625b40c5 ├─sda3 swap e61037a5-06f0-4e01-9bbb-ade94352c35c └─sda4 ext4 67e275c2-5c21-4c92-9b50-df589e16b412 sdb └─sdb1 ntfs Audio E4A04058A040337A 1.7T 6% /media/win_c sdc ├─sdc1 vfat 9AB3-F2CE 69.4M 28% /boot/EFI ├─sdc2 ├─sdc3 ntfs 6446C31C46C2EE3C 891.8G 4% /media/win_c2 └─sdc4 ntfs D21C30091C2FE6E7 sdd ├─sdd1 vfat BOOT C0C2-13F9 ├─sdd2 ext4 ROOT e7bf63c6-09c4-43b8-976b-8317e8aed429 39.6G 14% / ├─sdd3 ext4 HOME 5d2652d7-a7dd-4c21-8c24-9c7b56c67486 658.4G 9% /home └─sdd4 swap SWAP 10a999da-6111-4ae3-8589-1540e97f2dc1 [SWAP] sr0

Code: Select all: $ cat /etc/fstab # Entry for /dev/sdd2 : UUID=e7bf63c6-09c4-43b8-976b-8317e8aed429 / ext4 relatime,acl 1 1 # Entry for /dev/sdc1 : UUID=9AB3-F2CE /boot/EFI vfat umask=000,iocharset=utf8 0 0 # Entry for /dev/sdd3 : UUID=5d2652d7-a7dd-4c21-8c24-9c7b56c67486 /home ext4 relatime,acl 1 2 # Entry for /dev/sdb1 : UUID=E4A04058A040337A /media/win_c ntfs-3g defaults,nofail,umask=000 0 0 # Entry for /dev/sdc3 : UUID=6446C31C46C2EE3C /media/win_c2 ntfs-3g defaults,nofail,umask=000 0 0 none /proc proc defaults 0 0 # Entry for /dev/sda3 : UUID=dca4ac33-fed2-4400-b605-3e2cecc6a321 swap swap defaults 0 0 # Entry for /dev/sdd4 : UUID=10a999da-6111-4ae3-8589-1540e97f2dc1 swap swap defaults 0 0

Code: Select all: $ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.6.14-desktop-2.mga7 root=UUID=e7bf63c6-09c4-43b8-976b-8317e8aed429 ro nokmsboot splash quiet noiswmd resume=UUID=dca4ac33-fed2-4400-b605-3e2cecc6a321 audit=0 vga=791

just wondering why do you have multiple swap partitions?

I am running a triple boot system, currently Kubuntu with Ubuntu Studio's Audio, Graphic and Photo groups installed, Mageia 7.1, and Win 10. Each operating system is on a separate hard drive. That includes separate swap partitions. I always do this, so that should a hard drive fail, the other systems will continue working without issue. I have had one HD fail on this computer and the other HDs are the same age, make and model. My strategy is based on my concern that this computer is near end of life, so I also backup everything that I create into the cloud.

That doesn't make much sense, swap partition is usually shared and does not lead to the OS failing.

The question was probably more why you have multiple swap partitions for your Mageia installation. Because the resume partition it uses is /dev/sda3 which is from another linux, it seems.
But your active swap uses /dev/sdd4 which seems to be where the rest of your Mageia install is located. That is probably the cause for the timeout.
This can be corrected, although you would need to edit /etc/fstab, you would need to edit your bootloader configuration and rebuild all initrds.
If you don't have applied much customizations, I'd say a reinstallation is quicker and easier, but you would need to pay attention to what is selected as swap partition and also for the bootloader entries for the resume= option which also uses the swap partition.

On the Yakuake auto start:
In the bottom right corner of yakuake there's a drop-down menu ->Configure Yakuake->Behavior tab -> Uncheck autostart.

AstorBG wrote:On the Yakuake auto start:
In the bottom right corner of yakuake there's a drop-down menu ->Configure Yakuake->Behavior tab -> Uncheck autostart.

Thanks for the reply. That preference has never been checked, yet it still opens at startup. I only have Yakuake setup in the system prefs to start at boot.

doktor5000 wrote:That doesn't make much sense, swap partition is usually shared and does not lead to the OS failing.

The question was probably more why you have multiple swap partitions for your Mageia installation. Because the resume partition it uses is /dev/sda3 which is from another linux, it seems.
But your active swap uses /dev/sdd4 which seems to be where the rest of your Mageia install is located. That is probably the cause for the timeout.
This can be corrected, although you would need to edit /etc/fstab, you would need to edit your bootloader configuration and rebuild all initrds.
If you don't have applied much customizations, I'd say a reinstallation is quicker and easier, but you would need to pay attention to what is selected as swap partition and also for the bootloader entries for the resume= option which also uses the swap partition.

Am I to understand that you feel the problem with the long boot up times is related to my swap configuration? The current swap configuration doesn't seem to affect Kubuntu at boot up in the slightest, so...?

as you have mentioned you install each of your systems as a complete and seperate system.

possibility:
you installed Kubuntu after you installed Mageia.
the Kubuntu ubiquity / calamares installer saw your Mageia swap and formatted it.
By doing so it caused a new UUID to be generated for that partition.

So yes, Kubuntu doesnt mind that all the swap partitions it sees are correct UUID for its initrd.

How-ever, it is likely that re-installing Mageia will change the Mageia swap UUID, especially if you format it, and then your slow boot will transfer to Kubuntu.
For this reason, the Mageia installer will only format swap partitions "on demand" from the user.

globetrotterdk wrote:Am I to understand that you feel the problem with the long boot up times is related to my swap configuration? The current swap configuration doesn't seem to affect Kubuntu at boot up in the slightest, so...?

Yes, as visible in the log excerpt I quoted above.

And that is because you installed Kubuntu first, so it can't know about the swap partition created later on by Mageia.

globetrotterdk wrote:
AstorBG wrote:On the Yakuake auto start:
In the bottom right corner of yakuake there's a drop-down menu ->Configure Yakuake->Behavior tab -> Uncheck autostart.

Thanks for the reply. That preference has never been checked, yet it still opens at startup. I only have Yakuake setup in the system prefs to start at boot.

Please, if you want to discuss the yakuake issue, create a separate thread for that.

doktor5000 wrote:Yes, as visible in the log excerpt I quoted above.

And that is because you installed Kubuntu first, so it can't know about the swap partition created later on by Mageia.

Sorry, but I installed Kubuntu last.

benmc wrote:as you have mentioned you install each of your systems as a complete and seperate system.

possibility:
you installed Kubuntu after you installed Mageia.
the Kubuntu ubiquity / calamares installer saw your Mageia swap and formatted it.
By doing so it caused a new UUID to be generated for that partition.

So yes, Kubuntu doesnt mind that all the swap partitions it sees are correct UUID for its initrd.

How-ever, it is likely that re-installing Mageia will change the Mageia swap UUID, especially if you format it, and then your slow boot will transfer to Kubuntu.
For this reason, the Mageia installer will only format swap partitions "on demand" from the user.

I specifically used the manual install option and made sure that Mageia swap was not targeted for formatting, when installing. Soo, unless the Kubuntu installer screwed up, which it admittedly sometimes does, the Mageia swap was specifically not formatted when I installed Kubuntu. Anyway, bottom line... How do I sort out the fstab so that Mageia boots properly?
----
Hmm. I dug around in the /etc/fstab file and the swap UUID matches that of the actual partition as listed in Gparted, so that isn't the problem. I have checked the other entries as well against the UUIDs from Gparted. The offending entry in the /etcfstab is /devsda3, the Kubuntu swap partition UUID. The entry should be e61037a5-06f0-4e01-9bbb-ade94352c35. I still would like to know if this is correct and I should change the Kubuntu swap UUID...
----
OK, I corrected the /etc/fstab entry (I really hate mucking around in the fstab). Boot is a little bit quicker, but not fantastic...

ok

so can we have another

Code: Select all: journalctl -ab > /tmp/journal.log

?

there may be something else in there that merits attention

Ok, cheers.

ok, so it looks like your boot up to greeter is about 30 sec. (8:36:37 to 8:37:07).
I couldnt see anything that is massively holding up your boot times, so it would likely need to turn off some services to increase the bootup time

for me it is 1 sec longer, just long enough to make a coffee.

I used to boot up this laptop every day, now I just close the lid at night and login after making my coffee in the morning.

Mageia forum

[Solved] Yakuake and Mageia startup.

[Solved] Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: Yakuake and Mageia startup.

Re: [Solved] Yakuake and Mageia startup.

Re: [Solved] Yakuake and Mageia startup.

Re: [Solved] Yakuake and Mageia startup.