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.
- With NVMe boot:
L4TLauncher: Attempting Direct Boot
L4T boot options
0: NVME primary kernel
1: primary kernel
- With USB boot:
L4TLauncher: Attempting Direct Boot
L4T boot options
0: USB kernel
1: primary kernel
- 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