/etc/polkit-1/rules.d # ls -al
total 76
drwx------ 2 polkitd root 4096 Oct 25 22:00 .
drwxr-xr-x 3 root root 4096 May 16 13:29 ..
-rw-r--r-- 1 root root 322 Oct 25 22:00 50-default.rules
-rw-r--r-- 1 root root 61502 Oct 17 10:30 90-default-privs.rules
/etc/polkit-1/rules.d # cat 50-default.rules
/* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */
// DO NOT EDIT THIS FILE, it will be overwritten on update
//
// Default rules for polkit
//
// See the polkit(8) man page for more information
// about configuring polkit.
polkit.addAdminRule(function(action, subject) {
return "unix-user:0"];
});
and
the 90-default-privs.rules file is exactly the same as on a secondary SSD that I have been booing this same system with to test.
Looking over this thread again,
I don’t see that the question was ever asked if you’re installed on BTRFS.
If you are, you can fix your problem easily and properly by simply doing a rollback to before your incident.
That should restore all the files you deleted by accident.
Maybe solution is to do a new install (not a re-install over the top of existing) and migrate your data to the replacement.
If you have enough room on your hard drive, you can even multi-boot so it’s a simple copy/paste of your data, then you can take your time and make sure the new install is working fine before you remove the old install to recover your disk space.
There have been numerous forum threads over the years on the details of doing this, but if you have specific questions or run into issues, just post.
Although some have used the YaST Partitioner to re-size your partitions, I personally recommend using Gparted Live instead.
And, of course, make sure you have a good backup or copy of everything that’s valuable.
I would think there should be something in some log somewhere that could give a definitive pointer as to the impeding issue.
Fortunately, all major data is on a second physical device, with just a few items on the boot device, but a total rebuild is something I would like to not have to do if absolutely possible.
Problem is that computing can get very complex when you scratch too deep beneath the surface, today a lot of that complexity is shielded from humans so we can manage what we can.
Problem is, maybe you did more damage than you thought, so there might be layers that need to be inspected looking for that needle in a haystack.
Or, you haven’t done a really complete job restoring what went missing.
Maybe one thing you could do is
copy the /etc from another machine or install another instance side by side with your existing system.
Run something like tree to create a listing of everything in both your existing /etc and a default /etc and “diff” them to determine what is different.
That would at least determine if you’ve missed any files.
But, it won’t compare anything outside of /etc
From the secondary SSD that was running correctly, I copied the entire /etc (making a backup of my current).
I had to copy over passwd, groups, and shadow from my previous /etc, then booting was successful, but the GDM login did not show the defined (2) users (<user. & Backup).
Successful MATE desktop, but Still polkit would not start, but the errors were quite different:
/var/log/messages
systemd[1]: polkit.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
dbus-daemon[1037]: [system] Activation via systemd failed for unit 'polkit.service': Unit polkit.service is not loaded properly: Invalid argument.
Reinstalled these packages
zypper in -f gpg2
zypper in -f gconf-polkit
zypper in -f mate-polkit
zypper in -f polkit-default-privs
zypper in -f systemd
I now get the normal GDM login screen. pkaction now returns