summary refs log tree commit diff stats
path: root/gitlab/issues/target_missing/host_missing/accel_missing/1784.toml
diff options
context:
space:
mode:
Diffstat (limited to 'gitlab/issues/target_missing/host_missing/accel_missing/1784.toml')
-rw-r--r--gitlab/issues/target_missing/host_missing/accel_missing/1784.toml21
1 files changed, 0 insertions, 21 deletions
diff --git a/gitlab/issues/target_missing/host_missing/accel_missing/1784.toml b/gitlab/issues/target_missing/host_missing/accel_missing/1784.toml
deleted file mode 100644
index 9e61452e9..000000000
--- a/gitlab/issues/target_missing/host_missing/accel_missing/1784.toml
+++ /dev/null
@@ -1,21 +0,0 @@
-id = 1784
-title = "Mac M1 Max / Debian guest / Luks password / Switching to graphical login manager (lightdm/Gdm) hangs in 75%"
-state = "opened"
-created_at = "2023-07-24T08:22:00.581Z"
-closed_at = "n/a"
-labels = []
-url = "https://gitlab.com/qemu-project/qemu/-/issues/1784"
-host-os = "n/a"
-host-arch = "n/a"
-qemu-version = "n/a"
-guest-os = "n/a"
-guest-arch = "n/a"
-description = """In approximately 70% of cases I start QEMU with a Debian guest where the Debian guest was installed with full disk encryption, QEMU 'hangs' (does not respond') after I unlock the encrypted guest and the guest tries to start the graphical login manager (gdm or lightdm).
-
-I need to force quit QEMU, restart it multiple times until the start of the graphical login manager works."""
-reproduce = """1. Install Debian with (guided) full disk encryption and either the Gnome or the XFCE desktop environment
-2. To be able to unlock the hard disk after the installation finished, the Linux boot parameter 'console=tty1' needs to be added within grub to the Linux command line
-3. Try to restart/reboot QEMU  several times and QEMU will become unresponsive multiple times in this process."""
-additional = """I encounter this problem for several months now, with different versions of QEMU, macOS and Debian.
-
-There is one observation, which might help: I installed [DropBear](https://packages.debian.org/buster/dropbear-initramfs) to experiment with remote unlocking of Luks encrypted Linux boxes. It seems, that QEMU does not go into the unresponsive state, when I unlock the hard disk via SSH and not focus the QEMU window until after the graphical login manager started. (Only tried remote unlocking a few times so it is too early to confirm if this works 100% of the time."""