Orin Nano: Can't change/ select UEFI boot device

Hi,

I’m working on Orin Nano, and testing boot device select.

I previously flashed all the boot option (NVMe, SD, USB).
All boot option can boot up.

But when I put multiple storage on it, it always follow the sequence of NVMe->USB->SD.
Even I follow this post and nothing changes.

When it reach ‘L4TLauncher:’ the save of UEFI is gone.
‘Delete boot option’/
‘Change boot order’/
direct select ‘Boot Manager’/
It can’t not apply all of them above.

Please help me to fix this issue.

boot log is here:
boot_log.txt (30.6 KB)

Hi joe.zhang,

Are you using the devkit or custom board for Orin Nano?
What’s your Jetpack version in use?

It seems your kernel could not be loaded successfully.
How do you flash your board?
Could you just put NVMe on the board and flash into it to verify?

Are you using the devkit or custom board for Orin Nano?
==> devkit

What’s your Jetpack version in use?
==> L4T 35.3.1

It seems your kernel could not be loaded successfully.
How do you flash your board?
==> follow this web site and flash nvme/ usb/ sd individually.

Could you just put NVMe on the board and flash into it to verify?
==> If I only attach only one boot device, others will not shown on the UEFI.


Besides, I found my test step is wrong, check the root device is not the best way.

ubuntu@tegra-ubuntu:~$ lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0          7:0    0    16M  1 loop
sda            8:0    1  59.5G  0 disk
�├�─sda1         8:1    1  58.8G  0 part
�├�─sda2         8:2    1    64M  0 part
�├�─sda3         8:3    1   448K  0 part
�├�─sda4         8:4    1    32M  0 part
�├�─sda5         8:5    1    64M  0 part
�├�─sda6         8:6    1   448K  0 part
�├�─sda7         8:7    1    32M  0 part
�├�─sda8         8:8    1    80M  0 part
�├�─sda9         8:9    1   512K  0 part
�├�─sda10        8:10   1   300M  0 part
�├�─sda11        8:11   1    64M  0 part
�├�─sda12        8:12   1    80M  0 part
�├�─sda13        8:13   1   512K  0 part
�└�─sda14        8:14   1    64M  0 part
mmcblk1      179:0    0  57.8G  0 disk
�├�─mmcblk1p1  179:1    0  57.1G  0 part
�├�─mmcblk1p2  179:2    0    64M  0 part
�├�─mmcblk1p3  179:3    0   448K  0 part
�├�─mmcblk1p4  179:4    0    32M  0 part
�├�─mmcblk1p5  179:5    0    64M  0 part
�├�─mmcblk1p6  179:6    0   448K  0 part
�├�─mmcblk1p7  179:7    0    32M  0 part
�├�─mmcblk1p8  179:8    0    80M  0 part
�├�─mmcblk1p9  179:9    0   512K  0 part
�├�─mmcblk1p10 179:10   0   300M  0 part
�├�─mmcblk1p11 179:11   0    64M  0 part
�├�─mmcblk1p12 179:12   0    80M  0 part
�├�─mmcblk1p13 179:13   0   512K  0 part
�└�─mmcblk1p14 179:14   0    64M  0 part
zram0        251:0    0 611.4M  0 disk [SWAP]
zram1        251:1    0 611.4M  0 disk [SWAP]
zram2        251:2    0 611.4M  0 disk [SWAP]
zram3        251:3    0 611.4M  0 disk [SWAP]
zram4        251:4    0 611.4M  0 disk [SWAP]
zram5        251:5    0 611.4M  0 disk [SWAP]
nvme0n1      259:0    0 119.2G  0 disk
�├�─nvme0n1p1  259:1    0    55G  0 part /
�├�─nvme0n1p2  259:2    0    64M  0 part
�├�─nvme0n1p3  259:3    0   448K  0 part
�├�─nvme0n1p4  259:4    0    32M  0 part
�├�─nvme0n1p5  259:5    0    64M  0 part
�├�─nvme0n1p6  259:6    0   448K  0 part
�├�─nvme0n1p7  259:7    0    32M  0 part
�├�─nvme0n1p8  259:8    0    80M  0 part
�├�─nvme0n1p9  259:9    0   512K  0 part
�├�─nvme0n1p10 259:10   0   300M  0 part
�├�─nvme0n1p11 259:11   0    64M  0 part
�├�─nvme0n1p12 259:12   0    80M  0 part
�├�─nvme0n1p13 259:13   0   512K  0 part
�└�─nvme0n1p14 259:14   0    64M  0 part

Seems it does select the right boot device.
(Add and check the different name boot option for extlinux.)

But It select the wrong roofs.

Yes, you may boot from SD but mount rootfs from NVMe. (you should check how kernel cmdline specify).

May I know what’s your use case?

I want to make USB storage as a rescue file.

Like if I write a systemd service with reboot condition and something went wrong.
This rootfs can’t not be use anymore(keep rebooting).

You could verify if you can switch between different boot-device as expected in normal case first.

What do you mean about “went wrong”?
Is there something failed or corrupted in rootfs?
You could check the full serial console log at this moent.

  1. With NVMe boot:
