There have been 3 updates/variants in s short timeframe: 6.6.51 rpt1, 6.6.51 rpt2, 6.6.51 rpt3
I have no Pi5, but overall many instances of RPiOS, also some running custom kernel besides having the apt provided on upgraded/installed.
But this raised a bit of a warning flag and I did a quick github check which shows there is some issue with the new A2 queuing. You are the second one/topic I comment this.
If you use EXT4 for rootfs, the +rpt1 or +rpt2 might have done its damage/corruption resulting in 1 or more corrupted sector or block or flash pages that are used by a file that is critical for normal OS functioning. The Ext4 metadata can all be fine, an fsck.ext4 cannot detect such blocklevel file content curroption.
On the bootfs, files are overwritten, (see initramfs hook script) but that is done with 6.6.51 rpt1 or rpt2 likely which may or may not have corrupted further.
Your option is to use all kinds of advanced tricks to see or guess which file(s) the corruption is and replace that/those. Can be quick or simple, but also may hunt you for months as there might be corruption in files that aren't directly needed for usual OS functions.
It might be that initramfs contents are wrong. In that case you can copy firmware+DTBs+kernel+initramfs from some fresh image or github release repo onto the SD-card then it should boot.
If you have your rootfs on BTRFS, you can simply run a scrub on the rootfs and it will show you in dmesg of the Linux computer that you use for that, all files and/or metadata that are corrupted. With my 'pile of old SD-cards', I have done several repairs as you only need to copy a few files from backup, files with high/recent write activity.
So that is also my advice, use BTRFS for rootfs. It requires some tweaks here and there. You have to create the rootfs yourself and rsync roottree onto it. Forumuser @bls offers a script that can generate an image with rootfs as BTRFS, maybe have a look at that.
I have no Pi5, but overall many instances of RPiOS, also some running custom kernel besides having the apt provided on upgraded/installed.
But this raised a bit of a warning flag and I did a quick github check which shows there is some issue with the new A2 queuing. You are the second one/topic I comment this.
If you use EXT4 for rootfs, the +rpt1 or +rpt2 might have done its damage/corruption resulting in 1 or more corrupted sector or block or flash pages that are used by a file that is critical for normal OS functioning. The Ext4 metadata can all be fine, an fsck.ext4 cannot detect such blocklevel file content curroption.
On the bootfs, files are overwritten, (see initramfs hook script) but that is done with 6.6.51 rpt1 or rpt2 likely which may or may not have corrupted further.
Your option is to use all kinds of advanced tricks to see or guess which file(s) the corruption is and replace that/those. Can be quick or simple, but also may hunt you for months as there might be corruption in files that aren't directly needed for usual OS functions.
It might be that initramfs contents are wrong. In that case you can copy firmware+DTBs+kernel+initramfs from some fresh image or github release repo onto the SD-card then it should boot.
If you have your rootfs on BTRFS, you can simply run a scrub on the rootfs and it will show you in dmesg of the Linux computer that you use for that, all files and/or metadata that are corrupted. With my 'pile of old SD-cards', I have done several repairs as you only need to copy a few files from backup, files with high/recent write activity.
So that is also my advice, use BTRFS for rootfs. It requires some tweaks here and there. You have to create the rootfs yourself and rsync roottree onto it. Forumuser @bls offers a script that can generate an image with rootfs as BTRFS, maybe have a look at that.
Statistics: Posted by redvli — Sun Oct 13, 2024 11:34 am