Skip to content

Allow setting read/write, UUID and volume name options for EXT4 file systems#2199

Open
pojntfx wants to merge 3 commits into
microsoft:mainfrom
loopholelabs:add-read-write-uuid-volume-name-options
Open

Allow setting read/write, UUID and volume name options for EXT4 file systems#2199
pojntfx wants to merge 3 commits into
microsoft:mainfrom
loopholelabs:add-read-write-uuid-volume-name-options

Conversation

@pojntfx

@pojntfx pojntfx commented Jul 10, 2024

Copy link
Copy Markdown

Currently, file systems generated by the tar2ext4 tool lack a volume name and have their UUID set to 0000-...., despite the superblock in the internal package having the fields available. This PR allows to optionally set these fields with ReadWrite() Option, UUID(uuid [16]byte) Option and VolumeName(volumeName [16]byte) Option. The existing behavior does not change as a result of this.

@pojntfx pojntfx requested a review from a team as a code owner July 10, 2024 21:21
@pojntfx

pojntfx commented Jul 10, 2024

Copy link
Copy Markdown
Author

@microsoft-github-policy-service agree company="Loophole Labs"

…T4 file system writer

Signed-off-by: Felicitas Pojtinger <felicitas@pojtinger.com>
@pojntfx pojntfx force-pushed the add-read-write-uuid-volume-name-options branch from 2f57b0f to 9361934 Compare July 18, 2024 18:04
@katiewasnothere

Copy link
Copy Markdown

Hi @pojntfx, thanks for the contributions!

Could you provide a use case for the disk to be read/write? This tool was originally created for converting Linux container image tar files into VHDs that can be used on windows to run hypervisor isolated Linux containers. In this context, the VHDs shouldn't be read/write (though I have heard of some corner cases 😅).

@pojntfx

pojntfx commented May 15, 2025

Copy link
Copy Markdown
Author

Hi @katiewasnothere, sorry about the long delay. We have almost the exact same use case - we take an OCI image, extract it with umoci into an OCI runtime bundle, put it onto an EXT4 file system with hcsshim, mount it in a VM & start it with runc. In our case, we'd like those file systems to be read-writable. We also need to have a proper UUID & volume name so that we can mount it at an expected path, e.g. with a fstab like this:

LABEL=@OCI_RUNTIME_BUNDLE_MOUNT_LABEL@    /@OCI_RUNTIME_BUNDLE_MOUNT_DIR@    ext4    defaults    0    2

Same goes for #2325 - once the disk is read-writable and has a proper UUID & volume name, we'd like to be able to add extra free space for it.

A workaround for this issue ofc could be to use something like overlayfs, but in our case that's not really an option for performance reasons.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants