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


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

00:08ltspuser456 has left IRC (ltspuser456!d510b783@hypernet.the.forthnet.gr, Ping timeout: 260 seconds)
00:27kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 265 seconds)
00:43kjackal has joined IRC (kjackal!~quassel@209.121.128.189)
01:02kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 276 seconds)
02:19eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:359e:f3f:9ea7:9540, Quit: My computer has gone to sleep. ZZZzzz…)
02:20eddytv has joined IRC (eddytv!~eddy@2601:402:4500:4670:744f:2b1c:b6af:dc88)
03:12kjackal has joined IRC (kjackal!~quassel@64.141.80.139)
04:45kjackal has left IRC (kjackal!~quassel@64.141.80.139, Ping timeout: 265 seconds)
05:12
<alkisg>
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944565 , yey!
05:12
'morning all
05:13
<vagrantc>
and good night!
05:14
<alkisg>
:D
05:14* vagrantc waves
05:14
<alkisg>
Bye vagrant
05:14
<vagrantc>
just like old times :)
05:14
<alkisg>
True!
05:14
A nice feeling!
05:14
<vagrantc>
ltsp even built reproducibly on armhf :)
05:15
<alkisg>
Ah
05:15
vagrantc, if I wanted to buy one board only, which one would you suggest?
05:15
(not rpi, I already have 5 of those)
05:15
<vagrantc>
hard call at this point
05:15
<alkisg>
Something that is the most ...common? mainstream? uses uboot?
05:15
<vagrantc>
topic for another day
05:15
<alkisg>
One that if ltsp was supported there, it would be on most of them
05:15
ok
05:15
'night!
05:16
<vagrantc>
probably doesn't exist yet, but there are a few that might be getting there :)
05:16vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
05:27eu^ip1f12fd11dyn has joined IRC (eu^ip1f12fd11dyn!1f12fd11@31.18.253.17)
05:30
<eu^ip1f12fd11dyn>
wie instliere ich mint cinnemon 32bit auf einen ltsp
05:31
<alkisg>
eu^ip1f12fd11dyn: hi, sorry this channel is english-only; you may use google translate if you want
05:32
<eu^ip1f12fd11dyn>
wie installiere ich mint cinnamon 32 bit auf einen ltsp
05:33
<alkisg>
eu^ip1f12fd11dyn: https://ltsp.github.io/docs/installation/
05:36
<eu^ip1f12fd11dyn>
linux mint 19.2 is a 64bit system my client is a 32bit is this a problem
05:36
<alkisg>
(1) install 32bit server, or (2) create a 32 bit VM, or (3) create a 32bit chroot
05:36
3 solutions
05:37
<eu^ip1f12fd11dyn>
ok thanks
05:37
<alkisg>
The chroot must be based on ubuntu 18.04 which is 32bit
05:37
I don't know which mint is 18.04
05:37
maybe tara
05:38
Ah all of them are LTS now
05:38
So 19.2 also supports 32bit
05:40
It's silly that mint uses different versions from ubuntu, it just confuses people
05:41
<eu^ip1f12fd11dyn>
thanks
05:41
bye
05:41
<alkisg>
bye
05:41
make sure to use ltsp 19
05:41
not ltsp 5
05:41eu^ip1f12fd11dyn has left IRC (eu^ip1f12fd11dyn!1f12fd11@31.18.253.17, Remote host closed the connection)
06:01statler has joined IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de)
06:58woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de)
07:03
<enoch88483838>
alkisg, ok back online
07:03
<alkisg>
Heya enoch88483838
07:04
<enoch88483838>
The thing is this, I already have the old VM left, with the 4.10 kernel
07:04
It works, but I wanted the latest kernel
07:04
<alkisg>
The old VM uses 16.04
07:04
Not 18.04
07:04
<enoch88483838>
"just becuase I can" :)
07:04
aah that's also trye
07:04
true*
07:04
<alkisg>
I'm talking about stock 18.04
07:04
Read this: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
07:05
18.04 has TWO stacks, we just want one of them
07:05
We don't want to "downgrade"
07:05
Otherwise, you're looking to troubleshoot kernel/xorg issues. We can do that, but it's another topic.
07:05
We'd need to bisect, find the commit that broke it, report it upstream, test patches etc
07:05
It would take a few days, but it would make your clients boot in the future too
07:06
<enoch88483838>
ok, so reinstall 18.04 (I like it clean), or use the current, install 4.15 kernels and then uninstall 5.0?
07:06
<alkisg>
Use current, test 4.15, and only if it fixes thing, then uninstall 5
07:06
<enoch88483838>
ok
07:06
let's go
07:06
<alkisg>
Btw was it working fine in 4.10?
07:06
Specifically the dual screen
07:06
<enoch88483838>
yes, you fixed that with forcing DP
07:07
<alkisg>
I think I did that in 18.04
07:07
Not in 16.04
07:07
<enoch88483838>
"the old" fix which isn't working anymore
07:07
let me double check
07:07
I'm not sure if it was 16.04 or 18.04
07:07
<alkisg>
How easy is it for you to boot those clients with live CDs/USB sticks?
07:07
And test various ubuntu versions?
07:07
<enoch88483838>
very easy, it's a VM :)
07:07
<alkisg>
When you find one that boots with dual screen on, we'd know when it was working
07:08
I'm talking about the real client
07:08
<enoch88483838>
aah
07:08
<alkisg>
To test dual screen with live usb sticks
07:08
<enoch88483838>
not that easy
07:08
<alkisg>
I can make you a usb stick if you want
07:08
<enoch88483838>
the specs are too bad
07:08
no need, I've tried all the planets isb sticks and they;
07:08
1. don't work
07:09
2. are very slow
07:09
usb*
07:09
due to hw limitations
07:09
<alkisg>
So, dual screens were never properly working out of the box?
07:09
I'm starting to think it might be related to your cable or screen
07:09
<enoch88483838>
never tried dual screens as I was only testing
07:09
<alkisg>
Can you test with another dp cable and/or another screen?
07:09
<enoch88483838>
I can test with 18.04 live today
07:10
on a dual screec pc
07:10
<alkisg>
You can just boot it as an ltsp client
07:10
Right
07:10
<enoch88483838>
and get back to you
07:10
<alkisg>
So:
07:10
I think this problem might be:
07:10
<enoch88483838>
brb coffe
07:10
<alkisg>
1) caused by cabling, screen etc => troubleshoot that first
07:10
2) caused by a kernel regression => we'd need to use e.g. 4.15 and stock xorg
07:11
3) always existing in the kernel/xorg => we'd need to find workarounds, report bugs etc
07:11
So start with testing (1) and we'll see later about the others
07:12
<enoch88483838>
sure thing
07:52
so I live booted 18.04.1 on the client PC directly
07:52
that was 20 minutes ago
07:53
it's still loading the browser....
07:53
and DP doesn't work
07:53
<alkisg>
enoch88483838: start by changing the cable/screen
07:53
I.e. check if you have a hardware issue
07:53
Don't bother with software yet
07:54
<enoch88483838>
the new pc had different screens
07:55
the cables I used are standard in the company, so it must work with them, or we have to bu 58473932 new cables (more like 200, but still)
07:55
buy*
07:55
<alkisg>
Yes, but if you know the problem it's a lot more easier to handle it
07:55
<enoch88483838>
ok
07:55
<alkisg>
You don't spend days searching for software solutions when the problem is in the hardware
07:56
<enoch88483838>
I can send you the specs
07:56
sec
07:56
<alkisg>
You then look for workarounds
07:56
No
07:56
Just test with another cable
07:56
<enoch88483838>
I don't have any :/
07:56
<alkisg>
I don't have any way to get from specs to solutions :)
07:56
OK, so, so far you've tested with different PC and different screen, but not different cable?
07:56
<enoch88483838>
the cable we are using now are the only one that was working in the old sulution
07:57
solution*
07:57
<alkisg>
What was the old solution?
07:57
<enoch88483838>
with kernel 2.2
07:57
Thinpro 3
07:57
HP
07:57
<alkisg>
Kernel 2.2 had support for DP?
07:57
That sounds strange...
07:57
<enoch88483838>
it works...
07:57
<alkisg>
OK tell me the specs
07:57
I think something is amiss
07:57
<enoch88483838>
sec
08:00
<alkisg>
Maybe HP had a heavily patched old kernel in thinpro
08:01
<enoch88483838>
ok, I was lying
08:01
it's 2.6
08:01
will send you specs soon
08:01
https://cloud.danielhansson.nu/s/QKyg9dFHQ58H25H
08:02
forgot software, sec
08:03
<alkisg>
enoch88483838: and to clear something else up: you haven't found any linux distro/version where dual screens work out of the box (except thinpro). Correct?
08:03
(that would allow us to assume that the kernel never properly supported these, so we need to look for workarounds, not other kernels)
08:04
<enoch88483838>
alkisg I don't remember tbh, I've tested so many different distros I forgot the name of half of them
08:04
many times it wouldn't even boot
08:04
LTSP is my last resort, and it seems to be working nice actually
08:04
<alkisg>
OK. Do you want me to (1) check workarounds, (2) check the older kernel/xorg, (3) do nothing while you check via usb sticks etc?
08:05
<highvoltage>
LTSP is my last resort, that's a papa roach song right?
08:05
<enoch88483838>
highvoltage haha no idea
08:05
<alkisg>
Hehe
08:05
Those are too young for me to have heard of them :P
08:05
<enoch88483838>
alkisg do you recomend trying 16.04?
08:05
at least that worked when forcing
08:06
or 14.04 even maybe?
08:06
live booting
08:06
I would like to take as little time from you as possible :)
08:06
<alkisg>
enoch88483838: if you can test these with live booting, sure, any information "it works out of the box there" would help
08:06
<enoch88483838>
ok, will try with 14.04
08:06
<alkisg>
Otherwise, we can just install the 4.15 kernel/xorg
08:06
Try with 18.04.1
08:07
This has the 4.15 kernel
08:07
<enoch88483838>
but, I just tested to live boot 18.04.1 and it didn't work
08:07
<alkisg>
Then with 16.04.1
08:07
What part didn't work?
08:07
<enoch88483838>
dual screens
08:07
DP
08:07
<alkisg>
Everything else worked?
08:07
Does it work if you *only* have DP connected?
08:07
<enoch88483838>
well, as it took more than 20 minutes to boot into browser I didn't test, but yes, it seems so
08:07
I can try again
08:07
<alkisg>
Hehe
08:08
OK try 16.04.1 then
08:08
Don't go to 14.04
08:08
it's too old, unmaintained etc
08:08
Can't easily install such an old kernel
08:08
Note that 16.04.5 has 4.15; so test with 16.04.1, not .5
08:10
<enoch88483838>
18.04.1 boots with DP if **only** that one is connected
08:10
<alkisg>
That's good news
08:10
<enoch88483838>
I can test with 18.04.3 as well, same test
08:10
or no?
08:11
<alkisg>
You could probably just boot ltsp with just dp
08:11
<enoch88483838>
Can sure try
08:11
sec
08:11
<alkisg>
Which is 18.04.3
08:16
<enoch88483838>
I was too quick
08:16
it stops in the same place as LTSP
08:16
after loading the kernel
08:16
video is coming soon
08:16
<alkisg>
Even single screen?
08:17
<enoch88483838>
yes, that was what I tested
08:17
same error output as in LTSP
08:17
https://cloud.danielhansson.nu/s/fjrjz3DZgcpe5fC
08:18
at -02
08:19
-0:02*
08:19
the the screen dies
08:19
I can give you the cable as well
08:19
sec
08:19
<alkisg>
enoch88483838: and if you have only VGA, it works?
08:20
<enoch88483838>
VGA works yes
08:21
<alkisg>
Without that error? With the same usb stick?
08:21
<enoch88483838>
yes
08:21
18.04.1 live
08:21
<alkisg>
OK, try 16.04.1
08:21
<enoch88483838>
ok
08:23
Swedish, but still: https://www.atea.se/eshop/product/deltaco-dp-1013/?prodid=1889887
08:29
<alkisg>
enoch88483838: try this kernel parameter: i915.enable_dp_mst=0
08:30
<enoch88483838>
on the current LTSP?
08:30
<alkisg>
Wherever, sure
08:30
<enoch88483838>
ok
08:31
can I enable that under [clients]?
08:31
<alkisg>
No
08:31
<enoch88483838>
it must be specific?
08:31
<alkisg>
KERNEL_PARAMETERS only work per client at this point
08:31
<enoch88483838>
to a MAC?
08:31
<alkisg>
Yes, for now
08:31
<enoch88483838>
okok
08:33
<alkisg>
enoch88483838: finally, I see a related bug was solved upstream in Apr 2018, it might make sense to test with 19.10 live usb too
08:33
<enoch88483838>
okok
08:33
testing 16.04 now soon, and will test LTSP with that kernel hack, and then live boot 19.10
08:37gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.27)
08:44
<enoch88483838>
16.04.1 with dual screens didn't work, LTSP with that kernel parameter didn't work. Testing 19.10 now
08:44
<alkisg>
Did you run ltsp initrd when testing ltsp?
08:44
*and ltsp ipxe
08:44
<enoch88483838>
uuh, no
08:44
haha
08:44
<alkisg>
Then it wasn't applied :)
08:44
<enoch88483838>
got that
08:44
will try again
08:46gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.27, Read error: Connection reset by peer)
08:47gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.28)
08:48
<enoch88483838>
ok, so that didn't work either
08:48
(LTSP)
08:48
will try with 19.10 soon
09:03enoch88483838 has left IRC (enoch88483838!25f71ea4@37-247-30-164.customers.ownit.se, Ping timeout: 260 seconds)
09:16enoch911 has joined IRC (enoch911!25f71ea4@37-247-30-164.customers.ownit.se)
09:16
<enoch911>
alkisg got disconnnected
09:16
anyway: https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
09:16
19.10 isn't available for 32 bit
09:16
afaik
09:17
<alkisg>
True, ouch, you'd need a new kernel in 18.04 to test that
09:18
<enoch911>
isn't HWE the latest?
09:18
<alkisg>
There's also hwe-edge
09:18
Which is kernel 5.3 and possibly even newer xorg
09:18
<enoch911>
okok
09:19
I can always try
09:19
have snapshot so :)
09:21
<alkisg>
enoch911: if you want to speed things up, you can test with live cds etc while I test on the ltsp server
09:21
If there's no hurry, you can test everything yourself ;)
09:22
<enoch911>
I'm installing hwe-edge as we speak
09:22
my goal is to be done with this - this week
09:27
linux-generic-hwe-18.04-edge 5.3.0.19.85
09:27
is that the patched one?
09:27
<alkisg>
Yes and you also need xorg
09:28
<enoch911>
ok, hmm
09:30
xserver-xorg-hwe-18.04 is already the newest version (1:7.7+19ubuntu8~18.04.2).xserver-xorg-hwe-18.04 set to manually installed.
09:30
Are there a newer one?
09:31
<alkisg>
Isn't there an -edge?
09:31
<enoch911>
E: Unable to locate package xserver-xorg-hwe-18.04-edge
09:31
<alkisg>
OK then no :)
09:31
<enoch911>
ok :)
09:31
uninstalled 5.0 and only running 5.3 now
09:31
so let's see
09:31
root@ltsp2019:~# uname -r5.3.0-19-generic
09:32
brb
09:44
ok, no luck on 5.3 kernel
09:44
:/
09:44
calling 911 on alkisg
09:44
<alkisg>
Hehe
09:44
enoch911: OK, we'll need to test workarounds then
09:45
Give me half an hour or so to finish some other things
09:45
<enoch911>
ok sure
09:45
I could reinstall everyting with 18.0.1 if you prefer that?
09:45
or stay on 5.3?
09:46
with 18.04.3
09:46
<alkisg>
Stay on 5.3
09:46
It'll come as an update in a while anyway
09:46
<enoch911>
vnc setup
09:47
shes all yours
09:47
<alkisg>
Does the client reboot to linux?
09:47
or do you have to press something, f12 etc?
09:47
<enoch911>
aah, need to fix that
09:47
sec
09:47
<alkisg>
OK, please prepare 2 screens, automatic boot from network etc
09:49
<enoch911>
on it
10:02
ok done
10:03
<alkisg>
OK, will be available in half an hour or so...
10:03
I need to finish some things first
10:03
<enoch911>
no problem
10:03
no rush
10:04
it's the 50 client that has dual screens btw
10:04
<alkisg>
OK
10:28
enoch911: you didn't run ltsp ipxe, you didn't put it to the correct client :D
10:28
Let's see if that parameter does make any difference though...
10:28
<enoch911>
okok
10:29
you didn't put it to the correct client, that was another one I was testing on
10:29
anyway :)
10:29
<alkisg>
ok
10:33
<enoch911>
brb
10:33
<alkisg>
ok
10:36
<enoch911>
back
10:36
any luck?
10:36
<alkisg>
Not yet
10:37
<enoch911>
btw, with the old soulution the DP went to sleep randomly and came back after a few seconds, don't know if that tells you anything?
10:38
<alkisg>
I think it tells me that HP is using something that isn't supported well by the upstream kernel
10:38
Maybe the proper solution is to report the issue upstream so that they fix it for all future releases
10:38
And give feedback in whatever they ask, even if it takes a couple of weeks for them
10:38
<enoch911>
I don't think they support hardware from 2009 any more
10:38
especially not this
10:39
<alkisg>
It's i915
10:39
<enoch911>
aah
10:39
<alkisg>
It's still supported
10:39
Those dmesg errors there
10:39
These are what we want to report to freedesktop.org
10:40
<enoch911>
another thing, in freerdp yopu could use //dualmonitor, I don't know if that would work when connecting to the windows server as it won't even work in the "main" OS
10:40
single /
10:40
<alkisg>
Of course not
10:40
<enoch911>
just checking :)
10:42
<alkisg>
Ah firewall again
10:42
<enoch911>
need to open from 192.168.2.8?
10:42
<alkisg>
.50
10:42
<enoch911>
2.8 being the server
10:42
<alkisg>
dunno
10:42
I was trying from the client now
10:42
<enoch911>
ok
10:42
<alkisg>
To pastebin xorg.log
10:43
<enoch911>
that's closed down
10:43
<alkisg>
and dmesg
10:43
<enoch911>
will open for that as well
10:43
sec
10:44
try again
10:44
<alkisg>
OK will get clean logs after reboot
10:44
<enoch911>
ok
10:46
<alkisg>
enoch911: btw, do the clients also have hdmi that you could use if you bought cables?
10:46
<enoch911>
no, only dp
10:46
<alkisg>
vga and dp?
10:46
<enoch911>
yes
10:46
<alkisg>
Is that dp to dp monitor? Or e.g. dp to hdmi monitor?
10:47
<enoch911>
you mean with an adapter?
10:47
the monitor has hdmi, dp, vga
10:48
so, one screen vga --> vga
10:48
the other is dp --> dp
10:48* alkisg looks for dp -> hdmi
10:49
<enoch911>
but the client only have vga and dp as stated above
10:50
<alkisg>
For example: https://www.skroutz.gr/c/1944/kalodia_displayport/f/612230/HDMI-male.html
10:50
It might be worth it to see if a cable like that would work
10:50
<enoch911>
aah, ok now I follow
10:50
only thing I could get right now is an adapter for that
10:51
all cables we have are pure DP
10:51
I can check one extra time
10:51
sexc
10:51
sec
10:52
<alkisg>
dmesg=https://termbin.com/26hi xorg.0.log = https://termbin.com/hmbm
10:53
<enoch911>
no we didn't even have an adapter, that was hdmi in dp out
10:53
<alkisg>
enoch911: it might be worth it to go to a store and buy such a cable with 5 euros
10:53
<enoch911>
haha yeah, it might
10:53
I'll do that when my colleges are back from lunch
10:54
<alkisg>
dmesg after `echo on > /sys/class/drm/card0-DP-1/status` https://termbin.com/l2ar
10:57
cat /sys/kernel/debug/dri/0/i915_display_info = https://termbin.com/9ul1
10:57
<enoch911>
ok, found a hdmi to hdmi
10:57
<alkisg>
I don't think that would help :)
10:57
<enoch911>
put an adapter on it to make it work with dp
10:57
hackish but might work
10:57
<alkisg>
Ah ok if you have adapter
10:58
<enoch911>
should I change now?
10:58
<alkisg>
Can you test with another client?
10:58
<enoch911>
single screen yes
10:58
works?
10:58
<alkisg>
OK, single DP screen, sure
10:58
It's not related to dual screen
10:58
It's just that DP doesn't work in this HP model
11:05
<enoch911>
ok, so from monitor: hdmi > adapter > DP works
11:06
155 is HDMI test
11:06
<alkisg>
Good news
11:06
<enoch911>
problem now is that almost all our screens is DP
11:07
agreed
11:07
:)
11:07
so you think it will work aithout any hacks with HDMI?
11:07
without*
11:07
<alkisg>
Eeeh
11:07
didn't you say the client doesn't have hdmi?
11:07
How is it displaying hdmi now?
11:08
<enoch911>
yes, that's correct, it's working with an adapter
11:08
<alkisg>
I don't get it. To the back of the client, there's only VGA and DP, right?
11:08
Where did the adapter go, to DP?
11:09
<enoch911>
https://www.atea.se/eshop/product/deltaco-dp-hdmi30/?prodid=1502194
11:09
<alkisg>
So xrandr is reporting that you connected hdmi, even though you connected dp?
11:10
see there it says dp is disconnected
11:10
<enoch911>
from monitor: hdmi [cable] hdmi -> adapter[hdmi:dp] > client:DP
11:10
<alkisg>
Well then
11:11
We're forcing on the wrong output?!
11:11
Let's see
11:11
<enoch911>
50 is:
11:11
from monitor:DP --> client:DP
11:12
<alkisg>
ltsp155 says: DP-1 disconnected (normal left inverted right x axis y axis)
11:12
So... :)
11:12
It also says: HDMI-1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 509mm x 286mm
11:12
<enoch911>
it sure is
11:12
does*
11:13
but there's no HDMI in 50
11:13
at all
11:13
<alkisg>
Why is there an HDMI in ltsp155?
11:13
<enoch911>
beacuse you told me to set up such a station to test :
11:13
:)
11:13
<alkisg>
Aren't the clients the same?
11:13
Are you testing with a different kind of pc now?
11:13
<enoch911>
yes, clients, but not monitors
11:14
<alkisg>
Can you take a picture of the back site (ports) of ltsp155?
11:14
<enoch911>
clients only have DP, monitor vary
11:14
<alkisg>
OK, so ltsp155 doesn't have HDMI connected
11:14
As it doesn't have HDMI port
11:14
<enoch911>
155: from monitor: hdmi [cable] hdmi -> adapter[hdmi:dp] > client:DP
11:14
<alkisg>
It has DP connected, when THEN goes to and adapter, hdmi, monitor
11:14
But xrandr says that DP is disconnected
11:15
<enoch911>
ok, strange bug
11:15
50: from monitor:DP --> client:DP
11:15
155: from monitor: hdmi [cable] hdmi -> adapter[hdmi:dp] > client:DP
11:15
I can take a photo of it
11:15
sec
11:15
<alkisg>
No need
11:15
As long as ltsp155 has no hdmi port
11:15
Then we have all the necessary information
11:18
<enoch911>
no client have HDMI, only DP
11:18
I sent you this before: https://cloud.danielhansson.nu/s/tMnrgp5zAZbGSga
11:18
https://cloud.danielhansson.nu/s/HXMRXomrXeL6yxd
11:18
155
11:19
50 https://cloud.danielhansson.nu/s/37ffjYfT6LobZBx
11:19
<alkisg>
enoch911: eh, it does say hdmi and dvi there
11:19
<enoch911>
128 is DP only
11:20kjackal has joined IRC (kjackal!~quassel@64.141.80.139)
11:21
<enoch911>
I don't know how to explain better: the monitor on 155 is HDMI, DP, VGA etc, the client is DP only
11:21
<alkisg>
OK ok
11:21
Anyways, I think we did enough tries. The best I found was this: https://bugs.freedesktop.org/show_bug.cgi?id=106291#c20
11:21
<enoch911>
I didn't disconnect the DP in the video from the monitor, sorry if that made it unclear
11:21
<alkisg>
May I ask about the "why" it can't work, prior to kernel 4.15 it was possible to use: "initrd=/edid.cpio drm_kms_helper.edid_firmware=DP-1:edid/edid.bin video=DP-1:D"
11:22
That bug report says that they don't support forcing on the dp outputs anymore
11:22
Because the GPU needs to "talk" to the monitor
11:22
But, before 4.15, they allowed it
11:22
<enoch911>
well, then that's the issue
11:22
<alkisg>
So the next try would be to install some older kernel in 18.04, and try to force dp on
11:22
That would be a workaround that might work
11:22
<enoch911>
so running Ubuntu 18.04.1 on 4.10 and forcing would do it?
11:22
<alkisg>
On 4.14, no need to go that back
11:22
<enoch911>
ok
11:23
<alkisg>
The real solution would come by reporting the issue to freedesktop
11:23
So that it would work in the future kernels too
11:23
<enoch911>
but, if we use the soulution on 155 maybe we don't need to force DP
11:23
<alkisg>
Also, it *might* be solved in 19.10, which doesn't support 32bit, which would mean testing with debian or something else that does support it
11:23
If you buy adapters, then yes you might not need it
11:24
Or even just cables
11:24
From DP (client) to HDMI (monitor) cables
11:24
<enoch911>
exactly
11:24
will check if that's fesible
11:24
anyway, thanks for your help again
11:24
<alkisg>
First buy a couple of such cables etc and test
11:24
And if they work, then yeah, balance the $$ for cables vs $$ for support/bug solving/time
11:28
<enoch911>
that won't work, just checked
11:28
95% of our screens are DP, VGA, DVI
11:29
maybe DVI would work
11:29
can sure try
11:29
<alkisg>
Yeah, give it a try
11:29
Also try to buy another DP=>DP cable
11:29
Maybe that will work too
11:36
enoch911: if the cables don't work, install 4.10 or some other kernel, and let's try the force on workaround there
11:36
later; lunch time
11:53Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
11:54
<enoch911>
I'm installing 18.04.1 now and will downgrade to 4.10 kernel
11:55
tried different cables and it didn't work
11:55
as we only have DP monitors I don't have any choise here
11:55
choice*
12:19
alkisg; can I please get your PPA for xfreedesktop and latest x11vnc?
12:24eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:744f:2b1c:b6af:dc88, Quit: Not legit enough.)
12:38enick_952 has left IRC (enick_952!enauttchnc@gateway/shell/matrix.org/x-wfxqbzojbahueppc, Remote host closed the connection)
12:39uumas has left IRC (uumas!uumaslyseo@gateway/shell/matrix.org/x-cuufsuzwicmyqcgt, Read error: Connection reset by peer)
12:39Guest20711 has left IRC (Guest20711!enautmatri@gateway/shell/matrix.org/x-pyrikjwwbfaetcdc, Read error: Connection reset by peer)
12:39alexxtasi[m] has left IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-sqbkpvkyhbgojnap, Write error: Connection reset by peer)
12:39uumas_ has left IRC (uumas_!uumasmatri@gateway/shell/matrix.org/x-vwpozhiohwlfxver, Write error: Connection reset by peer)
12:41
<enoch911>
ok, at least my wiki is working :)
12:41
followed it now straight up, and it went as expected. :)
12:41
<alkisg>
(01:54:51 PM) enoch911: I'm installing 18.04.1 now and will downgrade to 4.10 kernel ==> why, you already had 18.04 there
12:41
The difference between 18.04.3 and .1 is just the kernel
12:41
!greek-schools-ppa
12:41
<ltsp>
greek-schools-ppa: https://launchpad.net/~ts.sch.gr/+archive/ppa/ supports LTS Ubuntu releases with newer LTSP versions, bug fixes etc
12:41
<enoch911>
I like it clean
12:42
<alkisg>
Hope we didn't lose the ltsp.conf notes :)
12:42
<enoch911>
newsflash, it's not booting on 4.15 kernel
12:42
no, that's in another VM
12:43
booting with dual screens that is
12:43
doing dist-upgrade now
12:43
when downgrading kernels
12:43
then try again
12:44
<alkisg>
enoch911: in the mean time, can I just install 4.10 in the normal VM?
12:44
<enoch911>
sure
12:44
will boot it
12:44
sec
12:47
but then we'll have 2 LTSP servers, which will win iPXE?
12:47
<alkisg>
Random
12:47
<enoch911>
ok
12:47
<alkisg>
Unless we define mac addresses in dnsmasq
12:47
<enoch911>
it's online now anyway
12:48
I think it will work
12:48
I have high hopes
12:48
:)
12:53section1 has joined IRC (section1!~section1@178.33.109.106)
12:53
<enoch911>
why 4.4?
12:53
<alkisg>
ltsp image takes time
12:53
let's try two kernels at the same time
12:53
<enoch911>
okok
12:55
<alkisg>
Also, 4.4 is long term support due to ubuntu 16.04
12:56
4.10 wasn't long term support afaik
12:56
<enoch911>
right
12:56
we just need something that works as intended, I honestly dont' care how :)
13:29
btw https://www.kernel.org/
13:29
so if 4.4 works I will try with 4.9
13:36
<alkisg>
enoch911: nah, you're install from mainline ppa, so you care about ubuntu long term supported kernels, which are different than upstream lts kernels
13:36
<enoch911>
ok
13:45
why am I still getting 4.15 kernel even if I ran image, inird, and ipxe?
13:45
do I need to force it somehow?
13:45
I even uninstalled the 4.15 kernels
13:47
tried ltsp kernel now
13:47
let's see
13:47uumas_ has joined IRC (uumas_!uumasmatri@gateway/shell/matrix.org/x-niprktrytcnywbbe)
13:47alexxtasi[m] has joined IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-dtlptpuxiczczvtz)
13:47enaut[m] has joined IRC (enaut[m]!enautmatri@gateway/shell/matrix.org/x-vmnauccszkyozkod)
13:47uumas has joined IRC (uumas!uumaslyseo@gateway/shell/matrix.org/x-lsabzuwrlnzwpcfl)
13:47enaut[m]1 has joined IRC (enaut[m]1!enauttchnc@gateway/shell/matrix.org/x-trnrdjtyfadlbcbo)
13:48enaut[m] is now known as Guest52735
13:57
<enoch911>
OK, I'm stuck again :/
13:57
it seems like the 4.15 kernel are cached
13:58
none of the ltsp commands work to replace it with the current in server 4.4
13:59
<alkisg>
enoch911: vnc
13:59
x11vnc -connect srv1-dide.ioa.sch.gr
14:00
<enoch911>
I'm making a new image now in the background
14:00
fyi
14:01
I'm giving up soon
14:01
reverting to 16.04 which worked and install freerdp2 there instead
14:02
<alkisg>
enoch911: it's 4.4
14:03
You much be booting from another server/vm
14:03
<enoch911>
no
14:03
<alkisg>
or even from local disk...
14:03
<enoch911>
it's the only one starter
14:03
the other one is shut down
14:04
<alkisg>
dir date: 15.02
14:04
<enoch911>
I made an image on 4.15, then overwrote that with a new run
14:04
isn't that how it works?
14:04
<alkisg>
client boot time: 14:50
14:04
so, you updated tftp after the client has booted
14:04
if you reboot it now it should work
14:05
<enoch911>
see for yourself please
14:05
note, did *another* ltsp image / just berore you conected, done like 4 of those since the change to 4.4
14:07
what????
14:07
<alkisg>
see, it's 4.4
14:07
It got scared of me :P
14:07
<enoch911>
that's very odd
14:07
yeah probably
14:07
thanks! :)
14:07
<alkisg>
np
15:03robert45 has joined IRC (robert45!~robert45@r186-54-62-103.dialup.adsl.anteldata.net.uy)
15:05
<robert45>
morning guys, Im experiencing some hard crashes on a ltsp thin client from time to time, all crashes follow the exact same pattern - a hard freeze, where input is not accepted (no keyboard, mouse won't move, etc. All resolved by a reboot. Im using ltsp5 with latest ppa updates. Logs shows the following error, not sure if its related or not: https://paste.ubuntu.com/p/GVXX3Y65yZ/ any ideas how to troubleshoot this one?
15:10
<alkisg>
robert45: hi, do you have multiple clients and this happens on just this one?
15:10
<robert45>
alkisg hey, I havent moved this to production yet so its only for testing. Testing with one client only for now
15:11
<alkisg>
Could be a hardware or drivers problem with this specific client
15:15
<quinox>
if it happens to any linux machine of me I usually suspect it ran out of memory
15:18
<robert45>
alkisg I see. All my desktops machines have same desktop model. This isnt happening on a production ltsp5 setup I have, only on the testing one
15:18
quinox hmm, thanks Im going to try increased the ltsp5 server ram, I think its much lower than the production one
15:19
tx guys, will try this first and let you know
15:19
<quinox>
or just keep htop open in a terminal
15:19
<alkisg>
!netconsole
15:19
<ltsp>
netconsole: https://github.com/ltsp/ltsp/wiki/netconsole
15:20
<alkisg>
ltsp.github.io/advanced/netconsole, I think...
15:20
Logs kernel panics
15:21
<quinox>
even better
15:21
<robert45>
got it
15:21kjackal has left IRC (kjackal!~quassel@64.141.80.139, Ping timeout: 265 seconds)
15:51
<alkisg>
!forget netconsole
15:51
<ltsp>
The operation succeeded.
15:51
<alkisg>
!learn netconsole as To log LTSP client kernel messages (and crashes) on the server: https://ltsp.github.io/advanced/netconsole/
15:51
<ltsp>
The operation succeeded.
15:55robert45 has left IRC (robert45!~robert45@r186-54-62-103.dialup.adsl.anteldata.net.uy, Ping timeout: 265 seconds)
16:08enoch911 has left IRC (enoch911!25f71ea4@37-247-30-164.customers.ownit.se, Remote host closed the connection)
16:10kp5678 has joined IRC (kp5678!d510b783@hypernet.the.forthnet.gr)
16:27kp5678 has left IRC (kp5678!d510b783@hypernet.the.forthnet.gr, Remote host closed the connection)
16:33kp5678 has joined IRC (kp5678!d510b783@hypernet.the.forthnet.gr)
16:54georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Read error: Connection reset by peer)
16:55georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
17:15kp5678 has left IRC (kp5678!d510b783@hypernet.the.forthnet.gr)
18:25ltspuser456 has joined IRC (ltspuser456!d510b783@hypernet.the.forthnet.gr)
18:29vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
18:45uumas_ has left IRC (uumas_!uumasmatri@gateway/shell/matrix.org/x-niprktrytcnywbbe)
18:58kjackal has joined IRC (kjackal!~quassel@64.141.80.139)
19:17kjackal has left IRC (kjackal!~quassel@64.141.80.139, Ping timeout: 252 seconds)
19:57statler has left IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de, Remote host closed the connection)
20:03section1 has left IRC (section1!~section1@178.33.109.106, Quit: Leaving)
20:44
<alkisg>
vagrantc: how is it possible that unstable has both the old and the new ltsp binary packages? https://packages.debian.org/search?suite=sid&keywords=ltsp
20:44
I would think that uploading a new version of a package with the same source name, would remove the binaries of the old one...
20:45
Heh. It appears to be confused: https://packages.debian.org/source/sid/ltsp
20:57woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection)
21:26shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi)
21:31Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
21:33shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Ping timeout: 240 seconds)
21:59ltspuser456 has left IRC (ltspuser456!d510b783@hypernet.the.forthnet.gr, Ping timeout: 260 seconds)
22:49
<vagrantc>
alkisg: it doesn't instantaneously decruft
22:50
alkisg: it could in theory be a bug in the ltsp source package that it didn't produce the other packages ...
22:51
highvoltage: i chose to orphan the packages rather than request removal, since all the debian-edu packages still depend on them
22:52
highvoltage: if debian-edu migrates to the new stuff or never responds ... well... then we should move forward with removal
22:52
highvoltage: but i basically dropped an unplanned transition on them, so figured i'd at least give them the chance to pick up the packages...
23:57TheProf has joined IRC (TheProf!~TheProf@207.35.209.231)