Qubes packages (Its alive!) #341215
Qubes packages (Its alive!) #341215
Conversation
There was a problem hiding this comment.
The python files need a meta attribute set. Since a lot of the Qubes tools are GPLv2 and have the https://qubes-os.org homepage, we could deduplicate the meta attributes in a common file that is inherited and // updated as needed.
|
|
||
| qubes-core-qubesdb = toPythonModule (pkgs.qubes-core-qubesdb.override { | ||
| inherit python; | ||
| withPython = true; |
There was a problem hiding this comment.
Might be better to make the main derivation have withPython ? true, and drop the override.
There was a problem hiding this comment.
Well, we still need to build this package using specific python version, thus override is inevitable
| gtk3 | ||
| ]; | ||
|
|
||
| # Should also be packaged as vm-only? |
There was a problem hiding this comment.
A split output package sounds good here IMO.
There was a problem hiding this comment.
I think current approach with passthru is okayish, as those packages are tightly bound.
Proper splitting will require a qubes package set, which I want to avoid.
| mv $out/usr/* $out/ | ||
| rm -rf $out/usr | ||
| # Scripts: qubes-rpc-multiplexer | ||
| cp ../lib/* $out/bin/ |
There was a problem hiding this comment.
| cp ../lib/* $out/bin/ | |
| cp ../lib/* $out/libexec/ |
Very optional. If it breaks something, revert to $out/bin. Having executable libraries on libexec would make this more cohesive with the xen package.
There was a problem hiding this comment.
It is installed to bin, it is just located in lib in source code.
I want however to split some of sbin binaries to libexec
|
Pushed other batch of qubes fixes, now you can actually somehow manage VMs using qubes-manager, given that you have installed templates somehow (E.g you can copy VMs from other qubes installation). Standard qvm-template doesn't work, because it uses RPM to install such packages. @SigmaSquadron xen needs python module, do you think it is possible to split it from xen package? At least separate output will do, but ideally it needs to be built fully independently, since xen is a large package. |
|
Forgot to cherry-pick some changes from my workstation nixpkgs. Sorry for the dirty git history, I will rebase and clean it up after more polishing. |
I'm all for splitting the Python stuff from the main package, but I have no idea how to do that or how circular dependencies are even supposed to work in the first place.
Feel free to dump everything in the draft PR. We can always beat the git history into a shape later. |
Well, they don't, derivation circular dependencies needs to be resolved somehow. Some can be merged together, some can be updated to be loosely coupled (E.g use PATH or specific runtime environment variables), but they need to be fixed, derivation can't depend on itself (Except for $out, but it is only known at runtime), because derivation hash = hash of its inputs. Right now, both of discovered dependency cycles are resolved using absolute system installation paths, and I'm not sure of a proper solution. |
|
Some more information for the module: Qubes' boot parameters: virtualisation.xen.bootParams = [ "smt=off" "gnttab_max_frames=2048" "gnttab_max_maptrack_frames=4096" ];Use the C-based XenStore (as Qubes doesn't use virtualisation.xen.store.path = "${pkgs.qubes-vmm-xen}/bin/xenstored";Also, any systemd services brought in by the module need to have their |
Yeah, of course, this is just a rough draft of how it should look, nothing work in this nixos module yet. BTW, qubesd has non-critical crash on service stop when using python 3.11 due to new python features being used (QubesOS/qubes-core-admin@23be00c), and I can't upgrade it to 3.12 because of meson regression in Xen, do you have idea on how to fix that? #253751 |
The hacky solution is to |
|
Thrown even more broken code into the pile, now it is able to generate menu entries for VMs, and recognize PCI device names. Nixos module is still broken, but now it might start most of the required things by itself. |
This hacky solution sounds good enough for now, I don't know how many of the bugs are caused by python version older than upstream wants. |
CertainLach
changed the title
CertainLach
changed the title
|
Latest changes make it run in KDE Wayland session. There are still many bugs, but basic functionality works perfectly fine. |
| # Bug: | ||
| # Loopback vchan connection not supported | ||
| # FATAL: vchan initialization failed | ||
| # Solution: Xenstore has no set domid | ||
| # It can be set manually using | ||
| # `run0 xenstore-write "/domid" 0` | ||
| # However it should always be set by default by something, | ||
| # and I am not sure how/where. | ||
| # FIXME: Is this still relevant? I don't remember where I have encountered this error, | ||
| # but I no longer have this problem. | ||
|
|
||
| # Bug: | ||
| # Not enough memory during start of VM | ||
| # Solution: | ||
| # Qubes memory manager overrides max memory of dom0 with | ||
| # total memory available, you need to set memory limit for it. | ||
| # I have no idea what writes this memory limit in QubesOS, but | ||
| # it can be set manually: | ||
| # `run0 xenstore-write /local/domain/0/memory/static-max 100000000` | ||
| # Note that the standard `xl mem-set` doesn't work for that, as it | ||
| # uses /vm/uuid/memory field instead. | ||
| # FIXME: Permanent solution needed. |
There was a problem hiding this comment.
Both of those looks like missing xen-init-dom0 call (normally a systemd service of this name, calling /usr/libexec/xen/bin/xen-init-dom0) - part of xen package
There was a problem hiding this comment.
First problem is fixed even without domid key.
I believe it was caused by hostname being not dom0, thus causing qubes-core-admin-client to misbehave, because it can't find domain according to hostname (qubes expects adminvm to have name == dom0 with no ability to change it, and if dom0 hostname is not dom0 - then it can't detect that current domain is dom0)
This was fixed by changing default dom0 hostname to dom0, and by setting qubesdb /name key to dom0 (Which is used as an alternative method of hostname detection) for the cases where you can't use dom0 as hostname.
There was a problem hiding this comment.
qubes expects adminvm to have name == dom0 with no ability to change it
Right... I know it's stupid, but unfortunately it's hardcoded in too many places right now...
There was a problem hiding this comment.
qubesdb /name workaround works well for everything
|
This branch is a little bit outdated, I'm debugging issues occured after nixos rebase. For some reason, installation of StandaloneVM stopped working, qemu window appears, but it is always empty. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
CertainLach
force-pushed
the
qubes-packages
branch
from
9697e80
to
172bd09
Compare
CertainLach
force-pushed
the
qubes-packages
branch
from
172bd09
to
5e6f44b
Compare
|
Rebased&Cleaned up the whole history. StandaloneVM installation is still broken, I believe this is caused by some upstream (qubes or nixos) changes, as I don't see any relevant changes between rebased and not rebased version of this PR. |
| + // in QubesOS that works well: /bin/qubesdb-read => read, however in nixos, path before can contain a -: | ||
| + // /nix/store/aaaaaa-qubesdb/qubesdb-read => qubesdb/qubesdb-read, which is not a valid qubesdb command. | ||
| + // Fix it by first taking a filename (=removing all components ending in /) of a path. | ||
| + cmd_argv0 = argv[0]; |
There was a problem hiding this comment.
TODO: replace with basename() call, and submit this patch upstream
| shmoverride.so: shmoverride.o ./list.o | ||
| $(CC) $(CFLAGS) $(extra_cflags) -shared -o shmoverride.so \ | ||
| - shmoverride.o list.o -ldl -lxenctrl -lxengnttab -Wl,-Bsymbolic | ||
| + shmoverride.o list.o -ldl -lxenctrl -lxengnttab -Wl,-Bsymbolic -Wl,-z,initfirst |
There was a problem hiding this comment.
Help of someone with dynamic linking knowledge is wanted here.
While -z initfirst helps on NixOS, it causes problems in upstream, and I still have no idea why LD_PRELOAD not implies initfirst, and if it is correct to use initfirst here.
| From 3d56e8b0f177f98914cecbe0d45afefa22c952ec Mon Sep 17 00:00:00 2001 | ||
| From: Yaroslav Bolyukin <[email protected]> | ||
| Date: Mon, 16 Sep 2024 18:54:21 +0200 | ||
| Subject: [PATCH 5/6] fix: data_percent might be empty |
There was a problem hiding this comment.
TODO: Submit this patch upstream.
It is possible to include necessary changes in nixos module, but those changes may break workflows of some users.
| From dadc0d427eddaf49a6b213e7345c86e81a9c84e7 Mon Sep 17 00:00:00 2001 | ||
| From: Yaroslav Bolyukin <[email protected]> | ||
| Date: Mon, 16 Sep 2024 18:54:05 +0200 | ||
| Subject: [PATCH 2/6] fix: broken qvm-device symlinks |
There was a problem hiding this comment.
TODO: This and relevant qubes-core-admin-client needs to be submitted upstream
| From 2448b386505af8540f21b0f81275f45776070f8c Mon Sep 17 00:00:00 2001 | ||
| From: Yaroslav Bolyukin <[email protected]> | ||
| Date: Sat, 14 Sep 2024 00:09:19 +0200 | ||
| Subject: [PATCH 3/3] fix: do not crash on pool with no volumes |
There was a problem hiding this comment.
TODO: Submit upstream
This is not an issue on QubesOS, because in qubes you have OOTB setup, and pools are never empty.
This is not the case on NixOS, on Nix you need to install distributions after.
|
Figured out StandaloneVM - this is caused by changes that were not included in the previous version of this PR, but in my private nixpkgs fork ++ lib.lists.optional withSeaBIOS "--with-system-seabios=${seabios}/share/seabios"This is incorrect, as @SigmaSquadron PTAL |
ofborg
bot
requested review from
globin,
hehongbo,
lovesegfault,
SigmaSquadron and
fpletz
There was a problem hiding this comment.
The build failures can probably be fixed with a rebase once #345171, #345192 and #341429 are merged.
Result of nixpkgs-review pr 341215 run on x86_64-linux 1
2 packages blacklisted:
- nixos-install-tools
- tests.nixos-functions.nixos-test
65 packages failed to build:
- appvm
- collectd
- diffoscope
- diffoscope.dist
- diffoscope.man
- docker-machine-kvm2
- gnome-boxes
- guestfs-tools
- htcondor
- libguestfs
- librenms
- libvirt
- libvirt-glib
- libvirt-glib.dev
- libvirt-glib.devdoc
- libvmi
- libvmi.dev
- libvmi.lib
- mgmt
- minikube
- multipass
- perl536Packages.SysVirt
- perl536Packages.SysVirt.devdoc
- perl538Packages.SysVirt
- perl538Packages.SysVirt.devdoc
- python311Packages.guestfs
- python311Packages.guestfs.dist
- python311Packages.libvirt
- python311Packages.libvirt.dist
- python312Packages.guestfs
- python312Packages.guestfs.dist
- python312Packages.libvirt
- python312Packages.libvirt.dist
- qemu_xen_4_17
- qemu_xen_4_17.debug
- qemu_xen_4_17.ga
- rubyPackages.ruby-libvirt (rubyPackages_3_3.ruby-libvirt)
- rubyPackages_3_1.ruby-libvirt
- rubyPackages_3_2.ruby-libvirt
- vagrant
- virt-manager
- virt-manager-qt
- virt-manager.dist
- virt-top
- virt-viewer
- xen (xenPackages.xen_4_19)
- xen.boot (xenPackages.xen_4_19.boot)
- xen.dev (xenPackages.xen_4_19.dev)
- xen.doc (xenPackages.xen_4_19.doc)
- xen.man (xenPackages.xen_4_19.man)
- xenPackages.xen_4_17
- xenPackages.xen_4_17-slim
- xenPackages.xen_4_17-slim.boot
- xenPackages.xen_4_17-slim.dev
- xenPackages.xen_4_17-slim.doc
- xenPackages.xen_4_17-slim.man
- xenPackages.xen_4_17.boot
- xenPackages.xen_4_17.dev
- xenPackages.xen_4_17.doc
- xenPackages.xen_4_17.man
- xenPackages.xen_4_18
- xenPackages.xen_4_18.boot
- xenPackages.xen_4_18.dev
- xenPackages.xen_4_18.doc
- xenPackages.xen_4_18.man
66 packages built:
- python311Packages.qubes-app-linux-usb-proxy
- python311Packages.qubes-core-admin
- python311Packages.qubes-core-admin-client
- python311Packages.qubes-core-admin.man
- python311Packages.qubes-core-libvirt
- python311Packages.qubes-core-libvirt.dist
- python311Packages.qubes-core-qrexec
- python311Packages.qubes-core-qubesdb
- python311Packages.qubes-core-qubesdb.dist
- python311Packages.qubes-desktop-linux-common
- python311Packages.qubes-desktop-linux-common.dist
- python311Packages.qubes-imgconverter
- python311Packages.qubes-imgconverter.dist
- qubes-vmm-xen (python311Packages.qubes-vmm-pyxen)
- qubes-vmm-xen.boot (python311Packages.qubes-vmm-pyxen.boot)
- qubes-vmm-xen.dev (python311Packages.qubes-vmm-pyxen.dev)
- qubes-vmm-xen.doc (python311Packages.qubes-vmm-pyxen.doc)
- qubes-vmm-xen.man (python311Packages.qubes-vmm-pyxen.man)
- python312Packages.qubes-app-linux-usb-proxy
- python312Packages.qubes-core-admin
- python312Packages.qubes-core-admin-client
- python312Packages.qubes-core-admin.man
- python312Packages.qubes-core-libvirt
- python312Packages.qubes-core-libvirt.dist
- python312Packages.qubes-core-qrexec
- python312Packages.qubes-core-qubesdb
- python312Packages.qubes-core-qubesdb.dist
- python312Packages.qubes-desktop-linux-common
- python312Packages.qubes-desktop-linux-common.dist
- python312Packages.qubes-imgconverter
- python312Packages.qubes-imgconverter.dist
- qemu_qubes
- qemu_qubes.debug
- qemu_qubes.ga
- qemu_xen (qemu_xen_4_19)
- qemu_xen.debug (qemu_xen_4_19.debug)
- qemu_xen.ga (qemu_xen_4_19.ga)
- qemu_xen_4_18
- qemu_xen_4_18.debug
- qemu_xen_4_18.ga
- qubes-artwork
- qubes-core-admin-linux
- qubes-core-agent-linux
- qubes-core-agent-linux.man
- qubes-core-libvirt
- qubes-core-qubesdb
- qubes-core-vchan-xen
- qubes-desktop-linux-kde
- qubes-gui-common
- qubes-gui-daemon
- qubes-linux-utils
- qubes-manager
- qubes-manager.dist
- qubes-seabios
- qubes-vmm-stubdom-linux
- xen-guest-agent
- xen-slim (xenPackages.xen_4_19-slim)
- xen-slim.boot (xenPackages.xen_4_19-slim.boot)
- xen-slim.dev (xenPackages.xen_4_19-slim.dev)
- xen-slim.doc (xenPackages.xen_4_19-slim.doc)
- xen-slim.man (xenPackages.xen_4_19-slim.man)
- xenPackages.xen_4_18-slim
- xenPackages.xen_4_18-slim.boot
- xenPackages.xen_4_18-slim.dev
- xenPackages.xen_4_18-slim.doc
- xenPackages.xen_4_18-slim.man
|
god bless you seriously 🙇 |
Description of changes
You can initialize qubes database files using
qubes-createfromqubes-core-admin, and then you need to install some virtual machines - this can be done by running qvm-backup on QubesOS system, and qvm-backup-restore in NixOS.After that, basic functionality will work.
Be careful with netvms, as dom0 updates will not work with them. Some loosening up of qubes security needs to be implemented, at least having "qvm-dom0-network-via-netvm" script (Which was present in QubesOS before, and now needs to be written from scratch?) would be a good start.
At this point, you're welcome for testing, but be aware that it is not finished yet.
Cc: @SigmaSquadron
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.