search for: strangecode

Hi Quinn, Am Do., 10. Sept. 2020 um 04:49 Uhr schrieb Quinn Comendant < quinn at strangecode.com>: > [...] > I don't see any significant errors in the boot log, but I would appreciate > if anyone has a moment to help me look for issues. Here's a copy of the > serial console boot log ? you can find the "Press Enter to continue" on > line 536: https://wri...

Hi Thomas, On 10 Sep 2020 10:06:01, Thomas Bendler wrote: > If I'm not mistaken, problems after UTMP point to problems with X/ hardware > configuration. So I guess you might find more information when you also > have a look at the log files of systemd. I don't see any hardware issues. Here's the output from `journalctl -p 5 -xb`: https://write.as/2vjgz6pfmopg7fnf.txt The

...VM timeouts were too short and it was timing out as we had a lot of multipath devices. Once those were up , you could just continue. journalctl will show you what has happened. Best Regards, Strahil Nikolov ? ?????????, 10 ????????? 2020 ?., 18:57:02 ???????+3, Quinn Comendant <quinn at strangecode.com> ??????: Hi Thomas, On 10 Sep 2020 10:06:01, Thomas Bendler wrote: > If I'm not mistaken, problems after UTMP point to problems with X/ hardware > configuration. So I guess you might find more information when you also > have a look at the log files of systemd. I don'...

Hello all, I've got an odd problem that doesn't seem to be mentioned anywhere. I have several identical CentOS 7 servers (GCE instances). I recently ran `yum update` and rebooted all of them. All the servers came back fine except one. I opened a connection to the serial console of the broken server, and was greeted with this prompt: ? Cannot open access to console, the root

Update: I found a workaround to prevent entering emergency shell during boot for no reason. I've simply cleared the `OnFailure=` option for initrd-parse-etc.service (which was previously set to `OnFailure=emergency.target`). Now the server boots successfully without dropping into an emergency shell. This is a total hack, and I'm a little embarrassed that it's the only solution that

On 11 Sep 2020 17:23:00, Gordon Messmer wrote: > Run "systemctl daemon-reload && echo success" and verify that it > reports success, and not errors. > > Check the output of "systemctl status initrd-cleanup" too. Those have always reported success (even before I removed the OnFailure option): [~] sudo systemctl daemon-reload && echo success

On 12 Sep 2020 11:40:48, Gordon Messmer wrote: > In that case, I'd revert the change you made, unlock the root account > so that you can use the emergency shell, let the system boot to an > emergency shell, and collect the output of "systemctl status > initrd-parse-etc.service" and "journalctl -b 0". Ok, I was able to log in as root in the emergency shell.