Running aurora, up to date, vaguely familiar with linux but only been using aurora for a few months
A while ago I messed up my fstab and got stuck in emergency mode. Said to log in as root but I couldn’t because I didn’t have a password. Managed to hack a password in via a live usb but it was quite a pain, and was also very surprised, giving atomic’s selling points, that changing to the previous version i grub wasn’t accounting for /etc issues, but oh well.
Recently now I suddenly can’t boot again. Both my old and new versions in grub have the same problem. I figured I was safe this time though: I’d already set up my root password before! Nope… now when I enter my password, it just sits there for about 30s and then drops me back to the same prompt anyway without any error
What am I supposed to do at this point? I haven’t been able to find anyone experiencing this or my past issues with the emergency mode online at all, and it seems like it’s impossible to even get to any more informative logs to see why the emergency mode login isn’t working.
Can someone confirm the right way to chroot or otherwise access internal ostree files in /etc, /var/home, etc via live usb? Not sure what the right term is here… I can see the raw partition but it’s almost all broken symlinks, and if I search around for etc folders I find multiple versions that seem nearly identical.
There’s some nice docs here about emergency mode on aurora/etc: Booting to Rescue & Emergency Mode | Aurora . Problem is, they claim that now passwords aren’t required, and you can just press enter to get to the console, which clearly isn’t happening for me. Are these docs out of date, or is there something wrong with my setup that’d cause it to not act this way? The doc doesn’t make any mention of what was changed or how so I can’t really find what’s going differently…
It seems like this mode is completely useless, all it does is block me from actually logging in to see the logs and address the issue. Is there a way to just disable this so that it drops me right to a shell if there’s a problem without login? Or make it at least print out the boot log before locking me out? Right now even if I boot in text mode as soon as it fails it blanks the whole screen and replaces it with this ‘emergency mode’ prompt that doens’t work, making it even more useless than just leaving me on a hung text log screen
is there a way to view these journalctl logs from the live usb? It seems like even when I log in there, there’s no logs from the recent boots, like they’re not being saved or something?
Is there a recommended way to handle boot failures caused by things that aren’t in the read only FS? I used an atomic OS specifically for the reliability but so far every boot failure hasn’t been recoverable via the methods the ublue atomic approach uses
I use Bluefin, but similar thing happened to me last week. When trying to boot either of the 2 options in grub, I kept getting this message:
You are in emergency mode. After logging in, type “journalctl -xb” to view system logs, “systemctl reboot” to reboot, or “exit” to continue bootup.
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Press Enter to continue.
What worked for me:
As mentioned in that doc, at the grub menu, I edited the boot option by adding single to the ‘linux’ line. This also brought me to a bash prompt where I could view the logs (using journalctl), but there seemed to be nothing unusual in the logs.
After that, I typed ‘exit’ and to my surprise it continued booting to the graphical session (gdm login screen). I logged in, then I did ujust update to get the latest image. It staged the deployment as normal, I rebooted, and everything is back to normal now. Perhaps the update/staging part resolved whatever issue there was.
If worse come to worse, you could try to re-install over top of your existing installation (using custom partition assignment) and reformatting all partitions except home (NOT reformatting the home partition - assuming you have a separate home partition. I made a separate home partition when I installed Bluefin). I tried reinstalling in a VM with custom partition assignments and my home files were preserved. I was going to do that, but then editing the grub boot option and updating to a newer deployment fixed it.
This won’t be helpful to fix your issue, but to explain - you can’t log in with your password because it’s asking you the root users password, which is not the same as your user accounts password (unless you’ve changed it). Under Arch Linux distros usually, when you install it will prompt you to re-use the same password as for your user for root too. Under Fedora and it’s variants (Like, Bazzite) usually root has login disabled because it doesn’t have a password set (which prevents anyone from accessing root as a security precaution).
Note that you’ll need a bootable Linux ISO (I think just about any version or distro will do, unless your system uses Btrfs - then you’re tied to versions that have built-in support for that …like stock Fedora Workstation, for example) so that you can access the terminal and type in the commands.
This is the problem, yeah. it uses btrfs and ostree- I can’t seem to find any documentation anywhere on how to properly chroot into an ostree based OS.
The closest I’ve seen is a few comments vaguely mentioning something like chroot /mnt/ostree/deploy/<osname>/deploy/<deployment_name> among many other steps, but it’s not clear how to even tell which deploy is which
I don’t think you should get into deployments just yet - you can just mount the whole Btrfs partition and look through the files (just need a bootable env compatible with Btrfs): sudo mount /dev/sdX# /mnt
If you want to chroot into it properly you’ll need to mount it in similar manner just with specifying the Btrfs subvolumes.
I.e.: mount -o subvol=/root /dev/sdX# /mnt
When you have the / mounted, you can do the whole chrooting process without mounting stuff like /home, /opt and others chrooting into it, then run mount -aonce chrooted (that’s what I do to get all the mount points from my broken systems /etc/fstab).
There’s more info about Btrfs mounting on Arch Wiki: Btrfs - ArchWiki
