[01:32] <kinghat> i have a supermicro board, its possible to use two different speed memory modules isnt it? it will just use the slower one?
[01:52] <OerHeks> maybe yes, maybe no, i guess not always.
[02:03] <JanC> kinghat: depends; it might depend on how many memory banks there are, whether it's a multi-CPU board, etc.
[02:04] <JanC> you motherboard's manual should have the details
[02:04] <kinghat> ya its a supermicro dual bulldozer opteron
[02:04] <JanC> usually you can find those on the manufacturer's site
[02:04] <kinghat> it doesnt really say about using different speed mem modules.
[02:04] <JanC> or in the box when you bought it new
[02:05] <kinghat> just which slots to populate and which types it supports.
[02:05] <kinghat> definitely dont have the box.
[02:06] <JanC> then maybe it doesn't matter (and will use the slowest, as you say, or maybe even a slower speed if that's necessary to make both work)
[02:06] <kinghat> ya im going to give it a whirl.
[02:07] <JanC> might be a good idea to run memtest86 or similar for a couple days to make sure it's stable  :)
[02:08] <JanC> if you can, using the same memory is probably a good idea though
[02:08] <kinghat> ya i just dont have enough lol
[09:13] <jc_> Hi, Anyone with experience in deploying the OpenStack with provider network. I have configured the openstack without any errors. Floating IPs are getting allocated but I am not able to connect to VMs. Any suggestions, where should i look for identifying actual problem?
[13:42] <weedmic> something like this but for sound cards - proc /etc/cpuinfo?
[13:44] <weedmic> nvm - i found my receipt
[13:44] <Pici> weedmic: theres lshw
[13:44] <weedmic> ok, great
[13:59] <weedmic> Pici: that's nice - even lists chips on the mobo - ty
[14:30] <teward> TJ-: alive?
[14:37] <TJ-> teward: parts of me are; not sure about the brain though!
[14:38] <teward> lol
[14:38] <teward> TJ-: that nginx patch you submitted, you might want to give it a shot at upstream consideration.
[14:38] <teward> because it's more complex than simply adding a 'sleep' like other patches have done
[14:38] <teward> and MIGHT actually solve the issue permanently
[14:38] <teward> was suggested in discussion with one of the upstreams
[14:39] <TJ-> teward: really? hmmm... OK, I'll fire it to the mailing list then
[14:39] <TJ-> teward: "as a basis for discussion of the underlying issue" :)
[14:39] <teward> yep make sure you read their guidelines.
[14:39] <teward> and yes lol
[14:40] <teward> http://nginx.org/en/docs/contributing_changes.html?
[14:40] <teward> needs to be an hg changeset but meh
[14:40] <teward> would like to test on cent but i'm lazy :p
[14:41] <TJ-> I've never used nginx :)
[14:48] <teward> lool
[15:49] <kinghat> how do i turn off the lock that ubuntu server puts on when you login preventing upgrades?
[15:51] <kinghat> https://paste.debian.net/hidden/7ce97532/
[16:22] <teward> kinghat: do you have unattended-upgrades installed and enabled?
[16:28] <kinghat> not sure it was just a default server install
[16:36] <teward> i'd advise you check, `sudo apt-cache policy unattended-upgrades` will tell if it's installed
[16:36] <teward> if it is, chances are what you're seeing are unattended upgrades doing its thing
[16:36] <teward> it's not when you *login* that it locks, its when unattended-upgrades runs it locks
[16:36] <teward> so you just wait
[16:50] <RoyK> teward: check ps axf output - I guess there's an apt process running already
[16:51] <teward> kinghat: ^
[16:51] <teward> RoyK: kinghat needs the help :)
[16:52] <kinghat> https://paste.debian.net/hidden/a56a2031/
[16:53] <teward> OK so it's isntalled.
[16:53] <teward> kinghat: check `ps axf` output for anything apt or dpkg related
[16:53] <teward> see what it says
[16:53] <teward> (as RoyK suggested)
[17:26] <kinghat> trying to extract this on server: https://paste.debian.net/hidden/bffdecb8/
[17:31] <Odd_Bloke> kinghat: That suggests it isn't a valid ZIP file.
[17:32] <kinghat> extracted the archive fine on desktop
[17:33] <Odd_Bloke> kinghat: Did it definitely transfer successfully?
[17:33] <Odd_Bloke> (I'd suggest comparing checksums to be sure.)
[18:37] <ahasenack> rbasak: still around?
[18:37] <ahasenack> rbasak: I could use some hints with dpkg-maintscript-helper rm_conffile, it's not doing what I expect
[18:40] <rbasak> o/
[18:41] <ahasenack> issue is after the install of the new package, i still have:
[18:41] <ahasenack> -rw-r--r-- 1 root root 121 Oct 26  2017 /etc/default/ipmidetectd.dpkg-remove
[18:41] <ahasenack> I wanted it gone
[18:41] <ahasenack> so let me paste the maintscript file I have, and versions
[18:43] <ahasenack> rbasak: https://pastebin.ubuntu.com/p/sCN6NxkfBx/ has versions, d/*.maintscript*, and the rendered ones in /var
[18:44] <ahasenack> my expectation when upgrading from 1.5.7 to 1.6.1 was to have that file removed (I didn't change it)
[18:44] <rbasak> Looking
[18:48] <ahasenack> it's no longer shipped in the 1.6.3 (sorry, I meant 1.6.3 above, not 1.6.1) package even
[18:49] <rbasak> ahasenack: I don't see why that wouldn't work.
[18:49] <rbasak> ahasenack: if you're sure that the code you're running is the code you're seeing, etc, then I'd instrument the maintainer scripts with set -x and echo "$@" next
[18:50] <rbasak> ahasenack: and then see if running line 37 from your pastebin afterwards doesn't delete it, and if not why not (I think you need to set environment variables to mimic a maintainer script environment like DPKG_MAINTSCRIPT_NAME
[18:50] <rbasak> )
[18:51] <ahasenack> ok
[18:52] <ahasenack> it was going just like the manpage said
[18:52] <ahasenack> the name *.dpkg-remove is indicative that it decided the file wasn't changed
[18:52] <rbasak> Yeah
[18:52] <ahasenack> so the next script could remove it
[18:52] <ahasenack> but didn't
[18:52] <rbasak> So the only question is why the postinst doesn't remove it
[18:52] <ahasenack> ok, let me add some -x, see how it's called
[19:02] <ahasenack> rbasak: I added the dist-upgrade output, I forgot to add it before. Just for completeness. But we can see the maintainerscript acting in there for other files: https://pastebin.ubuntu.com/p/8Dj9t92nNF/
[19:03] <ahasenack> basically "Installing new version of ..."
[19:21] <ahasenack> rbasak: does this shed any light on the issue, or not yet? https://pastebin.ubuntu.com/p/ykNgxhdhDP/
[19:21] <ahasenack> my next step is to call that interactively, setting any required env var
[19:22] <rbasak> ahasenack: I agree with you. That line is definitely running then.
[19:23] <ahasenack>  /usr/bin/dpkg-maintscript-helper has a "debug" statement, let me see if I can find out how to activate it
[19:25] <ahasenack> DPKG_DEBUG
[19:25] <ahasenack> ok
[19:56] <ahasenack> rbasak: got it!
[19:56] <rbasak> Now I'm in suspense!
[19:56] <ahasenack> rbasak: the previous version, 1.5.7-2ubuntu1, due to a bug in that version, was never fully installed
[19:56] <rbasak> Ah!
[19:57] <ahasenack> it's a bug I'm fixing in this update (well, debian fixed it)
[19:57] <ahasenack> but that was enough for postinst to not consider it an upgrade
[19:57] <ahasenack> so instead of the helper being called like this:
[19:57] <rbasak> I wonder if that's a dpkg-maintscript-helper bug.
[19:57] <ahasenack> + dpkg-maintscript-helper rm_conffile /etc/default/ipmidetectd 1.6.3-1.1ubuntu1~ freeipmi-ipmidetect -- configure 1.5.7-2ubuntu1
[19:57] <ahasenack> it was called like this:
[19:57] <ahasenack> + dpkg-maintscript-helper rm_conffile /etc/default/ipmidetectd 1.6.3-1.1ubuntu1~ freeipmi-ipmidetect -- configure
[19:57] <ahasenack> no version at the end
[19:57] <ahasenack> as one parameter
[19:58] <ahasenack> the version comparison, to see if finish_rm_conffile should be called or not, is
[19:58] <ahasenack>                 if [ "$1" = "configure" ] && [ -n "$2" ] &&
[19:58] <ahasenack> since $2 was ""...
[19:58] <ahasenack> the renamed conf file was left over
[19:59] <ahasenack> sorry, I mean the version comparison is going to be called if $2 exists, but it didn't
[19:59] <ahasenack> https://pastebin.ubuntu.com/p/wVjdpRJKKv/ is the bit in the helper
[20:02] <rbasak> ahasenack: oddly though your pastebin in https://pastebin.ubuntu.com/p/ykNgxhdhDP/ doesn't show that in line 7 though? That one does have the version.
[20:03] <ahasenack> rbasak: that was installing the same package over it, I'm ashamed to say
[20:03] <ahasenack> I didn't bother to downgrade
[20:03] <rbasak> ahasenack: it's an interesting interaction nonetheless, and one I think is worth documenting somehow.
[20:03] <ahasenack> and repeat the test
[20:03] <powersj> teward, congrats!
[20:03] <teward> powersj: thank you :)
[20:03] <rbasak> I'm not sure it's possible to fix easily in dpkg-maintscript-helper, but probably worth a bug regardless so this slightly surprising behaviour won't send someone else down your rabbit hole :)
[20:04] <ahasenack> rbasak: maybe the weird thing is that preinst didn't seem to mind the previous package was in a failed state
[20:04] <ahasenack> and it did its thing
[20:04] <rbasak> ahasenack: I believe that's expected behaviour though
[20:04] <rbasak> ahasenack: the error states and required unwinds are well specified: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#summary-of-ways-maintainer-scripts-are-called
[20:04] <ahasenack> I bet they are :)
[20:05] <powersj> slashd, congrats as well!
[20:05] <ahasenack> iF  freeipmi-ipmidetect              1.5.7-2ubuntu1              amd64        GNU IPMI - IPMI node detection tool
[20:05] <powersj> woops lol
[20:05] <ahasenack> rbasak: that's the state I was starting with^
[20:06] <powersj> meant ddstreet, congrats as well!
[20:06] <rbasak> ahasenack: that makes sense.
[20:06] <rbasak> ahasenack: it does seem wrong though that .dpkg-remove can ever end up outlasting the upgrade after the error state is repaired.
[20:07] <ahasenack> rbasak: https://pastebin.ubuntu.com/p/cpq7YKQpSz/ line 44:preinst ; line 140:postinst
[20:08] <ahasenack> so line 144, which is -n "$2", sees an empty $2
[20:08] <ahasenack> and skips the rest of the removal code
[20:08] <ahasenack> and we are left with /etc/default/ipmidetectd.dpkg-remove at the end
[20:11] <ahasenack> is this interesting enough to email ubuntu-devel@?
[20:11] <ahasenack> or just expected
[20:11] <ahasenack> expected in retrospect, I mean :)
[20:11] <ahasenack> it's never expected when it happens :)
[21:09] <DK2> https://imgur.com/a/oWwlbdC any idea what is broken here? server refused to boot
[21:13] <solderfumes> <DK2 "https://imgur.com/a/oWwlbdC any "> Not enough info to be sure. The System DBUS failed to start for some reason? Is your rootfs writable?
[21:14] <DK2> solderfumes: trying got a livesystem now
[21:53] <rbasak> ahasenack: interesting enough to file a bug against dpkg-maintscript-helper I think.
[21:53] <rbasak> The user story you have there doesn't clean up .dpkg-remove as expected.
[21:53] <rbasak> Though since it's cruft it'll probably be low priority, and there isn't an obvious way to fix it I don't think.
[22:48] <tobias-urdin> coreycb: sending now so i dont forget the details, troubleshooting the puppet CI being broken for ubuntu for some month(s) now
[22:48] <tobias-urdin> http://logs.openstack.org/04/665704/1/check/puppet-openstack-integration-5-scenario001-tempest-ubuntu-bionic-mimic/f4cd240/logs/nova/nova-compute.txt.gz#_2019-06-17_15_55_04_732
[22:49] <tobias-urdin> so we install using the nova-compute-qemu (or kvm package), this pulls "qemu"
[22:49] <tobias-urdin> qemu should pull qemu-system "Depends: qemu-system (>= 1:2.11+dfsg-1ubuntu7)"
[22:50] <tobias-urdin> but it doesn't, so there is no x86 emulator binary since qemu-system provides (pkg: qemu-system-x86) isn't pulled in
[22:51] <tobias-urdin> so nova-compute-qemu depends on "qemu", "nova-compute-libvirt", but the "qemu" doesn't depend in "qemu-system" provides properly
[22:51] <tobias-urdin> if i install "qemu-system" or "qemu-system-x86" directly it works
[22:52] <tobias-urdin> you can see repos and dpkg
[22:52] <tobias-urdin> http://logs.openstack.org/04/665704/1/check/puppet-openstack-integration-5-scenario001-tempest-ubuntu-bionic-mimic/f4cd240/logs/apt-cache-policy.txt.gz
[22:52] <tobias-urdin> http://logs.openstack.org/04/665704/1/check/puppet-openstack-integration-5-scenario001-tempest-ubuntu-bionic-mimic/f4cd240/logs/dpkg-l.txt.gz
[22:52] <tobias-urdin> hopefully i'll hear from you later today :)