I followed the documentation for Modifying Jetson RAM Disk to create a custom initrd and it works fine, but after rebooting a couple times (3 times maybe?) the system goes into recovery mode and I need to physically access it in order to disable recovery mode. I tried looking in the efivars filesystem to see if there are any counters or anything that I could reset, but the only thing that I could find that was reliably counting up was a MTC file that looks like it’s just a boot counter. The RootfsStatusSlotA variable goes from 0 to 255, and it’s just stuck on 0 for each boot into my custom initrd. In recovery mode it is at 255, and if I set it back to 0 then recovery mode is disabled and the system boots normally. Is there anything I can do to figure out what’s making it go into recovery mode and prevent it from happening?
Also for some reason this only seems to happen when I reboot from Linux by using the reboot command. If I manually power cycle the device by unplugging the USB C cable then it doesn’t go into recovery mode.
Your comment sounds like recovery image. But not recovery mode.
We have a counter as what you found there and if specific script didn’t clean up the timer for consecutive 3 times, then it will enter recovery boot.
You can also use this method to give it back to direct boot.
What is this counter and how do I reset it? The efivars filesystem does not have a counter besides the MTC-eb704011-1402-11d3-8e77-00a0c969723 file that changes. The RootfsStatusSlotA-871e084c-a330-417c-b678-38e696380cb9 file does not change from 0 until it goes to recovery boot, and then it goes to 255. Do I need to delete the file?
Actually we should check why it goes into recovery image but not how to restore it.
Also, are you sure you only modified the initrd? We have a nv-l4t-bootloader-config.service in the rootfs. Is it still there in your BSP?
I added a
chroot /mnt/mmc/ bash -c /opt/nvidia/l4t-bootloader-config/nv-l4t-bootloader-config.sh -v command to my /init script and it appears to have stopped the system from entering recovery boot. I will look at that script to try and find out what commands I need to put into my init script so that I don’t need to mount the mmc partition. It looks like it might be the mtdblock driver that gets used but I will need to look at it more.
Did you customize only the initrd or you have changed the rootfs too? I am just curious.
The initrd is just an Alpine Linux aarch64 root filesystem with busybox init. I left the rootfs the same and mount it under /mnt/mmc for loading the Nvidia graphics drivers and kernel modules.
Our rootfs has systemd to run that script in every boot. So does your rootfs disable systemd? Sounds like you only leave it for specific use.
The init system is
busybox init, systemd does not run. I will copy that script to my initrd once I find all the dependencies.
Honestly, I have to say that I don’t know how many things you need to find there.
For example, even the FAN control is a systemd service.
I figured out the fan already, I have a program that will use the sysfs files to manage it. The WiFi, GPU, and USB gadget Ethernet are all working too. I don’t think there was anything else for me to work on besides the recovery boot issue, and it looks like the l4t-bootloader script has everything I need to get that completed.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.