This commit broke symlinks when using Linuxulator: https://reviews.freebsd.org/D40090 Further information can be found in: https://reviews.freebsd.org/D40479 Repro steps, tested with latest 14.0-ALPHA3 ISO fresh install: sysrc linux_enable="YES" service linux start pkg install fontconfig linux-c7-fontconfig font-adobe-75dpi This command completes correctly: fc-list This command errors out: /compat/linux/usr/bin/fc-list After further testing, it was found that this issue only happens with ZFS file systems. UFS file systems are unaffected by this issue. The initial issue was discovered because due to fontconfig no longer being able to see its own config file, Linux apps no longer had font rendering support. The small test above is a smaller test case without requiring a full desktop installation to see the issue. A full video recording of the repro was also produced: https://www.youtube.com/watch?v=N46TGrCK4t8
dchagin wrote in D40479: > We found the cause of the problem, on it Handing it over to him
here it rather makes sense to speak about regression in vfs/namecache/ufs due to the fact that: 1. starting from https://cgit.freebsd.org/src/commit/sys/kern/vfs_cache.c?id=739ecbcf1c4fd22b5f6ee0bb180a67644046a3e0 file systems should cache symbolic link targets on their own. This method is not implemented for UFS, so the described bug does not occur for UFS. 2. UFS currently does not use namecache at all, so this bug does not occur. See here: https://reviews.freebsd.org/D41337, https://reviews.freebsd.org/D41338 I think it would be correct to modify the algorithm of the namei() and cache_fplookup() functions so that file systems are not responsible for caching symlink targets, ie, cache_fplookup() should stop its loop and return PARTIAL in case of a symbolic link, and namei() should resolve the symlink and go to the cache lookup starting from the current directory. As a temporary fix, try this patch, please: https://people.freebsd.org/~dchagin/vfs.patch
https://people.freebsd.org/~dchagin/nc.patch
https://reviews.freebsd.org/D41806
Dmitri - could you expand on vfs.patch, nc.patch, and D41806? Should we ignore vfs.patch and nc.patch in favor of D41806 when it lands?
(In reply to Dan Kotowski from comment #5) Ah, nc.patch is the same as D41806, vfs.patch is wrong, don't use it
Vincent, are you able to build & test the patch in D41806 to confirm it resolves the issue for you?
(In reply to Ed Maste from comment #7) I've asked Gleb to test, no response yet. I plan to commit this temporary solution tomorrow to merge to releng/14.0. I will write a separate letter with a plan to fix this problem.
The patch works as expected. Just tested it.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=bb8ecf259f96510b9c2146d846403393543061b7 commit bb8ecf259f96510b9c2146d846403393543061b7 Author: Dmitry Chagin <dchagin@FreeBSD.org> AuthorDate: 2023-10-19 10:33:58 +0000 Commit: Dmitry Chagin <dchagin@FreeBSD.org> CommitDate: 2023-10-19 10:33:58 +0000 vfs cache: Fallback to namei to resolve symlinks with leading / in target for non-native ABI This is a temporary solution to fix PR before release. During 15.0 it's necessary to refactor symlinks handling between vfs & namecache. PR: 273414 Reported by: Vincent Milum Jr, Dan Kotowski, glebius Tested by: Dan Kotowski, glebius Reviewed by: Differential Revision: https://reviews.freebsd.org/D41806 MFC after: 3 days sys/kern/vfs_cache.c | 5 +++++ 1 file changed, 5 insertions(+)
Nitpick: it doesn't matter whether symlinks start with /, only that they reside in compat.linux.emul_path and point outside of it. (Yes, both absolute and relative symlinks work on FreeBSD 13. That doesn't necessarily mean that behavior is worth keeping — I don't have an opinion here.)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b84a836ef02de42e262ce44d46c859be288df4b0 commit b84a836ef02de42e262ce44d46c859be288df4b0 Author: Dmitry Chagin <dchagin@FreeBSD.org> AuthorDate: 2023-10-19 10:33:58 +0000 Commit: Dmitry Chagin <dchagin@FreeBSD.org> CommitDate: 2023-10-22 06:55:53 +0000 vfs cache: Fallback to namei to resolve symlinks with leading / in target for non-native ABI This is a temporary solution to fix PR before release. During 15.0 it's necessary to refactor symlinks handling between vfs & namecache. PR: 273414 Reported by: Vincent Milum Jr, Dan Kotowski, glebius Tested by: Dan Kotowski, glebius Reviewed by: Differential Revision: https://reviews.freebsd.org/D41806 MFC after: 3 days (cherry picked from commit bb8ecf259f96510b9c2146d846403393543061b7) sys/kern/vfs_cache.c | 5 +++++ 1 file changed, 5 insertions(+)
A commit in branch releng/14.0 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=accbd5ad06c3eeb17d75cde05597f70f1fedb061 commit accbd5ad06c3eeb17d75cde05597f70f1fedb061 Author: Dmitry Chagin <dchagin@FreeBSD.org> AuthorDate: 2023-10-19 10:33:58 +0000 Commit: Dmitry Chagin <dchagin@FreeBSD.org> CommitDate: 2023-10-22 18:46:22 +0000 vfs cache: Fallback to namei to resolve symlinks with leading / in target for non-native ABI This is a temporary solution to fix PR before release. During 15.0 it's necessary to refactor symlinks handling between vfs & namecache. Approved by: re (gjb) PR: 273414 Reported by: Vincent Milum Jr, Dan Kotowski, glebius Tested by: Dan Kotowski, glebius Reviewed by: Differential Revision: https://reviews.freebsd.org/D41806 MFC after: 3 days (cherry picked from commit bb8ecf259f96510b9c2146d846403393543061b7) (cherry picked from commit b84a836ef02de42e262ce44d46c859be288df4b0) sys/kern/vfs_cache.c | 5 +++++ 1 file changed, 5 insertions(+)
This issue wasn't in 13.x