Fixing fstab/grub on the L13

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.

Is there some quick way I can rebuild the fstab?

1 Like

Restore it from backup?

I don’t think I have one.

I was thinking more along the lines of a live usb and adding the lines back, but I was wondering if there was some app that could fix it?

1 Like

I am not really sure but maybe try this? Website seems dead so I had to do that instead.
https://web.archive.org/web/20200502211404/https://www.andreydba.com/unix-linux/how-to/how-to-fix-boot-failure-due-to-incorrect-etc-fstab
google before more items are thing says…
Enter to grub mode (press any key after restart the server):
add init=/bin/bash to the end of the kernel command line and press enter.
The system will boot to a prompt.
Run the commands in the prompt:
mount -o remount,rw /

Unless someone finds some other way, you may just need to move/backup data with use of a live boot and reinstall which is pretty bad I guess. Not to think too much in hindsight but you should backup.

1 Like

Do you know what lines you want to add back??

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 /etc on the usual root drive and edit fstab.

Any chance that whatever you used to edit fstab originally made a backup copy?

1 Like

No it was nano I used.

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.

1 Like

Not that it helps now, but massage .bash_aliases (or whatever) so that nano is nano -B

Ubuntu is quite happy to boot without swap. I have no swap partition or file in /etc/fstab and the original /swapfile that Ubuntu set up is not there any more - and it boots happily.

/etc/default/grub ? as per, e.g., https://superuser.com/questions/383140/linux-grub2-how-to-resume-from-hibernation

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

1 Like

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.

1 Like

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.)

Maybe I am late.

Here is one option.

At grub boot up menu press a key, then edit the line for the normal boot kernel, usually that is the ekey when you highlight the boot kernel.

This will put you in edit mode, then on the linux line that is the kenel boot options, append at the end of that line init=/bin/bash

Then boot with this ( see below of the screen they tell you how to boot with this changed line )

This option will only be used for that boot and it will not be saved on files.

This will boot you straight to a shell with no password.

Then you have to remount root as read-write

Usually something like mount -o remount,rw /

Then you can edit /etc/fstab

Once done make sure all file changes are commited on disk

sync;sync;

Just to be paranoid lets remount root as readonly

mount -o remount,ro /

Then reboot

You might need to press power button here, since all env are not loaded.