Ubuntu 26.04 dracut requires systemd

[Sithuk]

Testing for ubuntu 26.04 and remote access to unlock zfsbootmenu during boot has identified an issue. It looks like ubuntu 26.04 has moved to a more systemd based dracut. Networking in the initramfs is now tied to systemd. Network-legacy doesn't appear to be a workaround anymore.

Are you aware of a workaround to get remote access to work? The relevant thread from the ubuntu zfsbootmenu install script discussion forum:
Sithuk/ubuntu-server-zfsbootmenu#88

[zdykstra]

Using our build container is going to get you the most tested/reliable EFI possible. With the schism between dracut and dracut-ng, it will become increasingly difficult to account for the variations between those two projects. dracut-ng explicitly supports non-systemd distributions, and it's what Void (and our build containers) use.

[Sithuk]

The script enables remote access including remote unlocking using the dracut-crypt-ssh module.

https://github.com/dracut-crypt-ssh/dracut-crypt-ssh

The last time I looked at using the zfsbootmenu container build system I don't think it supported loading that module into the container. Has that changed now? Is it possible to use the container to build a remote access zfsbootmenu boot file that has the remote unlock feature?

[zdykstra]

You can add arbitrary packages to a build container and dracut-crypt-ssh is packaged for Void.

[ahesford]

https://docs.zfsbootmenu.org/en/v3.1.x/general/container-building/example.html#adding-remote-access-capabilities

This example describe how you can populate a container image to build remote-capable images around mkinitcpio, which is often easier and more deterministic than dracut. However, it is possible to adapt the container to achieve the same result with dracut.

[Sithuk]

Thank you. I'll work on a container based version of the install script to attempt to achieve 26.04 compatibility.

[Sithuk]

I've got the script updated for a container based build, including for remote access. Not pushed the changes yet.

I have a welcome message feature in the current script that informs the user after they connect remotely what to enter to start zfsbootmenu. The message is displayed on connection to dropbear. How might I go about incorporating that with a container build system?
https://github.com/Sithuk/ubuntu-server-zfsbootmenu/blob/main/ubuntu_server_encrypted_root_zfs.sh#L1334

[Sithuk]

That didn't take long! First issue reported from a user not knowing what to enter at the prompt following remote access:
Sithuk/ubuntu-server-zfsbootmenu#88 (reply in thread)

Would you accept a pull request to update the remote-ssh-build.sh script to incorporate a welcome message feature?

[ahesford]

Not if it involves modifying the dracut-crypt-ssh module as you're doing. You should just created an rc.d directory in your container build directory; you can add scripts therein to modify the container once it's running but before generate-zbm is called. You can do your banner changes there.

[Sithuk]

I've now added the welcome message to my script. But it involves modifying the dropbear start sh script for the dracut-crypt-ssh module.

The best approach for an upstream fix might be to add a config option to dracut-crypt-ssh that allows for the dropbear banner option to be defined. Then all it would take is to add a config file to the /etc/zfsbootmenu/dracut.conf.d/ folder declaring the variable and a conf file to add the banner file to the container.

Would you support that approach?

[ahesford]

If done right, I'd accept changes to dracut-crypt-ssh to allow custom arguments, but that is independent of this project.

[Sithuk]

Does the container build system have an equivalent to the generate-zbm front end? Or must the user run the zbm-builder.sh or remote-ssh-build.sh scripts to regenerate the zbm initrd?

[ahesford]

zbm-builder.sh *is the front end.

[Sithuk]

I've pushed the updates to the script. I'm using your remote-ssh-build.sh script. Thank you for writing it. Are there any plans to remove it?
I've modified the script to delete the build_dir/dropbear/authorized_keys file at the start of each run. Otherwise the existence of an authorized_keys file in the dropbear folder stops the authorized_keys file from being refreshed from the user's file. So if the user adds a new key and re-runs the script, the authorized_keys file doesn't get updated. That looks like it might be as designed though?
https://github.com/Sithuk/ubuntu-server-zfsbootmenu/blob/main/ubuntu_server_encrypted_root_zfs.sh#L1496