[06:29] <lordievader> Good morning
[06:45] <edenist> morning
[07:57] <olivierbourdon38> monring everyone, anybody having experience with overlayroot package on ubuntu xenial 64 bits which generates a new initrd which is not compatible with my LVM based initial server setup. When I install overlayroot on my base image and reboot, the system does not seem to look for LVM root partition. Any ways to fix this ?
[08:09] <olivierbourdon38> in fact I just narrowed down the problem which is not caused by overlayroot but by initramfs-tools
[08:10] <olivierbourdon38> in fact on my system,  dracut is installed and was used to generate the initial initrd
[08:11] <olivierbourdon38> installing initramfs-tools removes dracut and regenerates a non LVM compatible initrd
[11:08] <rbasak> cpaelzer: I see three MPs in the review queue from you. Is there anything you'd like me to look at first?
[11:15]  * rbasak takes the oldest one first
[11:32] <compdoc> three MPs in the review queue? whats that?
[11:49] <rbasak> compdoc: https://code.launchpad.net/~canonical-server/+activereviews
[11:49] <rbasak> compdoc: though not a requirement for Ubuntu development, the Canonical server team operate a peer review policy for ourselves.
[12:35] <ahasenack> any idea why ubuntu-upload isn't working for this package that is in xenial? https://pastebin.ubuntu.com/p/FTBtZz5krd/
[12:35] <ahasenack> it's looking in cosmic
[12:41] <ahasenack> rbasak: hi, morning, did git-ubuntu break again? I'm getting ERROR:root:Is python3-pygit2 installed?
[12:41] <ahasenack> I have 0.7.4+git82.3512465  429 from edge installed
[12:41] <ahasenack> or maybe that was never fixed and I upgraded
[12:41] <ahasenack> oh, wait, I have 430 actually
[12:41] <ahasenack> but with that error
[12:44] <ahasenack> 429 works, I just reverted
[13:47] <cpaelzer> rbasak: no particular prio order - open-iscsi is a bit special (no merge but a bug fix)
[13:47] <cpaelzer> rbasak: and surely the one with the biggest changes, so more to discuss
[13:56] <rbasak> cpaelzer: what I haven't been able to figure out is how the socket activation works at all
[13:56] <rbasak> I grepped for sd_ and found nothing
[13:56] <rbasak> and StandardInput=socket doesn't seem to be in use
[13:57] <cpaelzer> rbasak: it is an abstract socket
[13:57] <cpaelzer> the iscsi adm uses the same abstract socket
[13:57] <rbasak> ahasenack: sounds like it's broken again :(
[13:57] <cpaelzer> so the @... in the socket file registeres this abstraction
[13:57] <cpaelzer> and this is what iscsiadm and co open against
[13:57] <rbasak> cpaelzer: yeah but if systemd accepts the first connection, how does it pass the fd of that first connection over?
[13:58] <cpaelzer> rbasak: I didn't care yet, but this is a general socket activation question and less MP specific right?
[13:59] <rbasak> cpaelzer: it's MP specific in that I don't see how it could possibly work so therefore have a suspicion that merging this will break something
[14:00] <rbasak> ahasenack: the self test passes for me. What subcommand is giving you that error please?
[14:00] <cpaelzer> rbasak: the socket connecting code in iscsiadm always does retry the connection anyway mutliple times
[14:00] <cpaelzer> rbasak: even if it does not use sd_listen_fds which would be explicit enabling via socket
[14:00] <rbasak> cpaelzer: ah
[14:00] <cpaelzer> the client will just reconnect
[14:00] <cpaelzer> the first triggers the service
[14:01] <ahasenack> rbasak: it was clone
[14:01] <rbasak> ahasenack: thanks
[14:01] <ahasenack> rbasak: I was trying to clone the recently imported skytools3
[14:01] <rbasak> ahasenack: it works for me. What release is your host machine please?
[14:02] <cpaelzer> rbasak: and it even has native systemd socket actviation support
[14:02] <cpaelzer> from open-iscsid changelog line 225
[14:02] <cpaelzer> 225       iscsid: implement systemd-compatible socket activation
[14:02] <cpaelzer> rbasak: I'm fetching the upstream repo to tell you where it does
[14:03] <cpaelzer> while I'm doing so, FYI - Fedora has socket activation on iscsid quite a while
[14:03] <cpaelzer> so things would have broken some time in this part of the world already
[14:04] <cpaelzer> rbasak: yep it checks first if it got an FD by systemd in  mgmt_ipc_systemd
[14:04] <ahasenack> rbasak: it was 430, I reverted to 429
[14:04] <rbasak> Ah
[14:04] <cpaelzer> rbasak: since https://github.com/open-iscsi/open-iscsi/commit/5d0e19fcc1cea77a72647cf96c5d3d773e8ee277
[14:05] <rbasak> cpaelzer: I was looking for sd_*
[14:05] <cpaelzer> rbasak: is that enough FYI for now or are there other open issues?
[14:05] <rbasak> cpaelzer: looks like they've implemented it themselves instead of using the systemd provided API
[14:05] <cpaelzer> rbasak: yep
[14:05] <rbasak> cpaelzer: that's fine for now thanks. I'll continue.
[14:05] <rbasak> ahasenack: I mean what release of Ubuntu, sorry - I want to try to reproduce in a VM.
[14:06] <ahasenack> rbasak: bionic
[14:06] <rbasak> (as it doesn't reproduce on my system)
[14:06] <rbasak> OK thanks
[14:08] <LambdaComplex> is there a guide for disabling netplan in ubuntu server 18.04?
[14:08] <sdeziel> LambdaComplex: last I've heard, it was as simple as "rm /etc/netplan/*"
[14:08] <LambdaComplex> well that would be nice
[14:09] <LambdaComplex> the /etc/network/interfaces file says to install ifupdown--i'm guessing that's the package containing the ifup and ifdown binaries
[14:09] <rbasak> I think that's all you need to do
[14:10] <genii> If you also want to use use ifconfig instead of ip, then you'll also need net-tools
[14:10] <LambdaComplex> genii: noted
[14:11] <LambdaComplex> ubuntu 16.04 doesn't use netplan, does it?
[14:11] <cyphermox> that's different from whether you use ifup / ifdown
[14:11] <cyphermox> LambdaComplex: it can, but it doesn't by default
[14:11] <compdoc> LambdaComplex, netplan isnt difficult
[14:12] <cyphermox> LambdaComplex: it would help a lot if you could tell me what you're trying to do, so if it doesn't work using netplan we can fix it for everyone.
[14:12] <rbasak> ahasenack: reproduced. Yeah it's pretty broken. The self test fails on Bionic. I think it happens to pass on Xenial because it matches the core snap release.
[14:13] <ahasenack> sometimes snaps remind me of the broken java promise: write once, run everywhere
[14:13] <LambdaComplex> cyphermox: can i just say "trust me, the problem isn't netplan" and have you actually trust me? :P
[14:13] <cyphermox> if you say so
[14:14] <cyphermox> if what you're trying to do is actually special though, it might still help if you describe it; then if someone else wants to do something like that we have an example or something
[14:16] <cyphermox> I *know* there are some things that aren't supported yet and I'm working on that, but I don't necessarily know of all the gaps because I don't necessarily try XYZ :)
[14:17] <LambdaComplex> cyphermox: oh, you're one of the netplan devs?
[14:17] <rbasak> ahasenack: FYI, I filed bug 1773991
[14:17] <ahasenack> ok
[14:38] <rbasak> cpaelzer: what is the purpose of replacing the invoke-rc.d call for the non-upgrade-path with deb-systemd-invoke?
[14:39] <rbasak> Specifically I mean:
[14:39] <rbasak> + deb-systemd-invoke restart iscsid.service || true
[15:01] <cpaelzer> rbasak: two reasons for that
[15:02] <rbasak> cpaelzer: FYI I just finished my review and asked in the MP but we can continue to discuss here
[15:02] <cpaelzer> change #1 is to change from the start/restart to just restart - this is due to the whole things no only mattering at restart (guared when entering htis)
[15:02] <cpaelzer> change #2 is to use deb-systemd-invoke, that is to be able to be able to pick .socket or .service
[15:02] <cpaelzer> without it will be both
[15:03] <rbasak> Are you sure it'll be both?
[15:03] <cpaelzer> and as I mentioned deb-systemd-invoke is the one that considers policy.d
[15:03] <rbasak> I got the impression systemd-sysv-generator affects .service only
[15:03] <cpaelzer> rbasak: it was both when testing, and with deb-systemd-invoke I can be explicit
[15:03] <rbasak> invoke-rc.d also considers policy-rc.d :)
[15:04] <cpaelzer> I want to explicitly say .service to be sure to do what I mean
[15:04] <rbasak> OK
[15:04] <cpaelzer> and not just, "some iscsid"
[15:04] <cyphermox> LambdaComplex: yes
[15:05] <rbasak> cpaelzer: would you mind putting a comment above that line please, explaining why that bit of the delta is there? The reason for everything else was obvious to me, just not that bit.
[15:05] <cpaelzer> rbasak: I'm already copying over
[15:05] <rbasak> Thanks :)
[15:05] <rbasak> My second MP point is also debatable
[15:05] <rbasak> I think it's probably correct to call systemctl is-active directly without deb-systemd-invoke
[15:05] <rbasak> Looking at its implementation
[15:06] <rbasak> And its manpage lists the start, stop and restart actions only
[15:06] <rbasak> But I await your opinion.
[15:08] <cpaelzer> interesting rbasak
[15:08] <cpaelzer> I didn't find that aspect, thanks to bring it up
[15:09] <cpaelzer> yeah I'd use systemctl instead then
[15:09] <cpaelzer> I was so happy to find deb-systemd-invoke to overuse it maybe, let me fix that
[15:10] <cpaelzer> there is another call that neess the same change
[15:11] <cpaelzer> rbasak: grepping through debian*postinst also confirms on systemctl for that
[15:21] <cpaelzer> rbasak: I have the MP updated
[15:48] <LambdaComplex> cyphermox: may i query you?
[16:38] <nacc> rbasak: there?
[16:40] <rbasak> nacc: o/
[16:44] <cyphermox> LambdaComplex: sure.
[16:44] <rbasak> nacc: I'm going to pop out for a while soon but will be back later.
[16:44] <rbasak> nacc: it'd be good to sync up with you
[16:47] <nacc> rbasak: sure
[16:47] <rbasak> nacc: well I'm still here right at the moment :)
[16:47] <rbasak> When is best for you?
[16:47] <nacc> rbasak: i'll be around for a while, and i think we have a checkpoint tmrw?
[16:47] <rbasak> Would you like to join a HO?
[16:47] <nacc> rbasak: yeah i can do a hangout
[16:49] <rbasak> nacc: I sent you a URL
[17:12] <LambdaComplex> hm, i just realized i screwed up...
[17:12] <LambdaComplex> i deleted the 1MB partition that ubuntu put at the start of the drive
[17:12] <LambdaComplex> apparently that was necessary
[17:49] <ahasenack> LambdaComplex: are you booting uefi or legacy/mbr?
[18:02] <lordievader> Sounds like the efi partition.
[18:33] <ahasenack> how do systemd service files with a "@" in their name work?
[18:33] <ahasenack> they seem to be some kind of template
[18:34] <ahasenack> https://pastebin.ubuntu.com/p/vNQfzrs7nr/ practical case
[18:34] <ahasenack> I *think* the idea is to have one service per config file in, respectively, /etc/openvpn/server and /etc/openvpn/client
[18:34] <sdeziel> ahasenack: yeah, exactly, those are per instance services
[18:34] <ahasenack> how are they used?
[18:34] <ahasenack> let's say I place a config in /etc/openvpn/server/myconfig.conf
[18:35] <ahasenack> the openvpn-server@.service file has
[18:35] <ahasenack> WorkingDirectory=/etc/openvpn/server
[18:35] <ahasenack> ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf
[18:35] <sdeziel> "service openvpn-server@myconfig start"
[18:35] <sdeziel> %i gets replaced with what follows @
[18:36] <sdeziel> not sure about %t though
[18:36] <ahasenack> hmmmm
[18:36] <ahasenack> that's cool
[18:37] <sdeziel> %t is runtime dir
[18:37] <sdeziel> man 5 systemd.unit()
[18:37] <sdeziel> yeah, that is a really nice feature
[18:38] <ahasenack> thanks
[20:21] <trippeh_> ah good, systemd-networkd-wait-online seems to be broken on my computer (18.04)
[20:22] <trippeh_> unless I specify interface it just times out, even with interface managed by networkd, working default ipv4 and ipv6 routes
[20:28] <trippeh_> oh one unimportant interface is temporarily stuck in configuring
[20:29] <trippeh_> so I guess not really broken just a little surprise :)