IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 10 November 2019 (all times are UTC)
| 00:02 | eddytv 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:23 | vagrantc 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:26 | gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.28, Read error: Connection reset by peer) | |
| 06:41 | gdi2k 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:00 | gdi2k has left IRC (gdi2k!~gdi2k@103.47.144.32, Ping timeout: 240 seconds) | |
| 07:17 | gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.28) | |
| 11:37 | eu^ip9472d4a5spe has joined IRC (eu^ip9472d4a5spe!5456d4a5@84.86.212.165) | |
| 11:38 | eu^ip9472d4a5spe is now known as elec332\ | |
| 11:38 | elec332\ is now known as elec332 | |
| 13:52 | woernie 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:55 | peter16 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:23 | peter16 has left IRC (peter16!5cdb64d3@ipservice-092-219-100-211.092.219.pools.vodafone-ip.de) | |
| 16:13 | statler has joined IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de) | |
| 16:17 | woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 16:18 | woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de) | |
| 16:48 | meo has left IRC (meo!~systemdju@unaffiliated/mikeseth, Quit: leaving) | |
| 16:56 | peter53 has joined IRC (peter53!5cdb64d3@ipservice-092-219-100-211.092.219.pools.vodafone-ip.de) | |
| 17:00 | vagrantc 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:38 | peter43 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:39 | peter53 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:45 | elec332 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:59 | peter43 has left IRC (peter43!5cdb64d3@ipservice-092-219-100-211.092.219.pools.vodafone-ip.de) | |
| 18:04 | peter14 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:21 | peter14 has left IRC (peter14!5cdb64d3@ipservice-092-219-100-211.092.219.pools.vodafone-ip.de) | |
| 18:22 | GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 268 seconds) | |
| 18:24 | GodFather 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:44 | woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection) | |