I’m really having troubles with my computer.
it’s the second time it drops dead on me. I’ve upgraded my qubes OS without any issues whatsoever, I reloaded my PC and went doing some chores, I was very much surprised when I got back to see my computer restarting repeatedly.
It really goes beyond my comprehention on how could this happen for the second time. The computer is a MSI stealth 15m and it’s brand new. I’ve never had this kind of problem with any other operating system.
The only error pointed out to me is this right here.
When a service is changed, which properly happened in the update, the command systemctl daemon-reload needs to be run. The warning just tells you it hasn’t happened, and the old version is being used.
This is unlikely to result in your system rebooting.
Try booting an old kernel, if your system can’t boot after an update it’s often related to the kernel.
At the blue boot screen, you can use the advanced menu option to select older kernels.
is systemd saying “hey, this unit file has changed since I last saw it, run this command to tell me to pick up the new unit file”.
One of two things is happened:
1] the file usbguard.service changed and should not have changed, you may have an actual incident on your hands.
2] the file usbguard.service changed, should have changed, and systemctl daemon-reload probably ought to have been part of some update process that ran but was not.
Hopefully #2 is the case, and if so is something the Qubes developers will be interested in so that other users are not affected.
I marked @renehoj’s post as the solution, so that it is easier to find for folks with the same issue as you @lofiwk. Feel free to correct if I got it wrong!
@lofiwk I just now updated dom0 on one of my test machines and the file /lib/systemd/system/usbguard.service did not change. Before rebooting, systemctl restart usbguard did not complain and a reboot went as normal.
What release of Qubes are you running? In your Qubes Global Settings panel, dom0 updates: is set to Stable updates, yes?
What sticks out to me is ls -l /lib/systemd/system/usbguard.service returns a date of Jan 14 2021, which is odd. What is the date on your copy?
When I run sha256sum /lib/systemd/system/usbguard.service I get a sha256 starting with 1c747c25 and ending with 81c21164. What do you get?
I just now opened a console for sys-usb to see if I am looking in the wrong place. The command find /lib/systemd | grep -i guard did not return any results.
the updates are set to stable, yes.
I update everything through the updater, but it fails once in a while, so I have to open up the qube manager and do it manually through the panel.
dom0 last update made this happen so I opened up the terminal and started putting the code you pointed out to me, and I practically have the same thing. I’m not sure at what I’m looking here so I used gpt to explain it all to me. Considering you are right, it does seems like an odd thing for the copy to be that old and that I’m not familiar to what it stands for… I don’t know if I should be sharing this but take a look:
I do have some results you didn’t seem to have. In this case, the usbguard.service file is owned by the root user and has read and write permissions for the owner and read-only permissions for other users. It is 844 bytes in size and was last modified on January 14, 2021. Maybe it’s just my imagination getting back at me, but I switched to Qubes because I had serious security issues (remote control, pointer moved on it’s own, screen was shared, the works) with windows and the reason why persists to this day.
Yes, I’m paranoid (diagnosed). Who isn’t this days? I’m just being clear here. If all of this is just mind fabric then, you have my permission to roast me until the end of time, but if this is actually something… I would be open to discuss it. I know what I’ve seen.
Anyway, I’m actually pretty glad I got to introduce myself to all of you and I want y’all to have a great evening. Greetings from Chile !!
Cheers