Issue with fstab after reinstall

[shiba]

Hi there! New MX Linux user here, I will start off by saying great work dev team!

I've been using MX on my Asus Notebook E203M, and it has been working beautifully until yesterday when I made a bonehead mistake of deleting my user directory. This messed up the icons and deleted all my apps. I wasn't too sad because I version control all my work. No biggie, I'll just reinstall MX Linux.

Well that wasn't as easy as I thought it would be. So I thought I would report my experience here. Long story short I had this exact same issue: https://mxlinux.org/forum/viewtopic.php?t=48458. So here are my notes I gathered and how I solved the problem.

Running this command:

Code: Select all

mount -o remount,rw /

Led to something along the lines of:

Code: Select all

Can't find UUID: 0f964a62-211e-4e73-9eb2-5279ced269f6

So based on what the internet was telling me fstab was clearly messed up.

Since the filesystem was read only, I had to boot with the live USB and access root to change the /etc/fstab file. Make sure you are changing the fstab for the actual OS and not just the liveUSB one. It will be obvious from the filepaths. You can figure out the path to the OS by clicking on the Filesystem icon.

So /etc/fstab went from:

Code: Select all

# Pluggable devices are handled by uDev, they are not in fstab
UUID=0f964a62-211e-4e73-9eb2-5279ced269f6 / ext4 defaults,noatime 1 1
UUID=7a164f84-cde7-4c77-a853-b62570f35fa8 swap swap defaults 0 0

to:

Code: Select all

# Pluggable devices are handled by uDev, they are not in fstab
#UUID=0f964a62-211e-4e73-9eb2-5279ced269f6 / ext4 defaults,noatime 1 1
UUID=7a164f84-cde7-4c77-a853-b62570f35fa8 swap swap defaults 0 0

Rebooted and just like that it worked.

As a nerd I'm very interested as to how this happened, and why my solution fixed it.

As a user, I'm concerned since I used the default settings from what I can tell and I chose to wipe the entire disk on reinstall. Hopefully this info can help the dev team make the installer even better. I'm sure they don't get a lot of reinstall bug reports.

[Head_on_a_Stick]

I'm very interested as to how this happened, and why my solution fixed it.

Your root partition was reformatted and this changed the UUID so /etc/fstab was incorrect.

You then commented-out the root partition line, thus rendering the error irrelevant (the system already knows where the root partition is, the fstab line is only needed to add different options for the filesytem).

If you un-comment the root partition line again and replace the UUID with the correct value then that will allow you to apply different options again.

Find the correct UUID with

Code: Select all

blkid

Alternatively, use the PARTUUID instead of the UUID in /etc/fstab — this will remain the same even if the partition is reformatted.

For your mount command you could have specified the device to avoid relying on /etc/fstab, like this:

Code: Select all

mount -o remount,rw /dev/sdXY /

Replace X with the drive letter and replace Y with the partition number for the root filesystem.

EDIT: check your swap UUID as well, you may need to correct the value in /etc/initramfs-tools/conf.d/resume to avoid errors on kernel upgrades.

[Adrian]

Your root partition was reformatted and this changed the UUID so /etc/fstab was incorrect.

That's obvious, I don't understand how come /etc/fstab was not changed at reinstall... how did you install? Where did you run this command "mount -o remount,rw /" in recovery mode?

[Stevo]

Could MX Boot repair include some code to look at fstab and the current blkid UUIDs to make sure they match, and fix it if necessary? You can get the same situation if you try a reinstall, but then decide to restore from a TimeShift backup instead. The UUIDs won't match.

[Adrian]

It's not really a boot problem, there could be a "fix_fstab" tool or something like that, but then this can get a bit complicated depending on what you want to fix and configuration (encrypted or not), I think it needs to be fixed with a lower-level, a CLI tool not in a GUI one.

[fehlix]

What I'm not clear about is this:

I chose to wipe the entire disk on reinstall.

What I'm not clear about is, if Op had chosen to wipe the disk, how could the fstab beeing wrong in the first place? I do probably miss something here....

[shiba]

I'm very interested as to how this happened, and why my solution fixed it.

Your root partition was reformatted and this changed the UUID so /etc/fstab was incorrect.

You then commented-out the root partition line, thus rendering the error irrelevant (the system already knows where the root partition is, the fstab line is only needed to add different options for the filesytem).

If you un-comment the root partition line again and replace the UUID with the correct value then that will allow you to apply different options again.

Find the correct UUID with

Code: Select all

blkid

Alternatively, use the PARTUUID instead of the UUID in /etc/fstab — this will remain the same even if the partition is reformatted.

For your mount command you could have specified the device to avoid relying on /etc/fstab, like this:

Code: Select all

mount -o remount,rw /dev/sdXY /

Replace X with the drive letter and replace Y with the partition number for the root filesystem.

EDIT: check your swap UUID as well, you may need to correct the value in /etc/initramfs-tools/conf.d/resume to avoid errors on kernel upgrades.

Thanks for the explanation.

I ran blkid and this is what I got:

Code: Select all

/dev/mmcblk0p1: UUID="6C10-EDAC" TYPE="vfat" PARTLABEL="ESP" PARTUUID="e287500a-381a-417e-bcbe-7d81917c6730"
/dev/mmcblk0p2: LABEL="rootMX18.2" UUID="49259c41-51fc-4b2a-afcb-39ebe77c545f" TYPE="ext4" PARTLABEL="primary" PARTUUID="71b0305d-398b-4ab6-bf90-11d7acb7d3ea"
/dev/mmcblk0p3: LABEL="swapMX" UUID="233c62c4-49aa-45cc-867d-307c06823e27" TYPE="swap" PARTLABEL="primary" PARTUUID="8f292ba5-4e80-4160-ba43-f1d1e9dfc9e8"

Can I get some guidance on what the corresponding /etc/fstab should look like?

Edit: /etc/initramfs-tools/conf.d/resume doesn't exist on my machine.

[shiba]

Your root partition was reformatted and this changed the UUID so /etc/fstab was incorrect.

That's obvious, I don't understand how come /etc/fstab was not changed at reinstall... how did you install? Where did you run this command "mount -o remount,rw /" in recovery mode?

That is what had me so confused as well.

I installed the latest version with a USB and default settings.

After the reinstall and rebooting it would throw the errors and just put me in a command line where I could login, but obviously not change anything since it was read only. That's where I ran the mount command at.

[Head_on_a_Stick]

Can I get some guidance on what the corresponding /etc/fstab should look like?

Something like

Code: Select all

UUID=49259c41-51fc-4b2a-afcb-39ebe77c545f / ext4 defaults 1 1
UUID=233c62c4-49aa-45cc-867d-307c06823e27 none swap defaults 0 0

There is absolutely no need for the noatime option: it breaks mutt and only offers a minuscule reduction in writes compared to the relatime default option (and also modern SSDs do not need any special treatment in respect of write operations).

Your swap partition is not used with your current fstab but you are completely oblivious to that because sysvinit lacks systemd's feature whereby it alerts the user to failed mount options with a boot message and delay.

[shiba]

Changed fstab like you suggested, rebooted, and posting this.

Thanks for the help. Loving how active this forum is.