IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 14 November 2019 (all times are UTC)
| 00:05 | kjackal has left IRC (kjackal!~quassel@209.121.128.189, 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 (kjackal!~quassel@209.121.128.189) | |
| 01:38 | kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 276 seconds) | |
| 01:50 | kjackal has joined IRC (kjackal!~quassel@209.121.128.189) | |
| 01:50 | eu^bb03e9cdvirtu has joined IRC (eu^bb03e9cdvirtu!bb03e9cd@187.3.233.205) | |
| 02:11 | kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 268 seconds) | |
| 02:41 | kjackal has joined IRC (kjackal!~quassel@209.121.128.189) | |
| 02:59 | kjackal 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:37 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 04:50 | kjackal has joined IRC (kjackal!~quassel@64.141.80.140) | |
| 05:00 | kjackal 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:29 | quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: WeeChat 2.6) | |
| 05:32 | quinox has joined IRC (quinox!~quinox@ghost.qtea.nl) | |
| 06:25 | <alkisg> website updated
| |
| 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 (gdi2k_!~gdi2k@58.69.160.27) | |
| 08:32 | gdi2k_ has left IRC (gdi2k_!~gdi2k@58.69.160.27, Ping timeout: 245 seconds) | |
| 08:45 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@58.69.160.27) | |
| 09:06 | gdi2k_ has left IRC (gdi2k_!~gdi2k@58.69.160.27, 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 (tbayen!~tbayen@46.114.4.200, Ping timeout: 268 seconds) | |
| 10:58 | tbayen has joined IRC (tbayen!~tbayen@x2f7fe59.dyn.telefonica.de) | |
| 11:55 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:09 | section1 has joined IRC (section1!~section1@178.33.109.106) | |
| 12:38 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 12:51 | georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, *.net *.split) | |
| 12:51 | bcg has left IRC (bcg!~b@dfx7-pyyyyyyyyyyyyyyt-3.rev.dnainternet.fi, *.net *.split) | |
| 12:51 | spectra has left IRC (spectra!~spectra@debian/developer/spectra, *.net *.split) | |
| 12:51 | sutula has left IRC (sutula!~sutula@184.100.153.93, *.net *.split) | |
| 12:53 | georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213) | |
| 12:53 | bcg has joined IRC (bcg!~b@dfx7-pyyyyyyyyyyyyyyt-3.rev.dnainternet.fi) | |
| 12:53 | spectra has joined IRC (spectra!~spectra@debian/developer/spectra) | |
| 12:53 | sutula has joined IRC (sutula!~sutula@184.100.153.93) | |
| 12:54 | derlis 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
| |