| MTecknology | dbungert: heh ... I thought this would be easier. Where does the hostname from the identity section get written to? | 00:24 |
|---|---|---|
| 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:28 |
| MTecknology | The defaults I provided aren't even valid, and it didn't seem to understand that a password was provided | 00:30 |
| 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:31 |
| dbungert | MTecknology: I'll simulate that case and get back to you | 00:32 |
| 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:33 |
| MTecknology | 20.04.6 server | 00:34 |
| 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:41 |
| MTecknology | It's like it used what I provided via autoinstall as the actual values rather than defaults | 00:42 |
| MTecknology | (but it /did/ prompt and allow me to change what was provided) | 00:44 |
| 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:50 |
| MTecknology | oh ... yeah | 00:51 |
| MTecknology | my awk command would do that | 00:51 |
| dbungert | heh, I was thinking of that as pseudocode ;) | 00:52 |
| 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:07 |
| 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:11 |
| MTecknology | (and the reboot prompt | 01:14 |
| MTecknology | ) | 01:14 |
| MTecknology | oh ... it looks like the domain needs to be passed via cloud-init params too | 01:31 |
| 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 | 02:30 |
| === chris14_ is now known as chris14 | ||
| MTecknology | patdk-lap: Apparently it's not /just/ order. I can't remove core20 from within the installer | 03:07 |
| 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. | 03:32 |
| 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:41 |
| MTecknology | dbungert: Lots of examples show cloud-init using an fqdn for the hostname; is this a bug in autoinstall? | 05:42 |
| === 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 | ||
| 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:16 |
| MTecknology | dbungert: I meant specifically the fqdn seems like an autoinstall bug. | 14:18 |
| dbungert | oh, the hostname value in identity? | 14:18 |
| 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:19 |
| MTecknology | I guess as a search value for dns, but that's not the primary interest. | 14:20 |
| 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:21 |
| 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:22 |
| 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:25 |
| 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:40 |
| MTecknology | I don't think subiquity should be writing that value directly to a file ... | 14:42 |
| MTecknology | fwiw, hostnamectl seems to "do the right thing" when I hand it the fqdn; it only writes the hostname portion to /etc/hostname. | 14:43 |
| 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:45 |
| MTecknology | It's completely fine after a restart and only starts to show up after resuming from sleep. | 15:46 |
| MTecknology | *sigh* @ "ValueError RSA key format is not supported" | 21:49 |
| 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] | 21:59 | |
| MTecknology | I'm using virtualenv with py3.8 ... I shouldn't be seeing these weird legacy problems. :/ | 22:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!