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