OMLx 4.0 Pre-Alpha ISO Plasma development builds

Plasma ISO build ID 2315
Testing in VBox virtual machines.

:+1:

Falkon working
LibreOffice working

[ruru@omlx-2315 ~]$ systemd-analyze
Startup finished in 1.256s (kernel) + 1.260s (initrd) + 5.695s (userspace) = 8.213s
graphical.target reached after 5.681s in userspace

.

[ruru@omlx-2315 ~]$ systemd-analyze blame
          3.381s systemd-udev-settle.service
          1.623s vboxadd.service
           953ms udisks2.service
           749ms ModemManager.service
           661ms polkit.service
           648ms dracut-initqueue.service
           549ms plymouth-quit.service
           537ms plymouth-quit-wait.service
           487ms NetworkManager-wait-online.service
           287ms nscd.service
           280ms iptables.service
           279ms nftables.service
           279ms systemd-logind.service
           263ms systemd-update-utmp.service
           250ms initrd-switch-root.service
           229ms packagekit.service
           221ms systemd-vconsole-setup.service
           207ms NetworkManager.service
           178ms systemd-udev-trigger.service
           138ms systemd-resolved.service
           124ms systemd-networkd-wait-online.service
           100ms systemd-udevd.service

In my opinion we may be ready for Alpha release.

@TPG @bero @ben79 @Cooker

QA, testers and users willing to help please test the latest ISO build ID 2315.
Thanks.

Same here in live mode.

@luca can you post in bug topic details of your hardware equipment (mostly CPU)?

1 Like

Done.

2 Likes

Getting ready to test ISO 2315.

Some bugs I’m aware of in addition to the Graphics/Wonderful black screen issue that @AngryPenguin and @luca have.

  1. Duplicate repos leading to error message when users update with dnf. The duplicates are i686 main and x86_64 main both are listed twice. Described here.

  2. Incorrectly named repos for non-free. There are as I recall 3 entries for nonfree instead of non-free. Described here.

  3. VirtualBox setting for “Show Toolbar” is not respected. Users has to set this again every time they open VBox. Screen-shot to come in next post.

  4. Will add/subtract to list as I test. There are more I can’t remember at the moment.

1 Like

Here is what VirtualBox (v. 5.22) looks like every time I open it in Fully updated Cooker.

This is what I want and am used to it to looking like:

Yet the setting is simply not respected or remembered by VirtualBox. I have to select ‘Show Toolbar’ every time I open VirtualBox.

This is not an issue, because we did not split cooker into 4.0 new repositories, and current repos are cooker for now.

BTW. We are looking for critical and blocker issues. Imho thes are minors. We have more important tasks for example setting mirror dispatcher for dnf. As I guess we do not want that all the users of 4.0 will use hero’s server as one and only source for dnf repositories.

Thanks a lot. Can you also show output from two command:

gcc -march=native -Q --help=target | grep march
and
gcc -march=native -Q --help=target | grep sse

I’m not talking about 4.0 repos I am talking about Cooker repos only. And there are most certainly duplicates which most certainly cause an error message in dnf is you can see in my post above. And the error is obviously and easily fixed by moving one of the duplicate files as I demonstrate in the same post.

The duplicates are:

cooker-i686.repo is the same and points to exactly same url’s as cooker-main-i686.repo.

cooker-x86_64.repo is the same and points to exactly same url’s as cooker-main-x86_64.repo.

I guarantee it! :astonished:

To get rid of the error the only way I found was to mv/rename one of the files in each case.

Adding to list in post 121.

  1. VirtualBox has incorrect error message on every start up about disk files not accessible:

The .vdi files are accessible and do boot. So as far as I know this error message is just incorrect. Further this error does not occur in Lx 3 with the very same VM’s in the list.

Here I am.

$ gcc -march=native -Q --help=target | grep march
  -march=                               westmere
$ gcc -march=native -Q --help=target | grep sse
  -mfpmath=                             sse
  -mno-sse4                             [disabled]
  -msse                                 [enabled]
  -msse2                                [enabled]
  -msse2avx                             [disabled]
  -msse3                                [enabled]
  -msse4                                [enabled]
  -msse4.1                              [enabled]
  -msse4.2                              [enabled]
  -msse4a                               [disabled]
  -msse5                      
  -msseregparm                          [disabled]
  -mssse3                               [enabled]
  Known assembler dialects (for use with the -masm= option):
    387 387+sse 387,sse both sse sse+387 sse,387
1 Like

ISO Build ID 2315 VirtualBox installation. Hardware testing will happen soon I hope as well.

I would be remiss if I did not acknowledge that there have been many bugs fixed as of this ISO so thanks to all or our hard working developers.

Host system is fully updated Cooker with VBox 5.22. I set memory to 4GB and disk size to 20GB.

Booting to ‘Live’ takes about 2 minutes.

The weirdest thing of all to me is that if I use ‘Erase disk’ for partitioning it wants to set a / of 11.2GB and swap of 8.5GB? I’m told the gargantuan swap partition has to do with hibernation and how much memory users selects to use for VM? I wish there was a better solution for this, really I do. But as it is I don’t use hibernate and am not doing 8.5GB swap partitions so I used ‘Manual Partitioning’. I set a 18.7GB / and a 1GB swap instead.

System installs without error.

First boot in to installed system took 1 minute and 33 seconds. Note: I am measuring actual boot time from Grub2 menu until sddm login screen first appears with a stop watch (without any tricks). In my experience systemd-analyze is not measuring actual boot time and is only useful for tracing actual systemd problems. I am trying to measure what users actually will experience not something that may be hypothetical. For instance this is what systemd-analyze reports for this 1 min. 33 sec. boot:

$ systemd-analyze
Startup finished in 993ms (kernel) + 993ms (initrd) + 4.000s (userspace) = 5.987s
graphical.target reached after 3.991s in userspace

So something takes an additional 1 min. and 27 sec. to boot beyond what systemd is doing in this instance. Post-edit: Also during boot Plymouth screen shows briefly like a second or less then I see a black screen until what ever decides to show sddm login screen. Also for perspective a Lx 3 VM with same settings on same host machine boots in about 20-25 seconds which I consider to be normal. So a minute and half is excessive without a doubt. Post-edit-again: If I boot and keep pressing the ESC key on kbd system boots in a normal 20-25 seconds. So what the bleep is causing this if I or user doesn’t do some kbd trick???

All that being said the ISO boots, installs, and works apparently normally except for booting time.

An issue I don’t believe I’ve noted before in this thread:
User can not edit current profile in Konsole, this is different behavior than I have seen previously as in Lx 3 for instance. If it is not intentional then this is a bug. If this is intentional then this is stupid but easy to work around.

Expected behavior is that user should be able to make changes to Konsole profile without becoming root or changing permissions. In other words expected behavior is to have this work like it always has. If I ever find out if this change in behavior is intentional or not I’ll know whether to file a bug report on this. If anyone knows please illuminate me.

So far I have filed these bug reports against Cooker repos (these are issues mentioned earlier in this thread):

Repository cooker-x86_64 is listed more than once in the configuration

Repos incorrectly named with incorrect URL’s

Lx 4 repo enabled in Cooker installation.

These bug reports are in the interest of making Lx 4 as professional and polished as we are capable. None are major and so far none affect usability, all are easy to work around. But the other side of the coin is that all would be super easy to fix so why not do so?

There are other bugs for instance some with VirtualBox mentioned earlier in this thread. I’ll endeavor to document these as I go with testing.

Post-edit: Lets get some logs in here since I have reported some issues;

journalctl-b.txt (71.8 KB)

dmesg.txt (45.3 KB)

Host machine hardware inxi -F:

inxi-F.txt (1.9 KB)

And may I be the first to wish you all a Merry Christmas and a Happy New Year and Happy Holidays or all of those. :christmas_tree:

:speak_no_evil::hear_no_evil::see_no_evil:

Post-edit: Fixed by @Colin. Thanks @Colin.

Another issue.

I was going to post omv-bug-report.log from the above VM but that is busted too now:

omv-bug-report.sh.txt (11.1 KB)

Post-edit: omv-bug-report.sh busted to smithereens! (That means it is broken.)

