On Wed, Sep 2, 2020 at 2:37 AM Mauro Condarelli <mc5686@xxxxxxxxx> wrote: > > Thanks Amir, > comments inline below > > Regards > Mauro > > On 9/1/20 8:43 PM, Amir Goldstein wrote: > > On Tue, Sep 1, 2020 at 9:01 PM Mauro Condarelli <mc5686@xxxxxxxxx> wrote: > > Hi, > most likely this is not the right place to ask, please redirect me as needed. > > I'm trying to use OverlayFS to add (limited) write capability to a ReadOnly > rootfs (SquashFS) > > Essentially (actual script is more complex, of course) boot-sequence includes: > > # /dev/mmcblk0p5: ext4 (upper+work+nwwroot+newroot/oldroot) > # /dev/mmcblk0p6: SquashFS mounted on / > mount /dev/mmcblk0p5 /overlay > mount -t overlay overlay -o lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work /overlay/newroot > cd /overlay/newroot > pivot_root . oldroot > mount --move oldroot/dev /dev > mount --move oldroot/proc /proc > > This works as expected, but, too often for comfort, some file > (and sometime also directories) become unavailable due to error: > > overlayfs: invalid origin (ssh/sshd_config, ftype=8000, origin ftype=4000). > > File name changes, of course, but rest is fairly constant. > > This always happens when some file is written. > Error persists reboots. > Only way I found to "cure" the system is to go on "upper" and delete the file > thus going back to "lower" version (in this case I should delete "/oldroot/overlay/upper/etc/ssh/sshd_config") > > This is a self-built kernel (Linux vocore 5.7.0 #2 PREEMPT Mon Aug 3 09:19:06 CEST 2020 mips GNU/Linux) > on a custom target based on a SoC (MT7628). > > I am available to do any required test, but I have no idea about where to start. > > Any hint (or redirect) would be greatly appreciated. > > This is probably your problem: > https://lore.kernel.org/linux-unionfs/32532923.JtPX5UtSzP@fgdesktop/ > > It surely looks like it is. > I tried to follow the thread, but I'm unsure i grokked it . > > I am using OverlayFS (ext4 over a SquashFS) on rootfs in order to > be able to update the whole system (changing SquashFS) while > retaining customization (essentially tweaks in /etc/, host certificates > and similar stuff) in an embedded target. > > To complicate matters I also have a dual system for fallback in case > of faulty upgrade; this means I can switch from: > lower=part6, upper=part5, update will go into part7 > to > lower=part7, upper=part5, update will go into part6 > > I don't need nfs at all, so exporting OverlayFS is not an issue, > but it's unclear to me if this "lower swapping" is > actually supported as I see: > > > > /me is again wondering what's the use case of modifying lower layer > > > with an existing upper. Is it fair to say, no don't recreate/modify > > > lower layers and use with existing upper. > > > > > > > It's fine by me to document that this is not supported. > > ... which is scary. > Note I do *not* need to modify lower on-the-fly, when I > swap systems, that will happen at reboot. Don't be scared :-) Your reaction is a good answer to Vivek's question above - No, it is not fair to say don't re-create lower and use existing upper But we may decide this is forbidden in case user opts-in to new features. The mentioned fix commit fixes the regression for mounts without mount options (index, xino, metacopy), just like your use case. > > If it is, it should be solved by commit a888db310195 > ovl: fix regression with re-formatted lower squashfs > in upstream kernel v5.9-rc1 or in stable kernel >= 5.7.10. > > I'm currently at kernel v5.7.0, but upgrading to > stable v5.8.5 shouldn't be a problem (I would like > to avoid Release Candidate kernels, if possible). > > Can You confirm v5.8.+ is supposed to work in my > use case? Yes, it was fixed in v5.8.0 (and not in v5.9-rc1 as I wrote). Thanks, Amir.
