I fought with this for a solid day too. It turns out that the subiquity autoinstall config file is NOT a cloud-init file and will not be processed by cloud-init, so the documentation you referenced is not the correct place to look.
This is breathtakingly confusing, since the autoinstall config is very close to a subset of cloud-init. It's even more confusing because subiquity uses cloud-init to find its config file, and there's even a module called "cc_ubuntu_autoinstall" in cloud-init, which as far as I can tell does almost nothing and is mostly there so that cloud-init doesn't choke on the top-level "autoinstall:" key in the file. And it's even MORE confusing because the autoinstall documentation I linked above doesn't even mention the required top-level "autoinstall:" field - that's only documented in an off-hand comment as part of the introductory page (https://ubuntu.com/server/docs/install/autoinstall) - so as documented it looks like it IS the same as cloud-init. Sigh.
I was unable to find any way to do this "right" with autoinstall. There's no hook in the process that lets you create the key files in an appropriate location such that the apt: block will be able to use them. I ultimately gave up and used the documented arrangement, which uses the deprecated approach of loading the keys globally. This ticket could be re-construed as an enhancement request to make subiquity support the same feature that cloud-init already does.
FYI, you can actually do two different things to get the cloud-init implementation of apt: to consume your config, but unfortunately neither of them work in the context of an autoinstall. First, you can put the apt: and packages: keys at the top-level of the config file (siblings to autoinstall:). Secondly, you can put a user-data: key under autoinstall: and then put any cloud-init keys under that. However, through experimentation, I can say that those end up being executed at wrong times during the autoinstall process, so neither works. But it might be useful for some other tasks.
I fought with this for a solid day too. It turns out that the subiquity autoinstall config file is NOT a cloud-init file and will not be processed by cloud-init, so the documentation you referenced is not the correct place to look.
The autoinstall config file is documented here: https:/ /ubuntu. com/server/ docs/install/ autoinstall- reference and unfortunately the magic of $KEY_FILE is not implemented in subiquity.
This is breathtakingly confusing, since the autoinstall config is very close to a subset of cloud-init. It's even more confusing because subiquity uses cloud-init to find its config file, and there's even a module called "cc_ubuntu_ autoinstall" in cloud-init, which as far as I can tell does almost nothing and is mostly there so that cloud-init doesn't choke on the top-level "autoinstall:" key in the file. And it's even MORE confusing because the autoinstall documentation I linked above doesn't even mention the required top-level "autoinstall:" field - that's only documented in an off-hand comment as part of the introductory page (https:/ /ubuntu. com/server/ docs/install/ autoinstall) - so as documented it looks like it IS the same as cloud-init. Sigh.
I was unable to find any way to do this "right" with autoinstall. There's no hook in the process that lets you create the key files in an appropriate location such that the apt: block will be able to use them. I ultimately gave up and used the documented arrangement, which uses the deprecated approach of loading the keys globally. This ticket could be re-construed as an enhancement request to make subiquity support the same feature that cloud-init already does.
FYI, you can actually do two different things to get the cloud-init implementation of apt: to consume your config, but unfortunately neither of them work in the context of an autoinstall. First, you can put the apt: and packages: keys at the top-level of the config file (siblings to autoinstall:). Secondly, you can put a user-data: key under autoinstall: and then put any cloud-init keys under that. However, through experimentation, I can say that those end up being executed at wrong times during the autoinstall process, so neither works. But it might be useful for some other tasks.