[06:27] good morning [07:00] Good morning [07:39] g'morning lordievader [07:39] better late than never :-) [07:54] Hey cpaelzer [07:54] How are you doing? [07:54] the same as always I guess (today doesn't feel special) [07:54] and you? [07:55] Doing good here, got coffee [09:07] hey all, when installing Xenial over net-install (iPXE) in UEFI mode, the installer seems to run just fine, but I get a black screen post-boot (right where GRUB should be) [09:07] is there a preferred way to net-install Xenial in UEFI? [09:09] I don't believe it's a hardware problem, because I can BIOS-compat-mode install just fine [09:09] this is on a Dell R630 [09:09] hello [09:10] How could I figure out if the kernel package 4.4.0.116.122 from xenial-proposed includes the fix from LP 1738219 ? [09:10] Launchpad bug 1738219 in linux (Ubuntu Bionic) "the kernel is blackholing IPv6 packets to linkdown nexthops" [Medium,In progress] https://launchpad.net/bugs/1738219 [13:28] I want to install Ubuntu server and afterwards install a desktop env. When I don't start the GUI (but it is present on the system) will the server still be less lean than without the installed GUI? I'm talking about procesor time, not disk space. [13:32] yes [13:32] there are non-gui parts that desktop installs [13:33] will it be noticable? shouldn't be [13:33] "install a desktop env" will install those though [13:33] Depends on what you mean exactly by "start the GUI". [13:34] If you're asking if boot time (in terms of CPU) will be less what you don't "start the GUI", then the answer is obviously yes. [13:34] it's for a home nas, but from time to time i want to be able to browse and other things, because the computer is in another room where there are no kids, so piecefull and quite :D [13:34] so in normal mode i only want it to be in console mode [13:35] Why? [13:35] What benefit is there to it being in console mode? [13:35] it stays on the whole day, so I think it's a waste of energy if it consumes (lot) more because I intalled the desktop packages [13:35] It won't use any more energy on an ongoing basis. [13:36] Waiting on a desktop login screen should use no additional CPU whatsoever. [13:36] good, even if it stays in GUI mode? [13:36] nice, thanks for that info [13:36] You might want to measure it to be sure though. I'm not accounting for any bugs. [13:37] I suppose once a minute it might bump a clock up or something. But that'd probably be an insigificant and unmeasureable amount of CPU in terms of energy costs. [13:37] hehe, it's not that big of an issue, but when the cpu starts consuming 100% more power it is [13:37] It should definitely not be doing that. [13:38] If it does, it's a bug. [13:38] I'm not aware of any such issue though. I expect we'd get reports quite quickly if that were to happen. [13:38] ok, then I just leave it on GUI login. thanks for the info! [13:40] coreycb: OK so I've done some further repacking on the pxc-5.7 tarball and I'm pretty happy with it - I'd like to merge jp-review-fixes into master and then upload for bionic if you're good with that? [13:42] jamespage: i think so. did you see my latest change to xtrabackup for boost? [13:43] jamespage: i still need to test that ^ [13:43] coreycb: I had not [13:45] jamespage: your latest changes look good. I think we just need to align the boost changes. [13:48] firefox is always using 100% cpu :( === rharper` is now known as rharper [18:02] jamespage: i'm working through the rc2's [18:03] coreycb: good man [18:03] coreycb: I've tested my latest pxc-57 - works OK - slightly unhappy with the internal server versioning [18:05] coreycb: but its the same as with -56 so not going to stress - that's polish now... [18:06] jamespage: ok [18:19] coreycb, cpaelzer: ovs 2.9.0 uploaded to bionic btw [18:19] jamespage: awesome [18:53] great jamespage [18:54] jamespage: I see no new OVS in proposed btw [18:54] ok it is the arm build that stalls [18:54] https://launchpad.net/ubuntu/+source/openvswitch/2.9.0-0ubuntu1 seems good so far [19:06] any good guesses why gbit ethernet seems to give only ~400-500mbits/s on 16.04.3 servers? same switch with same cables/ports have been tested to get ~940mbits/s between my laptop and a debian host. ...can it be that the NICs are just crappy? [19:06] (all cables less than 2m long, cat5e or cat6) [19:08] i found some threads on the r8169 driver being buggy, but those mainly seem to roll about getting 1000mbit link speed negotiated to start with. [19:08] ethtool is showing full duplex and 1000 speed just fine. [19:16] Tulitomaatti: realtek isn't know for high-quality drivers :/ how are you testing? maybe you need larger window sizes or similar? [19:17] default iperf with plain -s / -c. though, those do get me 940 between other devices than the 4 identical nodes i'm debugging. [19:22] lshw shows that the NIC is on a "82801 Mobile PCI Bridge" instead of the other stuff on "NM10/ICH7 Family PCI Express Port 1" [19:23] could a mobo maker slam a gbit nic on a bus that is slower than gbit? sounds unlikely. iperf to localhost gives over 5gbits/s. [19:32] I'd certainly hope a pci bridge could keep up with gigabit, that's pretty slow these days .. but maybe if they figured the average internet connection is 30mbps that no one would notice :( [19:36] Tulitomaatti: could the spectre fixes have anything to do with the degraded performance? [19:36] do you have data from before those updates? Or, do the machines which perform better have these security fixes applied? [19:38] i installed these about last week, so no data there. IIRC these atoms are old enough not to be affected by one of those bugs. [19:38] (d2550) [19:39] i guess i could try to boot to a live system of something else and see if the problem persists. [19:39] yes [19:39] any recommendations? [19:39] whatever debian and your laptop are running that gave you 940mbps? [19:43] os x on the laptop. but i guess debian should be fine as the server that works with 940 with the laptop is debian. [19:43] was asking just in case a some kind of ultimate network debugging image livedistro was floating around, that i didn't know about. [19:53] Tulitomaatti: I'm fairly certain that those old atom boxes are affected by meltdown at least so there is KPTI that could get in the way [19:56] mm. – the debian server is an even older atom (d510? pineview?). that being said, is there an easy way to see? iperf seems to take about... 56% cpu according to top, while transmitting. [19:57] (on one of the ubuntu nodes) [21:24] I have a server acting as nfs client. I want to mount /home to a location in a nfs drive [server:/opt/home] , But the root of the nfs drive will be elsewhere [server:/opt mounted to client:/opt]. Should I have two lines in fstab, one for the /opt mount and one for the /opt/home mount, or should I have only the /opt mount, and symlink /home to the location inside? [21:34] seems like it's not ubuntu-specific, or 4.13.0 specific: an ubuntu live image with 4.9.0 kernel also gets only "half" of the bandwidth that should be there. [21:34] i'm starting to guess at either crappy NIC or horrible drivers. or both. [22:00] Pinkamena_D: if I uncerstood you correctly, you are exporting both /opt and /opt/home separatedly from the server? [22:00] or is that part of the question, if you should? [22:11] ahasenack: part of the question [22:11] I think I would mount both separatedly on the client [22:11] First instinct would be to use a symlink to home, but I am struggling to think how exactly to create it onto a location I can not overwrite /home [22:12] Ok, I guess that is a logical solution [22:12] try it out, maybe the experiment will give you more data [22:12] you could also change the user's default homedir to be /opt/home [22:12] I am not in control of the server directly, but I found I can just mount two location like that when just the outer mountpoint is presented explicitly on the server [22:13] so it definitly 'works', I just wanted to check best practice [22:14] so the server is exporting just /opt? [22:14] yes [22:14] but you can mount server:/opt/home /home ? [22:14] yup [22:14] interesting, I didn't know that [22:14] Is that not supposed to work? Not sure lol [22:14] I guess good to learn [22:15] how do you know the server is exporting just /opt, you checked its /etc/exports file? [22:15] or did you run showmount against it? showmount -e iirc [22:16] no, I just trusted the server admin about it. I will look up how to use showmount to satifsy curiousity... [22:16] can it work from the client? [22:17] it's supposed to [22:20] I see a result like "/opt *" So I guess that answers it === strive is now known as emerge === emerge is now known as strive