<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 20, 2024 at 18:10 D. Hugh Redelmeier via talk <<a href="mailto:talk@gtalug.org">talk@gtalug.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Many people don't update their software.  They claim that it only brings <br>
grief.  I'm the opposite: I take any update offered in the hope it is an <br>
improvement.<br>
<br>
One of my computers hung during a Fedora update.  I don't know why <br>
it happened because I wasn't there (I also don't watch paint drying).<br>
<br>
Symptom: booting would not get the the log-in screen (GDM?).<br>
<br>
Step 1: have booting log to the display<br>
<br>
Normally Fedora booting is quiet so as not to disturb the serenity of the <br>
user.  In this case we want to see the log.  It might tell us what's wrong <br>
and it might tell us how far it got before hanging.<br>
<br>
- at the GRUB boot menu, type "e" to be given the chance to edit the <br>
  commands that GRUB will execute to boot Linux.<br>
<br>
- cursor to the end of the "linux" line<br>
<br>
- remove the last two parameters ("rhgb quiet")<br>
<br>
- type CTRL-x to get the modified commands executed<br>
<br>
Now lots of logging information will scroll by on the screen.<br>
<br>
In my particular case, it didn't tell me much but I could see that booting <br>
got a long way.<br>
<br>
<br>
Step 2: boot from a live Fedora USB and examine the system's HDD/SSD.<br>
<br>
I assume that you know how to boot from a live installation USB flash <br>
drive.<br>
<br>
It is easy from that desktop to examine the broken system.<br>
<br>
- SMART scanning the system's disk might by worthwhile, if only to <br>
  eliminate that source of doubt.<br>
<br>
- file system checks are always a good idea<br>
<br>
In my particular case, I didn't see anything obvious.<br>
<br>
Complicated brain surgery can be done by starting up the broken system in <br>
a chroot environment.  I started down that road but was interrupted before <br>
success or failure.<br>
<br>
<br>
Step 3: boot the system console mode, without a GUI.<br>
<br>
This had promise because it looked to me as if the failure was starting <br>
the graphical system<br>
<br>
Proceed like step 1, but after erasing "rhgb quiet", add " 3"; hit CTRL-X.<br>
<br>
Log in.  Now you have a shell.<br>
<br>
Since the system failed after a software update, I decided to do more of <br>
them.  You could instead back out of them.<br>
<br>
  sudo dnf update<br>
<br>
Failure:<br>
There was a set of kernel packages that seemed to be half installed.<br>
<br>
I removed the half that was installed and asked again for an update.  It <br>
worked.<br>
<br>
I could reboot the system and it would come up as expected.<br>
<br>
Success!<br>
---<br>
Post to this mailing list <a href="mailto:talk@gtalug.org" target="_blank">talk@gtalug.org</a><br>
Unsubscribe from this mailing list <a href="https://gtalug.org/mailman/listinfo/talk" rel="noreferrer" target="_blank">https://gtalug.org/mailman/listinfo/talk</a></blockquote><div dir="auto"><br></div><div dir="auto">I love war stories </div><div dir="auto"><br></div><div dir="auto">In the future, add “verbose” and “systemd.debug-shell=1” to the grub line, the first is obvious, the second gives you unsecured root shell on tty9 (alt f9).</div><div dir="auto"><br></div><div dir="auto">-nick </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><a href="https://gtalug.org/mailman/listinfo/talk" rel="noreferrer" target="_blank"></a><br>
</blockquote></div></div>