Thanx a lot to everybody for your work on Raspberry Pi OS! I happily use Raspberry Pi systems since 2017.
When attempting to initialize a new media with newest trixie Lite (both armhf and x64) on either
an 8 or 16 GB GBSD card in a Pi 3B for a pivccu install, it seems as if the filesystem
gets corrupted at different points of time in the process, leading to any possible error including boot failures.
I tested very often (>30 at least) during the last week, using
* two RPI 3Bs (one of them brand new) with
* three different SD cards in two different sizes and of two different vendors, one of them brand new.
The first problem I found on a system was /etc/initramfs-tools/initramfs.conf containing binary data, causing errors on system upgrade.
Since then, after having written the image to the SD card, I attach the card reader to the second Pi 3B (running a bookworm OctoPrint image of 09/2025) and mount the partitions. The fschk is always ok, and I also test selective files for their content and they are ok
(cmdline.txt, config.txt and initramfs.conf).
Booting from the media for system update/upgrade and pivccu install, one of the following problems problems appear:
* the new system is being pingable for about 5 secs during cloud-init, then not anlyonger reachable
* the new system is coming up with corrupted files after 1st boot or after a typical system update/upgrade
* the new system is not being connectable either after system upgrade or 1st phase of pivccu install
In most error cases with an 8 GB media, initramfs.conf always has invalid content, either binary and occasionally some XML fragments.
Also, when a system upgrade was possible at all (with initramfs.conf restored by me), scripts of mine that I copied to the system via SFTP before upgrade, occasionally had binary content after a system upgrade and reboot, and yes, initramfs.conf had invalid content again.
With the 16GB card I had less problems with first boot, and more often I could perform a system update/upgrade. In cases where the system became unreachable, it happened that the two above files were ok when being checked offline, nevertheless a boot wasn't possible anymore.
With the x64 image and an unreacheable system, on boot attempt the green LED blinked seven times, AFAIK an indication of that the SD card cannot be read. With the 8GB media this occurred every time already on cloud-init.
Also I switched between both Pi3B and had the same result.
Interestingly, something similar seems to have happened already with the above mentioned OctoPrint (bookworm!) image, which I boot only when using my 3D printer about every two weeks. From time to time the system is not reachable after startup, and I need to rewrite the bacukp of that image to the media.
Until now I was wondering what happened there, but after the last full week of testing, this sounds very familiar.
Currently, I see no way to set up a new Raspberry Pi media. Please let me know if and what I can do to investigate further. Is that a know issue, or am I the only one reporting such issues?
Thank you very much in advance!
When attempting to initialize a new media with newest trixie Lite (both armhf and x64) on either
an 8 or 16 GB GBSD card in a Pi 3B for a pivccu install, it seems as if the filesystem
gets corrupted at different points of time in the process, leading to any possible error including boot failures.
I tested very often (>30 at least) during the last week, using
* two RPI 3Bs (one of them brand new) with
* three different SD cards in two different sizes and of two different vendors, one of them brand new.
The first problem I found on a system was /etc/initramfs-tools/initramfs.conf containing binary data, causing errors on system upgrade.
Since then, after having written the image to the SD card, I attach the card reader to the second Pi 3B (running a bookworm OctoPrint image of 09/2025) and mount the partitions. The fschk is always ok, and I also test selective files for their content and they are ok
(cmdline.txt, config.txt and initramfs.conf).
Booting from the media for system update/upgrade and pivccu install, one of the following problems problems appear:
* the new system is being pingable for about 5 secs during cloud-init, then not anlyonger reachable
* the new system is coming up with corrupted files after 1st boot or after a typical system update/upgrade
* the new system is not being connectable either after system upgrade or 1st phase of pivccu install
In most error cases with an 8 GB media, initramfs.conf always has invalid content, either binary and occasionally some XML fragments.
Also, when a system upgrade was possible at all (with initramfs.conf restored by me), scripts of mine that I copied to the system via SFTP before upgrade, occasionally had binary content after a system upgrade and reboot, and yes, initramfs.conf had invalid content again.
With the 16GB card I had less problems with first boot, and more often I could perform a system update/upgrade. In cases where the system became unreachable, it happened that the two above files were ok when being checked offline, nevertheless a boot wasn't possible anymore.
With the x64 image and an unreacheable system, on boot attempt the green LED blinked seven times, AFAIK an indication of that the SD card cannot be read. With the 8GB media this occurred every time already on cloud-init.
Also I switched between both Pi3B and had the same result.
Interestingly, something similar seems to have happened already with the above mentioned OctoPrint (bookworm!) image, which I boot only when using my 3D printer about every two weeks. From time to time the system is not reachable after startup, and I need to rewrite the bacukp of that image to the media.
Until now I was wondering what happened there, but after the last full week of testing, this sounds very familiar.
Currently, I see no way to set up a new Raspberry Pi media. Please let me know if and what I can do to investigate further. Is that a know issue, or am I the only one reporting such issues?
Thank you very much in advance!
Statistics: Posted by cla — Tue Jan 27, 2026 1:40 pm — Replies 2 — Views 72