[00:00] <ahasenack> what do you have in /var/log/mysql* ?
[00:00] <tomreyn> when you last asked the same question in #ubuntu it was suggested you take a look at https://dev.mysql.com/doc/refman/5.5/en/problems-connecting.html
[00:00] <supercool> I tried to find this file /var/run/mysqld/mysqld.sock and it doesn´t exist
[00:00] <ahasenack> that's because the server isn't running
[00:00] <supercool> I did create it and change permission but when I restart mysql it cleans up the file
[00:01] <ahasenack> it's not just a missing file, that's a unix socket
[00:01] <ahasenack> it's one way mysql clients can talk to the server
[00:01] <ahasenack> your problem is before that
[00:02] <supercool> tomreyn: I had my irc client set to not receive channel massages I guess
[00:03] <supercool> I was receiving some spam and I needed to set my client and I think I changes something wrong
[00:04] <supercool> ahasenack: I have error.log but nothing inportant on it and it won´t change in restart
[00:05] <supercool> ahasenack: if you think it can help I can paste it somewhere
[00:05] <ahasenack> what about "sudo systemctl status mysql"?
[00:06] <tomreyn> supercool: ok
[00:06] <tomreyn> you should probably post my.cnf and package information on the mysql server used, too
[00:07] <supercool> ahasenack: service mysql status == "* MySQL is stopped."
[00:07] <ahasenack> supercool: there is usually more
[00:07] <ahasenack> supercool: how about this
[00:07] <ahasenack> sudo systemctl start mysql
[00:07] <ahasenack> then
[00:07] <ahasenack> sudo systemctl status mysql
[00:07] <ahasenack> and paste /var/log/mysql/error.log
[00:08] <supercool> ahasenack: I don´t have systemctl here. Can I use service instead?
[00:09] <ahasenack> supercool: what's your ubuntu release?
[00:09] <supercool> 18.04 I think
[00:09] <ahasenack> then you have systemctl
[00:09] <supercool> How do I find it?
[00:09] <tomreyn> "lsb_release -ds" reports your ubuntu version
[00:09] <ahasenack> which systemctl
[00:10] <supercool> No, I mean the ubuntu release
[00:11] <tomreyn> see one line above what you read last
[00:11] <supercool> I don´t have lsb_release
[00:12] <supercool> Maybe because I install it on a docker guest
[00:12] <tomreyn> cat /etc/issue
[00:12] <ahasenack> and that might be related to your mysql problem
[00:13]  * ahasenack -> bed
[00:13] <ahasenack> good luck
[00:13] <supercool> ahasenack: thank you!
[00:14] <supercool> Ubuntu 18.04 LTS \n \l
[00:14] <supercool> tomreyn: thank you!
[00:14] <tomreyn> so it's not fully up to date.
[00:15] <tomreyn> install all pending updates, see if this helps
[00:15] <supercool> bash: systemctl: command not found
[00:15] <tomreyn> well, your system is not properly installed
[00:15] <tomreyn> how did you install it?
[00:16] <supercool> I used docker
[00:17] <supercool> the command was apt-get update
[00:17] <supercool> I think I need a apt-get upgrade there
[00:18] <supercool> Do you want to see the Dockerfile used to generate the image?
[00:18] <tomreyn> "i used docker" as a response to the question "how did you install [Ubuntu]" is like saying "i use a computer" in response to the question of how you installed your OS.
[00:18] <supercool> tomreyn: sorry, I don´t understand your question then.
[00:19] <supercool> What do you want to know with how did you install it?
[00:19] <tomreyn> well docker is not only but mostly an einvironment where something can operate in. it doesn't explain how the stuff that operates in it is setup.
[00:20] <tomreyn> okay, show the dockerfile
[00:20] <supercool> Docker has a Ubuntu repository with a installer image. I did build a image of it on my computer
[00:21] <tomreyn> were there any errors when you built it?
[00:21] <supercool> Man, sorry. Docker has a repository with the official Ubuntu-server image on it.
[00:21] <supercool> You just use it to remote install it on your computer.
[00:21] <tomreyn> what you have there is not a proper 18.04 installation, i'm surprised it boots at all.
[00:22] <supercool> I think it is a very basic install made just to boot
[00:22] <supercool> Then you add apt as you wish
[00:22] <supercool> This is the idea
[00:23] <tomreyn> can you run "dpkg -l 'systemd*'" on this docker iinstance?
[00:23] <supercool> yes, it is possible
[00:24] <supercool> Could you point me a paste bin where I can put it to you please?
[00:24] <tomreyn> okay, it should generate some output, tell me the lines which start with 'ii'
[00:24] <tomreyn> !paste
[00:25] <supercool> Here we go: https://paste.ubuntu.com/p/4wfNJSxqzq/
[00:25] <supercool> I don´t think that was useful at all
[00:26] <tomreyn> okay, so that's ubuntu 18.04 without systemd. not a proper installation. i can't help you with this.
[00:26] <supercool> I can install systemd if you wish
[00:27] <tomreyn> that's not the point. neither ubuntu desktop nor ubuntu server would look like this after installation. i do not know what this system is, but it is not something i am into, and so i cannot help you with it.
[00:27] <supercool> https://paste.ubuntu.com/p/FXkYSsFD4Q/
[00:28] <tomreyn> yes, that's what it would normally look like
[00:28] <supercool> o/
[00:28] <tomreyn> i can help you install mysql on an ubuntu server installation, but that's not what you have there.
[00:28] <tomreyn> maybe it's ubuntu core or something, i have no experience with this.
[00:29] <supercool> Well if there is any tool not present I can go installing it
[00:29] <supercool> Untill we figure whats goin on
[00:29] <supercool> until*
[00:29] <tomreyn> i'm not going this route, this is just try and error, not knowing what you work with.
[00:30] <tomreyn> a waste of time on your and my part
[00:30] <supercool> Don´t fell afraid
[00:31] <supercool> We can do it
[00:31] <tomreyn> the only thing i'm afriad of is wasting more time on this. good luck!
[00:32] <supercool> Alright. Thank you anyway tomreyn!
[00:33] <tomreyn> welcome. please be sure to point out that you're experimenting with docker early in the conversation next time.
[00:36] <supercool> tomreyn: Ok.
[04:49] <cpaelzer> good morning
[04:54] <cpaelzer> ahasenack: 3:38 my time the importer completed the catch up
[05:12] <CarlenWhite> MSSQL is being really fickle tonight and I'm just considering just throwing it into a VM and never think about it again.
[05:13] <CarlenWhite> Really hates ZFS with a burning passion.
[05:13] <CarlenWhite> So might as well bubblewrap it inside a VM and avoid that trouble.
[05:57] <lordievader> Good morning
[07:00] <CarlenWhite> I was about to send an message mentioning that another server is going to have to handle requests for something and they might need to change settings. And then realized 'Oh I could just forward the port to the other server and no one has to do anything'
[07:00] <CarlenWhite> Yay for...laziness.
[07:00] <CarlenWhite> Or something.
[08:35] <twb> debian-security-support exists in ubuntu, but I'm pretty sure it's useless.  Is that right?  Is there an Ubuntu equivalent?  (I think it used to be called update-manager-core back in 2012)
[08:36] <twb> update-manager-core is already installed on this host, so I'll call that "good enough" for today.
[09:05] <twb> Hrm, why does unattended-upgrades in Ubuntu 16.04 still default to only Debian origins?
[09:05] <twb> Origins-Pattern "origin=Debian,codename=${distro_codename},label=Debian-Security";
[09:06] <twb> That's what dpkg-configure says, but "apt-config dump" disagrees....
[09:24] <TvL2386> so how do you configure a dummy0 interface on ubuntu server 18.04 using netplan
[09:25] <TvL2386> not only configure, but create as well
[09:25] <twb> TvL2386: I'm not familiar with netplan.  Have you already tried the obvious - check /usr/share/doc/netplan, man netplan ?
[09:25] <TvL2386> yep
[09:26] <TvL2386> It seems there's no such feature at the moment
[09:26] <TvL2386> https://bugs.launchpad.net/netplan/+bug/1774203
[09:26] <twb> the netplan I see in Debian seems to be for people doing finger(1) at MIT in 1987
[09:26] <TvL2386> meh....
[09:27] <TvL2386> what do you mean twb?
[09:28] <twb> Ahhh, http://bugs.debian.org/882661
[09:28] <TvL2386> I'm not really a fan of netplan
[09:28] <twb> cf. https://manpages.debian.org/netplan
[09:29] <TvL2386> oh lol :)
[09:29] <twb> Grr, manpages.ubuntu.com doesn't do TLS, and requires javascript or something
[09:30] <twb> Here we go: http://manpages.ubuntu.com/manpages/bionic/en/man8/netplan.8.html
[09:30] <TvL2386> so far my experience with netplan: pre/post hooks are not implemented and the workarounds are not working, bonding interfaces aren't removed when you remove them from your yaml file, dummy is not available
[09:30] <twb> Oops that's still the silly one
[09:31] <TvL2386> is there a way to revert to /etc/network/interfaces?
[09:31] <twb> TvL2386: could you use some other implementation to get the same effect?
[09:31] <twb> I am normally a Debian weenie who happens to be fighting an Ubuntu server today, so I dunno
[09:32] <TvL2386> hehehe :)
[09:32] <twb> But about 10 years ago, the important parts were "ifupdown" package and a udev rule to call net.agent
[09:32] <twb> Also, systemd-networkd or network-manager can (partly) replace interfaces(5), so those might be options for you
[09:33] <TvL2386> It's just a bit frustrating that all these things worked perfectly in 16.04 and it seems like netplan isn't mature yet
[09:33] <TvL2386> yet /etc/network/interfaces is deprecated and not working anymore
[09:33] <twb> I 100% commiserate; I had similar grief with upstart in 10.04
[09:34] <TvL2386> yeah as per your bugs.debian link: netplan generates backend files in /run and hands it of the the network daemon. Which seems to be networkd on 18.04
[09:35] <TvL2386> so I gotta check if I can make my own persistent "backend files"
[09:35] <twb> oh!
[09:35] <twb> TvL2386: if you run "networkctl" does it say unmanaged?
[09:36] <TvL2386> for this particular test I created a shell script to manually conffigure stuff via root cron using @reboot :)
[09:36] <TvL2386> checking
[09:36] <twb> If netplan is writing systemd-networkd config in /run, then the answer is simply that you can write your own systemd-networkd config in /etc/systemd/network
[09:36] <twb> I don't know if that supports dummyN but it's a place to start
[09:37] <TvL2386> it only says "unanaged" for interfaces not refered in my /etc/netplan/01-netcfg.yaml
[09:37] <TvL2386> ha :)
[09:37] <trippeh_> it does
[09:37] <twb> yay
[09:37] <TvL2386> thx twb, that gives me some nice pointers to continue
[09:37] <twb> the systemd index is "man systemd.directives"
[09:38] <trippeh_> man systemd.netdev and systemd.network should have all the relevant parts
[09:38] <twb> You can also ask #systemd (must be registered nick).  If systemd actually supports what you want to do, they will help.  If systemd doesn't do it, they'll try to trick you.
[09:39] <TvL2386> nice, I see now what it does! My yaml config is used in /run/systemd/network/10-netplan-ens1f0.network
[09:39] <TvL2386> among other nics
[09:39] <TvL2386> hahaha twb
[09:39] <TvL2386> thx trippeh_
[09:40] <TvL2386> SUPPORTED NETDEV KINDS
[09:40] <TvL2386>        âdummy     â A dummy device drops all packets sent to it.       â
[09:40] <TvL2386> `man systemd.netdev`
[09:40] <twb> cool
[09:40] <TvL2386>        Table 1. Supported kinds of virtual network devices
[09:40] <TvL2386> long list :D
[09:40] <twb> what's the use case for that?
[09:40] <TvL2386> vxlan... nice :)
[09:40] <twb> as opposed to just rp_filter and blackhole routes?
[09:41] <TvL2386> well... if you wanna know: I am testing ECMP. Got a ubuntu 18.04 server which needs a loopback ip address (not ^127.*)
[09:41] <TvL2386> and I wanted to add it to a dummy nic
[09:41] <twb> ip address add 4.3.2.1 dev lo
[09:41] <TvL2386> yeah yeah...
[09:41] <TvL2386> I want dummy!
[09:41] <TvL2386> ;)
[09:42] <twb> fair enough, I'm just trying to understand why, for my own benefit
[09:42] <TvL2386> because I thought it was easy
[09:42] <twb> haha
[09:42] <TvL2386> and the "lo" interface is magically configured
[09:42] <TvL2386> it has 127.0.0.1/8, though no netplan config
[09:43] <twb> yeah I don't know where "ip address add 172.18.77.1/22 dev lo brd +" would go in systemd-networkd
[09:43] <twb> the only obvious difference is that if you did that you'd get back ICMP responses instead of just nothing
[09:43] <TvL2386> I get that line until the "brd +"
[09:43] <TvL2386> broadcast +?
[09:43] <twb> brd + just  yep
[09:43] <TvL2386> what does that do?
[09:44] <TvL2386> hmmm... `grep -r 127.0.0.1 /run` does not return any hits
[09:44] <TvL2386> probably somewhere else of course
[09:44] <twb> http://ix.io/1iWJ
[09:45] <twb> if you don't brd +, there's no broadcast address set.  Only matters if you're doing broadcasty things (e.g. mdns, I guess)
[09:45] <twb> The other nice one is  "ip address add en0 192.168.1.2 peer 192.168.1.1"  if you're e.g. talking to a fresh router over a direct cable
[09:46] <TvL2386> weeeeeeeeeeiiiiiiiiiirrrrdddddd
[09:46] <twb> #netfilter can talk to you about that stuff if you care
[09:47] <TvL2386> man ip-address : interesting that "peer"
[09:47] <twb> it's a plain point-to-point so you don't need any /30 crap, like we did back in the dialup days
[09:47] <TvL2386> yeah it reminds me of pppoe
[09:48] <TvL2386> alrighty... back to dummy stuff
[09:49] <TvL2386> or finding out how I can add ip addresses to interface lo using netplan
[09:49] <TvL2386> without messing with the magical 127.0.0.1/8
[09:52] <twb> TvL2386: I expect you just want to write something like printf '[Match]\nName=dummy0\n[Network]\nDHCP=yes\n' >/etc/systemd/network/fnord.network
[09:56] <TvL2386> curl https://transfer.sh/gkGih/dummy.network
[09:56] <TvL2386> something like that
[09:57] <TvL2386> just need to find out how to "start" it
[09:57] <TvL2386> did `systemctl daemon-reload`
[09:57] <twb> does daemon-reload work for networkd?
[09:58] <twb> I thought that only reloaded /etc/systemd/system
[09:58] <TvL2386> I have no idea
[09:58] <TvL2386> it was a reflex :)
[09:58] <twb> I would try restarting systemd-networkd and then look at networkctl
[09:58] <twb> or, read the manpage :-)
[09:59] <TvL2386> yeah reading at the moment
[10:03] <twb> I'm usually lazy and not in prod at that point so I just reboot the whole host
[10:05] <TvL2386> yeah same here... but I feel it's in my best interest to know how this works now that /etc/network/interfaces is deprecated
[10:06] <TvL2386> I made a dummy.netdev file that should generate the device
[10:06] <TvL2386> I made a dummy.network file that configures it
[10:06] <TvL2386> I'm looking for a way to reload networkd(?) so it "sees" this new configuration
[10:07] <TvL2386> systemctl restart systemd-networkd
[10:08] <TvL2386> yeah baby!
[10:08] <TvL2386> # networkctl list dummy0
[10:08] <TvL2386> IDX LINK             TYPE               OPERATIONAL SETUP
[10:08] <TvL2386>  18 dummy0           ether              routable    configured
[10:08] <TvL2386> ip a s dummy0 # looks good to
[10:08] <TvL2386> cool
[10:09] <TvL2386> step 2: apt-get purge netplan
[10:11] <twb> nice
[10:11] <twb> I did that to NM for the first like 4 years after it landed, because it routinely broke my *wired* connections on servers
[10:21] <TvL2386> I'm just wondering if there's a more graceful way to alter the running configuration without completely restarting systemd-networkd
[10:21] <blackflow> TvL2386: no need to purge (as that also removes some metapackages), just remove any config from /etc/netplan and it won't interfere.
[10:22] <TvL2386> true blackflow
[10:22] <TvL2386> The following packages will be REMOVED:
[10:22] <TvL2386>   netplan.io nplan ubuntu-minimal
[10:22] <twb> I assumed they wanted to remove it for the cathartic pleasure rather than any real need :-)
[10:22] <TvL2386> :)
[10:22] <blackflow> wrt reconfiguring networkd without restarting, there's this (still open):  https://github.com/systemd/systemd/issues/6654
[10:23] <twb> like when you get an old piece annoying of kit and smash it with a hammer
[10:23] <blackflow> yeah but ubuntu-minimal.... my OCD would ahve an issue with removing that :)
[10:24] <TvL2386> hehehe :)
[10:24] <TvL2386> I don't really care tbh
[10:24] <TvL2386> Don't get me wrong, I care about your OCD, just not about ubuntu-minimal :P
[10:24] <blackflow> ;)
[10:26] <blackflow> netplan sounds nice on paper but in practice... I've hissed and barked at it here so it's not my intention to do that again. Gave it a chance and after several months no I still see no purpose of it. Yeah, centralized config regardless of backend, but in my experience any abstraction (and this is abstracion) is bound to either: a) do a half-assed job, or b) become extremely complex and thus
[10:27] <blackflow> buggy, in order to satisfy all the functions of supported backends.
[10:27] <blackflow> currently netplan is in the stage a)  as it doesn't cover all the functions.
[10:31] <TvL2386> so `netplan apply` generates some .network files in /run/systemd/network and then restarts systemd-networkd
[10:31] <TvL2386> that ~3sec disruption I have on applying seems to be the same as when manually restarting systemd-networkd
[10:32] <TvL2386> I agree blackflow
[10:32] <TvL2386> that's how I experience it as well
[10:33] <TvL2386> why use netplan on ubuntu-18.04 if you can generate those .network files yourself. Have more control, less magic....
[10:33] <TvL2386> same reason why I don't use ufw...
[10:33] <blackflow> which btw is against systemd policy for generators, that are only supposed to generate unit files and symlinks.   and going against systemd policy is bound to introduce breakage in the future, as sd developers don't like to care about stuff they recommend against.
[10:34] <TvL2386> enough whining from my side though :)
[10:34] <blackflow> less is more. sometimes literally (via symlinks)   :)))
[10:54] <jamespage> cpaelzer: ok so whats the purpose of lcore and pmd threads in the context of dpdk?
[11:10] <cpaelzer> jamespage: cpus the threads will spin on
[11:11] <cpaelzer> PMD threads are the polling mode device drivers
[11:11] <cpaelzer> you want those close to the device in numa systems
[11:12] <cpaelzer> lcore you can think of the management plane a bit
[11:13] <cpaelzer> like allocation of memory, some extra tasks
[11:13] <cpaelzer> essentially all nonPMD work it does
[11:13] <cpaelzer> masks for those can be set, but you really really have to know your HW to do so correctly
[11:13] <cpaelzer> (cpu masks)
[11:14] <cpaelzer> TL;DR: lcore = DPDK-EAL-thread; pmd-thread = a thread of the poll mode drivers(s)
[11:14] <cpaelzer> jamespage: does that explain what you needed?
[11:15] <jamespage> cpaelzer: yes - I think the charm is not quite doing the right thing at the moment
[11:15] <cpaelzer> jamespage: I always liked the blog kevin wrote https://developers.redhat.com/blog/2017/06/28/ovs-dpdk-parameters-dealing-with-multi-numa/
[11:15] <jamespage> we set a lcore mask based on the number of cores to allocate basedon the numa topoligy
[11:15] <cpaelzer> maybe that can help to get things straight
[12:13] <ahasenack> good morning
[12:13] <ahasenack> cpaelzer: I think I finally got hit by the glibc pending migration. DEP8 dependencies aren't installing anymore :/
[12:14] <cpaelzer> ahasenack: do you know how to resolce or should I show you in a quick session?
[12:14] <ahasenack> cpaelzer: this is in a bileto ticket for now
[12:15] <cpaelzer> I tihnk we had that - where you called the interface ugly
[12:15] <ahasenack> cpaelzer: is the solution that horrible url mangling? :)
[12:15] <cpaelzer> well you can do the same in the bileto tests
[12:15] <ahasenack> "interface" is a compliment :)
[12:15] <cpaelzer> ahasenack: yes
[12:15] <ahasenack> https://bileto.ubuntu.com/excuses/3399/cosmic.html
[12:15] <ahasenack> alles kaput
[12:15] <ahasenack> locally I had to enable proposed (--apt-pocket=proposed)
[12:15] <ahasenack> at least then it worked
[12:16] <cpaelzer> ahasenack: well that is much easier than selective unmasking then
[12:16] <cpaelzer> you can to &all_proposed=1 (or it is a - instead of a _)
[12:16] <ahasenack> just harder to show, in the context of a merge proposal
[12:16] <ahasenack> ah, that
[12:17] <ahasenack> hm, there is no "retry" icon for sssd, just freeipa, why us that?
[12:18] <cpaelzer> link?
[12:18] <ahasenack> just above
[12:18] <ahasenack> https://bileto.ubuntu.com/excuses/3399/cosmic.html
[12:18] <cpaelzer> found it
[12:19] <cpaelzer> because always failed = ok
[12:19] <ahasenack> well, that puts me in an odd situation
[12:19] <cpaelzer> and retry is only shown in case it is not ok
[12:19] <ahasenack> since there were no dep8 tests before
[12:19] <ahasenack> I'm adding them for the first time
[12:19] <cpaelzer> once they were successful once in the archive it will reset to expect that
[12:19] <ahasenack> and there is no way to tell bileto to use cosmic-proposed for the first run?
[12:20] <cpaelzer> umm
[12:20] <cpaelzer> you might still be able to retrigger it
[12:20] <ahasenack> "target series" should include proposed
[12:20] <ahasenack> in the list, I mean
[12:20] <cpaelzer> I'm just nt sure it would pick up the updated result
[12:22] <cpaelzer> hmm, no you can't reset it ... :-/
[12:22] <ahasenack> hmpf
[12:22] <cpaelzer> "You submitted an invalid request: Package sssd does not have any test results"
[12:22] <ahasenack> bileto has the chance to be so much more
[12:22] <cpaelzer> is testing locally ok?
[12:22] <ahasenack> yes
[12:22] <ahasenack> I'm even testing a login
[12:22] <ahasenack> but I want to add more
[12:23] <ahasenack> cpaelzer: https://git.launchpad.net/~ahasenack/ubuntu/+source/sssd/tree/debian/tests/all-ldap?h=sssd-dep8-tests
[12:26] <cpaelzer> smb: FYI iproute2 resolved
[12:27] <smb> cpaelzer, yay!
[12:27] <cpaelzer> 3/5 is already a much better rate
[12:27]  * cpaelzer feels bad to feel good about 3/5 success rate ?!
[12:28] <cpaelzer> xnox: I restarted dbus once more, that was the only one failing (timeouts, nothing critical)
[12:39] <cyphermox> TvL2386: blackflow: because it's a) not magic, and b) not doing anything but writing unit files (with some small exceptions for NM+wpa, but hey) and c) some people don't know the whole syntax of systemd-networkd files, whether they should use a .network, .link, .netdev, or even a .rules file to do what they want to do.
[13:02] <ahasenack> cpaelzer: https://code.launchpad.net/~ahasenack/ubuntu/+source/snapper/+git/snapper/+merge/354142 ubuntu/devel hasn't moved after the new debian/sid release was imported
[13:02] <ahasenack> cpaelzer: I guess it's a bug when dealing with sync'ed packages
[13:05] <cpaelzer> yes
[13:05] <cpaelzer> didn't you file a bug last week?
[13:05] <cpaelzer> when it came up the first time
[13:12] <cpaelzer> jamespage: you might help me on an ambiguity as well
[13:12] <cpaelzer> I can separate bweteen OVS and ovsdb
[13:12] <cpaelzer> but those two /lib/systemd/system/openvswitch-switch.service /lib/systemd/system/ovs-vswitchd.service
[13:13] <cpaelzer> it seems in the past I used the former but now have to use the latter
[13:13] <jamespage> I did some work for bionic to switch to a more native aapproach
[13:13] <jamespage> now you have ovsdb-server and ovs-vswitchd which are both part of openvswitch-switch
[13:13] <jamespage> so restarting openvswitch-switch on old or new will dtrt
[13:14] <jamespage> cpaelzer: ^^
[13:14] <cpaelzer> ok'ish
[13:14] <cpaelzer> thanks
[13:14] <cpaelzer> that explains what happened but now I'm back at my error
[13:14] <cpaelzer> :-)
[13:16] <cpaelzer> jamespage: now knowing this let me try to re-catch my issue
[13:22] <jamespage> coreycb: bah we have an upgrade issue on the nova-common/python-nova twiddles from queens to rocky
[13:25] <cpaelzer> ahasenack: reading your MP update - should I sponsor snapper?
[13:25] <cpaelzer> it really LGTM
[13:25] <ahasenack> cpaelzer: yes please
[13:25] <cpaelzer> and I see you can't
[13:25] <cpaelzer> thought MOTU would be wih you already
[13:25] <ahasenack> I also tried it on my arm "box", worked just fine
[13:25] <cpaelzer> isn't that MOTU
[13:25] <ahasenack> even though that one isn't armhf, it's armvl7 or something
[13:25] <ahasenack> I'm not motu :(
[13:25] <ahasenack> I'm.... andreas!
[13:25] <cpaelzer> grml, you should be all of that by now
[13:25] <ahasenack> I'm trying
[13:25] <ahasenack> the dmb agenda is out of date
[13:25] <ahasenack> I just pinged ubuntu-devel about it
[13:26] <cpaelzer> whatever it is, edit yourself in - maybe add a section "since below is out of date extra topics: -..."
[13:26] <cpaelzer> I was punted by being shy as well, it was out of date and when it was back three other topics got in front of me
[13:27] <cpaelzer> ahasenack: as a verification - a0e4e65631d63fe4fcf6b5938b2dc649f5f2a00f ?
[13:27] <ahasenack> ok
[13:27] <ahasenack> let me check
[13:27] <ahasenack> hm, no
[13:27] <ahasenack> let me see what is in lp
[13:28] <ahasenack> I might have pushed from my container
[13:28] <ahasenack> checking
[13:28] <cpaelzer> a0e4e65 is on your remote
[13:28] <cpaelzer> at least from my POV
[13:29] <cpaelzer> but good that we check, let me know what you find
[13:29] <ahasenack> sure
[13:29] <coreycb> jamespage: ok need a hand?
[13:29] <ahasenack> mine has debian/sid updated pointing at 0.5.6-2, the lp mp is against ubuntu/devel
[13:29] <coreycb> jamespage: was just trying to figure out the horizon build failure in cosmic
[13:30] <ahasenack> c'mon git pull
[13:30]  * ahasenack waits
[13:30] <coreycb> jamespage: kind of odd LP doesn't show the build log
[13:30] <jamespage> coreycb: some other failure hit retry
[13:30] <coreycb> jamespage: ok
[13:33] <ahasenack> cpaelzer: ah, I had updated dep3's last-update
[13:33] <jamespage> coreycb: missing breaks/replaces
[13:34] <coreycb> jamespage: ah, that'll do it
[13:34] <ahasenack> will fix and ping you
[13:36] <cpaelzer> ok
[13:39] <raidghost> When SYSTEM is running. Ethernet card is frozen, But the system still running. Connected to monitor with hdmi, ifup shows the card is up. lshw -c network shows the enp is correct. route -n shows the routes are okey. But why does the ethernet card then not respond?
[13:39] <raidghost> Running 18.04 Server LTS
[13:39] <coreycb> jamespage: neutron did not get an update for python(3)-neutron -> neutron-common. think i should do that now and consolidate *.install into neutron-common.install?
[13:40] <Ussat> what do you mean the ethernet card is frozen ?
[13:40] <Ussat> How do you mean the ethernet card does not respond.
[13:40] <raidghost> Ussat: It SUDDENTLY stop responding
[13:41] <raidghost> after some days running
[13:41] <Ussat> OK, assume I have no idea what youre talking about, responds HOW ? what do you expect....how is it not "responding"
[13:41] <raidghost> its a onboard ethernet card
[13:42] <Ussat> Loose its IP ? can ping ? I am confused here
[13:42] <raidghost> I cant go on internet, cant access it localy on my network
[13:42] <raidghost> not losen ip. i cant ping.
[13:42] <raidghost> it looks the same way as when it was suppose to work propperly
[13:42] <raidghost> example: when i try to ping my gateway (Fibermodem) i get Destination host unreachable
[13:43] <raidghost> When i try to ping my server inside/outside the network i get the same message from my laptop connected to my network
[13:43] <Ussat> do you still have a default route ?
[13:43] <raidghost> yes
[13:44] <Ussat> ifconfig still shows IP etc ?
[13:44] <raidghost> yes
[13:44] <Ussat> this is a laptop ?
[13:45] <raidghost> No. its not a laptop. its a high tower desktop computer set as server
[13:46] <Ussat> hmm...well, have a meeting in 10 mins need to go to....will be back in a hr...sorry
[13:46] <raidghost> its a MSI Z270 Gaming m3 (MS-7A62) mainboard
[13:49] <raidghost> https://ubuntuforums.org/showthread.php?t=2381674
[13:58] <ahasenack> cpaelzer: a0e4e65631d63fe4fcf6b5938b2dc649f5f2a00f is correct, my local change is irrelevant
[14:02] <cpaelzer> ok ahasenack
[14:03] <cpaelzer> also the debdiff looks equal to the last MP I reviewed
[14:04] <cpaelzer> ahasenack: uploaded
[14:04] <ahasenack> thx
[14:19] <jamespage> coreycb: ok but make sure you pull before you do - just uploaded a fix for the metadata/ssl/san/ipaddress cells v2 issue gnuoy has
[14:20] <jamespage> cpaelzer: bearing in mind you have to enable dpdk in later ovs versions, do we need to have a separate -dpdk package any longer?
[14:20] <jamespage> or can we just bake this into the standard binaries
[14:20] <coreycb> jamespage: ok
[14:21] <cpaelzer> jamespage: you wanted to keep it split to avoid regressions into "normal" OVS
[14:21] <cpaelzer> but ack, given that we enable it it is much safer today
[14:21] <jamespage> cpaelzer: earlier versions enabled dpdk blindly
[14:21] <cpaelzer> you might remove it in an early 19.04 upload maybe
[14:22] <jamespage> i.e. use the dpdk built binary, get the features
[14:22] <jamespage> cpaelzer: ack I think that's an idea
[14:22] <jamespage> cpaelzer: my only concern is whether it effects the CPU baseline for the binaries
[14:23] <cpaelzer> I can't promise that on the initial .so load there isn't a little bit
[14:23] <cpaelzer> but you can test that then ina KVM with a very scarce cpu definition
[14:24] <cpaelzer> and we are two more years into ss3 being everywhere
[14:30] <JeffFromOh> Hello. I have a question about the behavior of the 'shutdown' command on Ubuntu Server LTS 14.04.5. I am trying to schedule a shutdown for 12:01 am. When I schedule it, it indicates the system will be going down in XXX minutes, but then, it never returns to the command line. Which suggests to me that the scheduled shutdown is a foreground command, and if I close the putty window, the shutdown will be cancelled?
[14:31] <ahasenack> yes
[14:31] <JeffFromOh> By way of contrast, on OpenSuse Leap 15, if I do a schedule shutdown, I am immediately returned to the command line, and I can close the putty or terminal window, and the shutdown will not be cancelled.
[14:32] <ahasenack> I don't know about this difference, but I would schedule things with "at" instead
[14:32] <JeffFromOh> Yeah, I know I can use 'at' - I've done that in the past because of this issue.
[14:32] <JeffFromOh> But, why is the shutdown command on Ubuntu 14.04 so braindead?
[14:32] <JeffFromOh> lol
[14:32] <JeffFromOh> Oh well, I'll just use 'at' to schedule it
[14:33] <JeffFromOh> Anyhow, thank you for the confirmation that if I close the putty window, my scheduled shutdown would be cancelled.
[14:34] <ahasenack> JeffFromOh: check the suse manpage, maybe they have
[14:34] <ahasenack> n/m
[14:44] <jamespage> coreycb: hmm - https://launchpadlibrarian.net/386788623/buildlog_ubuntu-cosmic-amd64.nova_2%3A18.0.0-0ubuntu3_BUILDING.txt.gz
[14:45] <jamespage> that looks like one of the python 3.7 errors you hit - but its 2.7
[14:48] <coreycb> jamespage: hmm and it just built ok on friday
[14:48] <jamespage> coreycb: indeed!
[14:49] <jamespage> and it has in the auto-backport for the UCA
[14:49]  * jamespage sihgs
[14:53] <coreycb> jamespage: i'd have to guess that's an intermittent error, though i don't recall seeing it with py2.7
[15:28] <blackflow> cyphermox: it's actually doing more than just defining unit files, it's restarting systemd-networkd, which sd is not expecting to be done by generators. the fact "it works" is at the moment until SD changes interface/api/expectations because they don't recommend generators do that
[15:29] <blackflow> cyphermox: but c) could be applied to netplan too, as seen from all the "How do I" questions. ;)
[15:29] <cyphermox> blackflow: "how do I" are inevitable, networking is complicated.
[15:29] <cyphermox> blackflow: you're showing that you don't really know how netplan works
[15:30] <cyphermox> the generator certainly doesn't restart anything.
[15:31] <coreycb> jamespage: look ok to you? would like a +1 before landing this. https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/neutron/commit/?id=bd8410aa46a3b2f1ede353125f0c43b82081867f
[15:32] <blackflow> cyphermox: I'm sorry, you're right, it doesn't restart networkd. it reloads udevd.
[15:34] <blackflow> cyphermox: and also SD expects generators to generate service unit files, not network config. so, there's a bit more of expectation violation at work, for now real benefit.
[15:35] <blackflow> *for no
[15:35] <cyphermox> network config is a unit.
[15:36] <cyphermox> anyway, it's how it is
[15:37] <cyphermox> that's not going to change, because there is no other way to do what we do dynamically. My point is, nobody is forcing you to use netplan; your criticism is welcome, but better dealt with in the form of bug reports -- we do fix bugs all the time, just like in any other project
[15:39] <ohms360> howdy folks, got some infrastructure running ubuntu 18.04 server and running into some DNS troubles when i'm trying to resolve a CNAME record from my DNS servers. Wanted a quick sanity check in case I'm missing a certain record
[15:39] <ohms360> systemd-resolved returns this when I try to resolve this.example.tld (CNAME'd to thisArecord.example2.dlt) Sep 04 15:31:43 ws1 systemd-resolved[671]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
[15:39] <ohms360> nslookup of this.example.tld results in an NXDOMAIN
[15:39] <ohms360> these are obfuscated - so I'm after pointers for a sanity check here
[15:41] <cyphermox> sounds like the config isn't really applied on your DNS server?
[15:42] <cyphermox> ohms360: you'd want to do tests first with something like dig and asking the server directly, before even going through systemd-resolved.
[15:42] <ohms360> well here's the thing - if I do a dig @dnsserver it will return the NXDOMAIN but has an answer section with the CNAME
[15:42] <cyphermox> ie. dig this.example.tld @servr.ip
[15:42] <ohms360> let me paste an output
[15:42] <ohms360> sec
[15:44] <ohms360> wait
[15:44] <ohms360> think I just spotted my weird behaviour
[15:44] <blackflow> cyphermox: well I wasn't looking for an argument, I was just discussing its usefulness (or lack thereof) with TvL2386.
[15:44] <ohms360> looks like somehow it's appending .example.tld onto the CNAME target
[15:45] <blackflow> ohms360: you forgot an end dot? it'd be great if you could paste the real zone data
[15:45] <ohms360> i should probably read my dig outputs carefully before spamming IRC... thanks for the sanity check
[15:46] <ohms360> i'll paste it obfuscated - bear with me while i search/replace
[15:46] <cyphermox> it does sound like a missing . at the end
[15:46] <cyphermox> (in the DNS server's config, mind you)
[15:47] <ohms360> source.example.tld.	IN	CNAME	cname.target.tld.
[15:47] <ohms360>  is what's in bind
[15:49] <blackflow> ohms360: two completely different domains and subdomains?
[15:49] <ohms360> yeah
[15:49] <ohms360> my answer section is looking as such: ;; ANSWER SECTION:
[15:49] <ohms360> source.example.tld. 2 IN     CNAME   cname.target.tld.example.tld.
[15:50] <ohms360> not quite sure how the example.tld. is getting appended
[15:50] <blackflow> appended to what?
[15:51] <ohms360> the answer should look like
[15:51] <blackflow> it's in your config right there, if that line is from the zone
[15:51] <ohms360> ANSWER SECTION:
 source.example.tld. 2 IN     CNAME   cname.target.tld
[15:51] <blackflow> yeah well... what's the ZONE file? please pastebin that. and if you _have_ to obfuscate, please do it consistently.
[15:54] <ohms360> https://pastebin.com/DGwUJmUF
[15:55] <ohms360> https://pastebin.com/g9JMfLyj
[15:55] <blackflow> 5 second TTLs? also your answer has that 2 before IN ... 2 seconds? not defined in this zone. have you reloaded bind after zone change?
[15:56] <JanC> looks like you might be missing a dot in the end somewhere
[15:56] <JanC> or something like that
[15:56] <cyphermox> JanC: nope. :)
[15:57] <ohms360> yes bind has been reloaded
[15:57] <blackflow> ohms360: are you querying the correct server? are they syncing among themselves, there's 3 NS listed in the zone
[15:58] <ohms360> yes
[15:58] <blackflow> because your answer contains a 2 second TTL which is not in this zone, so whichever server responded, is not the one with this config.
[15:58] <ohms360> could that not be the destination TTL?
[15:59] <blackflow> can you pastebin the whole response to dig?
[15:59] <blackflow> obfuscate if you have to... consistently.
[15:59] <blackflow> no, that's not destination TTL because it's part of the CNAME rr for source.example.tld.
[16:00] <ohms360> the real question is why would it be appending the example.tld to target.tld
[16:00] <blackflow> because that zone file is NOT the config for the server that is responding to your queries.
[16:00] <blackflow> so, please pastebin the output of dig too.
[16:00] <blackflow> (and the dig command you used, esp. @ part, so obfuscate consistently)
[16:03] <blackflow> ohms360:   also.....   dig +multi region.example1.tld. SOA    and inspect the serial number, is it correct? matching the one in your pastebin, eg.  1532588522   ?
[16:21] <kstenerud> question about uvt-kvm: When I uvt-kvm ssh into a server I created on one machine, it works. When I try on a different server, I get permission denide (publickey). Is there a configuration I need to set to make it work?
[16:22] <ohms360> blackflow, yeah so the serials didn't match up which was strange, so as a test I just tried sql1-production instead and that's giving me the behaviour i desire now, so not sure if systemd-resolve on the clients was caching an old record despite the ttl being shorter or something?
[16:22] <ohms360> the original subdomain still has issues which is strange, and I didn't spot any conflicting A records
[16:26] <blackflow> ohms360:  well, query the master NS, verify teh serial corresponds to the one in the zone. then query slaves and see if they see the adequate serial.
[16:26] <blackflow> ohms360: and those TTLs are a bit too short. not every resolver will respect those.
[16:27] <ohms360> perhaps i applied with 2s at some point and this could be how that occurred
[16:29] <blackflow> and the serial will tell you which version of the zone file is being served.
[19:23] <ahasenack> kstenerud: did you create a salsa account yet?
[19:37] <kstenerud> ahasenack: yes I've got one
[19:38] <ahasenack> good
[19:39] <kstenerud> It looks like all they've done in the past is import from upstream
[19:39] <ahasenack> you mean the logwatch package repo?
[19:39] <kstenerud> yeah
[19:39] <kstenerud> https://salsa.debian.org/debian/logwatch
[19:39] <ahasenack> can you tell if it matches what the package is atm?
[19:40] <ahasenack> checking d/changelog, for example
[19:40] <ahasenack> to fetch a debian package, you can use "pull-debian-source <pkg>"
[19:41] <kstenerud> Ubuntu us up to date with what's in debian (7.4.3+git20161207-2)
[19:41] <kstenerud> The current bugs are from after that
[19:41] <ahasenack> I mean compare the git repo in salsa with the package that is in debian
[19:42] <kstenerud> yup it's the same
[19:43] <ahasenack> ok, so at least it's in sync
[20:28] <lamont> Is it just me, or is virtualbox angry in the current bionic?
[20:32] <ahasenack> I haven't tried
[20:36]  * dpb1 wonders why lamont is using virtualbox
[20:37] <lamont> dpb1: because of reasons
[20:37] <lamont> ahasenack: if you're of a mind to try, just install virtualbox, and run it... it errors out in init for me.
[20:38] <lamont> % virtualbox
[20:38] <lamont> VirtualBox: Error -610 in supR3HardenedMainInitRuntime!
[20:38] <lamont> VirtualBox: dlopen("/usr/lib/virtualbox/VBoxRT.so",) failed: <NULL>
[20:38] <dpb1> lamont: gluton for punishment still I see?
[20:38] <dpb1> :)
[20:38] <lamont> and then suggests that reinstalling virtualbox might help (doesn't, but thanks for pretending this is windows...)
[20:39] <jerichowasahoax> >using oracle software
[20:39]  * ahasenack gets a nasty secure boot dialog
[20:40] <ahasenack> lamont: the service failed to start, I wonder if it's because of the kernel module
[20:40] <ahasenack> [25301.665651] Lockdown: Loading of unsigned modules is restricted; see man kernel_lockdown.7
[20:41] <lamont> ahasenack: that's what everything says: due to kernel module version mismatch
[20:41] <lamont> ahasenack: ah! ta
[20:41] <ahasenack> I can't reboot now I'm adraid
[20:41] <lamont> No manual entry for kernel_lockdown
[20:41] <ahasenack> right :/
[20:42] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1767971
[20:42] <dpb1> ahasenack: you bricked your box?
[20:42] <ahasenack> no
[20:42] <ahasenack> but it told me I would have to type a password the next boot if I want this module loade
[20:42] <ahasenack> d
[20:42] <dpb1> WHAT
[20:42] <dpb1> oops
[20:42] <dpb1> WAT
[20:45] <lamont> Sep  4 12:41:13 tigernut kernel: [   78.991989] PKCS#7 signature not signed with a trusted key
[20:45] <lamont> ahasenack: so... how do I turn that off, like an idiot?
[20:46] <ahasenack> lamont: secure boot is a bios setting
[20:46] <dpb1> right
[20:46] <ahasenack> that particular message is not what is blocking things, though
[20:46] <dpb1> you can also just boot into an unsigned kernel?
[20:46] <ahasenack> it's the lockdown one
[20:46] <lamont> grep -i lockdown /var/log/kern.log shows nothing
[20:46] <dpb1> lamont: 18.04?
[20:47] <ahasenack> lamont: did you get a debconf dialog during the installation of virtualbox saying something along the lines that your machine is in secure boot mode
[20:47] <lamont> Description:	Ubuntu 18.04.1 LTS
[20:47] <ahasenack> if not, then it's not what I hit here
[20:47] <ahasenack> you should be good to go then. Is the module loaded?
[20:47] <lamont> ahasenack: not that I recall
[20:48] <lamont> Loading new virtualbox-5.2.10 DKMS files...
[20:48] <lamont> Building for 4.15.0-33-generic
[20:48] <lamont> Building initial module for 4.15.0-33-generic
[20:48] <lamont> Secure Boot not enabled on this system.
[20:48] <ahasenack> ok, looking good
[20:48] <lamont> I have this file: /lib/modules/4.15.0-33-generic/kernel/ubuntu/vbox/vboxguest/vboxguest.ko
[20:49] <lamont> sudo modprobe vboxguest
[20:49] <lamont> modprobe: ERROR: could not insert 'vboxguest': No such device
[20:49] <lamont> -tigernut 322 : sudo insmod /lib/modules/4.15.0-33-generic/kernel/ubuntu/vbox/vboxsf/vboxsf.ko
[20:49] <lamont> insmod: ERROR: could not insert module /lib/modules/4.15.0-33-generic/kernel/ubuntu/vbox/vboxsf/vboxsf.ko: Unknown symbol in module
[20:49] <lamont> -tigernut 323 : sudo insmod /lib/modules/4.15.0-33-generic/kernel/ubuntu/vbox/vboxguest/vboxguest.ko
[20:49] <lamont> insmod: ERROR: could not insert module /lib/modules/4.15.0-33-generic/kernel/ubuntu/vbox/vboxguest/vboxguest.ko: No such device
[20:50] <ahasenack> I can't until I reboot
[20:50] <ahasenack> # modprobe vboxdrv
[20:50] <ahasenack> modprobe: ERROR: could not insert 'vboxdrv': Required key not available
[20:50] <lamont> ahasenack: oh well
[20:50]  * lamont fires up a xenial vm to see if it likes him any more
[20:50] <ahasenack> lamont: you were trying this on a vm?
[20:50] <ahasenack> I don't know if virtualbox works in another vm
[23:02] <michael2> hi, I keep getting 404 when running aptitude install, does anyone know whats causes this?
[23:03] <michael2> e.g. Im getting output like:
[23:03] <michael2> 2% [Working]E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/universe/f/ffmpeg/libavcodec-ffmpeg56_2.8.14-0ubuntu0.16.04.1_i386.deb: 404  Not Found [IP: 198.199.99.226 80]
[23:07] <lamont> ahasenack: virtualbox (at least with the image I'm using, requires vmx or equiv, so it throws a fit in a vm.)  OTOH, it works just fine up to that point (as in virtualbox launches) on both a current xenial and bionic machine.
[23:08] <RoyK> michael2: tried apt update?
[23:09] <RoyK> or aptitude or apt-get
[23:10] <lamont> ahasenack: or maybe it only tries to dlopen() after it determines that the flags are right... I haven't looked that far yet.
[23:10] <michael2> RoyK: will try that now (embarrassing I didn't thik of that already!)
[23:11] <lamont> ahasenack: the vm comment 3 hours ago was the first time I tried it in a vm
[23:11] <lamont> before that was on my desktop
[23:12]  * lamont really doesn't want to boot a livecd just to test current-bionic
[23:12] <lamont> but that may be a thing
[23:14] <sbeattie> michael2: aptitude update should fix it, as the version of ffmpg in xenial is now 7:2.8.15-0ubuntu0.16.04.1
[23:15] <michael2> thanks. fundamentally I don't understand what the error actually _means_ - i.e. what is going on? so I know how to fix next time?
[23:16] <michael2> oh I thought the message was 404'ing against the IP address, heeh
[23:16] <michael2> hehe. but apt is actually saying "I can't find that package"
[23:17] <michael2> does that mean ubuntu package maintainers are uploading - then later removing packages from apt repo/server?
[23:18] <lamont> it means that packages are being superseded.
[23:19] <michael2> right, but if my - outdated - local index literally can't install a package, superceded or not - that tells me - its been completely removed from the archive?
[23:20] <lamont> that's what happens when a package is superseded.  TBF, it gets a 24ish hour stay of execution, IIRC
[23:20] <lamont> the maintainers aren't removing it, the archive management code is.
[23:20] <tomreyn> this version of the package you tried to install (due to your outdated local index) was removed server-side
[23:21] <michael2> why remove it? what not just append the new package - apt will automatically select the new one anyway
[23:21] <lamont> michael2: if you really want that version, you can likely find it on launchpad in the full publishing history.
[23:21] <lamont> michael2: if you don't remove it, then you lose mirrors
[23:21] <lamont> the archive is already huge
[23:21] <michael2> lose mirrors?
[23:22] <lamont> people stop mirroring when you eat their disks
[23:22] <michael2> ah - you exceed the storage capacity of some ISP who is mirroring. ok that makes sense
[23:22] <lamont> as it sits, it's roughly a terabyte.
[23:25] <michael2> yeah people's appetite for software is insatiable - hehe
[23:26] <lamont> generally speaking, I expect that the stay of execution is around 12 hours, to let slow links finish their dist-upgrade download even when the archive is in heavy churn
[23:31] <lamont> ahasenack: confirmed: it doesn't bother to call dlopen() in the vm, so basically nothing from that test.
[23:31] <RoyK> michael2: you can use unattended-upgrades to automatically update (or upgrade) apt
[23:31] <RoyK> works well
[23:32] <michael2> I dont trust that - ever since it broke a server - I only upgrade packages manually these days
[23:32] <RoyK> then use it to automtically update apt
[23:32] <RoyK> not upgrade
[23:32] <RoyK> I've been using that for some time on several machines - it works
[23:32] <michael2> ah gotcha
[23:33] <RoyK> !unattended-upgrades
[23:33] <RoyK> dumb bot
[23:35] <lamont> michael2: if you still want to do it manually, a daily cronjob that does an "apt-get update; apt-get -dy dist-upgrade" at least makes it so that you don't have to wait for all the debs to download.
[23:35] <RoyK> lamont: no reason to reinvent the wheel - unattended-upgrades works well
[23:36] <michael2> isn't there a systemd timer setup to already do that?
[23:36] <lamont> RoyK: Agreed. I use them on several machines.  If michael2 wants to stay in the dark ages, at least there are ways to reduce the pain.
[23:36] <lamont> michael2: yeah, it's called "unattended upgrades"
[23:36] <michael2> I prefer to live in the 15th century - "the renaissance period"
[23:37]  * lamont disappears for a while to boot a live cd and see if bionic.1 is hateful out of the box, or if his machien is special.
[23:37]  * RoyK hands michael2 a sledgehammer to help him debug his laptop
[23:39] <michael2> RoyK: a pair of jumper cables should do it
[23:40] <michael2> systemctl list-timers tells me "apt-daily.service" is already installed - and runs every morinig 8am
[23:41] <RoyK> perhaps it needs to be configured?
[23:42] <michael2> configured? isn't invoking the service enough?
[23:43] <RoyK> dunno - google it