after doing a apt-get dist-upgrade at the end of august, my osmc Pie is now almost unuseable. Everytime when I execute a command that requires dbus or systemd I run into a timeout because systemd-login doesn’t respond within 25 sec.
Rebooting didn’t solve that, nor any of the tips like deleting systemd session files or similar I found googling.
I cannot reinstall systemd, or install rng-tools, cause I suspected a random number thing, because it hits said error everytime.
I can only ssh to the box using ssh osmc@tv-himbeere /bin/bash --noprofile --norc -i
Its running headless, so I can’t tell if it would display an error.
Heere you can find my grab-logs output: https://paste.osmc.tv/wacukoyopu
I hope someone has a clue what I could try apart of reinstalling that thing.
You’ve only provided the APT logs. Please provide full logs: grab-logs -A (with a capital A).
Since you mention that you’re running headless, Sam produced a patched kernel to try to overcome some issues with headless devices. Probably worth a try:
I’m not able to provide the -A logs, because that won’t finish even after 30 min I guess its waiting on systemd…
Moreover, at that state of the system, I would not be able to install Sam’s patched kernel, because apt-get suffers the same problem.
However your links pointed me to the right direction, according to
fzinken at Headless Pi boot failure - #3 by fzinken
I added disable_fw_kms_setup=0 to config.txt, and all of a sudden, sshd lets me in again without --noprofile --norc -i
At first glance it seems that systemd now works properly again.
Is this setting save to use though?
Btw, the update clobbered my config.txt settings, I’m pretty sure that I once added some hdmi settings already, and my mpeg2 key is also gone. I think that happened in the august update and not in the previous one to buster, I did earlier that year.
Was that expected behaviour?
Thank you very much for your pointers for now
Best
Martin
It should be ok to stay with disable_fw_kms_setup=0.
As far as /boot/config.txt getting clobbered, this does seem to be a rare but recurring issue. I seem to recall that it can be related to the way MyOSMC saves the config settings you see in the GUI. However, in your case I’m inclined to think that it’s a one-off migration issue I’m not a dev, so haven’t looked closely at the code, but it might be down to the way that personalized settings should now be in /boot/config-user.txt and perhaps the upgrade could have handled this better.
I guess its waiting on systemd…