Using Jetson AGX Orin on my autonomous device resulted in an inability to access the root system properly

When I modified the/etc/rc.local file and sudo rebooted, the following phenomenon occurred.


我在rc.loacl里面添加了
sleep 3s
sudo ifconfig eth0 up
sudo ifconfig eth0 down

Below is my kernel printing information and the/etc/rc.local file
dmesg (81.7 KB)
rc.local (458 Bytes)

Why did I enter bash? What should I do to avoid sudo reboot into bash after adding the ifconfig up down operation?
Do you have any good suggestions.

I’m not positive, but it looks like you went to a shell due to filesystem errors. This is unrelated to the rc.local changes, and probably from incorrect shutdown. Are you always shutting down correctly, or is power being removed? The other reason this might occur is if some software caused the system to lock up and make shutdown unavailable.

Incidentally, using chmod on “/dev/ttyTHS*” in rc.local is not the right way to work with this. Those are device special files, which means they are not “real” files, but are instead kernel drivers “pretending” to be a file to allow communications with the driver. As such, you should instead do one of these:

  • Give your user permissions. Without the chmod, what do you see from:
    • ls -l /dev/ttyTHS*
    • What do you see from:
      egrep whoami /etc/group
  • Then add your user to the group of the serial UARTs. Note that if a UART is group tty, then you should not use this UART for general purposes, it is already used as a serial console; if the UART is group dialout, then it is free to use, and you can add your user to group dialout.
  • If you truly want to change the UART device special file ownership or permissions, then this is properly done through a udev edit.

As for the broken filesystem, it seems that it is sufficiently broken that the journal cannot fix this without risking loss. How attached are you to that content? You can clone, and then try to repair the clone on loopback (this takes a lot of time and disk space on the host PC), but you will lose something (and you cannot predict what would be lost, although items being written and not flushed are high on the hit list).

Yes, I have verified that it has nothing to do with rc.local. I don’t understand how to define an incorrect shutdown? I sudo reboot without cutting off the power, and after repeated operations, bash5-0 will appear. The command I burned on the PC is: sudo/ Flash.sh - r jetson agx orin devkit mmcblk0p1 Additionally, I am not sure if it is related to using a real-time kernel.

Incidentally, you can put a left backquote (unshifted tilde key in the upper left of the keyboard) on the left and right side of short commands to mark them as code on the forums. I suspect you wrote “sudo/ Flash.sh - r jetson agx orin devkit mmcblk0p1” because the forum was messing up if you typed the exact command. Multiline code blocks use a single line of three backquotes above and below, e.g.,
```
code
```

The sudo reboot and other sudo type shutdown commands should be valid and the filesystem should not be corrupt from that. Meaning `something` (I escaped the backquote here).

What filesystem did you use when you ran:
sudo ./flash.sh -r jetson-agx-orin-devkit mmcblk0p1
?

When you use the “-r” option you are telling it to reuse an existing rootfs image. If that image is not valid, or if it is corrupt, then the result will also be invalid or corrupt. It is possible that the ext4 filesystem issue is from that. Anything which is not a “working” ext4 filesystem would have that result, e.g., missing an ext4 driver would do the same (obviously it isn’t missing the driver in this case, this is just an illustration).

You never mentioned the new kernel. This indeed could be the cause. Some possibilities from this:

  • The boot setup from installing the new kernel is invalid, e.g., from an install issue for the kernel.
  • The kernel configuration is not correct, e.g., the kernel is installed correctly, but it was not correctly configured before installing.
  • The initrd is not correctly set up (this is a subset of the boot setup) such that the initrd itself does not have what it needs. There is a script, “Linux_for_Tegra/tools/kernel/flash/l4t_initrd_flash.sh” for use when an initrd is to be modified.

I couldn’t tell you whether you need the l4t_initrd_flash.sh or not. Most people don’t use this, but sometimes when doing A/B redundancy or any kind of alternate boot setup (e.g., to external device), this tends to be used.

Without knowing if the kernel itself is valid, it isn’t really possible to say if the l4t_initrd_flash.sh is needed. The documentation on A/B failover probably is what you need to consult if you are trying to enable this. If that is correct, then the question next goes to whether your kernel was built and installed correctly. Much of that I cannot answer.

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