So I foolishly messed up my fstab and the Librem doesn’t boot. Everything else is fine with the system, I just messed up that file.
Specifically, when starting the machine, it will ask me to enter the decryption password for the drive, then it will act like it is loading, with the spinning circle found on Ubuntu 20.04. However, it just stays like that. Hitting escape you will see that it doesn’t know where to look for booting.
If you do, sure, Live USB will do it easily. Just boot the Live USB, fire up nautilus, click on the usual root drive and it should mount automatically, navigate to /etcon the usual root drive and edit fstab.
Any chance that whatever you used to edit fstab originally made a backup copy?
I removed the initial 1 GB swap file that Ubuntu sets up, and deleted the hibernation partition I set up for hibernation. That was it.
I did not hibernate, but restarted. I didn’t think this would be an issue.
What I think is happening, is that when booting, it is looking for the swap partition to verify that there isn’t anything there it can resume from. But since it can’t find, it stalls ungracefully, instead of just cold booting.
Perhaps if I can remember the other thing I edited to include that logic (Grub), I can fix that.
Maybe pointing it at a non-existent partition is confusing it.
However that will be messier to fix because after changing /etc/default/grub you would then need to update-grub but that’s not going to work unless / is correct - so you would either need to take the approach suggested by @user1 or you would need to use man update-grub and then use the underlying command with a different output file. Edit: or you could try playing games with chroot
So I know what I need to do. I updated grub previous to resume using the swap partition I set up for hibernation. In an effort to move from a partition and use a swapfile, I forgot to update grub and it is still trying to use the partition which was deleted.
I know I can use a live usb to get into the system files. I can get to the grub file. I can put in the right UUID now instead. But how can I update grub to take the change to that file, instead of trying to build it off of the Live USB files?
I mean I know if I can just get this sorted I’d have the whole system back. I just can’t believe blanking it and starting over is necessary here.
You can try the approach suggested above by @user1
You can try chroot
Or … and this may or may not work … you can look at /boot/grub/grub.cfg or some other appropriate file on the real boot drive (grepping for the old UUID shouldn’t produce too many false matches) and if you can find where to change the UUID, change it there, as well as changing it in /etc/default/grub and then if it actually works to boot again from the real boot drive then you must do a proper update-grub once you have booted. (Unfortunately I stopped using hibernation some years ago so I can’t tell you the exact place that this ends up being configured.)