[01:07] <ideopathic> i'm trying to get a PXEServer going on 16.04.  I've seen various instructions out there,
[01:08] <ideopathic> but i have not been able to get the machines to boot.  Getting the error "A bootable device has not been detected"
[01:27] <drab> ideopathic: what steps have you followed?
[01:27] <drab> a bootable device has not been detected just means that the network boot has failed
[01:27] <drab> do you see the client getting an ip and a config or something? what happens on the client?
[01:28] <drab> there's quite a few pieces to make this whole thing working: dhcp/tftp offer with the right file, config file for tftp, netbook on the client side
[01:29] <ideopathic> I see the client getting an ip from the server.  I I get the Checking Media Presence, Media Present message and then Start PXE over IPv4
[01:29] <ideopathic> it then switches to IPv6
[01:29] <drab> and then of course luck and magic with the optional sacrifice of a nice bear to Stallman
[01:30] <ideopathic> from another client I can access the pxelinux.0 via tftp without issue
[01:30] <drab> ideopathic: checking media presence? from the bios you mean?
[01:30] <drab> if it already has got an ipv4 I don't get why it'd be checking for media presence
[01:31] <ideopathic> That's the message I get on the screen of the client attempting to boot via PXE
[01:31] <drab> mmmh, that doesn't sound like it's booting yet, if it says checking media file and fails that's still with the pxe boot manager
[01:31] <drab> nothing to do with tftp or your server setup
[01:32] <drab> when you say "start PXE over ipv4" , do you mean start looking for a kerbnel to download?
[01:34] <ideopathic> When the client machine starts up.. it returns the 3 lines Checking Media Presence...\nMedia Present...\nStart PXE over IPv4
[01:34] <ideopathic> the Start PXE over IPv4 turns into Start PXE over IPv6.  After a period of time, the screen clears and returns the message "A bootable device has not been detected"
[01:38] <drab> ok, so the machine never receives a pxe offer
[01:38] <drab> it probably starts on ipv6 after having failed on v4
[01:39] <drab> so your probably is most likely dhcp config
[01:39] <drab> if you run tcpdump on the dhcp server or the dhcp server in debug mode, do you see the client requestin an ip and getting back all info including the tftp ones?
[01:40] <drab> "A bootable device has not been detected" is normal since the disk has no Os installed and the PXE failed to receive a network boot offer
[01:40] <drab> ideopathic: what's your dhcp server? what's your network layout? please paste your dhcp config
[01:40] <drab> dpaste.org
[01:40] <drab> or whatever youi prefer, just not in channel
[01:44] <ideopathic> drab: https://dpaste.de/MF5B
[01:44] <ideopathic> thank you
[01:44] <ideopathic> I am testing node1 at the moment
[01:46] <drab> ok, first obvious answer, does the mac address match?
[01:46] <drab> eer, question, not answer
[01:46] <drab> like are you 100% sure such as that you went into the bios, show system info and found the mac there and compared it?
[01:47] <drab> if not, where did you get the mac from?
[01:47] <ideopathic> i scanned the mac from the machine.. but you're right.. let me double check
[01:48] <drab> ideopathic: I mean, aside from pxe, you should still be seeing entries in syslog from dhcpd
[01:48] <drab> such as dhcpd: DHCPDISCOVER from ....
[01:48] <drab> if you don't see those your client isn't even trying to get an ip
[01:49] <drab> so your problem is far earlier than even pxe
[01:49] <ideopathic> yes: DHCPREQUEST for 10.10.10.101 (10.10.10.10) from f4:4d:30:6f:19:1a via eno1
[01:49] <ideopathic> DHCPACK on 10.10.10.101 to f4:4d:30:6f:19:1a via eno1
[01:50] <drab> ok good, so that part is working fine
[01:50] <drab> ideopathic: so then if you grep tftp /var/log/syslog, does it show anything?
[01:51] <drab> on 10.10.10.10
[01:52] <ideopathic> yes.. I'm seeing bind: Address already in use
[01:52] <drab> :)
[01:53] <drab> how have you set up your tftp server?
[01:53] <ideopathic> i've posted tcpdump: https://dpaste.de/XHAU
[01:54] <ideopathic> I pretty much followed this for the config: https://www.ostechnix.com/how-to-install-pxe-server-on-ubuntu-16-04/
[01:54] <ideopathic> tftpd-hpa using inetd
[01:56] <drab> so you get what it shows in the link if you run systemctl status tftpd-hpa ?
[01:56] <drab> meaning, it shows it as running?
[01:57] <ideopathic> shows running
[01:57] <drab> uhm, that links seems contradictory to me
[01:57] <drab> if you set the daemon to yes, then you don't want to run it through inetd
[01:57] <drab> which is probably where the "address already in use" error comes from
[01:58] <drab> it's one or the other
[01:58] <ideopathic> got it.... i thought it odd too.
[01:58] <drab> but then it shouldn't be your problem
[01:58] <drab> because tftp is already running and the tcpdump shows it's downloading a file
[01:59] <drab> so that also seems to be working
[01:59] <drab> what else do you get if you grep tftp /var/log/syslog ? can you dpaste that please?
[02:01] <ideopathic> https://dpaste.de/Wsu4
[02:03] <ideopathic> i stripped out the inet conf
[02:05] <drab> ok, can you try again without inet just in case for some reason that was causing trouble?
[02:06] <ideopathic> just did.. no love
[02:06] <drab> ok, that's fine, wasn't expecting it to, just worth checking
[02:06] <drab> so that looks odd to me because I see no request from the client
[02:07] <drab> your tcpdump shows pxelinux.0 being downloaded
[02:07] <ideopathic> I think I solved it... I had to enable legacy boot on the intel nuc for this to work
[02:07] <drab> oh, great
[02:08] <ideopathic> wow.. do you know any good links that might cover UEFI boot with Ubuntu?
[02:08] <ideopathic> drab: thank you for working through this with me.. I was kind of stuck on my own.
[02:13] <drab> ideopathic: I collected a couple when I was trying to do this myself, but never finished it because we didn't need it so badly to justify the investment
[02:13] <drab> let me look at my bookmarks
[02:15] <drab> ideopathic: http://dpaste.com/0XGRQN8
[02:15] <ideopathic> drab: thank you!
[02:16] <drab> also note that I do things over http, much faster for parallel installs than tftpd
[02:16] <drab> so the second links is about http
[02:16] <drab> which may not apply to you
[02:16] <drab> ideopathic: if you figure it out I'd love to hear about it :)
[02:17] <ideopathic> got.. will likely try a little later...
[02:17] <ideopathic> i have apache running but i think something is off in the config as it's pulling from the interwebs.
[02:20] <drab> bbl
[07:19] <lordievader> Good morning
[07:19] <cpaelzer> hi lordievader
[07:21] <lordievader> Hey cpaelzer, how are you doing?
[07:22] <cpaelzer> as good as it can be for a Monday I'd think :-)
[07:22] <cpaelzer> how are you today?
[07:25] <lordievader> Doing good here. Having a new keyboard at work :)
[07:25] <lordievader> (Played a little with it over the weekend though)
[07:30] <dnegreira> which keyboard ?
[07:30]  * dnegreira looking into keyboards
[07:39] <lordievader> A Ducky ONE TKL
[07:52] <dnegreira> lordievader: neat
[07:53] <lordievader> I wanted a smaller one I could carry around if need be.
[07:55] <dnegreira> numlock is mostly useless
[07:55] <hateball> it's impossible to find a proper TKL keyboard with swedish layout and no windows logo on it :<
[07:56] <hateball> (preferably backlit also)
[07:57] <dnegreira> s/numlock.
[07:57] <dnegreira> s/numlock/numpad
[08:06] <lordievader> hateball: On these type of keyboards all keys are replacable. If you find a nice key for the win key, simply replace it.
[08:28] <TJ-> I've hit a problem with 16.04 server, network-manager and policykit, when remoted in over SSH. On the local console nmtui (the ncurses-based configuration tool) can edit system connections. On the remote session nmtui reports "Insufficient Privileges...". As far as I understand this is due to policykit actions but despite trying several alternate actions, and trying some rules, I've not been able to
[08:28] <TJ-> solve it. Any advice or hints on this?
[08:32] <lordievader> Same user I presume? Does 'loginctl' show the same output?
[08:40] <TJ-> Yeah, same user. Obviously there's no PK agent as there's no GUI. I tried several variations of custom actions and rules but not found a solution so far when on SSH
[08:41] <TJ-> "same output" ? you mean "insufficient privileges"? plain "loginctl" just shows the current sessions (1 local, 1 remote)
[08:46] <TJ-> as well as some custom action attempts I've tried this rule:
[08:46] <TJ->   if (action.id == "org.freedesktop.NetworkManager.settings.modify.system" &&
[08:46] <TJ->         (subject.isInGroup ("sudo") || subject.isInGroup ("netdev"))) {
[08:46] <TJ->     return polkit.Result.YES;
[09:00] <TJ-> I've got it to work setting ResultAny=yes" Action=org.freedesktop.NetworkManager.settings.modify.system Identity=unix-group:sudo  in /etc/policykit/localauthority/50-local.d/60-network-manager.pkla, but my initial reading of the docs suggested that ResultAny=yes wasn't very secure. I'd best reread that
[09:16] <lordievader> I always got the idea that polkit was very related to logind.
[09:16] <lordievader> Didn't the auth log point to why access was denied?
[09:26] <TJ-> There was nothing at all in auth
[09:29] <lordievader> Ah, you might need to add log statements in order to have polkit actually log things: https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
[09:31] <TJ-> Yes, I tried that too, but couldn't find them anywhere in the recorded log files
[09:36] <lordievader> Not in the systemd journal either?
[09:39] <TJ-> Nowhere
[13:03] <gunix> how often should i update ubuntu serve?
[13:07] <ogra_> every time it tells you to at the login scrreen
[13:11] <gunix> ogra_: not possible in production situations where downtime has to be agreed with by customers.
[13:11] <ogra_> well, then whenever your schedule allows ... what i meant to point out is that the machine tells you if there are updates available
[13:13] <gunix> ogra_: normally distros have specifications regarding how long you can go without upgrades, without living in the fear that a big upgrade will break the system. for example, archlinux should be upgraded once per day, but debian can go for months without upgrades. debian testing should be upgrade once per week. debian sid should get upgraded daily.
[13:13] <lordievader> gunix: Updates do not necesarily mean downtime.
[13:14] <gunix> lordievader: ubuntu has weekly kernel upgrades
[13:14] <lordievader> So? Since when are you forced to reboot when there is a kernel update?
[13:14] <lordievader> If you have good reason to reboot to a new kernel once  month, you reboot  once a month.
[13:15] <lordievader> And the above seems like a good reason to me.
[13:15] <gunix> sound like "do w/e you want and reboot when you can" :))
[13:16] <lordievader> Pretty much. Linux/Ubuntu won't force you to do anything. If a certain practice is wise is something different ;)
[13:16]  * ogra_ highly doubts debian can go for months without upgrades 
[13:16] <ogra_> (unless you dont care about security at alll)
[13:17] <lordievader> I'd do updates as often as possible. And reboot when necesary and possible.
[13:17] <gunix> ogra_: it has kernel upgrades once every 2-3 months, and upgrades usually come as a huge pack, except security upgrades
[13:17] <ogra_> ubuntu LTS is in the same boat as debian stable though
[13:17] <gunix> ogra_: isn't ubuntu LTS based on debian testing?
[13:17] <ogra_> no on unstable ... with 6months of stabilization
[13:17] <gunix> lordievader: i am not asking about what ubuntu forces me. i am asking how it is wise to do.
[13:18] <ogra_> wise is to do it every time there is a security update :)
[13:18] <gunix> ogra_: do you have a link with that information?
[13:18] <ogra_> not really
[13:18] <gunix> ogra_: wait a sec
[13:18] <ogra_> there are mailing lists where that was discussed ... i guess the ubuntu-devel ML
[13:19] <ogra_> there were a few LTSes in the beginjning where using testing was tried ...
[13:19] <ogra_> typically only if the release schedules have some bad overlap or so, so that unstable would be to risky
[13:20] <gunix> ogra_: lts is based on debian testing and other versions are based on debian unstable
[13:22] <ogra_> gunix, https://wiki.ubuntu.com/LTS
[13:22] <gunix> well, anyway, i am going to ask again, but rephrase: does ubuntu provide any official advice on how often the ubuntu server should be upgraded?
[13:22] <ogra_> "Starting with the 14.04 LTS development cycle, automatic full package import is performed from Debian unstable"
[13:22] <ogra_> every time you have a security upgrade :)
[13:22] <gunix> ogra_: thank you, i didn't know that.
[13:22] <gunix> ogra_: do you have a link?
[13:23] <ogra_> for what ?
[13:23] <gunix>  ogra_ | every time you have a security upgrade :)
[13:23] <maswan> Yeah, I'd recommend automatic updates
[13:23] <ogra_> well, thats common sense ...
[13:23] <gunix> i want to see the official page from ubuntu on this
[13:23] <maswan> Possibly with blacklisting of things that won't handle a restart well, like postrges for some applications using it, etc
[13:23] <ogra_> you dont want your production systems to run with open security holes
[13:23] <gunix> well, equally if it makes sense or not, i need the recommandation from the website. that's what i am searching for :)
[13:23] <ogra_> i doubt thats anywhere written as recommendation simply because its a logical conclusion
[13:24] <ogra_> if theer is a known security hole you want it closed ASAP
[13:25] <ogra_> https://help.ubuntu.com/community/AutomaticSecurityUpdates btw
[13:25] <gunix> ogra_: yes, that is clear.
[13:25] <ogra_> https://help.ubuntu.com/community/AutomaticSecurityUpdates#Using_the_.22unattended-upgrades.22_package
[13:26] <ogra_> that bit specifically
[13:27] <gunix> hmm. this should do. looks official enough. i will suggest automatic upgrades, with these articles as backup, and monthly reboots during security windows. thank you!
[15:19] <tomreyn> gunix: it would be better to have two business processes - one which ensures monthly reboots, another which ensures reboots upon critical kernel vulnerabilities.
[15:21] <tomreyn> you dot want to sit around 30 days with a vulnerable kernel in case of critical security issues.
[15:25] <gunix> tomreyn: that sounds like a good plan
[15:28] <tomreyn> you could also just do the critical ones but this would only work if you can ensure it happening reliably and fast. or look into live kernel patching.
[15:52] <gunix> tomreyn: live kernel patching is not really that safe yet.
[15:53] <tomreyn> HA is and always will be the bette roption
[15:55]  * drab wishes ldirectord was simpler to manage
[16:19] <madLyfe> lordievader: you around? i need your master on the server installer
[16:20] <madLyfe> mastery*
[16:21] <Ussat> TBH I will never trust live patching....on any of my systems....AIX/RHEL or Ubuntu
[16:33] <jbicha> Any suggested things people would like to see in 18.04 on the server side: LP: #1618188
[16:34] <jbicha> probably more of a Foundations thing, right? but it's nice when everybody agrees on taking the step
[16:52] <madLyfe> maybe you guys can help. i need to get the server installer to recognize my usb ethernet adapter. it has the module because if i complete the install w/o setting up the adapter i am able to manually set it up after boot by going into the network interfaces file.
[16:53] <madLyfe> the desktop live usb doesnt have a problem recognizing the adapter either.
[16:54] <madLyfe> so i just want to get it to recognize during install on server.