kola: Add test case for extra partition creation#457
Conversation
330c799 to
e372929
Compare
| filesystems: | ||
| - name: var | ||
| mount: | ||
| device: /dev/disk/by-partlabel/VAR |
There was a problem hiding this comment.
For /var we should also make sure that the mount point is set up in the initrd with Ignition because systemd-tmpfiles should populate /var from the initrd. I think with CLC and the translation to Ignition v3 this is complicated and if you want to test /var we should rather use Butane. If it's not really about /var (or /home and similar) but an arbitrary mount point then it's easier to use CLC.
There was a problem hiding this comment.
For /var we should also make sure that the mount point is set up in the initrd with Ignition because systemd-tmpfiles should populate /var from the initrd.
we don't populate /var with systemd-tmpfiles from the initrd, and ignition unmounts mounted partitions in one of the last stages. It does this to ensure a system does not depend on ignition performing the mount.
I think with CLC and the translation to Ignition v3 this is complicated and if you want to test /var we should rather use Butane. If it's not really about /var (or /home and similar) but an arbitrary mount point then it's easier to use CLC.
It's not about the mountpoint at all, it's about adding partitions to a partitioned disk (that's why this was in partitions.go).
For sure we need a testcase that ensures we don't break backwards compat with ignition v2/CLC. /var is also a location users are likely to try to put on a separate filesystem.
There was a problem hiding this comment.
We do, that's in base_image_var.conf and baselayout.conf but yeah, seems that we have a problem in general with separate /var partitions, at least on the first boot before the final system also had a chance to set up the files in /var. What one might see as result is either a failed unit or a misbehaving system, e.g., the first boot journal might not be persisted (this was a bug we fixed by letting the initrd populate /var correctly).
There was a problem hiding this comment.
FYI: The topic of separate /var is also relevant for applying sysext images from the initrd. The suggestion from Lennart was to establish a kernel command line setting similar to what systemd has for /usr. It would then be properly mounted in /sysroot/var.
There was a problem hiding this comment.
What we can also do in Flatcar is to define a partition or filesystem label to expect and then add a mount unit for that (it can be compatible with a future systemd cmdline way by having this mount unit only be set up if the cmdline option is not there, I think we have similar logic for /usr).
There was a problem hiding this comment.
Started something for supporting separate /var: flatcar/bootengine#75
There was a problem hiding this comment.
Would be good to write some files here with Ignition. We also have to add one more test case with Butane an defining the /var path in the initrd and writing some files because the uplifted v3 path is generated and can't be controlled whereas with Butane we can use the /sysroot/var mount point and have to check that this works.
There was a problem hiding this comment.
so i added the file creation part, but not the butane yet
This is a testcase for a regression that passes until Flatcar 3374 and fails on Flatcar 3510 (only checked stable releases). Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
e372929 to
1bea94d
Compare
Switch filesystem label to VAR to follow the same convention as other core filesystems (ROOT/EFI/OEM). The testcase has also been extended to make sure creating files in /var works. Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
This is a testcase for a regression that passes until Flatcar 3374 and fails on Flatcar 3510 (only checked stable releases).