I noticed this with a mvebu device but the bug may concern all kernel 4.9
users with ubifs, and possibly also jffs2 users, meaning practically all
targets...
Router fails to rename files that are both in /rom and in /overlay, i.e. they
were part of the original flash and have been modified later or were included
in sysupgraded config files. ( I use /etc/dropbear/dropbear_rsa_host_key
as an example testcase as that file is found in practically all builds.)
* Rename/mv fails.
* Deleting the same file succeeds.
* Copying is also ok.
(Deleting the file and copying a new one into its place does not enable
rename, which still fails.)
As the problem is in the core filesystem level, the rename failure happens in
all places: console, scripts and function calls from C programs.
Longer debug story and fix proposal for ubifs:
https://bugs.lede-project.org/index.php?do=details&task_id=579
The reason I am highlighting this at the mailing list is that after looking
again at the original Linux upstream commit, I noticed that also jffs2 is
among the filesystems that got the same new clause returning EINVAL error for
certain rename action types. That may mean that also non-ubi targets are
impacted with this. But I have no way of testing that.
The offending two new lines in kernel 4.9 fs/ubifs/dir.c :
if (flags & ~RENAME_NOREPLACE)
return -EINVAL;
Linux upstream commit that apparently restricts allowed rename action types,
possibly breaking overlayfs actions:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.9.y&id=f03b8ad8d38634d13e802165cc15917481b47835
I drafted a fix for ubifs (in FS#579) that seems to work by removing the two
new lines from fs/ubifs/dir.c that were not in our kernel 4.4 ubifs patches.
Otherwise the kernel 4.4 ubifs LEDE patches are pretty identical to the
upstream ubifs files in 4.9.
But I wonder if a better solution would be to change the RENAME flags in the
call from overlayfs instead, or something like that. My fs skills are not
good enough to determine the best solution.
I find this bug rather nasty as it makes a basic filesystem operation fail
rather mysteriously. I originally spotted this when I was debugging opkg for
Jow and first thought it to be a bug inside opkg, but after some debugging
with strace it turned out to be a failing rename operation at the filesystem
level.
Hopefully some filesystem gurus can look into this.
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
