`/srv` not being mounted in `transactional-update` environment

[astein248]

I am running MicroOS on two raspberry pi 4s. MicroOS was installed onto external SSDs via iso flashed to a usb drive.

One pi had its ssd automatically partitioned by yast. The other did not, but I was able to manually partition it the same way.

Once I got snapper and transactional-update working, I found a odd difference between the two installs.
The manually partitioned pi is not getting /srv and /home mounted inside of the transactional-update environment, which is causing some packages (specifically system-user-tftp, which is required by dnsmasq, which is required by cni-plugin-dnsname) to fail to install.
In this case it is because /srv is not mounted (and doesn't have the correct selinux context applied).

/srv is a sub-subvolume of / on both systems, and the subvolume structure is completely the same between them as far as I can tell.

Is /srv supposed to be mounted in the transactional-update environment?
Any ideas why it would be mounted on one system and not the other?

Please let me know what other information I can provide that may be helpful.

Thanks!

[laenion]

Neither /home nor /srv are mounted into the transactional-update environment by default, though you could change that in /etc/tukit.conf.

The difference may be caused by how the subvolumes were created: In a default install the subvolumes are not subvolumes of the root files system, but of @ (which itself isn't mounted anywhere by default, but you can see it with btrfs subvolume list /), and all these independent subvolumes will then be mounted to the corresponding places in the root file system.
When you created the subvolumes yourself I assume that you created the subvolumes of another one, probably the one which was your root file system back then. Could you check this by calling btrfs subvolume list / on the manually set up system?

[theEndBeta]

On MicroOS, the configuration file seems to be /usr/etc/tukit.conf, and is the same across both systems.

Similarly, the btrfs structure appears to be the same as well:

Automatically partitioned system:

ID 256 gen 27 top level 5 path @
ID 257 gen 28366 top level 256 path @/usr/local
ID 258 gen 27299 top level 256 path @/srv
ID 259 gen 28217 top level 256 path @/root
ID 260 gen 27873 top level 256 path @/opt
ID 261 gen 28365 top level 256 path @/home
ID 262 gen 12610 top level 256 path @/boot/writable
ID 263 gen 28352 top level 256 path @/boot/grub2/arm64-efi
ID 264 gen 28356 top level 256 path @/.snapshots

Manually partitioned system:

ID 256 gen 549 top level 5 path @
ID 258 gen 530 top level 256 path @/usr/local
ID 259 gen 519 top level 256 path @/srv
ID 260 gen 526 top level 256 path @/root
ID 261 gen 58 top level 256 path @/opt
ID 262 gen 562 top level 256 path @/home
ID 263 gen 58 top level 256 path @/boot/writable
ID 264 gen 538 top level 256 path @/boot/grub2/arm64-efi
ID 265 gen 561 top level 256 path @/.snapshots

Another thing that I just noticed it that /srv doesn't appear to be mounted in either system, but the working system is labeled correctly (and has my files) and the other is not.
The automatically partitioned system has some of my files, but not one that I created just before entering transactional-update shell.

Automatically partitioned system:

# before running `mount /srv`
dr-xr-xr-x.   1 root root system_u:object_r:var_t:s0            22 Apr  3 20:08 srv

# after running `mount /srv`
dr-xr-xr-x.   1 root root system_u:object_r:var_t:s0            22 Mar 22 20:00 srv

Manually partitioned system:

# before running `mount /srv`
drwxr-xr-x.   1 root root system_u:object_r:unlabeled_t:s0        0 Sep 10 18:34 srv

# after running `mount /srv`
dr-xr-xr-x.   1 root root system_u:object_r:var_t:s0             14 Sep  9 00:30 srv

[laenion]

Another idea after re-reading your last comment: If /srv is not mounted, then the contents of /srv may be part of the root file system instead of the subvolume. Could you check whether /.snapshots//snapshot/srv contains (all of your) files? It should be empty.