|02:34||yanu has left IRC (email@example.com, Ping timeout: 245 seconds)|
|04:36||Ark74 has left IRC (Ark74!~Luis@22.214.171.124, Quit: Leaving)|
|06:25||yanu has joined IRC (firstname.lastname@example.org)|
|06:53||gdi2k has joined IRC (email@example.com)|
|07:13||vsuojanen has left IRC (firstname.lastname@example.org, Ping timeout: 246 seconds)|
|07:23||gdi2k has left IRC (email@example.com, Ping timeout: 250 seconds)|
|07:28||gdi2k has joined IRC (gdi2k!~Android@126.96.36.199)|
|07:36||gdi2k has left IRC (gdi2k!~Android@188.8.131.52, Quit: -a- IRC for Android 2.1.55)|
|07:39||gdi2k has joined IRC (gdi2k!~Android@184.108.40.206)|
|07:49||kjackal has joined IRC (kjackal!~quassel@2a02:587:3109:4a00:8951:4cce:8d0:539a)|
|08:04||gdi2k has left IRC (gdi2k!~Android@220.127.116.11, Read error: Connection reset by peer)|
|08:07||gdi2k has joined IRC (gdi2k!~Android@18.104.22.168)|
|08:17||gdi2k_ has joined IRC (gdi2k_!~Android@22.214.171.124)|
|08:21||gdi2k has left IRC (gdi2k!~Android@126.96.36.199, Ping timeout: 265 seconds)|
|08:29||kjackal has left IRC (kjackal!~quassel@2a02:587:3109:4a00:8951:4cce:8d0:539a, Ping timeout: 276 seconds)|
|09:19||kjackal has joined IRC (kjackal!~quassel@2a02:587:3109:4a00:8951:4cce:8d0:539a)|
|09:59||eu^195128893revs has joined IRC (firstname.lastname@example.org)|
|10:10||eu^195128893revs has left IRC (email@example.com, Remote host closed the connection)|
|10:51||adrianor1 has joined IRC (firstname.lastname@example.org)|
|10:54||adrianorg has left IRC (email@example.com, Ping timeout: 245 seconds)|
|11:39||Nikoh77 has left IRC (Nikoh77!~Nikoh77@host148-135-static.9-79-b.business.telecomitalia.it, Remote host closed the connection)|
|13:58||vsuojanen has joined IRC (firstname.lastname@example.org)|
|14:29||gdi2k_ has left IRC (gdi2k_!~Android@188.8.131.52, Read error: Connection reset by peer)|
|14:30||gdi2k has joined IRC (gdi2k!~Android@184.108.40.206)|
|14:37||kjackal has left IRC (kjackal!~quassel@2a02:587:3109:4a00:8951:4cce:8d0:539a, Ping timeout: 276 seconds)|
|15:11||gdi2k_ has joined IRC (email@example.com)|
|15:12||gdi2k has left IRC (gdi2k!~Android@220.127.116.11, Ping timeout: 268 seconds)|
!learn ltsp5-uefi as Unofficial UEFI netbooting support for LTSP5: https://github.com/alkisg/ltsp5-uefi
The operation succeeded.
|17:36||kjackal has joined IRC (kjackal!~quassel@2a02:587:3109:4a00:8951:4cce:8d0:539a)|
|18:04||Tottle has joined IRC (Tottle!5496eb1d@p5496EB1D.dip0.t-ipconnect.de)|
Hello, i have Ubuntu 18.04 and i installed ltsp using https://ltsp.org/docs/installation/. I want to maintain my client image chrootless and network-boot it via my ThinkCenter M93P. Both, my host and client computer are connected to my OpenWrt/LEDE power Linksys Rounter. The client computer gets the host systems ip, but than fails with:
"Auto-select: undionly.kpxe. BOOT SERVER IP: 192.168.XXX.YYY. TFTP.... TFTP open timeout. Exiting Intel Boot Agent". Can you help me fixing that? Is there some other good explaining LTSP 2019 Resource?
Tottle: try this:
tftp: Here's a page to help you troubleshoot TFTP problems in Ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/Troubleshooting/TFTP
From the server: busybox tftp -g -r /ltsp/undionly.kpxe -l /tmp/undionly.kpxe
Does this work?
busybox tftp -g -r /ltsp/undionly.kpxe -l /tmp/undionly.kpxe localhost
I try this out
I ran " busybox tftp -g -r /ltsp/undionly.kpxe -l /tmp/undionly.kpxe localhost" from my host system. That doen't helped
What was the output of the command?
https://help.ubuntu.com/community/UbuntuLTSP/Troubleshooting/TFTP Doesn't help me, because this is not for the new LTSP 2019 and not for Ubuntu 18.04
Yes that's why I said "hmm no"
Tottle: do you have firewall running, e.g. ufw?
The operation succeeded.
!learn tftp as To test if your TFTP server is working, try this on the server (or from another PC): busybox tftp -g -r /ltsp/ltsp.ipxe -l /tmp/ltsp.ipxe localhost
The operation succeeded.
Tottle: also, is your tftp server IP there correct, or does it point to e.g. the router?
Ah see. ufw seems to be installed, but i never used that. Iptables says that INPUT, FORWARD and OUTPUT has ACCEPT Policy without any rules.
Do you reference "BOOT SERVER IP: 192.168.XXX.YYY"? Than: Yeah the 192.168.XXX.YYY-part is my enp4s0-interface address
(Of my host system)
192.168 are internal addresses, no need to hide them, they're not secret
Can I see with VNC?
vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
I know, but it seems to be irrelevant. If it would be better, i can post them
No, it sometimes makes chatting easier
No big deal
Ok, no problem, i will post them
So if I understood this correctly, your client cannot even get undionly.kpxe, it times out before it gets it
This can only be due to server tftp issues (you said no issues there), firewall, or wrong client ip
I would test with a VM client next, to see if it works with that. E.g. virtualbox client.
Hmm probably i have to configure something in my OpenWRT/LEDE router?
Normally, you should leave the router completely unconfigured, so send IPs but not boot filename or root-path etc
And you should use the proxydhcp mode of the ltsp server, which would take care of everything automatically
What's the output of this, on the server? sudo /usr/lib/klibc/bin/ipconfig -n enp4s0 | nc termbin.com 9999
This does a fake dhcp request
So that we see if your router does send a boot filename etc
I would suggest either VNC'ing to me (I'm an ltsp developer btw), or using a VirtualBox client
as the next step
I can try to connect with VirtualBox
Put the vbox client lan to bridged mode, and use boot.ipxe.org/ipxe.iso as the boot source
I have VirtualBox 5.2.34. I tried to connect via network-brigde to enp4s0 and deny promiscuous-mode. Than i booted via lan. There it also times out. I will try with boot.ipxe.org/ipxe.iso as boot source
Where can i specify boot.ipxe.org/ipxe.iso as network boot source?
download it, it's an iso
Ah ok, will do it
The output looks quite, but not completly, similar to the regular lan boot option from VirtualBox. The output is: ... Booting from PXE menu\n PXE\n PXEBS ... ok\n Next server: 192.168.1.121\n Filename: ltsp/ltsp.ipxe.0\n tftp://192.168.1.121/lsp/ltsp.ipxe.0.... Connection timed out
And is .121 your ltsp server?
Yeah thats my Ubuntu host system, on which I installed ltsp etc.
OK something is indeed very wrong there, if your client from localhost can't use tftp
Is dnsmasq running?
Ah you said that "busybox tftp" worked
Yeah at that point I'd want to see all these with my own eyes, over vnc
I will configure a tunnel, that you can see it
Or bother you if we could use TeamViewer, because I have chrooted my ssh, and i would have to modify it back to normal?
If the ltsp server has internet access, it can reach me
No need for tunnels etc
Teamviewer has blacklisted me because of "commercial use" somehow, so I stopped using it
I applied once to revoke that status, they did, then it was back the next time I used teamviewer again, so I stopped bothering with it
|19:30||kjackal has left IRC (kjackal!~quassel@2a02:587:3109:4a00:8951:4cce:8d0:539a, Ping timeout: 252 seconds)|
Ok, i understand. So i would have setup x11vnc with ssh tunnel, but you said, ltsp server with internet access. So what should i do? Somehow forward ltsp?
Did you install epoptes when you installed ltsp?
Yeah, but i never used it
OK, then just do this: x11vnc -connect srv1-dide.ioa.sch.gr
This should connect to me, if your ltsp server has xorg and internet access
(08:21:29 PM) Tottle: Hello, i have Ubuntu 18.04 ==> it's 16.04
Tottle: ok, the problem was network-manager in 16.04
It has a lot of bugs that prevent dnsmasq from working properly
You'd better use 18.04 instead of 16.04...
(or even 20.04 should be better than 16.04 :D)
(I closed VNC)
Oh i use different versions at different computers, I really thought that was 18.04. I will upgrade soon, but this is so errorprone and its an production system. Someone in the internet suggested that one can disable dnsmasq with #port=0. I thought that this would only be to be able to manipulate dns requests but have nothing to do with the
routing, because with it, i haven't internet anymore. Probably because of NetworkManger-Bug. So how can I avoid the NetworkManager bug?
Just reboot your pc now, it should be ok
port=0 disables dns, which is the default
By uncommenting it, you made it worse
The "bind-interfaces" that /etc/dnsamsq.d/network-manager had, was the main problem
It makes dnsmasq unstable; fortunately, systemd-networkd came along and ubuntu dropped their stupid hacks
So 18.04 doesn't have these problems at all
Ok. Than I will upgrade as soon as possible. Thank you for your great help!
|19:51||Tottle has left IRC (Tottle!5496eb1d@p5496EB1D.dip0.t-ipconnect.de, Remote host closed the connection)|
|21:02||pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 240 seconds)|
|21:13||pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)|
|21:25||pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 240 seconds)|
|23:29||pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)|