I'm getting the error bellow at boot using a custom build from 18.06.04 (same happens with 18.06.02)
daemon.err mount_root: failed to sync jffs2 overlay
From docs jffs2 is a compressed filesystem and overlay is the layer that provides the access to this filesystem merged with the read-only filesystem . Device is functional even with this error but I not sure what this error can cause and what's causing it. Any help is appreciated.
I'm going to guess that you've got a unit with 4 MB of flash or less, or have installed several packages or files on your overlay.
JFFS2 requires at least three erase blocks (typically 192 kB) free to be "safely" functional and at least one erase block (64 kB) free at all times to be marginally functional (this is after including the size of files to be written).
It takes 30 seconds or more before the JFFS2 file system is initialized and usable after a flash. Does this occur after that file system is acknowledged as ready?
I am getting the same error after an upgrade. No packages installed outside of those pre-built into the firmware file. Plenty of space left on the device itself (GL-B1300 running 19.07-SNAPSHOT). I did notice, that mount_boot takes several minutes minutes to finish running.
egrep "jffs|overlay" /var/log/system.log
kern.warn kernel: [ 64.577915] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
kern.warn kernel: [ 64.577981] jffs2_build_filesystem(): unlocking the mtd device...
kern.warn kernel: [ 64.589844] jffs2_build_filesystem(): erasing all blocks after the end marker...
kern.notice kernel: [ 122.249514] jffs2: notice: (3665) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
daemon.info mount_root: performing overlay whiteout
kern.warn kernel: [ 124.642967] overlayfs: upper fs does not support tmpfile.
daemon.info mount_root: syncronizing overlay
daemon.err mount_root: failed to sync jffs2 overlay
I am getting the same error in the master build as well and it is seen in both GL-B1300 that I have, so not a HW issues. The routers are otherwise functional. I wish someone could shed some light on this error message.
case FS_DEADCODE:
if (switch2jffs(v))
return -1;
ULOG_INFO("performing overlay whiteout\n");
umount2("/tmp/root", MNT_DETACH);
foreachdir("/overlay/", handle_whiteout);
/* try hard to be in sync */
ULOG_INFO("syncronizing overlay\n");
if (system("cp -a /tmp/root/upper/* / 2>/dev/null"))
ULOG_ERR("failed to sync jffs2 overlay\n");
break;
busybox's libbb/copy_file.c unfortunately doesn't seem to return distinct error codes, though it does look to give some kind of error messages in some cases with bb_perror_msg()
Perhaps
if (system("cp -av /tmp/root/upper/* / 2>/dev/null"))
Thank you; for whatever reason I did not consider looking at the source code. It is too simple now...
OpenWrt router does not have a syslog configured by default, so the errors are not visible usually.
The line you pointed out is copying a /tmp/root/upper/etc/uci-defaults/luci-sqm: character special (0/0) into /etc/uci-defaults/, BUT those are not regular files any more
I guess the filesystem does not allow copying those files.
I tried cp -a /overlay/upper/etc/uci-defaults/bcp38 /root/test/ on R7800 & GL-B1300 and it was unsuccessful both times, so I am not sure why I am only seeing these on the GL router.
These routers do have /overlay mounted differently, though:
R7800 : /dev/ubi0_1 on /overlay type ubifs (rw,noatime,ubi=0,vol=1)
GL-B1330: /dev/mtdblock11 on /overlay type jffs2 (rw,noatime)
cp -a /tmp/root/upper/* /root/test/
cp: can't create '/root/test/etc/uci-defaults/luci-sqm': Operation not permitted
cp: can't create '/root/test/etc/uci-defaults/ddns': Operation not permitted
cp: can't create '/root/test/etc/uci-defaults/bcp38': Operation not permitted
ls -la /tmp/root/upper/etc/uci-defaults/
c--------- 1 root root 0, 0 Nov 26 16:48 bcp38
c--------- 1 root root 0, 0 Nov 26 16:48 ddns
c--------- 1 root root 0, 0 Nov 26 16:48 luci-sqm
UPDATE: The output above is truncated; there are more character files there than three.
I’ll bet that’s the “erasure mark” of the successful run of the script (I haven’t checked how overlayfs marks). Maybe it should be handled differently. If so, maybe it’s completing after the erasure marks get handled - “bad timing”.
It is the erasure mark for sure. I will try to figure out what package it belongs to and raise a bug in a proper place.
Looks like there is no side effect, though: all other files are still copied over and there is no action taken based on the error code.