This repository has been archived by the owner on Dec 7, 2023. It is now read-only.
Configure dmsetup to fallback to managing device nodes without udevd #654
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch frees up dependent interactions with udev for device node creation.
Ignite can now create boot devices in absence of a working udevd equivalent.
This makes ignite easier to run in docker containers and WSL2.
I wrote a similar implementation (no_udev_sync) which completely bypassed udev sync even when present.
It execs
dmsetup info
to retrieve block device paths and manages its own symlinks, but I found this implementation gets sort of coupled to/dev
in the root mount namespace becausedmsetup info
will return the canonical device-path of/dev/dm-$i
.It's simple and possible to call
mknod /dev/dm-$i -m600 253 $i
and ensure the device node exists withno_udev_sync
.I decided to try using the built-in udev fallback from
dmsetup
which is what is implemented in this PR.Note it's possible to actually get working behavior with older builds of ignite by setting
DM_DISABLE_UDEV=1
, but this requires the user to know about udev and potentially passthrough their env to sudo.I found in
dmsetup
's changelog that the--verifyudev
fallback actually used to be the default behavior.I didn't look further, but I assume this was disabled, because it could be potentially harmful if you created devices during boot before udevd started up.
I figure that silently having udev rules not apply is fairly low-risk for ignite boot devices -- if people are using ignite during boot, they should be configuring their units at the proper run-level, but it is a consideration.
The trade-off is that if we accept this bit of informal fallback behavior, users don't have to configure
dmsetup
, and ignite can use dmsetup in containers without mounting/dev:/dev
*.Note:
losetup
does not seem to currently have any device node management.In order for
losetup
to work in a container without mounting/dev:/dev
you need to pre-create some loop device nodes in the container like so:Other Changes: