Bug 193338 - vfs_mountroot_shuffle sets wrong mnt_stat.mntonname
Summary: vfs_mountroot_shuffle sets wrong mnt_stat.mntonname
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.0-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-05 09:28 UTC by Denis V. Meltsaykin
Modified: 2024-10-11 16:22 UTC (History)
1 user (show)

See Also:


Attachments
patch (1.81 KB, patch)
2014-09-05 09:28 UTC, Denis V. Meltsaykin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Denis V. Meltsaykin 2014-09-05 09:28:02 UTC
Created attachment 146853 [details]
patch

In case if you have configured /.mount.conf with several rootfs options like (for example):

.md /mfs_root.lz readonly
ufs:/dev/ufs/rootimg
.timeout 3
ufs:/dev/ufs/bootfail
.ask

after fail at first rootfs kernel proceeds to next and loads it correct. But after loading system there are wrong options in mounted filesystems:

/dev/ufs/failsafe on / (ufs, local, read-only)
/dev/ufs/bootfail on /.mount (ufs, local, read-only)
/dev/ufs/boot on /.mount (ufs, local, read-only)

And a real ufs/boot is under /.mount/.mount/ instead of /.mount 
In this case you can't unmount it or remount to RW. Underlying filesystems become useless. This happens because of vfs_mountroot_shuffle() sets mporoot->mnt_stat.f_mntonname unconditional, despite the real FS hierarchy.

I have attached something looks like a patch, please review it. I hope it will help.
Thank you.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2024-10-11 03:50:24 UTC
^Triage: Properly set patch flag.

To submitter: is this aging PR still relevant?
Comment 2 Denis V. Meltsaykin 2024-10-11 16:22:16 UTC
(In reply to Mark Linimon from comment #1)

Not sure, but looking at the HEAD of vfs_mountroot.c seems like nothing changed since 2014. I'm not involved in a FreeBSD related field anymore, so I unfortunately don't know from the top of my head. We can probably close this report, as it seems like nobody really needs this fix, since the nested root mounts are not used anywhere.