<multi>
qyliss: okay, i've had a brief read of the patch -- the following references are based against current crosvm-demo HEAD on spectrum-os.org cgit
<multi>
qyliss: lines 19-21 of start-vm.nix -- is importing PATH necessary when you immediately re-export it?
<multi>
qyliss: you might also want a .s6-svscan/crash script (line 26 or so), though for such a minimal VM there might not be much that you can really do in terms of crash handling, so that's perhaps a debatable point
<multi>
qyliss: if you have a devtmpfs mounted at vm start, it might be worth explicitly redirecting standard output and standard error to the console
<multi>
qyliss: i have some old (and lightly modified) stage 1 execline init scripts generated by pre-1.0.0.0 s6-linux-init which might be of use if you want a copy
<multi>
qyliss: depending on how much environment stuff you're trying to configure in the stage 1 script, it might be worth building an in an envdir loaded with s6-envdir
<multi>
qyliss: this might just be personal taste, but if it were me writing the stage 1 script, i'd do all the filesystem mounting in lines 31 to 34 outside of the background block
<multi>
qyliss: (though the value of error recovery that could give you is debatable this early in the boot process is debatable)
<qyliss>
multi: you're right re: importing path
<qyliss>
I used to use the original value, but no more, and forgot to delete that line
<qyliss>
multi: stdout/stderr are already going to the console
<qyliss>
I based this on the pre-1.x output of s6-l-i-m fwiw
* multi
nods
<multi>
the old scripts i have around have been edited, and i don't remember what those edits were
<multi>
but they do explicitly set stdin to /dev/null, and stdout and stderr to the catch-all logger (which in spectrum's case is the console)
<multi>
i guess what i'm trying to say there is "better explicit than implicit"
<multi>
oh, there's also a "cd /" in there too as a sanity safeguard
<qyliss>
multi: got a name/mail I can Thanks-to in the commit message? I can also leave it out if you'd prefer.
<multi>
qyliss: see pm
<qyliss>
lgo
<qyliss>
Customising the kernel configuration is starting to bite me
<qyliss>
I might have to give up on overriding the Nixpkgs kernel config and configure my own from scratch
<qyliss>
Because it's very difficult to tell what the prerequisites are for config options I want to set when I can't use menuconfig.
<tilpner>
You can use menuconfig, but it's annoying
<qyliss>
Oh I can? How?
<tilpner>
Build config.boot.kernelPackages.kernel.configfile for your initial .config
<tilpner>
Then go to your kernel checkout and do nix-shell -E 'with import <nixpkgs> {}; unstable.linux_5_4.overrideAttrs (o: {nativeBuildInputs=o.nativeBuildInputs ++ [ pkgconfig ncurses ];})'
<tilpner>
make menuconfig and do your changes
<tilpner>
Then you can diff the menuconfig-created and nixpkgs-built configs until they match
<tilpner>
May have to do sorting/normalisation
<qyliss>
Oh nice
<qyliss>
I'll give that a try
<tilpner>
It's tedious, but still better than trying options at random and waiting another 5 hours
<qyliss>
I can build a kernel in a few minutes
<qyliss>
(I have access to a big build machine)
<qyliss>
But even then I wasn't getting anywhere with my "stab in the dark" approach
<lejonet>
Well, you can always grep for the stuff in the Kconfig and it'll tell you what it depends on... :P
<qyliss>
That's what I was trying
<lejonet>
sadly the Kconfig are a recursive mess when not using like menuconfig :/
<qyliss>
It's hard with things like CONFIG_VIRTIO which are set by other things
<lejonet>
s/are/is/
<lejonet>
Yeah
<qyliss>
I tried for hours last night
<qyliss>
Even when I was extremely confident it should be being set to y it was still stuck on m
<lejonet>
so what I would do is as tilpner suggested, but only use menuconfig to easily get the "DEPENDS" lines
<qyliss>
I tried that
<qyliss>
but see above :(
<lejonet>
:/
<lejonet>
Well, then you might have the cause that I was having on my desktop, that the kernel derivation overrides some things, unconditionally...
<lejonet>
I had to make my own kernel derivation (ofc based on the original one) to get a hardened kernel that nixpkgs-wise supports 32-bit binaries...
<qyliss>
yikes
<qyliss>
Where does this unconditional override happen?
<lejonet>
Yeah... setting features, which is checked by nixpkg packages, wasn't really overridable, or my nix-fu isn't strong enough (which is a completely plausible explanation too)
<lejonet>
Hmm, let me look, the whole kernel package in nixpkg is... interesting, there are many moving parts to it lol
<qyliss>
yeah
<lejonet>
hmm, you use the structuredExtraConfig to set stuff right?
<lejonet>
Because iirc that is the attrset that you need to override stuff on
<lejonet>
and if its m, that must mean one of its depends is m, because even with y, one that has its depends as m can't really be done, depending on how the dependency actually look
<qyliss>
lYeah
<qyliss>
I did try setting MODULES = y in generic.nix (with s/module/yes/g in common-config.nix)
<qyliss>
And at that point it worked
<qyliss>
Now, since my VMs have no support for loading kernel modules, it might make more sense to just proceed with that sort of thing, if I could do it in a cleaner way
<lejonet>
Well, you probably don't want all the crap that a default built kernel does have honestly, but its a good start
<qyliss>
Yeah
<qyliss>
At some point™ I'll definitely configure my own kernels
<qyliss>
But there will be a lot of things in the Nixpkgs config I do want to carry over
<lejonet>
yeah, the more you can "ride on" nixpkg the better, less to maintain
<qyliss>
That too
<qyliss>
I think this will end up being a case where it's easier to just have our own seperate configurations, though.
<tilpner>
If you want a minimal kernel, yes
<lejonet>
yeah, kernels are always special cases
<lejonet>
it would be awesome if there was an easy way to recursively parse Kconfig so that you could like rdep <kernel opt> <path to kernel source> and get a list of all the dependencies
<qyliss>
In theory menuconfig tells you that
<qyliss>
Or, well, not recursively
<lejonet>
Yeah, because the immediate depends are easy, as you say, menuconfig tells you that, but then those options might have dependencies too, which is what I think you've hit here
<qyliss>
This is really weird
<qyliss>
There's no other difference between menuconfig and what I'm generating now, and this still doesn't work
<lejonet>
O.o
<qyliss>
The thing I'm trying to do is add CONFIG_HW_RANDOM_VIRTIO=y, if anybody feels like having a go
<lejonet>
Seems logical that HW_RANDOM_VIRTIO would require HW_RANDOM
<lejonet>
iirc HW_RANDOM is "just" the submenu choice
<tilpner>
I don't know what happens if you do CONFIG_HW_RANDOM_VIRTIO=y but CONIFG_HW_RANDOM=n
<lejonet>
most likely HW_RANDOM_VIRTIO gets ignored
<tilpner>
Thus my question
<lejonet>
And yeah, it would seem like HW_RANDOM is for the actual HW RNG support, and then HW_RANDOM_VIRTIO depends on that
<lejonet>
and VIRTIO doesn't really seem to be a togglable thing (HW_RANDOM_VIRTIO depends on VIRTIO and HW_RANDOM) so the options you probably need to set to enable it is VIRTIO_PCI (which sets VIRTIO=y), HW_RANDOM and then HW_RANDOM_VIRTIO
<lejonet>
VIRTIO_PCI depend on PCI and VIRTIO_MENU
<lejonet>
and if VIRTIO_PCI is m, HW_RANDOM_VIRTIO can only be m too
<lejonet>
qyliss: so add HW_RANDOM=y and HW_RANDOM_VIRTIO=y should work
<qyliss>
That was the first thing I've tried
<qyliss>
or are you saying that you tried it and it worked for you?
<lejonet>
odd, nah I haven't tried, just going from poking around in menuconfig
<lejonet>
have you confirmed that you get VIRTIO_PCI=y inside the VM? It stupidly enough might be hidden behind VIRTIO_MENU, but I have a hard time seeing that being the actual issue honestly
<lejonet>
oh, it does have that, but default for VIRTIO_MENU is supposed to be =y so
<qyliss>
exactly
<lejonet>
same with PCI, it has =y as default, and that should be all the deps HW_RANDOM_VIRTIO needs, because expanded you could say it depends on PCI, VIRTIO_MENU, VIRTIO and HW_RANDOM
<lejonet>
Hmm, the error I'm getting with HW_RANDOM_VIRTIO is not directly that it doesn't like =y on it, but that the question is repeated...
<lejonet>
(that is apparently a die clause in the perl script that generates the .config)
<qyliss>
That's the error you get for any invalid option
<qyliss>
At least IME
<qyliss>
It is not a particularly nice developer experience, but it is what we have