OpenEmbedded for Tegra
Can't switch from slot B to A #2081
Answered
by
madisongh
antoinefaure
asked this question in
Q&A
|
Hi, Thanks again for this meta. Long story short, I had an update system that worked a while ago (based on Rauc) but the work on the Jetson was put on hold. Since then we have updated from Kirkstone to Scarthgap, I don't know if that's related to my issue. Basically I have a standard dual slot system from the following XML: In my machine configuration I also have: And all the fluff for the SSD size, overlay fs configuration etc. It boots fine on slot A. Then I do the opposite and try to switch back to the slot A with It randomly works after a while. I have tried mounting/unmounting Note: I did not overwrite the inactive slot before trying to switch to it. At first I did but I stopped to isolate the issue and confirm it was not due to my update image. I'm using a Jetson Orin NX 16GB from Seeedstudio (J4012). I'm attaching the logs from the serial adapter. Any help would be greatly appreciated. |
Answered by
madisongh
Dec 1, 2025
Replies: 4 comments 6 replies
|
It looks like attaching the raw log file doesn't work for some reason, so am dumping the logs here. |
0 replies
|
Someone from nvidia advised me to test this with their SDK, and it appears to be working. So it looks like the issue is tied to my Yocto setup. |
1 reply
|
Has the RAUC tegra support been updated for Orins and JetPack 5 and 6? Last I looked at the community layer for it, the only example implementation I saw was for the TX2. Getting the redundancy setup right isn't well documented. Would it help to compare with a sample implementation using swupdate? There's one here in the demo distro. I've been playing around with the meta-mender-tegra community layer, and while it's got some bugs, it mostly works for JetPack 6, too. |
|
Thanks @madisongh I have added the rauc support myself in our meta. It appears to be working fine but just to be sure I am not doing any updates right now; I am simply trying to switch between both slots. In the xml you can see that both slots have their rootfs, kernel etc flashed with the initial image. One thing that is interesting is that when I boot Until I manually mount But the directory Thanks for pointing to the demo distro; I've had a look and didn't see many differences:
Any help would be greatly appreciated as I am out of ideas. |
5 replies
Definitely. Do you use systemd or some other init manager? systemd should automatically mount the efivars filesystem at boot time. The default kernel config has If you use some other init manager, you probably need to add an entry to your fstab. |
|
I have checked and I do have I am also using systemd. What's strange is that on a cold boot that folder is empty even though mount shows: I can't umount it as it tells me: I don't see any useful logs related to efi: But then if I mount efivarfs manually with : I do see files in Forgot to say but to flash my board I do : |
|
It turns out that systemd's EFI support is only configured in if The If you have customized your initrd, you might want to check that it includes similar logic to the minimal-int script in the layer. I don't really have much else to suggest other than adding some instrumentation in your initrd and boot sequence to see if the mount is even being attempted, and if it is, seeing why it failed. |
Answer selected by
antoinefaure
|
That's it! I didn't have Thank you SO much for your help @madisongh, this has been driving me nuts for a wee while! It would probably be worth adding this information in the Redundant Rootfs A B Partition Support page ? Thanks again ! |
|
Glad you've got a solution. That wiki page (and several others) needs a refresh, and with the amount of information that changes with L4T major versions, I'm thinking about moving documentation out of the wiki and into the the layer repo itself. This one would be a good candidate for that. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It turns out that systemd's EFI support is only configured in if
efiis in DISTRO_FEATURES, and that's not set by default.The
tegra-minimal-initinit script we have in the layer, which gets incorporated by default into the initrd, has a mount for the EFI variables in it, so theBootChainOsCurrent-781e084c-a330-417c-b678-38e696380cb9variable can be read, and that, is used to determine which rootfs partition to mount. That mount is probably getting retained across theswitch_rootwhen the initrd transfers control to the main rootfs, and that's why I'm seeing it on my device.If you have customized your initrd, you might want to check that it includes similar logic to the minimal-int scrip…