-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use conditionals for all architecture dependent initrd modules #109280
Comments
So a quick way to find places where issues will pop up, is to look at previously successfully builds (The log of |
We should consider this as a temporary stop gap measure, but what we really want to do here is make the module system less opinionated on the list of default modules. |
Perhaps have two lists? One where failure is OK and another one where failure is fatal? |
The thing is, we actually do want the build to fail, if somebody makes a typo in their config. So if we have a list of "optional" modules, we should somehow distinguish those cases. |
@delroth since you have a custom kernel setup, would it help if the list in |
I think all-hardware.nix is only really used in rare situations e.g. building installer images or livecd or such, I personally don't really care about it. Really the main issue is that the NixOS module system allows for modules merging things into a list but not for modules filtering things out of a list -- given that I have a "weird" config due to having to use a custom built kernel, I would be OK with having to manually filter out the default modules I don't have, but that's not something that can easily be done :( (mkForce overrides the list completely, so that breaks the "other modules merging things into the list" part of the problem.) |
One way I can imagine is to convert the lists into attrsets. That's seems the usual approach to cases when you have a list in NixOS config and you actually need to remove parts. |
The image builder profile adds modules to the available kernel modules:
This profile is also used by the Raspberry Pi 4 sd image, which uses an alternate kernel and configuration. In turn, see #111683, this module is not present on that specialized configuration. The solution should make it possible for users of the NixOS options to "maybe add modules" too. Just saying in case it wasn't the foregone and obvious conclusion :). |
An update to my last comment: The image builder does not do this anymore. The
We also do not have the Pi 4 SD image files anymore. |
I marked this as stale due to inactivity. → More info |
Workaround from here (actually from @cleverca22): {
/* ... */
overlays = [
(final: super: {
makeModulesClosure = x:
super.makeModulesClosure (x // { allowMissing = true; });
})
];
/* ... */
} Hopefully I'll find it quicker next time if I mention it here. |
This is a meta issue to track the changes that are required since we've merged #78430 (resulted in some channel blockers: #109252).
This is important for everything that is part of
modulesClosure
(allowMissing
is nowfalse
):But for missing firmware we only print a warning: 49130f9
Relevant commits:
Open/unresolved issues to consider:
Potential improvements:
allowMissing
that defaults tofalse
?The text was updated successfully, but these errors were encountered: