Immutable Ubuntu with separate /usr partition

[X4mp]

Hi Community,
I need some help with mkosi and systemd-repart to build an immutable Ubuntu image with a separate /usr partiion and grub as bootloader.

I'm using grub as BooLoader and BiosBootLoader in my mkosi.conf and when I just use the esp, bios and root partition config for repart, the image can be booted sucessfully with qemu. But as soon as I add a repart config for Type=usr and use CopyFiles=/usr:/ the image won't boot anymore.

mkosi.conf:

[Distribution]
Distribution=ubuntu
Release=oracular
Repositories=oracular,main,restricted,universe

[Output]
Format=disk

[Content]
Bootable=yes
Bootloader=grub
BiosBootloader=grub
Timezone=UTC
Keymap=de-latin1
Locale=C.UTF-8
Packages=...<left  out for simplicity>

Autologin=yes
WithNetwork=true

[Host]
ToolsTree=default
ToolsTreeDistribution=ubuntu
ToolsTreeRelease=oracular

mkosi.repart/10-usr.conf

[Partition]
Type=usr
Label=nts_usr_%A
UUID=5a59947d-1546-489b-8669-db956b61ecb8
Format=ext4
CopyFiles=/usr:/
SizeMinBytes=10G
SizeMaxBytes=10G

My process of building the image is the following:

mkosi -f build
qemu-img convert -f raw image.raw -O qcow2 box.img
qemu-system-x86_64 -smp 6 -m 2G -net bridge,br=virbr0 -net nic,model=virtio box.img

This will start qemu and the boot is started, but after the initrd when systemd-switch-root trys to run systemd it fails and I drop into the emergency shell. I looked at journalctl -u systemd-switch-root.service and the error presented is that /etc/os-release cannot be found. This is probably, because /etc/os-release is just a symlink to ../usr/lib/os-release and /usr is not mounted in /sysroot/usr/.

Therefore my question, if you are ok with answering, is:
What are the necessary steps to mount the additional /usr/ partition in the initrd during boot, so systemd can find the files required?

[MoltenArmor]

I think you'd better take a look at systemd/particleos .

[X4mp]

I have looked at it and also installed it on another desktop, but there are a few clear differences in what I want to achieve.

1. I don't want o build an installer. I want to build an image which i can convert to a format I can use on my hypervisor. It's just for server VMs.
2. ParticleOS uses systemd-boot if I'm correct. Systemd-boot uses UEFI. I need to use grub.
3. ParticleOS only supports arch and fedora. Fedora can handle separate usr/ partitions better than others.

[MoltenArmor]

I have looked at it and also installed it on another desktop, but there are a few clear differences in what I want to achieve.

1. I don't want o build an installer. I want to build an image which i can convert to a format I can use on my hypervisor. It's just for server VMs.
2. ParticleOS uses systemd-boot if I'm correct. Systemd-boot uses UEFI. I need to use grub.
3. ParticleOS only supports arch and fedora. Fedora can handle separate usr/ partitions better than others.

1. I'm not sure what you mean. Any disk image built with mkosi does not include an installer, and raw disk images CAN directly be used for a vm, which is I've always been doing.
2. There is no relationship between what bootloader you use for UEFI and what bootloader you use for Legacy BIOS. From my understanding, you can use systemd-boot for UEFI and GRUB for Legacy BIOS. Just add BiosBootloader=grub.
3. I just mean that you can use ParticleOS as a reference.

Similar to you, I'm also trying to build an immutable Debian. Based on my experience, mount.usr= is necessary to make the system bootable when the root filesystem(/) is "generated" from /usr during the very first bootup. I use mount.usr=PARTLABEL=xxx to achieve this, which you can see here. You can also use mount.usr=PARTUUID as @DaanDeMeyer mentioned.

[X4mp]

Hey, thanks. I added the KernelCommandLine parameter and now it worked. Thank you very much for your help!

[DaanDeMeyer]

@X4mp You will need to add mount.usr=PARTUUID to the kernel command line at the very least so that mkosi will fill in the partuuid for you if you're not adding a usr verity partition. There might be other changes required because you're using grub instead of systemd-boot, you'll have to figure that out on your own as I don't know of anyone else running such a setup.

[X4mp]

Thanks @DaanDeMeyer
The KernelCommandLine parameter was the solution for my problem. Also there were no other changes necessary for grub, besides Bootloader=grub and BiosBootLoader=grub.