Thanks for your response. So you mean there’s absolutely no means to securely autoinstall Ubuntu on an encrypted volume? To be honest, I don’t quite understand the priorities here, I don’t think FDE is a negligible aspect in 2021. We don’t even allow unencrypted workstations at our company. And it’s been like this since 2016 I think. I’m not willing to put disk encryption passwords on a non-authenticated web server, where the autoinstall file resides. Nor on a thumb drive. No one should, it kinda defeats the purpose of encryption.
I’ve tried to look up early-command user input, but couldn’t find much. Do you have any pointers by any chance?
I can file bug reports, but where’s the place for that? In any case, I’m not sure all of those are bugs. It’s more of a design thing. If you designate a section as interactive, but also specify some answers for that section in the autoinstall file, there’s a conflict which autoinstall has to resolve. As of right now, autoinstall does that by simply ignoring any predefined answers for a section if it’s interactive. There’s at least 2 obvious solutions to this:
- you should be able to select single fields as interactive, not just whole sections, or
- autoinstall should pre-fill the fields specified in the autoinstall file for interactive sections
Neither happens right now. The 2nd option could be further expanded, because that one you could approach in at least 2 ways:
- you could just offer defaults which can be overridden interactively, or
- the predefined fields could be immutable so that the person doing the install could observe those values but couldn’t change them, they’d be “greyed out”.
This can be again either a design choice of autoinstall, or an option in the autoinstall file, like being able to define “soft interactive” and “hard interactive” sections, the former of which has mutable defaults and the latter immutable.
For the record, this is not limited to storage, the same happens with other sections, like identity. I do want to specify the user, because I don’t wanna risk helpdesk messing up the username and or password every now and then. But I do not want to specify the hostname, since that’s obviously machine-specific. And I can’t do that as of now. I either specify all or none of them. If I set identity interactive, my defaults are ignored completely.
It gets even worse if I need more than one user: if I specify one user in user-data/users, and also fill in the identity section with a user and hostname, the users under user-data/users are completely ignored. So in essence, you can’t specify the hostname AND have 2 users at the same time.
Not being able to interactively set hostname during install is particularly painful, because it’s too confusing to change afterwards. You can use hostnamectl set-hostname, but it’s worthless, because all it does is dump your input into /etc/hostname, but that’s not enough, you still need to manually adjust /etc/hosts too, otherwise su/sudo operations will keep throwing name resolution errors. So why bother with hostnamectl in the first place, you just substitute vi/echo/cat with a different command. You might as well just manually edit both files.