qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
<MichaelRaskin> (I do get initramfs shell, and can access nd modify the stateful storage provided as rwdisk)
tilpner has joined #spectrum
MichaelRaskin has quit [Quit: MichaelRaskin]
<IdleBot_9cfd8a4c> Status update: when running CrosVM as user, 9p works only with --disable-sandbox. NixOS VM does not work anyway: for some reason overlayfs works fine with Qemu 9p but not with CrosVM 9p
<qyliss> IdleBot_9cfd8a4c: Have you tried getting it to boot from a rootfs, with no initrd?
<IdleBot_9cfd8a4c> I wanted to use a Hydra kernel, so no
<qyliss> Would be interested to see if you could get it to work.
<IdleBot_9cfd8a4c> I wonder how small an initramfs is needed to mount the RO store over 9p… maybe it would be easier and not too slow
<IdleBot_9cfd8a4c> qyliss: you are specifically interested in rootfs without initramfs?
<qyliss> Yes -- I don't see any point having an initramfs
<IdleBot_9cfd8a4c> Well, avoiding kernel rebuilds…
<IdleBot_9cfd8a4c> Although in our case we could build something just large enough to use 9p or tftp
<IdleBot_9cfd8a4c> (in the same way a normal boot sequence would use initramfs)
IdleBot_9cfd8a4c has quit [Remote host closed the connection]
IdleBot_59b8da4c has joined #spectrum
<IdleBot_59b8da4c> But if we want any kind of tmpfs, we can just as well use initramfs, too
<qyliss> We'll build our own kernels anyway -- kernel rebuilds don't really matter.
<IdleBot_59b8da4c> Well, eventually maybe yes, but I want least amount of work before something useful happens (then iterate)
<IdleBot_59b8da4c> qyliss: re: no-initramfs: do you have a promising enough kernel config?
<qyliss> All I really tried was the Nixpkgs kernel with ENABLE_SQUASHFS=y
<IdleBot_59b8da4c> Did it have any block device as Y??
<qyliss> I suppose not?
<IdleBot_59b8da4c> And how was it supposed to read the image?
<qyliss> crosvm magic?? :P
<qyliss> I'll admit I don't know exactly where the seperation between vmm and kernel is in setting up devices and stuff
<IdleBot_59b8da4c> I thought VM magic boils down to vda block device which still needs _some_ block device support in kernel!
<multi> IdleBot_59b8da4c: that aligns with my understanding
<IdleBot_59b8da4c> CONFIG_VIRTIO_BLK=Y is highly recommended if you want your kernel to actually see vda
<multi> qyliss: afaiui, the hypervisor provides an emulated block device to the guest, which the guest then requires block device drivers to access
<multi> IdleBot_59b8da4c +1
<IdleBot_59b8da4c> That explains the squashfs failure, I guess…
<IdleBot_59b8da4c> Still unsure why sandbox+nonroot+9p=fail
<IdleBot_59b8da4c> I wonder if one cann connect third-party virtio providers without compiling them into the CrosVM…
<multi> i would offer to poke at things, but i have neither the time spare nor a hypervisor machine i can through up a nixos vm on ^^"
<qyliss> No need for a NixOS vm
<qyliss> You just need a Nix installation
<IdleBot_59b8da4c> NixOS VM is not strictly speaking necessary at any point
<qyliss> You can get it from apt in debian nowadays I think
<multi> qyliss: not seeing anything, unless i'm not getting the package name right
<qyliss> Might still be in testing or whatever
<multi> not seeing anything on packages.debian.org either (under the search term "nix")
<multi> ooooooh hello
<multi> i can probably work with that and feed that into my automagic package generation tooling
<multi> inb4 i turn into that weirdo who runs nixpkgs-on-debian...
<qyliss> not that weird
<multi> i dunno how common or not doing that sort of thing is
<qyliss> it's not uncommon
<multi> fair enough
<qyliss> Linux Nix users are generally either on NixOS or Ubuntu/Debian, IME
<qyliss> At least the ones I hear from
<multi> huh, til
<multi> how much does nixpkgs assume that you're running systemd? my debian machine is a bit of a frankenmess running with s6
<qyliss> none
<qyliss> It doesn't install units or anything
<qyliss> That's NixOS's job
<multi> right. just checking as this debian packaging has systemd-ish stuff involved, which i don't totally understand
<qyliss> Nix itself has a daemon
<qyliss> Which you don't have to use, but does nice things
<qyliss> So I imagine the Debian package comes with a systemd unit for that
<multi> looks like it
<multi> i can hack around that by just running it in a root-owned tmux for now tbh
<qyliss> You can also just not use the daemon
<qyliss> Or, well, I don't know about with the Debian package
<multi> what nice things does the daemon do?
<qyliss> Means you don't have to own the store, for one
<qyliss> Which is important if you have multiple users
* multi nods
<qyliss> Untrusted users don't have to be able to write to the store
<qyliss> Only root or whatever
<qyliss> That's basically it
<multi> okay
* multi hacks on debian package's dependencies to make it actually installable on her laptop, rebuilds
pie_ has quit [Quit: pie_]
<IdleBot_59b8da4c> Re: Nixpkgs and systemd: I dropped NixOS with one of the annoyances being systemd, I run a weird something based on Nixpkgs, I have no problems
<IdleBot_59b8da4c> nix-daemon is quite useful, but you basically run it as nix-daemon without arguments, so you should be able to make it work with any init system
pie_ has joined #spectrum