Thanks for the report TJ. I am surprised someone else has not hit this sooner.

Assignee: bugsquad => pkg-bugs
CC: (none) => mageia

It could be hardware-dependent; my card is low-end for the 580-series nvidia-current.

Those few times when I use a Live system I never use the proprietary drivers. I don't believe there's any advantage to them for the things I do, so it's not worth waiting for them to build. It may be the same with others.

Nothing I can do to investigate this, my only NVIDIA card has long since been unsupported by the proprietary driver.

Hi 

I don't get these kind of problems with a more recent nVidia card :

NVIDIA GeForce GT 1030/PCIe/SSE2

(the processor is :  6 × Intel® Core™ i5-9400F CPU @ 2.90GHz)

But there are other bugs with the proprietary drivers
https://bugs.mageia.org/show_bug.cgi?id=35008
https://bugs.mageia.org/show_bug.cgi?id=35009
https://bugs.mageia.org/show_bug.cgi?id=35010

CC: (none) => philippedidier

It's not the card. (yet)

The Quadro K620 is a Maxwell card, and works fine with nvidia-current 580 series driver in Cauldron, as long as I boot the Live iso without the nvidia drivers, install on the hard drive, then use MCC to switch to nvidia-current.

There is something different in the way the driver modules are built in the Live iso and what is done with MCC.

No change with the 10beta1 Live isos.

