Hey ARM guys, I'm trying to build a custom Fedora32 aarch64 image for the RPI 3/4. I'm using the livemedia-creator (part of lorax) in QEMU mode on an RPI 4 which is running the minimal image from here: https://kojipkgs.fedoraproject.org/compose/32/latest-Fedora-32/compose/Spins/aarch64/images/ The install is going great and successfully completes but when DDing the image onto an SDCARD and booting a PI 3/4 with it, it hangs while it is discovering the root drive. After a bit of investigating DMESG, it turns out that initramfs never loads any drivers neccessary for the SDCARD to be discovered (mmc_block.ko, sdhci-iproc.ko, sdhci-pltfm.ko, sdhci.ko) and thus can't boot the final root filesystem. I can easily fix the problem manually by copying an initramfs from the working minimal image but I'd like to understand why dracut is generating the initramfs during kickstart without the SDHCI modules. After that fix I can boot the new image and when I run dracut from that system it generates the correct initramfs. My guess right now is that QEMU abstracts the storage system and dracut (or even depmod) doesn't see a need to include those kernel driver modules. Once the system is actually booted with the SDCARD hardware present it correctly includes those modules. This can be verified by manually running dracut -vvv in the %post section during kickstart and the output shows that it doesn't include any of the mentioned modules. I'm looking for a method to apply within the %post section of kickstart that lets me go around that issue. Looking at the anaconda logs, I can see that depmod is already running wit the -a flag which instructs it to include ALL modules so go figure. Thanks! _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx
