IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 12 November 2019 (all times are UTC)
| 00:08 | ltspuser456 has left IRC (ltspuser456!d510b783@hypernet.the.forthnet.gr, Ping timeout: 260 seconds) | |
| 00:27 | kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 265 seconds) | |
| 00:43 | kjackal has joined IRC (kjackal!~quassel@209.121.128.189) | |
| 01:02 | kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 276 seconds) | |
| 02:19 | eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:359e:f3f:9ea7:9540, Quit: My computer has gone to sleep. ZZZzzz…) | |
| 02:20 | eddytv has joined IRC (eddytv!~eddy@2601:402:4500:4670:744f:2b1c:b6af:dc88) | |
| 03:12 | kjackal has joined IRC (kjackal!~quassel@64.141.80.139) | |
| 04:45 | kjackal 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:16 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 05:27 | eu^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:41 | eu^ip1f12fd11dyn has left IRC (eu^ip1f12fd11dyn!1f12fd11@31.18.253.17, Remote host closed the connection) | |
| 06:01 | statler has joined IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de) | |
| 06:58 | woernie 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:37 | gdi2k 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:46 | gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.27, Read error: Connection reset by peer) | |
| 08:47 | gdi2k 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:03 | enoch88483838 has left IRC (enoch88483838!25f71ea4@37-247-30-164.customers.ownit.se, Ping timeout: 260 seconds) | |
| 09:16 | enoch911 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:20 | kjackal 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:53 | Faith 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:24 | eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:744f:2b1c:b6af:dc88, Quit: Not legit enough.) | |
| 12:38 | enick_952 has left IRC (enick_952!enauttchnc@gateway/shell/matrix.org/x-wfxqbzojbahueppc, Remote host closed the connection) | |
| 12:39 | uumas has left IRC (uumas!uumaslyseo@gateway/shell/matrix.org/x-cuufsuzwicmyqcgt, Read error: Connection reset by peer) | |
| 12:39 | Guest20711 has left IRC (Guest20711!enautmatri@gateway/shell/matrix.org/x-pyrikjwwbfaetcdc, Read error: Connection reset by peer) | |
| 12:39 | alexxtasi[m] has left IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-sqbkpvkyhbgojnap, Write error: Connection reset by peer) | |
| 12:39 | uumas_ 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:53 | section1 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:47 | uumas_ has joined IRC (uumas_!uumasmatri@gateway/shell/matrix.org/x-niprktrytcnywbbe) | |
| 13:47 | alexxtasi[m] has joined IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-dtlptpuxiczczvtz) | |
| 13:47 | enaut[m] has joined IRC (enaut[m]!enautmatri@gateway/shell/matrix.org/x-vmnauccszkyozkod) | |
| 13:47 | uumas has joined IRC (uumas!uumaslyseo@gateway/shell/matrix.org/x-lsabzuwrlnzwpcfl) | |
| 13:47 | enaut[m]1 has joined IRC (enaut[m]1!enauttchnc@gateway/shell/matrix.org/x-trnrdjtyfadlbcbo) | |
| 13:48 | enaut[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:03 | robert45 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:21 | kjackal 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:55 | robert45 has left IRC (robert45!~robert45@r186-54-62-103.dialup.adsl.anteldata.net.uy, Ping timeout: 265 seconds) | |
| 16:08 | enoch911 has left IRC (enoch911!25f71ea4@37-247-30-164.customers.ownit.se, Remote host closed the connection) | |
| 16:10 | kp5678 has joined IRC (kp5678!d510b783@hypernet.the.forthnet.gr) | |
| 16:27 | kp5678 has left IRC (kp5678!d510b783@hypernet.the.forthnet.gr, Remote host closed the connection) | |
| 16:33 | kp5678 has joined IRC (kp5678!d510b783@hypernet.the.forthnet.gr) | |
| 16:54 | georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Read error: Connection reset by peer) | |
| 16:55 | georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213) | |
| 17:15 | kp5678 has left IRC (kp5678!d510b783@hypernet.the.forthnet.gr) | |
| 18:25 | ltspuser456 has joined IRC (ltspuser456!d510b783@hypernet.the.forthnet.gr) | |
| 18:29 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 18:45 | uumas_ has left IRC (uumas_!uumasmatri@gateway/shell/matrix.org/x-niprktrytcnywbbe) | |
| 18:58 | kjackal has joined IRC (kjackal!~quassel@64.141.80.139) | |
| 19:17 | kjackal has left IRC (kjackal!~quassel@64.141.80.139, Ping timeout: 252 seconds) | |
| 19:57 | statler has left IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 20:03 | section1 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:57 | woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 21:26 | shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi) | |
| 21:31 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 21:33 | shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Ping timeout: 240 seconds) | |
| 21:59 | ltspuser456 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:57 | TheProf has joined IRC (TheProf!~TheProf@207.35.209.231) | |