Debian is far behind with kernel versions. So it is possible that an update made changes where Debian is just aware in some weeks or month.
Have a look if you can install the program inxi
Then make us an: inxi -Fzx in terminal and post the output as </> Preformatted text here.
So we do see what hardware got detected and what driver is used.
The above was supposed to fix any errors in partitions.
I inserted the sd card into R Pi, but the boot problem remain.
Any suggestions to fix the damaged boot partition will be appreciated.
If there is no other way, then I have to rebuild the server from scratch (hours of config and test gone). A stark reminder to backup.
Ctrl D to stop at kernel options.
I selected earlier version(s)
5.15.10-200: After booting sequence is complete, the screen went blank. I ran ping and ssh but no connection (although Ethernet port is blinking)
5.15.8-200: No booting at all.
I’m not sure, but look like your setup using LVM. Usually fstab need something like /dev/mapper.
Once again not sure how, but you could try first chroot it somewhere to make sure it the installed GNU/Linux are functional then focus on how to mount LVM since I believe it’s need recognized by the bios by something insmod lvm on grub.cfg.
My bad. Look like I can’t get of rid my bad habit of skim reading.
Since you can see above menu, your UEFI and /boot partition should be fine. Your EFI firmware successfully read the content of /EFI/fedora/grub.cfg that pointing to other grub.cfg in /boot/grub2/grub.cfg.
Then the /boot/grub2/grub.cfg also successfully pointing to list of boot menu from /boot/loader/entries/*.
We could safe to say your /dev/sdb1 and /dev/sdb2 are fine.
Next are your /dev/sdb3. Since this partition using LVM, we need to make sure that fstab (or something equivalent with arm, I don’t know) and kernel parameter are correct. For kernel parameter you could directly check in /boot/loader/entries/. There should some file with each of them contain the boot parameter (same like when on boot list you press e on keyboard to edit on the fly).
Maybe you could share the fstab and one of the recent kernel parameter in /boot/loader/entries also with /boot/grub2/grub.cfg on part start with ### BEGIN /etc/grub.d/10_linux ### to part ### END /etc/grub.d/10_linux ### by mounting it with other machine.
Bellow are when I messed up with boot parameter with Fedora Workstation on VM:
Okay, I’ll keep the disk in question for checking later. I have no experience dealing with LVM snapshot yet.
For now, I’m reinstalling the system. I really need to back up the image once the config is done. Thanks.
Maybe this is off-topic, but would it be the case of the typical SD card being corrupted?
When running SBC on an SD card 24/7, how reliable could it be? I’m just weighing pros and cons of a backup plan.
A: Move the system volume group (fedora_fedora) on an SSD drive
B: Move the root file system (/) to an SSD drive and just leave the boot file system (\boot) on the SD card.
C: Just buy an SBC that supports USB boot
D: Mount LVM/backup - maybe not feasible for an unbootable system/less experienced users like me. LVM is auto-created by the ARM installer, but not sure how to use it.
What do you think? Do you have an SD card being a problem during your SBC test and daily use?