Raspberry Pi OS(full) fails after update

[nezra]

Completed with an RPI 3B, 16 and 32 GB card.

Pinn v3.3.4.4

1. install RPI from the internet.(also tried from archive) and any other OS(i went with batocera).
2. Launch RPI OS
3. Complete initial setup, including updating everything.
4. Reboot
5. RPI blinks activity light indicating no start.elf; No display output

PINN starts up every time, but fails when the OS tries to load. I've gone through this process 3 times. same thing, two different RPI 3B's, 3 different SD cards.

The OS installs fine, and can be accessed and interacted with. The moment it completes it's update as part of the initial setup, it no longer boots. I've run the maintenance scripts for fixing it; both the partition and FSCK; to no avail. Looking at the partition, everything is deleted except the overlays folder, the os_config.json, issue, cmdline and config.txt files.

After I did more digging, the result appears to be there isn't enough free space. This appears to be because Wolfram requires more than 1GB of space to update; which isn't available after the initial set of updates. as such, it breaks the update process, and in kind, leaves the boot folder empty. While the GUI says it's completed and forces a reboot, in reality, it never finishes, leaving the boot folder devoid of everything.

Is there a way to avoid this in the future by either increasing the Full OS size?

[lurch]

ping @XECDesign in case a similar problem would also affect NOOBS?

[XECDesign]

Yeah, I just tried installing everything I could fit on a 16GB card and the full OS didn't even have enough free space to boot.

So I guess there are 5 issues here. NOOBS and PINN don't force enough padding. You can't boot into a usable environment if you don't have enough free space. Piwiz doesn't make sure it has enough free space to do everything safely. The firmware package leaves you without /boot files if things go wrong.

[nezra]

Should i post this on Noobs & Raspberry PI's as well then? I only used the image provided by PINN when i did mine, so i didn't have the options to install everything else. The Share partition being incorporated into the base PI image i think would have supplied enough room.

I found out about wolfram's update size here if it helps:"

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=285532&p=1728322&hilit=wolfram#p1728322

[lurch]

I think most of these issues are due to apt not checking for enough free disk space, as mentioned here :confused:

[procount]

@XECDesign - did you miss an issue? I can only count 4 ;)

I agree with @lurch that apt seems to be the main culprit. Maybe Piwiz could try to avoid the issue, but how would it know how much space is required? Indeed, how do we know how much free space would be required for an apt upgrade when we create the image? What is reasonable at creation time might not be enough later if a subsequent update of a large package like wolfram requires 1GB free space in order to upgrade. The space required by apt upgrade is quite dynamic over time.

So how to fix?

• increasing the minimum space required for Raspberry Pi OS FULL in the JSON files should fix it for now, at least. PINN uses exactly the same installation files as NOOBS, so it will work for both.

• PINN typically ensures a minimum of 500MB of free rootfs partition space is available for each OS. Clearly this is not sufficient for Raspios FULL, but how do we determine what a safe minimum size is for each OS?

• For PINN, you can select your OSes via https://pinn.mjh.nz and force a fixed size for the Raspios FULL installation, thus ensuring it has sufficient free disk space for an apt upgrade, but this leaves it up to the user to determine what a suitable free space allocation should be.

[lurch]

I wonder if wolfram is now the largest-ever DEB file?

[XECDesign]

Should i post this on Noobs & Raspberry PI's as well then?

I'll be the person that will need to do something about it, so consider it reported.

I think most of these issues are due to apt not checking for enough free disk space, as mentioned here confused

dpkg and apt are generally set up so that if things go wrong, you can recover. IMHO, the main culprit is the firmware package which is awful in general. I had a replacement version that wouldn't fail in this way, but it hasn't had much testing since we had to get the 64bit image and now there are other things that need to be done quickly.

I wonder if wolfram is now the largest-ever DEB file?

In our repo? Close.

683M Jun 17  2019 ./pool/ui/libr/libreoffice/libreoffice-dbg_4.3.3-2+rpi4_i386.deb
587M Sep  3 18:21 ./pool/main/w/wolfram-engine/wolfram-engine_12.1.1+2020081901_armhf.deb

@XECDesign - did you miss an issue? I can only count 4 ;)

That's what happens when you have a train to catch.

I think on the NOOBS side, the fix is to use a percentage of total space as padding, since that seems to be how ext4 works when it comes to reserved blocks.

Given that this was a very unlikely set of circumstances, is it fair to pad 1.5GB each time for the full OS even though there won't be such a large upgrade on first boot most of the time?

I think for now I'll bump the numbers up until the firmware package is fixed and have a think about if there's anything else that can be done later.

[procount]

I think for now I'll bump the numbers up until the firmware package is fixed

@XECDesign - is this complete?