Issue with fstab after reinstall

[towwire]

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.

I just installed to a new ssd and if noatime is not needed then why on a new install is it there.
Here is the fstab.backup

Code: Select all

# Pluggable devices are handled by uDev, they are not in fstab
/dev/sda2 / ext4 defaults,noatime 1 1
/dev/sda3 /home ext4 defaults,noatime 1 2
/dev/sdb1 swap swap defaults 0 0 

This is the fstab

Code: Select all

# Pluggable devices are handled by uDev, they are not in fstab
UUID=290b4588-f0ef-40be-a204-c0992cb62a90 / ext4 defaults,noatime 1 1
UUID=2b2a5150-7e25-4c0f-9db3-f2ebe0c53f1a /home ext4 defaults,noatime 1 2
UUID=feb2f186-99a9-433b-bf94-3f755b458ec1 swap swap defaults 0 0 
UUID=92bf4518-7110-4096-a974-3d48c1558f54 /mnt/Download ext4 users,comment=x-gvfs-show 0 2

I added the Download partition.

[Head_on_a_Stick]

if noatime is not needed then why on a new install is it there

I have no idea, perhaps the developers will comment.

I suppose it could be argued that users of old SSDs might benefit from it (as long as they don't use mutt) but I would have thought that any SSDs fragile enough to benefit from that option would already be dead by now.

Reference: https://techreport.com/review/27909/the ... e-all-dead

[BitJam]

I agree with Head_on_a_Stick. The default "relatime" adds very very little extra overhead compared to "noatime" but still provides last access time that is updated at most once in 24 hours. I've discussed this previously in this thread.

Sometimes it is hard to kill off urban legends that keep echoing around the internet.

[dolphin_oracle]

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"

this shouldn't be possible with the autoinstaller to have old UUID info present in the fstab. I have a theory that is difficult to track down but may apply here.

I have seen on some cheap mmcblk devices (and some not-so-cheap nvme devices) that the partition type UUID does not update once we create the new ESP partition. I've never figured out why this is and it seems to be on a machine per machine basis.

I suppose its possible that the running linux system was unaware of the change in the partition table made by the autoinstall function. I think we may need to force a re-read of the partition table. there is a "partprobe" command for this function.

This is only a theory that fits the facts. To test, we would need you to run an autoinstall again on the device, checking the blkid information both before and after the autoinstall partitioning is done (very very early in the process). If the UUIDs match, then that would at least support my hypothesis. It should also be possible to update the information with "partprobe /dev/devicename", which we could manually run if the UUIDs match and see if they change.

in this case:

Code: Select all

partprobe /dev/mmcblk0

[BitJam]

I have seen on some cheap mmcblk devices (and some not-so-cheap nvme devices) that the partition type UUID does not update once we create the new ESP partition. I've never figured out why this is and it seems to be on a machine per machine basis.

I solve this by running blkid as root and using the "--cache /dev/null" option. This tells it to ignore the information it has cached and read it all anew.