diff --git a/fstab/README.md b/fstab/README.md
new file mode 100644
index 0000000..741bb38
--- /dev/null
+++ b/fstab/README.md
@@ -0,0 +1,53 @@
+# Welcome to the fstab part of owning your CloudKey
+
+/etc/fstab is generated dynamically each time the CloudKey boots, so editing it to add you drive and partition mounts is futile.
+
+Use these files in this folder to get around the problem with mounting drives at boot.
+
+Download each of the files to the /root folder. Trust me, it's the most persistent part of the CloudKey (Curses be to OverlayFS)
+
+## onboot.sh
+
+make this executable
+
+```
+chmod +x onboot.sh
+```
+
+This file is started after the OverlayFS has done it's annoying Voodoo, at which time it is safe to mount more drives. It is started by onboot.service which I will cover at the end.
+
+## doled.sh
+
+make this executable
+
+```
+chmod +x doled.sh
+```
+
+I wanted LED indications of boot errors, so I made a little LED scripting language and included four files ending in .led
+
+Feel free to reverse engineer this script if you want to customize your boot up LED sequences.
+
+## fstab
+
+This is the meat on the bones. Edit it just like you would a normal /etc/fstab, but use it for you internal drive and any USB drives you may add to your CloudKey.
+
+## onboot.service
+
+Move this to /etc/systemd/system
+
+```
+mv onboot.service /etc/systemd/system/onboot.service
+```
+
+Then enable it but don't start it. It must only run at boot up time after the OverlayFS does it's dark magic.
+
+```
+systemctl enable onboot.service
+```
+
+# NOTE
+
+If a drive is missing or fails to mount at boot time, it won't cause Debian to drop down to a recovery mode. This is good, as we have no keyboard, no monitor, no seriel terminal, nothing. Instead you can wait for everything to finish and then ssh in and read /tmp/onboot.log to see what happened so you can fix it.
+
+