L4TLauncher: Attempting Direct Boot
L4T boot options
0: NVME primary kernel
1: primary kernel
  1. With USB boot:
L4TLauncher: Attempting Direct Boot
L4T boot options
0: USB kernel
1: primary kernel
  1. Change boot sequence: success

But like I say, both boot option mount NVMe for rootfs.

ubuntu@tegra-ubuntu:~$ lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0          7:0    0    16M  1 loop 
sda            8:0    1  59.5G  0 disk 
├─sda1         8:1    1    55G  0 part /media/ubuntu/7d793bf7-affe-43a3-9399-683
├─sda2         8:2    1    64M  0 part 
├─sda3         8:3    1   448K  0 part 
├─sda4         8:4    1    32M  0 part 
├─sda5         8:5    1    64M  0 part 
├─sda6         8:6    1   448K  0 part 
├─sda7         8:7    1    32M  0 part 
├─sda8         8:8    1    80M  0 part 
├─sda9         8:9    1   512K  0 part 
├─sda10        8:10   1   300M  0 part 
├─sda11        8:11   1    64M  0 part 
├─sda12        8:12   1    80M  0 part 
├─sda13        8:13   1   512K  0 part 
└─sda14        8:14   1    64M  0 part 
zram0        251:0    0 275.9M  0 disk [SWAP]
zram1        251:1    0 275.9M  0 disk [SWAP]
zram2        251:2    0 275.9M  0 disk [SWAP]
zram3        251:3    0 275.9M  0 disk [SWAP]
zram4        251:4    0 275.9M  0 disk [SWAP]
zram5        251:5    0 275.9M  0 disk [SWAP]
nvme0n1      259:0    0 119.2G  0 disk 
├─nvme0n1p1  259:1    0 118.5G  0 part /
├─nvme0n1p2  259:2    0    64M  0 part 
├─nvme0n1p3  259:3    0   448K  0 part 
├─nvme0n1p4  259:4    0    32M  0 part 
├─nvme0n1p5  259:5    0    64M  0 part 
├─nvme0n1p6  259:6    0   448K  0 part 
├─nvme0n1p7  259:7    0    32M  0 part 
├─nvme0n1p8  259:8    0    80M  0 part 
├─nvme0n1p9  259:9    0   512K  0 part 
├─nvme0n1p10 259:10   0   300M  0 part 
├─nvme0n1p11 259:11   0    64M  0 part 
├─nvme0n1p12 259:12   0    80M  0 part 
├─nvme0n1p13 259:13   0   512K  0 part 
└─nvme0n1p14 259:14   0    64M  0 part

=> Yes, when I modify something that would potentially corrupt the rootfs.
(can’t reach the Login Prompt or keep rebooting.)

I have no choice but re-flash all APP partition, or remove NVMe to use different rootfs.
Both take a lot of time.


I found the way to modify the rootfs target /boot/extlinux/extlinux.conf.

- root=PARTUUID=ad43ec6f-6d79-4df0-b915-1c936b0e33ef
+ root=/dev/sda1

And could change it in demo image by modify flash.sh

elif [ "${target_rootdev}" == "internal" ] || \
     [ "${target_rootdev}" == "external" ] || \
     [[ "${rootfs_ab}" == 1 ]]; then
        # For 'internal' and 'external' target root devices,
        # or enabled ROOTFS_AB=1, always use the UUID stored in the file
        # ${rootfsuuidfile} or ${rootfsuuidfile}_b if present.
        # If this file is not present, then try to generate one.
        _tmp_uuid="";

        if [ "${target_rootdev}" == "external" ] || \
        [ "${external_device}" -eq 1 ]; then
                rootuuid_restore "_ext"
                _tmp_uuid="${rootfsuuid_ext}";
        else
                rootuuid_restore ""
                _tmp_uuid="${rootfsuuid}";
        fi

        if [ ${disk_enc_enable} -eq 1 ]; then
                # The encrypted fs UUID of the rootdev.
                if [ "${external_device}" -eq 1 ]; then
                        rootuuid_restore "_ext_enc"
                        _tmp_uuid="${rootfsuuid_ext_enc}";

                        bootpartuuid_restore "_ext"
                        rootfsuuid_enc="${rootfsuuid_ext_enc}"
                        rootfsuuid_b_enc="${rootfsuuid_b_ext_enc}"
                        # These variables are set in disk_encryption_helper.func
                        bootpartuuid="${bootpartuuid_ext}"
                        # These variables are set in disk_encryption_helper.func
                        bootpartuuid_b="${bootpartuuid_b_ext}"
                else
                        rootuuid_restore "_enc";
                        _tmp_uuid="${rootfsuuid_enc}";

                        bootpartuuid_restore;
                fi

                cmdline+="root=UUID=${_tmp_uuid} rw rootwait rootfstype=ext4 "
        else
                cmdline+="root=PARTUUID=${_tmp_uuid} rw rootwait rootfstype=ext4 "
        fi;
else
        cmdline+="root=/dev/${target_rootdev} rw rootwait rootfstype=ext4 "
fi;
1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.