qubes-vm-kernel - dracut support inside App Qubes #8649
Labels
C: core
C: kernel
P: default
Priority: default. Default priority for new issues, to be replaced given sufficient information.
Comments
adrelanos
added
P: default
adrelanos
changed the title
Qubes OS releaseR4.2 Brief summaryVM using Qubes VM kernel fails to boot Steps to reproduce
Expected behaviorFunctional boot. Actual behaviorBroken boot. Boot logThat is a weird way for the log to end without an error message. Additional information:The kernel command line as seen from the log...
It's lengthy (because of security-misc and debug-misc being installed) but that shouldn't matter, because the boot process was successful with initramfs-tools. Maybe the console setting |
|
That is by Qubes so probably not the issue.
|
|
Generally, Debian is using initramfs-tools, while Fedora is using dracut, so respective modules are packaged only for distributions where they are relevant. Is dracut a supported way of generating initramfs in Debian? If so, we can package dracut module for Debian too. In the meantime, you can test this by copying them a Fedora qube. |
dracut is in packages.debian.org for years. It's unfortunately not the default. Then it would be better supported. It has some bugs. But it works. It's the default in Kicksecure and Non-Qubes-Whonix since version 17. (Because it's the only feasable path towards ram-wipe (dracut module) that I could find.)
I wouldn't know what to copy. This Debian based VM already has these folders:
The same folders that Fedora has. Am I missing any, which ones do I need to copy over? |
|
I've cut the kernel parameters.
But still no more log output. Log still stops at the same message. |
Maybe killed by Xen on "out of PoD memory"? Check |
|
Good to know to keep dracut modules small to avoid an unbootable initial ramdisk. In this case it seems in order though:
But perhaps the So instead of running Maybe some modules are missing? Log: |
|
You guessed good.
|
That's a lot for a 400MB for booting. Note it is compressed, and kernel needs to uncompress it (which can easily eat twice its size), and still have space for kernel to run. The minimal initramfs shipped via dom0 is about 7MB. The dracut-generated one in Fedora templates is about 30MB. |
|
initial memory:
No special dracut command line parameters required. I regenerated to initial ramdisk using There are imo maybe two usability bugs here:
Useful to create tickets for that? |
|
If you are on most recent R4.2, there is an opt-in feature that should make such issues much more evident by changing how boot memory is handled (instead of giving full "maxmem" at boot and using PoD + xen-balloon to limit that to "memory", it gives just "memory" amount and doesn't use PoD at all, and then uses memory hotplug to increase if necessary). You can enable it with: At some point it will be default, but needs more testing first. |
I will test this. VM booted so let's see how it works over the coming weeks. Is there a ticket? |
|
Had to disable |
|
Qubes Debian 12 Template... Default initramfs-tools:
|
|
No related commits have been attached. Nothing has changed. dracut support would be good to have as it gives value as described in my original post. But... Not a blocker for: |
So, this looks to be the way to go then. I guess we can include hostonly=yes in a config snippet. |
|
In fact, we do have dracut config already installed in Fedora, it has hostonly=no, but it excludes a bunch of modules to limit the size. I'll add it to Debian too and see what happens. |
marmarek
added a commit
to marmarek/qubes-core-agent-linux
that referenced
this issue
Nov 25, 2024
This especially adds dracut config (that was previously installed in Fedora only). While dracut is not the default on Debian, it is possible to use it, so add the config to the package too. QubesOS/qubes-issues#8649
marmarek
added a commit
to marmarek/qubes-core-agent-linux
that referenced
this issue
Nov 25, 2024
This especially adds dracut config (that was previously installed in Fedora only). While dracut is not the default on Debian, it is possible to use it, so add the config to the package too. QubesOS/qubes-issues#8649
marmarek
added a commit
to marmarek/qubes-core-agent-linux
that referenced
this issue
Nov 25, 2024
Review content of initramfs on Debian, and remove biggest yet unused parts. QubesOS/qubes-issues#8649
marmarek
added a commit
to marmarek/qubes-core-admin
that referenced
this issue
Nov 25, 2024
It isn't default there, but it is available, so test it too. QubesOS/qubes-issues#8649
marmarek
added a commit
to marmarek/qubes-core-admin
that referenced
this issue
Nov 29, 2024
It isn't default there, but it is available, so test it too. QubesOS/qubes-issues#8649
This was referenced Dec 10, 2024
marmarek
added a commit
to QubesOS/qubes-core-agent-linux
that referenced
this issue
Dec 27, 2024
This especially adds dracut config (that was previously installed in Fedora only). While dracut is not the default on Debian, it is possible to use it, so add the config to the package too. QubesOS/qubes-issues#8649 (cherry picked from commit 8796b2b)
marmarek
added a commit
to QubesOS/qubes-core-agent-linux
that referenced
this issue
Dec 27, 2024
Review content of initramfs on Debian, and remove biggest yet unused parts. QubesOS/qubes-issues#8649 (cherry picked from commit e9e5b81)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The problem you're addressing (if any)
Qubes inside VM kernel booting is broken when using dracut.
The solution you'd like
The value to a user, and who that user might be
Related
Additional information
This might actually be a bug report. Qubes VMs might already have dracut booting functionality. But I haven't found any documentation on this. This is implied because Qubes already has several dracut modules.
/usr/lib/dracut/modules.d/90qubes-vm/usr/lib/dracut/modules.d/90qubes-vm-modules/usr/lib/dracut/modules.d/90qubes-vm-simpleThe text was updated successfully, but these errors were encountered: