Enter OEM interface after reboot

Yes, the content in my rootfs source file is just like this. I want to make it clear that after I use “l4t_create_default_user.sh”, the OEM interface will be skipped after I swipe the machine, but the OEM interface will appear again after I restart (restart after accidental power failure). Do you understand my meaning? thank you

So, the first boot can successfully skip the OEM interface, but it will appear after first reboot? (Or occur occasionally?)
If you finish the process of system configuration, will it still appear after reboot?

Have you tried to flash clean r35.1 (JetPack5.0.2) on your devkit through SDK Manager without any modification at rootfs? and see if the issue would appear.

  1. Yes, the OEM interface can be skipped for the first startup. After restart (not necessarily the first restart), this problem will occur occasionally. If the device is powered off and restarted after the restart, this problem will also occur;

  2. This hasn’t happened yet when using SDK Manager. After all, the system will not skip the OEM interface after using SDK Manager. Can you find clues from my log?

In the screenshot with “orphan inodes deleted”, and “recovery complete”, it means the system was not shut down correctly. Part of the data, presumably cached but not yet written, was reverted to avoid filesystem corruption. If one is for example performing first boot account setup, then that data is actively being written. Should power then be lost before the cached/buffered content is written, then that log message would be expected in order to save the system (but it would have lost the first boot account setup).

There are times when an error means it isn’t possible to shut down correctly, but were there any moments when a unit being set up was shut down prematurely after a first boot setup?

Let me see,

First of all, thank you very much for your answer.

  1. Do you mean that cached data (user configuration) is not written to disk properly?

2, if according to what you said, then how to judge the normal writing? That is, to ensure that the system can function properly and this situation will not happen again.

  1. I recall that sometimes this happens not on the first restart after running the system, but on a single restart after several restarts. Is the user configuration written to disk on the first boot, or before a reboot or power outage?

  2. If it is written to disk before restarting or power off, is this configuration that skips OEM interface to write to disk every time? Instead of writing to disk the first time the system runs after the flush?

Short answer: Most of the time you don’t need to worry so long as you don’t try to shut down by pulling the power. This is the nature of all modern computers. Long answer is more useful an interesting than most people would think (I’m odd)…

Also, if you shut down normally after a first boot account setup, then there is no need to do anything. It is when something goes wrong that it matters.

Unless a hard drive is specifically told to not buffer, and to run synchronously, it never writes directly to the disk or solid state memory. It has its own internal buffer. The operating system itself can add to this. When the disk is told to sync, it starts the process, but is not guaranteed to complete it (e.g., if power goes down it might actually complete if capacitors exist in the right place). On every disk made going into synchronous mode and not doing this results in an extreme performance loss. On solid state memory, e.g., eMMC or SD cards, this also causes an extreme loss of operating lifetime (the drive will fail very fast if always run in synchronous mode…this is what “wear leveling” is for in conjunction with buffers or cache). So yes, they do run a cache or buffer regardless of whether the operating system does this, but the operating system often adds more.

As an experiment install “xosview” (“sudo apt-get install xosview”). This is a GUI load display widget. You can enlarge it, and under “MEM” (memory) it color codes different classifications. You’ll find some RAM is classified as “cache” and some as “buff” (buffered). The cache tends to be RAM which acts as a middleman to the filesystem (perhaps more than the filesystem). Watch cache as you run this command (first use “sudo -s” since this requires root), which simply reads and discards what it reads from every regular file (there is no need to buffer this since content is thrown away):

find / -type f -print0 | xargs -0 egrep '.*' 2>/dev/null 1>/dev/null

You’ll see cache go up. You can stop the “find” command above (e.g., CTRL-c), and note that the cache in xosview will not go down. This is because the RAM used to read the content will (to some extent) remain in memory until RAM is needed for something else. If you were to write to that location, then the command doing the write would really be writing to that cache RAM in most cases, and then the cache would be written to disk over time (time possibly in milliseconds or seconds).

A second example would be working with those huge rootfs/APP partition images during a flash. If you have a system.img.raw file, e.g., maybe 28 GB or even larger, then you copy it somewhere else, it would take a lot of time to copy the file. When it is done copying, it isn’t really done. You could run the command “sync” to tell the disk to sync the cache, and on such a large file, this too would take significant time. Had the system lost power before this, all of that content would be lost. You don’t much care about cache which was only read (it isn’t changed), but content which was written and not flushed to disk via a sync will be gone. Worse, if the amount of outstanding unwritten content exceeded the filesystem journal, then it would not be able to compensate and you would have a corrupt filesystem needing manual intervention (which often leads to less than stellar results).

To see how much space journals are consuming:
journalctl --disk-usage

I have a desktop system with a mix of SSD and regular disks having a total of 3.9 GB of journal. I have a Jetson Orin here with 16 MB of journal. I’d have to have a lot of unwritten data for the desktop to corrupt upon power loss, but it would also lose a lot of file content. The Orin would corrupt if more than 16 MB of unwritten journal is required.

Keep in mind that if you constantly sync a solid state drive, then its life will go down. However, every normal shutdown performs sync. Also, someone here wisely pointed out that the first sync completing is not the same as the cached content actually completing write. It just means the sync command to flush the cache/buffers has begun. However, if you manually run the “sync” command (anyone can do this on command line) twice, then the second sync won’t return until it is allowed to start…which is after the first sync has completed. If there was nothing to write on the second sync, then it doesn’t actually do anything, so this would not put any wear on the disk. Before you do anything risky, manually run “sync” twice before you do it. It won’t guarantee no loss, but likely it will be a “near” guarantee that the journal size will not be exceeded and such a loss will be little more than annoying.

During a normal startup, before login (or perhaps even up to login), it is unlikely any crash or failure would exceed the journal size. It isn’t good to lose power or crash during a startup, but mostly this will be harmless as you’re not editing configuration files. Log files might get truncated, temporary files (which are already not intended to have any meaning upon reboot) might get lost, but much of this won’t matter. However, on a first boot account setup, that content could be lost (either all or in part).

For power outage, get an UPS. This is just the way it is: Cutting power on a running computer is “just bad” (™). I don’t have an UPS on my main computer, they’re just too loud when they are capable of putting out that much power (and the fans don’t go off just because nothing is drawing power). So I risk it. However, I only lose power about once in a year. A Jetson could much more easily use some sort of battery backup system since it uses so little power.

If you plan to do something risky, then running the “sync” command on command line does the job. If the system is failing and you don’t have a login, but you have a local keyboard (or serial console, but that changes details), you can easily use the Magic SysRq key combination to sync. At a local keyboard just hit the “ALT-SYSRQ-s” key combination (the SYSRQ key is generally next to the scroll lock key, and is the unshifted PrtScn key). If you monitor “dmesg --follow”, and then hit this combination (it doesn’t hurt to do this occasionally), you’ll something like “Emergency Sync complete”. Use this twice before purposely doing something risky, e.g., pulling the power plug. Don’t do this a lot (at least not if you have solid state drives).

If you have a serial console, then you don’t have direct keyboard access. This means you have to use echo commands to the right file instead of using ATL-SYSRQ-s. That file is “/proc/sysrq-trigger”. So to sync, you don’t need CTRL-SYSRQ, you would instead:
echo s > /proc/sysrq-trigger

Note that an extension of this, if you know the system has to be shut down, is to also use Magic SysRq to remount the filesystem read-only (you can’t harm a read-only system, nothing is cached or buffered) after the sync. Example:

# Two syncs:
ALT-SYSRQ-s
ALT-SYSRQ-s
# Remount read-only:
ALT-SYSRQ-r

You could even shut down as well even when most of the system is locked up and not responding (you could tell the system to shut down in ways normal shutdown would fail doing):

# Two syncs:
ALT-SYSRQ-s
ALT-SYSRQ-s
# Remount read-only:
ALT-SYSRQ-r
# The "boot" command:
ALT-SYSRQ-b

(on serial console just echo that character to the “/proc/sysrq-trigger”)

FYI, Magic SysRq is often used with kernel debugging. There is something called kgdb and kgdboc. It allows (to some extent) running a kernel in a debugger over a serial console. The Magic SysRq is needed for that.

Incidentally, not all Magic SysRq keys are valid on all architectures. Sometimes this is also disabled for security reasons. Often a subset is made available by default. One can add “kernel.sysrq=...number...” to create a bitwise mask of the allowed Magic SysRq functions to “/etc/sysctl.conf”. There are actually many parameters one can adjust in “/proc/sys” via a parameter in “/etc/sysctl.conf”, e.g., network adjustments like IPv4 fragmentation.

OK,thank you,i try

Hi jiangyinghao,

If you use SDKManager to flash the board with “pre-config” setting, it should also skip “System Configuration” at first boot. You also can enable auto-login after entering desktop. (system settings->user accounts->click “unlock”->enable “automatic login”)

For your reference, this is the instruction to install jetson with SDK Manager.
Install Jetson Software with SDK Manager :: NVIDIA SDK Manager Documentation

Hello, I don’t want to use sdk manager, because this is my customized system

okay, I just want to clarify the difference between manual flash and SDK Manager.

What do you modify in rootfs for your customized board?
Could you also please provide the command when you flash the board?

This has nothing to do with the reboot command. My suggestion is that you look at the content I replied earlier. I skipped the OEM interface by creating a user’s script. That is, it is OK to use it for the first time after the reboot. The OEM interface will appear when you use it again (restart/power plug). What’s the difference between this and the reboot command??

My brush command

sudo ./flash. sh -r jetson-agx-orin-devkit mmcblk0p1

sudo ./flash. sh jetson-agx-orin-devkit mmcblk0p1

/tools/l4t_create_default_user.sh -u $userName -p $userPasswd -a --accept-license -n $hostName

You have to use flash command without “-r” parameter to re-build system.img for applying the content from l4t_create_default_user.sh.

This command needs super user (sudo) permission to work.

It looks worked at first boot but might show up OEM interface again after another reboot (or power outage) in your case.
I’m trying to reproduce this issue on devkit, but I’ve not seen it.

Do you modify anything in rootfs?
Or the method (sync) from @linuxdev could help?

  1. I know the difference between - r in the flush command. I first compile the image on the server to generate an img file and then download it to the local computer. Then I use the - r parameter to flush the computer. The rootfs in the image have already used the script for creating users.

  2. This is not a problem that can be copied immediately. My suggestion is to start from logs.

i use sudo

Could you help to confirm the following items:

  1. Is the following message missing when the issue occurs?
    [ 30.969689] 1]: Started Forward Password Requests to Wall Directory Watch.

  2. Does the content in /etc/gdm3/custom.conf change when the issue occur?

  3. Use the source in JetPack_5.0.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra w/o other modification
    1). export your userName, userPasswd, hostName
    2). $ sudo ./tools/l4t_create_default_user.sh -u $userName -p $userPasswd -a --accept-license -n $hostName
    3). $ sudo ./flash. sh jetson-agx-orin-devkit mmcblk0p1

Thank you.

  1. Where can I read this message? Is it in the serial port startup log? I’ve uploaded it, but I can’t find it.

  2. No change

Can I find problems in my blog?

I did make many changes in rootfs. Because this is the image we need to customize

This message could be found in UART console log. (like dmesg-96.7KB you uploaded before)

Do you customize the rootfs on the devkit or custom board?
If you are able to flash clean JetPack5.0.2 with l4t_create_default_user.sh, I think that would be helpful to clarify if modification in rootfs causes this issue.