[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics



Cyril Brulebois <kibi@debian.org> (2023-05-14):
> Also, I should note that while my focus was on netboot-gtk mini.iso
> (because it's much quicker to rebuild/tweak than a netinst image), I'm
> replicating those results with the netinst images:
[…]
>  - Bookworm RC 1 has a “text-like” GRUB, all good.
>  - Bookworm RC 2 has a “graphical” GRUB, issues!

While adjusting my “nasty” approach to make sure it would build on all
three modified archs (amd64, arm64, i386), it occurred to me that:

 - Of course the trivial patch wouldn't work, because some builds aren't
   “pure GTK” builds, like cdrom-xen, and that one would also need the
   686-pae flavour on i386.

 - Of course it wouldn't work on arm64 either, since that one doesn't
   ship vboxvideo.ko.

 - And more importantly, we have the fb-modules udeb in various places,
   including for builds that aren't about the graphical installer…


And at this point, it seems fair to say that at least the Linux kernel
isn't perfect, as problems show up even without X in the picture!

 - With Bookworm RC 1 netinst amd64 (again under UEFI), switch from
   default “Graphical install” to “Install”: the text installer shows
   up with both std and cirrus.

 - With Bookworm RC 2 netinst amd64 (again under UEFI), switch from
   default “Graphical install” to “Install”: the screen is garbled
   with std, split with cirrus.


This is easily confirmed:

 - Triggering a debian-installer “netboot” build (not “netboot-gtk”):
   the resulting mini.iso exhibits the same problems as Bookwork RC 2
   using “Install”, with both std and cirrus.

 - Patching that “netboot” build to benefit from the extra DRM modules
   makes those issues go away, with both std and cirrus.

 - Alternatively, not patching the “netboot” build but reverting the same
   patch as mentioned before makes those issues go away, with both std and
   cirrus:
     https://salsa.debian.org/installer-team/debian-installer/-/commit/a4dc8c0fe7ad1a0c1506125ad9985f78819a1bb2


For the very short term (RC 3), I think I'll implement the following:

 1. Consider archs with the graphical installer (that's been my main
    focus until a few hours ago, when I started realizing the console
    without X was also impacted), even if other archs include fb-modules
    as well.
    This means: amd64, arm64, i386. Those happen to also do EFI/SB.

 2. Hardcode list of of modules to be added:
      drm_shmem_helper.ko
      drm_ttm_helper.ko
      drm_vram_helper.ko
      tiny/bochs.ko
      tiny/cirrus.ko
      ttm/ttm.ko
      vboxvideo/vboxvideo.ko [!arm64, i.e. amd64 and i386 only]

 3. For each of these 3 archs, deploy each of these modules. Do that for
    each build that includes drm.ko (which should be synonymous with
    fb-modules being deployed, given drm.ko is mandatory in the common
    fb-modules file, included from the arch-specific ones in src:linux),
    and do that without a condition on GTK detection or /usr/bin/Xorg's
    presence.

This should be targeted enough (touching 3 archs, two of which are getting
a lot of attention; leaving all others entirely untouched), yet generic
enough to work around issues that show up in both text and graphical
versions of the installer, by patching all relevant builds (netboot,
netboot-gtk, those used by debian-cd, etc.).

I'll push a v2 of my nasty branch once I've performed some clean-up and
some more testing.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature


Reply to: