Incorrect /etc/tmpfiles.d/00-create-volatile.conf breaks logfile storage

In most scarthgap-7 builds, we’re just now noticing that we don’t have a valid /var/volatile/log directory (thus no usable /var/log symlink), and it turns out that something’s installing an incomplete copy of 00-create-volatile.conf in /etc/tmpfiles.d/. For most apps that just use syslog(), that doesn’t break the app–it just means the app’s log messages don’t get stored. It does, however, prevent mysqld from starting.

So now we need to track down what recipe is including the broken 00-create-volatile.conf? If we simply remove that, the fully-fleshed-out version in /usr/lib/tmpfiles.d appears to be sufficient.

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:


Hello! Thank you for reaching out with your question.

You’ve observed that in some scarthgap-7 builds, /var/volatile/log (and thus /var/log) isn’t properly set up, which can affect services like mysqld. This typically relates to how the 00-create-volatile.conf tmpfiles configuration is handled.

Key Points and Guidance:

  • Default Behavior: By default, Toradex distributions set up /var/log as a symlink to /var/volatile/log, and this volatile directory is managed in RAM for flash wear reduction. This setup is controlled via tmpfiles configuration, specifically by files like /etc/tmpfiles.d/00-create-volatile.conf or /usr/lib/tmpfiles.d/00-create-volatile.conf.
    Persistent journald logging documentation

  • Issue Description: If an incomplete 00-create-volatile.conf lands in /etc/tmpfiles.d/, it overrides the system-wide configuration in /usr/lib/tmpfiles.d/, possibly resulting in missing or misconfigured directories needed for proper logging operation.

  • Investigating the Cause:

    1. Recipe Search: Within your Yocto or OpenEmbedded build environment, you can search for which recipe is installing or modifying 00-create-volatile.conf using the following command in your build directory:

      grep -r "00-create-volatile.conf" meta-*/recipes*/
      

      Check for references in both meta-toradex-* layers and any custom layers you might be using.

    2. Removal as Workaround: You are correct—if you remove or rename the incomplete /etc/tmpfiles.d/00-create-volatile.conf, the system will use the (likely correct) configuration in /usr/lib/tmpfiles.d/. This usually restores expected behavior.

    3. Permanent Fix: The best long-term solution is to identify and correct the recipe responsible for installing the malformed config file. Adjust or patch the recipe so that either:

      • It installs the complete, correct 00-create-volatile.conf, or
      • Does not install an unnecessary or incomplete version at all.
  • Manual Hotfix:
    You can also create a custom bbappend for the offending recipe that either deletes or replaces the faulty file during the install step.

Summary

  1. Search your layer sources for the origin of the incomplete 00-create-volatile.conf.
  2. Either remove the incorrect file or ensure it is replaced with a correct version.
  3. Review layer modifications if you are using custom layers, as this is often where overrides occur.

For more details on the logging system’s default setup, see:
Persistent journald logging

If you need further assistance on how to patch a recipe or investigate with more advanced Yocto/OpenEmbedded tools, please let me know!

Best regards,
Toradex AI Assistant.

Yup, it’s apparently meta-toradex-torizon/recipes-core/systemd/systemd_%.bbappend creating that file:

