You're viewing a single thread.
As long as I can get into the terminal I can fix the GUI. What really sucks is when it something that runs in the DM init sequence was using Python but a Python upgrade changed the import path and no it keeps restarting and I need to boot from a USB to disable that service so I can log into something and properly fix it.
Pass something stupid via your bootloader so it aborts boot and dumps you in an initrd busybox shell. No usb required.
This was my poor man's boot environments when I was using zfs on root. I had a pacman hook to snapshot before package transactions, then if it became unbootable I'd interrupt the following boot attempt, edit my grub command line with something wrong so I'd get dumped in the busybox shell, import my zfs pool and roll back before finally rebooting again.
That's nice. I've later googled it and found out that I could have added
3to the end of the grub command to make it boot in runlevel 3 which does not trigger the GUI, but I guess your way could also bypass boot issues that prevent even non-gui boot.I also see that there is runlevel 1, which is kind of an emergency mode, so maybe that would be the best thing to use?
Yeah for my case it was easier in the initrd otherwise I'd be trying to roll back the active / partition.
Re run levels, they were a sysvinit thing so I wasn't sure sure about systemd, this suggests that would work though https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet
And if you have to bail out even earlier, run level 1 will give you the
rescue.target
damn thats oddly specific XD