Hi,
On Sun, Dec 21, 2025 at 07:23:43AM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + upstream moreinfo
>
> On Sat, Dec 20, 2025 at 11:05:18PM +0100, Thorsten Glaser wrote:
> > Package: src:linux
> > Version: 5.10.247-1
> > Severity: important
> > X-Debbugs-Cc: [email protected]
> >
> > After an upgrade from 5.10.0-36 to -37, the virtual consoles
> > 2-12 are unusable: they merely show a screenful of the old
> > currency sign (which seems to be the replacement character
> > for some reason, but I believe it’s U+00A4), and when I enter
> > text, it mostly stays like that, except for one space that
> > moves around the screen and a lowercase x that appears near
> > the beginning of a line.
> >
> > Virtual console 1 is fully usable.
>
> Please see
> https://lists.debian.org/debian-kernel/2025/12/msg00211.html .
>
> If you can do the bisect mentioned that would help identifying the
> problem.
I just realized I had a copy paste error in my proceure there, so
obvoulsy the second git checkout would be v5.10.247. For consistencly
let's replicate it here:
git clone --single-branch -b linux-5.10.y
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
cd linux-stable
git checkout v5.10.244
cp /boot/config-$(uname -r) .config
yes '' | make localmodconfig
make savedefconfig
mv defconfig arch/x86/configs/my_defconfig
# test 5.10.244 to ensure this is "good"
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm it successfully boots /
problem does not exist
# test 5.10.247 to ensure this is "bad"
git checkout v5.10.247
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm it fails to boot /
problem exists
With that confirmed, the bisection can start:
git bisect start
git bisect good v5.10.244
git bisect bad v5.10.247
In each bisection step git checks out a state between the oldest
known-bad and the newest known-good commit. In each step test using:
make my_defconfig
make -j $(nproc) bindeb-pkg
... install, try to boot / verify if problem exists
and if the problem is hit run:
git bisect bad
and if the problem doesn't trigger run:
git bisect good
. Please pay attention to always select the just built kernel for
booting, it won't always be the default kernel picked up by grub.
Iterate until git announces to have identified the first bad commit.
Then provide the output of
git bisect log
In the course of the bisection you might have to uninstall previous
kernels again to not exhaust the disk space in /boot. Also in the end
uninstall all self-built kernels again.
If we can identify a breaking commit that would be then easy enough to
forward upstream. I nparticular we should make as well sure if this is
a 5.10.y specific regresssion (but I have not seen the behaviour
reported on other kernels).
Regards
Salvatore
