- User Since
- Dec 2 2016, 3:22 AM (102 w, 1 d)
Jun 18 2018
Feb 19 2018
Dec 4 2017
Oct 26 2017
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.
Oct 21 2017
Yes, thanks for following up.
Sep 20 2017
Sep 13 2017
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.
Sep 5 2017
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.
Aug 8 2017
You can use powershell on Solus now for administrative purposes:
Jul 31 2017
Woohooo... Patreon test ISO 2 boots with accelerated Xorg using the radeon driver. AMDGPU still segfaults, but regaining video acceleration is excellent.
Jul 30 2017
Jul 12 2017
May 16 2017
Additional information for any following:
May 13 2017
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.
May 12 2017
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.
Apr 30 2017
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.
Apr 23 2017
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...
Apr 20 2017
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.
Apr 18 2017
Dec 2 2016
Apologies, I was trying to not be pushy :)