[00:01] Looks like you have third party apt sources enabled. [00:01] Look in /etc/apt/sources.list and /etc/apt/sources.list.d/ [00:01] If you add third party sources, you allow problems in those third party sources to break your system. [00:02] I don't know for sure what's causing your breakage here, or if it's caused by a third party source. [00:03] But it's the first thing to eliminate, and the bump of openssl by that third party source makes it look more likely than not in this case, IMHO. [00:03] (given the symptom you're reporting) [00:03] thanks man, I'm gonna take a look at that, thanks very much [06:26] hello, does anyone know how I can create a mirror of my OS drive to a second disk (OS already installed) [06:26] I experienced some kind of issue and could not do it during installation [06:37] patz0r: no guarantee for your data as that is just a page I found, nothing I own - but https://www.considerednormal.com/2016/10/configuring-software-raid1-after-installation-of-ubuntu-16/ looks good I'd think [06:38] thanks i'll check it out, worst case i can re-install but i'd have to do it over IPMI which i'd like to avoid [06:38] it wouldn't allow me to create a mirror during install though, i could select both disks but not proceed through the md creation [06:48] rbasak: no further action needed, I updated the bug [07:41] cpaelzer, i'm going through that article you linked now, do you know whether I need to manually copy my 'efi filesystem' partition or if I can just do my linux filesystem? [07:51] patz0r: sorry I don't know, I'd think you better keep the efi out of the raid to be sure [07:51] just raid the other partition [07:51] and keep the efi out of it [08:09] cpaelzer, thank you, I will try that [11:04] good morning [11:05] smoser: rbasak: retrying apt-get update for a few times is one of the first things that was added to charmhelpers a long time ago, to give you an idea of apt-get update's reliability :) [11:06] rbasak: in this specific case, I think it was because the container was shutdown while some apt job was running, and that left a lock file in place [11:06] to generate a disco base image, I had to deploy cosmic, release-upgrade, and generate an image from that, since we don't have disco images yet (or didn't, haven't checked today) [12:02] Does anyone know why rmadison prints multiple unstable releases for a package? For example rmadison -u debian nspr [12:02] or dovecot [12:10] kstenerud, why not? it's not illegal to publish multiple versions of a thing in a suite. [12:10] plus this is results from dak's postgres database [12:11] kstenerud, this $ rmadison -u debian -S nspr -s unstable [12:11] might explain it better [12:11] 4.12-2 built on hurd-i386, 4.19 built on kfreebsd, 4.20 on linux-any [13:21] kstenerud: could you please also upload a disco package to ppa:kstenerud/cosmic-fetchmail-gmailssl-1798786 ? [13:21] kstenerud: in the future you can drop the ${distro} prefix from ppas, as they can hold multiple releases [14:04] kstenerud: can you please squash the two changelog commits? https://code.launchpad.net/~kstenerud/ubuntu/+source/fetchmail/+git/fetchmail/+merge/358699 [14:04] kstenerud: then I'm ready to sponsor [14:04] if you want [14:16] ahasenack: yes. there is no reason to retry apt-get update [14:17] remember hash-mismatch errors? I still get those every now and then [14:17] ahasenack, on which repos and which releases? [14:17] that is only possible on < xenial. [14:17] so I was told [14:17] i only get it against debugsysms repo [14:17] but I get it even in bionic [14:17] cause that repo doesn't have by-hash publication. [14:17] the cause might be different: might be a mirror being updated in a bad way [14:18] ahasenack, but which archieves of bionic? [14:18] a mirror [14:18] ahasenack, which mirror =) [14:18] br.archive.ubuntu.com [14:18] yeah... its 2 separate things. [14:18] and how it's done, and does it publish by-hashes? [14:18] I don't know, I don't maintain it. Just saying that retrying apt-get update still has its use cases [14:18] granted, in the case of a bad mirror, retrying for just a few minutes will probably not help [14:18] ahasenack, we need to see your apt-get update log when it happens [14:18] on < xenial, its known problem. but in my experience retrying is unlikely to fix the issue. especially retrying within seconds... what change would you expect in that case to make it work? [14:19] ahasenack, please pastebinit next time it happens. [14:19] on xenial+, it really should not happen. [14:19] will do [14:19] and we should not just program in retries to ignore it. [14:19] but to me it looks like it is updated badly. [14:20] actually, no, looks fine [14:21] A by-hash mirror still needs to sync in the correct order [14:22] (new by-hash first, then InRelease update, then delete expired by-hash entries) [14:22] country mirrors should be using 2stage sync, which does that. [14:22] I don't think you can check it's doing that correctly as an external observer. [14:22] well, i'm trying to spot if their by-hashes are out of date ;-) [14:23] You're a human being trying to spot a subsecond race? OK :) [14:23] rbasak, i believe ahasenack is a human too ;-) and is catching it [14:23] xnox is not mere human [14:23] I said he gets them now and then. [14:24] Which is rather different from looking on just one moment :) [14:27] smoser, i wonder if you gonna come to the curtin + s390x call =) [14:27] unless it's an rharper only thing..... [14:27] xnox: you can add me. i have a conflict at the first half hour there. [14:28] but itmight end early [14:29] I am having trouble trying to monitor the new time/date service on Ubuntu 18.04 with Zabbix. Prior to Ubuntu 18.04 we were able to monitor using the Zabbix key 'net.udp.service[ntp]' but now with timedatectl/timesyncd this is no longer working. [14:29] smoser, you have mail [14:29] zetheroo: via snmp? [14:29] just curious [14:29] The guys in the Zabbix channel don't seem sure what to do about this so I am asking here .. [14:30] ahasenack: no, using the Zabbix Agent [14:30] the question is more how things changed in Ubuntu from 16.04 ? [14:30] zetheroo: what exactly was that monitoring before, a process? An open port? [14:30] because in 16.04 it didn't use timesyncd, IIRC it used ntp/ntpd [14:30] with a local only listener [14:31] https://help.ubuntu.com/lts/serverguide/NTP.html.en [14:31] 'Since Ubuntu 16.04 timedatectl / timesyncd (which are part of systemd) replace most of ntpdate / ntp.' [14:31] as i said - that's what's changed. [14:31] ahasenack: wrt retrying... i dropped the apt retry because what it was really doing was waiting fo the system to boot. [14:31] oop i'm tired disregard. [14:32] But, yes, it didn't seem to be an issue with 16.04, only really noticed it in 18.04 [14:32] i replaced that with better logic to determine when the system was booted. [14:32] smoser: ok, got it [14:32] zetheroo: if the key is net.udp.service[ntp] then it's likely it was testing ithe NTP UDP socket locally [14:32] i'm not entirely opposed to retry-ing on apt-get update... but i'd lke it to be more intentional [14:32] ahasenack: does it ever actually fix the problem for you? [14:33] teward: right [14:33] and we were also using this key to look if the process was running: system.run[ntpstat > /dev/null 2>&1; echo $?] [14:33] smoser: not really, it would have to retry for a long time, or I would have to be lucky and the situation (mirror, or flaky network) to resolve itself by coincidence [14:33] in either xenial or right. [14:33] ahasenack, and you are not behind an apt-caching proxy or like a local squid-apt-proxy deployed, anything like that? [14:33] smoser: given the failure, I just noted that the retry was removed, and decided t oask [14:34] xnox: I am, but when that happened I removed the proxy to test, and it still failed [14:34] so... i dont' see the point in retrying if its not going to do anything in the majority of cases. [14:34] xnox: of course, after a while (30min?), it worked again [14:34] ahasenack, but did you clear local apt state too? [14:34] since 18.04 neither of these checks work anymore ... so I am wondering what would we be looking for / monitoring with the new time sync service? [14:34] ahasenack, cause little does it know...... if it already saw inconsistent stuff. [14:34] xnox: apt-get clean, I don't remember if I rm-f'ed the files [14:34] the list files, that is [14:34] whatever remains in /var [14:35] zetheroo: you could be looking for the process, or for the actual clock/time [14:36] ahasenack: I've been trying to find out what the process is that keep the system time sync'ed [14:36] zetheroo: 2627 ? Ssl 0:00 /lib/systemd/systemd-timesyncd [14:36] zetheroo: just for kicks, install chrony, and add a 'listen' directive to the end of it, then restart the service and see if Zabbix gets a reply? It might just be querying the local TCP port directly. [14:37] if Zabbix gets a data set then it's probably querying the local ntp service directly with NTP requests [14:37] zetheroo: you can also use timedatectl to query its status [14:37] try "timedatectl status" [14:37] maybe you can change your monitoring to call that and parse its output [14:38] ^ this also [14:39] teward: According to the Zabbix docs the net.udp.service key 'Checks if service is running and responding to UDP requests.' [14:39] zetheroo: which means it's querying NTP over udp/123 by default [14:39] there is a separate key for TCP 'net.tcp.service' [14:39] zetheroo: same difference except tcp/123 [14:40] but as i stated, there's nothing responding to NTP requests locally on that port [14:40] before 18.04 all we had to do was install ntpstat and the checks were working [14:42] afaik you can still use ntp [14:42] it's just not the default [14:42] ^ this [14:43] I already tried that [14:43] ahasenack: though, ntpstat relies on ntpq it seems under the hood [14:43] installed ntpstat and still nothing [14:43] ahasenack: so if NTPd isn't running ntpq might not reply. [14:43] therefore ntpstat may fail [14:43] well, I mean, switch back to everything ntp-based [14:43] apparently you have to actually switch [14:43] apt install ntp [14:43] that will remove chrony [14:43] yep [14:43] and disable timesyncd iirc [14:44] Wait, what are you trying to achieve? [14:44] I would really rather use the default services [14:44] timesyncd is just a client. Looks like you were checking that a server was working before [14:45] Do you actually want/need a server? [14:45] it seems easer for him to get back to ntp rather than switch the monitoring tool to timesyncd [14:45] rbasak: I think in the ntp days, even on a client, there was always an open udp port used by it [14:45] Yes [14:45] But what is the actual check for? [14:45] To check that the service is up? [14:45] compliance? :) [14:45] Regular systemd service monitoring will check that. [14:45] To check that the time is believed to be in sync? [14:46] I mean, I thought maybe others were monitoring the time/date info on their servers which were using timedatectl/timesyncd [14:46] That wasn't being checked before. [14:47] It would be a start to be able to monitor that the time/date sync service is running [14:47] zetheroo: it doesn't make sense, now that we're running a more pure client, to expect what you were doing before to work exactly. You're going to have to define what you actually want checked. [14:47] OK, so use systemctl status systemd-timesyncd.service for that [14:47] ahasenack: https://bazaar.launchpad.net/~smoser/+junk/check-archive/files [14:47] ok [14:47] Hopefully your monitoring system has a way to integrate better with systemd to check service statuses though. [14:47] that is 'check-archive'. run like: [14:48] check-archive -v http://br.archive.ubuntu.com/ubuntu trusty-updates [14:48] it will checksum all files comparing against the indexes [14:48] and stores headers and such. [14:48] of responses. [14:49] it reports happy right now on trusty-updates [14:50] rbasak: I was just thinking that ... [14:50] http://paste.ubuntu.com/p/YKhQMqzvBN/ [15:25] I'm tracking some high / medium 'importance' bugs, where progress feels slow. Some of them are in 'triaged' state (and have been for a while), others confirmed. and there are yet others which have been 'new' for months. [15:29] i'm sure everybody is working on more important things and i most likely just don't understand how priorities are internally set (i'm entirely serious here), but with my admittedly very limited insight, it feels the priorities may be wrong, and stable server-live installers which are more suitable for an LTS release should be provided soon. [15:29] [15:30] tomreyn: could you provide your best example of a mistriaged bug please? [15:35] this is hard to tell, i'll post a couple. [15:35] bug 1783413 has been handled, but only in curtin, so nothing has changed from a user perspectiver from what i understand. [15:35] bug 1783413 in subiquity "failed creating LVM on top of md devices" [Undecided,New] https://launchpad.net/bugs/1783413 [15:35] bug 1784124 remains 'new' since end of july [15:35] bug 1784124 in subiquity "subiquity raid+lvm installation failed" [Undecided,New] https://launchpad.net/bugs/1784124 [15:36] Thanks [15:37] bug 1785354 - if i understand it correctly, means that any system installed with the released server-live installer doesn't get regular file system checks. i would have assigned higher piro then. [15:37] bug 1785354 in curtin "/etc/fstab: fs_passno is 0 for all file systems" [Medium,Triaged] https://launchpad.net/bugs/1785354 [15:38] bug 1783129 is high prio, but continues to affect anyone using the released (not daily snapshot) installer [15:38] bug 1783129 in subiquity "Only "main" component enabled after install" [High,Confirmed] https://launchpad.net/bugs/1783129 [15:38] i'll stop here. thanks for having a look, rbasak [15:41] to anyone seeking commercial consultance, in the current state, i can only recommend to not use the server-live LTS installer, and this is seven months post release. [15:41] kstenerud: can I upload https://code.launchpad.net/~kstenerud/ubuntu/+source/fetchmail/+git/fetchmail/+merge/358699 ? [15:41] (which is not what i want to do.) [15:44] I still use the "alternate" installer, frankly. [15:48] kstenerud: around? [15:57] cpaelzer: will you finish this review, or should I grab a slot? https://code.launchpad.net/~kstenerud/ubuntu/+source/openssh/+git/openssh/+merge/358491 [16:03] tomreyn: thanks for the feedback; and thanks for filing those bugs and testing === cshep is now known as platonical [17:15] I'm trying to install 18.04 server on a machine and it boots up and the screen starts flickering and the installation menu does not come up. [17:15] any ideas? [17:15] standard onboard graphics [17:27] ikla, is it serial console or graphical? [17:27] ikla, can you change to a different tty? [17:27] ikla, you can try the alternative server cd too (linked in a separate link from the download pages) [17:42] smoser, do spill the beans =) [19:17] cpaelzer: hi! Mind if I release postgresql 10.6 as a security update? [19:55] rharper: i didn't file all of them, just some. thanks to you and all dev's for your continuous work. IMO 18.04 server is really a great improvement over 16.04, netplan is nice (except for some edges where it doesn't work so well, yet), and subiquity / curtin will surely be nice (and much nicer) once they cover the features d-i provides. keep up the good work! :) === kallesbar_ is now known as kallesbar [23:55] Has anybody tried to create an Ubuntu VM with virt-install? [23:56] and used the --extra-args option? [23:56] five or six years ago [23:56] virt-install is mostly deprecated by cloud images. [23:57] Try multipass - https://github.com/CanonicalLtd/multipass - it's much easier [23:57] And way quicker because there's no need to run an installer. [23:58] i'm just trying to create a vm on a local kvm host.