From: Ritesh Raj Sarraf <rrs@debian.org>
To: Benjamin Berg <benjamin@sipsolutions.net>, linux-um@lists.infradead.org
Subject: Re: UML mount failure with Linux 6.11
Date: Wed, 06 Nov 2024 17:22:27 +0530 [thread overview]
Message-ID: <093e261c859cf20eecb04597dc3fd8f168402b5a.camel@debian.org> (raw)
In-Reply-To: <2ea3c5c4a1ecaa60414e3ed6485057ea65ca1a6e.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
Hello Benjamin,
On Thu, 2024-10-31 at 11:07 +0100, Benjamin Berg wrote:
> Hi,
>
> Newer kernels have become more picky about that with the new mount
> API.
> This is relevant, see the discussion about "Unknown options":
> https://lwn.net/Articles/979166/
>
> We only use hostfs for the root file system and in that case it works
> well if you pass the path using "hostfs=/path" on the kernel command
> line. Doing that avoids issues when remounting the file system later
> on.
>
As upstream developers for UML, what would you conclude it as ?
We've recommended using hostfs for the UML kernel modules as well. What
would be the alternate approach to ensuring a proper boot for a modular
UML kernel ?
> I suppose that currently it does not work to mount hostfs later on.
> No
> idea what the right fix is. Maybe the host directory should be an
> explicit option like "hostpath=..." or so to make it compatible with
> the new mount APIs.
The ability to mount any hostfs mount point was/is a feature provided
by UML. We've used it and integrated with many tools like debos,
fakemachine etc; the Debian bug report has the details.
There'll be more reports following once UML 6.11 hits Debian Testing.
I hadn't expected a working feature to break with a newer Linux
release. :-(
Thanks,
Ritesh
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-11-06 13:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-30 8:13 UML mount failure with Linux 6.11 Ritesh Raj Sarraf
2024-10-31 10:07 ` Benjamin Berg
2024-11-06 11:52 ` Ritesh Raj Sarraf [this message]
2024-11-06 19:25 ` Benjamin Berg
2024-11-07 6:22 ` Hongbo Li
2024-11-07 13:09 ` Johannes Berg
2024-11-07 14:17 ` Hongbo Li
2024-11-07 14:35 ` Johannes Berg
2024-11-11 1:16 ` Hongbo Li
2024-11-12 20:10 ` Karel Zak
2024-11-13 1:23 ` Hongbo Li
2024-11-21 13:53 ` Hongbo Li
2024-11-25 17:43 ` Karel Zak
2024-11-26 13:50 ` Johannes Berg
2024-11-27 1:26 ` Hongbo Li
2024-11-27 12:02 ` Karel Zak
2024-11-27 13:15 ` Johannes Berg
2024-11-28 10:58 ` Karel Zak
2024-11-28 12:55 ` Johannes Berg
2024-11-27 13:55 ` Hongbo Li
2024-11-27 11:55 ` Karel Zak
2024-11-27 12:16 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=093e261c859cf20eecb04597dc3fd8f168402b5a.camel@debian.org \
--to=rrs@debian.org \
--cc=benjamin@sipsolutions.net \
--cc=linux-um@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox