Hello
I’m considering implementing an A/B boot flow as described in the Raspberry Pi documentation:
https://www.raspberrypi.com/documentati ... ab-booting
One question I have is about handling autoboot.txt. What happens if, during the update process, the autoboot.txt file gets corrupted?
From my understanding, if autoboot.txt is corrupted or unreadable, the system falls back to config.txt. This fallback mechanism is great for booting into a recovery system or something similar if the config.txt is on the same partition as autoboot.txt.
However, I’m curious if it’s possible to proceed with booting from bootA/rootfsA in such a scenario.
Will the firmware attempt the next boot partition if it fails to find a valid config.txt after encountering a corrupted autoboot.txt on first boot Partition?
Are there alternative approaches to ensure reliable boot behavior in this case without recovery system?
I’m considering implementing an A/B boot flow as described in the Raspberry Pi documentation:
https://www.raspberrypi.com/documentati ... ab-booting
One question I have is about handling autoboot.txt. What happens if, during the update process, the autoboot.txt file gets corrupted?
From my understanding, if autoboot.txt is corrupted or unreadable, the system falls back to config.txt. This fallback mechanism is great for booting into a recovery system or something similar if the config.txt is on the same partition as autoboot.txt.
However, I’m curious if it’s possible to proceed with booting from bootA/rootfsA in such a scenario.
Will the firmware attempt the next boot partition if it fails to find a valid config.txt after encountering a corrupted autoboot.txt on first boot Partition?
Are there alternative approaches to ensure reliable boot behavior in this case without recovery system?
Statistics: Posted by berkutta — Wed Jan 22, 2025 3:28 pm — Replies 1 — Views 25