(In reply to Thomas Andrews from comment #5)
> It's not the card. (yet)
> 
> The Quadro K620 is a Maxwell card, and works fine with nvidia-current 580
> series driver in Cauldron, as long as I boot the Live iso without the nvidia
> drivers, install on the hard drive, then use MCC to switch to nvidia-current.
> 
> There is something different in the way the driver modules are built in the
> Live iso and what is done with MCC.

I confirm that's there is something wrong with the way the Live iso uses the built nvidia drivers.
When I have been able to stop the booted Live iso, and rebooted it with the already built nvidia drivers (the USB pendrive has a persistent partition) I get no more display problems.

This is not a plasma problem but a strictly Live iso problem

Can you test adding "nouveau.modeset=0" to the boot command line as suggested by Giuseppe.

CC: (none) => ghibomgx

Seem related: Bug 35008, Bug 35009

CC: (none) => fri
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=35008, https://bugs.mageia.org/show_bug.cgi?id=35009

(In reply to Martin Whitaker from comment #8)
> Can you test adding "nouveau.modeset=0" to the boot command line as
> suggested by Giuseppe.

Just using the Live Plasma as it is(no persistence on the usb stick), and editing the boot command line from the grub menu to replace "nokmsboot" with nouveau.modeset=0" doesn't seem to make any significant difference.

BTW, the computer with the nvidia GPU uses rEFInd as the bootloader.

(In reply to Thomas Andrews from comment #10)

> (In reply to Martin Whitaker from comment #8)
> > Can you test adding "nouveau.modeset=0" to the boot command line as
> > suggested by Giuseppe.
> 
> Just using the Live Plasma as it is(no persistence on the usb stick), and
> editing the boot command line from the grub menu to replace "nokmsboot" with
> nouveau.modeset=0" doesn't seem to make any significant difference.
> 
> BTW, the computer with the nvidia GPU uses rEFInd as the bootloader.

You have to choose the "nonfree" menu before. Booting from the Live Plasma from refind menu shouldn't make difference. What should happen is that the x11-driver-video-nvidia-current is installed on the fly (and dkms-nvidia-current) too.

After that (after some time to build the kernel modules) it starts in graphics mode with the nvidia driver. Note that there could be some further error from drakdm which returns an error (that was due to wayland but it's another problem, now should be fixed in current task-plasma) and stops the login. In that case just switch to a terminal with ctrl-alt-f3, login, type rpm -e sddm-wayland-plasma --nodeps; killall sddm, and it will continue with the normal login.

(In reply to Giuseppe Ghibò from comment #11)
> 
> You have to choose the "nonfree" menu before. Booting from the Live Plasma
> from refind menu shouldn't make difference. What should happen is that the
> x11-driver-video-nvidia-current is installed on the fly (and
> dkms-nvidia-current) too.
> 
Yes, I did that. It's difficult to know what was happening - the screen was black part of the time, text other parts, with bits of text showing now and then. There was no recognizable message like "building nvidia driver" or "installing nvidia driver" which is what I would expect to see. VERY unprofessional-looking, but then this isn't an RC yet.
 
> After that (after some time to build the kernel modules) it starts in
> graphics mode with the nvidia driver. Note that there could be some further
> error from drakdm which returns an error (that was due to wayland but it's
> another problem, now should be fixed in current task-plasma) and stops the
> login. In that case just switch to a terminal with ctrl-alt-f3, login, type
> rpm -e sddm-wayland-plasma --nodeps; killall sddm, and it will continue with
> the normal login.

Mageia Welcome comes up, then after a few seconds I see a login, followed by Mageia Welcome again. But not a normal page. It's too big for the screen, for one thing, and only partially responsive. No way to close it, either.

But that's not what I should see at that point. Before the login, I should have a series of questions to answer, location, EULA, time/date, keyboard layout, stuff like that. I never see any of that unless I boot using nouveau.

I assume the lack of a splash screen (and the building/installing) messages is caused by adding the "nouveau.modeset=0" option (your initial report says boot appears to go normally). That would be because plymouth requires a working kernel graphics driver, and if you disable nouveau, it won't have one until the proprietary driver has been built and installed.

This is just reinforcing my opinion that we should drop the NVIDIA proprietary drivers from the Live ISOs.

(In reply to Philippe Didier from comment #7)
> (In reply to Thomas Andrews from comment #5)
> > It's not the card. (yet)
> > 
> > The Quadro K620 is a Maxwell card, and works fine with nvidia-current 580
> > series driver in Cauldron, as long as I boot the Live iso without the nvidia
> > drivers, install on the hard drive, then use MCC to switch to nvidia-current.
> > 
> > There is something different in the way the driver modules are built in the
> > Live iso and what is done with MCC.
> 
> I confirm that's there is something wrong with the way the Live iso uses the
> built nvidia drivers.
> When I have been able to stop the booted Live iso, and rebooted it with the
> already built nvidia drivers (the USB pendrive has a persistent partition) I
> get no more display problems.
> 
> This is not a plasma problem but a strictly Live iso problem

I must soften what I said there
The display problem of plasma is indeed linked to plasma itself inside Live Alpha1 with nvidia drivers 
https://bugs.mageia.org/show_bug.cgi?id=35008
https://bugs.mageia.org/show_bug.cgi?id=35009
it seems to be caused by the default configuration of plasma provided inside the Live Iso : 
modifying this configuration during this first session allows the second boot to work correctly

(In reply to Martin Whitaker from comment #13)

> 
> This is just reinforcing my opinion that we should drop the NVIDIA
> proprietary drivers from the Live ISOs.

In the past I have always used Live Plasma Iso with nvidia drivers to test the new versions of Mageia before installing them...
The Live Isos worked well (Mageia7 Mageia8 Mageia9) 
(it was nevertheless tricky to change the display from spread over 2 monitors into a secondary monitor cloned from the primary)

The built nvidia drivers work perfectly after the second boot...
This seems to be a problem for the Live Iso to use correctly these built drivers at the first boot

The real problem I have encountered is that this first boot is very very long, and that clicking on Live mode inside MageiaWelcome lets think that the program is stuck
(long time before Plasma effectively starts : this might need something to inform that something is working in the background)

I can't debug these problems. My only NVIDIA hardware is long since unsupported by the proprietary drivers, and is retired from active use. These days I choose to buy hardware from manufacturers who properly support open source software.

If the proprietary drivers only work properly after a reboot, then the sensible thing is to remove the option to install them on first boot. And in that case I would rather remove the packages from the ISO to reduce the ISO size and let users download and install them if they want to.

I recognise that first use with Plasma on Live alpha with proprietary nvidia (nvidia470) was very slow. I rebooted and then it was OK.

(In reply to Martin Whitaker from comment #16)
> I would rather remove the packages from the ISO to reduce the ISO
> size and let users download and install them if they want to.

Sounds good to me.

(In reply to Morgan Leijström from comment #18)
> (In reply to Martin Whitaker from comment #16)
> > I would rather remove the packages from the ISO to reduce the ISO
> > size and let users download and install them if they want to.
> 
> Sounds good to me.

This is the wrong thing to do(In reply to Thomas Andrews from comment #12)
> (In reply to Giuseppe Ghibò from comment #11)
> > 
> > You have to choose the "nonfree" menu before. Booting from the Live Plasma
> > from refind menu shouldn't make difference. What should happen is that the
> > x11-driver-video-nvidia-current is installed on the fly (and
> > dkms-nvidia-current) too.
> > 
> Yes, I did that. It's difficult to know what was happening - the screen was
> black part of the time, text other parts, with bits of text showing now and
> then. There was no recognizable message like "building nvidia driver" or
> "installing nvidia driver" which is what I would expect to see. VERY
> unprofessional-looking, but then this isn't an RC yet.
>  
> > After that (after some time to build the kernel modules) it starts in
> > graphics mode with the nvidia driver. Note that there could be some further
> > error from drakdm which returns an error (that was due to wayland but it's
> > another problem, now should be fixed in current task-plasma) and stops the
> > login. In that case just switch to a terminal with ctrl-alt-f3, login, type
> > rpm -e sddm-wayland-plasma --nodeps; killall sddm, and it will continue with
> > the normal login.
> 
> Mageia Welcome comes up, then after a few seconds I see a login, followed by
> Mageia Welcome again. But not a normal page. It's too big for the screen,
> for one thing, and only partially responsive. No way to close it, either.
> 
> But that's not what I should see at that point. Before the login, I should
> have a series of questions to answer, location, EULA, time/date, keyboard
> layout, stuff like that. I never see any of that unless I boot using nouveau.

This appears to be a combination of issues, and isn't specifically related to the nvidia drivers, it might be a problem with the graphics card itself or grub. For your information, I'm experiencing the black screen and long timeout even when booting with the free drivers (using Ventoy in both normal and GRUB modes), so it's not an nvidia specific problem. The long timeout (almost over 3 minutes and more) with the black screen occurs before the kernel even starts, you can see this because once the kernel starts, it displays timing starting from 0.1, 0.2 seconds, and this before any modules are built on the fly. You can press ESC to bypass the splash screen.

The further inconsistency you see with the EULA screen, etc., is due to SDDM starting in native Wayland mode in Beta 1. This should be resolved in the next builds. That's why you should enter in console, forcing removing the package and kill the sddm process.

As I mentioned, nvidia and nouveau can't coexist at boot. If nouveau starts and resizes the screen, the it's loaded, and any subsequent nvidia modules can't be loaded anymore because of concurrent access to the same device.
That's why nouveau needs to be disabled during boot. The only way to avoid this would be to preload the nvidia drivers in the initramfs image, but this is only possible for the -open modules, due to the license, and those modules supports only Turing cards and beyond. Also this would require providing an extra alternative built initramfs (beside stock one) containing that modules, and an extra entry in the grub menu.

To get the progress logs, plymouth can be disabled using the following kernel parameters:

rd.plymouth=0 plymouth.enable=0 vga=normal nouveau.modeset=0 nosplash noquiet

which you can use to boot with the non-free entry, instead of just nouveau.modeset=0.

I think we can use them too for the non-free grub line. With these parameters, after 3 minutes or more (that's the a"normal" duration of black screen I got before the kernel is loaded) you'll see the kernel starting with timing from 0.1-0.2 seconds, and then the required modules will be built with the visible verbosity.

"The further inconsistency you see with the EULA screen, etc., is due to SDDM starting in native Wayland mode in Beta 1. This should be resolved in the next builds. That's why you should enter in console, forcing removing the package and kill the sddm process."

But that doesn't explain why the  Live Xfce also skips the EULA, etc after building the nvidia drivers, but not if nouveau is used. It goes straight to the desktop.

Hi
I am still testing Alpha1 Plasma Iso with Nvidia proprietary drivers, trying to investigate several bugs I have found

For each test I create a new USB pendrive with persistent partition

I have had a big surprise with the first boot during a new attempt :
https://bugs.mageia.org/show_bug.cgi?id=35008#c11

Everything has worked perfectly ending with a clean Plasma session !!!

This makes me think that the order of the different steps might have changed for this attempt (particularly concerning the way the two monitors are used : spread screen over the 2 or clone of the second from the primary)

This leads me to think that it is neither a nvivia drivers problem nor a KDE Plasma problem but that concerns more specifically the way Live Iso itself launches successively its programs... or the way xorg.conf is created, or the choice between X11 or wayland

Nota Bene
In the past with Mageia8 or Mageia9 Live iso the detection and the use of 2 monitors was aleatory (sometimes screen spread, sometimes monitor cloned, sometimes only one monitor detected)

(In reply to Philippe Didier from comment #21)
> For each test I create a new USB pendrive with persistent partition

   Some variables comes to mind:
§ If different pendrive, the speed can matter if the issue is timing dependant
§ same if booted on different machine, or same machine with another port of a another speed
§ the randomness of parallell initialisation completing in possibly other order due to hardware interaction: network, monitors...?
§ If updated persistence: updated packages; other version
§ urpmi etc may in some cases randomly select one or another alternative dependency



/ Sidenote: if same ISO and stick, you can clean the persistence by simply deleting the folders in that partition while it is not booted on.
= quicker and less wear than rewriting the ISO. /

Hi Morgan

To use a correct protocol and be sure not introducing any bias in the tests I did :
I used each time the same USB pendrive
I used each time Isodumper from Mageia9 to create a fresh Live Alpha1 Plasma iso (with persistent partition) on this pendrive
I used always the same computer with the same devices plugged in
I used always the same USB port
I always choose to boot with Nvidia proprietary drivers
The first boot seems not to bring any update unless I ask for it in the MCC

Apparently, it's only when I quit Plasma that the persistent partition is filled with the modifications that remains inside the writeable memory of the computer : this allows the second boot with this pendrive to start quickly with the already built Nvidia drivers and the modifications applied to the configurations of Plasma. 

For this test I talk about here in comment 21 (referring to https://bugs.mageia.org/show_bug.cgi?id=35008#c11)
there was no change at all and the surprise was that everything went well at the first boot (with an empty persistent partition) unlike the several tests I did before... long time to build and install Nvidia modules as always, but correct display with for the first time the HDMI TV being a clone of the primary monitor instead of a screen spread over the two devices.

In my previous tests I only once tried to unplug my HDMI TV but the result was bad : Mageia Welcome filling the whole screen with no frame for its window and having launched Live Mode no way to quit any program (MCC or "Plasma Settings") their window was filling the screen without title bar and no way to quit them

As I said there's no worst bug than an bug that appears randomly

I forgot to say in comment 21 and comment23 that when the Live Plasma Iso Alpha1 worked correctly with Nvidia drivers at the first boot, the Mageia Welcome window appeared in the middle of the screen, with its frame allowing to close it...
In all other tests Mageia Welcome filled totally the screen and its window had no frame.

I wait to have access to Beta before doing other tests

(In reply to Philippe Didier from comment #23)
> no way to quit any program 

Does not even Alt-F4 work?

Can you use Alt-F2 to launch programs, for example konsole?


> As I said there's no worst bug than an bug that appears randomly

Yes, we need to see what happned.
Next time it happens, please grab a system log from boot until current time:

You can press Ctrl-Alt-F4 to fullscreen terminal and log in as root, enter 
  journalctl -b > somesuitablefilename.txt
and when booted OK to desktop attach that file to this bug.

Optionally compress it first, by the command
  xz somesuitablefilename.txt
 


(In reply to Philippe Didier from comment #25)
> I wait to have access to Beta before doing other tests

Join QA-list https://ml.mageia.org/l/info/qa-discuss,
Present yourself there and tell you want to be a QA ISO tester.
If you do not have edit rights to the wiki, ask for that.

Add yourself to bottom of this list:
https://wiki.mageia.org/en/QA_ISO_testers

Then our QA leader can send you credentials for accessing the ISOs

Read
https://wiki.mageia.org/en/Pre-release_ISO_testing#Joining_Up_.26_Participating

I have just added myself to the list of QA ISO testers inside the wiki

Since there have been lots of updates after Alpha1 was built I think it's better and more useful to test Beta now ...

(In reply to Philippe Didier from comment #27)
> I have just added myself to the list of QA ISO testers inside the wiki
> 
> Since there have been lots of updates after Alpha1 was built I think it's
> better and more useful to test Beta now ...

Please be patient. Our sysadmins have scheduled installation of some new server hardware this weekend, and as a consequence there may be some disruption in services until that is finished. I wouldn't want you to be in the middle of syncing/downloading the beta1 test isos while that's going on. I will send the credentials when I see the OK from the sysadmins.

Thanks
I already saw this information about new server hardware from Bruno Cornec on the dev mailing list

I will be patient ;o)

(In reply to Thomas Andrews from comment #28)
> (In reply to Philippe Didier from comment #27)
> > I have just added myself to the list of QA ISO testers inside the wiki
> > 
> > Since there have been lots of updates after Alpha1 was built I think it's
> > better and more useful to test Beta now ...
> 
> Please be patient. Our sysadmins have scheduled installation of some new
> server hardware this weekend, and as a consequence there may be some
> disruption in services until that is finished. I wouldn't want you to be in
> the middle of syncing/downloading the beta1 test isos while that's going on.
> I will send the credentials when I see the OK from the sysadmins.

I think you can give the grren light Thomas, as nothing will happen till monday anyway. And I do not plan to touch the existing servers such as duvel and suck which host the core infra. So please go !

CC: (none) => bruno

Thanks for the clarification, Bruno.

@Philippe: Email sent. Please be aware that with regard to this particular issue, little changed between the alpha1 and beta1 versions of the isos. Different kernel, different nvidia-current would be the biggest things, but on my hardware the result is the same if I boot using the nvidia driver.

@Thomas
Iso downloaded installed on USB stick with IsoDumper (which is complaining of a missing gpg key : this key doesn't exist inside the list of files downloaded)

I will test it tomorrow

The .gpg files are not generated until official testing.

Not normally a Gnome user, but I finally tried the beta1 Live Gnome this morning. It acts like the Xfce Live, appearing to boot normally, building and installing the nvidia-current driver, but then dumps the user onto the desktop. No questions about language, EULA, etc, so it is an English desktop. A non-English speaker is out of luck.

Booting without nvidia-current, I was able to specify another language, in my case Spanish, because I somehow remember enough of my high school Spanish to know it when I see it. Once I specified another language things operated in that language from then on, as is supposed to happen.

So, while the Plasma Live shows the most serious symptoms, ALL of the Lives are affected by this bug to some degree.

TJ, as you can get to a reasonably functional desktop with the Xfce or GNOME Lives, could you capture the system log by (as root)

  journalctl -b | xz > journal.log.xz

and attach it here, so I can look to see why the questions are being skipped but the DE starts. Either Xfce or GNOME will do.

Also could you try adding the full set of boot command line options Giuseppe has proposed:

  nouveau.modeset=0 rd.plymouth=0 plymouth.enable=0 vga=normal

to see if that works on your hardware.

You could instead try

  rd.driver.blacklist=nouveau modprobe.blacklist=nouveau

which should guarantee the nouveau driver isn't used.

Created attachment 15410 [details]
journal from Live Xfce boot with nvidia drivers

Created attachment 15411 [details]
Journal of Live Gnome boot with nvidia-current

One of each, so you can compare. BTW, the first time I booted Gnome Live today, plymouth worked normally. It dropped into text mode on subsequent boots with both Gnome and Xfce. At least I think that's it. Little boxes instead of the infamous three question marks, but it looks similar.

Which DE did you want me to try with those command line options? Or does it matter?

Thanks. I'll take a look later when my eyes have recovered from staring at a computer screen all day.

Try the Plasma Live with those options, as it's the most troublesome one.

Doesn't seem to make much difference either way. Giuseppe's options make for a neater-looking boot, but that's just because plymouth was shut off.

With both it eventually boots to a desktop with an overlarge Mageia Welcome in the background, and every minute or so it switches to the login screen. 

Lather, rinse, repeat.

There's more wrong here than simple interference from nouveau.

(In reply to Thomas Andrews from comment #40)

> Doesn't seem to make much difference either way. Giuseppe's options make for
> a neater-looking boot, but that's just because plymouth was shut off.
> 
> With both it eventually boots to a desktop with an overlarge Mageia Welcome
> in the background, and every minute or so it switches to the login screen. 
> 
> Lather, rinse, repeat.
> 
> There's more wrong here than simple interference from nouveau.

I think there are other problems with that, other than driver itself. Let's see  tomorrow wiht a local build.

First thing to note is that the nouveau driver is not being loaded, so can't be the source of the problems. Looking into this, that's because /usr/lib/udev/rules.d/80-drivers.rules checks for nokmsboot.

I also see these errors:

service_harddrake[738]: unknown line 341 (DRIVER2_NEEDS_OPEN_KERNEL_MODULES)

which seem to come from a new setting Giuseppe has added to /usr/share/ldetect-lst/Cards+. I don't think that's causing any problems, but needs to be fixed.

The major problem is that the X server is crashing the first time it is started, with an assertion failure in libglamoregl.so (called from the modesetting DDX driver). That's what stops the language, etc. questions being asked. But it would appear the X server can be started by LightDM.

GNOME is using Wayland, so it's less surprising that that works when startx dpesn't.

(In reply to Martin Whitaker from comment #42)
> First thing to note is that the nouveau driver is not being loaded, so can't
> be the source of the problems. Looking into this, that's because
> /usr/lib/udev/rules.d/80-drivers.rules checks for nokmsboot.

So, it's still used in the custom udev rules, though not on kernel anymore, then we can still keep it.

> 
> I also see these errors:
> 
> service_harddrake[738]: unknown line 341 (DRIVER2_NEEDS_OPEN_KERNEL_MODULES)

I added this to support newer open modules (it required a second part in drakx11, not committed) which is why you see that warning. However, it's now removed (fixed in updates_testing), so you won't see it anymore, because I implemented the same functionality in a simpler way. Anyway was already present in alpha1, and and you noticed was not causing any problem.

> 
> which seem to come from a new setting Giuseppe has added to
> /usr/share/ldetect-lst/Cards+. I don't think that's causing any problems,
> but needs to be fixed.
> 
> The major problem is that the X server is crashing the first time it is
> started, with an assertion failure in libglamoregl.so (called from the
> modesetting DDX driver). That's what stops the language, etc. questions
> being asked. But it would appear the X server can be started by LightDM.

Interesting find, looking deeper when I complete the ISO build.

I wonder if it's a potential race condition: the EULA may be starting before Xorg (or SDDM) has fully initialized (I'm referring to the version already fixed without sddm-wayland-plasma).

I wonder if this bug, apart the wayland problems with sddm-wayland-plasma, it's not the same or related to this: https://bugs.mageia.org/show_bug.cgi?id=34942, which hit intel when i915 it's not preloaded on initramfs, but just for another module/chipset (in this case nvidia).

In fact we see there, it could be due to a udev/systemd delay in the dev node creation (e.g. https://github.com/systemd/systemd/issues/25408) which hit the system when the module is not preloaded in the initramfs.

In the draklive-config's file/dracut-live.conf we have the entry:

add_drivers+=" amdgpu radeon nouveau i915 vboxvideo "

which means that amdgpu, radeon, nouveau, i915 and vboxvideo, are preloaded (and ready) in the initramfs, but as you can see nvidia-current it's not. But also it could affect all the chipset/modules that are not amdgpu, radeon, nouveau, i915 and vboxvideo. Mostly our tests are within these chipset cards.

(In reply to Giuseppe Ghibò from comment #44)
> I wonder if this bug, apart the wayland problems with sddm-wayland-plasma,
> it's not the same or related to this:
> https://bugs.mageia.org/show_bug.cgi?id=34942, which hit intel when i915
> it's not preloaded on initramfs, but just for another module/chipset (in
> this case nvidia).
> 
> In fact we see there, it could be due to a udev/systemd delay in the dev
> node creation (e.g. https://github.com/systemd/systemd/issues/25408) which
> hit the system when the module is not preloaded in the initramfs.

If it was, we would see the error message

  (EE) open /dev/dri/card0: No such file or directory

The error message we do see shows it has got beyond that.

It could be a race condition within the same family, not necessarily with that DRI error, because aborts before.

I was trying to get more debug info, but I hit another bug: 
https://bugs.mageia.org/show_bug.cgi?id=35131

Anyway, I was finally able to build two ISOs for Plasma with different flags/config combinations. They're nearly 5 GB each, and it seems to 
go beyond the initial problem. Is there a place I could upload them for a quick test?

(In reply to Giuseppe Ghibò from comment #46)
> Anyway, I was finally able to build two ISOs for Plasma with different
> flags/config combinations. They're nearly 5 GB each, and it seems to 
> go beyond the initial problem. Is there a place I could upload them for a
> quick test?

You should be able to log into rabbit (you have a home directory on that machine). What groups are you in?

P.S. Maybe best to discuss the details by private email

(In reply to Martin Whitaker from comment #47)
> (In reply to Giuseppe Ghibò from comment #46)
> > Anyway, I was finally able to build two ISOs for Plasma with different
> > flags/config combinations. They're nearly 5 GB each, and it seems to 
> > go beyond the initial problem. Is there a place I could upload them for a
> > quick test?
> 
> You should be able to log into rabbit (you have a home directory on that
> machine). What groups are you in?

I was able to log to rabbit. Which dir to use?

Giuseppe's ISOs are now available to test. They can be downloaded using mageiasync or dorsync from the usual pre-release rsync server. They can be found in the directory "nvidia-test". Giuseppe wrote:

----

There are 4 subdirectories:

Mageia-10-beta0-Live-Plasma-x86_64/
Mageia-10-beta0a-Live-Plasma-x86_64/
Mageia-10-beta0b-Live-Plasma-x86_64/
Mageia-10-beta0c-Live-Plasma-x86_64/

to be copied to /home/bcd/public_html/isos/nvidia-test/. I also tested the md5sum on the rabbit destination, to ensure they were correctly uploaded.

To minimize the downloads for testers, the ones to test for now are:

- Mageia-10-beta0c-Live-Plasma-x86_64/, which should work with nvidia proprietary and nouveau.

- Mageia-10-beta0b-Live-Plasma-x86_64/, this might show some problem after the EULA, but not as in beta1. 

----

To minimise the download time, if you do one at a time you can use the usual trick of copying and renaming the directories and files so that rsync only has to transfer the differences. The beta1 Live Plasma ISO should make a reasonable starting point for this.

Thank you, both - you do plenty, each!
Nice to see you Giuseppe now makes ISO too :-)

Should this also be announced on QA-list, or we only try them out for this specific bug first?

These ISOs are only for testing fixes for the nvidia bugs.

(In reply to Morgan Leijström from comment #51)

> Thank you, both - you do plenty, each!
> Nice to see you Giuseppe now makes ISO too :-)
> 

Only once...

> Should this also be announced on QA-list, or we only try them out for this
> specific bug first?

This is only for this bug with nvidia. And they are called beta0, so to not mix with a "newer" set.

You might use also some facilities to speed up testing, e.g. you may run "glmark", "vkmark" (vulkan), glxspheres.

Checksum failed for beta0b in Mageiasync. Tried downloading two ways, syncing with a renamed beta1 and a straight download. Both failed.

The beta0c checksum is OK.

(In reply to Thomas Andrews from comment #54)

> Checksum failed for beta0b in Mageiasync. Tried downloading two ways,
> syncing with a renamed beta1 and a straight download. Both failed.
> 
> The beta0c checksum is OK.

Strange, I rechecked the local beta0b, checksum with md5sum, sha512sum and sha3-512sum and both 3 were resulted verified. File size should be 5149018112.

File size is OK. Mageiasync only checks the sha3-512 sum these days. I haven't checked the others yet.

Dorsync says md5, SHA3, and SHA512 are all OK. Unknown what the problem is with Mageiasync.

(In reply to Martin Whitaker from comment #50)
> Giuseppe's ISOs are now available to test. They can be downloaded using
> mageiasync or dorsync from the usual pre-release rsync server. They can be
> found in the directory "nvidia-test". Giuseppe wrote:
> 
> ----
> 
> There are 4 subdirectories:
> 
> Mageia-10-beta0-Live-Plasma-x86_64/
> Mageia-10-beta0a-Live-Plasma-x86_64/
> Mageia-10-beta0b-Live-Plasma-x86_64/
> Mageia-10-beta0c-Live-Plasma-x86_64/
> 
> to be copied to /home/bcd/public_html/isos/nvidia-test/. I also tested the
> md5sum on the rabbit destination, to ensure they were correctly uploaded.
> 
> To minimize the downloads for testers, the ones to test for now are:
> 
> - Mageia-10-beta0c-Live-Plasma-x86_64/, which should work with nvidia
> proprietary and nouveau.
> 
> - Mageia-10-beta0b-Live-Plasma-x86_64/, this might show some problem after
> the EULA, but not as in beta1. 
> 
Hi Giuseppe
I have just tested Mageia-10-beta0c-Live-Plasma-x86_64 booting with Nvidia driver

It starts better : 
on a black background a text displays hash signs and all the steps being done :
installing rpms ; building nvidia driver, installing nvidia driver

Then I can choose language, accept licence, choose time setting, keyboard setting
OK
Then the Mageia Welcome covers the two screens (the second being a clone of the primary

Clicking on Live mode launches Plasma (slow launch)

The screen is now spread over the 2 monitors
Using Plasma Settings I can modify this to have the second monitor as a clone of the primary

But now I come back to the problems I got with Alpha1 :
- No frame (no title bar) for the window of Plasma settings and no way to quit it
- I can use the MCC to detect and use my printer (HP)  I can verify too that the hplip-gui is installed ... but hplip-gui can't be used (explanation later)
- with the MCC I can explore the devices but sometimes this is stuck on a category : the mouse being unresponsive
- The Mageia Menu displays the categories of programs but clicking on a category doesn't show the list of existing programs (reason why I can't launch HPLIP-gui or LibreOffice or anything)

- Clicking on Mageia Menu power off button leads to a grey screen but doesn't stop the system

Ctrl+alt+Del leads to a screen showing the choice (hibernate stop disconnect etc)
clicking on the stop button doesn't do anything except leading to a grey screen
Ctrl+alt+Del leads to the previous step

The magical buttons (alt + print screen ) doesn't allow to use RSEIUB

I need to physically power off the computer

To conclude :
Beta0c starts correctly like Alpha1 did until Plasma is launched
But Plasma works as badly as in Alpha1

no way to quit Plasma system settings like in this Alpha1 bug
https://bugs.mageia.org/show_bug.cgi?id=35008

No way to Power off like in this Alpha1 bug
https://bugs.mageia.org/show_bug.cgi?id=35010

Post scriptum 
in this bug 
https://bugs.mageia.org/show_bug.cgi?id=35107
I had tested Beta1 and provided logs and system journal

(In reply to Philippe Didier from comment #58)

> (In reply to Martin Whitaker from comment #50)
> > Giuseppe's ISOs are now available to test. They can be downloaded using
> > mageiasync or dorsync from the usual pre-release rsync server. They can be
> > found in the directory "nvidia-test". Giuseppe wrote:
> > 
> > ----
> > 
> > There are 4 subdirectories:
> > 
> > Mageia-10-beta0-Live-Plasma-x86_64/
> > Mageia-10-beta0a-Live-Plasma-x86_64/
> > Mageia-10-beta0b-Live-Plasma-x86_64/
> > Mageia-10-beta0c-Live-Plasma-x86_64/
> > 
> > to be copied to /home/bcd/public_html/isos/nvidia-test/. I also tested the
> > md5sum on the rabbit destination, to ensure they were correctly uploaded.
> > 
> > To minimize the downloads for testers, the ones to test for now are:
> > 
> > - Mageia-10-beta0c-Live-Plasma-x86_64/, which should work with nvidia
> > proprietary and nouveau.
> > 
> > - Mageia-10-beta0b-Live-Plasma-x86_64/, this might show some problem after
> > the EULA, but not as in beta1. 
> > 
> Hi Giuseppe
> I have just tested Mageia-10-beta0c-Live-Plasma-x86_64 booting with Nvidia
> driver
> 
> It starts better : 
> on a black background a text displays hash signs and all the steps being
> done :
> installing rpms ; building nvidia driver, installing nvidia driver
> 
> Then I can choose language, accept licence, choose time setting, keyboard
> setting
> OK
> Then the Mageia Welcome covers the two screens (the second being a clone of
> the primary
> 
> Clicking on Live mode launches Plasma (slow launch)
> 
> The screen is now spread over the 2 monitors

which video card?

> Using Plasma Settings I can modify this to have the second monitor as a
> clone of the primary

Isn't already a clone of the primary, as that should be the effect of the line "xclone=1" on the grub booting cmdline.

> 
> But now I come back to the problems I got with Alpha1 :
> - No frame (no title bar) for the window of Plasma settings and no way to
> quit it
> - I can use the MCC to detect and use my printer (HP)  I can verify too that
> the hplip-gui is installed ... but hplip-gui can't be used (explanation
> later)
> - with the MCC I can explore the devices but sometimes this is stuck on a
> category : the mouse being unresponsive
> - The Mageia Menu displays the categories of programs but clicking on a
> category doesn't show the list of existing programs (reason why I can't
> launch HPLIP-gui or LibreOffice or anything)
> 
> - Clicking on Mageia Menu power off button leads to a grey screen but
> doesn't stop the system

Did you get the Plasma mageia icon in the toolbar, where you can just select "logout", then you can re-login?

> 
> Ctrl+alt+Del leads to a screen showing the choice (hibernate stop disconnect
> etc)
> clicking on the stop button doesn't do anything except leading to a grey
> screen
> Ctrl+alt+Del leads to the previous step
> 
> The magical buttons (alt + print screen ) doesn't allow to use RSEIUB

RSEIUB is disabled, see bug: https://bugs.mageia.org/show_bug.cgi?id=35116

you can enable using

echo 1 > /proc/sys/kernel/sysrq

(In reply to Philippe Didier from comment #58)

> The screen is now spread over the 2 monitors
> Using Plasma Settings I can modify this to have the second monitor as a
> clone of the primary

If you start with just one monitor plugged instead of two, did you get the same problems ?

Hi Giuseppe

>which video card?
NVIDIA GeForce GT 1030/PCIe/SSE2 (Nvidia GeForce 745 and later)

> Isn't already a clone of the primary, as that should be the effect of the line "xclone=1" on the grub booting cmdline.

The second monitor is a clone until Mageia Welcome (after the choices of language time etc...) 
But
When I have clicked on "Live Mode", Plasma starts and the screen is spread on the 2 monitors

>> - Clicking on Mageia Menu power off button leads to a grey screen but
>> doesn't stop the system
> Did you get the Plasma mageia icon in the toolbar, where you can just select "logout", then you can re-login?
No: I get a grey screen and I get stuck on it

Ctrl+alt+Del leads to a black background with 5 buttons (hibernate, stop, start again, disconnect...) clicking on each of them leads to a grey screen

> If you start with just one monitor plugged instead of two, did you get the same problems ?
I will test again with the second monitor unplugged...

My hardware is listed in comment 0, except for the single monitor, an Acer R240HY.

I tried the beta0c, first with the nouveau driver. Everything seemed to work normally, including plymouth.

The first issue with the proprietary drivers was that plymouth went into text mode, resulting in the now-familiar confused text display. (Booting with "splash quiet" removed was much more professional-looking, but of course it was all text.) 

Giving it a chance, nvidia-current was built and installed, and after a while the language, EULA, etc questions came up the way they should, and at the end a fully-functional, normal-looking Plasma desktop came up. Since this machine uses an Ethernet connection, the Internet came up with no action needed on my part. Mageia Welcome was normal-sized, and functional. I played a quick game of Tux Racer, watched a couple of Youtube videos in Firefox, looked at the Double Commander file manager(?), used the desktop context menu to bring up the logout screen, and shut down normally.

If you could fix that issue with plymouth, it would be OK on this hardware.

About having the second monitor unplugged I already tested this for Alpha1 that didn't resolve the problem
https://bugs.mageia.org/show_bug.cgi?id=35008#c13

One strange thing is that during all the Alpha1 tests all went well once here is an extract of https://bugs.mageia.org/show_bug.cgi?id=35008#c11 :

>I can't understand why the Live Plasma Alpha1 had a different behaviour :
>I have used Isodumper to create a new USB pendrive (erasing the previously created  iso )
>I have booted again with this USB pendrive
>All went well this time !!!
>No problem with window decoration (I can close them)!
>Mageia welcome is in a window in the middle of the screen and can be closed when Live mode has been launched. The menu is correctly apparent... 
>The only difference is that now my hdmi TV is a clone of the primary monitor when Plasma appears with a correct background and a working taskbar...
>Nota Bene :
>During the previous tests the screen was always spread over the two monitors and that apparently caused the several problems I encountered.

I need to correct this sentence
"One strange thing is that during all the Alpha1 tests all went well once" 
to be clearer I meant 
One strange thing is that during all the ten Alpha1 tests I did, only one time everything went well with the two monitors plugged

The beta0c is DEFINITELY better than the beta0b on my hardware. About the only difference between the way the beta0b works and the beta1 is that with beta0b I do get the language, etc questions. The rest, the oversized Mageia Welcome, the lack of a way to logout/shutdown, all the same.

Created attachment 15415 [details]
hardware list

If this may help I attach the hardware list

Hi
Test Mageia-10-beta0c-Live-Plasma-x86_64 booting with Nvidia driver with only monitor

It starts the same way : 
on a black background a text displays hash signs and all the steps being done :
installing rpms ; building nvidia driver, installing nvidia driver

Then I can choose language, accept licence, choose time setting, keyboard setting
OK
Then the Mageia Welcome covers the whole screen of the monitor

Clicking on Live mode launches Plasma (slow launch)

But now I come back to the problems I got with Alpha1 :
- No frame (no title bar) for the window of Plasma settings and no way to quit it
- I can use the MCC to detect and use my printer (HP)  I can verify too that the hplip-gui is installed ... but hplip-gui can't be used (explanation later)
- with the MCC I can explore the devices but sometimes this is stuck on a category : the mouse being unresponsive
- The Mageia Menu displays the categories of programs but clicking on a category doesn't show the list of existing programs (reason why I can't launch HPLIP-gui or LibreOffice or anything)

- Clicking on Mageia Menu power off button leads to a grey screen but doesn't stop the system

Ctrl+alt+Del leads to a screen showing the choice (hibernate stop disconnect etc)
clicking on the stop button doesn't do anything except leading to a grey screen
Ctrl+alt+Del leads to the previous step

I always need to power off manually the computer

(In reply to Thomas Andrews from comment #64)

> My hardware is listed in comment 0, except for the single monitor, an Acer
> R240HY.
> 
> I tried the beta0c, first with the nouveau driver. Everything seemed to work
> normally, including plymouth.
> 
> The first issue with the proprietary drivers was that plymouth went into
> text mode, resulting in the now-familiar confused text display. (Booting
> with "splash quiet" removed was much more professional-looking, but of
> course it was all text.) 
> 
> Giving it a chance, nvidia-current was built and installed, and after a
> while the language, EULA, etc questions came up the way they should, and at
> the end a fully-functional, normal-looking Plasma desktop came up. Since
> this machine uses an Ethernet connection, the Internet came up with no
> action needed on my part. Mageia Welcome was normal-sized, and functional. I
> played a quick game of Tux Racer, watched a couple of Youtube videos in
> Firefox, looked at the Double Commander file manager(?), used the desktop
> context menu to bring up the logout screen, and shut down normally.

So, the nvidia works now. 

Do glmark2, vkmark and glxspheres run correctly ?

The non‑free boot was deliberately configured with vga=normal so that you can see the debug logs in case of problems. You might try editing the boot entry (pressing 'e' at GRUB) and removing vga=normal, allowing the default (and previous) vga=788 to be used instead, and then see how it behaves.

Another step to try is this: while in the Plasma desktop, click the Mageia icon in the bottom‑left corner, choose "Power/Session => "Log Out". At the next login, then select Plasma "(Wayland)" and also try the other desktop environments (IceWM, Weston, Openbox).

> 
> If you could fix that issue with plymouth, it would be OK on this hardware.

(In reply to Philippe Didier from comment #69)

> Hi
> Test Mageia-10-beta0c-Live-Plasma-x86_64 booting with Nvidia driver with
> only monitor
> 
> It starts the same way : 
> on a black background a text displays hash signs and all the steps being
> done :
> installing rpms ; building nvidia driver, installing nvidia driver
> 
> Then I can choose language, accept licence, choose time setting, keyboard
> setting
> OK
> Then the Mageia Welcome covers the whole screen of the monitor
> 
> Clicking on Live mode launches Plasma (slow launch)
> 
> But now I come back to the problems I got with Alpha1 :
> - No frame (no title bar) for the window of Plasma settings and no way to
> quit it

Can you logout from the panel icon? Otherwise open a new terminal (with CTRL+Alt+T) and type "qdbus-qt6 org.kde.Shutdown /Shutdown logout" to logout, then re-login again as "Plasma(x11)" and see whether you get the missed frames for the windows.

> 
> - Clicking on Mageia Menu power off button leads to a grey screen but
> doesn't stop the system
> 
> Ctrl+alt+Del leads to a screen showing the choice (hibernate stop disconnect
> etc)
> clicking on the stop button doesn't do anything except leading to a grey
> screen
> Ctrl+alt+Del leads to the previous step

suspend works? e.g. systemctl suspend ?

Several problems
1)
I can't quit Plasma Settings (no title bar = no file menu and so quit item and no X cross to close its window)
The panel icon doesn't show the title of the used program allowing to close its window (this title disappears immediately when Plasma Settings has been launched) :
I will attach the normal display of the panel icon in Mageia9 when Plasma Settings is launched and a example with Mageia9 of what it looks like in Mageia10


2)
CTRL+Alt+T opens a terminal but it appears filling the screen with no frame and no way to quit it


>Do glmark2, vkmark and glxspheres run correctly ?
glmark = OK
glxspheres = OK 60 frames/second
vlmark = can't work

3)
> Can you logout from the panel icon? 
NO

4) 
>Otherwise open a new terminal (with CTRL+Alt+T) and type "qdbus-qt6 org.kde.Shutdown /Shutdown logout" to logout, then re-login again as "Plasma(x11)" and see whether you get the missed frames for the windows.
I tried this but the screen remains filled by the Konsole and Plasma is not displayed
It is always the problem of windows filling the screen with no frame and title bar
(the reason why Mageia Welcome appears with no frame and fills the screen)

5)
CTRL+Alt+Del always leads to a black background with 5 choices : hibernate; power off; start again; disconnect; cancel
Clicking on each of them leads to a grey screen and nothing happens
then CTRL+Alt+Del leads again to the same choices
It's a infernal loop
I need to manually power off the computer

TO CONCLUDE : 
There seems to be a problem for Plasma itself (it's not strictly a Nvidia driver problem) maybe the use of wayland instead of X11

Besides this
6) Booting from a fresh USB pendrive takes 20 minutes before Plasma starts 
During this boot I get a black background with white text for each step (installing rpms; building nvidia driver; installing nvidia driver takes 15 minutes)


7) I tried to burn the iso on a DVD but 4,8 Go is too much for the capacity of the DVD


I will compare this behaviour with the one of my previous Mageia9 Live Plasma DVD

Created attachment 15416 [details]
normal panel inside Mageia9

Panel inside Mageia9 when Plasma Settings is launched :
The title of this program appears and can be used to quit

Created attachment 15417 [details]
an example from Mageia9 of what looks the panel inside Mageia10

I can't show the panel of Mageia10...
This is an example from Mageia9 with a panel without the title of a launched program
as it looks inside Mageia10 
(Naturally to catch this inside Mageia9 , Plasma Settings was not launched)

Post Scriptum
I will try too to boot the Mageia10 USB pendrive using what has been stored in the persistent partition

(In reply to Philippe Didier from comment #72)

> 
> >Do glmark2, vkmark and glxspheres run correctly ?
> glmark = OK
> glxspheres = OK 60 frames/second
> vlmark = can't work

those 60 fps are sync to vblank/monitor frame rate, to get the full max speed you have you use:

vblank_mode=0 __GL_SYNC_TO_VBLANK=0 <yourcommandbench>


> 
> 5)
> CTRL+Alt+Del always leads to a black background with 5 choices : hibernate;
> power off; start again; disconnect; cancel
> Clicking on each of them leads to a grey screen and nothing happens
> then CTRL+Alt+Del leads again to the same choices
> It's a infernal loop
> I need to manually power off the computer

I wonder if it's not due to having just to few memory. How much RAM do you have in your system?

> 
> 7) I tried to burn the iso on a DVD but 4,8 Go is too much for the capacity
> of the DVD

Use only from pendrive. This is known, it's not fitting on a DVD SL.

I couldn't boot with the USBpendrive using the persistent partition...

I used again Isodumper to create again Mageia10 Beta0c Live Plasma...

Unbelievable :
Booting with the nvidia driver was as long as before (black background with white text until the access to windows allowing the choose of language , accept licence and all the others)

but now the display of Plasma is perfect :

MageiaWelcome appears in a window in the middle of the screen and this window has a frame (it doesn't fill the screen anymore)

Plasma functions correctly : a launched program appears in a correctly framed  window and its title appears in the bottom panel allowing to quit from here !

The menu can be used (clicking on a category shows all the programs available and to launch them)

The stop button in the menu allows to power off

This bug appears randomly !!!!

What would help to debug now this has worked ???
I can use what has been stored in tne persistent partition but is it useful ?

There seems to be something changing randomly the order of the steps of the boot leading to Plasma ...
or maybe the choice of wayland or X11 ?

> I wonder if it's not due to having just to few memory. How much RAM do you have in your system?
16 Go Ram
I have provided my hardware list attached here https://bugs.mageia.org/attachment.cgi?id=15415

Post Scriptum
Of course I can't have anymore access to the content of the persistent partition of the USB pendrive which induced the bug... it has been erased to create the working USB pendrive

Nota Bene :
The same erratic bug appeared with Alpha1

(In reply to Philippe Didier from comment #77)

> I couldn't boot with the USBpendrive using the persistent partition...
> 
> I used again Isodumper to create again Mageia10 Beta0c Live Plasma...
> 
> Unbelievable :
> Booting with the nvidia driver was as long as before (black background with
> white text until the access to windows allowing the choose of language ,
> accept licence and all the others)
> 
> but now the display of Plasma is perfect :
> 
> MageiaWelcome appears in a window in the middle of the screen and this
> window has a frame (it doesn't fill the screen anymore)
> 
> Plasma functions correctly : a launched program appears in a correctly
> framed  window and its title appears in the bottom panel allowing to quit
> from here !
> 
> The menu can be used (clicking on a category shows all the programs
> available and to launch them)
> 
> The stop button in the menu allows to power off

So it seems working correctly now.

> 
> This bug appears randomly !!!!
> 
> What would help to debug now this has worked ???
> I can use what has been stored in tne persistent partition but is it useful ?
> 
> There seems to be something changing randomly the order of the steps of the
> boot leading to Plasma ...
> or maybe the choice of wayland or X11 ?

The current startup in beta0c should start always with X11. As tests, once you can logout from Plasma, you can try the other desktops available in sddm, including Plasma(Wayland), which should work as expected.

(In reply to Philippe Didier from comment #77)
> I couldn't boot with the USBpendrive using the persistent partition...
> 
> I used again Isodumper to create again Mageia10 Beta0c Live Plasma...
> 
> Unbelievable :
> Booting with the nvidia driver was as long as before (black background with
> white text until the access to windows allowing the choose of language ,
> accept licence and all the others)
> 
> but now the display of Plasma is perfect :
> 
> MageiaWelcome appears in a window in the middle of the screen and this
> window has a frame (it doesn't fill the screen anymore)
> 
> Plasma functions correctly : a launched program appears in a correctly
> framed  window and its title appears in the bottom panel allowing to quit
> from here !
> 
>
The description of what you saw with your first beta0c test reminded me of what I saw with the beta0b iso. I didn't say anything because I believed it was probably the differences in our hardware. But now, this test agrees with what I'm seeing with the beta0c iso. 

So now I have to ask: Is it possible that, believing you were creating a beta0c pen drive for that first test you accidentally actually created a beta0b pen drive?

Hi Thomas
> So now I have to ask: Is it possible that, believing you were creating a beta0c pen drive for that first test you accidentally actually created a beta0b pen drive?

There couldn't be any confusion for me since I have only downloaded Beta0c iso...

(In reply to Giuseppe Ghibò from comment #70)
> 
> So, the nvidia works now. 
> 
> Do glmark2, vkmark and glxspheres run correctly ?
> 
Only have time to try glmark2 right now, and it worked just fine. Gave me a score of 5151, respectable for this I think.

(In reply to Giuseppe Ghibò from comment #80)
> (In reply to Philippe Didier from comment #77)
> 
> > I couldn't boot with the USBpendrive using the persistent partition...
> > 
> > I used again Isodumper to create again Mageia10 Beta0c Live Plasma...
> > 
> > Unbelievable :
> > Booting with the nvidia driver was as long as before (black background with
> > white text until the access to windows allowing the choose of language ,
> > accept licence and all the others)
> > 
> > but now the display of Plasma is perfect :
> > 
> > MageiaWelcome appears in a window in the middle of the screen and this
> > window has a frame (it doesn't fill the screen anymore)
> > 
> > Plasma functions correctly : a launched program appears in a correctly
> > framed  window and its title appears in the bottom panel allowing to quit
> > from here !
> > 
> > The menu can be used (clicking on a category shows all the programs
> > available and to launch them)
> > 
> > The stop button in the menu allows to power off
> 
> So it seems working correctly now.
> 

What is surprising is that it works correctly this time... and only this time !  

Before this I have tested Beta0c Plasma ISO several times in the same conditions :
- freshly created USB pendrive using isodumper (with a fresh persistent partition)
- asking to boot with nvidia driver
The previous tests ended badly as explained 

> > 
> > This bug appears randomly !!!!
> > 
> > What would help to debug now this has worked ???
> > I can use what has been stored in tne persistent partition but is it useful ?
> > 
> > There seems to be something changing randomly the order of the steps of the
> > boot leading to Plasma ...
> > or maybe the choice of wayland or X11 ?
> 
> The current startup in beta0c should start always with X11. As tests, once
> you can logout from Plasma, you can try the other desktops available in
> sddm, including Plasma(Wayland), which should work as expected.

Do you mean that I can boot with the key which succeeded this last time ? (it will use the content of the persistent partition and starts faster since the driver is already built)

Created attachment 15418 [details]
bootlog of the Live Beta0c which worked correctly

bootlog of the Live Beta0c of the only time when it worked correctly

Created attachment 15419 [details]
xorg.conf of the Live Beta0c which worked correctly

xorg.conf of the Live Beta0c from the only time it worked correctly

Created attachment 15420 [details]
Xorg.0.log of the Live Beta0c which worked correctly

Xorg.0.log of the Live Beta0c from the only time it worked correctly

Created attachment 15421 [details]
compressed system.journal of the Beta0c working correctly

compressed system.journal of the Beta0c from the only time when it worked correctly

Before using again the pendrive which worked I have attached what may be useful, copied from the persistent partition and having made them readable by anybody

Hope this will help to understand why it worked this time

(unfortunately this will not help to understand why it did not work correctly during the other tests)

Hi Giuseppe

>The current startup in beta0c should start always with X11. As tests, once you can logout from Plasma, you can try the other desktops available in sddm, including Plasma(Wayland), which should work as expected.

I have used this "working" pendrive to test this : 
Fast boot (using what is stored in the persistent partition)
Plasma correctly displayed : 
- Mageia menu usable (lists of programs displayed)
- windows of programs having their frame (I can quit them)
- title of the program appearing in the bottom panel (besides the permanent icons) allowing to quit from here too

I have disconnected from Plasma and the sddm provided the choice :
 I have chosen Plasma Wayland
no problem
 I disconnected and went back to Plasma X11
no problem

When I click on the power off button from the Mageia menu the computer stops when I confirm (without waiting 30 seconds)

Since I had tested it with only one monitor I have plugged my HDMI TV : a window appears immediately and propose to clone the TV from the primary monitor : that works (in spite of a bad frequency : 60.5 instead of 60 easily corrected with Plasma Settings)

To conclude this worst kind of inconstant bug
It's an aporia : I can't understand why the Beta0c Live Plasma with nvidia driver has worked correctly this time and failed during all the previous tests

The nvidia problem of Beta1 seems to be corrected by Beta0c for the boot part (building and installing nvidia driver), including the correct display of the windows allowing to choose language, accept licence, choose time reference, choose keyboard model, 

But Beta0c generally fails (and rarely succeeds) to display correctly Mageia Welcome and then  Plasma itself.

This last problem appeared already with Alpha1... 
https://bugs.mageia.org/show_bug.cgi?id=35008
https://bugs.mageia.org/show_bug.cgi?id=35009
https://bugs.mageia.org/show_bug.cgi?id=35010
Does it deserve to open a new bug for Beta0c ?

There seems to be, after the correct basic start, a randomly change in the order of the steps leading to Plasma : most of the times it ends with an incorrect display, but rarely it ends correctly :
for me it succeeded for only one test (the last one) among eight in strictly same conditions (same freshly created pendrive, same computer, same plugged devices )

There is a new subdir with 'Mageia-10-beta0e-Live-Plasma-x86_64/' to be downloaded from the same repo. You might try that too. It has a newer kernel 6.18.10-1.mga10.

(In reply to Thomas Andrews from comment #64)

> If you could fix that issue with plymouth, it would be OK on this hardware.

Try whether the version beta0e has this working better.

(In reply to Philippe Didier from comment #91)

> The nvidia problem of Beta1 seems to be corrected by Beta0c for the boot
> part (building and installing nvidia driver), including the correct display
> of the windows allowing to choose language, accept licence, choose time
> reference, choose keyboard model, 
> 
> But Beta0c generally fails (and rarely succeeds) to display correctly Mageia
> Welcome and then  Plasma itself.
> 
> This last problem appeared already with Alpha1... 
> https://bugs.mageia.org/show_bug.cgi?id=35008
> https://bugs.mageia.org/show_bug.cgi?id=35009
> https://bugs.mageia.org/show_bug.cgi?id=35010
> Does it deserve to open a new bug for Beta0c ?
> 
> There seems to be, after the correct basic start, a randomly change in the
> order of the steps leading to Plasma : most of the times it ends with an
> incorrect display, but rarely it ends correctly :
> for me it succeeded for only one test (the last one) among eight in strictly
> same conditions (same freshly created pendrive, same computer, same plugged
> devices )

For now do not report on other bugs referring to "beta0c" outside this bug. Keep them for the next global ISO round eventually.

For the attempts, keep also track during whether the list of modules inserted by the system changes across various attempts (use lsmod |sort > files_attempt_nrXXX.txt and then cp somewhere).

(In reply to Philippe Didier from comment #84)

> Before this I have tested Beta0c Plasma ISO several times in the same
> conditions :
> - freshly created USB pendrive using isodumper (with a fresh persistent
> partition)

can you quickly see also whether using isodumper (launching from the live itself which has it) can create (of course not on the same USB pendrive but another) another ISO with the persistent partition enabled, so you don't have to boot from another installation.

Hi
I have just tested Beta0e Plasma with nvidia drivers
No change :
Same behaviour as Beta0c
Everything goes well until the choices ares done (little window for language, licence, time and keyboard)
BUT 
Then MageiaWelcome fills the screen, with no frame
Then when LiveMode has been chosen Plasma doesn't work well :
Mageia Menu only shows the categories of programs but the list of programs is not displayed
No way to quit

Same behaviour as in https://bugs.mageia.org/show_bug.cgi?id=35020#c69

>can you quickly see also whether using isodumper (launching from the live itself which has it) can create (of course not on the same USB pendrive but another) another ISO with the persistent partition enabled, so you don't have to boot from another installation.

No access to any program inside plasma with the launched Beta0e

(In reply to Philippe Didier from comment #97)
> >can you quickly see also whether using isodumper (launching from the live itself which has it) can create (of course not on the same USB pendrive but another) another ISO with the persistent partition enabled, so you don't have to boot from another installation.
> 
> No access to any program inside plasma with the launched Beta0e

Can you open a terminal (ctrl-alt-t) to type something?

So the cold boot of any series shows problems? What is the output of:

uname -r
lsmod | sort 

And if you do a "killall sddm" from the terminal?

Created attachment 15423 [details]
lsmod sorted from the last attempt

Result of lsmod sorted
From a new test of Beta0e (using a new freshly created USB pendrive)

Hi Giuseppe 
I did a new test with a new freshly created USB pendrive
uname : 6.8.10-desktop-1.mga10

the result of lsmod has just been attached

(In reply to Philippe Didier from comment #100)
> Hi Giuseppe 
> I did a new test with a new freshly created USB pendrive
> uname : 6.8.10-desktop-1.mga10
> 
> the result of lsmod has just been attached

from the list, modules seems correctly loaded. What if you open a terminal and remove the "mageiawelcome" package and kill sddm, typing:

urpme mageiawelcome
killall sddm

?

(In reply to Giuseppe Ghibò from comment #93)
> (In reply to Thomas Andrews from comment #64)
> 
> > If you could fix that issue with plymouth, it would be OK on this hardware.
> 
> Try whether the version beta0e has this working better.

No difference. Plymouth still drops into text mode before it starts to build the nvidia modules. Martin and I fought this battle before with an earlier Mageia - I don't remember which one, or what was finally done to fix it, but I do remember it was a frustrating experience.

I grabbed a journal of this last boot. Perhaps it will give a clue of what's going on.

Once the boot is finished, Plasma in Live mode works perfectly, just as it does for me, every time, with beta0c. This time I ran Libreoffice Calc, Dolphin, and VLC, all with no issues.

Created attachment 15424 [details]
journal of a boot with beta0e iso

(In reply to Thomas Andrews from comment #102)
> (In reply to Giuseppe Ghibò from comment #93)
> > (In reply to Thomas Andrews from comment #64)
> > 
> > > If you could fix that issue with plymouth, it would be OK on this hardware.
> > 
> > Try whether the version beta0e has this working better.
> 
> No difference. Plymouth still drops into text mode before it starts to build
> the nvidia modules. Martin and I fought this battle before with an earlier
> Mageia - I don't remember which one, or what was finally done to fix it, but
> I do remember it was a frustrating experience.
> 

Probably it is something that requires some fixes in plymouth itselves, that also we recently upgraded to release 24.

> I grabbed a journal of this last boot. Perhaps it will give a clue of what's
> going on.
> 
> Once the boot is finished, Plasma in Live mode works perfectly, just as it
> does for me, every time, with beta0c. This time I ran Libreoffice Calc,
> Dolphin, and VLC, all with no issues.

So it seems stable.

(In reply to Thomas Andrews from comment #102)
> No difference. Plymouth still drops into text mode before it starts to build
> the nvidia modules. Martin and I fought this battle before with an earlier
> Mageia - I don't remember which one, or what was finally done to fix it, but
> I do remember it was a frustrating experience.

I patched plymouth to recognise nokmsboot on the boot command line and force it to use the frame buffer device for display. But that patch got discarded when plymouth was updated in late December. I do wish the packagers would stop updating packages just because a new version is available. I've already spent over a day finding and fixing another regression caused by that plymouth update.

(In reply to Thomas Andrews from comment #102)
> 
> Once the boot is finished, Plasma in Live mode works perfectly, just as it
> does for me, every time, with beta0c. This time I ran Libreoffice Calc,
> Dolphin, and VLC, all with no issues.

You are lucky !
Several tests with Beta0c or Beta0e ended for me with Plasma not working correctly... 
comment #69
comment #96

Same as the problems I encountered with Alpha1
https://bugs.mageia.org/show_bug.cgi?id=35008
https://bugs.mageia.org/show_bug.cgi?id=35009
https://bugs.mageia.org/show_bug.cgi?id=35010

Only once I got Plasma working correctly without having modified anything in the test context
comment #77

Different hardware, and not just the GPU. 

Your motherboard/processor is a couple of generations newer than mine, for one thing, so it probably has different EFI firmware. For another, your list says you have 16GB of RAM, where I have 48GB. No doubt there are others.

If the problem is a race condition, those things can make all the difference.

One other thing: So far, I have been testing usb sticks created without persistence. That way, every time I boot is like the first time, and there are fewer variables in the mix. Once we have the Live Plasma booting as it should without persistence, we can introduce that variable and see what happens.

When troubleshooting, I always try to remember KISS: "Keep It Simple, Stupid."

Priority: Normal => High

Hi Thomas

2 points :
- About hardware (EFI and memory) I have the same hardware that I used for Mageia8 Mageia9...
When I had used Mageia9 Live Plasma DVD final release before installing Mageia9 it worked without any problem.

I have just did today a test with this DVD : it works always perfectly !

- using USB sticks without persistence don't allow to keep anywhere journal;  system.journal; xorg.log; boot.log; xorg.conf 
It's only when I opened (as root user) the persistent partition in my Mageia9 system 
that I could make this files readable by anybody and could attach them here


If the problems I have encountered for Plasma itself are caused by the fact that I have "only" 16Go memory (when it's widely enough for an installed Mageia system)...
 That means that the Live Iso might let think that Mageia10 can't work on my system!

Live ISO is supposed to demonstrate that Mageia10 can be used on the computer on which it is tested : a rarely obtained success is a bit daunting for a beginner.
(I am patient and unrelenting to try to debug : 8 tests before a success !)
I am quite sure now that the problem is linked to the order of the steps leading to launch MageiaWelcome and Plasma after the Nvidia driver is installed and used...

This problem of order of the steps appeared already for Alpha1 leading to Plasma problems that I reported 

Beta0 worked badly since the beginning (no choice of language licence time reference etc)
Beta0c and Beta0e have corrected this problem and work well now (without Plymouth and only a text displayed) until launching MageiaWelcome and Plasma that randomly run often  into troubles and rarely succeed.

What would be useful to find what changes in the order of the steps lead to a success or a failure ?

(In reply to Philippe Didier from comment #110)
> This problem of order of the steps appeared already for Alpha1 leading to
> Plasma problems that I reported 
> 
> Beta0 worked badly since the beginning (no choice of language licence time
> reference etc)
> Beta0c and Beta0e have corrected this problem and work well now (without
> Plymouth and only a text displayed) until launching MageiaWelcome and Plasma
> that randomly run often  into troubles and rarely succeed.
> 
> What would be useful to find what changes in the order of the steps lead to
> a success or a failure ?

The compressed system journal from beta0c when not working, to compare with the one you have already attached from when it did work. Also the output from 'journalctl -b' run as the Live user in both cases.

Plasma, like other DEs, starts lots of tasks in parallel, so it is not unexpected that the startup order is different each time you boot.

(In reply to Philippe Didier from comment #109)
> Hi Thomas
> 
> 2 points :
> - About hardware (EFI and memory) I have the same hardware that I used for
> Mageia8 Mageia9...
> When I had used Mageia9 Live Plasma DVD final release before installing
> Mageia9 it worked without any problem.
> 
> I have just did today a test with this DVD : it works always perfectly !
> 
Philippe, I did NOT mean to imply in any way that your hardware is somehow inadequate to run  Cauldron Live media. It is MORE than adequate. 

All of my hardware, most of which is less adequate than yours, also runs Mageia 9 Live media with no issues. That's because we tested Mageia 9 when it was in Cauldron, and corrected any issues we found before it was released. 

But that was Mageia 9. Mageia 10/Cauldron is in the middle of all that testing now. We are hunting for issues, like why does the Plasma Live work on one machine but not another, when it should work on both? What is it about the difference between the two machines that triggers the problem?

> - using USB sticks without persistence don't allow to keep anywhere journal;
> system.journal; xorg.log; boot.log; xorg.conf 
> It's only when I opened (as root user) the persistent partition in my
> Mageia9 system 
> that I could make this files readable by anybody and could attach them here
> 
Without persistence, I used the command 
"journalctl -b | xz > beta0e.journal.log.xz" 
to get a compressed journal fille, which was put in Live's /home, which resides in RAM until the session is shut down. Then I ran Dolphin, and used it to copy that file to a data partition on one of my hard drives that's open to anybody (by design). If you are able to bring up a command line, you might be able to do something similar, even without persistence.
> 
> If the problems I have encountered for Plasma itself are caused by the fact
> that I have "only" 16Go memory (when it's widely enough for an installed
> Mageia system)...
>  That means that the Live Iso might let think that Mageia10 can't work on my
> system!
> 
Again, I did not mean to imply that your issues are "caused" by having less memory than I have, or that it might not be enough for Mageia 10!!!!

What I did mean is that while it should work on both systems, if there is more RAM available it might use it differently, or perhaps the driver build process goes at a different speed with more RAM available. I'm speculating about possible differences in our hardware that might trigger the issue, NOT "cause" it.

> Live ISO is supposed to demonstrate that Mageia10 can be used on the
> computer on which it is tested : a rarely obtained success is a bit daunting
> for a beginner.

Agreed. I can promise you that until and unless these Live isos boot properly on BOTH of our systems, every time, the betas will NOT be released to the public.

Created attachment 15425 [details]
bootlog of the Live Beta0c which did not worked correctly for Plasma

bootlog of Beta0c Live Plasma with Nvidia driver which didn't work correctly with Plasma

Created attachment 15426 [details]
compressed system journal of the Live Beta0c which did not worked correctly for Plasma

compressed system journal of Beta0c Live Plasma with Nvidia driver which didn't work correctly with Plasma

Created attachment 15427 [details]
xorg.conf of the Live Beta0c which did not worked correctly for Plasma

xorg.conf of Beta0c Live Plasma with Nvidia driver which didn't work correctly with Plasma

Created attachment 15428 [details]
Xorg.0.log of the Live Beta0c which did not worked correctly for Plasma

Xorg.0.log of Beta0c Live Plasma with Nvidia driver which didn't work correctly with Plasma

I have just attached what has been created when Beta0c failed to launch correctly MageiaWelcome and Plasma (created in the persistent partition)

Question : MageiaWelcome has filled the screen (no frame, no clickbox to not display it later) 
in this bad test is it because MageiaWelcome has been displayed inside the first step of the launching of Plasma ?

The difference looks to be that in the non-working case sddm has started before finish-install (which is the program that asks the questions about language, etc.) has terminated.

(In reply to Philippe Didier from comment #110)

> 
> What would be useful to find what changes in the order of the steps lead to
> a success or a failure ?

have you tried this:

- open a terminal
- become root with 'su'
- type 'urpme mageiawelcome'
- type 'killall sddm'

then re-login and see if the desktop has still some problem.

(In reply to Giuseppe Ghibò from comment #119)
> (In reply to Philippe Didier from comment #110)
> 
> > 
> > What would be useful to find what changes in the order of the steps lead to
> > a success or a failure ?
> 
> have you tried this:
> 
> - open a terminal
> - become root with 'su'
> - type 'urpme mageiawelcome'
> - type 'killall sddm'
> 
> then re-login and see if the desktop has still some problem.

It seems that this must be done for a second boot with the same USB pendrive having a persistent partition... Isn't it?

(In reply to Philippe Didier from comment #120)

> (In reply to Giuseppe Ghibò from comment #119)
> > (In reply to Philippe Didier from comment #110)
> > 
> > > 
> > > What would be useful to find what changes in the order of the steps lead to
> > > a success or a failure ?
> > 
> > have you tried this:
> > 
> > - open a terminal
> > - become root with 'su'
> > - type 'urpme mageiawelcome'
> > - type 'killall sddm'
> > 
> > then re-login and see if the desktop has still some problem.
> 
> It seems that this must be done for a second boot with the same USB pendrive
> having a persistent partition... Isn't it?

no, not on a persistent partition, just open a terminal (with CTRL-Alt-t) of what remain of the desktop when is not working as expect and type that. You said that a opening a terminal was possible.

(In reply to Martin Whitaker from comment #118)
> The difference looks to be that in the non-working case sddm has started
> before finish-install (which is the program that asks the questions about
> language, etc.) has terminated.

That seems to be true since for one of my tests the last finish-install window (keyboard choice) was still  displayed over the MageiaWelcome window (this one filled the screen with no frame)

(In reply to Martin Whitaker from comment #118)
> The difference looks to be that in the non-working case sddm has started
> before finish-install (which is the program that asks the questions about
> language, etc.) has terminated.

Maybe the solution would be to increase the delay between finish-install and sddm
Or to imply that finish-install is really finished before starting sddm ?

Three tests with an USB pendrive without persistent partition :
- Two with only one monitor plugged
- One with two monitors plugged

As a side effect the boot is faster than with the presence of a persistent partition there are lots of things written in this persistencepartition and sometimes the content of the USB pendrive is read and sometimes something is written... multiplying access and smowing all the processes

For each of this tests everything is OK : 
finish-install goes to its end
MageiaWelcome doesn't fill the screen , and is in the middle and has its frame
Plasma works normally : 
the menu is normally displayed
The windows of the programs can be closed


Conclusion :
The problem seems to be induced by the presence of a persistent partition... 
Without it everything seems to be OK

To test a Live ISO it's better not to have a persistent partition !!!

This part of the bug concerning specifically Plasma may be closed
The Nvidia part seems OK too
the only missing part is Plymouth

Well, the reason Philippe and I are seeing different behavior has nothing to do with different hardware. I have been insisting on testing a usb stick without persistence, and Philippe has been insisting on using persistence. 

I just created a Live Plasma on a 16GB stick from the beta0e iso, WITH persistence, and tried booting with it. I thought booting without persistence took a long time, but this took FOREVER. (I don't know exactly how long, because I don't have a wall calendar in this room so I couldn't time it. ;-)  ) Oddly enough, plymouth was working normally. 

Eventually, the desktop came up. Or tried to. All I got was an oversized Mageia Welcome that couldn't be closed. The LED on the usb stick indicated there was plenty of activity going on there, so I waited. Several more minutes, and the panel appeared. I tried running Dolphin from the panel - nothing. But then, maybe 2-3 minutes later, it popped up. LED still flashing like crazy.

I shut it down with the power switch, then booted again, and everything was OK. Same things Philippe is seeing.

So Philippe, just to confirm, could you please create a beta0e stick without persistence, and see if it boots to a proper desktop with the proprietary drivers?

Meanwhile, I'm going to try booting with nouveau on a stick with persistence...

Mid-Air Collision!

Great minds, Philippe, great minds. Thank you for testing without persistence before I asked.

But, I don't think we can close the bug, since it still doesn't work with persistence. That's a valuable tool to have, and it needs to work correctly.

Good find

So possibly timing/timout issues with using persistence at least sometimes.

The speed of USB drives vary *much*, so maybe no problem when using a fast USB stick.

https://wiki.mageia.org/en/Storage_speed_test_results (my tests four years ago)

I have wondered sometimes if buffering and compression could be used for the persistence partition but never got further than wondering.

The beta0e iso still works OK when booting with nouveau from a stick with persistence.

So, if we fix plymouth, and implement the fix that shows the language, etc questions with the nvidia drivers into the rest of the Lives, then upon further reflection that would satisfy the issue I had when opening this now very long and complicated bug. 

I would be OK with another round of beta test isos, addressing the first-boot-with-persistence issue in another bug. We'd need to try each of the other DEs with persistence and the nvidia drivers, which I don't think has been done yet. If, that is, we are still going to try to keep the nvidia drivers on the Lives at all.

(In reply to Martin Whitaker from comment #105)
> (In reply to Thomas Andrews from comment #102)
> > No difference. Plymouth still drops into text mode before it starts to build
> > the nvidia modules. Martin and I fought this battle before with an earlier
> > Mageia - I don't remember which one, or what was finally done to fix it, but
> > I do remember it was a frustrating experience.
> 
> I patched plymouth to recognise nokmsboot on the boot command line and force
> it to use the frame buffer device for display. But that patch got discarded
> when plymouth was updated in late December. I do wish the packagers would
> stop updating packages just because a new version is available. I've already
> spent over a day finding and fixing another regression caused by that
> plymouth update.

Are the patches to be ported to release 24.x, these ones?

https://svnweb.mageia.org/packages/cauldron/plymouth/releases/0.9.5/7.mga10/SOURCES/1001-device_manager-ignore-drm-devices-when-kernel-modese.patch?revision=2213051&view=markup

https://svnweb.mageia.org/packages/cauldron/plymouth/releases/0.9.5/7.mga10/SOURCES/1002-main-allow-the-device-timeout-to-be-overridden-on-th.patch?revision=2213051&view=markup

(In reply to Philippe Didier from comment #117)

> I have just attached what has been created when Beta0c failed to launch
> correctly MageiaWelcome and Plasma (created in the persistent partition)
> 
> Question : MageiaWelcome has filled the screen (no frame, no clickbox to not
> display it later) 
> in this bad test is it because MageiaWelcome has been displayed inside the
> first step of the launching of Plasma ?

does it change something if you boot with passing maxcpus=1 (apart the longer modules generation time)?

(In reply to Thomas Andrews from comment #128)
> The beta0e iso still works OK when booting with nouveau from a stick with
> persistence.
> 
> So, if we fix plymouth, and implement the fix that shows the language, etc
> questions with the nvidia drivers into the rest of the Lives, then upon
> further reflection that would satisfy the issue I had when opening this now
> very long and complicated bug. 

I will test this Beta0f including Plymouth when it will be available
> 
> I would be OK with another round of beta test isos, addressing the
> first-boot-with-persistence issue in another bug. We'd need to try each of
> the other DEs with persistence and the nvidia drivers, which I don't think
> has been done yet. If, that is, we are still going to try to keep the nvidia
> drivers on the Lives at all.

I am OK with the idea of opening a new bug about the problems induced by the presence of a persistent partition 

I have tested again Alpha1 Plasma with Nvidia driver on a pendrive without persistent partition
All the bugs concerning Alpha1 are resolved when there's no more this persistent partition...
https://bugs.mageia.org/show_bug.cgi?id=35008
https://bugs.mageia.org/show_bug.cgi?id=35009
https://bugs.mageia.org/show_bug.cgi?id=35010

I need to know the number of this new bug concerning persistent partition (for Alpha or Betas) to add a link to it in the next comments inside the Alpha1 bugs

The only little problem remaining for me is a little error in the frequency of the HDMI TV when it is a clone of the primary monitor :
60,05 instead of 60 ... as a consequence The display is a little cropped on the TV
but this is easily corrected with Plasma System Settings

(In reply to Philippe Didier from comment #131)

> (In reply to Thomas Andrews from comment #128)
> > The beta0e iso still works OK when booting with nouveau from a stick with
> > persistence.
> > 
> > So, if we fix plymouth, and implement the fix that shows the language, etc
> > questions with the nvidia drivers into the rest of the Lives, then upon
> > further reflection that would satisfy the issue I had when opening this now
> > very long and complicated bug. 
> 
> I will test this Beta0f including Plymouth when it will be available

There will be also with nvidia-580.126.18.

Post Scriptum
Sorry for my late last comments I had to undergo a little surgery today and went to an hospital early this morning and had to stay there for some hours... 
Everything is OK for me but I must stay home for some days 

I will have lot of time for tests ;o)

For what it's worth, I just tried the beta1 Xfce Live with a persistent partition. Everything worked, including plymouth. Eventually.

It seems even slower than the Plasma Live, if that's possible. But the way the desktop came up is different than with Plasma. 

With Xfce, when the desktop started to show the first thing was a black screen. A minute or two later, you see a busy mouse cursor that can be moved with the mouse. Another few minutes, and you get the top panel. More minutes and the bottom panel. More minutes, and the Mageia background. Then the detected file systems, and finally the last thing to appear is Mageia Welcome.

With Plasma, the first part of the desktop to appear is the oversized Mageia Welcome. If you wait, after a while the panel will show up, but it seems unresponsive. Wait some more, and eventually you can run one of the applications from the panel.

From a user's perspective, it's as if Mageia Welcome is started too early in Plasma, before the desktop is ready for it.

But with either one, if you want to use a persistent partition with a nvidia GPU, it's FAR quicker to boot without the nvidia drivers, and install them afterward.

(In reply to Thomas Andrews from comment #135)
> For what it's worth, I just tried the beta1 Xfce Live with a persistent
> partition. Everything worked, including plymouth. Eventually.
> 
That's not quite right. I almost forgot - the language. etc questions were not asked.

I certainly expect the time to build and install the nvidia proprietary drivers to be much longer when using a persistent partition because that involves lots of writing to the USB stick instead of writing to RAM. And as Morgan wrote earlier, some USB sticks are quite fast, some are really slow! The trade off is that with persistence you suffer more on the first boot, without persistence you suffer on every boot.

But I'm surprised enabling persistence significantly slows down the DE startup. There shouldn't be that much being written to the USB stick.

(In reply to Martin Whitaker from comment #137)
> I certainly expect the time to build and install the nvidia proprietary
> drivers to be much longer when using a persistent partition because that
> involves lots of writing to the USB stick instead of writing to RAM. And as
> Morgan wrote earlier, some USB sticks are quite fast, some are really slow!
> The trade off is that with persistence you suffer more on the first boot,
> without persistence you suffer on every boot.
> 
> But I'm surprised enabling persistence significantly slows down the DE
> startup. There shouldn't be that much being written to the USB stick.

Hi Martin
 I use USB3 pendrive : creating a Live ISO with isodumper is quite fast on my computer
Nevertheless there are lots of accesses to the persistent partition (particularly the system.journal inside /var/ folder receives lots of modifications during each step...)
A kind of /root/ folder is created too with lots of sub folders and files

This is shown by the constantly flashing led of the pendrive (alterning reading and writing on it)

Booting with nvidia driver and using a persistent partition takes 25 minutes !...

Without persistent partition it takes around 5 minutes

(In reply to Martin Whitaker from comment #137)
> I'm surprised enabling persistence significantly slows down the DE
> startup. There shouldn't be that much being written to the USB stick.

Maybe few megabytes but many small files.
Some sticks are super terrible at many small random writes.
One of my tests was to run 
 # remove-unused-packages
and remove unused localisation.  For some stick you can go have a dinner... 

On fast sticks, Mageia Live is pretty impressive especially with persistence.

Not for this bug but maybe persistence could be buffered and compressed?
To both gain speed and storage size.
One part might be to use btrfs for persistence, which support compresion.

For me using a SanDisk Ultra USB 3.0 16GB stick (must be over 6 years old) with the beta0e ISO:

  - without persistence, boot to final Plasma desktop took 45s
    (excluding answering questions)

  - with persistence, first boot to final Plasma desktop took 55s
    (excluding answering questions), second boot took 50s

  - with persistence, installing x11-driver-video-nvidia-current
    from the desktop took 8m

That was with a Ryzen 2 laptop.

Well yes, my Xfce drive is USB 2.0, and older, as well. Flash drives seem to get slower the more they are used. It was what I had available. (Amazon was supposed to deliver some new drives yesterday. They aren't here yet.)

Even so, something about using those proprietary drivers on that first boot is slowing things down, well after the drivers were supposed to be all built and installed.

I just took the same drive, formatted the persistent partition, and booted again, this time with nouveau. When the desktop came up it appeared all at once, rather than piecemeal like before. More responsive, too.

@TJ, using beta0e without persistence and choosing to use proprietary drivers, could you try adding

  plymouth.use-simpledrm

to the boot command line to see if it stops Plymouth dropping into text mode.

No difference. I added it just before nokmsboot, if that makes any difference. 

I didn't make a new usb stick, either. Should I have?

No the old USB stick was fine. Oh well, it was worth a try.

A few upgrades. I've uploaded a beta0f (it should be moved to the proper position). In this version there is a little update to nvidia 580.18.19. There is also an extra set of driver to support the blackwell GPUs with the open gpu kernel modules. This modules have also the prebuilt kernel modules and thus it could speed up loading (it still requires a modification to drakx11, to avoid the dkms-<driver> is installed and enabled anyway, but that's another thing).

Note also that all the problems you might see here are not due to the nvidia drivers itself. Now those are resolved in the new betas. nvidia just let emerged other problems that were already there in particular in the parallel startup and plymouth. In fact if when you boot with the flag maxcpus=1 you won't get the mageiawelcome is started before the desktop. When this happens the kwin_x11 is not started and you get frameless windows. it could be forced running from the shell, typing kwin_x11 --replace.

(In reply to Giuseppe Ghibò from comment #145)
> A few upgrades. I've uploaded a beta0f (it should be moved to the proper
> position). In this version there is a little update to nvidia 580.18.19.
> There is also an extra set of driver to support the blackwell GPUs with the
> open gpu kernel modules. This modules have also the prebuilt kernel modules
> and thus it could speed up loading (it still requires a modification to
> drakx11, to avoid the dkms-<driver> is installed and enabled anyway, but
> that's another thing).
> 
> Note also that all the problems you might see here are not due to the nvidia
> drivers itself. Now those are resolved in the new betas. nvidia just let
> emerged other problems that were already there in particular in the parallel
> startup and plymouth. In fact if when you boot with the flag maxcpus=1 you
> won't get the mageiawelcome is started before the desktop. When this happens
> the kwin_x11 is not started and you get frameless windows. it could be
> forced running from the shell, typing kwin_x11 --replace.

Certainly, this must be tested without a persistent partition which induces a particular bug that is not linked to Nvidia driver itself...

I really think that a bug report needs to be created about what the persistent partition induces which was erroneously attributed to the simultaneous use of Nvidia driver and MageiaWelcome and Plasma : after several tests I discovered that without persistent partition the main problems disappeared for me in bugs 35008 35009  35010 35107 and in this bug 35020 itself here : https://bugs.mageia.org/show_bug.cgi?id=35020#c124

(In reply to Philippe Didier from comment #146)
> Certainly, this must be tested without a persistent partition which induces
> a particular bug that is not linked to Nvidia driver itself...

Could you list the bugs that occur with both the nvidia and nouveau drivers. You may have already reported this, but this bug report has got too long for me to easily see.

(In reply to Giuseppe Ghibò from comment #145)
> A few upgrades. I've uploaded a beta0f (it should be moved to the proper
> position). In this version there is a little update to nvidia 580.18.19.
> There is also an extra set of driver to support the blackwell GPUs with the
> open gpu kernel modules. This modules have also the prebuilt kernel modules
> and thus it could speed up loading (it still requires a modification to
> drakx11, to avoid the dkms-<driver> is installed and enabled anyway, but
> that's another thing).

I've moved the bet0f files to the QA ISO nvidia-test directory, but neither TJ nor Phillipe are using a Blackwell series GPU so I don't understand what you expect to learn from them.

Hi
I have just tested Beta0f Plasma twice (without persistent partition)

With free driver : no problem plymouth starts Mageia Welcome appears correctly Plasma is usable

With Nvidia driver it takes 4 minutes to get to finish-install (but plymouth doesn't appear)
Unfortunately 
- the programs  from Plasma (Plasma Settings) have no frame and no way to quit them
- The power off button from Mageia Menu doesn't stop Mageia but leads to a grey background
- Ctrl+ Alt + Del leads to a grey background with 5 choiced (Sleep, hibernate, quit, unconnect etc.. ) clicking on quit does nothing
need to manually power off the computer

quite Like in comment 69

(In reply to Martin Whitaker from comment #147)
> (In reply to Philippe Didier from comment #146)
> > Certainly, this must be tested without a persistent partition which induces
> > a particular bug that is not linked to Nvidia driver itself...
> 
> Could you list the bugs that occur with both the nvidia and nouveau drivers.
> You may have already reported this, but this bug report has got too long for
> me to easily see.
> 
Nvidia with  persistent partition...  in the end I discovered that without persistent partition I got no problem :
https://bugs.mageia.org/show_bug.cgi?id=35008
https://bugs.mageia.org/show_bug.cgi?id=35009
https://bugs.mageia.org/show_bug.cgi?id=35010
https://bugs.mageia.org/show_bug.cgi?id=35107

In this bug report (35020)
with persistent partition
comment 58
comment 63
comment 69
comment 77
without persistent partition
comment 124 OK

Having done several tests with a persistent partition most of them failed
Having done other tests without persistent partition all succeeded


That's the first time comment 148 that a test without persistent partition fails

(In reply to Philippe Didier from comment #148)
> Hi
> I have just tested Beta0f Plasma twice (without persistent partition)
> 
> With free driver : no problem plymouth starts Mageia Welcome appears
> correctly Plasma is usable
> 
> With Nvidia driver it takes 4 minutes to get to finish-install (but plymouth
> doesn't appear)
> Unfortunately 
> - the programs  from Plasma (Plasma Settings) have no frame and no way to
> quit them

the frameless windows means that the window manager kwin_x11 window manager is not started (it could be started manually from a shell running kwin_x11 --refresh).

> - The power off button from Mageia Menu doesn't stop Mageia but leads to a
> grey background
> - Ctrl+ Alt + Del leads to a grey background with 5 choiced (Sleep,
> hibernate, quit, unconnect etc.. ) clicking on quit does nothing
> need to manually power off the computer

Magic SysRq is enabled.

Have you tried booting with maxcpus=1 in that case?

(In reply to Giuseppe Ghibò from comment #150)

> Have you tried booting with maxcpus=1 in that case?

of course that for the booting part. Once it starts and you get a graphic shell, you can re-enable all cores with:

chcpu -e 0-3

e.g. in the case you have 4 (2+2) cores.

With my Quadro K620, booting with the nvidia drivers, without persistence:

Plymouth still drops into text mode. Unlike Philippe's experience, once the boot is complete, I'm presented with a fully functional, reasonably responsive Plasma desktop.

@Martin: I also created another stick with a persistence partition, and booted it with the free drivers. It booted OK, but I noticed that Mageia Welcome appeared first, before the background, desktop icons, or panel. I didn't time it, but I'd guess it was at least a minute, but less than two, before the rest appeared. 

I did the same with the beta1 Plasma Live, and it acted the same. This differs from the beta1 Xfce, where the whole desktop, including Mageia Welcome, popped up at the same time.

Hi
New tests of Beta0f Plasma (no persistent partition one monitor)
1) with nouveau 1 minute (with plymouth displayed) before the start of Plasma : OK

2) with Nvidia 4 minutes (without Plymouth only texts) before the start of Plasma : - This time the windows have a frame, 
- when I launch a program its name appears in the bpttom bar I can quit the program with the x cross of its window  orclicking on its name in the task bar
- I can power off with the button of Mageia Menu

The result is perfect fot both of them this time (the boot for Nvidia is not so long)

I will test with 2 monitors plugged

about comment 153 : I didn't have to run kwin_x11 to have a correctly working Plasma, there seems to be a random order of the steps before Plasma statrs

New tests with the same pendrive with two monitors (a monitor and an HDMI TV on the right):

1) booting with nouveau
- Starts with plymouth
- The finish-install step is spread over the 2 monitors its windows are splitted :
their left part on the left monitor and their right part on the right monitor (need to navigate with the mouse from one monitor to the other)
- When Plasma appears it is totally displayed on the left monitor (not spread over the two) the right monitor displays only the Mageia background
- I can use Plasma Settings to use the right monitor as a clone of the primary
The fresuency of the TV is OK : 60 hz

2) booting with Nvidia
- no plymouth but a text showing the steps (installing rpms building driver installing driver)
- The finish-install appears cloned on the two monitors : easy to click
- Plasma appears on the left monitor : the right monitor contains only the Mageia background (like for nouveau)
- I can use Plasma Settings to use the right monitor as a clone of the primary
The fresuency of the TV is OK : 60 hz

In both of these tests Plasma works normally (windows have a frame, Mageia Menu works, the power off button of the Menu stops the computer

Nota Bene with Nvidia clicking the Power Off button makes plymouth appear !!!

no way to understand why with Beta0f
the boot fails randomly comment 148 
or succeeds randomly comment 153 comment 155

I insist again to highlight the fact that having a pendrive without persistent partition causes less bugs

Lots of my previous comments here and lots of other bugs that I have reported about Alpha1 and Beta1 were caused by the persistent partition and polluted what should strictly concern Nvidia and Plasma

Does the problems that appear when using persistence only happen when using proprietary nvidia?

(In reply to Philippe Didier from comment #156)

> no way to understand why with Beta0f
> the boot fails randomly comment 148 
> or succeeds randomly comment 153 comment 155

Can you try whether adding "maxcpus=1" to boot this "randomness" is less prone? All you have to do is when in the Grub screen you choose "+ use non-free ...", press 'e' (edit) then move to the line where there is xclone=1 and append 'maxcpus=1' and the press 'ctrl-x' to boot?

BTW, there is "beta0g" available for downloading. It has a newer kernel (6.18.13-1.mga10).

What I also noticed, following the comment https://bugs.mageia.org/show_bug.cgi?id=35020#c118, is that in finish-install, whose code is here:

https://gitweb.mageia.org/software/drakx/tree/perl-install/standalone/finish-install

it enters in graphical mode when it calls the 'language' popup, at line 290. I guess at this point this is an X11 window using GTK (I wonder if that is already started with 3D support).

Then there is then there is the eula which seems triggered by:

call('license')

then there is the asking for "Timezone", "Country" and "Keyboard", which
corresponds to:

call('timezone');
call('country');
call('keyboard');
call('network');

then there is something like this:

if (defined $::WizardWindow) {
    $::WizardWindow->destroy;
    undef $::WizardWindow;
}

which apparently is supposed to "destroy" the Wizard Window. Is this that could cause the problems? Then following the code, it calls authentication, users, etc. and finally it calls:

call('glx')

which seems to complete the 3D features.

Maybe we could add a sleep(3) somewhere for debugging? e.g. before calling call('glx'):

sleep(3);
call('glx');
sleep(3);

or maybe move call('glx'), before setting the language, like this?

sleep(1)
call('glx')
call('language')
call('license')

so the graphical setup is already completed?

What is changed is that Plasma seems to become very picky regarding 3D support for getting started properly.

Hi
I have tested Beta0g Plasma without persistent partition with two monitors

1) booting with nouveau
- Starts with plymouth (clicking on ESC allows to see the successive steps)
- The finish-install step is spread over the 2 monitors its windows are splitted :
their left part on the left monitor and their right part on the right monitor (need to navigate with the mouse from one monitor to the other)
- When Plasma appears, after one minute since the boot, it is totally displayed on the left monitor (not spread over the two) the right monitor displays only the Mageia background
- Mageia Welcome is correctly displayed inside Plasma abd can be closed (I can chose not to show it at each start
- I can use Plasma Settings to use the right monitor as a clone of the primary
The fresuency of the TV is OK : 60 hz it is a perfect clone of the primary monitor

2) booting with Nvidia
- no plymouth but a text showing the steps (installing rpms building driver installing driver)
- The finish-install appears cloned on the two monitors : easy to click
- then Plasma appears on the left monitor (5 minutes after the boot) : the right monitor contains only the Mageia background (like for nouveau) 
- Mageia Welcome is correctly displayed inside Plasma abd can be closed (I can chose not to show it at each start
- I can use Plasma Settings to use the right monitor as a clone of the primary
The fresuency of the TV is OK : 60 hz

In both of these tests Plasma works normally (windows have a frame, Mageia Menu works, the power off button of the Menu stops the computer

Nota Bene with Nvidia clicking the Power Off button makes plymouth appear !!!

Nota Bene bis : I didn't have to edit Grub to succeed in both cases

Nota Bene ter : I didn't test it with a persistent partition : this would deserve other tests and certainly an other bug

(In reply to Thomas Andrews from comment #152)
> @Martin: I also created another stick with a persistence partition, and
> booted it with the free drivers. It booted OK, but I noticed that Mageia
> Welcome appeared first, before the background, desktop icons, or panel. I
> didn't time it, but I'd guess it was at least a minute, but less than two,
> before the rest appeared. 

I usually see MageiaWelcome appear before the Plasma desktop when testing on other platforms and in VirtualBox. Plasma is very slow to start - that's one of the many things I don't like about it.

(In reply to Morgan Leijström from comment #158)
> Does the problems that appear when using persistence only happen when using
> proprietary nvidia?

From what I've read in the comments (e.g. comment 141), yes.

(In reply to Giuseppe Ghibò from comment #160)
...
> Then following the code, it calls authentication,
> users, etc. and finally it calls:
> 
> call('glx')
> 

which does nothing, because we don't install compiz on the Live ISOs.

I wonder if there is a correlation with plymouth, and whether the lines

if (defined $::WizardWindow) {
    $::WizardWindow->destroy;
    undef $::WizardWindow;
}

which is called after call('network') at line 298 of finish-install is really necessary?

finish_install is called from the drakx-installer-xsetup service which is run after the system has booted. That service calls 'plymouth quit' before calling finish_install. So finish_install can have no bearing on the plymouth behaviour.

If you want to debug the plymouth issue, add 'plymouth.debug=stream:/dev/kmsg' to the boot command line, which will store a lot of extra information in the system journal.

Created attachment 15440 [details]
plymouth-debug.log

Here is the plymouth-debug.log  from Beta0g Plasma with nvidia driver
obtained with "plymouth.debug=stream:/dev/kmsg "

Created attachment 15441 [details]
compressed system journal of the Live Beta0g (including plymouth.debug

Here is the compressed system.journal from Beta0g Plasma with nvidia driver
obtained with "plymouth.debug=stream:/dev/kmsg "

Hi Martin
I have just attached what you asked for

Nota Bene for this test I have two monitors plugged

Nota Bene bis
this time Beta0g Plasma worked well with Nvidia driver like in comment 162 second part : 2)

the finish-install step is easier to use with Nvidia than with nouveau !
- with Nvidia the windows are not splitted but appear in the middle of cloned monitor
- With nouveau the screen is spread over the two monitors and the finish-install windows are splitted on the two monitors
look at comment 162 first part : 1)

Last thoughts

I can confirm that booting with Nvidia is not so long (less than 5 minutes when nouveau needs a little more than one minute)

When this bug report will be closed (it is not far from being closed) 
I will test with persistent partition and surely open a new bug report about the problems that appear because of the persistent partition (that I already discovered for Alpha and Beta) 


I have polluted  this 35020 bug report  with lots of comments linked to the use of a persistent partition until I stopped to create a persistent partition : comment 124


I have at least narrowed that this persistent partition was the culprit for the very long boot (25 minutes) and the bad behaviour of Mageia Welcome and Plasma

To confirm the problems with Nvidia driver AND persistent partition :
1) 
USB pendrive newly created with Beta0g and a persistent partition 
using  2 monitors
- boot for nouveau 
- Plymouth OK
-little problem for the finish install 
(the screen is spread over the 2 monitors and the windows are split : left part on the left monitor right part on the right monitor)
- 5 minutes before Plasma is launched and usable 'spread on the 2 monitors but it's easy to get the second one as z clone of the primary
Their frequency is correct (60Hz)

2)
USB pendrive newly created with Beta0g and  a persistent partition 
using  2 monitors
- boot for Nvidia
- no plymouth but a white text with hash signs on black background
-the led of the pendrive begins to be crazily constantly flashing
- building and installing Nvidia driver takes 16 minutes
-finish install appears on cloned monitors but is very slow 
- Plasma begins to launch 
- the window of Mageia Welcome appears after 28 minutes  covering the display with no frame
- After 32 minutes the Plasma Desktop is spread over the 2 monitors
- The Mageia Menu is not usable (I can only see its right half part)
- I use Plasma settings to have the second monitor as a clone of the primary
- No frame (no title bar) for the window of Plasma settings and no way to quit it
- with the MCC I can explore the devices but sometimes this is stuck on a category : the mouse being unresponsive
- When the monitors are clones, the Mageia Menu appears correctly and displays the categories (groups) of programs but clicking on a category doesn't show the list of existing programs 

- Clicking on Mageia Menu "power off" button leads to a grey screen but doesn't stop the system

Ctrl+alt+Del leads to a screen showing the choice (hibernate stop disconnect etc...)
clicking on this stop button doesn't do anything except leading to a grey screen
Ctrl+alt+Del leads to the previous step
it's a loop
Need to manually power off the computer


TO CONLUDE

1) Nvidia drivers works correctly if you don't use a persistent partition (Mageia10 works even better than with nouveau) 
two little problems :
no Plymouth but the steps are explained by the text displayed
5 minutes before Plasma starts and works correctly

2) the persistent partition brings lots of problems same as for Alpha1
-more than 30 minutes to launch Plasma pendrive flashing constantly
-bad display of Mageia Welcome (window without frame)
- Plasma not usable Mageia Menu not usable
- no way to Power OFF

POST SCRIPTUM
I have booted again with the pendrive with persistent partition that I used with Nvidia driver in comment 170
- Everything that was stored in the persistent partition allows a relatively fast boot (4 minutes) quite as quick as my installed Mageia9
- Plymouth is present
- Plasma is correctly displayed (cloned monitors as it was set previously)
- Every window has its frame and can be closed
- Mageia Menu works and allows to launch the installed programs
- the Power Off button in Mageia Menu stops effectively the computer

I think that while not perfect, the current state with NVidia is usable, and I think we can move forward.

I've added the fixes I used based on the progress here in the archive "draklive-config-beta0x-fixes.tar.xz" in my home dir, in nvidia-tests/.

I wonder of two things:

a) Is it possible to run the "finish-install" stage (or the previous stage calling it) manually, outside of the booting procedure, for testing purposes?

b) Would adding a "sleep(2)" (or sleep(3)) after the following code in "finish-install" at line 302) be beneficial, giving the drivers extra time to settle before the new desktop starts?

if (defined $::WizardWindow) {
  $::WizardWindow->destroy;
  undef $::WizardWindow;
}
sleep(2); <---

?

(In reply to Giuseppe Ghibò from comment #172)
> I think that while not perfect, the current state with NVidia is usable, and
> I think we can move forward.
> 
> I've added the fixes I used based on the progress here in the archive
> "draklive-config-beta0x-fixes.tar.xz" in my home dir, in nvidia-tests/.

This is full of completely unrelated additions. Please say exactly what changes were needed to fix this bug.

Note that testing on my old laptop with hybrid nvidia/intel graphics has shown we need to change the default session to Plasma(Wayland).

> I wonder of two things:
> 
> a) Is it possible to run the "finish-install" stage (or the previous stage
> calling it) manually, outside of the booting procedure, for testing purposes?

Yes. You need to restore the contents of /etc/sysconfig/finish-install (see draklive-config/files/finish-install), then as root run

  DISPLAY=:0 /sbin/finish-install

> b) Would adding a "sleep(2)" (or sleep(3)) after the following code in
> "finish-install" at line 302) be beneficial, giving the drivers extra time
> to settle before the new desktop starts?
> 
> if (defined $::WizardWindow) {
>   $::WizardWindow->destroy;
>   undef $::WizardWindow;
> }
> sleep(2); <---

Why should the drivers need time to settle? At that point the X server is up and working. In any case drakx-installer-xsetup kills the X server in its final step and SDDM starts from scratch.

Adding random sleeps to work around bugs is never the right thing to do, as it is always fragile.

I'll also note that the packages x11-driver-video-nvidia-current and x11-driver-video-nvidia-current-wopengpu are largely comprised of the same files. Including both on the ISO will add a needless extra 300MB to the ISO size. The common files should be split out into a separate package.

(In reply to Martin Whitaker from comment #173)

> (In reply to Giuseppe Ghibò from comment #172)
> > I think that while not perfect, the current state with NVidia is usable, and
> > I think we can move forward.
> > 
> > I've added the fixes I used based on the progress here in the archive
> > "draklive-config-beta0x-fixes.tar.xz" in my home dir, in nvidia-tests/.
> 
> This is full of completely unrelated additions. Please say exactly what
> changes were needed to fix this bug.
> 
> Note that testing on my old laptop with hybrid nvidia/intel graphics has
> shown we need to change the default session to Plasma(Wayland).

The necessary changes involve adjustments to dracut-live.conf (as shown in the archive above) and build.cfg. Specifically, dracut-live.conf needs to exclude nouveau.ko. For build.cfg, 'sddm-wayland-plasma' needs to be explicitly excluded within the 'exclude_packages =>' section; simply not including it isn't sufficient. I've added it after gimp in the list, and also added 'task-plasma-x11' within the 'if_($has_plasma)' block.

Note that 'sddm-wayland-plasma' doesn't influence the default desktop session but the display manager.

These changes were tested between builds 0b and 0c, and are crucial to prevent issues like mageiawelcome starting prematurely, the EULA being skipped, and kwin either crashing or not starting correctly.

Also, beyond basic benchmarking testing tools, I've explicitly added 'egl-wayland-json' and 'egl-wayland2-json', along with 'lib64nvidia-egl-wayland1' and 'lib64nvidia-egl-wayland2_1'. The latter are quite small and don't interfere even if NVidia drivers aren't installed, slightly speeding up installation by reducing the number of packages to be installed later.

> 
> > I wonder of two things:
> > 
> > a) Is it possible to run the "finish-install" stage (or the previous stage
> > calling it) manually, outside of the booting procedure, for testing purposes?
> 
> Yes. You need to restore the contents of /etc/sysconfig/finish-install (see
> draklive-config/files/finish-install), then as root run
> 
>   DISPLAY=:0 /sbin/finish-install
> 
> > b) Would adding a "sleep(2)" (or sleep(3)) after the following code in
> > "finish-install" at line 302) be beneficial, giving the drivers extra time
> > to settle before the new desktop starts?
> > 
> > if (defined $::WizardWindow) {
> >   $::WizardWindow->destroy;
> >   undef $::WizardWindow;
> > }
> > sleep(2); <---
> 
> Why should the drivers need time to settle? At that point the X server is up
> and working. In any case drakx-installer-xsetup kills the X server in its
> final step and SDDM starts from scratch.

Regarding X server settling time, modern GPUs and the kernel's DRM subsystem manage significantly more resources than in the past. Killing the X server doesn't instantly release all of them, unlike a graceful termination. While the X process terminates quickly upon being killed, the resources held by the X server and its drivers (locks, memory, etc.) take time to be fully released. Firing up a new session immediately after killing the old one can lead to desktop startup issues, and Plasma is particularly prone to this. This isn't a new issue, a similar bug existed in Mageia 7 or 8 (still open, IIRC) and wasn't fully resolved upstream. You can easily test this by repeatedly killing the X server and restarting Plasma sessions; you'll often find the desktop fails to start correctly if restarted too quickly. Some other distributions have circumvented this with different approaches, using pure systemd startup strategies.

(In reply to Giuseppe Ghibò from comment #175)
> The necessary changes involve adjustments to dracut-live.conf (as shown in
> the archive above) and build.cfg. Specifically, dracut-live.conf needs to
> exclude nouveau.ko.

As previously said, nouveau is included in the initrd to stop plymouth falling back to text mode, so can't be excluded. However, if the module is not loaded, it can't cause any problems. In my tests the udev rules take care of that when nokmsboot is detected, but we can try adding rd.driver.blacklist=nouveau as an additional precaution.

> Also, beyond basic benchmarking testing tools, I've explicitly added
> 'egl-wayland-json' and 'egl-wayland2-json', along with
> 'lib64nvidia-egl-wayland1' and 'lib64nvidia-egl-wayland2_1'. The latter are
> quite small and don't interfere even if NVidia drivers aren't installed,
> slightly speeding up installation by reducing the number of packages to be
> installed later.

This would cause draklive-install to install these packages on systems that don't need them. If these packages are truly small, they will add an insignificant amount to the time taken to install and build the proprietary drivers.

> Regarding X server settling time, modern GPUs and the kernel's DRM subsystem
> manage significantly more resources than in the past. Killing the X server
> doesn't instantly release all of them, unlike a graceful termination. While
> the X process terminates quickly upon being killed, the resources held by
> the X server and its drivers (locks, memory, etc.) take time to be fully
> released. Firing up a new session immediately after killing the old one can
> lead to desktop startup issues, and Plasma is particularly prone to this.

We do a clean termination of the X server. If you look in the system journal you will find these messages:

drakx-installer-xsetup[1050]: waiting for X server to shut down
drakx-installer-xsetup[1051]: (II) Server terminated successfully (0). Closing log file.

which is confirmed by examining /var/log/Xorg.0.log.old.

commit a6f1207bc0e64cc529d78082050e4e6e4418b83d
Author: Martin Whitaker <mageia@...>
Date:   Tue Feb 24 09:33:48 2026 +0000

    Add workarounds for NVIDIA proprietary drivers (mga#35020)
    
    Make sure the nouveau driver is not loaded by dracut.
    Force SDDM to use X11, not Wayland.
---
 Commit Link:
   https://gitweb.mageia.org/software/build-system/draklive-config/commit/?id=a6f1207bc0e64cc529d78082050e4e6e4418b83d

(In reply to Martin Whitaker from comment #176)
> (In reply to Giuseppe Ghibò from comment #175)
> > The necessary changes involve adjustments to dracut-live.conf (as shown in
> > the archive above) and build.cfg. Specifically, dracut-live.conf needs to
> > exclude nouveau.ko.
> 
> As previously said, nouveau is included in the initrd to stop plymouth
> falling back to text mode, so can't be excluded. However, if the module is
> not loaded, it can't cause any problems. In my tests the udev rules take
> care of that when nokmsboot is detected, but we can try adding
> rd.driver.blacklist=nouveau as an additional precaution.

We already tested this deeply between 0b and 0c, where this was the only and single difference and with nouveau.ko preloaded ALL the tests were failing, while with it excluded it worked with nouveau driver flawlessly very well, but also with nvidia.

IMHO is not something tied to the preloading of it, but there could be something in the scripts detecting its presence somewhere by some parsing.

(In reply to Giuseppe Ghibò from comment #178)
> We already tested this deeply between 0b and 0c, where this was the only and
> single difference and with nouveau.ko preloaded ALL the tests were failing,
> while with it excluded it worked with nouveau driver flawlessly very well,
> but also with nvidia.
> 
> IMHO is not something tied to the preloading of it, but there could be
> something in the scripts detecting its presence somewhere by some parsing.

Then we have to find out what that is. I'm sorry, but I'm not going to reintroduce a bug that affects using the free drivers in order to support using the proprietary drivers.

There's a new set of beta1 Live ISOs in the trial-builds directory on the pre-release rsync server. Please test.

> Also, beyond basic benchmarking testing tools, I've explicitly added
> 'egl-wayland-json' and 'egl-wayland2-json', along with
> 'lib64nvidia-egl-wayland1' and 'lib64nvidia-egl-wayland2_1'. The latter are
> quite small and don't interfere even if NVidia drivers aren't installed,
> slightly speeding up installation by reducing the number of packages to be
> installed later.

"This would cause draklive-install to install these packages on systems that don't need them. If these packages are truly small, they will add an insignificant amount to the time taken to install and build the proprietary drivers."

This brings to mind another potential issue after all these changes are made. What happens if a user innocently selects using the proprietary drivers when a covered GPU isn't present? If it's too old, or even if not Nvidia?

(In reply to Martin Whitaker from comment #176)

> 
> > Regarding X server settling time, modern GPUs and the kernel's DRM subsystem
> > manage significantly more resources than in the past. Killing the X server
> > doesn't instantly release all of them, unlike a graceful termination. While
> > the X process terminates quickly upon being killed, the resources held by
> > the X server and its drivers (locks, memory, etc.) take time to be fully
> > released. Firing up a new session immediately after killing the old one can
> > lead to desktop startup issues, and Plasma is particularly prone to this.
> 
> We do a clean termination of the X server. If you look in the system journal
> you will find these messages:
> 
> drakx-installer-xsetup[1050]: waiting for X server to shut down
> drakx-installer-xsetup[1051]: (II) Server terminated successfully (0).
> Closing log file.
> 
> which is confirmed by examining /var/log/Xorg.0.log.old.

There may be other resources released later. A test could involve introducing a "delay" just after the first X server closes, following the "wizardwindow->destroy" call. This delay would be programmable and can be passed from the boot command line in userland, ranging from 0 (default) to 60 seconds (maximum). This allows for a configurable delay. If no delay is specified, it will remain at 0, as it is currently, meaning no delay will be applied.

(In reply to Martin Whitaker from comment #180)
> There's a new set of beta1 Live ISOs in the trial-builds directory on the
> pre-release rsync server. Please test.

Took me a while, but here are some results:

32-bit Xfce will not boot using rEFInd the way I have it configured, so it wasn't tested.

All other three DEs acted the same. Booting without the nvidia drivers went normally, plymouth, questions, functioning desktop. 

Booting with nvidia drivers went into a text screen, as if esc had been pressed while in plymouth, and indeed, pressing esc showed the infamous three boxes of plymouth text mode. Boot proceeded, building and installing nvidia driver, and in the end sent me to a functioning desktop, skipping the questions.

And one final thing, remembered from something either in the qa-discuss ML or on the pad. I believe it's probably related, or I would not bring it up here: 

Booting to install Mageia without nvidia drivers proceeds normally, to finish at the installer. Booting with the nvidia drivers builds the drivers the same as booting into Live mode, but when finished takes you to the Plasma, Gnome, or Xfce desktop, instead of the installer.(There may be a bug on this. I didn't find it with a quick search.)

(In reply to Giuseppe Ghibò from comment #182)
..
> There may be other resources released later. A test could involve
> introducing a "delay" just after the first X server closes, following the
> "wizardwindow->destroy" call. 

That does not close the X server. The matchbox window manager is still running. If you want to play with delays, you need to add them after xinit has exited in the /lib/systemd/drakx-installer-setup script.

(In reply to Thomas Andrews from comment #183)
> Took me a while, but here are some results:
> 
> 32-bit Xfce will not boot using rEFInd the way I have it configured, so it
> wasn't tested.

Yes, sadly rEFInd doesn't support mixed 32/64 bit boot.

> All other three DEs acted the same. Booting without the nvidia drivers went
> normally, plymouth, questions, functioning desktop. 
> 
> Booting with nvidia drivers went into a text screen, as if esc had been
> pressed while in plymouth, and indeed, pressing esc showed the infamous
> three boxes of plymouth text mode.

Yes, I removed "splash" from the boot command line when booting with the proprietary drivers as we know it doesn't work.

> Boot proceeded, building and installing
> nvidia driver, and in the end sent me to a functioning desktop, skipping the
> questions.

Darn!

> And one final thing, remembered from something either in the qa-discuss ML
> or on the pad. I believe it's probably related, or I would not bring it up
> here: 
> 
> Booting to install Mageia without nvidia drivers proceeds normally, to
> finish at the installer. Booting with the nvidia drivers builds the drivers
> the same as booting into Live mode, but when finished takes you to the
> Plasma, Gnome, or Xfce desktop, instead of the installer.(There may be a bug
> on this. I didn't find it with a quick search.)

Yes, that's this bug. The drakx-installer-setup process is responsible for running the installer after it has asked the usual questions, but if it fails before it gets there, the system will just go on to starting the DM.

This seems an unlikely culprit, but could someone try booting one of the 64-bit trial-builds ISOs (any one will do), selecting to use the proprietary drivers and editing the boot command line to add

  rd.driver.blacklist=mxm-wmi

(In reply to Martin Whitaker from comment #180)
> There's a new set of beta1 Live ISOs in the trial-builds directory on the
> pre-release rsync server. Please test.

Hi
1)
I have tried to use RSYNC 
I got this answer :
rsync: [sender] link_stat "/Mageia-10-beta1-Live-Plasma-x86_64" (in isos) failed: No such file or directory (2)

What is the real name of this set of beta1 Live ISOs ?

2)
Besides this :
 in comment 170 and comment 171 I have tested beta0g Plasma using Nvidia with persistent partition : 
- The first boot gives a bad result after a very long time

- But the second boot gives a perfect result (less than 4 minutes, Plymouth, PLasma OK,)   It seems that every configuration or built driver or installed rpms that has been stored on the persistent partition from the first boot is used in the good order This Plasma is then perfectly usable


The length of the first boot seems to be caused and explained by a relentless back and forth from reading to writing on the pendrive (lots of little files are created and lots of files are modified over time particularly in the /var/log/ folder)

@Martin: I used Xfce, because it was the one that came to hand. Unfortunately, there was no difference. 

@Philippe: I used mageiasync, with "trial-builds" as the release, and I downloaded fresh, full copies to a different destination than the original beta1 downloads on my computer. The password is the same.

(In reply to Thomas Andrews from comment #187)

> 
> @Philippe: I used mageiasync, with "trial-builds" as the release, and I
> downloaded fresh, full copies to a different destination than the original
> beta1 downloads on my computer. The password is the same.

Thanks
I found it

I have just tested this last beta1 plasma with nvidia (without persistent partition) and with two monitors

The boot took 4 minutes

No Plymouth but the text displayed is now very much clearer : all the steps are clearly detailed (same as when clicking on ESC when Plymouth appears in Mageia9)

One little warning during this boot:
landlock is disabled but requested
You should enable landlock at boot time

But finish-install is not used (no choice of language, no need to accept the licence, no choice for Time reference,  local hour, and keyboard )

and Plasma is immediately starting :
- the symbol showing that Plasma is loading is cloned on the two monitors over Mageia background
- then Plasma starts spread on the two monitors and it works perfectly 
but it's  in English with a qwerty keyboard
- I can launch any program with Mageia Menu and can stop it from its window or with its name in the bottom taskbar
- Power Off button from the Menu stops the computer

Two problems :
- No Plymouth but this allows to clearly display all the steps of the boot and prevent to think that the computer is frozen when you remain on plymouth without explanation  
Indeed This might be better not to have Plymouth and it's a minor problem
- the finish-install step is totally skipped

(In reply to Martin Whitaker from comment #179)

> (In reply to Giuseppe Ghibò from comment #178)
> > We already tested this deeply between 0b and 0c, where this was the only and
> > single difference and with nouveau.ko preloaded ALL the tests were failing,
> > while with it excluded it worked with nouveau driver flawlessly very well,
> > but also with nvidia.
> > 
> > IMHO is not something tied to the preloading of it, but there could be
> > something in the scripts detecting its presence somewhere by some parsing.
> 
> Then we have to find out what that is. I'm sorry, but I'm not going to
> reintroduce a bug that affects using the free drivers in order to support
> using the proprietary drivers.

I've dug deeper. It seems that removing nouveau.ko from the draklive-config's  file/dracut-live.conf doesn't actually have any effect nouveau.ko is included in the initramfs image regardless of whether it's added to dracut-live.conf or not. I'm running some further tests, but my internet connection is currently down due to a provider infrastructure fault and I'm waiting for it to be fixed. Hope to have some news soon.

(In reply to Martin Whitaker from comment #174)

> I'll also note that the packages x11-driver-video-nvidia-current and
> x11-driver-video-nvidia-current-wopengpu are largely comprised of the same
> files. Including both on the ISO will add a needless extra 300MB to the ISO
> size. The common files should be split out into a separate package.

I'm trying to split it.

(In reply to Martin Whitaker from comment #184)
> (In reply to Giuseppe Ghibò from comment #182)
> ..
> > There may be other resources released later. A test could involve
> > introducing a "delay" just after the first X server closes, following the
> > "wizardwindow->destroy" call. 
> 
> That does not close the X server. The matchbox window manager is still
> running. If you want to play with delays, you need to add them after xinit
> has exited in the /lib/systemd/drakx-installer-setup script.

looking to it. I was thinking to add a configurable parameter to be parsed at cmdline, like dm_startup_delay=... from 0 to 45s (default = 0), e.g. to be added there.

(In reply to Giuseppe Ghibò from comment #190)

> [...]
> I've dug deeper. It seems that removing nouveau.ko from the
> draklive-config's  file/dracut-live.conf doesn't actually have any effect
> nouveau.ko is included in the initramfs image regardless of whether it's

meaning that we can leave where it is.

Latest testing reveals that beyond the other bugs fixed, defaulting to the "Plasma(Wayland)" session introduces a subtle but significant usability issue: while the driver build correctly, the initial configuration steps, like language selection, EULA acceptance, timezone, and keyboard layout are completely bypassed: the Plasma Wayland desktop is immediately presented using default English settings, keyboard, etc., and the EULA isn't displayed until after the first logout.

To avoid such problem at startup it's recommended to keep the 'Plasma(X11)' as the default (i.e. 'Plasma' => 'Plasma(X11)' in %default_sessions) and not 'Plasma(Wayland). This ensures the correct configuration, allowing users to select the preferred language, EULA acceptance, timezone, and keyboard layout, before the Plasma desktop loads in X11. Once started, just logging out, correctly displays the SDDM greeter, allowing to choose between different sessions, including Plasma(Wayland), and all of them are working flawlessly.

(In reply to Giuseppe Ghibò from comment #194)
> Latest testing reveals that beyond the other bugs fixed, defaulting to the
> "Plasma(Wayland)" session introduces a subtle but significant usability
> issue: while the driver build correctly, the initial configuration steps,
> like language selection, EULA acceptance, timezone, and keyboard layout are
> completely bypassed: the Plasma Wayland desktop is immediately presented
> using default English settings, keyboard, etc., and the EULA isn't displayed
> until after the first logout.

This analysis can't be right for two reasons:

1. The default session only affects the Autologin Session setting in the SDDM configuration file. The initial configuration steps are run before SDDM is started, so can't be affected by that.

2. TJ tested all three 64-bit Live ISOs. The initial configuration was skipped on all three. The default session type for Plasma is not used in the GNOME and Xfce ISO builds.

In nvidia-test, there are 3 new ISOs for NVidia:

1) Mageia-10-beta1w-Live-GNOME-x86_64
2) Mageia-10-beta1w-Live-Plasma-x86_64
3) Mageia-10-beta1x-Live-Plasma-x86_64

The first is for GNOME, the second is for Plasma with a Wayland desktop session as default, and the third is the same as the second, but with an X11 desktop session as default.

All three have been tested and should work with NVidia without the previous problems.

Hi Giuseppe
I have isodumper to create two pendrives without persistent partition :
Mageia-10-beta1w-Live-Plasma-x86_64
Mageia-10-beta1x-Live-Plasma-x86_64

For each of them I got this warning in the end of isodumper job :
The computed and stored sums don't match

But that doesn't prevent them to work

1) Test of Mageia-10-beta1x-Live-Plasma-x86_64 with Nvidia driver

a) with one monitor :
- no plymouth but all the steps are clearly displayed on a black background (installing rpms, building driver, installing driver)
- finish_install is correctly displayed
- Plasma works perfectly (windows with frame, menu usable, power-off button stops the computer)

b) with two monitors
- no plymouth but all the steps are clearly displayed on a black background (installing rpms, building driver, installing driver)
- finish_install is correctly displayed : cloned on the two monitors
- Plasma is spread on the two monitors but the Mageia-Welcome and the taskbar are displayed only on the left monitor
- No problem to get the second monitor as a clone of the primary using Plasma Settings
- Plasma works perfectly (windows with frame, menu usable, power-off button stops the computer)

2) Test of Mageia-10-beta1w-Live-Plasma-x86_64 with Nvidia driver

a) with one monitor :
- no plymouth but all the steps are clearly displayed on a black background (installing rpms, building driver, installing driver)
NOTA BENE a warning appears in the beginning :
       You should enable landlock
- finish_install is correctly displayed
- Plasma works perfectly (windows with frame, menu usable, power-off button stops the computer)

b) with two monitors
- no plymouth but all the steps are clearly displayed on a black background (installing rpms, building driver, installing driver)
NOTA BENE a warning appears in the beginning :
       You should enable landlock
- finish_install is correctly displayed : cloned on the two monitors
- Plasma is spread on the two monitors but the Mageia-Welcome appears on the right monitor and  the taskbar is displayed on the left monitor
- No problem to get the second monitor as a clone of the primary using Plasma Settings
- Plasma works perfectly (windows with frame, menu usable, power-off button stops the computer)

To conclude : 
this is perfect with X or Wayland (5 minutes to boot)
The only remaining problem is that there's no Plymouth  but I really think it's worth not having plymouth : we can clearly see what is going on and we cannot think the process is frozen 
(Plymouth might offer quite the same screen without clear explanation )

Great job indeed !
This should be proposed for users

If some bugs appear for Plasma itself they might not be caused by Nvidia driver

Post Scriptum
I am not familiar with Gnome
I didn't test the live for Gnome letting this test for Gnome users

Let me recheck the signatures...

For the signatures, which signatures isodumper checks? however I just tried all the three signatures provided:

$ md5sum -c Mageia-10-beta1w-Live-GNOME-x86_64.iso.md5;sha3-512sum -c Mageia-10-beta1w-Live-GNOME-x86_64.iso.sha3;sha512sum -c Mageia-10-beta1w-Live-GNOME-x86_64.iso.sha512

Mageia-10-beta1w-Live-GNOME-x86_64.iso: OK
Mageia-10-beta1w-Live-GNOME-x86_64.iso: OK
Mageia-10-beta1w-Live-GNOME-x86_64.iso: OK

$ md5sum -c Mageia-10-beta1w-Live-Plasma-x86_64.iso.md5;sha3-512sum -c Mageia-10-beta1w-Live-Plasma-x86_64.iso.sha3;sha512sum -c Mageia-10-beta1w-Live-Plasma-x86_64.iso.sha512

Mageia-10-beta1w-Live-Plasma-x86_64.iso: OK
Mageia-10-beta1w-Live-Plasma-x86_64.iso: OK
Mageia-10-beta1w-Live-Plasma-x86_64.iso: OK

$ md5sum -c Mageia-10-beta1x-Live-Plasma-x86_64.iso.md5;sha3-512sum -c Mageia-10-beta1x-Live-Plasma-x86_64.iso.sha3;sha512sum -c Mageia-10-beta1x-Live-Plasma-x86_64.iso.sha512 

Mageia-10-beta1x-Live-Plasma-x86_64.iso: OK
Mageia-10-beta1x-Live-Plasma-x86_64.iso: OK
Mageia-10-beta1x-Live-Plasma-x86_64.iso: OK

e.g. md5:
9eba80ac3bbfccbd47c2d197c4bb93ca  Mageia-10-beta1w-Live-Plasma-x86_64.iso
b2739fa64dce68e3abf7a7c1cb5943c8  Mageia-10-beta1x-Live-Plasma-x86_64.iso

Hi Giuseppe
I don't know why Isodumper-QT gave the warning :
"The computed and stored sums don't match"

That's the first time this happens (I have used Isodumper-QT dozens of times )

The sha512 and sha3 files are in the same folder as the iso file in both of cases

Maybe a problem of Isodumper-QT  itself

Nevertheless the pendrives work perfectly that's the main thing to know
(my opinion is that the absence of Plymouth is not important )

You may communicate the good results for X or Wayland to Martin who thought no more providing Nvidia drivers for the Live Isos

Created attachment 15469 [details]
draklive-config diffs

draklive-config diff file.

Changes:

- config/build.cfg:
  - re-enabled nvidia menus
  - added support for magic-sysrq that was disabled in late systemd (bug #35116)
  - extra utils are for local testing without enabling media and networking to download them (you may not add them).

- files/50gdm-disable-wayland.xsetup:
  - don't disable wayland anymore when nokmsboot (nvidia) is used, as it's supported now (keep the 'nowayland' as it was).

(In reply to Philippe Didier from comment #201)

> Hi Giuseppe
> I don't know why Isodumper-QT gave the warning :
> "The computed and stored sums don't match"
> 
> That's the first time this happens (I have used Isodumper-QT dozens of times
> )
> 
> The sha512 and sha3 files are in the same folder as the iso file in both of
> cases
> 

yes, then you might check against them manually as in the commands above. Ensure you have dowloaded also the correct .md5, .sha3 and .sha512 files.

> Maybe a problem of Isodumper-QT  itself
> 
> Nevertheless the pendrives work perfectly that's the main thing to know
> (my opinion is that the absence of Plymouth is not important )
> 
> You may communicate the good results for X or Wayland to Martin who thought
> no more providing Nvidia drivers for the Live Isos

just written on dev@ml

Mageiasync says all three failed the "sh3-512" checksum, yet dorsync says all three passed all three sum checks. 

I don't know where the difference is, but Mageiasync is always OK with Martin's checksums, but more often than not yours fail.

(In reply to Thomas Andrews from comment #204)

> Mageiasync says all three failed the "sh3-512" checksum, yet dorsync says
> all three passed all three sum checks. 
> 
> I don't know where the difference is, but Mageiasync is always OK with
> Martin's checksums, but more often than not yours fail.

So, there is a mismatch between the checksums from Mageiasync and dorsync? Do we need to check the checksums of the checksums?

I have checked all three with the nvidia drivers, without persistence, and all three seem to work as they should as far as I went. I'm not a Gnome user either, but I have used it enough to know when I see distortions, sluggishness, or crashes. The gnome-2048 game on the Gnome iso did crash, but as it does the same thing without the nvidia drivers I don't think they are the cause.

But they aren't done yet. What about Xfce? Both arches? I'll admit there have been so many test isos that I've lost track, but the last I knew, when the proprietary drivers were loaded, the 64-bit iso skipped the questions, as well.

The proprietary drivers aren't available for 32-bit, so only the 64-bit Xfce needs testing. But we also need to know whether this now works with persistence enabled.

(In reply to Thomas Andrews from comment #206)

> I have checked all three with the nvidia drivers, without persistence, and
> all three seem to work as they should as far as I went. I'm not a Gnome user
> either, but I have used it enough to know when I see distortions,
> sluggishness, or crashes. The gnome-2048 game on the Gnome iso did crash,
> but as it does the same thing without the nvidia drivers I don't think they
> are the cause.
> 
> But they aren't done yet. What about Xfce? Both arches? I'll admit there
> have been so many test isos that I've lost track, but the last I knew, when
> the proprietary drivers were loaded, the 64-bit iso skipped the questions,
> as well.

I did some cleanup locally. I've only added the 64-bit ISOs, as the Nvidia drivers currently cover only 64-bit architectures. For Xfce, I just added

Mageia-10-beta1w-Live-Xfce-x86_64/

to the nvidia-test area, where you can download it from the same source/zone as before. md5/sha512/sha3-512 checksums were checked.

I had to do some cleanup locally. I've added only the 64-bit ISOs as the nvidia-drivers cover only 64bit.

I've left glmark2, vkmark, glxgears, vkcube and glxsphres, for testing, should you want to use them.

1) Test of Mageia-10-beta1x-Live-Plasma-x86_64.iso with persistent partition and Nvidia driver

22 minutes before having a working Plasma : lot of time spent to read from or write to the pendrive
every step is OK (finish_install is done)

NB it took 5 minutes without a persistent partition

Plasma is slowly responsive
power off works

2) a second test with this same pendrive (persistent partition has been filled)
 5 minutes before a working Plasma
But Plasma is slowly responsive (needing lot of accesses to the persistent partition)

to conclude
I can only recommend not to use a persistent partition !!!

The Live Iso is supposed to test and demonstrate if Mageia10 can be used on a computer, if its devices are recognized and if the main programs that Mageia proposes work...
Without a persistent partition the ISO does what it is supposed to do

Post scriptum
I didn't test an Iso with free driver and persistent partition

I think that's the performance of the overlayfs over a USB pendrive, not related to the graphics driver. Usually pendrive has a good transfer rate over sequential access, but might have a poor performance on random write at 4k blocks.

You might try a speed test using kdiskmark (to be installed as it's not included in the ISO anymore), but it writes large data on it.

Which model of pendrive are you using?

It could also be a characteristic of Plasma. It isn't exactly a "light" DE. Philippe didn't test persistence with anything else.

Xfce Live, both with and without persistent partition, using new usb 2.0 8GB flash drives.:

Booted with nvidia drivers, and without persistence. Boot went well, acting about the same as the others.

The first boot with nvidia and with persistence took approximately 20 minutes. Not much of a surprise, as the LED indicated a lot of activity on the usb drive. Once the activity stopped, I used MCC to add the Princeton mirror and checked for updates. There were none. Then I closed MCC, opened the file manager, and played a video from my computer's hard drive in Parole. IT played normally, no skips or buffering that I could see. In fact, while things were slower than when using my desktop's NVME drives, it wasn't annoyingly so.

I shut it down, then did another boot. This one took around two minutes, and once up was just as responsive as the first boot, if not more so.

It's almost my bed time now. I'll try the Plasma isos with persistence tomorrow. I have a hunch that the secret may be that we just have to be patient on that first boot, and give Plasma plenty of time to fully come up before trying to use it, and I'd bet that if that is done the second and subsequent boots would only take 2-3 minutes, as they do with Xfce.

(In reply to Philippe Didier from comment #209)
> The Live Iso is supposed to test and demonstrate if Mageia10 can be used on
> a computer, if its devices are recognized and if the main programs that
> Mageia proposes work...

That's one of its uses. Another is as a rescue system (easier to use than the rescue system on the classic installer ISOs). For that, having persistence allows the user to easily add a few extra tools.

(In reply to Philippe Didier from comment #197)

> NOTA BENE a warning appears in the beginning :
>        You should enable landlock

to enable landlock and get rid of those messages you might add at boot cmdline (editing at grub) the entry "lsm=landlock".

(In reply to Thomas Andrews from comment #213)

> It's almost my bed time now. I'll try the Plasma isos with persistence
> tomorrow. I have a hunch that the secret may be that we just have to be
> patient on that first boot, and give Plasma plenty of time to fully come up
> before trying to use it, and I'd bet that if that is done the second and
> subsequent boots would only take 2-3 minutes, as they do with Xfce.

Your intuition is probably correct. The slowdown can be due to the pendrive itself. I have, for instance, a USB 3.0 pendrive that could exceeds 350-400 MB/s on sequential transfer rates for large files (both reading and writing), but when writing a standard OS (any OS, even non-Linux distros) to it using 4 KB blocks, its transfer rate drops to 0.001 MB/s, making it almost unusable. This is visible when performing benchmarks with tools like fio or kdiskmark.

Regarding persistence, IIRC, we have a squashfs partition (compressed with zstd, which should offer one of the best uncompression rates) combined with a real partition on the pendrive used through overlayfs for writing data. When you start Plasma (or any other desktop environment), it begins writing to $HOME/.config, creating thousands of files for configuration, themes, menus, etc. These files are created in $HOME the first time you log in, so it takes a considerable amount of time because it has to write directly to disk (at a slow rate). On a standard boot (without persistence), this is combined with an overlayfs on a tmpfs, which is in RAM, so it doesn't have to write anything to pendrive.

To speed things up, especially for slower pendrives, we could probably use two kinds of overlayfs partitions. As far as I remember, this could be done with some tweaking at boot time and maybe some extra script. For example, we could have an overlayfs partition only for /home in a ramdisk/tmpfs, and a real persistent partition for / with overlayfs, on the disk. In this case, the persistent partition on disk would be used for updating the system, but /home for writing would be in scratch (recreated at every boot), and boot could be slightly faster. /var remains on disk, as it's written to by logs and cache files, but maybe it could be moved to an overlayfs in a ramdisk too.

(In reply to Martin Whitaker from comment #214)

> (In reply to Philippe Didier from comment #209)
> > The Live Iso is supposed to test and demonstrate if Mageia10 can be used on
> > a computer, if its devices are recognized and if the main programs that
> > Mageia proposes work...
> 
> That's one of its uses. Another is as a rescue system (easier to use than
> the rescue system on the classic installer ISOs). For that, having
> persistence allows the user to easily add a few extra tools.

And that's pretty cool.

(In reply to Martin Whitaker from comment #214)
> (In reply to Philippe Didier from comment #209)
> > The Live Iso is supposed to test and demonstrate if Mageia10 can be used on
> > a computer, if its devices are recognized and if the main programs that
> > Mageia proposes work...
> 
> That's one of its uses. Another is as a rescue system (easier to use than
> the rescue system on the classic installer ISOs). For that, having
> persistence allows the user to easily add a few extra tools.

My most recent use of a Live was when the ssd in my laptop started to fail. I connected the replacement via usb, used gparted to partition/format it, and then copied the data from /home partitions that were still good. Using gparted from a Live was easier than trying to get a Live gparted to boot with rEFInd, and all the tools I needed were right there on the Mageia Live, anyway.

I've built a new set of beta1 ISOs which can be found in the trial-builds directory. Please test the 64-bit Live ISOs to check that they work correctly when using the NVIDIA proprietary drivers.

Well it took a while, but I have tested all three, both without and with persistence. All thre seem to be working as they should, providing each is given enough time to "settle" on the first boot with nvidia drivers and persistence. It appears that the Live systems, with persistence, don't multitask well, so if you, say, ask one to start an app while it is writing a config file somewhere, it will be very sluggish.

Specific times, from the grub menu to when the desktop is ready to use, including answering questions with the defaults:

Plasma:
No persistence - 7.5 minutes
1st boot w/persistence - 29 minutes
2nd boot w/persistence - 2 minutes

Gnome:
No persistence - 6 minutes, 40 seconds
1st boot w/persistence - 27 minutes 
2nd boot w/persistence - 2 minutes, 15 seconds

Xfce:
No persistence - 6 minutes, 30 seconds
1st boot w/persistence - 21 minutes
2nd boot w/persistence - 1 minute,45 seconds

This is with isos dumped with Isodumper to the cheapest 8GB usb 2.0 flash drives I could find on Amazon. Better quality , usb 3.0 drives would probably be faster.

And one last test, done with the Plasma Live without persistence: When selecting install with nvidia drivers from the grub menu, once the driver is built and the questions asked and answered, the installer is started, as it should be. I did not go through with an actual install, however, because my eyes are getting squirrelly.

Thanks for all the testing TJ. What's your opinion - should we push these out to QA or stick with what we've got? I'm concerned about overloading our small testing team.

(In reply to Giuseppe Ghibò from comment #217)
> (In reply to Martin Whitaker from comment #214)
> 
> > (In reply to Philippe Didier from comment #209)
> > > The Live Iso is supposed to test and demonstrate if Mageia10 can be used on
> > > a computer, if its devices are recognized and if the main programs that
> > > Mageia proposes work...
> > 
> > That's one of its uses. Another is as a rescue system (easier to use than
> > the rescue system on the classic installer ISOs). For that, having
> > persistence allows the user to easily add a few extra tools.
> 
> And that's pretty cool.

Persistence also allows to update the stick to update compatibility (for example new kernel - even backport 6.18 runs on mga9 Live with persistence)

(In reply to Martin Whitaker from comment #221)
> Thanks for all the testing TJ. What's your opinion - should we push these
> out to QA or stick with what we've got? I'm concerned about overloading our
> small testing team.

If there isn't much difference between these and the round 2 Lives you already sent to QA (other than the nvidia stuff), go ahead and push them out. They should only need minimal testing in addition to my tests and what's already been done for round 2.

OK. There's between 60 and 80 updated packages on each one (not counting the firefox language packages) which doesn't seem too bad, although it does include new kernel and firmware.

Hi

Tested last Beta1 iso for Plasma from March 7th with two monitors
2 pendrives created with Isodumper (no warning about a bad sum) 

1)
No persistent partition, Plasma, Nvidia proprietary driver

- No plymouth screen with pot and bubbles, but the steps are displayed on a black background
- install rpms takes around 1 minute and 30 seconds
- build modules takes around 2 minutes
- install modules and the x11 rpms for nvidia takes 1 minute
- finish_install is cloned on the two monitors
- plasma appears quickly with Mageia Welcome on the right monitor
- plasma-settings allows to get the right monitor as a clone of the primary 
- every device is recognized out of the box (wacom tablet, sound card, ethernet)
- the HP printer can be installed 
Launching application is fast

Booting from the pendrive takes 5 minutes before having a working Plasma (fast responsive)

2)
First boot with persistent partition for Plasma Nvidia proprietary driver
- install rpms takes around 2 minutes
- build modules takes around 5 minutes
- install modules takes 7 minutes
-  install the x11 rpms for nvidia-current takes 2 minutes
- then finish_install appears and is cloned on the two monitors
- 2 minutes before a black background fills the two monitors and  Mageia Welcome appears on the right monitor
- 2 minutes again before Plasma is correctly displayed
- plasma-settings allows to get the right monitor as a clone of the primary 
but it is very slowly responsive
- launching Firefox or LibreOffice takes more the 1 minute

Booting with this pendrive takes 20 minutes and we get a very slow Plasma (the led of the pendrive is incessantly flashing)

3)
Second boot with persistent partition for Plasma Nvidia proprietary driver
The persistent partition has been filled during the first boot
- boot to Plasma takes 5 minutes (all the previous settings are preserved)
But Plasma is as slow as after the first boot : we may think it is frozen for more than 1 minute when we launch any program : its window appears lately and is slowly filled (particularly for Firefox when the first welcome content is downloaded ...)


To conclude
 Persistent partition is not really usable : this is not linked to Nvidia itself but to the fact that a pendrive is incessantly solicited for writing or reading data

Post Scriptum 
About HP printer
 https://bugs.mageia.org/show_bug.cgi?id=31623 is still present : 
There's always an incompatibility between HP Toolbox and the presence of ipp-usb :
if ipp-usb is installed HP toolbox can't communicate with the printer
(I have chosen to install the proposed hplip driver for HP the printer)

The errata created about this for Mageia9 is still valid for Mageia10

I believe that is only for usb-connected printers, and of those only the ones that are capable of using "driverless" printing and scanning. My own theory, not supported by any known evidence, is tha cups is set up to prefer working with driverless operation, rather than the older hplip.

I have two working HP printers, one with a scanner. The one with a scanner had issues with scanning if connected via usb (bug 31222) but works perfectly with hplip after being connected to my network via wifi. My Laserjet, connected via Ethernet, is equally usable. Both appear in the HP toolbox, but more extensive information for each is accessible through their embedded websites.

(In reply to Thomas Andrews from comment #227)
> I believe that is only for usb-connected printers, and of those only the
> ones that are capable of using "driverless" printing and scanning. My own
> theory, not supported by any known evidence, is tha cups is set up to prefer
> working with driverless operation, rather than the older hplip.
> 
No : Cups proposes the choice between hplip drivers and driverless usb printers
But choosing hplip doesn't allow HP-toolbox to communicate with the printer if ipp-usb is installed
hp-toolbox offers many more options than a driverless use

> I have two working HP printers, one with a scanner. The one with a scanner
> had issues with scanning if connected via usb (bug 31222) but works
> perfectly with hplip after being connected to my network via wifi. My
> Laserjet, connected via Ethernet, is equally usable. Both appear in the HP
> toolbox, but more extensive information for each is accessible through their
> embedded websites.

Hi
To understand the effect of a persistent partition I have used a pendrive freshly created with isodumper with the last Beta1 Plasma iso (round 3)

1)
I boot with the nouveau driver (default booting proposed) on a computer with two monitors like in comment 225
It takes 3 minutes to reach the finish_install step : its windows are split in the middle of a screen spread over the 2 monitors
(and not cloned on the two monitors like with Nvidia driver)

Plasma appears on a screen spread over the two monitors :
Mageia Welcome on the right monitor the task bar on the left monitor

Plasma-settings is very slow to start but allows to get the second monitor as a clone of the primary (the led of the pendrive is ceaseless flashing

Firefox is very slow to start and to display the content of the two initial tabs
Launching any program takes a long time

Power off is slow

2)
Second boot with this pendrive : its persistent partition has been filled during the first boot
Ok : 
- no more finish-install step
-the monitors are cloned
But :
Plasma is slowly responsive, like after the first boot : launching Firefox MCC (or any other program takes a long time
The pendrive doesn't stop flashing 


To conclude :
Whichever driver we use (Nvidia or nouveau) the persistent partition induces the same behaviour : it slows down dramatically the running of Plasma


- When there is no persistent partition, everything is written and stored inside the computer memory (wide enough for this purpose) that allows a quick access.

- When there's a persistent partition this partition is ceaseless used for write and read accesses : quite nothing is temporarily stored in the computer memory before being saved on the persistent partition 
It looks like this partition is used as a RAM instead of using the own RAM of the computer!

Two basic things are different in my tests:

1) I only use one monitor. 

2) I waited until the drive LED stopped flashing before I tried using anything on that first boot, even though the screen looked like it was ready to work, and after making changes in system settings I waited until the LED stopped flashing before I shut the system down.

My drive was USB 2, even though I was using it in a USB 3 port. I would not expect that to be as responsive as my systems that are installed on the system drives, or even as responsive as a USB3 drive, but making allowances for the hardware capability I wouldn't term the second boot of my tests as "sluggish." In addition, the LED did not flash nearly as much during the second boot, but then I didn't try to do much that would be taxing of the system.


I guess my expectations for using a Live iso are lower than yours. It started when I tried Knoppix years ago to fix some problem or another, from a DVD. Usable to fix the problem, but barely. 

People kept telling me that a Live version of a distro would give me an idea of how that distro worked, but NONE of them had the same feel as the distro on my hard drive, and that's because of the limitations of the hardware. They have their uses, but I have never found getting an idea of the "feel" of a distro to be one of them.

A few notes. In the end, what model of USB drive are you using? Does it support USB3, and especially does it support UASP? Have you run any benchmarks on it, for example with kdiskmark (see https://wiki.mageia.org/en/Testing_storage_speed)?

Last but not least, you aren't required to use a USB flash drive; you can also use any external USB disk for the ISO+persistence, even a mechanical one, which should provide higher performance.

To find out which driver the device is using, "lsusb -vt" will show the port speed and the driver in use (e.g. xhci_hcd, ehci_hcd, or uhci_hcd).

Also, what filesystem are you using for the persistent partition? f2fs or ext4 or other? IIRC, it only needs to be labeled "mgalive-persist", but it can be any supported filesystem. You can experiment more than one.

I have opened a bug specifically for the problem induced by a persistent partition
https://bugs.mageia.org/show_bug.cgi?id=35196

The pendrive is an USB3 pendrive

"lsusb -vt" gives this
 Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
        ID 346d:5678  

The persistent partition is always "mgalive-persist" nothing else

I will attach the result of KDiskMark

Created attachment 15476 [details]
result of kdiskmark

result of KDiskMark for the used pendrive to test isos

Yes, write 4 kB blocks is in the order of 0.2-0.3 MB/s.

(In reply to Thomas Andrews from comment #230)

> I guess my expectations for using a Live iso are lower than yours. It
> started when I tried Knoppix years ago to fix some problem or another, from
> a DVD. Usable to fix the problem, but barely. 

IIRC knoppix had an option (it was ramdisk IIRC), that allow to copy the entire disc to ramdrive before booting. But at that time it was a CD size so 700MB at most.

> 
> People kept telling me that a Live version of a distro would give me an idea
> of how that distro worked, but NONE of them had the same feel as the distro
> on my hard drive, and that's because of the limitations of the hardware.
> They have their uses, but I have never found getting an idea of the "feel"
> of a distro to be one of them.

Mostly depends on the pendrive. There are pendrive with DRAM cache and performance closer to those of a SSD. Alternatively also an external SSD pocket drive could be used.

The nice live system https://www.system-rescue.org/ also can load all onto RAM and you can then remove the USB stick/DVD. 

That Comment 234 stick is terribly slow.
four? yeas ago i documented some tests here
https://wiki.mageia.org/en/Storage_speed_test_results

At https://wiki.mageia.org/en/Talk:Persistent_live_systems we discuss some trick to enhance speed for certain app (i.e firefox) that do much file access, by making it use RAM instead also when we have persistence.

Another ide i have but no time to try is to use a btrfs persistence partition, with compression, in order to reduce bandwidth on the USB connection.

Hi Morgan
most of the pendrives have very bad speed for writing small blocks
see https://bugs.mageia.org/show_bug.cgi?id=35196#c2

Nevertheless without a persistent partition the last Beta1 Plasma round3 is quite perfect with Nvidia or nouveau

thanks to Giuseppe (who choosed to persevere rather than giving up with Nvidia driver) and to Martin who applied what was found

Hi

All that I wrote about problems with persistent partition can be ignored : it's not linked to the persistent partition itself !!!

Indeed it was caused by the fact that my USB3  pendrives are too slow !
A fast USB pendrive is absolutely needed !!!
It's not so easy to know which are good since their write or read speed for little files is quite never specified !

You may find here an usb pendrive tester (that I should have consulted before buying them !)
https://ssd-tester.com/top_usb_sticks.php

On top of that, if you are going to be using the drive a lot over time, you are going to want to get an industrial-grade drive with wear-leveling. 

Most consumer-grade drives, the kind many of us buy because of price, don't have wear leveling, and consequently will fail quicker under heavy use.

(In reply to Thomas Andrews from comment #240)
> On top of that, if you are going to be using the drive a lot over time, you
> are going to want to get an industrial-grade drive with wear-leveling. 
> 
> Most consumer-grade drives, the kind many of us buy because of price, don't
> have wear leveling, and consequently will fail quicker under heavy use.

Exactly.

There's also another marketing metric called "terabytes written" (TBW), which essentially indicates endurance. Pendrives usually don't publish these values, but they are generally a lot lower than those of interal (or external) SSDs.

Some USB flash drives (though rare) have a DRAM cache, which significantly improves performance.

However, as I mentioned, sometimes a portable (pocket) external SSD disk is more convenient. They are similar in size to largest flash drives and are very 
lightweight. They usually come with a short USB cable (Type A or Type C), typically 10-15 centimeters long. These portable SSDs perform 
close to, and sometimes even faster than SATA SSDs (they are in USB3.2Gen2 and USB3.2Gen2x2, and sometimes compatible with USB4). If you have a bootable Thunderbolt port, you can also use a portable Thunderbolt SSD external portale disk (NVMe), which can achieve speeds comparable to the fastest internal NVMe drives, around 40 Gbps.

Does anyone have a card in the Ampere or Blackwell architecture (e.g. RTX30x0, RTX40x0, RTX50x0)? There's a new set of ISOs for them (in the same place as before, under "nvidia-test"):

Mageia-10-beta1w-Live-Plasma-x86_64/
Mageia-10-beta1w-Live-Xfce-x86_64/

The "DATE.txt" file should be of 2026-03-18.

With them, there's an extra boot menu called "nonfree NVIDIA drivers (fastboot)" which allows these architectures to boot faster, using prebuilt opengpu 
modules, without dkms building them. It's not immediate, but reduces the desktop build/startup time to 8-10 seconds, instead of minutes.

Hi

You can ignore what I have previously written about the problems brought by  a persistent partition...

All this was caused by a bad USB pendrive : the test by KDiskMark showed these bad results
                       KDiskMark (3.1.2): https://github.com/JonMagon/KDiskMark
                    Flexible I/O Tester (fio-3.33): https://github.com/axboe/fio
--------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
Sequential   1 MiB (Q=  8, T= 1):   144.781 MB/s [    141.4 IOPS] < 56368.05 us>
Sequential   1 MiB (Q=  1, T= 1):   142.759 MB/s [    139.4 IOPS] <  7166.08 us>
    Random   4 KiB (Q= 32, T= 1):     5.104 MB/s [   1276.2 IOPS] < 25005.45 us>
    Random   4 KiB (Q=  1, T= 1):     4.668 MB/s [   1167.0 IOPS] <   850.26 us>

[Write]
Sequential   1 MiB (Q=  8, T= 1):    39.349 MB/s [     38.4 IOPS] < 194036.84 us>
Sequential   1 MiB (Q=  1, T= 1):    36.035 MB/s [     35.2 IOPS] < 26357.67 us>
   Random   4 KiB (Q= 32, T= 1):     0.354 MB/s [     88.5 IOPS] < 434384.66 us>
    Random   4 KiB (Q=  1, T= 1):     0.237 MB/s [     59.3 IOPS] < 16868.44 us>

Profile: Default
   Test: 1 GiB (x5) [Measure: 5 sec / Interval: 5 sec]
   Date: 2026-03-11 17:56:17
     OS: mageia 9 [linux 6.6.120-desktop-1.mga9]


I have bought a Transcend JetFlash 780 (32 GB USB 3.1)
Its test with KDiskMark gives this :

                       KDiskMark (3.1.2): https://github.com/JonMagon/KDiskMark
                    Flexible I/O Tester (fio-3.33): https://github.com/axboe/fio
--------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
Sequential   1 MiB (Q=  8, T= 1):   528.316 MB/s [    515.9 IOPS] < 15466.71 us>
Sequential   1 MiB (Q=  1, T= 1):   466.780 MB/s [    455.8 IOPS] <  2187.18 us>
    Random   4 KiB (Q= 32, T= 1):   144.907 MB/s [  36226.9 IOPS] <   979.29 us>
    Random   4 KiB (Q=  1, T= 1):    28.500 MB/s [   7125.1 IOPS] <   141.36 us>

[Write]
Sequential   1 MiB (Q=  8, T= 1):   465.787 MB/s [    454.9 IOPS] < 16694.60 us>
Sequential   1 MiB (Q=  1, T= 1):   304.584 MB/s [    297.4 IOPS] <  2480.23 us>
    Random   4 KiB (Q= 32, T= 1):   169.455 MB/s [  42363.8 IOPS] <  1985.44 us>
    Random   4 KiB (Q=  1, T= 1):    55.573 MB/s [  13893.3 IOPS] <    79.54 us>

Profile: Default
   Test: 1 GiB (x5) [Measure: 5 sec / Interval: 5 sec]
   Date: 2026-03-19 11:47:06
     OS: mageia 9 [linux 6.6.120-desktop-1.mga9]

With this fast pendrive everything went well for Live Plasma official Beta1 :
Booting it with Nvidia driver took 5 minutes before having a working Plasma, 
Plasma is now as fast as if it was installed on on a harddrive inside the computer !

Using a persistent partition needs absolutely a very fast USB pendrive

(In reply to Morgan Leijström from comment #237)
> The nice live system https://www.system-rescue.org/ also can load all onto
> RAM and you can then remove the USB stick/DVD. 
> 
> That Comment 234 stick is terribly slow.
> four? yeas ago i documented some tests here
> https://wiki.mageia.org/en/Storage_speed_test_results
> 
> At https://wiki.mageia.org/en/Talk:Persistent_live_systems we discuss some
> trick to enhance speed for certain app (i.e firefox) that do much file
> access, by making it use RAM instead also when we have persistence.
> 
> Another ide i have but no time to try is to use a btrfs persistence
> partition, with compression, in order to reduce bandwidth on the USB
> connection.

Hi Morgan
You may add inside https://wiki.mageia.org/en/Storage_speed_test_results
the results with KDisk Mark for this USB 3.1 pendrive :
Transcend JetFlash 780 (32 GB USB 3.1)

https://bugs.mageia.org/show_bug.cgi?id=35020#c243

It's very very fast to be used as a live system ...
It costs 30 € which is quite acceptable !

Thank you Philippe.
Added top in table at https://wiki.mageia.org/en/Storage_speed_test_results#Test_results

Created attachment 15489 [details]
new patch for draklive for using prebuilt modules for Ampere and beyond architectures

Please add to the next builds.

(In reply to Giuseppe Ghibò from comment #246)

> Created attachment 15489 [details]
> new patch for draklive for using prebuilt modules for Ampere and beyond
> architectures
> 
> Please add to the next builds.

The x11-driver-video-nvidia-current-common preinstalling is optional, but would save unpacking and installing later on the fly.