[07:29] Good morning [11:30] DemomanCA: explain the details of your issue here please [11:31] DemomanCA: also idle & patient a bit, as volunteers might still wakeup at this time [11:32] Thanks lotuspsychje, so I have a fresh 18.04 install, 2 network interfaces together in an LACP bond. Interface works fine on boot, grabs IPv4 and IPv6 address from my DHCP server, all good. However, any time systemd-networkd restarts, the network stops working. Main causes are systemd updates or if I change a config and run sudo netplan apply. No idea where to start troubleshooting [11:32] this.... [17:21] Anyone is using OpenID,SAML for login to Ubuntu ? [19:03] Changed /etc/hostname, and entries in /etc/hosts and still cant get ubuntu server to change its hostname. what am I missing? [19:04] dhcp [19:05] its statically set [19:05] which ubuntu release is it? [19:05] 18.04.1 [19:05] does "hostnamectl status" report what you expect it to report? [19:06] Static hostname is correct, transient hostname shows old one? [19:07] did a hostnamectl set-hostname, gonna reboot see if it sticks this time [19:07] i would quote the man page but it's a bit long [19:08] and it reverted again [19:10] hmm, how did you install? [19:10] did you edit /etc/cloud/cloud.cfg and make sure yo uset preserve_hostname from 'false' to 'true'? [19:12] if you used the live installer it might do evil things like this if you reboot and revert the hostnames after you make changes [19:13] i did live installer, but preserve_hostname is set to false [19:14] set it to true [19:14] it should now stick [19:14] OHhh i see [19:14] man things have changed for ubuntu server since the last time i used it [19:15] cloud-init is an annoying piece of [CENSORED REDACTED CENSORED] and if that file is present in the install it can cause headaches [19:15] nah it's a subiquity / live installer ISO headache [19:15] if you use the alternate installer it still works as normal [19:15] yeah had to fix the damn sources too [19:15] though you still need to hostnamectl and such [19:16] Ahhh that did it [19:16] thank god, i was about to switch back to fedora server lol [19:18] teward, have you filed a bug against subiquity for this behavior? [19:18] powersj: IIRC this is known cloud-init behavior [19:18] not subiquity [19:19] that doesn't mean subiquity is doing the right thing [19:19] true, but i haven't filed a bug yet, no. [19:19] E:TOOBUSY [19:20] powersj: also, since I use a modified 18.04.1 template to deploy all my servers, or I'm doing per-system manual installs, or installs that're LXD container based... I don't have the issue anymore [19:20] so i've never gotten around to it :P [19:28] powersj: assuming I don't forget, should I file a bug against cloud-init or subiquity in this case? [19:28] because it sounds like subiquity needs to adjust the cloud config but doesn't. [19:28] and I haven't tested the 18.10 or 19.04 dailies yet to see if they exhibit the same behavior [19:30] teward, I'd say start with subiquity [19:30] ack [19:30] powersj: would i have to do that from a live session or would filing from my 18.04 install suffice? [19:30] at least for the `ubuntu-bug` stuff [19:30] your install is fine [19:32] oh... that's unusual [19:32] $ ubuntu-bug subiquity [19:32] dpkg-query: no packages found matching subiquity [19:32] :| [19:33] guess i'll do it manually then [19:37] powersj: https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1809155 <-- [19:37] Launchpad bug 1809155 in subiquity (Ubuntu) "subiquity in 18.04.1 via cloud-init doesn't set hostname persistence" [Undecided,New] [19:38] teward, thanks! [19:39] ... Anyone know where I can find auth.log or like, anything else? [19:39] my /var/log is uncomfortably empty [19:41] did you happen to mount other filesystems over it? [19:41] or are you currently 'in' a namespace without populated directory? [19:41] No, it's a brand new system [19:41] There are files *in* /var/log, just not auth.log, syslog or kern.log [19:42] powersj: five monopoly bucks says it's a cloudinit headache problem :P [19:43] Should probably mention that this is OVH's 16.04 ARM template [19:43] Which is already stupid annoying to begin with as it's missing some very basic packages [19:43] but I can't imagine why they'd have taken out logging [19:47] hdn't ovh signed this agreement not to modify ubuntu images? [19:47] I'm missing quite a few things by the looks of it, TBH [19:48] I was able to read the sshd logs with journalctl but that's not really a replacement (IMO) for auth.log [19:48] I'm gonna send in a ticket asking them 'the hell they're doing [19:49] there used to be this https://www.reddit.com/r/linux/comments/4ov74y/ovh_founder_on_twitter_canonical_is_attempting_to/ [19:49] tomreyn: did they? Was that enforced with Canonical Legal? [19:49] if it was we can go bash OVH with a hammer... :P [19:49] i don't remember the final outcome, but have a hunch they agreed to the terms in the end. [19:50] https://www.irccloud.com/pastebin/TUpJsg4e/ [19:50] for anyone curious though there's the directory structure in /var/log [19:50] is this a VM or dedicated? [19:50] It's a dedicated server [19:51] One of their ARM servers though [19:51] and which version does lsb_release -ds report exactly? [19:51] well that's just it [19:51] lsb_release doesn't work [19:51] /etc/os-release $VERSION is set to 16.04 though [19:52] lsb_release doesn't work how? [19:52] doesn't say anything? isn't installed? [19:53] E:NotEnoughInfo [19:53] also: cat /etc/issue [19:53] Looks like just lsb-release isn't installed [19:53] stand by [19:54] if you could pastebin /etc/os-release that's be nice, too [19:54] Ubuntu 16.04 LTS [19:55] so it's 16.04.0 apparently [19:55] https://www.irccloud.com/pastebin/1IWduBTP/ [19:55] it is :-( [19:55] i suspect there may be no syslogging daemon installed, thus no /var/log/syslog === techmagus_ is now known as techmagus [20:32] tomreyn: that's exactly it [20:32] rsyslog is not installed [20:33] It just seems, if OVH was going for a minimal image to use on these servers, that's probably the one thing I wouldn't have left out of the image, you know [20:37] so ¯\_(ツ)_/¯ [20:37] issue fixed [20:47] NyanCat: you might want to install updates, though, since you must be lacking a lot. [20:47] that's the other screwy thing [20:47] there's nothing available [20:47] it'd be nice to see your apt-cache policy (after apt-get update) [20:48] https://www.irccloud.com/pastebin/T4mM5IDb/ [20:51] no security patches for you [20:51] nor any updates [20:52] well, it's not like i needed security, it's not paramount or anything, right??? [20:52] ....*nervous laugh* [20:52] NyanCat: i'm sure your host can provide a qualified statement on this. [20:53] lol [20:53] OVH and qualified in the same sentence [20:54] Worth a shot, but sending a trouble ticket to OVH is like giving a kid $5 to go get bread and expecting them to come back with bread [20:54] in the past it's been common for hosters (i've seen several do so) running arm systems to fix the kernel image to the image they shipped, for whihc no sources were available. [20:54] that's because upgrading them is not neccessarily flawless, and if they break repairing cantake more time. [20:55] and if you decide to stick to a certain kernel image you may want to keep the user space the same, too, i guess. so maybe this is what you'Re seeing. [20:56] is it a good idea to do this, and connect this to the internet? definitely no. [20:56] I'm running "vanilla" according to them [20:56] When you image the server one of the advanced configuration options is to use the distribution or vanilla kernel [20:56] cat /proc/version should tell [20:57] ..... no way [20:57] I'll send you a message for this one, it does reveal IPs [21:00] NyanCat: the FQDN in the kernel string just reveals the hostname of the system this kernel was built on. [21:04] So it's purely coincidental that the FQDN happens to resolve to an IP in the same subnet as my server [21:04] I suppose, if that particular block was reserved for their ARM servers [21:06] i don't know how they do IPAM, there is #ovh, maybe someone knows there, but i doubt they'll disclose it. [21:43] teward: thanks for filing that bug [23:48] hmm so i installed ubuntu server 18.04LTS and it seems (correct me if I'm wrong) that 3rd party repositories are disabled? [23:48] if so how do i enable them [23:49] add files to /etc/apt/sources.list.d/ as you decide you want them [23:50] maddawg2: you expected some third party repos to be enabled by default? [23:51] umm no i added them but for whatever reason apt-get is providing me errors now that were not existing in 16.04 [23:51] i think maybe i found the reason [23:51] universe repository is disabled i think by default [23:51] ah that [23:51] it was unable to grab dependencies [23:51] that's fixed in the latest iso btw [23:51] ah [23:52] good to know.. i downloaded this one maybe 6 months ago but never got around to upgrading my server [23:52] http://releases.ubuntu.com/18.04.1.0/ [23:53] hm the ISO i have is labeled: ubuntu-18.04.1-live-server-amd64.iso [23:54] that not the same as 18.04.1.0? [23:54] file names will be the same [23:54] checksums will differ [23:54] actually i'm wrong, sorry [23:55] the updated ISOs seem to be named ubuntu-18.04.1.0-live-server-amd64.iso (extra ".0") [23:57] i wonder why it wasnt there to begin with tbh [23:58] seems like a big oversight... makes me wonder wehat else is borked :-P [23:58] an apt update && apt upgrade will show you the rest :) [23:59] maddawg2: if you would like a similar result to what the old (debian) installers provided, then use the 'alternative' (non-'live') server installer