Is it related to the number of “orphan inodes” deleted? I’m not sure, because I saw that the number was 4 before, but it was 5 this time.
Could you help to confirm the log you provided
normal —> boot.log (107.3 KB)
abnormal —> dmesg (96.7 KB)
or opposite?
=========================
I found both logs can recognize hostname
[ 30.681738] 1]: Set hostname to <mos>.
[ 29.600857] systemd[1]: Set hostname to <mos>.
but one (dmesg-96.7KB) with forward password message, another (boot.log-107.3 KB) not
[ 30.969689] 1]: Started Forward Password Requests to Wall Directory Watch.
opposite
Could you help to check the content in /etc/gdm3/custom.conf ?
The configuration if set as you expected
AutomaticLoginEnable = true
AutomaticLogin = XXXXXXX
After the OEM page is displayed, you cannot access the system to view files
This is the rootfs after executing the create user script
AutomaticLoginEnable = true
AutomaticLogin = XXXXXXX
l4t_create_default_user.sh should be run before flash the board.
You can use UART console (by Micro-USB with /dev/ttyACM0) to check /etc/gdm3/custom.conf
or you can check your source of rootfs (which you said that you customize)
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.
-
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;
-
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.
- 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.
-
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?
-
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