Conversation
Jetson boards had no way to fix a persistent BootOrder mismatch in-image, since avocado-boot-device was never pulled into the Tegra rootfs or initramfs packagegroups. Provisioning a new image onto a disk does not change firmware boot order, so a board could keep booting an older medium with no in-OS remedy short of a manual efibootmgr procedure. Add avocado-boot-device as a runtime dependency of both the Tegra rootfs and initramfs packagegroups so the tool ships by default on these images, and document the fix-up procedure, including the efibootmgr-based manual fallback for OS images that predate this change. Signed-off-by: Javier Tia <javier@peridio.com>
There is currently no reliable way for userspace on a provisioned Jetson device to determine which boot medium (eMMC, NVMe, USB, etc.) the flash actually targeted. Consumers would otherwise have to re-derive this from BOOTDEV/ROOTFS_DEVICE at runtime, which is error-prone and duplicates logic already resolved during provisioning. Write the already-resolved boot_media value into a marker file on the var image immediately after the boot medium case statement completes. Keying the marker on the resolved value, rather than writing it inside each branch of the case, avoids duplicating the write logic across every boot media type and guarantees the marker always reflects the final decision made by the script. Signed-off-by: Javier Tia <javier@peridio.com>
After flashing a new boot medium (NVMe, SD, eMMC, USB), Jetson platforms need the UEFI BootOrder updated to reflect the freshly written device before the system reboots into it. Today this adjustment only happens if something explicitly invokes avocado-set-boot-device after flashing, so a flash-and-reboot flow can leave the bootloader pointing at the wrong medium and boot the previous image instead of the one just written. Introduce avocado-boot-order-assert, a lightweight initramfs service that checks for a marker file left on the var partition naming the medium that was just flashed. If present, it invokes avocado-set-boot-device to reprogram BootOrder before switch-root hands off to the real rootfs, then removes the marker; if the update fails, the marker is left in place so the assertion is retried on the next boot. Running this step in the initramfs, after the var partition is mounted but before switch-root, guarantees the boot order is corrected as early as possible without requiring changes to the full rootfs image, and keeps the flashing tooling decoupled from boot-order logic by communicating solely through the marker file. A custom initrd-preset file is shipped alongside the systemd unit since current systemd versions look for initrd-preset rather than system-preset when generating presets inside an initramfs image. Signed-off-by: Javier Tia <javier@peridio.com>
The boot order assertion script running in the Tegra initramfs environment relies on grep and sed for parsing and validating boot device configuration. Without these utilities present in the initramfs image, the assertion logic fails at runtime since the minimal initramfs environment does not include them by default. Add grep and sed as runtime dependencies of the packagegroup-avocado-tegra-initramfs package group so they are always available when the boot order assertion executes during early boot. Related: ENG-2132 Signed-off-by: Javier Tia <javier@peridio.com>
…ot-order-assertion Archiving jetson-boot-order-assertion. These two capability pages are the only artifact from this change that survives the worktree deletion and reaches the base branch, so they are committed here rather than left in the devspec data directory. Signed-off-by: Javier Tia <javier@peridio.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Jetson boards never assert UEFI
BootOrderfor the medium provisioning just flashed, so firmware keeps booting whatever it already preferred - reproduced on hardware where NVMe provisioning after a prior USB provision left the board silently booting USB again.Solution
Composes the
avocado-boot-devicetool (#393) into the Tegra rootfs and initramfs package groups by default, adds a marker write tostone-provision-tegraflash.shnaming the medium just flashed, and adds a oneshot systemd unit that reads that marker before switch-root and asserts persistent boot order for it. A failed assertion leaves the marker in place so the same intent survives to the next boot.Key changes
avocado-boot-order-assert: new recipe, initrd-stage oneshot unit, sibling to the existing early-boot rootfs-selection unitstone-provision-tegraflash.sh: writes a per-medium marker onto the var image at flash timepackagegroup-avocado-tegra-{rootfs,initramfs}.bb: composeavocado-boot-device(andgrep/sed, needed for its class matching) by defaultdocs/boot-device-selection.md: manual assertion command and its fallback for images predating this changeReviewer notes
Stacked on #393 (
boot-device-extension) - this PR's base is that branch, notscarthgap, and it can't merge until #393 does. Hardware-verified on an Orin Nano bench across SD and NVMe: automatic assertion on first boot, manual assertion plus fallback, and fail-safe retry across three consecutive failed/successful boots. I'd like a look at the systemd unit's capability set (CapabilityBoundingSet=CAP_SYS_ADMIN, confirmed sufficient by repeated hardware writes rather than by inspection) and at the marker's trust boundary - it's a build artifact rather than user input, but the assertion tool does read it unvalidated beyond a class allowlist.