I've managed to break my Solus system with the installation of the Citrix workspace app.

At first it seemed ok, although I've got some error messages at the end of the Citrix installation script. I'm translating from German so the English translation is maybe not on on point.

The ctxusbd-daemon could not be integrated into the init-Runlevels. The reason is that none of the following commands were available:

  1. install_initd
  2. update-rc.d
  3. chkconfig

Apart from this error message the system behaved no differently (at first) and even Citrix worked. But soon I got more and more errors: I could not start applications like Terminal. Also apps like Terminal and Firefox were missing from the Budgie menu.

Also eopkg didn't work any more. Any command with eopkg produced this error message:

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
ImportError: No module named site

Finally I gave up and I've restarted the system and got this error message:

Failed to execute /sbin/init

How can I repair this error. I've already folllowd the steps described in https://help.getsol.us/docs/user/troubleshooting/boot-rescue.

I was able to chroot into my systems but I don't know how to proceed now.

Repairing packages with eopkg doesn't work as eopkg is not available.

Is it possible to solve this without reinstalling Solus?

    Ferdi I was able to chroot into my systems but I don't know how to proceed now.

    Repairing packages with eopkg doesn't work as eopkg is not available.

    If you don't do it a lot, there's nothing intuitive at all about mounting your partition and repairing it. I have to do the chroot instructions from the top sometimes 3-4 times. make sure you mount your boot, too. They key to that solus guide is knowing what does not pertain to you (luks etc probably),

    --In other words there is no circumstance I know of, if you are mounted correctly, that eopkg wouldn't work or wouldn't be available.

      I was able to chroot into my systems but I don't know how to proceed now.

      Recovering with chroot is only really possible if the core of your system is still OK, but it doesn't boot anymore for some reason. In this case the core of your system was affected by the script.

      Is it possible to solve this without reinstalling Solus?

      Probably not. It really depends on what the installation script did. Do you have a link to the installation script so we can try to reproduce it?

      I've managed to repair the system (somewhat). I've noticed that the folder /usr/lib was containing only one folder systemd that was almost empty. I've stumbled already on this Thread where one of the commenters recommended to copy the content of /usr/lib from a Live system to the chrooted systems /usr/bin. I did this and followed the rest of the steps in the Boot rescue article as eopkg worked again :-)

      After the I could boot my system but some things did not work properly:

      • on the greeter is a new user called Citrixlog with an unknown password. There is no user Citrixlog in /home!
      • startup was slower and the system reacts sluggish from time to time.
      • Audio doesn't work. No device is detected!
      • Nemo can't be started. If run nemo in the terminal a message about incompatible GTK-theme appears, doesn't matter which theme I use.
      • Keepassxc complains about a incompatible qt version (5.10 vs. 5.19)
      • the app syncthing-gtk is working but most controls in the window are missing.
      • Shutdown is slower as now a broadcast message is shown. That wasn't the case in the past.

      I've did another check of the eopkg packages with sudo eopkg check and reinstalled all installed packages containing qt or gtk.

      So I guess some things are still broken. Can I solve these issues by copying other files and folder from a Live system?

      7 days later

      I've reinstallled the system with Solus 4.4. That went well.

      Lessons learned:

      • rtfm
      • if unsure, test in virtual machine first
      • backups are vital (I had them, but never forget that lesson)