virtualbox-ose-guest-dkms: fix conflict with older vboxguest dkms mod…

[aaFn]

…ule in initramfs - see issue #58300

Testing the changes

• I tested the changes in this PR: YES

Local build testing

• I built this PR locally for my native architecture, x86 (ARCH-LIBC)

[classabbyamp]

this is a hacky workaround, not an actual fix.

the proper fix would be making this package rebuild the initramfs, like other dkms modules that get put in the initramfs:

void-packages/srcpkgs/zfs/template

Lines 20 to 21 in 597dfed

	# dkms must be before initramfs-regenerate to build modules before images
	triggers="dkms initramfs-regenerate"

void-packages/srcpkgs/nvidia/template

Lines 329 to 330 in 597dfed

	# dkms must be before initramfs-regenerate to build modules before images
	triggers="dkms initramfs-regenerate"

void-packages/srcpkgs/broadcom-wl-dkms/template

Line 13 in 597dfed

triggers="dkms initramfs-regenerate"

[ahesford]

I fail to see a good argument for including these drivers in an initramfs image. For that reason, I think triggering an initramfs rebuild in this package is unnecessary. Replacing an initramfs image involves some risk (albeit small) that the machine will be rendered unbootable, and it is not likely worth even a small risk for this package.

I'd be very slightly more receptive to shipping a dracut configuration snippet that omits this driver, but given that somebody might have a legitimate reason to include these drivers, I'm reluctant to do so. Overriding default behavior is generally undesirable.

Regardless of whether either of these options is pursued, the proposed workaround here is definitely not acceptable.

[sgn]

vboxguest doesn't need to be included into initramfs. It's not required for bringing up the machine.

[aaFn]

Thank you. If it is agreed here that vboxguest is not needed in initramfs, I guess that acting on virtualbox-ose would continue to be a workaround, since the root cause is present as soon as from the first install through the "Live-CD".

=> What would it take to reach a decision and get vboxguest removed from initramfs for a true solution ?
Is that something on which I can help ?

Else, happy to edit this PR into something more amenable if you desire, like trying and testing a dracut.conf with omit_drivers.
Although I presume that this implies a regeneration of initramfs, so is not addressing @ahesford's "small risk" concern.
Let me know.

[ahesford]

Not every manual intervention required to make a package behave like the user expects is a bug or demands resolution at the distribution level. This is especially true for Void, where we actively avoid making too many decisions for users and expect them to be actively involved in the administration of their systems. We've seen many times (for example, with pipewire) how adding our own "innocuous" configuration changes eventually leads to trouble for users, and ultimately becomes a problem for us as we seek to unwind an earlier decision when our assumptions are no longer (or never were!) valid.

You can reconfigure your Dracut installation to meet your requirements. I fail to see a good argument for shipping a default configuration to do so. That we cannot justify the inclusion of the VBox guest driver in an initramfs image does not imply that we have justified the explicit exclusion of it.

If this is anybody's problem to fix, it would belong to the upstream dracut-ng project. It is their process that too aggressively selects the driver for inclusion. I suspect that an alternative like 'mkinitcpio`, which is much more conservative about selecting drivers for the initramfs image, will be immune to this problem.

[aaFn]

Digging a bit, wouldn't that come from

void-packages/srcpkgs/linux6.12/files/x86_64-dotconfig

Line 8804 in 5a528af

CONFIG_VBOXGUEST=m

?

If I am correct, and not sure what is generating that file nor what is the source input behind it, I believe that "m" means "build it as a module in the kernel".
And still if correct, I can't find what is used as source code for that vboxguest module : the compiled .ko file contains no version indication, and clearly doesn't match with what is in virtualbox-ose.