On Fri, May 7, 2021 at 6:51 AM www <ouyangxuan10@xxxxxxx> wrote: > > Hi Amir， > > > > > At 2021-05-06 18:25:51, "Amir Goldstein" <amir73il@xxxxxxxxx> wrote: > >On Thu, May 6, 2021 at 12:49 PM www <ouyangxuan10@xxxxxxx> wrote: > >> > >> Hi Amir, > >> > >> > >> > >> At 2021-05-01 00:16:28, "Amir Goldstein" <amir73il@xxxxxxxxx> wrote: > >> >On Fri, Apr 30, 2021 at 12:59 PM www <ouyangxuan10@xxxxxxx> wrote: > >> >> > >> >> Hi Amir, > >> >> > >> >> > >> >> Thank you very much for your help. I have another question to clarify. > >> >> > >> >> >> 3. If we upgrade overlayfs separately, we are not very good at verifying that we have solved this problem, because the recurrence probability of this problem is very low. So I want to ask, how can we quickly reproduce this problem? > >> >> > >> >> >Re-creating a lower squashfs after files have been copied to upper should > >> >> >reproduce the problem quite often. > >> >> > >> >> Does the re-creating lower squashfs here mean that remount squashfs? > >> >> I've tested dozens of times in the remount way, but I haven't found this problem again? > >> >> My test steps are: > >> >> 1). umount lower squashfs; > >> >> 2). modify the file in upper dir; > >> >> 3). mount lower squanshfs; > >> >> 4). restart service(it will re-parse the modified file) or reboot the system and the problem didn't happen. > >> >> > >> > > >> >No. That's not what I mean by re-creating lower fs. > >> >What I mean is that overlayfs is the file is question is in the squashfs > >> >image and has been copied up. > >> > > >> >I don't know where the squashfs image you are using comes from > >> >but I am guessing you have replaced it with a new squashfs image. > >> >In the new squashfs image, files have different inode numbers. > >> > > >> >I reckon this behavior is common for OpenWRT where the system > >> >image is being upgraded. > >> > > >> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/initrdscripts/files/obmc-init.sh (init file) > >> ... > >> line 376: mount /run/image-rofs /run/initramfs/ro -t squanshfs -o ro,loop (line 358, set copy-base-filesystem-to-ram=y) > >> ... > >> line 416: mkdir -p $upper/var/log --- new add line, not in the file > >> line 417: mount -t overlayfs -o lowerdir=run/initramfs/ro,upperdir=run/initramfs/rw/cow,workdir=run/initramfs/rw/work cow /root > >> ... > >> I would like to ask if the newly added line(line 416) or "set set copy-base-filesystem-to-ram=y" causes this problem?(This folder is created and the value is set every time the system starts, but the probability of problems is not high) > >> There are no other changes. > >> > >> > > > >I don't know. > > > >I am not sure what wasn't clear in my answer. > > > >The lowerfs image, namely /run/image-rofs in your script can be downloaded > >from tftp or from the web. I have no idea what actually happens in your setup. > > > the /run/image-rofs image is copied form flash. > line 359: test ! -e /run/image-rofs && ! cp $rodev /run/image-rofs -- the $rodev is mtd4 > > > >Every time you run this init script this lower fs image may change, while the > >upper f2fs rwfs does not change. > >When that happens, it MAY cause the reported issue. > > > the /run/image-rofs is squashfs, readonly, cannot be modified. > Do you mean that when I upgrade the new firmware, rofs (squashfs) has been updated (rofs has been modified), is it easy to have this problem? > YES! Thanks, Amir.
