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


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

00:05kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 265 seconds)
00:19eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:5c90:f542:5be8:a75e)
00:23eddytv_ has joined IRC (eddytv_!~eddy@2601:402:4500:4670:5c90:f542:5be8:a75e)
00:29eddytv_ is now known as eddytv
01:26kjackal has joined IRC (kjackal!~quassel@209.121.128.189)
01:38kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 276 seconds)
01:50kjackal has joined IRC (kjackal!~quassel@209.121.128.189)
01:50eu^bb03e9cdvirtu has joined IRC (eu^bb03e9cdvirtu!bb03e9cd@187.3.233.205)
02:11kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 268 seconds)
02:41kjackal has joined IRC (kjackal!~quassel@209.121.128.189)
02:59kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 240 seconds)
03:31
<eddytv>
Hmm... is it expected that ltsp ipxe no longer works? It's trying to download stuff from github.com/ltsp/binaries/releases/latest/download but that hierarchy appears to be gone.
03:32
(I'm running ltsp 19.10-1~201911051455~ubuntu18.04.1)
04:04
<vagrantc>
it now copies from the filesystem
04:04
didn't know they were already removed
04:04
there's an ltsp-binaries package in the ppa
04:05
eddytv: welcome to the cutting edge :)
04:06
<eddytv>
d'oh... the docs have not been updated yet
04:07
<vagrantc>
https://ltsp.github.io/docs/installation/ has ... "apt install ltsp ltsp-binaries dnsmasq ..."
04:08
the packages in Debian are caught in some nowhere land for the time being: https://bugs.debian.org/944702
04:08
<eddytv>
Ah... I was referring to https://ltsp.github.io/man/ltsp-ipxe/
04:09
which talks about needing an internet connection and specifying alternate URLs still. I totally missed the addition of the binaries package on the main installation docs page.
04:10
<vagrantc>
quite possibly!
04:12
the ltsp-ipxe manpage was updated in git, not sure why it didn't propegate to the website
04:12
<eddytv>
OK, I did an apt update and am now running 19.11-1~201911110854~ubuntu18.04.1, and installed ltsp-binaries — now ltsp ipxe is working again. Thanks!
04:13
<vagrantc>
looks like those need to be synced
04:14
the manpages need to be sync'ed from the ltsp repository to the ltsp.github.io repository
04:22
<eddytv>
Any idea if https://github.com/ltsp/ltsp/blob/master/ltsp/common/ltsp/55-images.sh#L272-L273 is still required?
04:22
(I need to comment out that line for ltsp image to work)
04:24
If I don't comment it out, I get: modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/5.0.0-32-generic/modules.dep.bin' modprobe: FATAL: Module loop not found in directory /lib/modules/5.0.0-32-generic
04:28
Alternatively, if it's still required, could it be made to just redirect stdout/stderr to /dev/null and try continuing on if the modprobe command fails? Then I wouldn't have to manually comment out that line every update...
04:37vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
04:50kjackal has joined IRC (kjackal!~quassel@64.141.80.140)
05:00kjackal has left IRC (kjackal!~quassel@64.141.80.140, Ping timeout: 268 seconds)
05:04
<alkisg>
(06:06:27 AM) eddytv: d'oh... the docs have not been updated yet ==> whoops you're right, I updated the man pages but didn't push them to the web page, will do today
05:06
eddytv: re: modprobe, it sounds like your kernel isn't available in your image?
05:07
In general, `modprobe loop` should succeed in any system, I don't know any valid cases where it shouldn't work
05:09
And if it fails, we do want to block and notify the user, as it's necessary for VM loading (not for squashfs booting though)
05:29quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: WeeChat 2.6)
05:32quinox has joined IRC (quinox!~quinox@ghost.qtea.nl)
06:25
<alkisg>
website updated
06:28vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
07:50vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
08:27gdi2k_ has joined IRC (gdi2k_!~gdi2k@58.69.160.27)
08:32gdi2k_ has left IRC (gdi2k_!~gdi2k@58.69.160.27, Ping timeout: 245 seconds)
08:45gdi2k_ has joined IRC (gdi2k_!~gdi2k@58.69.160.27)
09:06gdi2k_ has left IRC (gdi2k_!~gdi2k@58.69.160.27, Ping timeout: 265 seconds)
09:17statler has left IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de, Remote host closed the connection)
10:17statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
10:32tbayen has left IRC (tbayen!~tbayen@46.114.4.200, Ping timeout: 268 seconds)
10:58tbayen has joined IRC (tbayen!~tbayen@x2f7fe59.dyn.telefonica.de)
11:55Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:09section1 has joined IRC (section1!~section1@178.33.109.106)
12:38mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
12:51georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, *.net *.split)
12:51bcg has left IRC (bcg!~b@dfx7-pyyyyyyyyyyyyyyt-3.rev.dnainternet.fi, *.net *.split)
12:51spectra has left IRC (spectra!~spectra@debian/developer/spectra, *.net *.split)
12:51sutula has left IRC (sutula!~sutula@184.100.153.93, *.net *.split)
12:53georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
12:53bcg has joined IRC (bcg!~b@dfx7-pyyyyyyyyyyyyyyt-3.rev.dnainternet.fi)
12:53spectra has joined IRC (spectra!~spectra@debian/developer/spectra)
12:53sutula has joined IRC (sutula!~sutula@184.100.153.93)
12:54derlis has joined IRC (derlis!be6881aa@190.104.129.170)
12:58
<derlis>
Hello partners, I need to get the data of the thinclient that enters the server. Login data logout and other data. I am NOT finding the logs. Could you give me a hand with this?
13:20
<eddytv>
alkisg: I'm running "ltsp image" (which runs "ltsp kernel", which is where the error occurs if I don't remove that line) and "ltsp ipxe" (to generate the "ltsp.ipxe" file) and "ltsp initrd" in an lxc container. I have /srv/tftp and /srv/ltsp mounts in the container, so when it's done, all the files end up in the right place for serving by dnsmasq/NFS.
13:21
But I have to manually comment out that modprobe line whenever there's a new ltsp update...
13:21
<alkisg>
eddytv: ah this issue happens on the server?!
13:21
<eddytv>
Yes
13:21
<alkisg>
OK so your server kernel is different from the container kernel... let me think...
13:21
If you modprobe loop on your host, it's solved?
13:22
derlis: which ltsp version and distribution?
13:23
eddytv: we do need the loop module on the server as well, to support VMs as image sources
13:23
E.g. someone might have a 64bit server and 32bit virtualbox VM, and use the VM as the source to ltsp image
13:24
But, we need to make your use case work too. In the best scenario, you should even be able to use a VM image within the container
13:24
<eddytv>
I think it's because I'm building my LTSP images/configs in a container. There is no /lib/modules at all in the container, but I've already defined loop devices in the container config, so mounting the squashfs it just generated does work.
13:25
(I'm also building my LTSP image from a dedicated chroot that is built via distrobuilder.)
13:26
I realize this is outside the scope of what you guys support, so if it's an issue, I'll just continue to comment out that line when I see the modprobe error.
13:31
<alkisg>
eddytv: if you `modprobe loop` outside the container, does the problem go away? What is the host, debian?
13:32
eddytv: inside the container, does this directory exist? /sys/module/loop/
13:33
We may put code to detect that if the directory is already there, it won't modprobe at all
13:33
<eddytv>
Ubuntu 18.04 + lxd 3.0.3... this issue isn't with the loop device though... it's moddep not finding modules.dep.bin... because there is no /lib/modules.
13:33
Inside (and outside) the container I do see /sys/module/loop without having to modprobe anything
13:34
<alkisg>
Great. Can you file an ltsp issue for that, so that I mention it in the commit?
13:34
<eddytv>
Will do
13:34
<alkisg>
As it's a rare use case, and we'll want to see why that line in the code exists when reading it later
13:34
Ty
13:34
<eddytv>
Thank you! Sounds like a good solution.
13:35
<alkisg>
(03:22:07 PM) alkisg: derlis: which ltsp version and distribution?
13:35
eddytv: ah, if you ever have time, I'd love to read a wiki page about using lxc with ltsp, and I guess many other users too
13:35
As we lack a famous way to maintain chroots now
13:36
So if distrobuilder and lxc can help there, it'd be awesome
13:49
<derlis>
alkisg I am using ltsp-5.4 and Debian 6.
13:51
<eddytv>
alkisg: once I get this working, I'll be happy to write up something!
13:51
<alkisg>
derlis: ouch, that's woefully outdated. Anyway, lastlog, w etc should tell you about client logins
13:51
eddytv: great, ping if you need any help
13:55
eddytv: does `modprobe overlay` also fail if you manually run it inside the container?
13:55
<eddytv>
yes, exactly the same way
13:56
<alkisg>
Ty, will do that for both cases then
13:56
It's not triggered in your case, but it might be triggered elsewhere
13:56
<eddytv>
gotcha. that makes sense
14:00
<alkisg>
Ah, we're checking /proc/filesystems there, so no need to check /sys/module/overlay
14:00
Fix committed