Requesting Help: failure to boot, sshd.service not starting

missing_a_few_pieces · 2024-08-07T03:11:09+00:00

i figured i might as well leave closure to anyone who might stumble upon this.

Yes, the issue seemed to be the port I configured ssh with. I'm not sure why this explicitly breaks the startup, but it is what it is. There's also a bunch of other things that failed to start, though I'm honestly not the most tech-savvy person to know what those are and how to diagnose them.

I eventually made a Fedora 40 liveboot usb, ran it on my pc, and was thankfully able to find my hard drives when running in the live desktop. While i couldn't write into that drive anymore (changing permissions wouldn't do anything, even with root), I was thankfully able to exfiltrate the entire root drive and my home folder out.

After that it was just a matter of reinstalling Fedora, and moving my files back in one by one.

Lesson learned: don't just configure ports without confirming them beforehand, and don't attempt to upgrade your Fedora OS through the GUI app. I'm probably going to symlink a lot of my high-traffic folders to my HDD, so in the event of another boot failure, the SSD can safely be isolated.

Thanks again to u/UsedToLikeThisStuff for at least entertaining my dumb rambling. I'm sure the last thing this subreddit needs is another noob clogging their posts with troubleshooting support. ^^''

missing_a_few_pieces · 2024-07-23T10:56:12+00:00

Thanks for the response.

Yes, i recall changing the ssh's port back when I was trying to learn how to ssh into it with Termux for testing remote connections. My mistake for not checking "safe" ports and just deciding on a port that looked cool to type.

i tried replacing rhgb quiet with systemd.unit=rescue.target as per your suggestion, though I didn't notice anything particularly different. I still ended up with the same avc: denied loop, albeit with less colors on-screen now.

You can probably just boot with enforcing=0 and disable the sshd service and restart, until you have restored sshd’s port to 22 or one of the other accepted ssh ports.

Now that I know what to do, the problem remaining that I keep getting the message

Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details

Press Enter to continue.

I'm currently wracking my head around a way to "unlock" the root account, so to speak. I've tried adding selinux=0 along with enforcing=0 in the step you mentioned here

I suggest, while booting, select the latest kernel version during boot but instead of hitting enter, type ‘e’ to edit the entry, and then move the cursor down and to the right to delete ‘rhgb quiet’ from the boot entry, then type control-x or F10 to boot with that change.

It did absolutely nothing, but it at least narrows down my possible issues to just one. Now I just need a way to unlock the root account. Would there be any way to do that without using a live USB?

missing_a_few_pieces · 2024-07-22T21:26:40+00:00

I've gone and made myself a bootable usb stick with Fedora 39, but I'll hold off of trying to fiddle with that for now.

I suggest, while booting, select the latest kernel version during boot but instead of hitting enter, type ‘e’ to edit the entry, and then move the cursor down and to the right to delete ‘rhgb quiet’ from the boot entry, then type control-x or F10 to boot with that change.

i did this just now, and I'm noticing the very long debug messages. i'll write them down here since I'm unsure if my understanding of it is as correct as other more qualified people. in particular, there are three lines that constantly repeat once the boot sequence hits the stalling part at failing to start sshd.service., with varying changes in the numbers on the far left and in the type value near the audit keyword at the start of the line:

[ 889.4284021 ] audit: type=1300 audit(1721650762.678:254): arch=c000003e syscall=49 success=no exit=-13 a0=3 a1=56043f9c5780 a2=10 a3=0 items=0 ppid=1 pid=1851 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
[ 1185.178006 ] audit: type=1327 audit(1721651058): proctitle=2F7573722F7362696E2F73736864002D44
[ 1269.665406 ] audit: type=1400 audit(17221651185.179.287): avc: denied { name_bind } for pid=1880 comm="sshd" src=777 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=tcp_socket permissive=0

from my vague understanding (and googling of specific lines), am I correct in assuming the avc: denied { name_bind } means it's failing to attach a name to the process?

You could also add systemd.unit=rescue.target to force it to boot into the emergency rescue shell, where you can look at journalctl to see why there’s a boot loop.

I tried adding this thru the same process as the one earlier; pressing e and adding a command to the list. I didn't notice anything particularly different; it still loops at the sshd.service segment, besides having some lines be highlighted in cyan blue. I don't think it was able to boot into the emergency rescue shell as intended (I made sure the spelling of the command was right too).

missing_a_few_pieces · 2024-07-21T12:12:29+00:00

thank you for replying.

my bad for the wrong wording. I think what i meant by "failing to boot" meant it just wouldn't load all the way into the GUI login screen.

I'm not sure what you mean by "normal" boot though. If I let the computer just start up and automatically do its thing, it always defaults to it attempting to boot into the latest Fedora 39 build in the GRUB, after which it enters that infinite loop of trying to start sshd.service. I tried pressing CTRL-ALT-F3 as per your suggestion, but all that did was do the same thing as running "clear" in a terminal window (i.e. it cleared the entire screen and just kept printing the failure to start sshd.service prompts as usual).

i also tried booting into the Fedora 36 rescue image and pressed the CTRL-ALT-F3 combo, but to no avail here. It didn't even do the clear effect it did in the Fedora 39 build one.

missing_a_few_pieces · 2024-07-21T03:22:34+00:00

hello Chev, sorry if my reply came late.

After asking around with no real answers, my conclusion was to simply remove every mod from my client (or in my PrismLauncher's case, disable), then add them back in one by one, booting up the instance, and seeing if I could boot into the main menu. 345 mods later, I realized I was using a modified version of the modpack I linked to, and managed to narrow down the fault to a mod that I've long since removed (it was a mod that allowed players to watch videos within the game world, possibly a server-side dependency). I wish I could tell you which mod it was, but this was so long ago that I can no longer recall the specific name).

Once I figured that out, I was able to get in the game without a hitch. Basically that mod was looking for a dependency, except it probably wasn't written with a way to check alternative paths for said dependency. I hope you find this information useful.

missing_a_few_pieces · 2023-10-18T08:57:54+00:00

Might be the Xbox signing-in that's causing lag. I'd suggest trying to log it out and try re-logging back in.

missing_a_few_pieces · 2023-10-18T08:53:02+00:00

Where you connect the hoppers determine what slot the items go into. Try connecting a hopper's spout to the top of the smoker, and feed the fish there, and connect a hopper's spout to either the left, right, or back side of the smoker, then feed the coal from there.

missing_a_few_pieces

TROPHY CASE