Bug in shrink-backup - Journal is missing after first boot

[Awak00m]

Describe the bug
/var/log/journal link is missing after the first boot, though it is yet in place on burned SD.
/var/log.hdd/journal should be a directory, but it is a link, pointing to itself, but as a directory.
Looks like /var/log/journal is moved to /var/log.hdd/ while the first boot.

To Reproduce
Steps to reproduce the behavior:
Just apply the script to existing and correct file system, then burn the image to SD.

Expected behavior
A clear and concise description of what you expected to happen.
/var/log/~journal -> /var/log.hdd/journal sub-directory

Instead we get:

/var/log/~journal is absent.
/var/log.hdd/~journal -> /var/log.hdd/journal as a sub-directory.

Hardware (please complete the following information):

• Hardware: Banana Pi M2 zero
• OS: armbian-community from here

Additional context
I tied both -e and -az options. No difference.
Screenshots and logs are attached.




shrink-backup1.log
shrink-backup2.log

[UnconnectedBedna]

As I said on the Armbian forum, you need to provide proof that the files are missing on the img before you boot.

I did exactly this on a armbian system.

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0         7:0    0     5G  0 loop 
└─loop0p1   259:0    0     5G  0 part /mnt/temp
mtdblock0    31:0    0     1M  0 disk 
mtdblock1    31:1    0     1M  0 disk 
mmcblk0     179:0    0  14.8G  0 disk 
└─mmcblk0p1 179:1    0  14.6G  0 part /
zram0       252:0    0 492.3M  0 disk [SWAP]
zram1       252:1    0    50M  0 disk /var/log

$ df -h
Filesystem                                         Size  Used Avail Use% Mounted on
udev                                               419M     0  419M   0% /dev
tmpfs                                               99M   13M   87M  13% /run
/dev/mmcblk0p1                                      15G  4.0G  9.8G  29% /
tmpfs                                              493M  736K  492M   1% /dev/shm
tmpfs                                              5.0M  4.0K  5.0M   1% /run/lock
tmpfs                                              493M     0  493M   0% /tmp
/dev/zram1                                          49M   24M   22M  53% /var/log
tmpfs                                               99M     0   99M   0% /run/user/1000

# Is anything mounted from there?
$ findmnt --raw | grep /var/log
/var/log.hdd /dev/mmcblk0p1[/var/log] ext4 rw,noatime,errors=remount-ro,commit=600
/var/log /dev/zram1 ext4 rw,relatime,discard

$ ls -l /var/log
total 792
drwxr-xr-x 2 root     root       4096 Jan 14 00:00 apt
-rw-r--r-- 1 root     root          0 Jan 14 00:01 armbian-hardware-monitor.log
-rw-r----- 1 root     adm      136195 Jan 14 01:00 auth.log
-rw------- 1 root     root          0 Jan 14 00:01 boot.log
-rw-rw---- 1 root     utmp          0 Jan 14 00:01 btmp
drwxr-x--- 2 _chrony  _chrony    4096 May 19  2024 chrony
-rw-r----- 1 root     adm      106053 Jan 14 01:00 daemon.log
-rw-r----- 1 root     adm           0 Jan 14 00:01 debug
-rw------- 1 root     root          0 Jan 14 00:01 fail2ban.log
-rw-r----- 1 root     adm         660 Jan 14 00:47 kern.log
-rw-rw-r-- 1 root     utmp     296296 Jan 14 00:54 lastlog
drwxr-x--- 2 www-data www-data   4096 May 19  2024 lighttpd
drwx------ 2 root     root      16384 Jun 21  2024 lost+found
-rw-r----- 1 root     adm        1580 Jan 14 00:47 messages
drwxr-xr-x 2 pihole   pihole     4096 Jan 13 00:00 pihole
lrwxrwxrwx 1 pihole   pihole       23 May 19  2024 pihole-FTL.log -> /var/log/pihole/FTL.log
lrwxrwxrwx 1 pihole   pihole       26 May 19  2024 pihole.log -> /var/log/pihole/pihole.log
drwx------ 2 root     root       4096 May 19  2024 private
drwxr-xr-x 3 root     root       4096 May 19  2024 samba
-rw-r----- 1 root     adm      179295 Jan 14 01:00 syslog
drwxr-xr-x 2 root     root       4096 Aug  1 00:07 sysstat
drwxr-xr-x 2 root     root       4096 May 19  2024 unattended-upgrades
-rw-r----- 1 root     adm           0 Jan 14 00:01 user.log
-rw-rw-r-- 1 root     utmp      28000 Jan 14 00:54 wtmp

