stgraber@castiana:~$ incus exec test-d13 -- dmesg | grep -i secure
[ 0.000000] Kernel is locked down from EFI Secure Boot; see man kernel_lockdown.7
[ 0.000000] secureboot: Secure boot enabled
[ 1.229895] integrity: Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
If it doesn’t, then your distribution either doesn’t ship a Secure Boot firmware at all, or it ships it under a name which Incus doesn’t recognize. If the latter, it’s an easy fix to the Incus code to make it work.
Feeling like sending an Incus PR to put the secureboot versions high in the generic list too? We still want generic to support cases with no secboot handling so those must stay, but it should prefer secboot enabled firmware.
Its also broken with the same error trying to run in a LXD VM with the settings advised on IncusOS docs. Ive tried messing with security.csm but that doesn’t help. Appreciated this isn’t an LXD forum anymore but I cant really understand why it would work in one and not the other (though I admit I haven’t checked for any special differences in LXD & Incus and struggle to believe there would be any)
That’s definitely odd. I’d have expected the same security.secureboot=false to work on LXD unless they’ve changed the way EDK2 is built since I’ve left…
Basically what you want is for a Secure Boot enabled kernels but not have the Microsoft keys loaded. If security.secureboot=false doesn’t achieve that, try with security.secureboot=true but then go into the firmware/BIOS menu by hitting ESC during boot and see if you can use a setting in there to put it into Setup Mode.
(sidenote: Incus docs say “requires secure boot” then your VM docs are like “disable secureboot”, im sure technically there is a difference between the two- but its somewhat confusing for the layman)
Yeah, security.secureboot controls whether the default keys (Microsoft’s) are loaded or not. So we need it set to false to give us a clean slate that we can populate with our keys (therefore preventing any other OS from being booted).
Short version, with LXD’s current firmware, you need to do the enrollment completely by hand, similar to what you have to do on a physical server.
For that, follow the Incus instructions but hit ESC early in boot so you can get in the UEFI firmware menu, then go to the Secure Boot section, select Custom mode and then import all the keys from the install media one by one.
@amikhalitsyn@tomp any idea why the UEFI firmware in LXD behaves weirdly?
Not being able to perform full key enrollment through systemd-boot seems a bit problematic
Sorry for not digging far enough, of course be super cool if that was auto-done but not Incus devs problem these days of course. Thank you for the video I’ll try this tomorrow. I expect I’ll have a php-lib up for IncusOS API this week (assuming the vid is correct, which I have 0 doubts about)
The API and CLI are both still in flux and don’t yet have the level of backward compatibility that folks have come to expect from Incus itself.
That said we’re getting pretty close and we’ve got a bunch of stuff hitting various part of the API these days, so minor changes may still happen but major re-shuffles are unlikely at this point.
I’ll be sure to add the warning and try to keep up with the changes.
Looking forward to IncusOS + TrueNas hitting stable, If you could lobby “Veeam” to integrate with LXD/Incus (“lxus” (lexus) as I like to call it), id basically die happy.
Yeah, the IncusOS + TrueNAS Scale 24.10 with the new truenas storage driver is really a nice combo for quickly building clusters with flexible storage.
For Veeam, I’ve not looked into it too closely directly but at FuturFusion we’ve been dealing with quite a lot of different backup and disaster recovery solutions. It’s a market that’s kinda overcrowded these days to the point where I don’t think we have two customers using the same solution right now…
This makes it basically impractical to spend significant resources on any one of them right now to get perfect deep integration with them. So we’ve mostly been dealing with one-off API bridges, basically a script that can talk to both the Incus backup API and to the backup system.
I see that Veeam has support for providing a backed up S3 endpoint. That’d be the first thing I’d try to play with as Incus’ backup API supports backing up to an S3 compatible bucket. If that works, then all you really need is something telling Incus to backup each instance to that S3 bucket, then let the backup system handle the retention of that data.
Again, it’s not the ideal deep integration we’d love to see, but until we have a bunch of customers all using the same platform, it’s hard to spend the engineering time needed for deep integration, whether on our end or on the backup solution provider’s end.
(And unlike other pieces of our stack where folks are happy to use whatever we recommend, backup systems are usually pretty set in stone, so we can’t just tell everyone to switch to a particular one)
Ah and I know that at least @bensmrs has been looking at improving the snapshot and backup features of Incus. We’ve been exchanging some ideas of what can be done to get better retention policies for snapshots and then looking at how to have those snapshots get synced externally to another Incus system.
That’s a bit different from full on backups (where the target system isn’t Incus) but it’s another piece of the puzzle towards improving the data safety and disaster recovery story.
Its a nice feature but I’m really after the integration with tape backups (yes physical tapes), Veeam is quite a nice backup solution covering quite alot of eventualities. I understand is heavily used with VMware but you’ll have far wider exposure than me so I might have just been sold by a sales person.
Totally get it, its supports promox right now - and Incus support ZFS delegation, it might be hackable, but I’m speculating, maybe I’ll find some time to try and bodge it (though I think I need special licenses).
I know you wont want to be seen to recomenend anything and I fully expect the answer to this to be “wait and see ” but… Any standouts so far? I’ve nearly worked out my migration path form VMware for everything except backups, I have to point at “LXDMosaic” but its just more “I wrote it” which isn’t suitable for large environments.
” but… Any standouts so far? I’ve nearly worked out my migration path form VMware for everything except backups, I have to point at “LXDMosaic” but its just more “I wrote it” which isn’t suitable for large environments.