[00:24] <MTecknology> dbungert: heh ... I thought this would be easier. Where does the hostname from the identity section get written to?
[00:28] <dbungert> MTecknology: that gets funneled through cloud-init and set on first boot.  I do think it would be useful to be able to prompt separately for the hostname, but not something with an easy answer today without also showing the rest of Identity.
[00:28] <MTecknology> I see the defaults I provided in /target/etc/cloud/cloud.cfg.d/99-installer.cfg, but I don't see the hostname that was provided to the interactive section
[00:30] <MTecknology>  The defaults I provided aren't even valid, and it didn't seem to understand that a password was provided
[00:31] <MTecknology> dbungert: I'm trying to figure out how to apply the hostname via late-commands, since I won't have cloud-init on the first boot. All that I need for that is to be able to /get/ the hostname ... but I can't find the user-provided value
[00:32] <dbungert> MTecknology: I'll simulate that case and get back to you
[00:33] <dbungert> MTecknology: what iso are you using?
[00:33] <MTecknology> This is the minimal version of what I'm trying to accomplish - https://0x0.st/HFeb.txt
[00:34] <MTecknology> 20.04.6 server
[00:41] <dbungert> MTecknology: looks like my above claim is incorrect, the hostname should be written direct to /target/etc/hostname
[00:41] <MTecknology> oh.. I ended up with an empty file
[00:42] <MTecknology> It's like it used what I provided via autoinstall as the actual values rather than defaults
[00:44] <MTecknology> (but it /did/ prompt and allow me to change what was provided)
[00:50] <dbungert> MTecknology: yea, twice in a row with the amd64 20.04.6 ISO and identity interactive I can see it set the hostname in the way you want.  by chance is there anything else in late-commands that might be affecting this?  not sure otherwise
[00:51] <MTecknology> oh ... yeah
[00:51] <MTecknology> my awk command would do that
[00:52] <dbungert> heh, I was thinking of that as pseudocode ;)
[01:07] <MTecknology> dbungert: Yup, you're absolutely correct. It magically does the right thing once marked interactive and the awk command is what broke it.
[01:11] <MTecknology> dbungert: Is there any way to avoid the reboot prompt and/or disk wipe confirmation? That behavior changes once the section is marked interactive.
[01:14] <MTecknology> (and the reboot prompt
[01:14] <MTecknology> )
[01:31] <MTecknology> oh ... it looks like the domain needs to be passed via cloud-init params too
[02:30] <MTecknology> dbungert: So ... "preserve_sources_list" appears to be an option that exists, but I don't see it documnted, and it makes me wonder if that's what created sources.list.curtin.old
=== chris14_ is now known as chris14
[03:07] <MTecknology> patdk-lap: Apparently it's not /just/ order. I can't remove core20 from within the installer
[03:32] <MTecknology> curtin in-target -- snap remove --purge lxd succeeds, but trying to remove core20 afterward fails from within the installer, but running the same snap command (removal order) after a reboot is fine.
[05:41] <MTecknology> setting the domain is proving to be a lot more frustrating than I expected. I assumed I could just pass it as a boot argument or provide it with the hostname, but nope ... neither.
[05:42] <MTecknology> dbungert: Lots of examples show cloud-init using an fqdn for the hostname; is this a bug in autoinstall?
=== esembee_ is now known as esembee
=== JanC_ is now known as JanC
=== kenoba8 is now known as kenoba
=== kostkon_ is now known as kostkon
=== Poster` is now known as Poster
[14:16] <dbungert> MTecknology: bug in autoinstall> more no than yes, early boot network and fetching nocloud data happens without autoinstall being involved.  might be worth a release note though.
[14:18] <MTecknology> dbungert: I meant specifically the fqdn seems like an autoinstall bug.
[14:18] <dbungert> oh, the hostname value in identity?
[14:19] <MTecknology> Yeah, it was complaining about me trying to add a domain to that field, but I see no other place where it could be provided.
[14:20] <MTecknology> I guess as a search value for dns, but that's not the primary interest.
[14:21] <dbungert> AIUI that really should be hostname and not fqdn going to /etc/hosts, so that sounds like a doc bug if examples show otherwise
[14:22] <MTecknology> oh ... but if the fqdn were handed to cloud-init for the firstboot, it would "do the right thing"
[14:22] <MTecknology> er.. was that /etc/hosts or /etc/hostname?  Shouldn't both be in hosts?
[14:22] <MTecknology> (no domain first)
[14:25] <MTecknology> I guess I should go look at cloud-init source and try to figure out what it actually does when an fqdn is provided. Maybe it just breaks that apart into search domain anyway??
[14:25] <dbungert> both hosts and hostname are written to /target/etc by Subiquity and `man hostname` leads me to believe the fqdn version should not be going to /etc/hostname
[14:40] <MTecknology> There should be a distinction between fqdn and hostname, and it seems like the ubuntu installer doesn't support that
[14:40] <MTecknology> I /should/ be able to install a system that winds up with "hostname -f" presenting the fqdn, but I don't see any way do do that other than run a hostnamectl command at the end of installation
[14:42] <MTecknology> I don't think subiquity should be writing that value directly to a file ...
[14:43] <MTecknology> fwiw, hostnamectl seems to "do the right thing" when I hand it the fqdn; it only writes the hostname portion to /etc/hostname.
[15:45] <MTecknology> I'm starting to see this behavior more and more often, where *anything* I do involving disk is absurdly slow/laggy and it doesn't recovery until I restart the computer. It's still "usable," but also very painful. It's almost like swap didn't turn back on and I'm exclusively using swap space.
[15:46] <MTecknology> It's completely fine after a restart and only starts to show up after resuming from sleep.
[21:49] <MTecknology> *sigh* @ "ValueError RSA key format is not supported"
[21:59] <MTecknology> Apparently I'm running into this old issue -> https://github.com/saltstack/salt/issues/40889#issuecomment-297590224
[21:59] -ubottu:#ubuntu-server- Issue 40889 in saltstack/salt "salt-master 2016.11.4 crashes on CentOS 7 with error 'RSA key format is not supported'" [Closed]
[22:18] <MTecknology> I'm using virtualenv with py3.8 ... I shouldn't be seeing these weird legacy problems. :/