$ ls -l /var/log.hdd
total 2784
drwxr-xr-x 2 root     root       4096 Jan 14 00:00 apt
-rw-r--r-- 1 root     root          0 Jan 13 00:00 armbian-hardware-monitor.log
-rw-r--r-- 1 root     root      25217 Jun 22  2024 armbian-hardware-monitor.log.1.gz
-rw-r--r-- 1 root     root      13541 May 19  2024 armbian-hardware-monitor.log.2.gz
-rw-r--r-- 1 root     root     293476 Jan 14 00:01 armbian-ramlog.log
-rw-r----- 1 root     adm      131656 Jan 14 00:00 auth.log
-rw-r----- 1 root     adm      452453 Jan 12 00:00 auth.log.1
-rw-r----- 1 root     adm       22732 Jan  5 00:00 auth.log.2.gz
-rw-r----- 1 root     adm       21450 Dec 29 00:00 auth.log.3.gz
-rw-r----- 1 root     adm       21436 Dec 22 00:00 auth.log.4.gz
-rw------- 1 root     root          0 Jan 13 00:00 boot.log
-rw------- 1 root     root       2737 Jun 21  2024 boot.log.1.gz
-rw------- 1 root     root       1536 Jun 19  2024 boot.log.2.gz
-rw------- 1 root     root       1523 May 19  2024 boot.log.3.gz
-rw-rw---- 1 root     utmp          0 Jan 13 00:00 btmp
-rw-rw---- 1 root     utmp         20 Dec 31 00:00 btmp.1.gz
drwxr-x--- 2 _chrony  _chrony    4096 May 19  2024 chrony
-rw-r----- 1 root     adm      102157 Jan 14 00:00 daemon.log
-rw-r----- 1 root     adm      344989 Jan 12 00:00 daemon.log.1
-rw-r----- 1 root     adm       19344 Jan  5 00:00 daemon.log.2.gz
-rw-r----- 1 root     adm       17439 Dec 29 00:00 daemon.log.3.gz
-rw-r----- 1 root     adm       17440 Dec 22 00:00 daemon.log.4.gz
-rw-r----- 1 root     adm           0 Jan 13 00:00 debug
-rw-r----- 1 root     adm        1024 Jun 22  2024 debug.1
-rw-r----- 1 root     adm         202 May 19  2024 debug.2.gz
-rw------- 1 root     root          0 Jan 13 00:00 fail2ban.log
-rw------- 1 root     root        431 Oct 27 02:00 fail2ban.log.1
-rw------- 1 root     root        801 Jun 22  2024 fail2ban.log.2.gz
-rw------- 1 root     root        431 May 19  2024 fail2ban.log.3.gz
-rw-r----- 1 root     adm           0 Jan 14 00:01 kern.log
-rw-r----- 1 root     adm        1295 Jan 13 23:58 kern.log.1
-rw-r----- 1 root     adm        1041 Nov 16 03:31 kern.log.2.gz
-rw-r----- 1 root     adm         338 Nov  9 15:57 kern.log.3.gz
-rw-r----- 1 root     adm         266 Nov  2 12:37 kern.log.4.gz
-rw-rw-r-- 1 root     utmp     296296 Jan 13 23:50 lastlog
drwxr-x--- 2 www-data www-data   4096 May 19  2024 lighttpd
-rw-r----- 1 root     adm         773 Jan 13 23:58 messages
-rw-r----- 1 root     adm         147 Jan 11 00:00 messages.1
-rw-r----- 1 root     adm         143 Jan  4 00:00 messages.2.gz
-rw-r----- 1 root     adm         143 Dec 28 00:00 messages.3.gz
-rw-r----- 1 root     adm         143 Dec 21 00:00 messages.4.gz
drwxr-xr-x 2 pihole   pihole     4096 Jan 13 00:00 pihole
lrwxrwxrwx 1 pihole   pihole       23 May 19  2024 pihole-FTL.log -> /var/log/pihole/FTL.log
lrwxrwxrwx 1 pihole   pihole       26 May 19  2024 pihole.log -> /var/log/pihole/pihole.log
drwx------ 2 root     root       4096 May 19  2024 private
drwxr-xr-x 3 root     root       4096 May 19  2024 samba
-rw-r----- 1 root     adm      173202 Jan 14 00:00 syslog
-rw-r----- 1 root     adm      587292 Jan 12 00:00 syslog.1
-rw-r----- 1 root     adm       40287 Jan  5 00:00 syslog.2.gz
-rw-r----- 1 root     adm       38118 Dec 29 00:00 syslog.3.gz
-rw-r----- 1 root     adm       38115 Dec 22 00:00 syslog.4.gz
drwxr-xr-x 2 root     root       4096 Aug  1 00:07 sysstat
drwxr-xr-x 2 root     root       4096 May 19  2024 unattended-upgrades
-rw-r----- 1 root     adm           0 Jan 13 00:00 user.log
-rw-r----- 1 root     adm         236 Jun 22  2024 user.log.1
-rw-r----- 1 root     adm         125 May 19  2024 user.log.2.gz
-rw-rw-r-- 1 root     utmp      27600 Jan 13 23:50 wtmp

I made a backup from this system to /mnt/backup/test/test.img, I used autoexpansion, but it does not matter for now.
I then looped it using shrink-backup and mounted the loop to /mnt/temp:

$ sudo shrink-backup --loop /mnt/backup/test/test.img /mnt/temp
## Zoom speed NOT requested...
## Looping img file...
## /mnt/backup/test/test.img is looped to /dev/loop0
##############################################################################
# NAME      MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
# loop0       7:0    0   5G  0 loop 
# └─loop0p1 259:0    0   5G  0 part 
##############################################################################
## Done.

$ sudo mount /dev/loop0p1 /mnt/temp

I then confirmed that the files were still there:

$ ls -l /mnt/temp/var/log
total 772
drwxr-xr-x 2 root     root       4096 Jan 14 00:00 apt
-rw-r--r-- 1 root     root          0 Jan 14 00:01 armbian-hardware-monitor.log
-rw-r----- 1 root     adm      133856 Jan 14 00:45 auth.log
-rw------- 1 root     root          0 Jan 14 00:01 boot.log
-rw-rw---- 1 root     utmp          0 Jan 14 00:01 btmp
drwxr-x--- 2 _chrony  _chrony    4096 May 19  2024 chrony
-rw-r----- 1 root     adm      104470 Jan 14 00:40 daemon.log
-rw-r----- 1 root     adm           0 Jan 14 00:01 debug
-rw------- 1 root     root          0 Jan 14 00:01 fail2ban.log
-rw-r----- 1 root     adm           0 Jan 14 00:01 kern.log
-rw-rw-r-- 1 root     utmp     296296 Jan 14 00:01 lastlog
drwxr-x--- 2 www-data www-data   4096 May 19  2024 lighttpd
drwx------ 2 root     root       4096 Jun 21  2024 lost+found
-rw-r----- 1 root     adm         920 Jan 14 00:11 messages
drwxr-xr-x 2 pihole   pihole     4096 Jan 13 00:00 pihole
lrwxrwxrwx 1 pihole   pihole       23 May 19  2024 pihole-FTL.log -> /var/log/pihole/FTL.log
lrwxrwxrwx 1 pihole   pihole       26 May 19  2024 pihole.log -> /var/log/pihole/pihole.log
drwx------ 2 root     root       4096 May 19  2024 private
drwxr-xr-x 3 root     root       4096 May 19  2024 samba
-rw-r----- 1 root     adm      176859 Jan 14 00:45 syslog
drwxr-xr-x 2 root     root       4096 Aug  1 00:07 sysstat
drwxr-xr-x 2 root     root       4096 May 19  2024 unattended-upgrades
-rw-r----- 1 root     adm           0 Jan 14 00:01 user.log
-rw-rw-r-- 1 root     utmp      27600 Jan 14 00:01 wtmp

