[Solved] Yakuake and Mageia startup.

[globetrotterdk]

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.

[doktor5000]

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)

[globetrotterdk]

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.

[doktor5000]

Code: Select all

systemd-analyze plot > boot.svg

Didn't return anything

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

[globetrotterdk]

Doh.

[doktor5000]

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.

[globetrotterdk]

OK, here it is.

[doktor5000]

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

[doktor5000]

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

[globetrotterdk]

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

[benmc]

just wondering why do you have multiple swap partitions?

[globetrotterdk]

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.

[doktor5000]

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.

[AstorBG]

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

[globetrotterdk]

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.

[globetrotterdk]

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...?

[benmc]

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.

[doktor5000]

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.

[doktor5000]

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.

[globetrotterdk]

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.

[globetrotterdk]

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...

[benmc]

ok

so can we have another

Code: Select all

journalctl -ab > /tmp/journal.log

?

there may be something else in there that merits attention

[globetrotterdk]

Ok, cheers.

[benmc]

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.