[06:03] <lordievader> Good morning
[07:45] <peetaur2> Howdy. Since 18.04 doesn't have mcelog any more, what do you guys use?
[07:47] <peetaur2> for AMD you just load the edac_mce_amd driver, and grab "Hardware Error" stuff from syslog...but not sure what to do on intel
[08:24] <tomreyn> maybe rasdaemon
[08:27] <peetaur2> tomreyn: thanks ...  and reading about that, it seems it uses "kernel tracing events" and EDAC. And looking at the machine I wanted it on, it seems to have i7core_edac loaded (but it's a Xeon E5620). Maybe that means it'll already dump stuff in syslog.
[08:32] <tomreyn> ideally the firmware would detect events and log and handle them
[08:35] <sahid> jamespag I think we missed to update https://git.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/murano-dashboard
[08:35] <sahid> jamespage: ^
[08:35] <sahid> coreycb: ^
[08:35] <tomreyn> peetaur2: where that's absent (or just implemented for 1-bit errors, like on most ryzen / threadripper), relying on syslog and custom scripts in user space may be the only (unreliable) alternative. i'm (even) less experienced with intel in this regard, too.
[08:39] <peetaur2> tomreyn: I have other ways to get the event log...but I want something I can deploy with puppet and alert with nagios
[08:39] <peetaur2> not sure how to do that with the supermicro ipmi event log
[08:49] <sahid> coreycb: https://git.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/python-mimeparse/
[14:28] <Ussat> is system-storage-manager not avaliable in Ubuntu ?
[16:37] <lordcirth> Ussat, their site says it's Alpha
[16:37] <lordcirth> At least, the sourceforge download page does
[16:37] <Ussat> huh
[16:37] <Ussat> thats, odd since it has been i rhel since 7.X
[16:38] <lordcirth> Ah, project moved
[16:38] <lordcirth> https://github.com/system-storage-manager/ssm
[16:38] <Ussat> its a pretty standard utility, I like to have the same tools on each if possible
[16:38] <Ussat> I am just suprised there is not a package for Ubuntu
[16:39] <Ussat> oh well, thanks
[16:44] <lordcirth> Ussat, it doesn't sound hard to compile. You could submit it to Debian.
[16:50] <RoyK> ,v ssm
[17:05] <TJ-> Ussat: ssm was in Debian (and Ubuntu) but got removed. The project originally started on SourceForge around 2012 I think
[17:05] <Ussat> Why was it removed ?
[17:06] <TJ-> it's in 16.04
[17:06] <Ussat> I mean its all acedemic at this point,  ut why ?
[17:06] <TJ-> Ussat: bit-rot I think; unmaintained
[17:06] <Ussat> That is unfortunate
[17:06] <Ussat> its a usefull utility
[17:06] <TJ-> Ussat: see https://launchpad.net/ubuntu/+source/system-storage-manager/+publishinghistory
[17:08] <TJ-> Ussat: looks like people at RedHat took it up but Debian maintainer got lost around 2015 and it wasn't updated there
[17:10] <Ussat> Ya...I dont use it a LOT but its ion my standard install kit on rhel/cent
[17:10] <Ussat> in
[17:10] <Ussat> I mean, its not needed by any means, just conveniant
[20:01] <axisys> need help with removing an LV using preseed/late_command ..
[20:02] <axisys> d-i     preseed/late_command string umount /target/dummy/ did not unmount it...
[20:02] <axisys> still seeing /dummy after installation
[20:07] <tomreyn> it was probably in use?
[20:08] <lordcirth> If it was in use, the late_command would have failed, assuming it wasn't caught
[20:08] <tomreyn> there's an installation log stored at /target/var/log/
[20:41] <axisys> grep dummy /var/log/syslog does not show any unmount or mount related logs
[20:43] <axisys> i suppose I could add force or lazy option and rebuild the ISO and re-install
[20:53] <TJ-> axisys: are you seeing a file-system mounted on /dummy/ or just the mountpoint directory?
[20:54] <TJ-> axisys: if the latter, your late_command_string also needs to "rmdir /target/dummy"
[21:28] <axisys> TJ-: it is a separate partiton
[21:29] <axisys> TJ-: so yes /dev/mapper/system-dummy mounted on /dummy