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

Bug#1036771: debian-installer: Wrong colors in GRUB submenus for netboot on x86

Same player, shoot again.

Cyril Brulebois <kibi@debian.org> (2023-05-25):
> I'm therefore proposing *not* to force those colors in normal submenus,
> and to only force colors when in the dark menu (and its submenus).

And I'm now proposing to only do that on x86, which can be detected via
a new IS_X86 (similar to IS_PURE_GTK), set from x86.cfg.

Doing so shouldn't change anything to the rest of the analysis for x86
(touching netboot and only netboot).

> See how the only affected build targets are netboot and netboot-gtk,
> leaving the “CD-oriented” ones alone, meaning no impact on debian-cd
> builds. I consider this change to be safe for x86.

That's still the plan.

> Not breaking arm64
> ==================

That escalated quickly.

> Seeing debian-cd_info.tar.gz there got me worried, keeping in mind the
> original intent was to fix netboot* on x86!

And worried I should have stayed.

> Here, we see that we have the “usual”/“feedback” colors hardcoded at the
> top, there's no background_image call, and there's no condition at all.
> So dropping the re-hardcoding of the same colors in submenus doesn't
> look like it should break anything (I'm pretty sure I tested that a few
> days ago, with my first local netinst arm64 build; but I'll probably
> giving it another spin after uploading debian-installer with the patch,
> waiting for the various buildd/ftp/release bits to happen).

Combine this…

> Also, for some reason, with or without patching the debian-installer
> build, the color “reset” after entering/exiting the dark menu just works
> on arm64.

… with this, and guess what happens?

I'm not sure why that happens (and why that's different across archs),
and I won't get to the bottom of this before the upcoming release, but
dropping the hardcoded colors in submenus on all archs means breaking
submenus on arm*: only the main menu and the dark menu get specified
colors used, and all other submenus have undefined colors instead.

It seems there's some kind of reset each time on moves from one menu to
another one, which is likely why colors have always been hardcoded,
dating back all the way to 2014 and the introduction of this script for

For the record, this breaks both netboot and netinst. 100% success rate.

> In passing, I'm seeing a warning/error message when entering the dark
> menu, but that might just be some limitation of the virtualization
> environment (maybe some unsupported video mode change).

For completeness the screen reads:

    error: no video mode activated.

    Press any key to continue...

> Conclusion
> ==========
> This bug report is more for later reference than anything, to fully
> document the reasons, worries, and reassurances about the change, so
> that we can get back to it if anything breaks, without having to
> rediscover that rabbit hole…


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: