Okay, then in that case it cannot be that problem unless you updated very selectively and not your full system.
Maybe we can start with figuring out the truth here. After booting the rescue system, run the following commands on the terminal, preferably after you connected to your local ethernet or wifi to get internet with the rescue system:
$ cryptsetup luksOpen /dev/nvme0n1 reform_crypt
$ vgchange -ay reformvg
$ mount /dev/reformvg/root /mnt
$ mount /dev/mmcblk1p1 /mnt/boot
$ mount -o bind /dev /mnt/dev
$ mount -t sysfs sys /mnt/sys
$ mount -t proc proc /mnt/proc
$ cp /etc/resolv.conf /mnt/etc
$ chroot /mnt bash
At this point you will have a shell open inside your system on nvme and you can start poking around and investigating. For example, it would be useful to know the full output of running:
sudo reform-check
That command should include your reform-tools version and your kernel version. If it does not, then you can retrieve those by also giving me the output of these commands:
$ dpkg -l | grep reform-tools
$ dpkg -l | grep linux-image-
Lastly, to check the hypothesis with the binutils bug, could you please also run the following:
$ ls -lha /boot
$ lsinitramfs /boot/initrd.img-* | grep /lib/modules | wc -l
You can leave the chroot environment and get your terminal back by running these commands:
$ exit
$ umount --recursive /mnt
$ vgchange -an reformvg
$ cryptsetup luksClose reform_crypt
Looking forward to your findings. ![]()
No, DB9 RS232 serial is quite different (last but not least voltage-wise) from UART serial.