[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

Hi Ben,

Thanks for all those details!

Ben Hutchings <ben@decadent.org.uk> (2023-05-14):
> > 
> >   +-------------+-----------------+-----------------+-----------------+
> >   |  Graphics   |  Bullseye 11.7  |  Bookworm RC 2  |  Daily builds   |
> >   +-------------+--------+--------+--------+--------+--------+--------+
> >   |             |  BIOS  |  UEFI  |  BIOS  |  UEFI  |  BIOS  |  UEFI  |
> >   +-------------+--------+--------+--------+--------+--------+--------+
> >   |             |   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
> >   | -vga std    |   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
> >   | -vga cirrus |   OK   |   OK   |   OK   |  KO-S  |   OK   |  KO-S  |
> >   | -vga qxl    |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   | -vga virtio |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   | -vga vmware |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   +-------------+--------+--------+--------+--------+--------+--------+
> I started testing with QEMU and OVMF from unstable, and I'm instead
> seeing Xorg failing to start in the same cases you see glitches.  The
> relevant error message seems to be this one:
> http://codesearch.debian.net/show?file=xorg-server_2%3A21.1.7-3%2Fhw%2Fxfree86%2Ffbdevhw%2Ffbdevhw.c&line=504

Checking RC 1, I'm seeing OK results for both `-vga std` (or no options)
and `-vga cirrus`. I should note GRUB itself is “text-like” with RC 1,
while it's “graphical” with RC 2.

Reverting the following commit in debian-installer.git and building a
netboot-gtk image against unstable gives me a working graphical
installer with `-vga std` (or no options) and `-vga cirrus`. I didn't
check the rest of the matrix though.

So it looks to me the GRUB config fix uncovered a pre-existing bug, and
the linux version bump (6.1.20-1 → 6.1.20-2) between RC 1 and RC 2 isn't
a factor (xserver-xorg-* udebs didn't change).

Interestingly, switching to the bullseye branch and cherry-picking the
same GRUB config fix there, and rebuilding d-i against current bullseye,
I'm getting exactly the same problem: KO-G for std, KO-S for cirrus!

So it looks like this might be a rather old issue, rather than a
regression during the Bookworm release cycle.

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:
 - Bullseye has a “text-like” GRUB, all good.
 - Bookworm RC 1 has a “text-like” GRUB, all good.
 - Bookworm RC 2 has a “graphical” GRUB, issues!

> > Questions
> > =========
> > 
> >  - Is it really to be expected that X and standard drivers would regress
> >    this way when moving from Bullseye to Bookworm?
> No.
> >  - Or is it expected to require specific kernel modules while that wasn't
> >    the case before? I've discovered this in VM environments, but maybe
> >    similar things could be happening on bare metal as well, and maybe
> >    some more modules should be considered for inclusion?
> No.
> >  - Is it acceptable to just bundle bochs, cirrus, and vboxvideo for the
> >    time being (i.e. RC 3, RC 4, 12.0.0), be it via the nasty approach
> >    or via a proper linux fb-modules inclusion?
> >  - Or does shipping those few modules risk breaking the kernel and/or X
> >    on other platforms? (I'd definitely hope not!)
> I would not expect so.  They get used on the installed system, so they
> probably work.

Copy all!

Note for a further session: instead of debugging d-i itself, it should
be possible to reproduce those issues in the installed system, by
keeping only a specific list of kernel modules and X drivers. Of course,
that means having GRUB in “graphical” mode as well (a quick check
suggests installing desktop-base, without plymouth*, is sufficient for
that part).

As a very quick experiment, I tried:
 - installing xfce4 and desktop-base;
 - rebooting;
 - X doesn't start directly, one needs to run startxfce4 from the

 - manually removing all X drivers except fbdev_drv.so;
 - manually removing both tiny/ drivers (bochs and cirrus);
 - rebuilding the initramfs;
 - rebooting.

This gives me the following:
 - std: black screen, not even seeing a console prompt;
 - cirrus: “garbled/split” screen symptoms in the console, and in X;
 - qxl: all good in the console and in X.

Interestingly, purging desktop-base gets me back to a “text-only” GRUB
prompt, but both std and cirrus are exhibiting “garbled/split” screen
symptoms in the console and in X.

I'll stop here, I just wanted to confirm one could reproduce those
issues within the installed system, which should almost always be a
debug-friendlier environment than d-i…

> > Proposal plan for d-i (Bookworm RC 3, RC 4, and 12.0.0)
> > =====================
> > 
> > Unless I received strong negative feedback before Monday (May 15th),
> > I plan on including the nasty approach in RC 3, and to revert it
> > altogether in RC 4 if big bad regressions are reported:
> >   https://salsa.debian.org/installer-team/debian-installer/-/commit/9fceca63273d0b501ea64d7b719acafc93a5b7fa
> > 
> > As a side note, keeping the bundling in src:debian-installer for the
> > next few weeks makes us autonomous: we can enable and disable those
> > extra modules without requiring a new linux upload… so it's nasty but I
> > actually thought about the few advantages we were getting out of this!
> > 
> > We should also be OK legal-wise, given we already have linux in
> > Built-Using via its udebs, so copying things around from linux-image
> > wouldn't change anything there, would it?
> > 
> > Of course in the long run, if having those modules is desired, it will
> > be better to have them merged in linux and to drop the nasty code, e.g.
> > in a point release.
> [...]
> Definitely.
> I will spend some time investigating this, but I doubt I'll come up
> with a better fix in time.

Thanks so much for your feedback.

It'd probably be even less likely to get to the bottom of it (at least
as far as I would be able to investigate myself) in a timely manner
given the absence of a known good version to use in a bisect session to
track down when that “regression” was introduced…

Monitoring the ppc64el situation (#1033058) was already on my radar for
upcoming point releases, I've added this new issue to the list:

Maybe I'll end up learning about FB after all… twice the fun!

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: