Hey all, I know a lot of changes have been made to the discovery image recently so I’m not sure if there’s an issue with the latest commits to the repo or if there’s just something wrong with my environment. I’m trying to update our customized discovery image to use the latest source since it seems to resolve some issues we were having on specific baremetal hardware models during pxe-less provisioning. However when ever I attempt to build the latest version available in the github repository I get an error stating the facter gem is unavailable to install.
Additionally when I remaster the existing FDI, it completes successfully but when I go to write it to a removable drive the partition layout is missing.
I’ve attempted this on both a clean vm with the no-virt option and a baremetal install of centos 8 stream. I do not have foreman installed on either of these machines though, the instructions are unclear if that is a prerequisite. I’ll be attempting that later today but thought I would at least get a post created in case that doesn’t resolve the issue with building from scratch. There is still the issue with remaster however.
Problem:
When attempting to build FDI 4.0.3 from source, anaconda spits out an error stating the facter gem cannot be found. FDI remaster also does not write partitions for booting from the image.
Expected outcome:
Build-livecd-root results in a successful build of FDI. Discovery remaster outputs an iso with customizations and can written to removable media and booted from. Foreman and Proxy versions:
3.1.2
Distribution and version:
Centos 8 Stream
Other relevant data:
I’ll add some logs here once I get a chance to, My previously logs were wiped when I had re-imaged my test machine with Centos Linux 8.5 just in case it was an issue with stream, but after digging through the repo it’s obvious I should be using stream.
Hmmm I swear this worked the other day. I am looking into this, but I don’t remember adding any extra repository. Did we stop carrying rubygem-facter in our repos recently? @packaging
Without looking deeper into it, I see “All matches were filtered out by modular filtering for argument”. So if I recall it correctly the repos were changed from using module_hotfixes=1 to provided modules themselves. So perhaps a matching dnf module enable somewhere is needed. Hope this points in the right direction.
Thanks for the response. After looking through the kickstart files it looks like the repos being used are the nightly builds. Should this be the case? I’ve tried switching to the 3.2 release repos but have the same results.
After disabling the following packages in 20-packages.ks I’m able to successfully build. It does look like the packages are available in both nightly and 3.2 release repos
facter
foreman-discovery-image-service (errors out when attempting to install sinatra dependency)
foreman-discovery-image-service-tui (errors out when attempting to install rubygem-fastgettext)
So I installed CentOS 8 Stream and I have learned that dnf behavior was probably changed, now additional repositories have their own module?
[root@centos8 ~]# dnf module list
Repository 'foreman-nightly' is missing name in configuration, using id.
Last metadata expiration check: 0:00:05 ago on Tue 24 May 2022 09:46:10 AM CEST.
CentOS Stream 8 - AppStream
Name Stream Profiles Summary
389-ds 1.4 389 Directory Server (base)
... cut ...
varnish 6 [d] common [ Varnish HTTP cache
d]
virt rhel [d][e] common [ Virtualization module
d]
foreman-nightly
Name Stream Profiles Summary
foreman el8 installe Foreman module
r
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
So after foreman module is enabled, I can install the required package: dnf module enable foreman:el8. Looks like this needs to be added to the kickstart.
To your question about partition - the remaster script just unpacks the ISO, reconfigures bootloaders and then makes a new ISO and then it performs isohybrid --partok --uefi. Can you try this command alone? Do you have it installed?
Adding those modules fixed the issue with building. However now when I attempt to boot on some hardware I’m getting a kernel panic. When I boot the same image on a vm it gets to discovery just fine. I’m guessing this is just something to do with a missing kernel option I need to add.
@lzap Had a chance to look at this again. Turns out the wireless hardware is what’s causing a kernel panic when booting the FDI, Testing in a VM works fine and the issue is only present when booting on bare metal with a device that has the wireless device enabled. Whats curious is the release version of the same image works just fine on this same hardware.
Are there some additional options applied to the release image that I may be missing?
I kick off the build with the below options.
sudo ./build-livecd-root dev /var/lib/libvirt/images/ "proxy.url=https://example.com proxy.type=foreman fdi.pxauto=1 fdi.ssh=1 fdi.rootpw=example" nonvirt
Oh damn, can you tell which driver is the one that is causing pain? We can perhaps remove it from FDI. We already do remove a lot of drivers (those with wifi in the name). This one might be named differently.
It’s an Intel wireless 9000 series. Looking at the packages kickstart I see a lot of the intel wireless drivers are removed so I’m not sure if it’s still included.
iwlwifi-9000-pu-b0-jf-b0-46 is what it appears to be trying to load.
As I mentioned previously, This issue doesn’t exist with the release/prebuilt discovery image. Only when I manually build it. Disabling wireless in the bios prevents the kernel panic and the issue isn’t present when testing in a VM.
I suggest to remove the driver anyways, can you file a PR to our repo with a “rm” statement that removes the file that is causing issues? I can then trigger nightly rebuild and you can test the official image.
I am not really sure what you are doing wrong and why your build would not work