do_install:append() {
    if [ ${@ oe.types.boolean('${VOLATILE_LOG_DIR}') } = True ]; then
        sed -i '/^d \/var\/log /d' ${D}${nonarch_libdir}/tmpfiles.d/var.conf
        echo 'L+ /var/log - - - - /var/volatile/log' >> ${D}${sysconfdir}/tmpfiles.d/00-create-volatile.conf
    else
        # Make sure /var/log is not a link to volatile (e.g. after system updates)
        sed -i '/\[Service\]/aExecStartPre=-/bin/rm -f /var/log' ${D}${systemd_system_unitdir}/systemd-journal-flush.service
    fi

Greetings @jarndraugr,

Thank you for bringing this to our attention. Something is definitely off here. On 7.2.0 I can confirm the following.

There is a symlink from /var/log to /var/volatile/log:

$ ls -l /var/log
lrwxrwxrwx 1 root root 17 May 10 00:11 /var/log -> /var/volatile/log

But, /var/volatile/log doesn’t actually exist in any form:

$ ls -l /var/volatile/
total 0

Furthermore, checking the logs for systemd-tmpfiles-setup.service I see the following:

Jan 08 18:22:59 verdin-imx8mp-06849059 systemd-tmpfiles[451]: Failed to open path '/var/log': No such file or directory
Jan 08 18:22:59 verdin-imx8mp-06849059 systemd-tmpfiles[451]: Failed to open path '/var/log': No such file or directory
Jan 08 18:22:59 verdin-imx8mp-06849059 systemd-tmpfiles[451]: Failed to open path '/var/log': No such file or directory
Jan 08 18:22:59 verdin-imx8mp-06849059 systemd-tmpfiles[451]: Failed to open path '/var/log': No such file or directory

Comparing with our version 6.8.2. OS based on Kirkstone I see the following. I see the following:

The symlink start and endpoints actually exist. There’s no errors in the service and the file has it’s usual contents plus the line we append in our bbappend:

cat /etc/tmpfiles.d/00-create-volatile.conf
#This goes hand-in-hand with the base-files of OE-Core. The file must
# be sorted before 'systemd.conf' becuase this attempts to create a file
# inside /var/log.


d               /run/lock               1777    -       -       -
d               /var/volatile/log               -       -       -       -
d               /var/volatile/tmp               1777    -       -
L+ /var/log - - - - /var/volatile/log

This file gets installed by the base systemd recipe in openembedded-core, and we just add that last line to it in our bbappend. Therefore something must have changed in the base systemd recipe in Scarthgap. Looking at the recipes between the two versions I see the issue now.

In Kirkstone the recipe had this line to install the file:

install -m 0644 ${WORKDIR}/00-create-volatile.conf ${D}${sysconfdir}/tmpfiles.d/

This led to it being installed in /etc/tmpfiles.d which we append to.

Now in Scarthgap it was changed to:

install -m 0644 ${WORKDIR}/00-create-volatile.conf ${D}${nonarch_libdir}/tmpfiles.d/

Which leads to it being installed in /usr/lib/tmpfiles.d instead. Which is okay, but we need to update our bbappend to append the additional line to the new install location. Right now it’s appending to the old location which creates a new file instead since nothing is there anymore by default.

Well that was an interesting issue to investigate, I’ll create a ticket for our team to review and update our bbappend. Thank you again for bringing this to our attention.

Best Regards,
Jeremias

Hi @jarndraugr,

Just to inform you, this issue should now be resolved with the following commit: systemd: Fix volatile logs · torizon/meta-toradex-torizon@51e8f15 · GitHub

Thank you again for bringing this to our attention.

Best Regards,
Jeremias

Hi @jeremias.tx

I’m trying to persistently store logs from my docker-contained Qt application, and successfully see logs via journalctl after enabling the journald logging driver in my docker-compose.yml.

However, when I enable persistent journald logging as described in this article, I no longer get most journald messages, including from my application.

Could the problem discussed in this thread have something to do with it?

I tried copying the more complete 00-create-volatile.conf from /usr/lib/tmpfiles.d to /etc/tmpfiles.d and then removing the lines containing /var/volatile/log as described in the article, but no luck.

I’m running torizoncore 7.2.0 build 13 on a Verdin iMX8M Mini on a mallow carrier board.

Note: after enabling persistent journald logging, this is the logging output that I see:

torizon@amplifidx-dx100-alpha-unit4:~$ journalctl 
Jan 08 10:23:37 amplifidx-dx100-alpha-unit4 systemd[1143]: Queued start job for default target Main User Target.
Jan 08 10:23:37 amplifidx-dx100-alpha-unit4 systemd[1143]: Created slice User Application Slice.
Jan 08 10:23:37 amplifidx-dx100-alpha-unit4 systemd[1143]: Reached target Paths.
Jan 08 10:23:37 amplifidx-dx100-alpha-unit4 systemd[1143]: Reached target Timers.
Jan 08 10:23:37 amplifidx-dx100-alpha-unit4 systemd[1143]: Starting D-Bus User Message Bus Socket...
Jan 08 10:23:37 amplifidx-dx100-alpha-unit4 systemd[1143]: Listening on D-Bus User Message Bus Socket.
Jan 08 10:23:37 amplifidx-dx100-alpha-unit4 systemd[1143]: Reached target Sockets.
Jan 08 10:23:37 amplifidx-dx100-alpha-unit4 systemd[1143]: Reached target Basic System.
Jan 08 10:23:37 amplifidx-dx100-alpha-unit4 systemd[1143]: Reached target Main User Target.
Jan 08 10:23:37 amplifidx-dx100-alpha-unit4 systemd[1143]: Startup finished in 1.539s.
-- Boot aa48d34d20404895ba2e7e97bc4e9cce --
Jan 08 10:29:55 amplifidx-dx100-alpha-unit4 sudo[1215]:  torizon : TTY=pts/0 ; PWD=/var ; USER=root ; COMMAND=/usr/sbin/reboot
Jan 08 10:29:55 amplifidx-dx100-alpha-unit4 systemd[1145]: Activating special unit Exit the Session...
Jan 08 10:29:55 amplifidx-dx100-alpha-unit4 systemd[1145]: Stopped target Main User Target.
Jan 08 10:29:55 amplifidx-dx100-alpha-unit4 systemd[1145]: Stopped target Basic System.
Jan 08 10:29:55 amplifidx-dx100-alpha-unit4 systemd[1145]: Stopped target Paths.
Jan 08 10:29:55 amplifidx-dx100-alpha-unit4 systemd[1145]: Stopped target Sockets.
Jan 08 10:29:55 amplifidx-dx100-alpha-unit4 systemd[1145]: Stopped target Timers.
Jan 08 10:29:55 amplifidx-dx100-alpha-unit4 systemd[1145]: Closed D-Bus User Message Bus Socket.
Jan 08 10:29:55 amplifidx-dx100-alpha-unit4 systemd[1145]: Removed slice User Application Slice.
Jan 08 10:29:55 amplifidx-dx100-alpha-unit4 systemd[1145]: Reached target Shutdown.
Jan 08 10:29:55 amplifidx-dx100-alpha-unit4 systemd[1145]: Finished Exit the Session.
Jan 08 10:29:55 amplifidx-dx100-alpha-unit4 systemd[1145]: Reached target Exit the Session.
Jan 08 10:29:55 amplifidx-dx100-alpha-unit4 (sd-pam)[1147]: pam_warn(systemd-user:setcred): function=[pam_sm_setcred] flags=0x8004 service=[systemd-user] terminal=[<unknown>] user=[tor>
torizon@amplifidx-dx100-alpha-unit4:~$ 

Cheers,
Jeff

Hi @jeffgable,

Could the problem discussed in this thread have something to do with it?

Yes the issue described in this thread would most likely have an effect on persistent logging. The fix that was done here came after version 7.2.0 was released, so it would make sense. The next release would have this fix.

I tried copying the more complete 00-create-volatile.conf from /usr/lib/tmpfiles.d to /etc/tmpfiles.d and then removing the lines containing /var/volatile/log as described in the article, but no luck.

How exactly did you do this? Just coping the file exactly as is will not work. I just tried myself on 7.2.0 and persistent logging works fine once /etc/tmpfiles.d is adjusted. This is what the file in /etc/tmpfiles.d should look like before configuring persistent logging:

#This goes hand-in-hand with the base-files of OE-Core. The file must
# be sorted before 'systemd.conf' becuase this attempts to create a file
# inside /var/log.


d               /run/lock               1777    -       -       -
d               /var/volatile/log               -       -       -       -
d               /var/volatile/tmp               1777    -       -
L               /var/tmp                -       -       -       -       /var/volatile/tmp
L               /var/log                -       -       -       -       /var/volatile/log
L+ /var/log - - - - /var/volatile/log

Should probably reboot after modifying the file so it takes effect before you configure persistent logging.

After this I just applied the steps from the article and I can see multiple boots worth of logs:

$ journalctl --list-boots
IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -1 d65e508ee80e4e1b9b091f1a96749888 Wed 2025-01-08 18:22:58 UTC Wed 2025-01-08 19:23:31 UTC
  0 390784e24fb54ba5a038be611f39942e Wed 2025-01-08 18:22:58 UTC Wed 2025-01-08 19:29:59 UTC

Which is what I expect once persistent logging is enabled.

Best Regards,
Jeremias

Hi @jeremias.tx ,
I did exactly what you did, and see exactly what you see with journalctl --list-boots.

The problem is that my application logs, and most other logs, are now NOT shown, as they should be. So, logging is persistent, but it is now logging very little of the activity.

Here is my /etc/tmpfiles.d/00-create-volatile.conf after modification per the article.

torizon@amplifidx-dx100-alpha-unit4:~$ cat /etc/tmpfiles.d/00-create-volatile.conf 
#This goes hand-in-hand with the base-files of OE-Core. The file must
# be sorted before 'systemd.conf' becuase this attempts to create a file
# inside /var/log.


d		/run/lock		1777	-	-	-
d		/var/volatile/tmp		1777	-	-
L		/var/tmp		-	-	-	-	/var/volatile/tmp

torizon@amplifidx-dx100-alpha-unit4:~$

With persistent logging enabled, I do see multiple boots as expected:

torizon@amplifidx-dx100-alpha-unit4:~$ journalctl --list-boots 
IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY                 
 -2 6bd67067606240b695f66f72dc1e4259 Wed 2025-01-08 10:23:33 PST Wed 2025-01-08 10:23:34 PST
 -1 9da18937d3914213b5e40ad1f2d2d664 Wed 2025-01-08 10:23:12 PST Wed 2025-01-08 10:24:00 PST
  0 6b099c5d9bf2481da17d537184668796 Wed 2025-01-08 10:24:13 PST Wed 2025-01-08 10:24:35 PST

But, when I just type journalctl rather than journalctl --list-boots, I see this, which is far less data than expected:

torizon@amplifidx-dx100-alpha-unit4:~$ journalctl
Jan 08 10:23:33 amplifidx-dx100-alpha-unit4 systemd[1138]: Queued start job for default target Main User Target.
Jan 08 10:23:33 amplifidx-dx100-alpha-unit4 systemd[1138]: Created slice User Application Slice.
Jan 08 10:23:33 amplifidx-dx100-alpha-unit4 systemd[1138]: Reached target Paths.
Jan 08 10:23:33 amplifidx-dx100-alpha-unit4 systemd[1138]: Reached target Timers.
Jan 08 10:23:33 amplifidx-dx100-alpha-unit4 systemd[1138]: Starting D-Bus User Message Bus Socket...
Jan 08 10:23:33 amplifidx-dx100-alpha-unit4 systemd[1138]: Listening on D-Bus User Message Bus Socket.
Jan 08 10:23:33 amplifidx-dx100-alpha-unit4 systemd[1138]: Reached target Sockets.
Jan 08 10:23:33 amplifidx-dx100-alpha-unit4 systemd[1138]: Reached target Basic System.
Jan 08 10:23:33 amplifidx-dx100-alpha-unit4 systemd[1138]: Reached target Main User Target.
Jan 08 10:23:33 amplifidx-dx100-alpha-unit4 systemd[1138]: Startup finished in 1.535s.
-- Boot 9da18937d3914213b5e40ad1f2d2d664 --
Jan 08 10:23:12 amplifidx-dx100-alpha-unit4 systemd[694]: Queued start job for default target Main User Target.
Jan 08 10:23:12 amplifidx-dx100-alpha-unit4 systemd[694]: Created slice User Application Slice.
Jan 08 10:23:12 amplifidx-dx100-alpha-unit4 systemd[694]: Reached target Paths.
Jan 08 10:23:12 amplifidx-dx100-alpha-unit4 systemd[694]: Reached target Timers.
Jan 08 10:23:12 amplifidx-dx100-alpha-unit4 systemd[694]: Starting D-Bus User Message Bus Socket...
Jan 08 10:23:12 amplifidx-dx100-alpha-unit4 systemd[694]: Listening on D-Bus User Message Bus Socket.
Jan 08 10:23:12 amplifidx-dx100-alpha-unit4 systemd[694]: Reached target Sockets.
Jan 08 10:23:12 amplifidx-dx100-alpha-unit4 systemd[694]: Reached target Basic System.
Jan 08 10:23:12 amplifidx-dx100-alpha-unit4 systemd[694]: Reached target Main User Target.
Jan 08 10:23:12 amplifidx-dx100-alpha-unit4 systemd[694]: Startup finished in 1.573s.
Jan 08 10:24:00 amplifidx-dx100-alpha-unit4 sudo[1159]:  torizon : TTY=pts/0 ; PWD=/var/rootdirs/home/torizon ; USER=root ; COMMAND=/usr/sbin/reboot
Jan 08 10:24:00 amplifidx-dx100-alpha-unit4 systemd[694]: Activating special unit Exit the Session...
Jan 08 10:24:00 amplifidx-dx100-alpha-unit4 systemd[694]: Stopped target Main User Target.
Jan 08 10:24:00 amplifidx-dx100-alpha-unit4 systemd[694]: Stopped target Basic System.
Jan 08 10:24:00 amplifidx-dx100-alpha-unit4 systemd[694]: Stopped target Paths.
Jan 08 10:24:00 amplifidx-dx100-alpha-unit4 systemd[694]: Stopped target Sockets.
Jan 08 10:24:00 amplifidx-dx100-alpha-unit4 systemd[694]: Stopped target Timers.
Jan 08 10:24:00 amplifidx-dx100-alpha-unit4 systemd[694]: Closed D-Bus User Message Bus Socket.
Jan 08 10:24:00 amplifidx-dx100-alpha-unit4 systemd[694]: Removed slice User Application Slice.
Jan 08 10:24:00 amplifidx-dx100-alpha-unit4 systemd[694]: Reached target Shutdown.
Jan 08 10:24:00 amplifidx-dx100-alpha-unit4 systemd[694]: Finished Exit the Session.
Jan 08 10:24:00 amplifidx-dx100-alpha-unit4 systemd[694]: Reached target Exit the Session.
Jan 08 10:24:00 amplifidx-dx100-alpha-unit4 (sd-pam)[696]: pam_warn(systemd-user:setcred): function=[pam_sm_setcred] flags=0x8004 service=[systemd-user] terminal=[<unknown>] user=[tori>
-- Boot 6b099c5d9bf2481da17d537184668796 --
Jan 08 10:24:13 amplifidx-dx100-alpha-unit4 systemd[1138]: Queued start job for default target Main User Target.
Jan 08 10:24:13 amplifidx-dx100-alpha-unit4 systemd[1138]: Created slice User Application Slice.
Jan 08 10:24:13 amplifidx-dx100-alpha-unit4 systemd[1138]: Reached target Paths.
Jan 08 10:24:13 amplifidx-dx100-alpha-unit4 systemd[1138]: Reached target Timers.
Jan 08 10:24:13 amplifidx-dx100-alpha-unit4 systemd[1138]: Starting D-Bus User Message Bus Socket...
Jan 08 10:24:13 amplifidx-dx100-alpha-unit4 systemd[1138]: Listening on D-Bus User Message Bus Socket.
Jan 08 10:24:13 amplifidx-dx100-alpha-unit4 systemd[1138]: Reached target Sockets.
Jan 08 10:24:13 amplifidx-dx100-alpha-unit4 systemd[1138]: Reached target Basic System.
Jan 08 10:24:13 amplifidx-dx100-alpha-unit4 systemd[1138]: Reached target Main User Target.
Jan 08 10:24:13 amplifidx-dx100-alpha-unit4 systemd[1138]: Startup finished in 1.550s.
Jan 08 10:24:34 amplifidx-dx100-alpha-unit4 sudo[1165]:  torizon : TTY=pts/0 ; PWD=/var/rootdirs/home/torizon ; USER=root ; COMMAND=/usr/sbin/reboot
Jan 08 10:24:35 amplifidx-dx100-alpha-unit4 systemd[1138]: Activating special unit Exit the Session...
Jan 08 10:24:35 amplifidx-dx100-alpha-unit4 systemd[1138]: Stopped target Main User Target.
Jan 08 10:24:35 amplifidx-dx100-alpha-unit4 systemd[1138]: Stopped target Basic System.
Jan 08 10:24:35 amplifidx-dx100-alpha-unit4 systemd[1138]: Stopped target Paths.
Jan 08 10:24:35 amplifidx-dx100-alpha-unit4 systemd[1138]: Stopped target Sockets.
Jan 08 10:24:35 amplifidx-dx100-alpha-unit4 systemd[1138]: Stopped target Timers.
Jan 08 10:24:35 amplifidx-dx100-alpha-unit4 systemd[1138]: Closed D-Bus User Message Bus Socket.
Jan 08 10:24:35 amplifidx-dx100-alpha-unit4 systemd[1138]: Removed slice User Application Slice.
Jan 08 10:24:35 amplifidx-dx100-alpha-unit4 systemd[1138]: Reached target Shutdown.
Jan 08 10:24:35 amplifidx-dx100-alpha-unit4 systemd[1138]: Finished Exit the Session.
Jan 08 10:24:35 amplifidx-dx100-alpha-unit4 systemd[1138]: Reached target Exit the Session.
Jan 08 10:24:35 amplifidx-dx100-alpha-unit4 (sd-pam)[1140]: pam_warn(systemd-user:setcred): function=[pam_sm_setcred] flags=0x8004 service=[systemd-user] terminal=[<unknown>] user=[tor

Do you see the same behavior?

Cheers,
Jeff

Do you see the same behavior?

No I see the full logs for each boot with persistent logging enabled:

Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd034]
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Linux version 6.6.84-7.2.0-g87bfb710b6f1 (oe-user@oe-host) (aarch64-tdx-linux-gcc (GCC) 13.3.0, GNU ld (GNU Binutils) 2.42.0.20240723) #1-Torizon SMP PREEMPT Mon Mar 31 08:47:48 UTC 2025
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: KASLR disabled due to lack of seed
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Machine model: Toradex Verdin iMX8M Plus WB on Verdin Development Board
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: efi: UEFI not found.
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Reserved memory: created CMA memory pool at 0x00000000a0000000, size 512 MiB
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: OF: reserved mem: 0x00000000a0000000..0x00000000bfffffff (524288 KiB) map reusable linux,cma
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: OF: reserved mem: 0x0000000000900000..0x000000000096ffff (448 KiB) nomap non-reusable ocram@900000
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Zone ranges:
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel:   DMA      [mem 0x0000000040000000-0x00000000ffffffff]
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel:   DMA32    empty
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel:   Normal   [mem 0x0000000100000000-0x000000013fffffff]
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Movable zone start for each node
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Early memory node ranges
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel:   node   0: [mem 0x0000000040000000-0x000000013fffffff]
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Initmem setup node 0 [mem 0x0000000040000000-0x000000013fffffff]
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: psci: probing for conduit method from DT.
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: psci: PSCIv1.1 detected in firmware.
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: psci: Using standard PSCI v0.2 function IDs
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: psci: MIGRATE_INFO_TYPE not supported.
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: psci: SMC Calling Convention v1.4
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: percpu: Embedded 29 pages/cpu s80040 r8192 d30552 u118784
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: pcpu-alloc: s80040 r8192 d30552 u118784 alloc=29*4096
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Detected VIPT I-cache on CPU0
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: CPU features: detected: GIC system register CPU interface
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: alternatives: applying boot alternatives
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/157a467dd3b97eaebfbf6e17d0c8859fdd0abc1d397c637c6ecd808f79dc0260/0
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Unknown kernel command line parameters "splash ostree=/ostree/boot.1/torizon/157a467dd3b97eaebfbf6e17d0c8859fdd0abc1d397c637c6ecd808f79dc0260/0", will be passed to user space.
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: Built 1 zonelists, mobility grouping on.  Total pages: 1032192
Jan 08 18:22:58 verdin-imx8mp-06849059 kernel: mem auto-init: stack:all(zero), heap alloc:off, heap free:off
....<2000+ lines of logs>

I don’t know why yours would be cut off. Did you modify anything else? I’m just on a standard 7.2.0 release image. The only modification was the persistent logging related changes. Or at least I assume you have other modifications I can see from your logs you at least modified stuff like the device hostname.

Try to enable persistent logging on a standard 7.2.0 image with no other modifications. Then compare and see if the behavior is the same. If it’s not then there must be some other modification that is affecting the logging.

Best Regards,
Jeremias