Ed Maste
2023-11-07 00:26:42 UTC
I've moved the Ventoy support discussion to the -hackers mailing list.
looked into how Ventoy operates, and it appears to require more than
just including the (BSD licensed) geom_ventoy.ko in our releases.
Ventoy stores the block mapping in the kernel module itself that it
then injects into the ISO image.
I think methods of supporting Ventoy, in order of "architectural elegance" are:
1. Mount the exFAT device and then mount the ISO image within. This
unfortunately requires FUSE as we do not yet have kernel exFAT
support. There's probably also a small performance penalty, but it
shouldn't be a significant issue in the context of an installer.
2. Use a geom module that provides arbitrary block mapping, akin to
one of the modes of Linux's lvm2. We do have a geom_linux_lvm module
already, but I am not sure if it provides the required functionality.
It may be that we can use it as-is, it may be that we can extend it to
support what we need, or we could use geom_ventoy as a starting point
for something new.
3. Include geom_ventoy in our tree (after code review) and find a way
to have Ventoy write the mapping into it.
I believe that helloSystem (a FreeBSD derivative,
https://hellosystem.github.io/docs/) has already gone down this path,
so the first step is to see what they've tried and what works for
them.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
The second way is via block mapping, using some service to translate
offsets in the image file within the lower filesystem to physical
offsets in the underlying device. Linux has native support for this
via lvm2/dmsetup, and this is the mode that's used when I tried
booting a Ubuntu ISO via Ventoy. As it turns out NetBSD and
DragonflyBSD have a GPL'd lvm2 port, and presumably work the same way
with Ventoy. Ventoy's geom_ventoy FreeBSD kernel module works
similarly, just in a slightly hackish and Ventoy-specific way.
I want to clarify one item here, because it has come up again. I'veoffsets in the image file within the lower filesystem to physical
offsets in the underlying device. Linux has native support for this
via lvm2/dmsetup, and this is the mode that's used when I tried
booting a Ubuntu ISO via Ventoy. As it turns out NetBSD and
DragonflyBSD have a GPL'd lvm2 port, and presumably work the same way
with Ventoy. Ventoy's geom_ventoy FreeBSD kernel module works
similarly, just in a slightly hackish and Ventoy-specific way.
looked into how Ventoy operates, and it appears to require more than
just including the (BSD licensed) geom_ventoy.ko in our releases.
Ventoy stores the block mapping in the kernel module itself that it
then injects into the ISO image.
I think methods of supporting Ventoy, in order of "architectural elegance" are:
1. Mount the exFAT device and then mount the ISO image within. This
unfortunately requires FUSE as we do not yet have kernel exFAT
support. There's probably also a small performance penalty, but it
shouldn't be a significant issue in the context of an installer.
2. Use a geom module that provides arbitrary block mapping, akin to
one of the modes of Linux's lvm2. We do have a geom_linux_lvm module
already, but I am not sure if it provides the required functionality.
It may be that we can use it as-is, it may be that we can extend it to
support what we need, or we could use geom_ventoy as a starting point
for something new.
3. Include geom_ventoy in our tree (after code review) and find a way
to have Ventoy write the mapping into it.
I believe that helloSystem (a FreeBSD derivative,
https://hellosystem.github.io/docs/) has already gone down this path,
so the first step is to see what they've tried and what works for
them.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de