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! 
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.
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,387ISO 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. 
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. 
Plasma ISO build ID 2315
Errors when updating. Log attached
konsole_05-agg.txt (34,5 KB)
I suspect related to this. Based on most of the skipped packages being perl-whatever.
This is related to perl update to 5.28.x version started by @bero. Not all perl modules were rebuild with success.
Plasma ISO build ID 2315
$ digikam
digikam: error while loading shared libraries: libsane.so.1: cannot open shared object file: No such file or directory
.
$ showfoto
showfoto: error while loading shared libraries: libsane.so.1: cannot open shared object file: No such file or directorydigikam and showfoto errors solved installing lib64sane1
.
Postedit:
And for both digikam and showfoto missing dep also: lib64x265_151
Hi.
It seems that the BUG 2381 has been fixed. Thanks to @crazy and @bero
@luca you can now test it and confirm if this working also for you, if yes, then we can say that the issue has been fixed.
How to test it:
Get latest iso 2315.
Boot as Live ISO into VirtualBox or on real hardware.
When you see black screen, switch to tty (virtual terminal) by pressing ctrl+alt+f2 or f3/f4+
Then log in as live user. User name should be “live”.
Now we need install fixed mesa (patched for gcc).
So if you have working internet connection just update all system as root:
su or sudo
dnf update
if for some reason fully update don’t want complete (small disc space or etc) then try updating only graphics stack. So all package from mesa
dnf install lib64dri* lib64EGL* lib64gbm1* lib64glapi0* lib64GLX* lib64xatracker2 etc. Of course without devel packages.
If you dont have internet connection available or can’t connect to it via command line, then we can use other solution. Start your standard operating system and go to this website ABF Build List and manually download all needed package.
In my case I needed:
lib64dri-drivers-18.3.0-0.rc4.1-omv4000.x86_64.rpm lib64dri-drivers-intel-18.3.0-0.rc4.1-omv4000.x86_64.rpm lib64dri-drivers-nouveau-18.3.0-0.rc4.1-omv4000.x86_64.rpm lib64dri-drivers-radeon-18.3.0-0.rc4.1-omv4000.x86_64.rpm lib64dri-drivers-swrast-18.3.0-0.rc4.1-omv4000.x86_64.rpm lib64dri-drivers-virtio-18.3.0-0.rc4.1-omv4000.x86_64.rpm lib64dri-drivers-vmwgfx-18.3.0-0.rc4.1-omv4000.x86_64.rpm lib64EGL_mesa0-18.3.0-0.rc4.1-omv4000.x86_64.rpm lib64gbm1-18.3.0-0.rc4.1-omv4000.x86_64.rpm lib64glapi0-18.3.0-0.rc4.1-omv4000.x86_64.rpm lib64GLX_mesa0-18.3.0-0.rc4.1-omv4000.x86_64.rpm lib64mesaopencl1-18.3.0-0.rc4.1-omv4000.x86_64.rpm lib64osmesa8-18.3.0-0.rc4.1-omv4000.x86_64.rpm lib64xatracker2-18.3.0-0.rc4.1-omv4000.x86_64.rpm mesa-18.3.0-0.rc4.1-omv4000.x86_64.rpm
Then boot cooker live ISO and again switch to tty (ctrl+alt+F2) and mount partitions where you saved the downloaded files.
for example in terminal
mkdir xyz
su
mount /dev/sda6 /home/live/xyz
(where dev/sda6 is partition where you save downloaded mesa packages, so in your case it can be sda1, sda2 etc. If you dont know check it by command fdisk -l)
If all go fine, go to mounted folder /home/live/xyz and find your mesa packages. Then install it all as root by command:
su
rpm -Uvh lib64dri* lib64mesa* lib64EGL* lib64gbm1* lib64glapi0* lib64GLX* lib64xatracker2 mesa* --nodeps
After installation we can check it.
Run in command line:
startx
For me it start in failsafe mode (two white terminal on windows). If also for you start in this crap way, they in one of this terminal run another command:
startkde
(for run plasma session on x11)
or
startplasmacompositor
(for run plasma in wayland)
If you see desktop, then all is fine. You can now test cooker in live iso mode or install it.
Just remember if you install it, after first boot you see also black screen. Then you need install this mesa packages again and after it reboot and all should be fine now for while.
This should be fixed in new ISO. Until then you have to make temporary solutions.
So if you have some free time, try this and write if it helped you.
Outstanding news. 
Let’s hope it works for @luca and other users.
There will certainly be other packages that either won’t install or work without libsane.so.1 or a replacement for it.