Error during installation on Vmware (VMware® Workstation Pro 25H2) Error : modprobe: FATAL: Module ntfs3 not found in directory /lib/modules/6.12.58-ipfire ntfs3 Module missing during installation. See: https://community.ipfire.org/t/ipfire-2-29-x86-64-core199-development-build-master-9745aa67/15285
Hello Phil, the NTFS kernel module has nothing to do with this problem. It probably wasn't loaded for a very long time. What kind of controller is your hypervisor emulating? What kernel modules do you have loaded inside the VM?
I installed vmware workstation on my arch linux system. Trying to install IPFire CU199 Testing I also got the same result of no hard disk found. Your question on the controller used made me go and look more closely at the default vm that vmware comes up with. By default it uses scsi for the hard disk. On my vm system I changed the hard disk from scsi to sata and the install was able to find the hard disk.
(In reply to Michael Tremer from comment #1) > Hello Phil, > > the NTFS kernel module has nothing to do with this problem. It probably > wasn't loaded for a very long time. > > What kind of controller is your hypervisor emulating? What kernel modules do > you have loaded inside the VM? I simply tested the installation of the ipfire-2.29-core199-x86_64.iso on my VMware test platform running Windows 11, as I do with every new version. I can confirm that by creating the hard drive as SATA, the installation works for CU199. You can close this bug report if you want, but it would be necessary to test it on other machines to be sure.
(In reply to Phil SCAR from comment #3) > I can confirm that by creating the hard drive as SATA, the installation > works for CU199. > > You can close this bug report if you want, but it would be necessary to test > it on other machines to be sure. I don't think this can be closed, yet. We want to be as compatible as possible with whatever we can reasonably support. When you say SCSI is the default, does this refer to virtio using SCSI? I am not sure if we have it, but could you run "lspci" on the other console?
We should fix this problem because with CU198 (previous dracut) IPFire installs with no problems with a virtual scsi hard disk specified. When I use the Custom (Advanced) virtual machine configuration option then the section for configuring the Virtual Disk Type has IDE SCSI (Recommended) SATA NVMe There is also a section for the SCSI I/O controller which has the options LSI Logic (Recommended) LSI Logic SAS Paravirtualized SCSI In both the above cases the recommended options are the ones already selected and if you use the Typical (Recommended) option for the Virtual Machine Configuration instead of the Custom (Advanced) then those recommended settings are the ones used by default. What is behind those virtual disk drives I have no idea and no idea how to find out. I changed to the IPFire console in vmware after the install had failed due to not finding the disk drive and tried the lspci command but it came back with command not found. Hopefully I checked in the right place.
Created attachment 1689 [details] Proposed patch Hello Adolf, could you test this change and rebuild the ISO? I think that dracut-ng is now configured to strip down the initramdisk as much as possible and that removes any drivers that won't be needed by the build system.
(In reply to Michael Tremer from comment #6) > Created attachment 1689 [details] > Proposed patch > > Hello Adolf, > > could you test this change and rebuild the ISO? > > I think that dracut-ng is now configured to strip down the initramdisk as > much as possible and that removes any drivers that won't be needed by the > build system. I tested the vmware with the existing CU199 Testing and confirmed that it couldn't find the hard disk and then immediately changed the source of the iso to the one built with your patch fix. It successfully found the hard disk and I was able to select it and it installed the filesystem, boot loader etc and ended up with the Reboot command. So the patch is confirmed to have fixed this problem.
(In reply to Adolf Belka from comment #7) > So the patch is confirmed to have fixed this problem. Perfect. Thank you for testing this. I just pushed a change that should do the same, but does it in the configuration file instead. That way, whenever we call dracut, we don't have to pass any extra command line switches: > https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=9f55a31459d6ca64f2827bc8eadb6e981245df75 The change was introduced in a default configuration file that was installed with dracut-ng: > https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=9457019809d8aa7dc1731a73e5edb131ce383026 I have removed all of those because we don't want them to interfere with our configuration. Once the nightly build is through, it would be good if you can check again that the changes in production are actually solving the problem, too.
(In reply to Michael Tremer from comment #8) > > Once the nightly build is through, it would be good if you can check again > that the changes in production are actually solving the problem, too. Tested and confirmed that problem fixed with the updated changes.
Tested Ok for me too with last ISO https://nightly.ipfire.org/master/2025-11-27%2011:15:11%20+0000-75ecc483/x86_64/ipfire-2.29-core199-x86_64.iso On Vmware Windows (VMware® Workstation Pro 25H2) with default Hard Disk.
Perfect. Thank you both for verifying.
Loosely related to this, I have pushed a commit that the NTFS module will no longer be loaded in the installer: > https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=1cc63f13e01067efd559698e9ab3c35640b38a95
https://www.ipfire.org/blog/ipfire-2-29-core-update-199-released