IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 24 March 2022 (all times are UTC)
| 01:14 | vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:20, Quit: leaving) | |
| 01:17 | Vercas has joined IRC (Vercas!~Vercas@gateway/tor-sasl/vercas) | |
| 02:04 | Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Ping timeout: 240 seconds) | |
| 02:14 | vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:20) | |
| 02:18 | Vercas has joined IRC (Vercas!~Vercas@gateway/tor-sasl/vercas) | |
| 02:47 | vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:20, Quit: leaving) | |
| 05:32 | lucascastro has left IRC (lucascastro!~lucascast@192-140-51-239.static.oncabo.net.br, Ping timeout: 260 seconds) | |
| 06:20 | lucascastro has joined IRC (lucascastro!~lucascast@192-140-51-239.static.oncabo.net.br) | |
| 07:17 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 07:53 | wyre has left IRC (wyre!~wyre@user/wyre, Quit: ZNC 1.8.2 - https://znc.in) | |
| 07:55 | wyre has joined IRC (wyre!~wyre@user/wyre) | |
| 08:15 | Hyperbyte has left IRC (Hyperbyte!~jan@middelkoop.cc, Ping timeout: 240 seconds) | |
| 09:18 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 09:19 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 10:24 | wyre has left IRC (wyre!~wyre@user/wyre, Quit: ZNC 1.8.2 - https://znc.in) | |
| 10:25 | wyre has joined IRC (wyre!~wyre@user/wyre) | |
| 11:51 | lucascastro has left IRC (lucascastro!~lucascast@192-140-51-239.static.oncabo.net.br, Remote host closed the connection) | |
| 11:53 | lucascastro has joined IRC (lucascastro!~lucascast@192-140-51-239.static.oncabo.net.br) | |
| 16:17 | vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:20) | |
| 16:47 | lucascastro has left IRC (lucascastro!~lucascast@192-140-51-239.static.oncabo.net.br, Ping timeout: 260 seconds) | |
| 20:00 | lucascastro has joined IRC (lucascastro!~lucascast@192-140-51-239.static.oncabo.net.br) | |
| 20:29 | <quinox> alkis: no hurry (I'm not at work so I can't do anything until tomorrow), but do you perhaps know what's wrong when my LTSP22-with-proxydhcp setup works great when I test it with a virtualbox-machine-with-network-in-bridgemode, both legacy BIOS boot and UEFI boot, but fails on real hardware: initial DHCP works, PXE message shows up, iPXE menu shows up (and works), loading of vmlinux works, ltsp.img
| |
| 20:29 | works, initrd.img works, I start to see kernel messages but then DHCP client fails with "No broadcast interfaces found" over and over again
| |
| 20:29 | I tried it on 2 different computers (I buy single computers whenever I need one, so they all differ a bit), and these machines currently happily boot LTSP5
| |
| 20:30 | I think it happens right before it tries to mount /
| |
| 20:30 | https://ghost.qtea.nl/tmp/ltsp22-boot-no-broadcast-interfaces.txt
| |
| 20:32 | I tried disabling IPv6 in my own DHCP server but that didn't seem to fix it
| |
| 20:33 | the network cards are standard on-board thingies
| |
| 20:34 | 10.50.0.12 is the LTSP22 server
| |
| 20:34 | IPv4 firewall on it is fully open
| |
| 20:39 | I fully accept it's a problem in my own setup somewhere, I just don't know where to look right now :)
| |
| 20:39 | and booting a VM using this LTSP setup works flawlessly without changing anything, so that's a bit odd
| |
| 20:42 | my LTSP5 setup uses Ubuntu18.04, for LTSP22 I used Ubuntu20.04 as client
| |
| 21:05 | <alkisg> quinox: I don't think I've seen "no broadcast interfaces" before, but it sounds like it's missing network drivers. E.g. maybe you somehow have kernel 5.13 in the image, but 5.4 in the tftp, so the modules aren't there?
| |
| 21:06 | You can set DEBUG_SHELL=1 in ltsp.conf and get a shell, and run `ip a` to see if it does see an ethernet card, `uname -r` to see the kernel version etc,
| |
| 21:06 | and in the off-case where the card is there and the problem in somewhere in DHCP, you could try KERNEL_PARAMETERS='ip=${ip}:${srv}:${gateway}:${netmask}:${hostname}:' in ltsp.conf
| |
| 21:14 | <quinox> thanks
| |
| 21:14 | does it still process ltsp.conf on the client if it can't mount / ?
| |
| 21:15 | it comes from ltsp.img, so I'm guessing yes
| |
| 21:17 | I found some post on the internet where this happened for people with dual-stack, but supposedly that was fixed in DHCP Client 4.4.0 and I see 4.4.1 being used
| |
| 21:17 | and I disabled RA in my own DHCP server which didn't fix it
| |
| 21:20 | <alkisg> Yes, it comes from ltsp.img
| |
| 21:21 | The second DHCP request (ipxe and then initramfs) in ltsp clients isn't very important, so you can solve it with the KERNEL_PARAMETERS that I mentioned above; it goes under [common] in ltsp.conf and you need to run `ltsp ipxe` afterwards
| |
| 21:21 | <quinox> awesome, thanks
| |
| 21:23 | the UEFI boot seems to do even yet another DHCP request, I see the PXE message twice
| |
| 21:23 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:32 | <alkisg> At most there are three requests: BIOS or UEFI, then iPXE, then initramfs
| |
| 21:33 | If one uses iPXE directly (e.g. some NICs have it; or VM client; or iPXE on disk/CD/win32-loader/grub-ipxe etc), and passes the KERNEL_PARAMETERS, then it's only a single DHCP request
| |
| 21:33 | I asked the iPXE developers if we could reuse the DHCP packet, and they've had good progress in implementing it; I need to see if it's ready for us to use it
| |
| 21:35 | Unfortunately pxelinux/syslinux doesn't support UEFI well so we couldn't keep using it, we did have to switch to iPXE. And grub didn't have broad netbooting support.
| |