Files
own-your-cloudkey/fstab
2025-12-11 11:14:57 +02:00
..
2025-12-11 10:52:08 +02:00
2025-12-11 10:59:31 +02:00
2025-12-11 10:55:08 +02:00
2025-12-11 10:54:28 +02:00
2025-12-11 11:02:13 +02:00
2025-12-11 10:50:33 +02:00
2025-12-11 11:14:57 +02:00

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.