$ ls -l /mnt/temp/var/log.hdd
total 2780
drwxr-xr-x 2 root     root       4096 Jan 14 00:00 apt
-rw-r--r-- 1 root     root          0 Jan 13 00:00 armbian-hardware-monitor.log
-rw-r--r-- 1 root     root      25217 Jun 22  2024 armbian-hardware-monitor.log.1.gz
-rw-r--r-- 1 root     root      13541 May 19  2024 armbian-hardware-monitor.log.2.gz
-rw-r--r-- 1 root     root     293476 Jan 14 00:01 armbian-ramlog.log
-rw-r----- 1 root     adm      131656 Jan 14 00:00 auth.log
-rw-r----- 1 root     adm      452453 Jan 12 00:00 auth.log.1
-rw-r----- 1 root     adm       22732 Jan  5 00:00 auth.log.2.gz
-rw-r----- 1 root     adm       21450 Dec 29 00:00 auth.log.3.gz
-rw-r----- 1 root     adm       21436 Dec 22 00:00 auth.log.4.gz
-rw------- 1 root     root          0 Jan 13 00:00 boot.log
-rw------- 1 root     root       2737 Jun 21  2024 boot.log.1.gz
-rw------- 1 root     root       1536 Jun 19  2024 boot.log.2.gz
-rw------- 1 root     root       1523 May 19  2024 boot.log.3.gz
-rw-rw---- 1 root     utmp          0 Jan 13 00:00 btmp
-rw-rw---- 1 root     utmp         20 Dec 31 00:00 btmp.1.gz
drwxr-x--- 2 _chrony  _chrony    4096 May 19  2024 chrony
-rw-r----- 1 root     adm      102157 Jan 14 00:00 daemon.log
-rw-r----- 1 root     adm      344989 Jan 12 00:00 daemon.log.1
-rw-r----- 1 root     adm       19344 Jan  5 00:00 daemon.log.2.gz
-rw-r----- 1 root     adm       17439 Dec 29 00:00 daemon.log.3.gz
-rw-r----- 1 root     adm       17440 Dec 22 00:00 daemon.log.4.gz
-rw-r----- 1 root     adm           0 Jan 13 00:00 debug
-rw-r----- 1 root     adm        1024 Jun 22  2024 debug.1
-rw-r----- 1 root     adm         202 May 19  2024 debug.2.gz
-rw------- 1 root     root          0 Jan 13 00:00 fail2ban.log
-rw------- 1 root     root        431 Oct 27 02:00 fail2ban.log.1
-rw------- 1 root     root        801 Jun 22  2024 fail2ban.log.2.gz
-rw------- 1 root     root        431 May 19  2024 fail2ban.log.3.gz
-rw-r----- 1 root     adm           0 Jan 14 00:01 kern.log
-rw-r----- 1 root     adm        1295 Jan 13 23:58 kern.log.1
-rw-r----- 1 root     adm        1041 Nov 16 03:31 kern.log.2.gz
-rw-r----- 1 root     adm         338 Nov  9 15:57 kern.log.3.gz
-rw-r----- 1 root     adm         266 Nov  2 12:37 kern.log.4.gz
-rw-rw-r-- 1 root     utmp     296296 Jan 13 23:50 lastlog
drwxr-x--- 2 www-data www-data   4096 May 19  2024 lighttpd
-rw-r----- 1 root     adm         773 Jan 13 23:58 messages
-rw-r----- 1 root     adm         147 Jan 11 00:00 messages.1
-rw-r----- 1 root     adm         143 Jan  4 00:00 messages.2.gz
-rw-r----- 1 root     adm         143 Dec 28 00:00 messages.3.gz
-rw-r----- 1 root     adm         143 Dec 21 00:00 messages.4.gz
drwxr-xr-x 2 pihole   pihole     4096 Jan 13 00:00 pihole
lrwxrwxrwx 1 pihole   pihole       23 May 19  2024 pihole-FTL.log -> /var/log/pihole/FTL.log
lrwxrwxrwx 1 pihole   pihole       26 May 19  2024 pihole.log -> /var/log/pihole/pihole.log
drwx------ 2 root     root       4096 May 19  2024 private
drwxr-xr-x 3 root     root       4096 May 19  2024 samba
-rw-r----- 1 root     adm      173202 Jan 14 00:00 syslog
-rw-r----- 1 root     adm      587292 Jan 12 00:00 syslog.1
-rw-r----- 1 root     adm       40287 Jan  5 00:00 syslog.2.gz
-rw-r----- 1 root     adm       38118 Dec 29 00:00 syslog.3.gz
-rw-r----- 1 root     adm       38115 Dec 22 00:00 syslog.4.gz
drwxr-xr-x 2 root     root       4096 Aug  1 00:07 sysstat
drwxr-xr-x 2 root     root       4096 May 19  2024 unattended-upgrades
-rw-r----- 1 root     adm           0 Jan 13 00:00 user.log
-rw-r----- 1 root     adm         236 Jun 22  2024 user.log.1
-rw-r----- 1 root     adm         125 May 19  2024 user.log.2.gz
-rw-rw-r-- 1 root     utmp      27600 Jan 13 23:50 wtmp

The files are included and exists on the img.

So please provide this to show if shrink-backup includes the files or not.
If the files are included, what is happening on your system is very likely to be outside the scope of this script.
Even the autoexpansion itself is the built in armbian function running at boot.

Edit
FYI, /var/log/journal does not exist on a normal system while running, check /run/log/journal/yadyadayada if its the live journalctl log you are looking for, and THAT directory (/run/*) is excluded in the script by default.
If you really want to include the stuff in there, you have to edit and use exclude.txt with -t option, but I urge you to look into what /run is before you do that.

[Awak00m]

So please provide this to show if shrink-backup includes the files or not.

My screenshots named "xxxx-before" are just what you want.
Or should I provide just text versions?

/var/log.hdd/ on SD before the first boot :

/var/log/ on SD before the first boot :

[Awak00m]

Here is my "original" lsblk output:
sda 8:0 1 119,4G 0 disk
└─sda1 8:1 1 119,4G 0 part /media
mmcblk0 179:0 0 29,8G 0 disk
└─mmcblk0p1 179:1 0 29,4G 0 part /var/log.hdd
/
zram0 253:0 0 242,7M 0 disk [SWAP]
zram1 253:1 0 50M 0 disk /var/log
zram2 253:2 0 0B 0 disk

This is what is processed by the script. Looks like a correct Armbian SD.
The above is yet before the loop creation, of course.

Here is a text version of loop0p1 /var/log :

-rw-r--r-- 1 root root 5241 янв 13 00:00 alternatives.log
drwxr-xr-x 2 root root 4096 янв 13 14:31 apt
-rw-r--r-- 1 root root 434284 янв 13 17:10 armbian-hardware-monitor.log
-rw-r----- 1 root adm 47201 янв 13 20:45 auth.log
-rw-r--r-- 1 root root 69555 янв 13 00:00 bootstrap.log
-rw-rw---- 1 root utmp 2688 янв 13 00:00 btmp
-rw-r----- 1 root adm 19432 янв 13 20:45 cron.log
-rw-r--r-- 1 root root 198226 янв 13 14:31 dpkg.log
-rw-r--r-- 1 root root 0 янв 13 00:00 faillog
lrwxrwxrwx 1 root systemd-journal 20 янв 13 17:10 journal -> /var/log.hdd/journal
-rw-r----- 1 root adm 439612 янв 13 20:49 kern.log
-rw-rw-r-- 1 root utmp 292 янв 13 20:15 lastlog
drwx------ 2 root root 4096 янв 13 17:10 lost+found
drwx------ 2 root root 4096 янв 7 07:33 private
lrwxrwxrwx 1 root root 39 янв 7 07:33 README -> ../../usr/share/doc/systemd/README.logs
drwxr-xr-x 3 root root 4096 янв 7 07:33 runit
drwxr-x--- 3 root adm 4096 янв 12 00:00 samba
-rw-r----- 1 root adm 794881 янв 13 20:49 syslog
drwxr-xr-x 2 root root 4096 янв 13 20:19 v2ray
-rw-rw-r-- 1 root utmp 51840 янв 13 20:15 wtmp

Here is a text version of loop0p1 /var/log.hdd :

-rw-r--r-- 1 root root 5241 янв 13 00:00 alternatives.log
drwxr-xr-x 2 root root 4096 янв 13 14:31 apt
-rw-r--r-- 1 root root 386595 янв 13 17:10 armbian-hardware-monitor.log
-rw-r--r-- 1 root root 16158 янв 11 21:50 armbian-hardware-monitor.log.1.gz
-rw-r--r-- 1 root root 15343 янв 13 17:10 armbian-ramlog.log
-rw-r----- 1 root adm 44729 янв 13 17:10 auth.log
-rw-r----- 1 root adm 13301 янв 12 00:00 auth.log.1
-rw-r--r-- 1 root root 69555 янв 13 00:00 bootstrap.log
-rw-rw---- 1 root utmp 2688 янв 13 00:00 btmp
-rw-r----- 1 root adm 18163 янв 13 17:00 cron.log
-rw-r----- 1 root adm 22061 янв 12 00:00 cron.log.1
-rw-r--r-- 1 root root 198226 янв 13 14:31 dpkg.log
-rw-r--r-- 1 root root 0 янв 13 00:00 faillog
drwxr-sr-x 3 root systemd-journal 4096 янв 8 21:28 journal
-rw-r----- 1 root adm 391649 янв 13 16:34 kern.log
-rw-r----- 1 root adm 62595 янв 11 22:57 kern.log.1
-rw-rw-r-- 1 root utmp 292 янв 13 16:19 lastlog
drwx------ 2 root root 4096 янв 7 07:33 private
lrwxrwxrwx 1 root root 39 янв 7 07:33 README -> ../../usr/share/doc/systemd/README.logs
drwxr-xr-x 3 root root 4096 янв 7 07:33 runit
drwxr-x--- 3 root adm 4096 янв 12 00:00 samba
-rw-r----- 1 root adm 720306 янв 13 17:10 syslog
-rw-r----- 1 root adm 133330 янв 12 00:00 syslog.1
drwxr-xr-x 2 root root 4096 янв 13 14:18 v2ray
-rw-rw-r-- 1 root utmp 48384 янв 13 17:10 wtmp

AFAICS, we have a little difference here:
lrwxrwxrwx 1 root systemd-journal 20 янв 13 17:10 journal -> /var/log.hdd/journal
and
lrwxrwxrwx 1 root root 39 янв 7 07:33 README -> ../../usr/share/doc/systemd/README.logs

So, we could conclude that relative links have been survived, while absolute - not. Is this a way to go?

[Awak00m]

I have no idea, where this RAM disk is created, and how its contents is filled up.
Otherwise I could modify absolute ~lournal/ link to relative and test it.

[UnconnectedBedna]

As I said, ram or not, does not matter.

One last time.

Provide information EXACTLY like I did in my first response.
Provide proof that the directories or content of /var/log and /var/log.hdd are missing from the image after creation.
I want a side by side comparison like in my first post, done from the system BOOTED, not from some other system you put the sd-card in. I want it ALL to be done on the same system, exactly like I did in my first response.
Either do that or close the issue.

I am NOT going to guess and try to understand some strange images.
Use text, copy/paste and format as code.
https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#quoting-code

Provide the requested information if you claim something to be a bug or nothing will be done from my side.

I already explained that there is no journal in there on a normal system WHILE RUNNING, they are in /run on a live system. If you want to copy those files from that EXACT location (/var/log/journal), do it while the system is NOT BOOTED, ie, you do not need this script for that. This script is for backing up a RUNNING system.
If your claim is that /var/log/journal DOES EXIST on the RUNNING SYSTEM but for some reason not on the created img, provide proof.

So, provide ls output from the directories you back up FROM, and an ls from the looped and mounted img file.
I want to see EXACTLY what files that you claim are missing. I want to compare them name by name, size by size etc.
Images will be completely disregarded.

I want to see every command you do, ls -l, how you loop the img and mount it etc. (it looks like you provided the output of the img file correctly, I also need the ls from the RUNNING system to compare file for file IN THE SAME POST, ALL DONE FROM THE SAME SYSTEM, the system you back up from.
Don't take this the wrong way, but it is pretty clear you are not very familiar with how a linux system works, so I require this before I take action.
There have been too many times where hours have been spent to finally discover it is just user error.
(No need to provide lsblk, df or findmnt, that was just me showing you that I have the same log2ram function you do)

Edit
Btw, sudo systemctl status armbian-ramlog.service is what is doing your log2ram.
But as I explained and shown, none of that should matter.

[Awak00m]

Sorry but we don't understand each other...

Provide proof that the directories or content of /var/log and /var/log.hdd are missing from the image after creation.

I can't do it, because everything is OK in both the image file and burned SD before the first boot.
Therefore your actions from your first post prove nothing, as I completely agree and can confirm just the same.

Nevertheless, similar outputs for my ORIGINAL LIVE SYSTEM are below:

lsblk:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0   1,8G  0 loop
└─loop0p1   259:0    0   1,8G  0 part /mnt/sda1
sda           8:0    1 119,4G  0 disk
└─sda1        8:1    1 119,4G  0 part /media
mmcblk0     179:0    0  29,8G  0 disk
└─mmcblk0p1 179:1    0  29,4G  0 part /var/log.hdd
                                      /
zram0       253:0    0 242,7M  0 disk [SWAP]
zram1       253:1    0    50M  0 disk /var/log
zram2       253:2    0     0B  0 disk

df-h:

udev               185M            0  185M            0% /dev
tmpfs               49M         2,2M   47M            5% /run
/dev/mmcblk0p1      29G         1,2G   28G            5% /
tmpfs              243M            0  243M            0% /dev/shm
tmpfs              5,0M            0  5,0M            0% /run/lock
tmpfs              243M            0  243M            0% /tmp
/dev/zram1          47M         4,4M   39M           11% /var/log
tmpfs               49M            0   49M            0% /run/user/0
/dev/sda1          117G          55G   57G           50% /media
/dev/loop0p1       1,8G         1,2G  452M           73% /mnt/sda1

findmnt --raw | grep /var/log:

/var/log.hdd /dev/mmcblk0p1[/var/log] ext4 rw,noatime,errors=remount-ro,commit=120
/var/log /dev/zram1 ext4 rw,nosuid,nodev,noexec,relatime,discard

Similar outputs for the DUPLICATED LIVE SYSTEM are below:
lsblk:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    1 119,4G  0 disk
└─sda1        8:1    1 119,4G  0 part /media
mmcblk0     179:0    0  29,8G  0 disk
└─mmcblk0p1 179:1    0   1,8G  0 part /var/log.hdd
                                      /
zram0       253:0    0 242,7M  0 disk [SWAP]
zram1       253:1    0    50M  0 disk /var/log
zram2       253:2    0     0B  0 disk

df-h:

udev               185M            0  185M            0% /dev
tmpfs               49M         2,6M   47M            6% /run
/dev/mmcblk0p1     1,8G         1,2G  451M           74% /
tmpfs              243M            0  243M            0% /dev/shm
tmpfs              5,0M            0  5,0M            0% /run/lock
tmpfs              243M            0  243M            0% /tmp
/dev/zram1          47M         2,8M   41M            7% /var/log
tmpfs               49M            0   49M            0% /run/user/0
/dev/sda1          117G          55G   57G           50% /media

findmnt --raw | grep /var/log:

/var/log.hdd /dev/mmcblk0p1[/var/log] ext4 rw,noatime,errors=remount-ro,commit=120
/var/log /dev/zram1 ext4 rw,nosuid,nodev,noexec,relatime,discard

I want to see every command you do, ls -l, how you loop the img and mount it etc. (it looks like you provided the output of the img file correctly, I also need the ls from the RUNNING system to compare file for file IN THE SAME POST, ALL DONE FROM THE SAME SYSTEM, the system you back up from.

I created a loop with
losetup -f -P /media/banana.img
and mounted is with
mount /dev/loop0p1 /mnt/sda1

Here is a listing of /var/log (this is my original OS!) :

-rw-r--r-- 1 root root               5241 янв 15 00:00 alternatives.log
drwxr-xr-x 2 root root               4096 янв 13 14:31 apt
-rw-r--r-- 1 root root             582065 янв 15 03:51 armbian-hardware-monitor.log
-rw-r----- 1 root adm               92115 янв 15 04:45 auth.log
-rw-r--r-- 1 root root              69555 янв 15 00:00 bootstrap.log
-rw-rw---- 1 root utmp               2688 янв 15 00:00 btmp
-rw-r----- 1 root adm               39285 янв 15 04:45 cron.log
-rw-r--r-- 1 root root             198226 янв 15 00:00 dpkg.log
-rw-r--r-- 1 root root                  0 янв 15 00:00 faillog
lrwxrwxrwx 1 root systemd-journal      20 янв 15 03:51 journal -> /var/log.hdd/journal
-rw-r----- 1 root adm              585388 янв 15 04:52 kern.log
-rw-rw-r-- 1 root utmp                292 янв 15 03:52 lastlog
drwx------ 2 root root              16384 янв 15 03:51 lost+found
drwx------ 2 root root               4096 янв  7 07:33 private
lrwxrwxrwx 1 root root                 39 янв  7 07:33 README -> ../../usr/share/doc/systemd/README.logs
drwxr-xr-x 3 root root               4096 янв  7 07:33 runit
drwxr-x--- 3 root adm                4096 янв 12 00:00 samba
-rw-r----- 1 root adm             1065432 янв 15 04:52 syslog
drwxr-xr-x 2 root root               4096 янв 14 00:00 v2ray
-rw-rw-r-- 1 root utmp              68352 янв 15 03:52 wtmp

Here is a listing of loop0p1 /var/log (this is the image file!) :

-rw-r--r-- 1 root root              5241 янв 13 00:00 alternatives.log
drwxr-xr-x 2 root root              4096 янв 13 14:31 apt
-rw-r--r-- 1 root root            434284 янв 13 17:10 armbian-hardware-monitor.log
-rw-r----- 1 root adm              47201 янв 13 20:45 auth.log
-rw-r--r-- 1 root root             69555 янв 13 00:00 bootstrap.log
-rw-rw---- 1 root utmp              2688 янв 13 00:00 btmp
-rw-r----- 1 root adm              19432 янв 13 20:45 cron.log
-rw-r--r-- 1 root root            198226 янв 13 14:31 dpkg.log
-rw-r--r-- 1 root root                 0 янв 13 00:00 faillog
lrwxrwxrwx 1 root systemd-journal     20 янв 13 17:10 journal -> /var/log.hdd/journal
-rw-r----- 1 root adm             439612 янв 13 20:49 kern.log
-rw-rw-r-- 1 root utmp               292 янв 13 20:15 lastlog
drwx------ 2 root root              4096 янв 13 17:10 lost+found
drwx------ 2 root root              4096 янв  7 07:33 private
lrwxrwxrwx 1 root root                39 янв  7 07:33 README -> ../../usr/share/doc/systemd/README.logs
drwxr-xr-x 3 root root              4096 янв  7 07:33 runit
drwxr-x--- 3 root adm               4096 янв 12 00:00 samba
-rw-r----- 1 root adm             794881 янв 13 20:49 syslog
drwxr-xr-x 2 root root              4096 янв 13 20:19 v2ray
-rw-rw-r-- 1 root utmp             51840 янв 13 20:15 wtmp

As you can see, everything is OK here.
In other words, this is the exact copy of the original working system.

Next we boot it (i.e. boot from SD with it), and have the next /var/log contents:

-rw-r--r-- 1 root root   5241 янв 15 02:10 alternatives.log
drwxr-xr-x 2 root root   4096 янв 13 14:31 apt
-rw-r--r-- 1 root root 528617 янв 15 02:10 armbian-hardware-monitor.log
-rw-r----- 1 root adm   50528 янв 15 02:10 auth.log
-rw-r--r-- 1 root root  69555 янв 15 02:10 bootstrap.log
-rw-rw---- 1 root utmp   2688 янв 15 02:10 btmp
-rw-r----- 1 root adm   21491 янв 15 02:10 cron.log
-rw-r--r-- 1 root root 198226 янв 15 02:10 dpkg.log
-rw-r--r-- 1 root root      0 янв 15 02:10 faillog
-rw-r----- 1 root adm  531345 янв 15 02:11 kern.log
-rw-rw-r-- 1 root utmp    292 янв 15 02:10 lastlog
drwx------ 2 root root  16384 янв 14 00:16 lost+found
drwx------ 2 root root   4096 янв  7 07:33 private
lrwxrwxrwx 1 root root     39 янв  7 07:33 README -> ../../usr/share/doc/systemd/README.logs
drwxr-xr-x 3 root root   4096 янв  7 07:33 runit
drwxr-x--- 3 root adm    4096 янв 12 00:00 samba
-rw-r----- 1 root adm  943911 янв 15 02:11 syslog
drwxr-xr-x 2 root root   4096 янв 13 20:19 v2ray
-rw-rw-r-- 1 root utmp  60288 янв 15 02:10 wtmp

In other words, we see, that journal link is missing.

Here is a listing of /var/log.hdd (this is my original OS!) :

-rw-r--r-- 1 root root              5241 янв 15 00:00 alternatives.log
drwxr-xr-x 2 root root              4096 янв 13 14:31 apt
-rw-r--r-- 1 root root            532658 янв 15 03:51 armbian-hardware-monitor.log
-rw-r--r-- 1 root root             16158 янв 11 21:50 armbian-hardware-monitor.log.1.gz
-rw-r--r-- 1 root root             20540 янв 15 03:51 armbian-ramlog.log
-rw-r----- 1 root adm              90131 янв 15 03:51 auth.log
-rw-r----- 1 root adm              13301 янв 12 00:00 auth.log.1
-rw-r--r-- 1 root root             69555 янв 15 00:00 bootstrap.log
-rw-rw---- 1 root utmp              2688 янв 15 00:00 btmp
-rw-r----- 1 root adm              38245 янв 15 03:45 cron.log
-rw-r----- 1 root adm              22061 янв 12 00:00 cron.log.1
-rw-r--r-- 1 root root            198226 янв 15 00:00 dpkg.log
-rw-r--r-- 1 root root                 0 янв 15 00:00 faillog
drwxr-sr-x 3 root systemd-journal   4096 янв  8 21:28 journal
-rw-r----- 1 root adm             538267 янв 15 02:55 kern.log
-rw-r----- 1 root adm              62595 янв 11 22:57 kern.log.1
-rw-rw-r-- 1 root utmp               292 янв 15 02:53 lastlog
drwx------ 2 root root              4096 янв  7 07:33 private
lrwxrwxrwx 1 root root                39 янв  7 07:33 README -> ../../usr/share/doc/systemd/README.logs
drwxr-xr-x 3 root root              4096 янв  7 07:33 runit
drwxr-x--- 3 root adm               4096 янв 12 00:00 samba
-rw-r----- 1 root adm             991786 янв 15 03:51 syslog
-rw-r----- 1 root adm             133330 янв 12 00:00 syslog.1
drwxr-xr-x 2 root root              4096 янв 14 00:00 v2ray
-rw-rw-r-- 1 root utmp             64896 янв 15 03:51 wtmp

Here is a listing of loop0p1 /var/log.hdd (this is the image file!) :

-rw-r--r-- 1 root root              5241 янв 13 00:00 alternatives.log
drwxr-xr-x 2 root root              4096 янв 13 14:31 apt
-rw-r--r-- 1 root root            386595 янв 13 17:10 armbian-hardware-monitor.log
-rw-r--r-- 1 root root             16158 янв 11 21:50 armbian-hardware-monitor.log.1.gz
-rw-r--r-- 1 root root             15343 янв 13 17:10 armbian-ramlog.log
-rw-r----- 1 root adm              44729 янв 13 17:10 auth.log
-rw-r----- 1 root adm              13301 янв 12 00:00 auth.log.1
-rw-r--r-- 1 root root             69555 янв 13 00:00 bootstrap.log
-rw-rw---- 1 root utmp              2688 янв 13 00:00 btmp
-rw-r----- 1 root adm              18163 янв 13 17:00 cron.log
-rw-r----- 1 root adm              22061 янв 12 00:00 cron.log.1
-rw-r--r-- 1 root root            198226 янв 13 14:31 dpkg.log
-rw-r--r-- 1 root root                 0 янв 13 00:00 faillog
drwxr-sr-x 3 root systemd-journal   4096 янв  8 21:28 journal
-rw-r----- 1 root adm             391649 янв 13 16:34 kern.log
-rw-r----- 1 root adm              62595 янв 11 22:57 kern.log.1
-rw-rw-r-- 1 root utmp               292 янв 13 16:19 lastlog
drwx------ 2 root root              4096 янв  7 07:33 private
lrwxrwxrwx 1 root root                39 янв  7 07:33 README -> ../../usr/share/doc/systemd/README.logs
drwxr-xr-x 3 root root              4096 янв  7 07:33 runit
drwxr-x--- 3 root adm               4096 янв 12 00:00 samba
-rw-r----- 1 root adm             720306 янв 13 17:10 syslog
-rw-r----- 1 root adm             133330 янв 12 00:00 syslog.1
drwxr-xr-x 2 root root              4096 янв 13 14:18 v2ray
-rw-rw-r-- 1 root utmp             48384 янв 13 17:10 wtmp

As you can see, everything is OK here.
In other words, this is the exact copy of the original working system.

Next we boot it, and have the next /var/log.hdd contents:

-rw-r--r-- 1 root root              5241 янв 14 00:03 alternatives.log
drwxr-xr-x 2 root root              4096 янв 13 14:31 apt
-rw-r--r-- 1 root root            527344 янв 15 02:10 armbian-hardware-monitor.log
-rw-r--r-- 1 root root              2996 янв 15 02:10 armbian-ramlog.log
-rw-r----- 1 root adm              49802 янв 14 00:16 auth.log
-rw-r--r-- 1 root root             69555 янв 14 00:03 bootstrap.log
-rw-rw---- 1 root utmp              2688 янв 14 00:03 btmp
-rw-r----- 1 root adm              21491 янв 15 02:09 cron.log
-rw-r--r-- 1 root root            198226 янв 14 00:03 dpkg.log
-rw-r--r-- 1 root root                 0 янв 14 00:03 faillog
lrwxrwxrwx 1 root systemd-journal     20 янв 13 17:10 journal -> /var/log.hdd/journal
-rw-r----- 1 root adm             531009 янв 14 00:16 kern.log
-rw-rw-r-- 1 root utmp               292 янв 14 00:04 lastlog
drwx------ 2 root root              4096 янв 13 17:10 lost+found
drwx------ 2 root root              4096 янв  7 07:33 private
lrwxrwxrwx 1 root root                39 янв  7 07:33 README -> ../../usr/share/doc/systemd/README.logs
drwxr-xr-x 3 root root              4096 янв  7 07:33 runit
drwxr-x--- 3 root adm               4096 янв 12 00:00 samba
-rw-r----- 1 root adm             938774 янв 15 02:10 syslog
drwxr-xr-x 2 root root              4096 янв 13 20:19 v2ray
-rw-rw-r-- 1 root utmp             57216 янв 14 00:16 wtmp

In other words, we see that the journal directory is missing, and it is a broken link, pointing to itself.

I hope I was as clear as I can.

Obviously you have some different OS. Where you downloaded it from?
Could you test all the same with community version (I specified the link)?
Maybe the problem is just in the OS version?

And thank you for your time!

[UnconnectedBedna]

I can't do it, because everything is OK in both the image file and burned SD before the first boot.

Then... What does shrink-backup have to do with any of this?
If the files are the same on the img as on the system you run, what exactly are you trying to say here?
Also strange that the dates don't match up, do you create that symlink manually??

As I have explained multiple times, there normally IS NO journal in /var/log on a running DEBIAN BASED system, it gets moved when booting and rotated back when shutting down. (You can change that behavior in journald, but normally, /run is utilized.)
Maybe you have configured something to create that symlink, and that is not correctly configured, or the specific version of armbian you have uses /var/log, and has miss-configurations with ramlog or smthn, I have no idea. But shrink-backup is definitely not responsible for that behavior.

When the script is done, it's done. And if the files are there before boot, they are there. If they gets removed or symlinked or whatever, it has NOTHING to do with shrink-backup.
Even if you have the autoexpansion enabled, it is running code that you already had from your armbian install, the systemd service: armbian-resize-filesystem.service

Just out of curiosity, what do you have in /run/log/journal on the running system?

Could you test all the same with community version (I specified the link)?
Hardware: Banana Pi M2 zero

Sure, buy me one and I'll try it for you. xD

[Awak00m]

Then... What does shrink-backup have to do with any of this?

Good question! Should I provide you with a proof of the fact, that contents, produced by dd and by your script, differ AFTER the first boot?
Are you agree, that it would be a proof?
If so, I can confirm, that dd if=/dev/mmcblk0p1 of=/dev/sda1 bs=1M makes the exact copy. Just tried it. 💯

Also strange that the dates don't match up, do you create that symlink manually??

Obviously the "bad" symlink's date is different from the original directory's date, since a symlink is just a physical file created sometime during the system startup process. And of course, I never created it manually.

normally IS NO journal in /var/log on a running DEBIAN BASED system

I can't tell, "how normal" is the "Armbian community" OS version. I just see, what I see.
I posted the link to the origin.
And I checked all the same behavior on the original downloaded image with the only armbian-config been applied in order to turn WiFi on.

If they gets removed or symlinked or whatever, it has NOTHING to do with shrink-backup.

In my opinion this statement is incorrect, but of course, who am I to argue with you...
Indeed, the problem is covered NOT in the symlink copying itself. It is covered in some other place.

Just out of curiosity, what do you have in /run/log/journal on the running system?

/run/log/journal:
drwxr-s---+ 2 root systemd-journal 60 янв 16 10:01 0ee91095e12a4ef3b0e88b307b0ed90d

inside it we have:
-rw-r-----+ 1 root systemd-journal 638976 янв 16 10:00 system.journal

/var/log.hdd/journal:
drwxr-sr-x+ 2 root systemd-journal 4096 янв 16 00:00 0ee91095e12a4ef3b0e88b307b0ed90d

inside it we have:

-rw-r-----+ 1 root systemd-journal 1073576 янв 12 00:11 system@71a6efb12d304507bbf076017457af03-0000000000000001-00062b3458d>
-rw-r-----+ 1 root systemd-journal  957904 янв 12 00:36 system@71a6efb12d304507bbf076017457af03-0000000000000647-00062b72f9b>
-rw-r-----+ 1 root systemd-journal 1219288 янв 13 08:58 system@71a6efb12d304507bbf076017457af03-0000000000000ce6-00062b73540>
-rw-r-----+ 1 root systemd-journal  933664 янв 13 12:16 system@71a6efb12d304507bbf076017457af03-00000000000013e9-00062b8e747>
-rw-r-----+ 1 root systemd-journal 1085712 янв 13 14:11 system@71a6efb12d304507bbf076017457af03-0000000000001a66-00062b91375>
-rw-r-----+ 1 root systemd-journal  966112 янв 13 16:14 system@71a6efb12d304507bbf076017457af03-00000000000021b6-00062b92d3c>
-rw-r-----+ 1 root systemd-journal 1057040 янв 14 00:00 system@71a6efb12d304507bbf076017457af03-000000000000275c-00062b948ab>
-rw-r-----+ 1 root systemd-journal 1059904 янв 15 00:00 system@71a6efb12d304507bbf076017457af03-0000000000002e90-00062b9b0d2>
-rw-r-----+ 1 root systemd-journal 1056544 янв 15 03:51 system@71a6efb12d304507bbf076017457af03-000000000000345c-00062baf2b0>
-rw-r-----+ 1 root systemd-journal 1050624 янв 16 00:00 system@71a6efb12d304507bbf076017457af03-0000000000003b6b-00062bb2683>
-rw-r-----+ 1 root systemd-journal 2621440 янв 16 08:12 system.journal

Sure, buy me one and I'll try it for you. xD

Buy what? Would you like to say that the same OS version has different structure on different hardware?
Yet I could agree, that the structure may vary between 32-bit and 64-bit CPU...
What you did show in your first answer, was definitely NOT a fresh Armbian community OS, right?

[UnconnectedBedna]

Good question! Should I provide you with a proof of the fact, that contents, produced by dd and by your script, differ AFTER the first boot?
Are you agree, that it would be a proof?

Nope, because a dd is a CLONE, not a copy, not a backup, A CLONE BIT FOR BIT of the system you run. Completely different from rsync with shrink-backup that is a COPY of SELECTED FILES.
If a dd works, and shrink-backup does not, logic dictates that there are some files on your system that you have to make sure are included when using shrink-backup. This can be done as I have mentioned before, by utilizing -toption and editing exclude.txt
https://github.com/UnconnectedBedna/shrink-backup?tab=readme-ov-file#-t-excludetxt

Important

If -t is NOT selected the following folders will be excluded:

/lost+found
/proc/*
/sys/*
/dev/*
/tmp/*
/run/*
/mnt/*
/media/*
/var/swap

There seems to be something refusing to boot unless you shut down your system CORRECTLY. I have pointed you in a direction 4-5 times of what I think it is.

since a symlink is just a physical file created sometime during the system startup process.

No they are not, they are exactly like files or directories on linux. When they are created, they are created. NOTHING in a linux filesystem is changed randomly at boot. A symlink is just a file with a different magic bit (or sticky bit or whatever it's called).
I created these symlinks a few years ago, very strange that they are not "recreated" every reboot, or you think I haven't rebooted since 2022?

$ ls -l
total 0
lrwxrwxrwx 1 bedna media 31 Nov  6  2022  Albums -> /media/diverse/media/mp3/Albums
lrwxrwxrwx 1 bedna media 39 Nov  6  2022 'Sorterade mp3' -> '/media/diverse/media/mp3/Sorterade mp3/'

So if you find what is recreating that symlink, and why, you probably find the culprit of your refusal to boot.
But I assure you, shrink-backup is NOT responsible for that.

Buy what? Would you like to say that the same OS version has different structure on different hardware?

Yes, of course... They are different releases. Some are from armbian, some are community driven outside of armbian support...
Did... did you not install a release for your specific hardware?!?
I didn't check your link since installing an OS has nothing to do with shrink-backup.

What you did show in your first answer, was definitely NOT a fresh Armbian community OS, right?

It was not, but that does not matter at all. All shrink-backup does is copy selected files to an img.
I asked you for output to compare, and you delivered that. 👍
After looking at the files on the img and on your system, all files are there after the backup is done.
IDK how many times I have to hint and point you in the direction of strange configuration on your side.

But your question is a good one. Have YOU ensured the release of this particular distro acts this way with a fresh install and a reboot? You are the one claiming there is a bug in shrink-backup, YOU have to provide proof, I can not reproduce this issue. (you have to do the first run, and then reboot before trying to use shrink-backup)
The test I did here obv worked as intended. So if something is not working on your side, the logical reason is something is different on YOUR side, or there would be more reports of the script not working on latest armbian release. (or maybe there are way less users of the script than I think and you ARE the first, but I find that pretty unlikely, but COULD be true. That is why I'm not closing this issue. 😉 )

I will give you a hint, again, because I can be wrong. As you pointed out, the version I run is not the latest.
All my armbian hardware has sadly gone out of support, even in community, so I have to rely on old versions until I have money to invest in something new.
Armbian is forked from raspberry pi os and modified to become armbian, and the latest release of rpiOS DO utilize /var/log/journal while booted (bullseye does not). I assume they want a persistent log instead of a volatile.
So guess what is inside /run/log/journal? Absolutely nothing.
But on your system:

/run/log/journal:
drwxr-s---+ 2 root systemd-journal 60 янв 16 10:01 0ee91095e12a4ef3b0e88b307b0ed90d

/var/log.hdd/journal:
drwxr-sr-x+ 2 root systemd-journal 4096 янв 16 00:00 0ee91095e12a4ef3b0e88b307b0ed90d

Your installation will probably not be confused at all, or, idk, refuse to boot when you have the same log hash in two locations, I honestly don't know, but it seems YOU have identified it as a problem for you...

I'm no logging expert but:

$ man systemd-journald

FILES
       /etc/systemd/journald.conf
           Configure systemd-journald behavior. See journald.conf(5).

       /run/log/journal/machine-id/*.journal, /run/log/journal/machine-id/*.journal~, /var/log/journal/machine-id/*.journal, /var/log/journal/machine-id/*.journal~
           systemd-journald writes entries to files in /run/log/journal/machine-id/ or /var/log/journal/machine-id/ with the ".journal" suffix. If the daemon is stopped uncleanly, or if the files are found
           to be corrupted, they are renamed using the ".journal~" suffix, and systemd-journald starts writing to a new file.  /run/ is used when /var/log/journal is not available, or when Storage=volatile
           is set in the journald.conf(5) configuration file.


$ man journald.conf

OPTIONS
       All options are configured in the [Journal] section:

       Storage=
           Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy
           (which is created if needed). If "persistent", data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal
           (which is created if needed), during early boot and if the disk is not writable.  "auto" behaves like "persistent" if the /var/log/journal directory exists, and "volatile" otherwise (the
           existence of the directory controls the storage mode).  "none" turns off all storage, all log data received will be dropped (but forwarding to other targets, such as the console, the kernel log
           buffer, or a syslog socket will still work). Defaults to "auto" in the default journal namespace, and "persistent" in all others.

           Note that journald will initially use volatile storage, until a call to journalctl --flush (or sending SIGUSR1 to journald) will cause it to switch to persistent logging (under the conditions
           mentioned above). This is done automatically on boot via "systemd-journal-flush.service".

           Note that when this option is changed to "volatile", existing persistent data is not removed. In the other direction, journalctl(1) with the --flush option may be used to move volatile data to
           persistent storage.

           When journal namespacing (see LogNamespace= in systemd.exec(5)) is used, setting Storage= to "volatile" or "auto" will not have an effect on the creation of the per-namespace logs directory in
           /var/log/journal/, as the systemd-journald@.service service file by default carries LogsDirectory=. To turn that off, add a unit file drop-in file that sets LogsDirectory= to an empty string.