D-Bus fails to start, rendering system unusable

[taprove]

These were the packages installed since the previous reboot:

Screen Shot 2022-09-30 at 7.45.15 AM.png (75.25 KiB) Viewed 1868 times

[TrevorH]

Next time, don'tdisable selinux, set it to permissive mode either by editing the config file or by running setenforce 0 or by appending enforcing=0 to the kernel command line. Now you have a second problem of how to turn it back on again...

[taprove]

The SELinux disabling wasn't a troubleshooting step, I was just mentioning that as many articles seemed to center around that. It was done before this issue (and on a number of other dev machines) and could have been re-enabled as I was able to do just about everything but NetworkManager, and other networking-related items.

We couldn't afford to have this machine down any longer so I put in to have a restore of it from a couple of days prior to the incident. While that will get things back on track, it leaves me with an uneasy feeling not knowing what knocked this for a loop as we recently rebuilt an entire development environment on CentOS 9 Stream. Not had a similar issue with any other machines yet though so fingers are crossed.

[TrevorH]

Personally I don't think that CentOS Stream is fit for any production use. It breaks too often, lags behind security updates sometimes by a significant amount - for example a kernel update earlier this year for an important/critical update giving root access was more than 3 weeks behind RHEL and an httpd update around the same time took 71 days to appear in Stream after it was pushed for RHEL and the other clones.

[xraycat]

The problem is with the machine ID when d-bus calls sd_id128_get_machine() function.

First try to find /etc/machine-id, if it exists delete or move it somewhere else, then run:

Code: Select all

echo unidentified > /etc/machine-id

Then reboot.

A new machine-id will be generated and everything will just work.