|00:05||kjackal has left IRC (firstname.lastname@example.org, Ping timeout: 265 seconds)|
|00:19||eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:5c90:f542:5be8:a75e)|
|00:23||eddytv_ has joined IRC (eddytv_!~eddy@2601:402:4500:4670:5c90:f542:5be8:a75e)|
|00:29||eddytv_ is now known as eddytv|
|01:26||kjackal has joined IRC (email@example.com)|
|01:38||kjackal has left IRC (firstname.lastname@example.org, Ping timeout: 276 seconds)|
|01:50||kjackal has joined IRC (email@example.com)|
|01:50||eu^bb03e9cdvirtu has joined IRC (firstname.lastname@example.org)|
|02:11||kjackal has left IRC (email@example.com, Ping timeout: 268 seconds)|
|02:41||kjackal has joined IRC (firstname.lastname@example.org)|
|02:59||kjackal has left IRC (email@example.com, Ping timeout: 240 seconds)|
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.
(I'm running ltsp 19.10-1~201911051455~ubuntu18.04.1)
it now copies from the filesystem
didn't know they were already removed
there's an ltsp-binaries package in the ppa
eddytv: welcome to the cutting edge :)
d'oh... the docs have not been updated yet
https://ltsp.github.io/docs/installation/ has ... "apt install ltsp ltsp-binaries dnsmasq ..."
the packages in Debian are caught in some nowhere land for the time being: https://bugs.debian.org/944702
Ah... I was referring to https://ltsp.github.io/man/ltsp-ipxe/
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.
the ltsp-ipxe manpage was updated in git, not sure why it didn't propegate to the website
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!
looks like those need to be synced
the manpages need to be sync'ed from the ltsp repository to the ltsp.github.io repository
Any idea if https://github.com/ltsp/ltsp/blob/master/ltsp/common/ltsp/55-images.sh#L272-L273 is still required?
(I need to comment out that line for ltsp image to work)
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
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:37||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)|
|04:50||kjackal has joined IRC (firstname.lastname@example.org)|
|05:00||kjackal has left IRC (email@example.com, Ping timeout: 268 seconds)|
(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
eddytv: re: modprobe, it sounds like your kernel isn't available in your image?
In general, `modprobe loop` should succeed in any system, I don't know any valid cases where it shouldn't work
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:29||quinox has left IRC (firstname.lastname@example.org, Quit: WeeChat 2.6)|
|05:32||quinox has joined IRC (email@example.com)|
|06:28||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
|07:50||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)|
|08:27||gdi2k_ has joined IRC (firstname.lastname@example.org)|
|08:32||gdi2k_ has left IRC (email@example.com, Ping timeout: 245 seconds)|
|08:45||gdi2k_ has joined IRC (firstname.lastname@example.org)|
|09:06||gdi2k_ has left IRC (email@example.com, Ping timeout: 265 seconds)|
|09:17||statler has left IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de, Remote host closed the connection)|
|10:17||statler has joined IRC (statler!~Georg@gwrz.lohn24.de)|
|10:32||tbayen has left IRC (firstname.lastname@example.org, Ping timeout: 268 seconds)|
|10:58||tbayen has joined IRC (email@example.com)|
|11:55||Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)|
|12:09||section1 has joined IRC (firstname.lastname@example.org)|
|12:38||mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)|
|12:51||georgeneophytou has left IRC (email@example.com, *.net *.split)|
|12:51||bcg has left IRC (firstname.lastname@example.org, *.net *.split)|
|12:51||spectra has left IRC (spectra!~spectra@debian/developer/spectra, *.net *.split)|
|12:51||sutula has left IRC (email@example.com, *.net *.split)|
|12:53||georgeneophytou has joined IRC (firstname.lastname@example.org)|
|12:53||bcg has joined IRC (email@example.com)|
|12:53||spectra has joined IRC (spectra!~spectra@debian/developer/spectra)|
|12:53||sutula has joined IRC (firstname.lastname@example.org)|
|12:54||derlis has joined IRC (email@example.com)|
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?
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.
But I have to manually comment out that modprobe line whenever there's a new ltsp update...
eddytv: ah this issue happens on the server?!
OK so your server kernel is different from the container kernel... let me think...
If you modprobe loop on your host, it's solved?
derlis: which ltsp version and distribution?
eddytv: we do need the loop module on the server as well, to support VMs as image sources
E.g. someone might have a 64bit server and 32bit virtualbox VM, and use the VM as the source to ltsp image
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
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.
(I'm also building my LTSP image from a dedicated chroot that is built via distrobuilder.)
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.
eddytv: if you `modprobe loop` outside the container, does the problem go away? What is the host, debian?
eddytv: inside the container, does this directory exist? /sys/module/loop/
We may put code to detect that if the directory is already there, it won't modprobe at all
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.
Inside (and outside) the container I do see /sys/module/loop without having to modprobe anything
Great. Can you file an ltsp issue for that, so that I mention it in the commit?
As it's a rare use case, and we'll want to see why that line in the code exists when reading it later
Thank you! Sounds like a good solution.
(03:22:07 PM) alkisg: derlis: which ltsp version and distribution?
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
As we lack a famous way to maintain chroots now
So if distrobuilder and lxc can help there, it'd be awesome
alkisg I am using ltsp-5.4 and Debian 6.
alkisg: once I get this working, I'll be happy to write up something!
derlis: ouch, that's woefully outdated. Anyway, lastlog, w etc should tell you about client logins
eddytv: great, ping if you need any help
eddytv: does `modprobe overlay` also fail if you manually run it inside the container?
yes, exactly the same way
Ty, will do that for both cases then
It's not triggered in your case, but it might be triggered elsewhere
gotcha. that makes sense
Ah, we're checking /proc/filesystems there, so no need to check /sys/module/overlay