Debian Upgrade Day

2025-07-15 21:48:42 PDT (last update 2025-07-15 21:50:27 PDT)

Bart Massey 2025

I got a new second monitor for my home desktop today (2025-07-15). My old second monitor was pretty great, except it was so old it had a fluorescent backlight. It was only 30", but put off enough heat to toast bread.

The new monitor was as close to the old as I could buy in terms of geometry, but I oddly could not find a new 30" 1600p monitor. I bought a 32" 4K monitor. This second monitor sits next to the 72" TV I use as my primary display. I have always wanted to be able to move windows from display to display without them changing size (too noticeably). That meant I got to use display scaling.

Selecting a monitor

Selecting a monitor from the Internet is harder than it should be. The key problem for me was that I wanted a monitor about the display same height as the old one. The old one was something like 17", so I went looking for a 17"-high monitor.

No one will tell you the height and width of the display for the monitor they are trying to sell you. No, no. You get the diagonal size (in freedom units) and the aspect ratio (a dimensionless ratio). Clearly these are the important parameters that normal people want to know.

Anyhow, https://github.com/BartMassey/monitor-dims encapsulates the math.

Upgrading Debian

Sadly, the new monitor meant it was time for the dreaded home desktop Debian upgrade. I mean, not really, but as I suspected it turned out I had to log out and back in anyway: the combination of X11 and Nvidia in a dual-monitor situation always gets the display pretty messed up when configuring, so logouts are necessary. This is a good time for me to do the Debian upgrades I've been putting off for months because everything was just working, within reason.

Fixing sources.list.d

For a while now, apt has been whining at me with "You need to update your /etc/apt/sources.list.d real bad! There's bad keys, and besides, there's a whole archive description file format you need to migrate to! It's important!"

Ok. So let's do this too while we're at it.

After making appropriate backup copies of stuff, I ran apt modernize-sources. Cool.

  1. That command was not smart enough to migrate the arch field of a archive listing:

    deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main

    for example just lost the arch part. Then apt complained at me that the Chrome archive didn't have x86 support. I know. But I'm on a dual-architecture platform for gaming purposes.

    Much research and agony later I solved this by manually adding

    Architectures: amd64

    to every single .sources file. Note the slight but very important difference between Architecture: (silently ignored) and Architectures: works fine.

  2. The problem of "bad" archive signing keys had been around a while. For Zulip Desktop, for example, apt update --audit gave the ominous

    Warning: https://download.zulip.com/desktop/apt/dists/stable/InRelease: Policy will reject signature within a year, see --audit for details

Audit: https://download.zulip.com/desktop/apt/dists/stable/InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on 69AD12704E71A4803DCA3A682424BE5AE9BD10D9 is not bound: No binding signature at time 2025-03-13T21:39:32Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z

"Since 2026-02-01." Nice. Anyhoo, except for Zulip Desktop (filed Issue #1437) I managed to track down proper keys for everything I needed.

Turns out you're supposed to put the signing keys in /etc/apt/keyrings and reference them there with a Signed-By header — unless the signing key is a "system key" and needs to go somewhere else. The initial apt modernize-sources had done stuff, so it was not too brutal to figure out. Still…

Dealing With Linux Nvidia — Again

This one is always comical. This time, I managed to get the Debian login prompt to come up on my freshly-booted primary screen. But only the primary screen. The new screen was ignored.

VT-switching to the console showed that the new screen was working fine. It just didn't light up under X11.

"No problem," I naïvely thought. "I'll just log into my account and use the Nvidia display tool to fix it. Or xrandr. Something will work."

On login the screen froze so hard I gave up and rebooted my machine.

…

Let's just skip the silly debugging session. Bottom line: everything works perfectly at this point — as long as I turn off my new secondary monitor before I log in, and then turn it back on. Srsly. This is reproducible, and I have only the vaguest guesses why/how this is a thing.

Epilogue

I burned down about five hours on this — not counting things like unpacking my new monitor and finding an old adjustable stand to use with it, and then putting the stand from my soon-to-be-discarded thermal-generator/monitor onto the monitor I borrowed the stand from.

The good news is that I am now ready to put off upgrading Debian for another month, and getting a new monitor for another 10 or 15 years. I wonder why I do that?