Was distracted by systemd and PAM bits yesterday, working on the GNOME packages upgrade locally currently and will get that pushed out today assuming testing goes well on my laptop. I may opt to defer the ALSA update to week 5, after "that one thing" depending on time constraints, I still need time to finish up the local rebuilds and don't want to rush it onto unstable before sync (nor push it post-sync since only unstable repo users would have the opportunity to test it before "that one thing" gets validation).

Working on kernel updates for linux-lts and linux-current at the moment. Barring any absolutely necessary fixes or security issues resolved in newer kernels between the time of me landing kernels + rebuilds and That One Thing, these should be the "final" kernels until at least Week 5.

Kernels done.

Udev rules are failing to apply on my desktop after the systemd upgrade, should I make a task about it?

@serebit https://discuss.getsol.us/d/3446-unstable-repo-users-testing-desired-for-systemd-244

@kyrios123 I'm aware, I sent a message there 21 hours ago and didn't get a response. Apologies for the impatience.

Edit: I figured out what the problem was. Added a comment in that discussion with details.

Hey everyone,

I'm going to be cooking a few test ISOs throughout today and tomorrow for testing and would like to send out some ISO links for hardware validation. I'm looking for coverage of:

• Newer AMD CPUs / APUs such as Athlon Pro and Ryzen 3/5/7/9 3000 series desktop CPUs, as well as Picasso APUs.
• Newer AMD RX GPUs
• Newer Intel CPUs (specifically Comet and Ice Lake architectures / micro-architectures)
• NVIDIA 20xx series GPU
• NVIDIA 16xx series GPU

This email address can be obtained by using the email referenced on the Press Center page and removing the anti-spam bits. I'm not going to be looking at the Phabricator database to get people's email addresses so commenting alone will not help you.

Further Notes:

1. If there is a bunch of overlap, like 10 people offering testing for NVIDIA 16xx series GPU, don't take offense if I just reply that the similar hardware may already be undergoing testing.
2. Link me your Phabricator (dev.getsol.us) profile. If you're a brand new user on Phabricator (welcome, stranger!), the chances may be lower depending on circumstances, since I want to reduce the risk of the test ISOs leaking. If you don't link your Phabricator profile, no chances of cookies ISOs for you.
3. Newer NVIDIA GPUs are probably going to be hit-and-miss depending on the respective support in nouveau, so don't have too high of expectations.
4. I'll be testing installation across various methods (FDE, no-FDE, only LVM, manual installation) but there is some partition changes that landed lateish in the cycle of os-installer. If you happen to encounter an issue specifically related to partition alignment, then let me know. Otherwise just acknowledge that well, it is an old installer (from the EvolveOS days) and we haven't nuked it from existence yet.
5. Earliest emails will be sent out is tonight. I also work full-time and it isn't on Solus :P

Thank you all in advance!

Sent out a cooked Budgie ISO to a few folks that were kind enough to reach out. I've validated full-disk encryption installation using the new testing ISO and will also be doing another re-install with just LVM (no encryption).

Also it's using a new compression algorithm compared to previous ISOs. The ISOs end up *slightly* larger but the end result is a much faster installation (seriously, it took me longer to fill out the info than it took to write to disk). Hopefully those testers will notice (and we'll get some positive results from them).

Tomorrow I'll be cooking the other editions (and hopefully getting some finalized MATE desktop branding updates from @kyrios123). Installation should be identical but it won't hurt to test the other editions.

So checked it, I have a 3900X and 5700XT - the only thing I notice was it took a while to load the desktop, saw my cursor icon for a while before the rest got loaded (could be due my triple monitor setup). Everything else was working, tested different software and no issues inside the live ISO and damn that background :)

In T8592#163537, @JoshStrobl wrote:

Sent out a cooked Budgie ISO to a few folks that were kind enough to reach out. I've validated full-disk encryption installation using the new testing ISO and will also be doing another re-install with just LVM (no encryption).

Also it's using a new compression algorithm compared to previous ISOs. The ISOs end up *slightly* larger but the end result is a much faster installation (seriously, it took me longer to fill out the info than it took to write to disk). Hopefully those testers will notice (and we'll get some positive results from them).

Tomorrow I'll be cooking the other editions (and hopefully getting some finalized MATE desktop branding updates from @kyrios123). Installation should be identical but it won't hurt to test the other editions.

I could do some ISO testing on my notebook (intel i7 gen 8+nvidia mx150) and desktop (ryzen 5 +nvidia 1030).

@bvdlingen
Kindly mail him and ask

This email address can be obtained by using the email referenced on the Press Center page and removing the anti-spam bits. I'm not going to be looking at the Phabricator database to get people's email addresses so commenting alone will not help you.

Ran first tests on a computer with a Ryzen 5 3600 and RX 5700.

• Booting and installation: no issues.
• Games (tested OpenGL and Vulkan): no issues.
• Video (tested Firefox and mpv): no issues.

I ran into this issue when the install was still fresh:

Checking integrity of udisks                                         Broken
Corrupted file: /usr/lib/tmpfiles.d/udisks2.conf

$ cat /usr/lib/tmpfiles.d/udisks2.conf
d /var/lib/udisks2 0700 root root -

Running sudo eopkg it --reinstall udisks doesn't seem to solve it.

I will have time to do more detailed testing in the upcoming days, let me know if there's anything you'd like me to try. I plan to build Unreal Engine and see if it runs fine. I'll run and install the ISO on my laptop (XPS 13 from 2015) and just run the ISO on my work PC (2080 Ti). I'll report back.

EDIT: Suspend and wake up works fine by the way, I remember people with similar hardware complaining about it. No issues on my end.

Also

In T8592#163538, @Girtablulu wrote:

So checked it, I have a 3900X and 5700XT - the only thing I notice was it took a while to load the desktop, saw my cursor icon for a while before the rest got loaded (could be due my triple monitor setup).

I did not experience this. I have a single monitor.

UPDATE: I'm running into a new issue, but I had the same on Fedora before installing the ISO, so it doesn't seem to be Solus-specific. I have speakers plugged in at the back of my computer, and a headset plugged it at the front. Sound settings only let me choose the headset. I have to unplug it in order to be able to choose the speakers. Doesn't seem to be a hardware issue as I can switch between both on Windows.

I just booted the ISO on the computer at work (Intel Coffeelake and RTX 2080 Ti). It boots without issue both when using integrated graphics and the dedicated GPU with Nouveau. I didn't need to use nomodeset.

Thanks for the comprehensive testing @rjurga. The udisks package being broken is normal, the tmpfile is either being modified by udisks or eopkg (I need to check which), causing the sha of the file to change and for eopkg to report that it is broken, it can be safely ignored.

Glad to hear suspend and resume works, as well as the 2080Ti without nomodeset. nomodeset has been a pain point for some NVIDIA GPUs in the past, as I'm sure you're aware.

Long story short it’s apparently a limitation in the current Nouveau driver since I noticed that lowering the refresh rate to 120 Hz (on 1440p) before booting works around the problem.
After installing NVIDIA’s proprietary driver on the installed system it's possible to renegotiate the refresh rate without the monitor blacking out, including to 144 Hz.

NVIDIA finally releasing more documentation for their GPU’s will help the NOUVEAU effort in the near future.

This is not the full story, I’m still trying to pinpoint some other problems.

In T8592#163560, @Timalex wrote:

Long story short it’s apparently a limitation in the current Nouveau driver since I noticed that lowering the refresh rate to 120 Hz (on 1440p) before booting works around the problem.

I did not experience this in my previous test, but I was using a 4K 60 Hz monitor.

I just tested the last hardware I had: XPS 13 from 2015. i5-5200U with HD Graphics 5500. ISO boots, installs, and then Solus runs with no issues. Wifi works, suspend works.

In T8592#163537, @JoshStrobl wrote:

Tomorrow I'll be cooking the other editions (and hopefully getting some finalized MATE desktop branding updates from @kyrios123). Installation should be identical but it won't hurt to test the other editions.

https://mamot.fr/@kyrios/103528910031182958

First, I strongly suggest the next release to be called Solus 4.0.9999.
On Dell XPS L421x (2012) with i5-3517U, GT630 and 2 hard drives:

1. Installation alongside Windows 10 went fine and super fast (3minutes excluding partitioning),
2. Udisks was the only broken package (I know it isn't actually broken, but eopkg's derp)

