Same here,
Three instances, all unable to reboot. Both mine refers to netlogd file not existing.
Looks like it is unable to read the ZFS datastore.
Can you share the netlogd error?
For the ZFS side, does your system have secureboot disabled?
ERROR open /etc/systemd/netlogd.conf: no such file or directory
System is fully trusted (TPM2 & SecureBoot)
Likely caused by the cleanup logic in Cleanup rootfs from initrd by stgraber · Pull Request #1339 · lxc/incus-os · GitHub . We should probably whitelist the netlogd.conf file in that code.
What would be the best way to get them back up running for the moment ?
Easiest likely is to boot onto a live media, unlock the LUKS of the root disk with the recovery key and remove the netlogd lines from /var/lib/incus-os/state.txt.
But we could really do with a screenshot/photo of the error so we can tell when it hits as the error message on its own really doesn’t help us that much.
I think I tracked down the issue and if I’m right, it means a pretty late startup failure, basically when the service comes online, which means the system would be recoverable through RESCUE_DATA once the new image is available.
Added the netlogd fix to Various bugfixes by stgraber · Pull Request #1352 · lxc/incus-os · GitHub
Okay, so yeah, it’s failing after the emergency update hook so the system can be recovered with RESCUE_DATA once we have an update available. You’ll just need to prepare a USB stick with a VFAT partition using the RESCUE_DATA label and then put the image files on there, IncusOS will auto-apply the update when booted with that connected and you’ll be fine.
Already modified state file. Will wait for an update before adding back my netlog config
I see a 20260910… has been released, presumably with those fixes merged, how would one go about creating that RESCUE_DATA image? I’m not clear on what needs to be in the partition.
Figured it out. Seems you just need to basically wget the contents of Index of /os/202609100026/ into the RECOVERY_DATA’s update/ folder
(post deleted by author)