how VT colors are set and why they broke

[Harald Sitter]

Long ramblings on how VT colors are set...

A couple of months ago we had a problem where openqa was stumbling
over VT (getty) colors being different from one run to another. I've
tried to investigate it back then, but then eventually the problem
solved itself and I was content with calling it a transient
regression.

Naturally the problem appeared again and this time it didn't go away
again. So into the rabbit hole I went.

# What's it look like?

The VT sometimes is darkish grey (#aaaaaa). Othertimes it is a
brighter grey (#cccccc).

# But why?

The dark grey, as it turns out, is the kernel default color (0x07). It
was a complete and utter mystery why it would be anything but that
default color though.
So, I was playing around with GRUB a bit, and sure enough randomly the
color would changed. I of course assumed it was related to GRUB.
Except, that didn't make any sense as the color settings in GRUB had
no direct impact on the actual bright grey. Worse yet, there is no
code in either GRUB or the kernel that would pass color settings
around.
Clearly it would be user space! Oh no, one of 3 million user space programs!

Rather by chance I had the idea of running a broken ISO to
rescue.target only. To my great surprise the ISO had the dark grey at
that point. I continued on to multi-user.target. AND OMG, the colors
changed. A quick review of the units in-between reveals
setvtrgb.service. And that my friends is the thing that sets the VT
color from user space.

It's not too interesting really. There's a config in /etc which sets
the colortable and the service applies it on the kernel VT. That is
where the brighter grey comes from.

The obvious reason it randomly isn't applied must be that the unit is
malfunctioning. And indeed that is the problem. From what I've
discerned it must run after the VTs are up and plymouth is gone. The
latter is where the problem appears. With our unit tree the service
ran often times well before plymouth terminated, so the color change
didn't stick and the VT was left at the #aaaaaa default value. And the
best thing about this is that it is entirely depending on the unit
order, so in theory run1 can be fine, run2 can be broken, run3 can be
fine again.

https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1783283

For prosperity here's what I've learned:

- should we have VT color change problems it's likely setvtrgb's fault
- if it is not, try going through the targets manually, unless the
kernel default changes a user space program would be the one setting
the VT color
- you can set the default color via cmdline vt.color=0xNM where N is
background and M is foreground

# Fixy?

A tentative fix for this is being rolled out and should land soon. The
primary use is obviously having consistent appearance and thus
consistently passing openqa tests. Beyond that it's not exactly a show
stopper. Although I guess the color is also nicer.

To that end if thing continue to be flaky we may opt to implement a
persistent workaround for this. Which could be simply forcing a given
color at runtime. But I hope it doesn't come to that.

HS