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


Channel log from 12 March 2019   (all times are UTC)

01:46mmarconm has joined IRC (mmarconm!~mmarconm@unaffiliated/mmarconm)
01:50mmarconm has left IRC (mmarconm!~mmarconm@unaffiliated/mmarconm, Client Quit)
05:18map7 has joined IRC (map7!~user@103.232.216.31)
05:20
<map7>
Hello, I just upgraded my ltsp chroot image and tried booting one of my thin clients and got the error "No network interfaces found" (Running Debian Testing 64bit)
05:20
it seems to locate the pxelinux.o0 and download that ok
05:23
what should I check?
05:24
<alkisg>
map7: can you upload a screenshot?
05:25
<map7>
yes just a sec
05:25
<vagrantc>
most likely PXE downloaded stuff, but you're missing drivers and/or firmware for your network card in linux.
05:26
although even that...
05:26
<map7>
I'm testing through a virtualbox PXE image
05:26
like I always do
05:27
This is a remote location so it's hard for me to test with a real thin client
05:27
<alkisg>
https://prnt.sc/
05:29
<map7>
http://prnt.sc/mwmwds
05:29
<alkisg>
!quiet
05:29
<ltsp>
quiet: to enable the Debian kernel and initramfs to show up more messages, in order to better troubleshoot the boot process, remove "quiet" from /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
05:30
<alkisg>
map7: do this ^, but also change the network card type in the vm properties
05:30
E.g. from "virtio" put "intel" or something like that
05:30
Or the opposite...
05:30
<map7>
ok
05:31
<alkisg>
map7: also, are you sure you have the newer kernel?
05:31
E.g. booting with kernel 4.x when the chroot has 3.x, can cause this
05:32
(hmm although this is the initramfs, this shouldn't happen, ok)
05:33
<map7>
Kernel on the chroot: linux-image-amd64 4.19+102
05:37
<alkisg>
and `uname -r` in the initramfs, check that they match; but the most important would be to change the nic in the vm properties
05:37
<map7>
Just did a uname -r and it's running 4.19.0-2-amd64
05:37
I've tried a different NIC same problem
05:38
Just removing the quiet now
05:40
<vagrantc>
4.19.x is going to have any NICs that virtual machines support
05:41
<alkisg>
Does the initramfs version match the chroot version? They seem different to me
05:41
<vagrantc>
you want to know linux-image-4.19.*-amd64 in the chroot, not the unversioned metapackage
05:42
<map7>
http://prnt.sc/mwn01k
05:43
<alkisg>
map7: what's the output of `ip l` there?
05:43
<map7>
linux-image-4.19.0-2-amd64
05:44
<alkisg>
and which device are you using now in the VM properties?
05:44
<map7>
enp0s3
05:44
<alkisg>
And does `ipconfig enp0s3` give an ip?
05:45
<vagrantc>
could very well be a bug in debian's LTSP ... haven't tested it in months
05:45
<map7>
yes it does give an ip address of 10.1.1.246
05:45
<alkisg>
I don't think we're initializing the nic ourselves these days
05:45
<map7>
which seems correct
05:46
<alkisg>
map7: and the output of `cat /proc/cmdline`?
05:46
<map7>
I'm using a Bridged Adapter in the VM
05:46
<alkisg>
But specifically which one? Intel desktop xxx?
05:46
virtio? pcnet?
05:46
<map7>
Intel Pro/1000 MT Desktop (82540EM)
05:46
<alkisg>
And which one did you have before?
05:48
<map7>
PCnet-PCI II (Am79C970A)
05:48
http://prnt.sc/mwn1p0
05:50
<alkisg>
!ipappend
05:50
<ltsp>
ipappend: o temporarily solve DHCP problems in the initramfs, try putting IPAPPEND 3 after the APPEND line in /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default. More info: http://www.syslinux.org/wiki/index.php/SYSLINUX#IPAPPEND_flag_val_.5BPXELINUX_only.5D
05:50
<alkisg>
Can you try replacing ipappend 3 with ipappend 2?
05:51
In pxelinux.cfg/default, only in the first time you see it there
05:51* alkisg returns in half an hour...
05:51
<map7>
ok
05:58adrianorg has left IRC (adrianorg!~adrianorg@186.213.153.238, Ping timeout: 250 seconds)
06:03alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 246 seconds)
06:03sutula has left IRC (sutula!~sutula@207-118-151-61.dyn.centurytel.net, Ping timeout: 246 seconds)
06:09alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
06:10
<map7>
I get the same result with ipappend 2 as I do with ipappend 3
06:10
<vagrantc>
did you ever get the content of: cat /proc/cmdline ?
06:13
<map7>
yeah I'll paste it again
06:14
cat /proc/cmdline = http://prnt.sc/mwn9a9
06:16
booting with debug = http://prnt.sc/mwn9p0
06:27
<alkisg>
map7: it sounds like it doesn't wait for udev to make the device available before trying to get an ip
06:28
<map7>
is there something I can add to the kernel line to make it wait?
06:29
<alkisg>
map7: in the initramfs, do you have /sbin/udhcpc ?
06:30statler has joined IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de)
06:30adrianorg has joined IRC (adrianorg!~adrianorg@177.132.221.100)
06:30
<alkisg>
Hmm actually, try passing this in pxelinux.cfg/default: xtrace=udhcp
06:30
Put it where quiet was
06:31
map7: also... does it wait 30 seconds before saying "no network interfaces found"?
06:31
<map7>
I don't see a udhcpc is this supposed to be in /opt/ltsp/amd64/sbin?
06:31
it does wait a while, haven't time it though
06:31
<alkisg>
No
06:32
initramfs-tools put it there dynamically
06:32
So, in the client initramfs prompt, just run: ls /sbin/udhcpc
06:32
If it's not there, no problem, it's expected
06:32
OK, try that xtrace parameter
06:32
<map7>
yes I have /sbin/udhcpc
06:33
i see it's doing a whole lot of sed commands
06:34
with 1 second sleeps
06:35
<alkisg>
if [ -n "$(ip -oneline link show | sed -n '/ether/s/[0-9 :]*\([^:]*\).*/\1/p')" ]; then
06:35
This one?
06:35
If it does this 30 times and the NIC isn't available, then yes that's the issue
06:35
<map7>
yes it looks like that
06:36
<alkisg>
map7: I think I'd need to have a look over vnc, to try to fix the bug
06:36
!vnc-dide
06:36
<ltsp>
vnc-dide: To share your screen with me, run this: sudo apt-get --yes install x11vnc; x11vnc -connect srv1-dide.ioa.sch.gr - this is a reverse connection, it doesn't need port forwarding etc.
06:37
<alkisg>
Which one is that, debian buster?
06:37
<map7>
yes it is
06:37
<alkisg>
vagrantc: we could also just remove udhcpc completely, the issues I filed years ago have been fixed upstream, we don't need it anymore
06:37
That's my udhcpc script, not busybox udhcpc
06:38
How is buster wrt such changes?
06:38
map7: if you are able to vnc, I do have a bit of time now
06:39
<map7>
yep one sec
06:41
I just ran the x11vnc line
06:42
but it fails
06:42
<alkisg>
I didn't receive any connection
06:42
Message?
06:42
What's your host distro/version
06:42
?
06:42
<map7>
Debian testing (buster)
06:43
<alkisg>
Are you using x2go or something to access the server?
06:43ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
06:43
<map7>
yes I'm on x2go
06:43
this could confuse things
06:43
<alkisg>
Try: x11vnc -noshm -connect srv1-dide.ioa.sch.gr
06:46
map7: put pass + press enter
06:47
<map7>
i did have ipappend 2, but reverted it back to 3
06:47
after testing
06:50
<alkisg>
map7: `ip -oneline link show` doesn't show the nic
06:51
<map7>
yeah i noticed that just then
06:52
<alkisg>
map7: it looks like a bug in `ip`
06:53
<map7>
is the ip command a different version?
06:53
looks like it works on the server not the client
06:53
ah it's the busybox version
06:54
<alkisg>
Yes, file a bug report against busybox in debian testing
06:54
And tell them that -oneline is broken
06:54
<map7>
ok will do
06:56
<alkisg>
To work around, you'd need to:
06:56
Delete chroot/usr/share/initramfs-tools/scripts/init-premount/udhcpc,
06:56
regenerate the initramfs,
06:56
AND switch to ipappend 2
06:57
<map7>
to generate the initramfs do I just run the update-initramfs in the chroot section?
06:57
<alkisg>
sudo ltsp-chroot update-initramfs -u
06:57
and ltsp-update-image/kernels
06:58
<map7>
ok, thanks for your help alkisg you have been amazing
06:58
<alkisg>
You're welcome
06:59
<map7>
I'll report the bug and try the work around.
07:00
<alkisg>
busybox 1.27.2 works here in my vm
07:00
Which version do you have?
07:00
(I closed the vnc connection)
07:00
<map7>
1.30.1-2
07:01
<alkisg>
Why? That's not what testing has
07:01
You're using things from unstable...
07:01
<map7>
hmmm, I shouldn't be as my repository says testing
07:01
<alkisg>
https://packages.debian.org/search?keywords=busybox
07:01
`apt policy busybox` should tell you
07:02
<map7>
500 http://ftp.au.debian.org/debian testing/main amd64 Packages
07:02
<alkisg>
Do the vnc command again
07:02
<map7>
*** 1:1.30.1-2 500
07:02
<alkisg>
x11vnc -noshm -connect srv1-dide.ioa.sch.gr
07:04
map7: ok so good news, it just broke in the latest update a few days ago
07:04
So it should be easy to get the regression fixed
07:04
<map7>
great
07:05
i see
07:07
<alkisg>
So a more proper workaround would be to download 1:1.27.2-3 from the ftp server and install it using `dpkg -i`
07:08
<map7>
I was just thinking that
07:08
it would be cleaner, I might just do that and report the bug
07:08
and freeze the package incase someone upgrades everything in the meantime
07:09
<alkisg>
`apt hold` helps with that
07:09
<map7>
cheers
07:09
<alkisg>
(in the chroot)
07:09
cheers
07:09
<map7>
thanks
07:20spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Ping timeout: 246 seconds)
07:30Natureshadow has joined IRC (Natureshadow!45d1515d22@commu.teckids.org)
07:39
<map7>
alkisg: I've sent the report and I downgraded busybox and all my thin clients came to life again
07:39
thanks again.
07:39
<alkisg>
Great
07:39
np
07:52
<vagrantc>
map7: cc me on the bug report: vagrant@debian.org
07:52
map7: or i guess if you've already filed, give me the number :)
07:52
so i can subscribe to it
07:53
actually, x-debbugs-cc: vagrant@debian.org ... if you still can
07:55
alkisg: fwiw, recent versions of apt support "apt install ./package.deb" rather than "dpkg -i" ... and then it properly handles dependencies and such
07:56
<alkisg>
vagrantc: true, I'm using that a lot
07:56
<vagrantc>
recent including debian stable, so who knows how many ubuntu releases ago...
07:57
<alkisg>
At least since 16.04, I haven't discovered it before that though
07:58
<vagrantc>
ran my first wayland session today ... a rewrite of my favorite window manager was released today and figured i'd try it :)
07:58
16.04 is pretty far back
07:58
<alkisg>
vagrantc: about wayland, I figure we can just completely deprecate thin clients, and only advice users to run xrdp or whatever else supports wayland as a session after login
07:59
So in the new ltsp version, I'm not going to bother with thin clients at all, hope that's ok
07:59
<vagrantc>
i think it mostly just runs xwayland... can barely tell the difference, but it doesnt' need a login manager, you can just login from console and run it :)
08:00
alkisg: i'm thinking dropping thin clients is fine ... if someone needs it and comes up with reasonable patches, then reconsider ... but year, xrdp or x2go or whatever might make more sense for fully thin clients
08:00
<alkisg>
Great
08:01
<vagrantc>
but i don't have any issues with the next major rewrite not coming with thin clients support out of the box
08:06kjackal has joined IRC (kjackal!~quassel@2a02:587:3119:ef00:ed02:b2af:e92c:df84)
08:45Da-Geek has joined IRC (Da-Geek!~Da-Geek@212.250.100.150)
08:54
<Hyperbyte>
No more thin clients?!
08:54
It's end of an era. :-(
08:54
<alkisg>
"remote xorg" doesn't really work when there's no xorg :D
08:54
RDP, VNC etc will continue to work
08:54
<vagrantc>
and it's been in bitrot for ages
08:54
<alkisg>
So it's "netbooted with remote desktop"
08:55
Not "netbooted with remote xorg"
08:55
You can still call it a thin client if you like it
08:56
<Hyperbyte>
It just won't be the same. </3
09:00
<alkisg>
Btw, I think rdp and x2go handle printers and local/remote devices better than ltsp nowadays
09:09
<Hyperbyte>
I'm actually only still using thin clients in one place and there's an investment plan to get rid of them... so...
09:09
I may appear to care, but I actually don't. ;-)
09:09
<alkisg>
:D
09:10statler has left IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de, Remote host closed the connection)
09:15GodFather has left IRC (GodFather!~rcc@66.210.242.210, Read error: Connection reset by peer)
09:15GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net)
09:41vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
09:45statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
11:52Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:03spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
13:10[GuS] has joined IRC ([GuS]!~gustavo@2800:810:451:84ea:2480:6301:a427:59c5)
13:12
<[GuS]>
Hi, I have a problem with LTSP, which I don't know is because works like that. My network is Gigalan, Server with Xubuntu 18.04, latest LTSP from its repository (the one that suggest in LTSP Wiki, Installation). Some workstations has a dedicated nVidia GPU, others just an Intel one. Now every workstations has no aceleration at all and you can notice that most of all in browsers. Is there a way to fix this?
13:12
I can't find anything searching on Google related to this exactly.
13:18
(also the client images are i386, just in case)
13:28adrianorg has left IRC (adrianorg!~adrianorg@177.132.221.100, Ping timeout: 272 seconds)
14:09pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, *.net *.split)
14:16pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
14:43
<alkisg>
[GuS]: did you manually install the nvidia drivers?
14:43
How many images do you have, just one?
14:43
And are you using a chroot or not?
14:48[GuS] has left IRC ([GuS]!~gustavo@2800:810:451:84ea:2480:6301:a427:59c5, Ping timeout: 252 seconds)
15:55kjackal has left IRC (kjackal!~quassel@2a02:587:3119:ef00:ed02:b2af:e92c:df84, Ping timeout: 252 seconds)
16:11spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Quit: Leaving)
16:13spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
16:22adrianorg has joined IRC (adrianorg!~adrianorg@177.18.50.11)
16:44Da-Geek has left IRC (Da-Geek!~Da-Geek@212.250.100.150, Ping timeout: 246 seconds)
17:03kjackal has joined IRC (kjackal!~quassel@thecube.ath.forthnet.gr)
17:04Da-Geek has joined IRC (Da-Geek!~Da-Geek@212.250.100.150)
17:06
<quinox>
I had trouble mixing nvidia closed source drivers with ati closed source drivers in a single image
17:06
they destroy each others files
17:08Da-Geek has left IRC (Da-Geek!~Da-Geek@212.250.100.150, Remote host closed the connection)
17:10
<quinox>
I no longer use the closed source ones
17:10kjackal has left IRC (kjackal!~quassel@thecube.ath.forthnet.gr, Ping timeout: 246 seconds)
17:13
<mwalters>
interestingly enough... they generally coexist on a windows box just fine... I used to use an older nvidia purely for physx while using an ATI has my primary video card
17:14
I never tried a mix system with linux
18:00[GuS] has joined IRC ([GuS]!~gustavo@2800:810:451:84ea:2480:6301:a427:59c5)
18:01
<quinox>
I don't really blame them, they have to hack around some weird shit I'd imagine
18:01
<[GuS]>
alkisg: LTSP under chroot, is using nouveau (for those with nvidia driver, which checked with lspci in the thin client) and only one image (i386)
18:02
<quinox>
are they accelerated when using a non-LTSP Ubuntu with nouveau?
18:04
<[GuS]>
Yeah, tested even with a KDE Neon live USB
18:04
<quinox>
you want thin clients?
18:04
<[GuS]>
(at least, the nvidia boards ones)
18:04
<quinox>
the thing with thin clients is that everything runs on the server
18:05
<[GuS]>
I already know that
18:05
<quinox>
so no hardware acceleration
18:05
<[GuS]>
But is not suppose that uses hardware video on thin client?
18:05
<quinox>
it uses the hardware for showing the pixels on the screen, but it can't use the hardware for accelerating anything
18:06
<[GuS]>
Oks
18:06
Then I had the wrong info all this years :P
18:06
<quinox>
fat clients are the way of the future
18:06
much better experience, as long as you have RAM and a decent CPU
18:06
<[GuS]>
Yeah, which some thin clients here are not the case, which are old one core only :P
18:07
Well, I will have to upgrade at least to a mini PC... just wanted to try again with LTSP, which passed many years since last time used...
18:07
<quinox>
I have no idea about your situation, but hardware isn't too expensive anymore
18:07
<[GuS]>
Not in my country, which they are
18:08
(Argentina)
18:08
Even a small mini pc are expensive.
18:08
So i was migrating a client of mine, which had all these computers with windows xp.
18:09
Well, quinox thanks for that update!
18:09
<quinox>
no problem
18:09
<[GuS]>
and thanks alkisg.
18:10[GuS] has left IRC ([GuS]!~gustavo@2800:810:451:84ea:2480:6301:a427:59c5, Quit: Konversation terminated!)
18:12
<mwalters>
if the thin client had the proper modules in the image, would it accelerate something run with ltsp-localapps?
18:16
<quinox>
I would guess.. yes?
18:17
knowing their CPU and memory impact, as soon as you run your browser as a localapp you might as well use fat clients
18:18
<mwalters>
more a curiosity than anything else
18:18
<quinox>
(and damn those electron apps)
18:18
<alkisg>
localapps are nice for things like tuxpaint/tuxtype, i.e. lightweight apps with little ram/cpu and lots of graphics
18:18
<mwalters>
we used to use it for chrome
18:19
before updating to 18.04
18:19
<alkisg>
If one starts a browser, he'd better just switch to fat clients
18:19
<mwalters>
I think my users struggle with the startup delay of fat clients
18:19
(app launching)
18:20
Mate doesn't seem to give you a busy cursor when you launch something =/
18:20
So they end up trying to launch chrome like 5 times because it takes 5 seconds to open :D
18:20
<alkisg>
Haha
18:20
It would be the same with local installations though
18:20
What I want for the future is to use small and really fast ssd-based storage for caching
18:20
<mwalters>
yeah, it was the same thing, for whatever reason I think metacity did the busy cursor thing
18:21
<alkisg>
So if the ltsp image is cached locally, and can be read at 500 mb/sec... things would open in 1 sec
18:21
<mwalters>
eer... retro... whatever that retro gnome DE was
18:21
<quinox>
tearing wise Wayland has been a pleasant surprise
18:21
<mwalters>
that'd be nice
18:22
I'm sure most of our UX ... oddities... would be solved by the busy cursor showing correctly ;)
18:23
<quinox>
yeah, that kind of stuff is quite important for the user experience
18:24
<alkisg>
A bug report could help :)
18:24
In mate
18:24
<mwalters>
that'd require me to actually test out crap ;)
18:24
I'm busy writing technology plans and policies and procedures =/
18:24
...and chatting on irc ;)
18:39
<quinox>
the next generation LTSP will support wayland yeah?
18:41
<alkisg>
That's the plan
18:42
<quinox>
excellent
18:57statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
18:59
<highvoltage>
well it's going to be fat client so it will support basically anything
19:04
<alkisg>
E.g. ldm needs x
19:04
so we'll need to either make ldm support wayland, or use a real DM and pamssh
19:12vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
20:53josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Quit: The Lounge - https://thelounge.chat)
21:59kjackal has joined IRC (kjackal!~quassel@2a02:587:3119:ef00:905a:842c:23e9:9e2c)
22:03josefig has joined IRC (josefig!~josefig@unaffiliated/josefig)
22:14Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
23:01kjackal has left IRC (kjackal!~quassel@2a02:587:3119:ef00:905a:842c:23e9:9e2c, Ping timeout: 252 seconds)
23:39vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 252 seconds)
23:52ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)