OMLx 4.0 Pre-Alpha ISO Plasma development builds

Here I am able to work around the lengthy boot issue on hardware with:

# systemctl mask systemd-udev-settle.service

# systemctl disable lvm2-monitor.service

YMMV. So far I don’t see anything that this has broken.

I also did:

# systemctl disable systemd-networkd-wait-online.service

# systemctl disable fedora-loadmodules.service

Post-edit:

# systemctl disable NetworkManager-networkd-wait-online.service

# systemctl disable ModemManager.service

Now:

# systemd-analyze
Startup finished in 4.195s (firmware) + 22.782s (loader) + 1.150s (kernel) + 940ms (initrd) + 1.109s (userspace) = 30.178s
graphical.target reached after 1.099s in userspace

:grin:

Starting out after updates on 10-29 or 10-30 it was:

graphical.target reached after 3min 2.988s in userspace

Post-edit: Some of these like ModemManager.service I know I don’t need, most of us wouldn’t. Pretty sure that I don’t need lvm2-monitor.service either, but not positive.
The " -wait-online.service" ones I don’t know. I don’t know what they do, what they are for, wish I did. Maybe for computers with slower internet connections? Also I don’t know what
systemd-udev-settle.service does but disabling it has not led to any harmful effects that I can see so far. :pensive:

FWIW: This is not something I normally would do as normally OM Lx tends to boot relatively fast for a full featured operating system. I don’t get excited about services that take a few seconds or less. This was only done because of inordinately long boot times in Cooker after the recent updates. And in my case the 2 culprits taking the time were systemd-udev-settle.service and lvm2-monitor.service.

:monkey:

What version of multipath-tools do you have installed ? 0.7.7-3 ?

Found this in your logs:

Oct 31 14:28:48 ben79-pc kernel: multipath[2205]: segfault at 100 ip 00007fd8f8999a11 sp 00007ffd0da3c1f8 error 4 in libc-2.28.so[7fd8f883f000+16a000]
Oct 31 14:28:48 ben79-pc kernel: Code: 84 00 00 00 00 00 0f 1f 00 31 c0 c5 f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0 83 e1 3f 83 f9 20 77 1f <c5> fd 74 0f c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 20 83 e1 

Oct 31 14:28:58 ben79-pc lvm[535]:   WARNING: Device /dev/sdb16 not initialized in udev database even after waiting 10000000 microseconds.
Oct 31 14:29:08 ben79-pc lvm[535]:   WARNING: Device /dev/sdb17 not initialized in udev database even after waiting 10000000 microseconds.
Oct 31 14:29:19 ben79-pc lvm[535]:   WARNING: Device /dev/sda1 not initialized in udev database even after waiting 10000000 microseconds.
Oct 31 14:29:29 ben79-pc lvm[535]:   WARNING: Device /dev/sdb1 not initialized in udev database even after waiting 10000000 microseconds.
Oct 31 14:29:39 ben79-pc lvm[535]:   WARNING: Device /dev/sdb2 not initialized in udev database even after waiting 10000000 microseconds.
Oct 31 14:29:49 ben79-pc lvm[535]:   WARNING: Device /dev/sdb3 not initialized in udev database even after waiting 10000000 microseconds.
Oct 31 14:29:59 ben79-pc lvm[535]:   WARNING: Device /dev/sdb4 not initialized in udev database even after waiting 10000000 microseconds.
Oct 31 14:30:09 ben79-pc lvm[535]:   WARNING: Device /dev/sdb5 not initialized in udev database even after waiting 10000000 microseconds.
Oct 31 14:30:19 ben79-pc lvm[535]:   WARNING: Device /dev/sdb6 not initialized in udev database even after waiting 10000000 microseconds.
Oct 31 14:30:29 ben79-pc lvm[535]:   WARNING: Device /dev/sdb7 not initialized in udev database even after waiting 10000000 microseconds.
Oct 31 14:30:39 ben79-pc lvm[535]:   WARNING: Device /dev/sdb8 not initialized in udev database even after waiting 10000000 microseconds.
Oct 31 14:30:47 ben79-pc systemd[1]: systemd-udev-settle.service: Main process exited, code=exited, status=1/FAILURE
Oct 31 14:30:47 ben79-pc systemd[1]: systemd-udev-settle.service: Failed with result 'exit-code'.
Oct 31 14:30:47 ben79-pc systemd[1]: Failed to start udev Wait for Complete Device Initialization.
Oct 31 14:30:47 ben79-pc systemd[1]: Starting Device-Mapper Multipath Device Controller...
1 Like
$ rpm -qa multipath-tools
multipath-tools-0.7.7-3.x86_64

This is a system installed from ISO Build ID 2280 and updated as of yesterday. It is the system I used for the reporting above.
(I see 322 updates and 1 to install today but haven’t pulled the trigger yet.)

Post-edit: @TPG If ever there is anything for me to try about the boot delay let me know it is a simple matter to re-enable services and see what transpires. In fact since I’m a tester I kind of think it best to keep my system at normal defaults.

