[00:43] <trippeh> my seagates are like that, never caused issues
[00:43] <trippeh> as far as I understand, modern drives are so dense they are correcting all the time.
[00:45] <trippeh> as long as you dont have any pending or reallocated sectors it is prob fine
[01:03] <drab> trippeh: thanks for the data point
[01:03] <drab> trippeh: the output on those seagate is weird and very diff than my HGST or any other disk I've seen really, tyhere's now raw data table
[01:04] <drab> so I can't see the reallocated sectors for example
[01:04] <drab> the link above suggested looking at "Elements in grown defect list: 0"
[01:05] <drab> and several others did the same
[01:05] <drab> these are seagate constellations btqw
[06:18] <cpaelzer> While I'm not up to speed yet I wanted to mention that today is again Bug Squashing Day https://wiki.ubuntu.com/ServerTeam/BugSquashingDay
[06:18] <cpaelzer> chair likely is just me for now
[06:18] <cpaelzer> rbasak: are you around already?
[06:52] <lordievader> Good morning
[06:59] <cpaelzer> hi lordievader, good morning to you as well
[07:12] <Deeps> hiya, is there a way to keep ubuntu from changing /home/$USER/.bash_history ownership back to root on apt upgrade / reboot, and purging the contents?
[07:12] <Deeps> running ubuntu 16.04.2 xenial
[07:13] <Deeps> i've manually reassigned ownership of that file to the user a couple of times, but after a reboot it seems to go back to root and have been blanked
[07:14] <sarnold> Deeps: I have never once seen that.
[07:14] <sarnold> Deeps: what have you installed that didn't come from the archive?
[07:16] <sarnold> Deeps: have you done any funny configuration of ~/.bashrc or ~/.bash_profile? any funny pam modules? any funny /etc/profile or /etc/profile.d/ games?
[07:16] <Deeps> best i can tell, nothing particularly exciting on there at all
[07:16] <Deeps> http://paste.ubuntu.com/24458832/
[07:17] <sarnold> looks pretty normal
[07:20] <sarnold> Deeps: you could install auditd and add a file watch rule on the file. once auditd is installed, edit /etc/audit/audit.rules and add a line -w /home/deeps/.bash_history -p wa
[07:20] <sarnold> Deeps: then /var/log/audit/audit.log would contain information on the process that modified the file
[07:21] <Deeps> http://paste.ubuntu.com/24458844/ like that?
[07:22] <sarnold> looks good; I think now systemctl restart auditd.service
[07:22] <Deeps> timestamping in the log file isn't very friendly, heh
[07:23] <sarnold> no it is not :)
[07:23] <Deeps> looks like it's working, i manually changed it back to ownership of me and got this in the logs http://paste.ubuntu.com/24458852/
[07:24] <Deeps> will see what resets it next time, thanks for the help
[07:24] <sarnold> great, good idea to test right away
[07:25] <sarnold> aureport -f looks like a friendlier output view. neat.
[07:25] <Deeps> realised it's not a reboot that's doing it, as the box has been up 100 days and the bash history only got reset in the last week
[07:25] <Deeps> oh that is nice, cheers
[07:36] <lordievader> Hey cpaelzer, how are you doing?
[07:48] <cpaelzer> lordievader: good enough to complain as I always do :-)
[08:05] <lordievader> cpaelzer: Good, good :)
[08:08] <funabash1> hey guys how can i get more info about this process: tcp        0      0 127.0.0.1:5005          0.0.0.0:*               LISTEN      11500/6
[08:10] <cpaelzer> funabash1: 11500 should be the pid
[08:11] <cpaelzer> funabash1: so look around at things like
[08:11] <cpaelzer> ps axlf | less (search for 11500 in there)
[08:11] <cpaelzer> ls /proc/11500/* - ususally comm, exe and stat* are interesting there to start with
[08:19] <funabash1> cpaelzer: check this please, https://pastebin.com/ePPGe532
[09:07] <cpaelzer> funabash1: back now, reading
[09:09] <cpaelzer> funabash1: so the process is your sshd it seems
[09:09] <cpaelzer> not the common port for ssh but well
[09:09] <cpaelzer> funabash1: OTOH you might recheck if you still want to look for 11500, in case the pid just got reused by sshd
[09:10] <cpaelzer> funabash1: the first you posted was netstat output right?
[09:47] <rbasak> cpaelzer: yes, but the electrician's here so I may disappear suddenly :-/
[10:20] <funabash1> cpaelzer: i did kill it
[10:32] <rizonz> this is so strange,m preseeding servers using a 64bits only server cannot find some packages
[10:32] <rizonz> but they are there in 64 bits
[10:54] <Aison> is it possible to remove dash and only use bash?
[10:55] <ikonia> possible yes, sensible no
[10:55] <ikonia> why not just use bash where you want,
[10:58] <Aison> k
[12:27] <rbasak> cpaelzer: add bug 1683237 to your list of why you should have core dev please :)
[12:28] <cpaelzer> hehe, yeah correct
[12:30] <cpaelzer> xnox: are you Mr. systemd now?
[12:30] <xnox> cpaelzer, probably....
[12:30] <cpaelzer> enough commitment :-)
[12:31] <cpaelzer> xnox: fyi I have come to this while triaging server bugs (and duped something onto it) but wanted to make you aware of bug 1624317
[12:32] <cpaelzer> reading the comments there it seems that might get some extra hot-ness now that zesty is releases with systemd-resolved
[12:32] <xnox> cpaelzer, my networking know-how is low; thus most of the resolved/networkd bugs are beyond me =/ i do my best, but some help in that area would be good.
[12:33] <xnox> in like trianging and telling what things do. I can write code and send it upstream, but e.g. i have never knowngly ran split-horizon DNS or how that supposed to work correctly.
[12:35] <cpaelzer> me neither, I just happened to follow the "dns leak argument" in the other bug until I realized they were the same
[12:46] <cpaelzer> TafThorne: thanks for starting to verify the logrotate issue on Xenial
[12:46] <cpaelzer> TafThorne: do you think you can do the other releases as well over the next few days?
[12:46] <TafThorne> cpaelzer: No problem.  I'll need to fire up some fresh VMs after finding install images to do the others.
[12:47] <cpaelzer> TafThorne: no pressure, just wanted to know if that task is with you
[12:47] <cpaelzer> TafThorne: thank you in advance
[12:49] <TafThorne> cpaelzer: I should be able to install a Trusty and Yakkety Vm... although I might also have a Trusty PC somewhere here that I could test on easily enough.  That would be faster.
[12:50] <ahasenack> TafThorne: have you tried lxd instead of vms?
[12:50] <TafThorne> Never before.  I could try that
[12:50] <ahasenack> it's even faster
[12:51] <ahasenack> TafThorne: what's your base distro?
[12:51] <ahasenack> where you work?
[12:52] <ahasenack> TafThorne: http://pastebin.ubuntu.com/24459990/
[12:53] <ahasenack> then import your ssh key, and you can ssh into it
[12:59] <TafThorne> ahasenack: 16.04
[12:59] <TafThorne> ahasenack: Basingstoke, UK
[12:59] <ahasenack> TafThorne: should work just fine
[13:00] <TafThorne> ahasenack:cool thanks.  That would be much faster.
[13:01] <TafThorne> ahasenack: Can I go down as well as up?  So `lxc launch ubuntu:trusty` or somilar?
[13:01] <ahasenack> TafThorne: yes, even precise
[13:01] <ahasenack> or debian
[13:01] <ahasenack> or many others
[13:06] <ahasenack> TafThorne: if this is the first time you are installing lxd, the only gotcha is that you have to add yourself to the lxd group before using the commands, which means a logout/login sequence or some other trick
[13:13] <TafThorne> ahasenack: thank you for the warning.  I have a terminal installing the client.  I'll add myself to the group now.
[13:15] <TafThorne> (i'll have to remember the syntax for that before I add a user named TafT to a a group named useradd but I can work that out with GOogle in a few seconds)
[13:19] <ahasenack> I use gpasswd -a <user> lxd
[13:19] <TafThorne> I have gone with `usermod -a -G lxd <user>`
[13:21] <TafThorne> Should be the same result.  I'll not try and fancy jumping though hoops.  I will just `sudo login` as me again in a terminal.  That should be enough to confuse me tomrro wwhen I look at the console agian.
[13:22] <TafThorne> `groups` suggests I am added. Time to follow he paste.
[13:25] <TafThorne> ahasenack: That was quite quick to get started.  http://pastebin.ubuntu.com/24460153/ Now I guess everthing else is like any other headless terminal.  I go set-up to use -propose, install the package and run the test case?
[13:32] <ahasenack> TafThorne: yeah
[13:32] <ahasenack> it took 27s because it had to download the image, I had it cached already
[13:32] <ahasenack> TafThorne: try "lxc image list" and "lxc list"
[13:33] <ahasenack> TafThorne: since you didn't run "lxd init" before launching the container, I'm not sure how your networking is setup, lxc list should tell if your container got an ip or not
[13:54] <TafThorne> ahasenack: does not look like it has an IP
[13:54] <ahasenack> TafThorne: I'd suggest to tear it down then and then run sudo lxd init and follow through the setup wizard that it runs
[13:55] <TafThorne> ahasenack: will do.  I'll get back to it when I am at a good point to logout and login agian to sort all that out too.
[13:55] <ahasenack> ok
[17:45] <drab> urm
[17:45] <drab> I've been running qemu in console on my desktop for testing and it works fine
[17:46] <drab> I moved the same script to a remote server and when I try to start it I get "Could not initialize SDL(No available video device) - exiting
[17:46] <drab> "
[17:46] <drab> however I was using qemu on my desktop from terminal, with -curses
[17:46] <drab> so not opening the GUI
[17:46] <drab> but you can't use -curses or -nographic with -daemonize (which seems to imply it)
[17:47] <drab> so I'm a bit lost... I can't use the paramters to tell qemu to not start a graphical env if I demonize it, which makes no sense to me
[17:47] <drab> any clue?
[17:48] <drab> I also tried -vga none and still get the same error
[18:04] <ahasenack> drab: what's the command line you are using?
[18:04] <ahasenack> drab: you can test locally on your desktop by unsetting DISPLAY probably, that would replicate the remote case
[18:05] <ahasenack> drab: also try -display none
[18:05] <ahasenack> or -display vnc and the vnc parameters (see manpage), these don't require DISPLAY (the shell var, for X access) and work with -daemonize
[18:06] <drab> ahasenack: /usr/bin/qemu-system-x86_64 -enable-kvm -name test -machine type=ubuntu,accel=kvm,usb=off -cpu host -smp 1 -m 2G -netdev bridge,br=lxdbr0,id=qemubr -device virtio-net-pci,mac=52:54:00:11:01:18,netdev=qemubr,id=eth0 -drive file=test/rootfs.raw,format=raw,id=root,if=none -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=root -boot dn -monitor unix:test/mon.sock,server,nowait -pidfile
[18:06] <drab> test/instance.pid
[18:06] <drab> then with -daemonize at the end or -curses
[18:06] <drab> right now I'm going through an install with -curses on the remote server for testing
[18:07] <drab> so that works fine
[18:07] <drab> ahasenack: I'll try -display none, thanks, vnc seems a good workaround too
[18:08] <ahasenack> drab: do you need the console to drive things interactively?
[18:09] <drab> no, it's all preseeded, ultimately I don't want any console
[18:09] <ahasenack> ok, then -display none should work I think
[18:09] <drab> trying, thanks
[18:09] <ahasenack> -nographic is another one
[18:13] <drab> ahasenack: it worked, thanks a lot
[18:13] <ahasenack> \o/
[18:13] <drab> anothe strange thing I noticed testing
[18:13] <drab> I have -boot dn
[18:13] <drab> but it always seemst o boot from network
[18:13] <drab> even tho the disk install is valid and -boot d will boot just fine
[18:14] <drab> and with -curses I stil see a complaint about not being able to boot cdrom, even tho I never ask it to boot from cdrom
[18:14] <ahasenack> isn't "d" the cdrom?
[18:14] <drab> oh, lol, I thought d was disk, n network
[18:14] <drab> my bad
[18:15] <drab> c cdrom
[18:15] <drab> should have doubel checked
[18:15] <ahasenack> yeah, c is "disk c", from windows fame
[18:15] <ahasenack> or pc bios, if you will
[18:15] <drab> you're right, man says d is cdrom
[18:16] <drab> thanks for catching that
[18:16] <ahasenack> np
[18:16] <drab> now I need to figure out my systemd unit and I'm all set
[18:16] <ahasenack> for systemd I'm not your guy :)
[18:17] <drab> it's actually not too bad to run qemu on its only, only took me 5 days and harassing half of the ppl in here :P
[18:17] <drab> its own*
[18:17] <drab> but there's no provision to start instances at boot so need to write your own glue
[18:17] <drab> this looks promising tho: https://kissmyarch.de/archives/2014/02/28/qemu_systemd_service/index.html
[18:18] <drab> at least that's how that guy did it and it seem a reasonably clean soluition
[18:18] <drab> stop/reset on socket works like a charm, already using that to interact with daemonized instance
[18:18] <ahasenack> have you tried libvirt and virt-manager?
[18:18] <ahasenack> you can use virt-manager to talk to remote qemu instances even, via ssh
[18:18] <drab> I have and I'm against violence
[18:18] <drab> :P
[18:18] <dpb1> lol
[18:19] <ahasenack> I just remembered it because libvit will start vms on boot if you want it to, and it can also be used remotely in a headless scenario
[18:20] <drab> yeah, I read about that, I gave it a try and decided not to go down that path, had too many problems right off the bat and since I'm mostly running lxd to make what looked like a big investment to figure it out didn't seem warranted
[18:21] <drab> basically I like magic as long as I understand the spell
[18:21] <drab> so I didn't trust myself to just point and click, not that it worked tho, couldn't get it to use my existing bridge for one
[18:22] <drab> I'm not saying it's bad, don't get me wrong, I hear lots of ppl happily use it in prod
[18:22] <drab> just didn't seem to be a good fit for me/what I'm doing even tho there was some upfront work involved this way too
[18:23] <ahasenack> sure
[18:37] <drab> anothe trying I'm trying to figure out, so far I always used -drive file=.... as I was dealing with image files
[18:38] <drab> but now I'd like to pass a partition of a disk to be used by KVM as a data mountpoint
[18:38] <drab> file= doesn't seem to be the right thing, but I can't google out what enchantment exactly I should use
[18:40] <drab> or maybe it is, just found something where they use lvm vols straight in file= syntax
[18:47] <drab> \0/ worked
[18:48] <drab> whups, cyclop