Oh cool - I didn't noticed. I will remove my workaround locally and get workmates to do the same.

No apologies accepted - you guys are both busy and doing fantastic work! :)

Thanks for the update and keep up the great work! :)

It appears the problem will be fixed when https://dev.solus-project.com/D809 lands, but currently the workaround I described above is still required by myself and others at my company using cups-browsed.

Yes, thanks for following up.

In T4524#80133, @ikey wrote:

@chrisweeksnz we'll take anything we can get! Once we move to CDN + new infra we'll need to add geoip mirror selection to the SC and push out an emergency update to help everyone jump across to mirrors

Are you open to having the repos mirrored? I can potentially help organise things within New Zealand if so at no cost - FSMG has a host with gigabit connectivity, but is georestricted to connections from NZ and I work with the maintainer. If interested, please let me know.

Super work! I've let my Solus using work colleagues know that the change is coming and to remove my workaround systemd service when your patch lands.

This issue is not concerned with whether cups starts (it does, but has the systemd service name org.cups.cupsd.service). The issue is that cups-browsed.service won't start because it requires a service with a name that doesn't exist (cups.service). The same problem has been experienced by users on Ubuntu and Arch, which makes me wonder if it is part of a default config that gets written down and just needs an appropriate filter applied to it at build time to alter. Quick observation of your diffs in both D809 and D842 support this concept - specifically package.yml in D842 seems to copy across the vendor file on line 49 without performing any changes to it. If your package doesn't adjust the name of the cups service from org.cups.cupsd.service to cups.service or adjust the cups-browsed.service file as described above , then the problem I am describing will remain.

You can use powershell on Solus now for administrative purposes:

Woohooo... Patreon test ISO 2 boots with accelerated Xorg using the radeon driver. AMDGPU still segfaults, but regaining video acceleration is excellent.

Additional information for any following:

No problem - I'm new too. The CLI tool that you use to install, upgrade, and downgrade packages is eopkg. The method I have been using is to see the history of updates using eopkg history. That will provide a list of transaction numbers and which packages were modified during each transaction. Look through the list of transactions to find when the linux-lts kernel was updated from 4.9.20-12 to a newer revision and note the transaction number (eg. 87). Revert your installed packages to that transaction number using the transaction number identified (87 in this example) with this command: eopkg history -t 87. Please note that this will roll back all the packages installed back to that transaction, so after rolling back, reboot your host into the Xorg GUI, run all updates except the linux-lts package. Reboot after the upgrade and verify that you still have graphical login.

Is there a way for me to try that on stable or do I simply wait till the next linux-lts update?

Sounds like your problem is very similar to mine: https://dev.solus-project.com/T3319

Same problem exists with 4.9.26-25.

I am only sure that the upgrade of the kernel package alongside the combinations of packages that I have tried, are causing xorg to segfault. The kernel itself doesn't segfault and I have access to non-graphical terminals when the xorg segfault occurs.

Problem persists with latest kernel. Upgrading from 4.9.20-12-1-x86_64 to 4.9.25-23-1-x86_64 continues to cause the segfault.

Okay, I have completely isolated the issue: the upgrade from linux-lts version 4.9.20-12-1-x86_64 to 4.9.24-22-1-x86_64 causes the segfault to occur.

By process of elimination, the first culprit for the segfault identified is:

I don't know if there will be multiple causes, but when performing this update, the segfault starts to occur.

I have reduced the problem packages down to something within the set of 'remaining packages' at the bottom of this message. If I install the budgie 10.3 update, then one of it's dependencies definitely calls the action that causes the segfault. Is there a particular order of actions that I could try to help define where the issue is to help? I will try installing the nvidia drivers next (which should have no impact given I have an AMD chipset video card, unless a dependency causes the error), followed by experiments with gnome related upgrades...

I am in the process of identifying the package(s) that cause the failure. My method so far has been to rollback to previously known good state (eopkg history -t 38), incrementally cherry-pick pacakges to install, restarting the host post each update to verify successful application. So far required and security updates have successfully been applied. I will resume testing over the weekend and report my findings.

Apologies, I was trying to not be pushy :)