Just make sure not to use a sdcard for the freedombox system disk, as freedombox is not designed to conserve them like openwrt, they fail way too quickly.
The mdadm, yes. but sorry, I don’t know about cockpit.
What I found with btrfs is that depending on snapshot preferences, and whether using a SSD or HD, there are some beneficial config adjustments to do for the default (btrfs) rootfilesystem.
How did you get cockpit to work, by the way? → [buster] cockpit: not authorized to perform operation (#2033) · Issues · FreedomBox / FreedomBox · GitLab
I stumbled over exactly the same authorization problem and finally logged in as fbx after setting up a password for that user.
That makes me feel unsure:
The kit includes the A20-OlinuXino-LIME2, a custom metal case with a laser-engraved FreedomBox logo, a high-speed 32GB micro SD card with the FreedomBox software pre-installed, a backup battery, a power adapter, and an ethernet cable.
That’s exactly how I bought the Pioneer-FreedomBox-HSK, so I assume the sd card IS definitely the system disk.
How else would that work?
I would expect usual sdcards to sustain above writes issues only for months.
Everyone who wants the system to last longer will currently either have to deal with the workarounds in
or
Thank you for the hints.
So, my best bet would be to buy an additional storage add-on with a ssd , connect it to the SATA port and follow the instructions in the freedombox manual to setup the system on this disk. I will consider this.
For a NAS setup, the openwrt image should work ok directly from the sdcard and always be able to cleanly reboot into the RAM after power outages. I don’t know if your device can boot from sata or usb. If it can, then you could try writing the freedombox image to that device, otherwise you could start with booting the sdcard and move the running btrfs root filesystem over to another drive (like in the issue posted above), while keeping the boot loader on the sdcard.
I own the Pioneer Edition FreedomBox Home Server Kit (A20-OlinuXino-LIME2) from Olimex. They also sell a BAY-SSD-xxxGB metal enclosure. Pioneer-FreedomBox-HSK supports BAY-HDD/SSD and when assembled the external storage is seen as additional disk.
What’s unclear to me is if this also means the system can boot from that disk.
I don’t quite understand how openwrt fits in that picture. As I understand it, freedombox is almost plain debian with freedombox packages installed. If I go the openwrt route, freedombox is not possible anymore, so I have to follow the docs here to roll my own services.
Well, I found a promising answer in the olimex forum:
So it should be possible to boot from ssd. Now I have to find the time to to do this.
Someone who knows your device would have to answer about its boot features.
I mentioned openwrt because it boots local adjustments to its readonly squashfs from F2FS into a RAM overlayfs (minimizing sdcard wear and corruption on power interruption). And you would have to manually fix the mentioned issues in freedombox also, anyway. So for just btrfs+sshserver-sftp-server the effort seems about the same.
That sounds like the freedombox workaround from the “move system to SSD” issue could work for you (leaving only the boot loader on sdcard).
Indeed! I finally found some time to make progress:
btrfs replace start -B /dev/mmcblk0p2 /dev/sda1 /
btrfs filesystem resize max /
reboot
moved the file system to the new ssd. I also managed to set up a btrfs RAID 1 on my two 1TB HDD’s connected via USB. After creating two empty partitions on /dev/sdb and /dev/sdc (I used Cockpit for this) I did:
mkfs.btrfs -L "Nas" /dev/sdb -f
mkfs.btrfs /dev/sdc -f
mkdir /mnt/nas
mount /dev/sdb /mnt/nas
cd /mnt/nas
btrfs subvolume create backup
cd
umount /dev/sdb
mount -o compress=zlib,subvol=backup,autodefrag,noatime /dev/sdb /mnt/nas
umount /dev/sdc
btrfs device add -f /dev/sdc /mnt/nas
btrfs filesystem balance start -dconvert=raid1 -mconvert=raid1 /mnt/nas
btrfs filesystem show /mnt/nas
With the help of northerncoder.ca.
Then set up Samba to back up my Windows 10 Box. Then backed up my Linux box with rsync. So far everything works as expected.
One small caveat. After setting up the above structure I found out that my Nas got mounted twice, first by /etc/fstab as /mnt/nas and then by the freedombox automount feature as /media/root/Nas. With the difference, that /mnt/nas pointed to the subvolume backup and /media/root/Nas to the root of /dev/sdb1.
I found this confusing as it also appeared twice on the Samba service page, as Nas and nas resp. So because of my setup I decided that I don’t need the automatic mount of removable devices and to remove the udisk2 service:
systemctl mask udisks2
systemctl unmask udisks2
systemctl unmask udisks2.service
Not sure if the last one is needed, though. Found at StackExchange.
Concerning the default mount, I learned that it can be handy to have the filesystem’s root mounted, to create snapshots and to have all subvolumes accessible for the root user, independent of custom mountpoint(s).
You didn’t write about the initial mkfs.btrfs of sdb.
Anyway nice that “show” seems to return your desired setup.
You’re right, of course, thank you. I edited my previous post.
Thank you for the hint, I didn’t consider this. If need be, I’ll undo the above removing of udisks2 service.