I’ll release new version 0.7.8 soon, hope it will fix the issue.

1 Like

And I will test it. Something else to report. Spectacle isn’t working. I believe I have a package built during mass rebuild:

$ rpm -qa spectacle
spectacle-18.08.2-2.x86_64

So far all I know is that it doesn’t open with this Konsole output:

$ spectacle
spectacle: error while loading shared libraries: libKF5PurposeWidgets.so.5: cannot open shared object file: No such file or directory

Looking like a missing library file or packages.

$ rpm -q --whatprovides libKF5PurposeWidgets.so.5
no package provides libKF5PurposeWidgets.so.5
]$ rpm -q --whatprovides libKF5PurposeWidgets.so
no package provides libKF5PurposeWidgets.so
$ rpm -q --whatprovides libKF5PurposeWidgets
no package provides libKF5PurposeWidgets

finds nothing. But I may not be doing that correctly.

Post-edit: I’ve also been tending to forget that mass rebuild may have an impact on what issues I’m seeing now. Also mass rebuild when finished maybe will correct some issues?

[bero@c64 bero]$ rpm -q --whatprovides ‘libKF5PurposeWidgets.so.5()(64bit)’
lib64KF5Purpose5-5.51.0-2.znver1
lib64KF5PurposeWidgets5-5.51.0-2.znver1

1 Like

Like a good ole Mandriva user I copy and paste:

$ rpm -q --whatprovides ‘libKF5PurposeWidgets.so.5()(64bit)’
bash: syntax error near unexpected token `('

But the dnf search finds the packages so we shall see.

So:

$ sudo dnf install lib64KF5PurposeWidgets5

fixes Spectacle so a missing package dependency. And it is very helpful to have screen shot utility working for testers!

1 Like

I’ve just fixed that

1 Like

Thanks @TPG. And thanks @bero.

Found another problem, probably a small matter for our devs including @TPG and @bero. dnf seems to think there are 2 k3b packages even though I only see one in the repo.

# dnf clean all

# dnf -v --refresh search k3b
... (Lot of output from the -v)
Completion plugin: Generating completion cache...
Searching Packages: 
======================================================================== Name Exactly Matched: k3b =========================================================================
k3b.x86_64 : CD-Burner for Plasma 5
Repo        : @System
Matched from:
Provide    : k3b = 18.08.2-2

k3b.x86_64 : CD-Burner for Plasma 5
Repo        : cooker-x86_64
Matched from:
Provide    : k3b = 18.08.2-2

======================================================================= Name & Summary Matched: k3b ========================================================================
k3b-devel.x86_64 : Development libraries from k3b
Repo        : cooker-x86_64
Matched from:
Provide    : k3b-devel = 18.08.2-2

So something is borked somewhere and it seems to be bleeping up Discover or confusing Discover or pkcon.

$ pkcon update
Getting updates               [=========================]         
Finished                      [=========================]         
Starting                      [=========================]         
Finished                      [=========================]         
Fatal error: Multiple matches of k3b;6:18.04.2-1;x86_64;cooker-x86_64

And I believe that is feeding what we users know as the Discover update applet.

Post-edit: Until this is fixed users can disable Discover updates applet in system tray if it bothers you.

And so this is what users might see:

But installed are:

Which is weird. Discover is showing an older version of k3b to update and a newer version of kipi-plugins.

# dnf update kipi-plugins
...
Last metadata expiration check: 0:13:42 ago on Thu 08 Nov 2018 12:37:50 PM CST.
Dependencies resolved.
Nothing to do.
Complete!

Post-edit: So maybe something is messed up with kipi-plugins or dnf meta data?

Post-edit: Obviously Spectacle is working now. Thanks to @TPG.

Well there were old k3b and kipi-plugins versions on 1686 repository, so i’ve removed them.
BTW @bero would be noice to remove *.i586 rpms from i686 repository

1 Like

I’ve got sound broken (after it was working) on 2 hw computers. Will start a new thread for the issue.

Post-edit: https://forum3.openmandriva.org/t/sound-has-broken-on-2-hw-cooker-computers/2216/3

Also upgrade and distro-sync are busted:

https://forum3.openmandriva.org/t/lib64lvm2cmd2-03-2-03-01-2-x86-64-conflicts-with-file-from-package-lib64lvm2cmd2-02-2-02-182-1/2215/3

So far k3b still won’t change for packagekit and discover updater.

# pkcon update
Getting updates               [=========================]         
Finished                      [=========================]         
Starting                      [=========================]         
Finished                      [=========================]         
Fatal error: Multiple matches of k3b;6:18.04.2-1;x86_64;cooker-x86_64

Discover updater also has this rather odd error message when one first opens the window. (I think it is an error message.)

Same error message from Konsole:

Note: But as you can see I’m so happy that Spectacle is working. Very useful for tester monkeys.

:monkey:

i’ve fixed this

2 Likes