[00:15] <keithzg[m]> Hmm is there any Free Software projects out there that provide something like the Ubuntu QA site? (Also looking a bit into the Ubuntu QA site itself since it appears the source is indeed available for that.) Basically looking for a testing framework that isn't automated but rather is expecting folks to be doing things manually and then manually marking tests as failed or not, etc.
[00:19] <OerHeks> https://stackexchange.com/
[00:23] <sarnold> OerHeks: I think keithzg[m] means this thing instead http://iso.qa.ubuntu.com/
[00:25] <keithzg[m]> sarnold: Yeah, precisely. And it as least *seems* to be more amenable to one running one's own instance than Launchpad. A bit surprising to me there don't seem to be more options like that out there, though, which makes me wonder if I'm just looking in the wrong places!
[00:26] <sarnold> keithzg[m]: I'm not sure I've even seen this site before; it could just be that no one else knows about it either :)
[00:26] <keithzg[m]> Hah! Well, it's definitely used by the desktop flavours for tracking testing leading up to each release. Which is precisely the kind of workflow we have at my dayjob.
[00:27] <sarnold> keithzg[m]: check this out too http://open.qa/ -- suse folks use this, I've heard good things about it https://openqa.opensuse.org/
[00:27] <keithzg[m]> The whole world + dog seems to have gone over to CI and automated testing which makes it hard to find manual testing tracking software (which makes sense! but alas our software is quite resistant to automation).
[00:27] <keithzg[m]> Oho, thanks sarnold
[00:28] <keithzg[m]> Oh, another automated one :(
[00:28] <sarnold> keithzg[m]: I think they've got stuff for driving a VM through install process with clicking things and so on
[00:29] <sarnold> so depending upon just how unautomatable your stuff is, you might be able to get to it anyway :)
[00:33] <TJ-> has anyone deployed -server into a Windows Server2016 Hyper-V guest and utilised DDA (PCI paas-through in Hyper-V) and can tell me what to expect, or look for, when the device doesn't seem to show up?
[00:35] <keithzg[m]> sarnold: Yeah, I'm also trying to do as much fully automated testing as possible, so that's something to keep in mind for that side of things. But it really is a lotta very manual tests that are done, and our system for that is aging and in need of replacement (we're stuck on a circa-2013 version of MediaWiki since later versions will break our custom testing implementation; that's even gonna be a problem next
[00:35] <keithzg[m]> ubuntu-server LTS since an old PHP might not be available!). It's also all complicated by the dumb DRM management insists on using, which complicates firing up clean and/or multiple VMs for testing :*(
[00:38] <sarnold> ugh :(
[00:38] <sarnold> that does sound like a real chore :(
[00:40] <keithzg[m]> Yeahhhhh. It's not great, and really compounds the existing complications (Windows is already a lot harder to reliably automated GUI actions in than Linux, at least as far as I've been able to learn or experience). Luckily most of my job is just spent in the comforting reliability of shells on Ubuntu servers :D
[00:41] <sarnold> familiarity and predictability :)
[00:42] <TJ-> keithzg[m]: I've recently been baptised into Windows PowerShell ... just URghhh!
[00:42] <keithzg[m]> TJ-: Haha! Oh I very much feel your pain
[00:44] <rbasak> keithzg[m]: https://checkbox.readthedocs.io/en/latest/index.html maybe? I'm not sure if that's exactly what you're looking for but it might be a good starting point to see what Ubuntu has been doing
[00:45] <freebdS> in postfix if mynetworks= is set to mynetworks=172.24.2.0/24, 127.0.0.0/8" what sense does it make to set inet_interfaces to loopback?
[00:48] <tomreyn> inet_interfaces decides which interfaces postfix binds to, mynetworks defines which networks postfix trusts to be 'the good guys', it will relay mail for.
[00:49] <freebdS> but if inet_interfaces is set to loopback one can send mail only from a machine where postfix is hosted on right?
[00:51] <keithzg[m]> rbasak: That looks neat, but again seems to be oriented towards automated testings; I'm mostly after, instead, entirely manual testing (for automated testing we have unit tests, and some scripted post-build jobs, set up alongside our build infrastructure in Jenkins).  Although "Some test are fully manual and don’t run any commands." sounds promising . . .
[00:52] <tomreyn> freebdS: yes, this would be the expectation since loopback should only be used to address the same system.
[00:52] <rbasak> freebdS: if I understand your question correctly then you are right, but it is also harmless. There are other reasons that configuration may be valid, for example for consistency with other configs.
[00:52] <rbasak> keithzg[m]: yeah I think it supports interactive manual testing? I wasn't able to discern any more information from a quick glance.
[00:52] <sarnold> freebdS: perhaps you're using stunnel4 or ssh to poke remote sockets into loopback
[00:52] <sarnold> freebdS: or perhaps your NICs are all multihomed and some are 'local' and some are 'remote' ..
[00:53] <freebdS> no i am just preparing for a red hat cert
[00:54] <keithzg[m]> rbasak: Unfortunately the reporting functionality for Checkbox seems to broadly be "either integrated with Launchpad or creating report files". Basically what I'm looking for is just what the ISO QA stuff does, ie. a list of tests that then can be done for each release milestone, with testers manually marking pass/fail and writing notes about them, and then some sort of overview that one can get to see testing
[00:54] <keithzg[m]> status for each release based on that.
[01:02] <TJ-> hmmm, seems I need to know which are the Hyper-V "LIS" drivers in the mainline kernel... and then to figure out how to get -server's debian-installer to find/load them
[01:08] <TJ-> Is there a way in debian-installer to find/load kernel modules from udebs ?
[01:33] <TJ-> grrr, this is frustrating! The driver is in the .udeb on the ISO image but I cannot figure out how to get it installed
[01:35] <sarnold> can dpkg -i 'install' those?
[01:35] <sarnold> I've never had to use the udebs before
[01:42] <TJ-> The d-i shell is limited, there's only udpkg, but it doesn't 'support' .µdeb files.
[01:43] <TJ-> The problem I have is this driver, in the linux-modules-extra .µdeb, needs to be loaded in order for the guest to discover the storage devices it is to install to
[01:43] <TJ-> it's the drivers/pci/controller/pci-hyperv.ko  - the base installer only has pci-hyperv-intf.ko loaded
[01:45] <TJ-> Thanks so much Microsoft and their idiotic hypervisor implementation and support. 3 days of pain so far simply to try and get PCI passthrough working!
[01:46] <TJ-> what's weird here is the .µdeb is in the ISO /pool/ so it can be installed at some point... if it is only into the /target/ though I shall not be happy
[01:57] <TJ-> FINALLY!. FYI for others: there are both .µdeb and .deb files, so "udpkg --unpack /pool/main/l/linux/linux-modules-extra-`uname -r`_amd64.deb" followed by "demod" and then "insmod /lib/modules/`uname -r`/kernel/drivers/pci/controller/pci-hyperv.ko"
[01:57] <TJ-> At which point "lspci" will list the DDA devices
[01:58] <sarnold> TJ-: oh sweet
[01:58] <sarnold> TJ-: what a pain :)
[01:59] <TJ-> And then you'll see something like this (can't copy text out of hyper-v viewer so screenshot snippet) https://i.imgur.com/qWwl6ei.png
[02:00] <TJ-> I'm actually attempting to pass-through 2x NVMe controllers and a quad-port Intel i350 Gigabit Ethernet controller
[02:00] <sarnold> oo
[02:01] <TJ-> the idea is to install standalone Linux on its own hardware to avoid upsetting Windows Server2016 and at some point in the future migrate this HP ML110 G9 to native Linus OS.
[02:03] <TJ-> Right! bed-time (02:00). I'll complete this and do a write-up before I forget tomorrow.
[02:04] <sarnold> gnight TJ-
[02:06] <TJ-> oops, noticed a typo above "demod" >> "depmod"
[02:08] <sarnold> it did take me a moment to figure that one out, hehe
[02:09] <TJ-> I've been suffering the last week from having to use many different keyboards with different layouts - typing accuracy has gone AWOL :)
[02:12] <Casper26> Can anyone help with this please? https://paste.ubuntu.com/p/mKwjhHPbxR/
[02:18]  * keithzg[m] is doing battle with Netplan on a fresh KVM VM created by uvtool . . . trying to set a static address but after disabling cloud-init's network handling and creating a netplan .yaml file, nada.
[02:18] <keithzg[m]> Tempted to just resort to straightforward stuff, Netplan just never seems to go right for me, but I guess I should learn how to debug it . . .
[02:19] <keithzg[m]> Surely there's more than the paltry options listed at https://netplan.io/troubleshooting ? Like some sort of log somewhere?
[02:20] <mybalzitch> netplan is such trash, go back to something that works like ifupdown
[02:23] <keithzg[m]> Well, sure, reliable ol' ifupdown is definitely my fallback plan. Just figure I should learn how to actually figure out what's going wrong when Netplan goes wrong.
[02:24] <keithzg[m]> (Also currently tricky to install alternate packages in this VM since networking isn't working, heh)
[02:28] <keithzg[m]> journalctl for systemd-networkd (which in theory is being used as the renderer) doesn't list anything, other than a ton of lines with nss-ldap failing (weirdly starting before the Network Service says it starts)
[02:30] <keithzg[m]> The netplan docs say "Verify that configuration in /run/systemd/network includes the settings in your netplan YAML." but there isn't even a /run/systemd/network file or folder. There is a /run/sytemd/netif folder, containing links/2 which tells me the operating state is off, but that's nothing more than what networkctl already told me . . .
[02:34] <rbasak> keithzg[m]: the latest uvtool supports --network-config to the create subcommand. That'll pass your desired network config through to cloud-init
[02:34] <rbasak> keithzg[m]: https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html#network-config-v2
[02:35] <keithzg[m]> rbasak: Oh, I had no idea; I keep trying "man uvtool" and being reminded that uvtool doesn't bother to have a man page :P
[02:35] <rbasak> keithzg[m]: "man uvt-kvm"
[02:35] <rbasak> Maybe "uvtool" should be a symlink!
[02:36] <keithzg[m]> Ah!
[02:37] <keithzg[m]> Anyways, that doesn't seem to be supported by the version in 18.04 anyways, alas
[02:38] <rbasak> IIRC the version packaged for Xenial in ppa:uvtool-dev/master has it
[02:38] <keithzg[m]> Yikes I thought I found what was probably my mistake in my netplan config and now it's not fully booting, never gets to the login prompt
[02:41] <keithzg[m]> I've certainly had Netplan cause problems before, but this is a new record, lol
[02:45] <keithzg[m]> Time to blow that VM away and try to figure out how to provide a config that uses the bridge, I guess
[02:46] <keithzg[m]> (In terms of how to write that config, that is; presumably then I just need to pass it with --network-config then)
[02:46] <rbasak> Right
[02:46] <rbasak> It might be easier to verify the config first using the VM and netplan interactively though
[02:50] <keithzg[m]> Well, sure. I guess. I mean . . . last config I wrote left it unbootable. So.
[02:51]  * keithzg[m] is increasingly tempted by the siren call of ifupdown
[02:51] <rbasak> Use uvt-kvm create --password=foo
[02:51] <rbasak> Then virsh console
[02:51] <rbasak> Log in over that
[02:51] <rbasak> Then experiment with network config without rebooting
[02:51] <rbasak> Tweak netplan config, run "netplan apply" (IIRC)
[02:51] <keithzg[m]> Eh, the password wasn't the problem.
[02:51] <rbasak> Once you have it, then test reboot
[02:51] <keithzg[m]> Actually had added a user and everything.
[02:52] <keithzg[m]> It just wasn't actually finishing booting.
[02:52] <rbasak> Once you have that, then save that config to the host and use uvt-kvm create --network-config to reproduce
[02:52] <rbasak> To test/prepare an ifdown configuration I would use exactly the same plan
[02:52] <sarnold> when I set up a rpi3b+ I also felt like there was so little visibility on what netplan was doing :/ I got it to work but have no idea how. (Probably the error was entirely unrealted to netplan, the nics on those things are blobby annoying)
[02:52] <rbasak> netplan just writes networkd config
[02:53] <rbasak> To see what it did, you need to know and examine networkd configuration
[02:53] <keithzg[m]> rbasak: Yeah, I just uhhh have never had any such problems with ifupdown. And the problem was, netplan wasn't writing networkd config, and I saw no way to see why it wasn't.
[02:54] <sarnold> heh, ifupdown hadn't given me problems in the last decade *because* it gave me a huge amount of trouble in the decade before that and I learned what not to do..
[02:54] <rbasak> keithzg[m]: could you file a bug report with steps to reproduce please?
[02:54] <keithzg[m]> Oh yeah don't get me wrong, networking? You'll always find a way for it to go wrong ;)
[02:54] <sarnold> yeah, right next to printers :) heh
[02:55] <rbasak> keithzg[m]: if the UI could do with improving to give better diagnostics, an understanding of how your situation came about would be useful
[02:55] <keithzg[m]> rbasak: I already blew away the VM, but if I manage it again I'll try. But quite simply, I tried following the troubleshooting steps listed, and they skipped right over where my issue appeared to be (ie. in actually creating the networkd config)
[02:57] <rbasak> keithzg[m]: thanks, but I'd only be relaying the message so I can't really use that information. If you manage to write it up fully, then we can pass that around, decide how we might improve the UI and get it done, etc.
[02:57] <keithzg[m]> Eh, sure. I'm not sure what there is to write up though. Netplan is a black box: make it less of a black box?
[02:58] <rbasak> The usual bug report format - steps you followed, what you expected, what you got instead. And also what documentation you were following and what documentation you felt was missing.
[02:59] <rbasak> Otherwise we're only guessing. We'll add some diagnostics and think we've improved things for you but instead we'll completely miss the mark.
[02:59] <keithzg[m]> Naw I get that, I just . . . it seems like such an obvious and basic thing that I can't say I can even imagine it wouldn't have occurred to someone. So presumably the choice has already been made to not document that stuff for some reason or another.
[03:00] <rbasak> It's hard. You need a networking expert to design and write these things. They tend to do things differently to the rest of us.
[03:00] <rbasak> It's pretty normal to end up with these blind spots when people don't give us feedback.
[03:02] <keithzg[m]> Oh, c'mon. I can't buy that as an excuse. Actually writing a log somewhere and saying where that log is, that's not exactly some novel concept some crazy genius wouldn't think of because they're such a crazy genius.
[03:02] <rbasak> You're jumping to assumptions there.
[03:02] <rbasak> For all you know, all the relevant troubleshooting is there and in a reasonable place and you've just failed to find it.
[03:02] <rbasak> Without a report, we just don't know.
[03:03] <keithzg[m]> I looked through the entirety of (privilege-elevated) journalctl's output. There wasn't anything there.
[03:03] <rbasak> I can't confirm what you did or did not do without a full report.
[03:04] <keithzg[m]> Okay, you've convinced me. I'll return to ifupdown.
[03:04] <keithzg[m]> A lot easier than trying to re-break netplan in the same way or making netplan actually work for me.
[03:04] <sarnold> .. or file a bug report :)
[03:04] <rbasak> ifupdown has bugs too you know :)
[03:05] <keithzg[m]> sarnold: If I knew enough about netplan to repro my issue I would . . .
[03:06] <keithzg[m]> But I can't imagine "I edited some files, nothing got created and there was no output, btw the VM is blown away now" would be a terribly helpful bug report!
[03:06] <rbasak> Come on. You're using uvtool and the problem you describe sounds entirely reproducible with no non-deterministic factors. Of course you can repro your issue. If you can't, how is it an issue?
[03:06] <keithzg[m]> rbasak: Well there's also the issue that I just don't understand Netplan's config files apparently and so generally fail at writing working ones, lol
[03:06] <rbasak> It would be helpful because we'd know what edits you made, what files you created, what you ran, what didn't get created, and so on.
[03:07] <rbasak> Then we'd be able to identify what bit of documentation or what lack of documentation misled you, and how we might improve that.
[03:08] <keithzg[m]> Gotta run from work now, I'll give netplan one last chance tomorrow, and try to write up whatever I run into as a bug report. But if it takes over an hour I'll just resort to ifupdown, which I know actually works in my setup since a half-dozen VMs on the same host already are set up that way :(
[03:09] <keithzg[m]> (I suspect I wouldn't be having nearly as much trouble if Netplan wasn't using YAML, I just can't get along with YAML!)
[03:09] <rbasak> Just pretend it's JSON then :)
[03:09] <sarnold> rofl
[03:10] <keithzg[m]> Haha
[03:11] <keithzg[m]> I can't say I'm super fond of JSON either but at least it doesn't freak out if I use tabs! :p
[03:11]  * sarnold hands keithzg[m] a trailing ,
[03:11] <keithzg[m]> haha
[07:05] <lordievader> Good morning
[07:07] <cpaelzer> o/ lordievader
[07:08] <lordievader> Hey cpaelzer
[07:08] <lordievader> How are you doing?
[07:08] <cpaelzer> great, I hope 2020 is kind to you as well lordievader
[07:09] <lordievader> Thus far, yes :)
[08:26] <Skyrider> Think I'll give up on systemD timer.. not as great as I expected it to be.
[08:26] <Skyrider> It even ran twice last night (within 20 seconds) when it shouldn't have.
[08:43] <lordievader> I really start wondering how you set this up. I've never had any issues with systemd timers.
[08:53] <Skyrider> Makes me wonder the same.. timer ran at 23:59:01 and 23:59:17 while the original timer is set to 2020-*-* 00:59:15, so those 17 seconds is accurate .... so makes me wonder, why did it run at 23:59:01
[09:03] <lordievader> Timezone difference to UTC?
[09:04] <Skyrider> Shouldn't cause 17 seconds runtime difference.
[09:05] <lordievader> > Note that timers do not necessarily expire at the precise time configured with this setting, as it is subject to the AccuracySec= setting below.
[09:05] <lordievader> Which says:
[09:05] <lordievader> > Specify the accuracy the timer shall elapse with. Defaults to 1min. The timer is scheduled to elapse within a time window starting with the time specified in OnCalendar=, OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec= or OnUnitInactiveSec= and ending the time configured with AccuracySec= later.
[09:05] <lordievader> 17 seconds falls within the window of a minute.
[09:12] <Skyrider> That I know, but i haven't set up the script to run at 23:59:01
[09:12] <Skyrider> I would assume it still follows the seconds accurately in the timers
[09:14] <lordievader> No, like the documentation says it runs in the window 23:59:01 -- 00:00:01. Unless you specified a different accuracy.
[09:16] <Skyrider> so even if I set up OnCalendar=2020-*-* 00:59:15 it can still run at 01?
[09:16] <Skyrider> Ah, I get it.. within that minute timeframe.
[09:17] <Skyrider> Shouldn't it be 23:59:15 to 00:00:!5?
[09:17] <Skyrider> **15
[09:18] <lordievader> Anyhow, to get back to the original issue. I'd setup a test defining a new timer set to run every minute (or every 5 minutes or so) to validate systemd-timer is to only thing triggering the service.
[09:27] <Skyrider> Yup yup. Guess I'll have to ^^
[13:49] <sdeziel> I'm using the hwe and hwe-edge kernels on various Bionic servers and none of them received the latest update batch (5.0.0-38 and 5.3.0-26). Anyone else seeing this?
[13:54] <lotuspsychje_> !info linux-generic-hwe-18.04
[13:54] <ubottu> linux-generic-hwe-18.04 (source: linux-meta-hwe): Complete Generic Linux kernel and headers. In component main, is optional. Version 5.0.0.37.95 (bionic), package size 1 kB, installed size 12 kB (Only available for i386; amd64; armhf; arm64; ppc64el; s390x)
[13:55] <sdeziel> lotuspsychje_: true but https://usn.ubuntu.com/4226-1/ announced 5.0.0-38
[13:56] <sdeziel> I received the email announce late on January 6th but maybe the builders are overloaded?
[13:56] <lotuspsychje_> yeah im trying to findout whats going on too
[13:57] <lotuspsychje_> sdeziel: maybe the #ubuntu-mirrors might know more about it?
[13:58] <sdeziel> lotuspsychje_: right, I tried both the UK and the US archive servers though
[13:58] <sdeziel> both are primary IIRC
[13:59] <lotuspsychje_> i received kernel updates for 20.04 yesterday, not sure if other bionic users received yet
[13:59] <sdeziel> https://launchpad.net/ubuntu/+source/linux-hwe/+publishinghistory and https://launchpad.net/ubuntu/+source/linux-hwe-edge/+publishinghistory seem to indicate they were not published
[14:02] <sdeziel> hmm, linux-hwe shows 5.3.0-26.28~18.04.1 being proposed for Bionic. Looks like a transition of the hwe kernel from 5.0.0 to 5.3.0
[14:09] <sdeziel> thanks lotuspsychje_
[14:10] <lotuspsychje_> you found yourself sdeziel :p
=== lotuspsychje_ is now known as lotuspsychje
[22:24] <ruben23> hi guys i got apache 2.4.7  and setup and Alias problem now im getting 403 Forbidden  ---> anyone can help how to work around this please
[22:25] <sarnold> check your logs; trust in your logs
[22:30] <ruben23> https://pastebin.com/acX8bYWq
[23:01] <teward> And i was going to reply to them too oh well (they left)
[23:23] <keithzg[m]> Hah, well howabout that. Wrote what I *thought* was the same Netplan YAML file from scratch, but at least when running `netplan apply` today it appears to have actually correctly set up the network device. (Bolsters the theory that I just did something wrong with the YAML the first time!) Time to disable cloud-init's network configuration and reboot and see what happens . . .
[23:23] <sarnold> keithzg[m]: woo
[23:35] <keithzg[m]> sarnold: Seems like I might be finally getting the hang of Netplan, phew! Although maybe I'll be looking back on saying that with mirth at some point ;)
[23:36] <sarnold> keithzg[m]: good now I know who to bug next time I have trouble :)
[23:37] <keithzg[m]> sarnold: Hehe
[23:43] <keithzg[m]> Awwww, crap. I had assumed everything was working fine because ifconfig was reporting the right IP address and all that. But nope; actually network unreachable. Sigh.
[23:48] <keithzg[m]> All journalctl says for systemd-networkd for the interface is "Gained carrier" then "Could not set route: Network is unreachable", which seems inexplicable to me; the NIC is defined for this VM the same way all the other VMs on the same host are :(
[23:54] <keithzg[m]> In case anyone can point out some obvious mistake I've made, https://paste.ubuntu.com/p/VWwBtRHS9F/ is the Netplan config I'm trying to use and https://paste.ubuntu.com/p/JbTf7NHt44/ is an equivalent that's working on a VM on the same host using good ol' ifupdown.
[23:56] <sarnold> keithzg[m]: the ifupdown example uses a /8 so the gateway can be reached; the netplan example uses a /24 so the gateway cannot be reached from that address
[23:56] <sarnold> keithzg[m]: that might not be *the* problem but it may contribute
[23:57] <tds> I didn't think you need to care about the subnet for the gateway with ifupdown anyway, it just adds onlink to the default route?
[23:58] <keithzg[m]> sarnold: Huh, fair enough. I had seen that but figured that couldn't be the problem, since I have *another* Netplan-using server on the network that uses /24 (in fact that's why I used /24, I figured I must have been misunderstanding things)
[23:59] <keithzg[m]> Yeah, that fixed things. But now I'm just baffled that the other server actually works fine using /24!