After a system reboot several times I started getting the bash environment
can I know what is the root cause of this error??
current_bash_mode_log.txt (52.2 KB)
If your system fails to boot up in consecutive 3 times, it will enter a mode called recovery boot (not recovery mode).
Jetson System firmware version 202401.0-d8a952cf-dirty date 2024-01-17T05:30:46+
00:00
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
** WARNING: Test Key is used. **
L4TLauncher: Attempting Recovery Boot
EFI stub: Booting Linux Kernel...
So what needs to be checked was why you cannot boot the system for consecutive 3 times. But not current log you shared.
what is the solution for the above bash environment problem how can I find the root cause of this bash environment issue?
current_bash_mode_log.txt (52.2 KB)
You can reflash your board first and reproduce the error. Currently your log does not help as I already explained in previous comment.
we get same logs as we shared earlier
As I already said, you need to share the log before recover boot happened…
Currently you always share the log late.
The situation would be
-
reflash the board
-
The board may boot first time and fail.
-
The board may boot second time and fail.
-
The board may boot 3rd time and fail.
-
Due to (2),(3) and (4), the board goes into recovery boot.
I need the log from either (2), (3) or (4). But you only shared the log from (5).
The crash in (2),(3) and (4) are the real root cause.
(5) is a NVIDIA boot mechanism which is not the reason of the crash…
This is a log after flashing from the first boot to the bash environment
fourth_boot.txt (63.5 KB)
third_boot.txt (73.5 KB)
second_boot.txt (74.0 KB)
first_boot.txt (70.8 KB)
Hi
It seems no obvious kernel panic from the first to third boot.
It means the cause of recovery boot is from something else. Did you customize anything in your rootfs?
Could you check do you still have nv-l4t-bootloader-config.service on your device? And what is the status of this service in every boot?
There is no customization in rootfs.
Yes, I have checked every boot nv-l4t-bootloader-config.service status
first_boot_service_status.txt (1.6 KB)
second_boot_service_status.txt (288 Bytes)
third_boot_service_status.txt (288 Bytes)
fourth_boot_service_status.txt (288 Bytes)
fifth_boot_service_status.txt (288 Bytes)
again our system is in the bash environment.
Hi,
The status showed dead and no further log from your 2nd,3rd and 4th boot. That seems to be the reason that this goes to recovery boot.
Also, there is one error in first boot status.
Apr 01 10:25:55 phoenix-desktop nv-l4t-bootloader-config.sh[9040]: Info: Spec variable TegraPlatformSpec is not found.
Could you check if you really has
/sys/firmware/efi/efivars/TegraPlatformCompatSpec-*
in your device?
This is a current log of the nv-l4t-bootloader-config.service and after 4-5 reboots system working properly till now not in a bash environment
/sys/firmware/efi/efivars/TegraPlatformCompatSpec-*
this file is also available
current_service_status.txt (1.5 KB)
OK, so is there anything else you want us to check?
Looks like issue is gone.
But nvgetty.service loading much more for execution
Is that related to the original topic? Don’t know why mentioning this.
yes related to this topic nvgetty.service loading much more time because of this service nv-l4t-bootloader-config.service also takes time for execution
Are you talking about the original issue was caused by you disabled some service ?
we have not disabled any service but nvgetty.service takes too long to execute so because of this nv-l4t-bootloader-config.service also takes time to execute.
nv-l4t-bootloader-config.service.txt (1.8 KB)
Then how did this service currently work again on your side? Did you do anything else?
You need to figure it out what is changed on your side in comparison with NV devkit. I am not your colleague and not possible to do some telepathy to know what happened on your side.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.