but

3. Swap was not created. The space for Solus was tiny (15GB), but was this really on purpose? I wouldn't use a system without swap
4. The installer only saw 1 ESP, which was on the other drive to which it automagically suggested to install the system (suggested automatic install on Windows drive, but bootloader in Solus 4.0's ESP). I know you know about it but is no less problematic, especially in laptops where you can't just take the drive out.
5. In CLR-Boot-Manager the system name is still Solus 4.0 Fortitude, don't forget to change it for the final ISO.

In T8592#163565, @Jacek wrote:

4. The installer only saw 1 ESP, which was on the other drive to which it automagically suggested to install the system (suggested automatic install on Windows drive, but bootloader in Solus 4.0's ESP). I know you know about it but is no less problematic, especially in laptops where you can't just take the drive out.

I went around this by creating a gpt partition table with gparted, and then relaunching the installer (and again selecting automatic partitioning). This time it picked up the right drive for setting up the ESP.

Also I got a swap partition on both desktop and laptop. I do use full disks though.

In T8592#163563, @kyrios123 wrote:

https://mamot.fr/@kyrios/103528910031182958

I'd like to learn what is the reasoning behind having several default languages, while hiding others away behind the three dots. To be frank that screen rubs me the wrong way. I see no usability win in segregating languages into more and less important. A speaker of a "less important", nondefault language will not appreciate having a convenient shortcut to a handful of languages they don't want to use the system with. They'll still go for their native language, just with additional steps and a little insult along the way.

@paracetamol

https://github.com/getsolus/os-installer/blob/3c4e7691fcf170246e6faba64e91beb55600c2cc/os_installer2/pages/__init__.py#L14

Because Ikey borrowed it from gnome-initial-setup ages ago and never changed it. They still do it the same way:

https://gitlab.gnome.org/GNOME/gnome-initial-setup/blob/master/gnome-initial-setup/cc-common-language.c#L292

I imagine this list was based on the total number of native speakers, globally. Which is a pretty logical thing to do as a programmer: most frequently used choices first. And in the case of GNOME, there's even comment where they only used 8 languages to keep the window from being too tall, probably to avoid scrolling for accessibility too. These things are very very very rarely intended to be discriminatory.

"Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's razor

"Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's razor

It's not even stupidity. Those are extremely likely to be the most popular languages. The UX in that section makes sense. I have absolutely no reason to desire for it to be changed.

You don't see me rooting for Finnish to be a default... If you're taking it as an insult then I don't really know what to tell you.

Swap was not created. The space for Solus was tiny (15GB), but was this really on purpose? I wouldn't use a system without swap

Yes. The expected behavior is the installation on a bigger partition / disk size. Otherwise you run into the risk of not having enough usable space for /, user files, and supplemental programs they want.

https://github.com/getsolus/os-installer/blob/master/os_installer2/strategy.py#L45

In CLR-Boot-Manager the system name is still Solus 4.0 Fortitude, don't forget to change it for the final ISO.

It's a test ISO. You and I both know That One Thing hasn't seen baselayout changes per the meta task. I've done these things before, I don't just "forget" to change major aspects of it.

! In T8592#163570, @JoshStrobl wrote:
It's not even stupidity. Those are extremely likely to be the most popular languages. The UX in that section makes sense. I have absolutely no reason to desire for it to be changed.

I was going more for ignorance over how it might be perceived. I happen to think it was well thought out from an engineering standpoint. For most people, it saves a few extra clicks.

In T8592#163570, @JoshStrobl wrote:

"Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's razor

It's not even stupidity. Those are extremely likely to be the most popular languages. The UX in that section makes sense. I have absolutely no reason to desire for it to be changed.

In my opinion it does not make sense from the UX standpoint. It would if this was an e-commerce website presenting most popular products to the user. In such scenario defaults can translate into more profit, as the user doesn't lose interest halfway through browsing the store or sees a product that they didn't know they want to buy. A win-win for both the user and the store, ie. good usability.

Here I am presented with a one off installation screen, where the conversion rates don't apply. A completely different situation. It's not nearly that important to have click saving defaults here, while segregating languages into first and second class citizens can leave a bad taste, ie. bad usability.

In T8592#163571, @DataDrake wrote:

I was going more for ignorance over how it might be perceived. I happen to think it was well thought out from an engineering standpoint. For most people, it saves a few extra clicks.

Damn, the technical baggage argument was a satisfactory answer that I was going to roll along with.

Anyway, I am not going to pollute this thread with this issue. I am grumpy about it and even more so after reading the reasoning, but it's not a show stopper. Although I do wish the response was more empathetic.

@paracetamol We have heard and understood your argument and will take it under advisement for the next development cycle for the installer.

With that said, this discussion has gone off-topic for this thread and I would ask that we steer back towards the discussion around experiences with the testing ISO and the remaining tasks. Thank you!

Seeded out GNOME and MATE testing ISOs. Thanks again to everyone that has tested and provided feedback. For those that emailed and have not seen a reply, I do appreciate you all reaching out and fortunately much of the hardware that you all have generously volunteered is already receiving test coverage either by existing testers or Core Team / Global Maintainers. If I see anything that sticks out of course, I'll send out an email.

In terms of the Software Center changes, this is being deferred to a later update post-release. Not ideal but the "bucket" and some of the tree view logic needs some pretty substantial changes (tree view will be swapped out for a list box + listbox entries) and early testing brought some of these issues to light. The changes aren't something we want to rush out only to potentially cause more problems than the existing UX issues. As such, I've removed it from the list.

Booted all the ISOs successfully on my Ryzen 5 3600 and RX 5700 setup. I didn't test installation with Gnome and Mate. Everything seems to run fine in the live environment, not much to report compared to Budgie.

By the way, not sure if it matters but I created all the installation media with dd, I didn't try anything else.

@rjurga Thank you for testing the other ISOs. Much appreciated.

The data is in

*Budgie: Partial desktop, GNOME: Halted boot log, MATE: Blank screen or partial desktop

systemd-journald[2678]: /dev/kmsg buffer overrun, some messages lost.

Secure Boot disabled
Rufus was used to simulate a user coming from Windows. Written in ISO Image mode (Default).
As expected "ERROR: LEGACY BOOT MEDIA" is printed when selecting a non-UEFI entry from a GPT formatted drive.

I hope this can help to identify some issues and find a solution

Rufus was used to simulate a user coming from Windows. Written in ISO Image mode (Default).

While I appreciate the testing, that literally goes against our documentation and we'd inform the user as such. I would appreciate if more useful test results when Rufus is used in dd mode would be provided. The intent of seeding the ISO to specific testers is to perform hardware validation, not provide false positive results, causing unnecessary confusion during an important period of testing, and "simulate a user" that isn't accurately following installation instructions.

Thanks.

What a fool I am. I haven't used Windows for years and apparently forgot that little crucial step.
Sorry about that. Trust me it's more than a little frustrating.

This is Budgie written with DD mode. Same rendering results as before.

If it helps to know, my Navi setup was tested with GPT, UEFI, 144 Hz monitor (although I set it to run at 120 Hz), CSM disabled.

For the 2080 Ti, I tested with GPT, UEFI, 60 Hz monitor, CSM enabled.

I installed Solus from new Budgie ISO on the laptop with Ryzen 7 3700U and integrated Vega 10. Laptop utilizes UEFI, OS was installed on the whole SSD using default partition settings (no dual boot), Secure Boot was disabled. ISO was flashed on the USB drive using dd.

Installation went smoothly, all hardware including Wi-Fi and Bluetooth adapters seem to work correctly. I've tried playing games (namely Minetest and Taisei), video playback using mpv with OpenGL and Vulkan (--vo=gpu --gpu-api=vulkan, through libplacebo) output and with VAAPI on (--hwdec=vaapi) and off - all these modes worked as expected.

Overall everything seems to work fine, I will report if I find any issues.

@Timalex Not a problem, thank you for the additional test results with it written in dd mode. Interesting that you're specifically having issues on NVIDIA + 144hz. I'm going to guess this is either a nouveau issue, Xorg itself, or something in the kernel. At least we can safely rule out it being Mutter, given you had the issues on Budgie, GNOME, and MATE (which doesn't use Mutter).

@aleksvor Good to hear that it's working with your laptop and thanks for all the hardware acceleration-related testing as well :)