initrd-setup-root: Set up more /var directories from packages

[pothos]

The base_image_var.conf contents are generated during image build and
don't originally come from tmpfiles rules but from package
installation. For those rules coming from a package's tmpfiles I think
t's enough to let them do the job at their regular boot stage but for
those not from tmpfiles we don't really know whether this works for
them, so I added it as precaution. Also, add info on where
/var/log/journal gets set up.

How to use

Backport to Alpha

Testing done

Done

[krnowak]

Where the base_image_var.conf and var.conf come from?

[pothos]

All these files are under /sysroot/usr/lib/tmpfiles.d/

[tormath1]

I got an error from the initramfs when trying to apply this conf:

                bash-5.1# systemd-tmpfiles --root=/sysroot --create var.conf
                /sysroot/usr/lib/tmpfiles.d/var.conf:15: Failed to resolve group 'utmp'.

[krnowak]

Sorry for the confusion. I meant that I know that baselayout-home.conf comes from our baselayout project, but I don't know from which project base_image_var.conf and var.conf come from. I couldn't find them in systemd, init or baselayout. That's why I'm asking.

[pothos]

base_image_var.conf is generated based on package contents, var.conf comes from systemd.

Ok, sounds like we should not add var.conf directly but only copy the wanted line somehow

[krnowak]

Ok, sounds like we should not add var.conf directly but only copy the wanted line somehow

flatcar-tmpfiles in baselayout could also copy the utmp group to solve the issue Mathieu had.

[tormath1]

Suggested change

	var.conf
	systemd-tmpfiles --root=/sysroot --create var.conf --exclude-prefix /var/log/wtmp --exclude-prefix /var/log/btmp --exclude-prefix /var/log/lastlog

[pothos]

Ah, interesting, I went with flatcar/baselayout#29 to only work on Flatcar-specific things and be independent from systemd changes

[tormath1]

Note: it's possible to quickly identify if the system is persisting logs by running: journactl --verify: if you only see /run/log/journal/* it means the issue is still present.
I'm looking to provide tests to avoid future regressions.

[pothos]

Looks ok now:

journalctl --verify
PASS: /run/log/journal/c7ff69fdb5844e33a22092259bad1823/system.journal                                                                             
PASS: /var/log/journal/6716a3388bb147ec955254cbe893efc6/system.journal

After the reboot I also see the first boot:

journalctl --list-boots
IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY                 
 -1 272c012b16a04d55b5c6d67f1ce8c85e Mon 2023-04-03 12:47:37 UTC Mon 2023-04-03 12:50:49 UTC
  0 e953f09c5c494cf2a61dc1c13f27f2a6 Mon 2023-04-03 12:50:54 UTC Mon 2023-04-03 12:51:12 UTC