LTSP 5 is in minimal maintenance mode
The new LTSP is hosted at https://ltsp.github.io

IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 19 March 2019   (all times are UTC)

00:27enaut[m] has left IRC (enaut[m]!enautmatri@gateway/shell/matrix.org/x-fzxqqskyorbhseco, Read error: Connection reset by peer)
00:36enaut[m] has joined IRC (enaut[m]!enautmatri@gateway/shell/matrix.org/x-sdbyyprcsdwiwdmr)
02:14vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 272 seconds)
02:33vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
03:39vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 246 seconds)
03:58vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
06:57kjackal has joined IRC (kjackal!~quassel@2a02:587:3119:ef00:39ef:42dd:f5e8:3018)
07:51ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
08:52
<vlt>
alkisg: Hi!
08:52
My strange TFTP problem returned.
08:53
I have more details, am quite certain that it's not LTSP's fault but have no idea idea what casues this.
08:54
*causes
08:55
The problem affects three clients now that are all in the same part of the building, the same ethernet "segment". And: They boot from three different LTSP servers :hm:
08:57
Our DHCP hands out their respective IP addresses just fine and tells them where to continue, they show "Trying to load pxelinux ..." or "Loding vmlinuz ...", then take up to 10 or 12 minutes and then continue just fine.
08:57
I measured the network speed (just with nc) and there are no problems at all.
08:58
Any idea what could happen there?
09:03
<alkisg>
!tftp
09:03
<ltsp>
tftp: Here's a page to help you troubleshoot TFTP problems in Ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/Troubleshooting/TFTP
09:03
<alkisg>
There's a command there to fetch things from tftp
09:04
Try to fetch the kernel again AFTER the client boots, to measure specifically tftp speeds
09:35
<vlt>
alkisg: Thank you!
09:59
On clients that finally managed to boot I used the following test command from that wiki page: `time tftp 192.168.1.9 -v -m binary -c get /ltsp/i386/pxelinux.0`
10:00
It's hard to recognize speed problems with that small file so I then requested initrd.img which is 16 MB.
10:01
On normal clients that file gets loaded in around 1 s, that matches the network bandwidth of 100 Mbit/s.
10:02
On one of the affected machines I got this: "Received 16283145 bytes in 605.1 seconds [215279 bit/s]"
10:02
Damn.
10:03
I watched the transfer using iftop and that speed was constantly around ~220 kBit/s.
10:04
But remember: sending other TCP/IP packets to and from that client now works just fine.
10:04
What could cause such a bandwidth limitation for TFTP transfers for that specific ethernet segment?
10:21
<alkisg>
vlt: firewall, blocking UDP traffic, bad switches that have issues with UDP etc
10:37
<vlt>
I can rule out a firewall. It's all local. And I think that would affect the other clients similarly.
10:37
Sounds more like a bad ethernet component, yes.
10:38
<alkisg>
Ah, I've also seen bad linux drivers causing issues. That could e.g. be worked around by changing the MTU to 1492.
10:38
Try exchanging two clients, a good and a bad one
10:38
If they continue the same way, you'll make sure that switches, cabling etc are not involved, just bad drivers
10:40
At another case, cabling issues appeared with a realtek card, while swapping it with intel didn't cause issues, as intel was smart enough to detect the cabling problems and switch to 100 mbps instead of gigabit
10:40
So do the exchange part to be 100% sure that it's not switches/cables, before you start playing with MTUs and other driver parameters.
10:46
<vlt>
Three different clients booting from three different TFTP servers (Ubuntu 12.04, 14.04 and 16.04/amd64) but all within the same part of the building more and more sounds like a bad ethernet switch to me.
10:47
But I'll take a working client there and see.
10:53
<alkisg>
vlt: I've also seen switches that misbehaved because they were not reset for months. Do try resetting them before throwing them away...
10:54
They do have software running, even if it's not a full OS, and it still can get crashes and erratic behavior at times
12:24spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Ping timeout: 246 seconds)
12:33Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:58spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
15:22Natureshadow has left IRC (Natureshadow!45d1515d22@commu.teckids.org, Remote host closed the connection)
16:58vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
20:12
<alkisg>
Hyperbyte: can we try to allow unregistered users again? I don't remember how to unset the flag...
20:22
<||cw>
mode -r I believe
20:22
+r sets is, -r removes it
20:28ChanServ sets mode: +o Hyperbyte
20:28Hyperbyte sets mode: -r
20:28Hyperbyte sets mode: -o Hyperbyte
20:42
<alkisg>
ty both
21:21Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
22:52ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)