Bug 290968 - Dynamic linuxbase loading can mount in unexpected locations
Summary: Dynamic linuxbase loading can mount in unexpected locations
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 15.0-STABLE
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-emulation (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-11-12 07:08 UTC by Wes Morgan
Modified: 2025-11-21 20:28 UTC (History)
2 users (show)

See Also:


Attachments
Potential fix, falling back to /compat/linux if the sysctl does not exist (367 bytes, patch)
2025-11-12 07:08 UTC, Wes Morgan
no flags Details | Diff
Revised diff against src tree (367 bytes, patch)
2025-11-13 20:49 UTC, Wes Morgan
no flags Details | Diff
diff against src tree (443 bytes, patch)
2025-11-16 00:21 UTC, Mark Linimon
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Wes Morgan 2025-11-12 07:08:23 UTC
Created attachment 265354 [details]
Potential fix, falling back to /compat/linux if the sysctl does not exist

The /etc/rc.d/linux module sets _emul_path from the compat.linux.emul_path sysctl, but does not verify that the variable exists. If it does not exist, $_emul_path will be empty, and with linux_mounts_enable=YES (the default), the script will try to mount linsysfs and linprocfs to /sys and /proc, which can lead to some "double mounts" and interesting side effects for /sys.

This occurred on a working system after upgrading to 15-STABLE. The linux module failed to load due to a missing mqueuefs dependency, and /usr/src/sys seemed to vanish until it became clear what happened.

Better behavior might be to exit or fall back to /compat/linux for the mounts.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2025-11-13 20:25:38 UTC
Please help us out here: to which 'linux' file in the src tree does this patch
apply to?
Comment 2 Wes Morgan 2025-11-13 20:49:24 UTC
Created attachment 265402 [details]
Revised diff against src tree

Revised; as diff against src tree.
Comment 3 Wes Morgan 2025-11-13 20:50:00 UTC
Sorry - revised patch attached; a diff against "libexec/rc/rc.d/linux".
Comment 4 Mark Linimon freebsd_committer freebsd_triage 2025-11-16 00:21:32 UTC
Created attachment 265436 [details]
diff against src tree

^Triage: rebase patch.
Comment 5 Mark Johnston freebsd_committer freebsd_triage 2025-11-21 18:29:52 UTC
Does this happen when one of the linuxlator kernel modules fails to load?  rc.d/linux loads kernel modules first, and one of those ought to be creating the sysctl.
Comment 6 Wes Morgan 2025-11-21 20:28:09 UTC
(In reply to Mark Johnston from comment #5)

Correct. See the original note --- linux.ko failed to load due to a missing module dependency. The script should check that the sysctl exists, indicating that module is truly loaded. Currently it assumes the module loads successfully and uses a potentially non-existent sysctl.

This is an edge case, as most installations use GENERIC, which builds all modules, so they would never see it. I only build the modules I need, a holdover from the old days of slower, single core systems, and small boot partitions. Sometimes you are bit by module dependencies silently showing up, like this.