root@fxpi:/etc# uci get fstab.overlay
mount
root@fxpi:/etc# uci get fstab.overlay.uuid
0d3b2a4c-bb14-4bb2-abbf-37717762bac5
root@fxpi:/etc# uci get fstab.overlay.target
/overlay
I too am having the same problem. Can anyone help? Being able to use an ext4 partition on the Pi\s SD card as overlay (while keeping the easy resetability of SquashFS) would be great
messed around with one on ext4 and while it was functional... it was a little more clunky... probably something minor with the traditionally early mtd style overlay switching...
(from memory i think I may have set the partition label to 'rootfs_data' or something... but I don't think that would work on squashfs)
imho
dont go hand in hand...
for sdcard based devices... i recommend;
burn a second sdcard with the same version and tape it to the top of the case
use the image builder to change the default partition sizes of an ext4 fs image
squashfs + large-overlay on a following partition do make sense from a 'virtual-box' -> 'gimme-more-space-now' on a factory image does make some sense... so we might have to hang around for someone who's using an sdcard style(squashfs) image to mess around with it a little more to pinpoint the quirks more clearly...
even then... I think it's only a thing for people with 'intermediate' or previous experience with overlay on other devices... to many places people can overlook steps or fail to transfer what is good general guidance into situational use...
afaik @erdoukki would probably be the person who comes to mind who might have some practical experience / ability to pinpoint exact quirks re: squash+sdcard+extroot-overlay...
( farouk tazkan ? name escapes me is also a master in this space )
my overwhelming advice is that default partition sizes on sdcard/disk images is at least 35-50% too small... the smartest thing that can be done in the short term is adding at least an extra %35 which for most people...
will remove the need for the overlay all together...
All wise words someothertime, however it would be good if all squashfs devices behaved similarly in respect to extroot, whether they're mtd, nand or emmc based. Would just save a lot of hassle for everyone!
the use case you provided seems entirely new... i'm not aware of any nand, emmc or mtd device that will allow for an extra augmented extroot-overlay on the same disk...
(guides and advice specifically state to use an additional disk)
in the linux overlay man pages i believe this is actually outlined as one of the primary restrictions of overlays in general...
(hint: if your preinit sets up a loopdev it will work)
going off the downloads stats... these kinds of images rank very highly in popularity... so i'm sure there are many others with similar experience...
here is another tip...
if you leave your 'hot-swap' sdcard in a usb-card reader... you can mount it and run a cron/manual periodic backup as such;
sysupgrade -b -k /mnt/card2p1/sysupgrade.tgz
if you ever need to recover ... swap the cards... possibly re-install any recently installed packages... would take maybe 2mins tops...
I prefer personaly use an ext4 system and extend the eMMC (or uSD) with an additional partition where I copy the system root (and mount as / for extroot)...
Then fstab (block-mount ipk) take care of any crash and check fs with the option :
config 'global'
...
option check_fs '1'
...
config 'mount'
option target '/'
option uuid 'replace with correct uuid found it with blkid command'
option enabled '1'
option enabled_fsck '1'
It is a 24/24 7/7 365/365 solution which is crashless !
No problem with sysupgrade, but you'll need to replace then the added partition content with the sysupgraded rootfs content...
I have done some "ugly" scripts to take care of this type of installation; available here :
They also take care of adding ipk at upgrade and firstboot...
Mostly working on espressobin board arm64 custom firmware but may be enhanced and fixed to be more stable and use also on any board like the RPi !
The poweroff, unplug, crash of filesystem is easily fixed with this method / scripts...
An automated reboot may happen after a filesystem fix...
