Thankyou for the reply @JerryChang .
I am currently using Jetpack 5.0.2 (However, as mentioned, I have tested the RootfsA/B redundancy on Jetpack 4.6 and Jetpack 5.1 as well).
My question was specific to corrupting slot A from slot A: Why the system won’t reboot if I use slot A to corrupt slot A itself, and then reboot. Currently I am guessing that this interferes with the failover mechanism somehow. But still waiting for a solid answer from someone from NVIDIA (or someone else even). If you could help me out as to why the failover is not working in this specific scenario?
Additionally, I also need help regarding recovering slot status once the failover mechanism takes place. I have taken a look at the following thread:
Even though the thread is for Xavier-NX, I assumed that the process would be similar for Jetson-AGX-Xavier, and tried to run the following commands in an attempt to recover boot status of unbootable slot.
# cd /sys/firmware/efi/efivars/
# printf "\x07\x00\x00\x00" > /tmp/var_tmp.bin
# printf "\x3c\xc0\x01\x00" >> /tmp/var_tmp.bin
# chattr -i RootfsInfo-781e084c-a330-417c-b678-38e696380cb9
# dd if=/tmp/var_tmp.bin of=RootfsInfo-781e084c-a330-417c-b678-38e696380cb9; sync
# chattr +i RootfsInfo-781e084c-a330-417c-b678-38e696380cb9
# reboot
However, when I run the first chattr command (chattr -i RootfsInfo-781e084c-a330-417c-b678-38e696380cb9), I get the message:
chattr: Read-only file system while setting flags on RootfsInfo-781e084c-a330-417c-b678-38e696380cb9.
Is the above mentioned method supported for Jetson-AGX-Xavier as well? If not, then what method could be used to set the status of the unbootable slot back to bootable again?
If the method is supported for AGX-Xavier as well, then how can I change attribute of the read-only file Read-only file RootfsInfo-781e084c-a330-417c-b678-38e696380cb9, as using the chattr command as mentioned above doesnt seem to be working.