Check GitHub - OpenMandrivaAssociation/openmandriva-repos: OpenMandriva package repository files for DNF and PackageKit. There are no duplicates.
First run rpm -qf yum.repos.d/*

After sddm starts, there are other stuff that is executed. I see in logs that “packagekitd” is executed on Plasma start. On ISO we should disable it as it makes no sense to run it.

Nov 20 21:11:29 ben79-pc dbus-daemon[583]: [system] Activating via systemd: service name='org.freedesktop.PackageKit' unit='packagekit.service' requested by ':1.54' (uid=1001 pid=956 comm="/usr/bin/plasmashell ")
Nov 20 21:11:29 ben79-pc systemd[1]: Starting PackageKit Daemon...

Then what is producing these error messages? What I am talking about is what is on the actual 2315 ISO and on any system installed from that not what is in Github.

# dnf --refresh upgrade
Repository cooker-i686 is listed more than once in the configuration
Repository cooker-i686-debuginfo is listed more than once in the configuration
Repository cooker-testing-i686 is listed more than once in the configuration
Repository cooker-testing-i686-debuginfo is listed more than once in the configuration
Repository cooker-updates-i686 is listed more than once in the configuration
Repository cooker-updates-i686-debuginfo is listed more than once in the configuration
Repository cooker-testing-x86_64 is listed more than once in the configuration
Repository cooker-testing-x86_64-debuginfo is listed more than once in the configuration
Repository cooker-updates-x86_64 is listed more than once in the configuration
Repository cooker-updates-x86_64-debuginfo is listed more than once in the configuration
Repository cooker-x86_64 is listed more than once in the configuration
Repository cooker-x86_64-debuginfo is listed more than once in the configuration

Hint: Something, somewhere, is listed twice, and I know what that is. What makes the files duplicates is not that the name of the file is exactly the same, they aren’t. What makes the files duplicates is because what is inside the files, including the url’s, is exactly the same. Look inside the files cooker-i686.repo and cooker-main-i686.repo and every url is the same. Look inside the files cooker-x86_64.repo and cooker-main-x86_64.repo and every url is the same. And I challenge you to rename say cooker-main-i686.repo to cooker-main-i686.repo.bak and cooker-main-x86_64.repo to cooker-main-x86_64.repo.bak and see if all those error messages listed above do not go away. You do need to be sure that the remaining repos cooker-i686.repo and cooker-x86_64.repo are enabled.

# rpm -qf /etc/yum.repos.d/*
openmandriva-repos-cooker-4.0-0.0.8.x86_64
openmandriva-repos-cooker-4.0-0.0.8.x86_64
file /etc/yum.repos.d/cooker-contrib-x86_64.repo.rpmnew is not owned by any package
openmandriva-repos-cooker-4.0-0.0.8.x86_64
openmandriva-repos-cooker-4.0-0.0.8.x86_64
file /etc/yum.repos.d/cooker-main-i686.repo is not owned by any package
file /etc/yum.repos.d/cooker-main-x86_64.repo is not owned by any package
openmandriva-repos-cooker-4.0-0.0.8.x86_64
file /etc/yum.repos.d/cooker-non-free-x86_64.repo is not owned by any package
openmandriva-repos-cooker-4.0-0.0.8.x86_64
openmandriva-repos-cooker-4.0-0.0.8.x86_64
openmandriva-repos-cooker-4.0-0.0.8.x86_64
openmandriva-repos-cooker-4.0-0.0.8.x86_64
file /etc/yum.repos.d/cooker-restricted-x86_64.repo.rpmnew is not owned by any package
openmandriva-repos-cooker-4.0-0.0.8.x86_64
openmandriva-repos-cooker-4.0-0.0.8.x86_64
openmandriva-repos-cooker-4.0-0.0.8.x86_64
openmandriva-repos-4.0-0.0.8.x86_64
openmandriva-repos-4.0-0.0.8.x86_64
openmandriva-repos-4.0-0.0.8.x86_64
openmandriva-repos-4.0-0.0.8.x86_64
openmandriva-repos-4.0-0.0.8.x86_64
openmandriva-repos-4.0-0.0.8.x86_64
openmandriva-repos-4.0-0.0.8.x86_64
openmandriva-repos-4.0-0.0.8.x86_64
openmandriva-repos-4.0-0.0.8.x86_64
openmandriva-repos-4.0-0.0.8.x86_64
openmandriva-repos-4.0-0.0.8.x86_64
openmandriva-repos-4.0-0.0.8.x86_64

Post-edit: This is very easy to reproduce. Just run or install ISO 2315 in VBox or on hardware and then open Konsole, become root, and run ‘dnf --refresh upgrade’. You will see these error messages.

Reported: Issues · OpenMandrivaAssociation/distribution · GitHub

Yes, and thanks for fixing @TPG.

These bugs were discussed in TC-Meeting and are being looked at with an eye to fixing scripts to make things more better, logical, ect. for users.
Note: None of these are a major issue, the only consequence of these is unnecessary error messages, there is no harm or loss of function for user. Users may feel free to ignore these or do what ever work around you choose until devs are done working there magic on these. So don’t worry be happy. :monkey:

Plasma ISO build ID 2315
Errors when updating. Log attached

konsole_05-agg.txt (34,5 KB)

1 Like