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


Channel log from 10 November 2019   (all times are UTC)

00:02eddytv has joined IRC (eddytv!~eddy@2601:402:4500:4670:359e:f3f:9ea7:9540)
00:09
<eddytv>
Q: is it possible to build a minimal LTSP initrd and install it on "real" storage (like a small SSD) so clients boot faster? Right now, they boot, wait for DHCP, start PXE, chain-load iPXE, which waits for the "Press Ctrl-B for iPXE command line..." and then finally starts booting (with the iPXE menu timeout set to 0). This makes for a pretty slow startup. Having some kind of local initrd would also allow enabling "Fast Boot" in the
00:09
BIOS (which disables net booting, booting from USB, etc.) which should make things even faster...
00:17
<vagrantc>
it's certainly possible, but would add a lot of local maintenance overhead
00:18
there may have been some code (or maybe just ideas) floating around to automate the process ... some versions of raspberry pi boards need that, for example
00:19
eddytv: how long of a wait are you seeing?
00:20
eddytv: it might be simpler to troubleshoot the network booting speed than rewrite a bunch of code and locally save data on each and every client
00:20
<eddytv>
Let me time it...
00:23
<vagrantc>
alkisg: i think i figured out why my virtual machine doesn't load snponly.efi ... it's because dnsmasq behaves differently if your PXE client is iPXE: dhcp-match=set:iPXE,175,39
00:24
alkisg: e.g. qemu's PXE implementation is iPXE ... so it just skips that step
00:25
actually... the line is probably pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe rather than pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi
00:30
<eddytv>
OK, here's the timings: after I see a "black screen" after hitting the power button, it takes ~10s for the BIOS POST stuff. Then I see the Intel UNDI PXE-2.1 boot. 4s later it starts DHCP. 4s after that I see the "PXE -> EB: !PXE at 9904:0070" and "iPXE initializing devices..." 5s after that, I see "iPXE 1.0.0+ / Press Ctrl-B for the iPXE command line..." about 2s after that I see "Configuring (net0...)" and then 4s after that the iPXE
00:30
boot menu (if enabled). So about 32s total after power-on.
00:34
<vagrantc>
that does seem a bit slow, indeed
00:59
<eddytv>
and this is on an Intel NUC5PPYH (built Aug. 2016) :-/
01:19
<vagrantc>
why it takes so long to start the various DHCP calls is surprising
03:23vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
04:42||cw has left IRC (||cw!~chrisw@97-87-137-194.dhcp.stls.mo.charter.com, Ping timeout: 245 seconds)
04:43||cw has joined IRC (||cw!~chrisw@97-87-137-194.dhcp.stls.mo.charter.com)
06:26gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.28, Read error: Connection reset by peer)
06:41gdi2k has joined IRC (gdi2k!~gdi2k@103.47.144.32)
06:46
<alkisg>
eddytv: yeah it's possible to put the LTSP kernel and initrds locally and boot them e.g. with grub
06:46
If you want, start a community issue and a wiki page, and I'll help you write/maintain it
06:47
But note that you'll need to write the new ltsp.img initrd locally for any changes that you do in ltsp.conf; I haven't programmed any other method to get it remotely yet
06:48
It should be very easy to get it via nfs; but it will need a couple of lines e.g. in ltsp.conf to do that
07:00gdi2k has left IRC (gdi2k!~gdi2k@103.47.144.32, Ping timeout: 240 seconds)
07:17gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.28)
11:37eu^ip9472d4a5spe has joined IRC (eu^ip9472d4a5spe!5456d4a5@84.86.212.165)
11:38eu^ip9472d4a5spe is now known as elec332\
11:38elec332\ is now known as elec332
13:52woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de)
13:55
<elec332>
Hello, I have a question about LDAP authentication for LTSP19
13:55
I installed LTSP, installed LDAP, added the empty 54.sh and NFS exported the home dir
13:56
However, when I log in, the screen goes black for a second and returns to the login screen
13:56
<uumas>
Does login work for local users?
13:59
<elec332>
Nope, then I get: "Logging on using cached credentials", and the it goed to the standars text when the pow is incorrect (sorry, that didnt work, try again)
13:59
*when the pw is incorrect
14:01
LDAP dies work in some way, because it does detect when the pw is incorrect, but when it is correct the screen goes black for a second. But normally after that you go to the desktop, but it goed back to the login screen instead
14:04
<uumas>
What happens if you try to login in a tty?
14:04
Press Ctrl+Alt+F3
14:08
<elec332>
That works, looks like home isnt being exported properly
14:10
<uumas>
You need to configure nfs home for ldap auth to work for now: https://github.com/ltsp/ltsp/issues/16
14:42
<elec332>
I did that, but it was for testing anyways. I'v e got it set up to mount /home from my NAS now
14:44
I als read om the manpage about PWMERGE_SUR=, PWMERGE_SGR=, PWMERGE_DGR=, PWMERGE_DUR=
14:45
Say the only local user on the ltsp server is the user "ltsp", how whould I block the PXE clients from logging in with that account?
14:54
<alkisg>
elec332: PWMERGE_SUR="^(?!administrator)"
14:54
It's "negative regular expression"
14:54
*ltsp in your case, not administrator as the help mentions
14:55peter16 has joined IRC (peter16!5cdb64d3@ipservice-092-219-100-211.092.219.pools.vodafone-ip.de)
14:56
<peter16>
I have a problem with my LTSP installation on Debian 10.
14:57
<alkisg>
What problem?
14:57
<peter16>
The Client starts as expected but when I login the screen stays black forever
14:58
<alkisg>
Which distribution and version?
14:58
<peter16>
Debian 10
14:58
<alkisg>
ltsp5 or ltsp19?
14:58
<peter16>
ltsp 5.18
14:58
<alkisg>
Are you using gnome and possibly wayland?
14:59
<peter16>
gnome ... as far as I know
14:59
<alkisg>
elec332: to test a regex, use something like this: printf "ltsp\nltsp123\nabcd\n" | grep -P '^(?!ltsp$)'
14:59
elec332: this shows that this regex would allow the ltsp123 and abcd users, but not the ltsp user, so it's the regex you're looking for
15:00
peter16: what's the output of this? ls -l /opt/ltsp/images /opt/ltsp/*/usr/share/xsessions
15:01
<peter16>
ls: Zugriff auf '/opt/ltsp/*/usr/share/xsessions' nicht möglich: Datei oder Verzeichnis nicht gefunden/opt/ltsp/images:insgesamt 3665492-rw-r--r-- 1 root root 1907294208 Nov 10 15:17 amd64.img-rw-r--r-- 1 root root 1846161408 Okt 20 16:13 amd64.img.old
15:01
<alkisg>
peter16: ok so afaik you're using thin clients and the old ltsp. It's recommended to use fat clients and the new ltsp.
15:02
To give you better advice, can you see this? https://ltsp.github.io/advanced/specs/
15:02
<peter16>
yes
15:02
<alkisg>
I.e. how many clients, which cpu exactly, and how much ram?
15:03
<peter16>
Only one client (right now its only me for testing) -CPU: Intel(R) Xeon(R) CPU E3-1240L v5 @ 2.10GHz
15:04
<alkisg>
OK then forget everything you tried so far
15:04
This was the old ltsp
15:04
You want to try with the new one:
15:04
!install
15:04
<ltsp>
install: To install LTSP19+: https://ltsp.github.io/docs/installation. To install LTSP5: http://wiki.ltsp.org/wiki/Installation/Ubuntu for Ubuntu, or http://wiki.ltsp.org/wiki/Installation for other distributions
15:04
<alkisg>
The first link there
15:05
(or you can also start with ltsp.github.io)
15:05
<peter16>
Ok, I can try this ... however on the previous install Debian 8 LTSP was running fine.
15:05
<alkisg>
Yes. LDM needed to be updated for newer distributions and environment, wayland etc
15:06
We didn't want to do that, so we implemented ltsp19 instead
15:06
So the old ltsp may still run in some cases and fail in others
15:06
<peter16>
ok, I will try the new version. thanks a lot.
15:06
<alkisg>
But it receives no maintenance
15:07
Also, you used a wrong method, which ended in thin chroot instead of fat chroot
15:07
When reading the new web page, start testing with the chrootless method
15:07
Thin chroots have a hard time to work with desktop environments that require opengl, like gnome
15:07
Fat chroots or chroots work fine
15:07
*or chrootless
15:09
<peter16>
The interesting thing is that even so x11 stays black I can still switch to another text console and login as root ... but not as a user
15:13
<alkisg>
peter16: are you sure you want to troubleshoot a thin client setup, even though it's 10 times worse than a fat one?
15:14
At least you could install gnome in the chroot and make it a fat one
15:14
!fatclients
15:14
<ltsp>
fatclients: Nowadays LTSP supports thin and fat clients. They are both diskless and netbooted from the same LTSP chroot, but while thin clients run the session on the server and transfer the screen, fat clients run the session locally with their own CPU/RAM, thus performing amazingly better. See also !ltsp-pnp and https://help.ubuntu.com/community/UbuntuLTSP/FatClients
15:14
<peter16>
No, I used a fat client also before Debian 10
15:14
<alkisg>
And you want a thin client now?
15:14
<peter16>
No
15:14
<alkisg>
You have a thin chroot now
15:14
No xsessions
15:15
I don't think there's any point in trying to make a thin chroot show an opengl-based remote environment
15:15
<peter16>
It looks like I have no xsession
15:15
<alkisg>
Even if you make it work with software emulation, it'll be extremely slow
15:15
<peter16>
but I can login via console as root
15:15
<alkisg>
But even if you now install gnome in the chroot, it'll still be the old ltsp, which is unmaintained
15:15
So I don't think there's any reason at all to continue troubleshooting this...
15:16
If a setup is already using ltsp5, ok, they could continue until they reinstall...
15:16
But I see no reason to use it in new installations
15:16
<peter16>
No problem ... I will try the new LTSP19
15:17
<alkisg>
The mailing lists have also moved, to https://github.com/ltsp/community/issues
15:17
<peter16>
Thanks, will LTSP19 be available within the Debian Packages soon?
15:17
<alkisg>
It's available in debian experimental
15:17
It will be the only ltsp in bullseye
15:18
Not sure if vagrantc will put it in buster-backports
15:18
<peter16>
Ah, good to now ...
15:18
<alkisg>
https://packages.debian.org/ltsp
15:19
<peter16>
That is the version which I have installed right now ....
15:19
<alkisg>
No, this is ltsp19 in experimental
15:19
What you have is ltsp5 in buster
15:20
<peter16>
Sorry, my mistake ... I was looking into the wrong tab.
15:21
So, many thanks for all your help - I will try again with LTSP19 ...
15:22
<alkisg>
You're welcome; in case you still have doubts, I'm a developer of both ltsp5 and ltsp19
15:22
ltsp19 is the way to go.
15:22
<peter16>
Thanks for your kind support.
15:22
<alkisg>
np
15:23peter16 has left IRC (peter16!5cdb64d3@ipservice-092-219-100-211.092.219.pools.vodafone-ip.de)
16:13statler has joined IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de)
16:17woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection)
16:18woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de)
16:48meo has left IRC (meo!~systemdju@unaffiliated/mikeseth, Quit: leaving)
16:56peter53 has joined IRC (peter53!5cdb64d3@ipservice-092-219-100-211.092.219.pools.vodafone-ip.de)
17:00vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
17:05
<peter53>
Hi, I just downloaded LTSP (v19.10) from Github ... create and installed the deb-file "ltsp_19.10-1_all.deb" followed by the commands which are mentioned in the Manual: ltsp dnsmasq --proxy-dhcp=0, ltsp image /, ltsp ipxe, ltsp nfs, ltsp initrd. Since I'm using dual NIC I uncoment the line NAT=1 in ltsp.conf. However, when starting the client I get
17:05
the following message: "No DHCP or proxyDHCP offers were receifed."
17:06
<alkisg>
peter53: did you set your internal ip to 192.168.67.1 ?
17:07
<peter53>
I've just check ... yes
17:08
<alkisg>
Run: tail -f /var/log/syslog
17:08
Reboot a client
17:08
See if you get a line by dnsmasq that sees the client request
17:09
<peter53>
no new lines ...
17:09
<alkisg>
Try sudo systemctl restart dnsmasq, then again boot client
17:09
If dnsmasq doesn't see the client request, something is wrong
17:10
<peter53>
no new lines ...
17:10
<alkisg>
Do you mind if you share your screen with me? It'll be a lot faster...
17:10
!vnc-edide
17:10
<ltsp>
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
17:11
<vagrantc>
managed switch? broken switch? broken cables? wrong port?
17:13
<peter53>
epoptes ist not installed - maybe you can give me some hints were to check ...
17:13
<alkisg>
What vagrant said is more likely
17:14
I was going to do a review of all the things you already said, in case you misreport something, then tell you it's likely not related to server software
17:15
<vagrantc>
does the switch blink when the client is attempting dhcp?
17:16
<peter53>
Half an hour ago we discussed about the old LTSP which is not running xsession - however, since I was able to connect via console to the server (e.g. via ssh) I think there is no connection problem.
17:18
<alkisg>
What's the output of this? netstat -nap | grep dnsmasq
17:19
dnsmasq is the very first stage; if it's on the same subnet as the client, it should log in syslog at least the client request
17:19
<peter53>
no output
17:20
<alkisg>
Did you install ltsp19 over your older ltsp5 installation?
17:20
Was it using isc-dhcp?
17:20
When you restarted dnsmasq, did it report failure?
17:20
That's why I like checking over vnc, it answers all those questions in a minute or so...
17:21
<peter53>
I removed the old ltsp but maybe I have overseen something ...
17:21
<alkisg>
Btw, I mean sudo netstat ..., if you run it as the user it might not have enough access
17:21
<peter53>
no error when restarting dnsmasq
17:21
<alkisg>
Is dnsmasq running? Check with ps aux | grep dnsmasq, or systemctl status dnsmasq, etc
17:22
su -; netstat -nap | grep dnsmasq
17:22
<peter53>
dnsmasq is running: Started LSB: DHCP and DNS server.
17:22
<alkisg>
You should at least have this: udp 0 0 0.0.0.0:67 0.0.0.0:* 1188/dnsmasq
17:23
<peter53>
nothing ... so maybe, I have to check the dnsmasq.conf
17:24
<alkisg>
What's the output of ls /etc/dnsmasq.d ?
17:24
Just one file there, or more?
17:24
<peter53>
Two files: ltsp-dnsmasq.conf ltsp-dnsmasq.conf_orig
17:24
<alkisg>
Did you create that second one?
17:25
<peter53>
yes
17:25
<alkisg>
It probably interferes, move it in another directory
17:25
Also, paste your modified one, to paste.debian.net etc
17:25
*restart dnsmasq after moving the file
17:28
<peter53>
Actually, I didn't modify the file - I just made I copy in case I would like to
17:28
<alkisg>
It makes dnsmasq execute the directives twice
17:28
So it's probably invalid
17:28
dnsmasq isn't limited to .conf files, it reads almost any extension
17:29
<peter53>
I removed the copy but still the same behavior
17:29
<alkisg>
Did you run systemctl restart dnsmasq?
17:29
<peter53>
yes
17:29
<alkisg>
What's the output of this? ps aux | grep dnsmasq
17:29
<peter53>
root 18193 0.0 0.0 6088 892 pts/1 S+ 18:29 0:00 grep dnsmasq
17:29
<alkisg>
Then it's not running
17:29
And of this? ps aux | grep dhcp
17:30
<peter53>
root 849 0.0 0.0 9488 6052 ? S 15:31 0:00 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /run/dhclient-enp2s0.pid -lf /var/lib/NetworkManager/dhclient-5fa3373e-1b44-42fe-8cbe-1ac67cc1acf9-enp2s0.lease -cf /var/lib/NetworkManager/dhclient-enp2s0.conf enp2s0
17:30
<alkisg>
OK then you're not using isc-dhcp
17:30
<peter53>
no
17:31
<alkisg>
What's the output of this? systemctl status dnsmasq | nc termbin.com 9999
17:31
<peter53>
https://termbin.com/dysv
17:32
<alkisg>
Is your system updated from older debian versions/
17:32
?
17:32
vagrantc: dnsmasq has a .service unit in buster, right?
17:33
<peter53>
I've setup a new Debian 10 on a new partition which seems to run fine ... I just migrate the /home partition which might still contain some old ltsp files
17:34
dnsmasq.service loaded active exited LSB: DHCP and DNS server
17:35
<alkisg>
peter53: do you have this file? /lib/systemd/system/dnsmasq.service
17:38peter43 has joined IRC (peter43!5cdb64d3@ipservice-092-219-100-211.092.219.pools.vodafone-ip.de)
17:38
<alkisg>
(07:35:42 PM) alkisg: peter53: do you have this file? /lib/systemd/system/dnsmasq.service
17:38
<vagrantc>
alkisg: never had a reason to look :)
17:38
<alkisg>
vagrantc: I checked https://packages.debian.org/buster/all/dnsmasq/filelist, it's there
17:39
<peter43>
Sorry, my system hang up ... so I had to restart and didn't get your last messages ...
17:39
<alkisg>
For some reason peter43's dnsmasq ...starts as a broken sysvinit unit instead of systemd service
17:39peter53 has left IRC (peter53!5cdb64d3@ipservice-092-219-100-211.092.219.pools.vodafone-ip.de, Ping timeout: 260 seconds)
17:43
<peter43>
It looks like there is no /lib/systemd/system/dnsmasq.service
17:44
<alkisg>
peter43: dpkg -l dnsmasq | grep ^ii
17:44
Output of that?
17:45elec332 has left IRC (elec332!5456d4a5@84.86.212.165, Ping timeout: 260 seconds)
17:46
<peter43>
dnsmasq is rc which means that I have removed it via apt-get autoremove after uninstall of old ltsp
17:47
<alkisg>
Didn't you follow the new ltsp installation instructions?
17:47
It mentions the installation of dnsmasq in the command line...
17:49
<peter43>
I tried to follow this manual: https://ltsp.github.io/docs/installation/
17:50
<alkisg>
apt install ltsp dnsmasq nfs-kernel-server openssh-server squashfs-tools ethtool net-tools epoptes
17:50
That manual installs dnsmasq...
17:50
<peter43>
However, since I had to install the deb-file (instead of using apt install ...) I probably missed somthing ...
17:50
<alkisg>
Why did you install the deb file?
17:50
To avoid the ppa?
17:50
<peter43>
I'm using Debian
17:51
<alkisg>
Yes, that page is for debian
17:51
The ppa too
17:51
https://ltsp.github.io/docs/ppa/ ==> Note that normally Debian users should not be using PPAs. LTSP is an exception, as it only contains shell code (and a bit of python), it is interpreted (Architecture:all, no compiled binaries involved), and the .debs are tested on Debian too.
17:51
<peter43>
I though ppa is only campatible with ubuntu
17:51
<alkisg>
I did spend 2-3 weeks testing the ppa on debian too :)
17:51
Have some trust
17:52
I tested on jessie, stretch, 2 buster installations, and a few debian live cds, before releasing ltsp
17:55
<peter43>
Ok, I will try this out ... I just installed dnsmaq will do some further test but I probably have to start from bginning.
17:56
<alkisg>
Nah just install the missing packages and it should be ok
17:58
<peter43>
I will work on it ... thanks a lot for your help - I come back to you later.
17:59peter43 has left IRC (peter43!5cdb64d3@ipservice-092-219-100-211.092.219.pools.vodafone-ip.de)
18:04peter14 has joined IRC (peter14!5cdb64d3@ipservice-092-219-100-211.092.219.pools.vodafone-ip.de)
18:05
<peter14>
After installing dnsmasq and reboot every is working fine now ... thanks a lot for your help.
18:06
<alkisg>
np
18:06
it would take only 1 min over vnc
18:06
(for another time)
18:08
<peter14>
Some suggestion: even Debian can use ppa .. maybe you could add dnsmasq and nfs-kernel-server to the ltsp dep-file dependencies.
18:09
<alkisg>
No, as the ltsp package is the client package, not the server package
18:12
<peter14>
Now I am confused since I installed the package on my server ...
18:13
<alkisg>
It is a bit confusing :D it also contains parts of the server code
18:13
But they're not executed on the clients
18:15
<peter14>
I see ... and many thanks again.
18:16
<alkisg>
The ltsp server may also boot live cds as images
18:16
So it needs the client code too
18:18
<vagrantc>
fwiw, you could've added experimental to your sources.list and explicitly installed: "apt install ltsp/experimental" since experimental is by default pinned to only install packages you explicitly request
18:18
but that doesn't get updated as often or as consistently
18:18
in fact, i suspect there's still a bug in it
18:20
<peter14>
No problem. I will try the deb-file for a while and later upgrade via ppa ... have a nice week.
18:21peter14 has left IRC (peter14!5cdb64d3@ipservice-092-219-100-211.092.219.pools.vodafone-ip.de)
18:22GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 268 seconds)
18:24GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com)
18:41
<vagrantc>
there's also ...
18:41
also apt install ./package.deb
18:41
which does the dependency resolution and all that
18:43
<alkisg>
Or he could just blindly follow the instructions and add the ppa and have everything ready quickly and get updates etc :D
18:46* vagrantc nods
18:47* vagrantc is always setting people up for trouble
19:22
<alkisg>
vagrantc: another path may be... I could put the binaries inside the ltsp package in the ppa, but the same package when it's build on debian wouldn't find the binaries and wouldn't have them included,
19:22
so, hopefully, in 20.04 and bullseye, it would find the binaries from the ipxe.deb, and in the meantime, it would have them included in the ltsp.deb in the ppa
19:24
No wget in the code at all; just checks in the file system, in /usr/share/ltsp/binaries or in /usr/lib/ipxe/whatever
19:30
<vagrantc>
you mean include the ipxe binary in the PPA and pretend like we'll get those features added in Debian eventually?
19:31
ah, it could first check /usr/share/ltsp/binaries, falling back to /usr/lib/ipxe (or vice-versa?)
19:31
<alkisg>
right
19:32
<vagrantc>
that sounds way better :)
19:32
where were they being wgetted to?
19:36
<alkisg>
Directly in tftp
19:43
<vagrantc>
alkisg: i like it ... additionally, alternately, /var/cache/ltsp/binaries or something like that for manual installs?
19:44
or would you rather just rely on people manually downloading to /usr/share/ltsp/binaries and a package could potentially overwrite it at some point?
19:44
less correct with my packager hat on, but certainly simpler
19:46
<alkisg>
vagrantc: manually downloading directly to tftp
19:46
We don't care if they want to cache them in /home, we don't handle their cache
19:47
We handle /usr/share/ltsp/binaries and /usr/lib/ipxe/*
19:47
Or, I could put a separate ltsp-binaries package in the ppa
19:47
And add it to the instructions, noting that it isn't needed if one doesn't use the ppa or uses a recent enough debian/ubuntu
19:48
I think I like that a bit better
19:48
<vagrantc>
alkisg: ah, we don't overwrite the binaries in tftp by default?
19:48
<alkisg>
No, we only try to wget them if they're not already there, or if forced by the user
19:48
with --binaries
19:49
So now the same switch would mean "overwrite them from /usr/*, not via wget"
19:49
<vagrantc>
with the change, we'd remove the wget part are replace with copy-from-filesystem ?
19:49
<alkisg>
Right
19:49
<vagrantc>
i like it
19:49
solves the problem in my book
19:49
<alkisg>
And, with the latest idea, /usr/share/ltsp/binaries comes from a completely separate package
19:49
ltsp can use it, but doesn't depend on it
19:49
<vagrantc>
right
19:50
<alkisg>
That way we don't lose the ability to ship the latest and greatest ipxe or whatever, and we're ok with debian too
19:50
<vagrantc>
right
19:50
<alkisg>
We only lose the download counter :P
19:50
<vagrantc>
and if someone wants to install that from the ppa, they're able to
19:50
heh
19:51
<alkisg>
Right, even just ltsp-binaries from ppa, while keeping ltsp from debian
19:51
I think I'll implement that tomorrow, if it helps getting ltsp to testing
19:51
I think ubuntu 20.04 has already started synching, it'd be nice to have ltsp e.g. before christmas there
19:52
<vagrantc>
if i then upload to unstable with a blocking bug for testing migration
19:52
though i fear we might have an unresponsive maintainer problem :(
19:53* vagrantc closed two bugs that were fixed in upstream versions included in debian 3-5 years ago
19:53
<alkisg>
Why blocking? It's ok to tell them "the binaries aren't available, please read this documentation page on how to get them"
19:53
It's only snponly
19:53
And we can even fallback to ipxe.efi instead
19:53
<vagrantc>
oh, if we have a fallback, then i'm ok to race forward :)
19:54
<alkisg>
Btw, I don't consider the server parts of ltsp as blocking,
19:54
as there are setups where *all* the server parts are elsewhere
19:54
E.g. tftp server elsewhere, dhcp elsewhere etc etc
19:54
<vagrantc>
it seems like quite an incomplete thing
19:54
without that part... but ymmv
19:54
<alkisg>
It's not like ltsp5 supported uefi booting :D
19:55
<vagrantc>
true!
19:55
<alkisg>
OK, I'll do all these, including the ipxe.efi fallback
19:55
Long day tomorrow :D
19:56
<vagrantc>
great!
19:57
curiously, my usual test environment using virt-manager/qemu uses ipxe out of the box and skips that whole "download ipxe" step
19:57
so interestingly not in a great position to test this stuff
19:57
<alkisg>
Yes, as it has enough code to read the menu
19:58
We have code in dnsmasq to do that
19:58
<vagrantc>
someone also reported very slow boot times because of the multiple dhcp requests and such
19:58
alkisg: right, i finally figured out why it wasn't trying snponly :)
19:59
<alkisg>
You can configure it to load snponly.efi anyway, not sure how much of a test that is though
19:59
<vagrantc>
right
19:59
you mean by editing dnsmasq configuration?
19:59
<alkisg>
Yes
19:59
<vagrantc>
how do you distinguish from ipxe.efi and snponly.efi ?
20:00
<alkisg>
Usually the ipxe which is included in kvm or vbox are smaller versions
20:01
So they miss some of the support like menus or https etc
20:01
And those can be checked by dhcp options
20:01
dhcp-match=set:iPXE,175,39
20:01
<vagrantc>
but not the one in debian, my usual test environment
20:01
<alkisg>
# "39" means "recent iPXE with menu support": http://ipxe.org/howto/dhcpd
20:01
<vagrantc>
apparently
20:01
<alkisg>
Then you'd put a dumber ipxe.efi :D
20:02
<vagrantc>
heh
20:02
so ... if it's recent ipxe, load an old ipxe, if it's an old ipxe, load snponly.efi ?
20:02
<alkisg>
No, I mean, you'd overwrite kvm's ipxe.efi with an old one
20:03
That way I think you wouldn't even need to modify the dnsmasq config
20:03
For example, if you compile ipxe.efi without menu support, and use that in kvm, then there's no need to change anything in dnsmasq at all
20:03
<vagrantc>
that feels quite dirty :P
20:03
but sure
20:04
<alkisg>
I think kvm also supports tianocore
20:04
So that you have a proper uefi stack,without ipxe.efi
20:04
<vagrantc>
yeah, that's what it's loading
20:04
but it still uses ipxe
20:04
virt-manager might not expose all the configurability...
20:05
<alkisg>
https://github.com/tianocore/tianocore.github.io/wiki/Enable-UEFI-PXE-Boot-in-EDK-II
20:05
PXE Boot is enabled by the EDK II network stack.
20:05
Afaik the upstream support isn't related to ipxe, but yeah virt-manager might be using ipxe for compatibility with other things
20:06
I saw eddytv remarks above, he does have a point. I asked in #ipxe about it (reuse the pxe stack dhcp packet without additional request), got not response
20:07
<vagrantc>
yeah, if i manually exit ipxe when booting, tianocore falls back to it's own dhcp implementation
20:07
<alkisg>
I think that second dhcp request only takes 1 second though, so it wouldn't save much, it's all the boot path that takes time
20:07
E.g. "network card initialization"
20:08
I think we could add syslinux.efi and grub.efi code, but for now they're a lot less stable than ipxe, so I thought I'd leave it for the future
20:09
Even with syslinux, the local kernel that eddytv asked for would be a whole lot faster
20:09
<vagrantc>
sure
20:09
<alkisg>
I'm just not sure where to put ltsp.conf then. Maybe with an fstab bind mount, to /srv/tftp/ltsp/ltsp.conf
20:10
Or add code in `ltsp initrd` to fetch it from there, so that it may be omitted from /etc/ltsp
20:10
<vagrantc>
yup, confirmed that snponly.efi gets loaded if i use tianocore's network boot implementation
20:10
<alkisg>
Reinventing the wheel... :D
20:11
<vagrantc>
!bug
20:11
<ltsp>
bug: To file a bug report for upstream LTSP, go to https://bugs.launchpad.net/ltsp
20:11
<alkisg>
!forget bug
20:11
<ltsp>
The operation succeeded.
20:11
<vagrantc>
we should fix that :)
20:11
<alkisg>
!learn bug as To file a bug report for upstream LTSP, go to https://github.com/ltsp/ltsp/issues
20:11
<ltsp>
The operation succeeded.
20:12
<vagrantc>
!bug | echo eddytv
20:12
<ltsp>
eddytv bug: To file a bug report for upstream LTSP, go to https://github.com/ltsp/ltsp/issues
20:12
<vagrantc>
eddytv: you should probably file a bug about the local kernel/initrd stuff
20:13
<alkisg>
Yeah I told him about it above ^
20:13
And a wiki page with a nice how-to :D
20:14
<eddytv>
That would be interesting... I wonder if it would be possible to have an iPXE boot option that would update the local kernel/initrd to make it easy to keep it up-to0-date
20:14
<alkisg>
eddytv: no, that would be an ltsp.conf option
20:14
!kernel
20:14
<ltsp>
I do not know about 'kernel', but I do know about these similar topics: 'ltsp-update-kernels', 'ltsp-kernel'
20:15
<alkisg>
!ltsp-kernel
20:15
<ltsp>
ltsp-kernel: Copy the kernel and initrd from an image to TFTP: https://github.com/ltsp/ltsp/blob/master/docs/ltsp-kernel.8.md
20:15
<alkisg>
No
20:15
!device
20:15
<ltsp>
I do not know about 'device', but I do know about these similar topics: 'debian'
20:15
<alkisg>
Meh anyway it was KERNEL_DEVICE in ltsp 5
20:15
So, KERNEL_DEVICE=/dev/sda5 meant "sync kernel and initrd from nfs or tftp to that partition"
20:16
And now it would need to sync ltsp.img too
20:17
<eddytv>
So it was "smart" enough to know if it needed to update the local copy?
20:17
<alkisg>
rsync
20:17
<eddytv>
Nice
20:17
<alkisg>
...or something, not sure, but yeah it didn't copy all the time
20:18
I implemented it for raspberries but also used it in a school where the card didn't support netbooting
20:18
<vagrantc>
you really shouldn't use raw device names...
20:18
<alkisg>
It was the only cards I ever found that couldn't be netbooted, compex
20:18
<vagrantc>
they're prone to changing depending on if someone left a USB stick in or not
20:18
<eddytv>
Switching topics for a sec, I was just looking at the tags that got set by dnsmasq during my testing with the Intel NUC yesterday: dnsmasq-dhcp[29190]: tags: known, iPXE, X86PC, eth1
20:19
<vagrantc>
the /dev/disk/by-* entries might be more stable, if longer
20:19
<alkisg>
Yeah it was up to the administrator, this was just an example
20:19
<eddytv>
does the presence of the "iPXE" tag mean it has "recent iPXE menu support"?
20:19
<alkisg>
Yes
20:21
<eddytv>
Hmm. Is it supposed to send `undionly.kpxe` in that case?
20:21
<alkisg>
AFAIK no, it's supposed to send the menu
20:23
<eddytv>
Looking in the dnsmasq logs, I see: 18:36:15 dnsmasq-tftp[29190]: sent /srv/tftp/ltsp/undionly.kpxe and then (10s later): 18:36:25 dnsmasq-tftp[29190]: sent /srv/tftp/ltsp/ltsp.ipxe
20:23
<alkisg>
eddytv: and you're booting from a local ipxe?
20:24
<eddytv>
not sure what you mean...
20:25
<alkisg>
The client, does it boot from the BIOS PXE support, or via grub + ipxe.lkrn?
20:25
Is it a real client? Is it a virtual client?
20:25
<eddytv>
It's an Intel NUC, during "real" netbooting
20:26
<alkisg>
OK, then it should be: first request => no ipxe tag => undionly => then request with ipxe tag => then menu
20:26
Which part is amiss?
20:27
<eddytv>
Ah, you're right. I missed that the "iPXE" tag was missing from the first request
20:27
Makes sense now.
20:44woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection)