Non-mandatory fstab mounts (How to have your cake and eat it too!)

As many of you know, I am using some relatively large SSD drives with Charlie.

Part of this is a separate “Project_Files” partition that mounts over a “Project_Files” directory in pi’s home directory.

When booting from the SSD, everything is fine since, (barring catastrophic errors during boot), everything is there and everything mounts normally.

What about SD cards?  When I configured my latest instance of GPGOS 3.0.1 on a SD card, I, (silly me!), copied over the relevant section of the normal SSD version’s fstab:

# Mount SSD "Project Files" partition
PARTUUID=278aeaf6-0b  /home/pi/Project_Files ext4 defaults,noatime  0  2

. . . and everything is just peachy until I decide to use the robot without the SSD attached, as the operating system assumes that if it’s documented in the fstab file, it’s important.  If it’s not there booting goes right out the window because the OS thinks an essential resource has suddenly gone AWOL.

Here’s the crush:

  1. Having a known resource documented in the fstab file so that it will always mount the same way, in the same location, with the same characteristics, (etc.), all the time is a good thing.
    • Transient devices are handled by the O/S, and are usually mounted under /media and, as a consequence, don’t need to be enumerated in fstab.
    • In this case, I have something that can be transient, but that when it DOES exist, I want it to mount relative to /home/pi.
  2. However, if the “known resource” is something that cannot be guaranteed to be present, the fstab mount is problematic as the O/S assumes fstab mounts are essential system resources.
    • In the case of GPGOS/Raspbian Buster, the result is a 90 second timeout than a crash to the console that is not recoverable because the root account is locked, and the O/S has nowhere else to go.

So.  What do we do?  Can we "have our cake, (a transient device), and eat it too, (mounting it using fstab)?

Of course we can!

The magic word here is “nofail”.  When added as a mount option, it tells the O/S:

  • IF  this device exists when you start mounting devices during boot, go ahead and mount it the way fstab says to mount it.
  • Otherwise, (if it doesn’t exist, or isn’t ready, or whatever), just pretend we didn’t see that particular fstab line and keep on booting normally.

Adding that little tid-bit of knowlege, the fstab entry shown before becomes:

# Mount SSD "Project Files" partition
PARTUUID=278aeaf6-0b  /home/pi/Project_Files ext4 defaults,noatime,nofail  0  2

Possible caveat:
While researching this, some folks mentioned that the “nofail” option must come after the “auto” option if it exists, otherwise “auto” will be ignored, (or “auto” will be handled in a different way, or whatever).  Others indicated that as far as they knew - or at least as documented - there was no such restriction.

In this case, “auto” is part of the O/S’s mount “defaults”, and is included when “defaults” is specified.  Since I put “nofail” at the end, there should be no problems.

What say ye?


And you talk about ROS complicating “life”…


No, it’s just the operating system’s stupid inability to read minds!