[04:39] <cpaelzer> good morning
[12:15] <xnox> cpaelzer, -drive file=generic-2.qcow2,if=none,id=D21 -device nvme,drive=D21,serial=1233 -global nvme.physical_block_size=4096 -global pci.logical_block_size=4096
[12:15] <xnox> cpaelzer, gives me nvme drives, but still with 512 physical and logical sectors =(
[12:15] <xnox> cpaelzer, how can I have 4k? =)
[12:21] <xnox> cpaelzer, =) i think i'm just gonna patch qemu to bump 9 to 12, and recompile to get 4k by default =)
[12:22] <cpaelzer> hehe
[12:22] <cpaelzer> I haven't used 4k there yet, I would need to check docs and experiment as well
[12:29] <cpaelzer> xnox: not sure if that helps, but passing through full devices works with different blpock sizes
[12:30] <cpaelzer> but I assume you want 4K on the qcow that is as file on a 4K device?
[12:30] <xnox> hmmm... i was hoping to fake 4k inside qemu
[12:31] <cpaelzer> oh just faking
[12:31] <cpaelzer> not insisting on what really happens then?
[12:31] <xnox> i have a bug report that grub-installer fails on 4k intel matrix raid and nvme
[12:31] <xnox> in uefi mode
[12:32] <xnox> i got uefi, i got nvme drives, i even have intel matrix raid inside the kvm, it's just the 4k is what is missing atm
[12:35] <cpaelzer> xnox: try a raw file instead of qcow and all tunables bumped up to 4k
[12:35] <cpaelzer> xnox: -device nvme,drive=drv0,serial=foo,opt_io_size=4096,min_io_size=4096,logical_block_size=4096,physical_block_size=4096
[12:39] <cpaelzer> xnox: is that looking better from your installers POV then?
[12:42] <xnox> cpaelzer, nope, i still get 512 in /sys/devices/*/queue/physical_block_size
[12:42] <xnox> i fear it's not supported option for nvme =/
[12:43] <cpaelzer> it is listed in qemu-system-x86_64 -device nvme,help
[12:45] <cpaelzer> xnox: yeah my test system also only gets 512 on that :-/
[12:49] <cpaelzer> xnox: does it (for the bug) have to be nvme to the guest?
[12:53] <cpaelzer> xnox: yeah with virtio-blk I got 4k immediately
[12:53] <cpaelzer> must be with the device being set up as nvme
[12:53] <cpaelzer> but since the arguments of nvme suggest they would work there this is odd
[12:53] <cpaelzer> maybe on nvme there are mor constraints (e.g. can not fake it)
[12:59] <xnox> cpaelzer, looking at the code, i do not see it set that stuff up.
[13:00] <cpaelzer> so it might be really not avail for nvme yet
[13:00] <xnox> cpaelzer, well. we don't know for sure. Let me try with virtio-blk i guess
[13:52] <jamespage> coreycb: ok so I'm in dep hell
[13:53] <jamespage>  python3-networking-bgpvpn : Depends: python3-django-horizon but it is not installable
[13:53] <coreycb> jamespage: ah.. yeah i think horizon is not fully py3 yet
[13:56] <coreycb> dosaboy: sorry i missed the meeting
[14:00] <coreycb> jamespage: i'll take a look at horizon now if you didn't start on it
[14:00] <jamespage> coreycb: its blocking me so let me take it
[14:00] <coreycb> jamespage: ok
[16:14] <Ussat> so I am having a HELL of a time with this: I run logcheck thus: su -s /bin/bash -c "/usr/sbin/logcheck" logcheck
[16:14] <Ussat> and this is the output:  sort: cannot read: '/tmp/logcheck.luiR3D/logoutput/*': No such file or directory
[16:15] <Ussat> any idea why that error is being thrown ?
[16:15] <Ussat> I know the file does not exist, but I am wondering what is telling it to look there ?
[16:35] <avgtechie> probably something in the script /usr/sbin/logcheck
[17:10] <Ussat> Yea I found it......was going from a very old version to a new server new version...
[17:10] <Ussat> flags etc changed, but got it
[19:58] <runelind_q> will 16.04 ever get 4.15 kernel or will I have to upgrade to 18.04 for that?
[19:59] <sarnold> runelind_q: looks likeone is sitting in -proposed at the moment https://launchpad.net/ubuntu/+source/linux-hwe
[20:00] <sarnold> my guess is when the next 16.04.x point release is shipped
[20:00] <nacc> i believe aug
[20:00] <nacc> per the lts page
[20:00] <nacc> !hwe
[20:03] <runelind_q> cool, don't see much of a reason to upgrade to 18.04 on my lxd box then.
[20:03] <sarnold> definitely wait on 18.04.1 if you're thinking of it
[20:03] <runelind_q> well you have to wait for 18.04.1 anyways to upgrade-in-place, right?
[20:04] <nacc> you can force it
[20:04] <nacc> iirc
[20:05] <runelind_q> meh, I'm not too worried about it.
[20:05] <runelind_q> this box just does lxd and I'm more worried about stability
[20:06] <nacc> runelind_q: yes, i wouldn't bother upgrading then
[20:08] <runelind_q> especialy if 16.04 will eventually get 4.15
[20:09] <runelind_q> 4.4->4.15 seems like a big jump though.
[20:09] <nacc> runelind_q: well, if you're on hwe, you will already be at 4.13
[20:09] <nacc> if you're not on hwe, you will stay on 4.4
[20:10] <runelind_q> hwe?
[20:11] <runelind_q> reading about it now
[20:12] <runelind_q> is hwe recommended?
[20:18]  * runelind_q #yolo
[20:25] <runelind_q> catch you on the flip side, I hope :)
[20:47] <runelind_q> nacc: 4.13.0-45-generic seems to work fine so far.
[21:35] <nacc> runelind_q: "recommended" is hard to say
[21:35] <nacc> runelind_q: if your hardware works great in 4.4, there's no particular reason to use HWE
[21:36] <runelind_q> now you tell me ;p
[21:36] <nacc> runelind_q: HWE = HardWare Enablement stack
[21:37] <runelind_q> makes sense I guess.
[21:42] <JanC> I guess the newer kernel might also be useful for other things, but you always risk that something breaks or gets worse too  :)
[21:42] <runelind_q> like SSH going non-responsive :D
[21:43] <nacc> JanC: yeah, in principle it does enable other "features", but the primary use-case is the hardware stack
[21:43] <nacc> most users are not aware of kernel features outside of the hardware support, tbh
[21:44] <sarnold> /dev/urandom is a thousand times faster
[21:45] <nacc> heh
[21:46] <sarnold> 13.4 MB/s on my xeon running 4.4 and 203 MB/s on my i7 laptop running 4.15
[21:52] <runelind_q> heh, interesting, SSH locks up to the LXD box itself, but not containers running on that box O.o
[22:52] <keithzg> Hrmmm, weird, trying to set up Samba shares on a machine and I'm getting NT_STATUS_NO_SUCH_USER for a user that's most definitely a user account local to the samba server machine.
[22:52] <keithzg> It's been so long since I've had any problems setting up samba!
[22:58] <genii> Samba usernames are not neccessarily the same as local account usernames
[23:00] <nacc> keithzg: yeah, I think that is not finding your username in the AD?
[23:01] <keithzg> Hrmm. Well if I'm *running* AD it sure isn't intentionally, heh
[23:01] <nacc> keithzg: samba can also act as the AD
[23:03] <keithzg> nacc: Sure; thing is, I'm at a loss for what the difference is, I just compared the smb.conf file from an entirely working server here at the office and it's likewise unchanged other than adding shares. So I would have assumed things to Just Work in the same way.
[23:03] <nacc> keithzg: ack, i honestly don't use samba at all, just spitballing :)
[23:04] <keithzg> nacc: Alas, I work in an office where 90% of people are running Windows, so it's a necessary evil . . .
[23:05] <keithzg> This right now is part of my plan of slowly trying to change things over from "all computers have network shares that allow any guest users full control", heh
[23:06] <sarnold> keithzg: take a look at smbpasswd, hopefully that'll get you in the right direction for a username/password combo that works
[23:08] <keithzg> sarnold: Err but the problem is that I need to do more than just creating some new credentials that work, I need this to automatically work for all users that'd be valid on the machine itself :(
[23:08] <keithzg> It's hard enough getting users to create one password and actually remember it!
[23:09] <keithzg> Anyways even trying to set it via smbpasswd I get NT_STATUS_ACCESS_DENIED
[23:09] <Gobo708> Hi All, simple but frustrating one... does anyone know how to change the hostname? I have tried setting local loopback in /etc/hosts first, to ensure this is not interfering. I have tried hostnamectl set-hostname newhostname, I have tried editing /etc/hostname
[23:10] <Gobo708> This is a  VM btw
[23:10] <nacc> dpb1: --^ did the default setting change for cloud-config? https://ubuntuforums.org/showthread.php?t=2389098&page=2&s=d1d6765c0fda139a3be80b3f6fcdcfa7
[23:10] <Gobo708> There is mention that you need to edit /etc/cloud/cloud.cfg and set preserve_hostname to true, but cloud.cfg states that this will prevent set hostname from working.... so *shrug*
[23:11] <sarnold> Gobo708: I haven't tried changing a hostname but fixing /etc/hosts and /etc/hostname then rebooting feels like it ought to have done the trick
[23:11] <nacc> dpb1: s/config/init/ -- not great when a forum post suggests removal of cloud-init as the workaround
[23:11] <keithzg> Yeah anytime I've needed to change a hostname, nothing more than /etc/hosts and /etc/hostname has been required.
[23:11] <nacc> Gobo708: do you actually have a cloud.cfg currently?
[23:11] <sarnold> keithzg: hrm in ten seconds of searching I didn't spot any docs online about using pam_unix in samba.. but instructions for the other way around, using pam_winbind for other services ..
[23:12] <Gobo708> from cloud.cfg #This will cause the set+update hostname module not to operate if (true)
[23:12] <Gobo708> I will try rebooting again, in case it may have worked
[23:14] <Gobo708> nacc, I think setting local loopback may have been interfering
[23:14] <Gobo708> nacc, with /etc/hosts set correcty, after reboot it stuck
[23:16] <keithzg> sarnold: Yeah, and the perplexing thing is I swear I didn't really do much at all to get this working on other servers before; I really thought it Just Worked by default, but it sure isn't on this one server! Admittedly the problem one is running 18.04---hopefully this isn't something I have to look forwards to when I finally upgrade the others!
[23:18] <nacc> Gobo708: ok
[23:19] <Gobo708> nacc, thanks for your time ;)
[23:46] <keithzg> I'm finding it increasingly perplexing that the use-case of using standard PAM authentications for Samba seems so poorly documented . . .
[23:51] <nacc> keithzg: in his tz, ahasenack may be able to help
[23:53] <sarnold> given the ntlm2 wireformat for authentication it may not really be feasible to use pam_unix
[23:53] <keithzg> sarnold: Tjat
[23:53] <sarnold> you might be stuck having to manage an AD thing
[23:54] <keithzg> err, that's fair enough, but theoretically the samba password database should be able to sync with PAM.
[23:54] <keithzg> That seems to be the modern solution to that. But I've yet to find any documentation of that officially, and all the unofficial documentation seems to be woefully out of date or incomplete itself.
[23:56] <keithzg> Ex. apparently in 14.04 there was a package libpam-smbpass, but it sure doesn't seem to exist before *or* after trusty . . .
[23:59] <sarnold> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799840