Open nh2 opened 5 years ago
Also, what does this mean?
error: option not set correctly: USB_NET_DRIVERS (wanted 'y', got 'm')
Yes, if I write USB_NET_DRIVERS y
into extraConfig
, then I really do want y
!
Am I misunderstanding this?
USB_NET_DRIVERS may depend on other settings set to "m" which prevents USB_NET_DRIVERS y, that's why the script can't answer "y" and fails warning you. Thus you have to search for USB_NET_DRIVERS dependencies and set them to "y" as well.
USB_NET_DRIVERS may depend on other settings set to "m" which prevents USB_NET_DRIVERS y, that's why the script can't answer "y" and fails warning you. Thus you have to search for USB_NET_DRIVERS dependencies and set them to "y" as well.
Ah, I see. That makes sense.
Not sure if it's related, but I'm experiencing similar issues, albeit when overriding a musnix kernel (4.19.31) with structuredExtraOptions
.
I'm trying to enable TRANSPARENT_HUGEPAGES
, and the option never even appears in the list of questions.
The other options on the Memory Management page appear like they should. I checked the kernel source that is being used and the option does seem to exist 😕
you can check in a nix-shell how the configuration is generated, warnings appear at the end when nix was nox able to select a requested config item eval "$configurePhase"
you can check in a nix-shell how the configuration is generated, warnings appear at the end when nix was not able to select a requested config item
eval "$configurePhase"
I suppose I forgot to mention I'm using NixOps. Is there an easy way to initiate a nix-shell for NixOps deployments? Or would it be easiest to debug in a different manner?
you should run the nix-shell with the kernel version that is built by nixops for your machine. nixops builds it locally before sending the closure on the target so nixops doesn't make a difference.
Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:
still important to me
Hitting this too with linux 5.8-rc2
:
GOT: Defined at drivers/net/wireless/realtek/rtw88/Kconfig:28
GOT: Prompt: Realtek 8822BE PCI wireless network adapter
GOT: Depends on: NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_REALTEK [=y] && RTW88 [=m] && PCI [=y]
GOT: Location:
GOT: -> Device Drivers
GOT: -> Network device support (NETDEVICES [=y])
GOT: -> Wireless LAN (WLAN [=y])
GOT: -> Realtek devices (WLAN_VENDOR_REALTEK [=y])
GOT: -> Realtek 802.11ac wireless chips support (RTW88 [=m])
GOT: Selects: RTW88_CORE [=n] && RTW88_PCI [=n] && RTW88_8822B [=n]
GOT:
GOT:
GOT:
QUESTION: Realtek 8822BE PCI wireless network adapter, NAME: RTW88_8822BE, ALTS: N/m/?, ANSWER: y
repeated question: Realtek 8822BE PCI wireless network adapter at /nix/store/ri66gafl5xrrqkf5jssjpj10xd1jad3n-generate-config.pl line 81.
Error in reading or end of file.
Error in reading or end of file.
Error in reading or end of file.
I marked this as stale due to inactivity. → More info
still
@snajpa I'm hitting the exact same repeated question while bisecting for a bug introduced between 5.7 and 5.8 that makes my VMs hang for minutes at a time. Is there anything I can define so generate-config.pl
answers with, say, m
, as, according to its comments, it's attempting to do anyway?
@JenniferPadilla I don't have the answer for you, but when I had to bisect a kernel (that's also how I found this bug), I worked around it by bisecting + building "outside of nix", that is, I prepared the build environment nix-shell once, and ran make -j
in git bisect
, to quickly build successive kernels, instead of doing a full nix-build
every time.
Like nh2. also we should use a structured extraConfig like is done in the rest of the kernel configuration and deprecate the legacy "extraConfig" setting. Otherwise we lose an opporunity to detect conflicts in the nix configuration.
@nh2 I found that if you add kernel configuration items to an extraConfig
key of any boot.kernelPatches
member, just as if you'd add any old kernel config for your own purposes, then that's already sufficient to override the wrong guesses generate-config.pl
makes. So just add RTW88_8822BE
and RTW88_8822CE
as appropriate.
spews out tons of
Error in reading or end of file
same with linuxManualConfig
but i dont see how the interactive prompt is answered 0__o
when i run make oldconfig
in a terminal, it blocks waiting for my input
it keeps failing with
repeated question
not here. in my case the build continues
I marked this as stale due to inactivity. → More info
still, I'm packaging linux with custom source.
Update: Disable autoModules
in buildLinux
works fine for me.
But it seems this will cause different derivation calculation between "build with nix only" and "build on NixOS"? Some options will be true on NixOS, but false on "nix only" build.
I think I understand what's going on here. I had this issue and fixed it by changing some =lib.kernel.yes
options to =lib.kernel.module
. The problem was that a prerequisite option was set to module, and so answering y
is invalid. You can see what option is having causing problems (one at a time) by scrolling up to the first message before all the Error in reading or end of file.
s
You can see this in the original problem:
USB Mass Storage support, NAME: USB_STORAGE, ALTS: M/n/?, ANSWER: y
M/n/?
are the possible options, module, no, or ?
(help). But then generate-config gave it ANSWER: y
and then everything breaks
USB_NET_DRIVERS may depend on other settings set to "m" which prevents USB_NET_DRIVERS y, that's why the script can't answer "y" and fails warning you. Thus you have to search for USB_NET_DRIVERS dependencies and set them to "y" as well.
The answer was here the whole time. What is this issue about exactly? A better error message?
Just ran into a similar issue where I had to use the kernelPatches extraConfig workaround.
the configuration script kept reading DRM_PANEL_BOE_TH101MB31UIG002_28A
before its dependency BACKLIGHT_CLASS_DEVICE
and would fail.
Issue description
I have the fealing that the
generate-config.pl
script is pretty bugged, it keeps failing withrepeated question
and spews out tons ofError in reading or end of file.
afterwards when trying to useboot.kernelPatches.extraConfig
:Output:
and lots more of that, eventually failing with
builder for '/nix/store/jjmxf3ivfp7xbz0y9bcqd9swvfrrc6h9-linux-config-4.4.178.drv' failed with exit code 255
.Indeed, it asked a question twice, should the script handle that if stuff is being patched?
Steps to reproduce
Technical details
On commit 05a53ecd827c5910e34171e7681c56913b29add1