IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 7 November 2019 (all times are UTC)
| 00:50 | eddytv has joined IRC (eddytv!~eddy@2601:402:4500:4670:c954:cfa4:b07f:bd36) | |
| 00:51 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 03:05 | eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:c954:cfa4:b07f:bd36, Quit: My computer has gone to sleep. ZZZzzz…) | |
| 03:26 | pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv) | |
| 03:27 | pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Client Quit) | |
| 04:37 | dgroos has joined IRC (dgroos!~dagro001@63.225.132.145) | |
| 04:37 | dgroos has left IRC (dgroos!~dagro001@63.225.132.145, Client Quit) | |
| 05:40 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288) | |
| 06:34 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 06:37 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 06:55 | <alkisg> vagrantc: so, I think we can find everything locally except snponly.efi and memtest.efi. It's still not OK to wget just these two, right?
| |
| 06:55 | I.e. code that would search things locally, and fall back to https if they're not found, or even if the user passes a special switch
| |
| 06:58 | For example, `ltsp ipxe` wouldn't wget anything, and only rely on local things, while `ltsp ipxe --wget-missing-binaries` would prompt the user "downloading over https, verify them yourself..." and download either the missing ones or all of them if --wget-all-binaries is specified
| |
| 06:59 | Or we can just tell him "wget those missing binaries yourself: ..." and spout some wget commands for him
| |
| 07:01 | * alkisg did like the download counter though :P | |
| 07:27 | kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288, Ping timeout: 276 seconds) | |
| 07:30 | <highvoltage> alkisg: memtest.efi doesn't work anyway
| |
| 07:31 | <alkisg> highvoltage: hm? It worked for me... did I upload a broken version?
| |
| 07:31 | OK let me test
| |
| 07:31 | <highvoltage> alkisg: not sure if you uploaded a newer blob since I last tried
| |
| 07:31 | <alkisg> I didn't
| |
| 07:32 | Did you try on a single client?
| |
| 07:32 | E.g. maybe it does have some bugs and hangs on some clients...
| |
| 07:33 | gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.27) | |
| 07:33 | <highvoltage> alkisg: I tried on a bunch of efi clients and they said something like "This version of memtest does not support pxe"
| |
| 07:33 | <alkisg> highvoltage: did you load it with ipxe, or from e.g. grub?
| |
| 07:34 | <vagrantc> alkisg: what do we miss not having snponly.efi ?
| |
| 07:34 | alkisg: i like the "--wget-missing-binaries" route ...
| |
| 07:34 | <alkisg> vagrantc: it won't boot on many PCs
| |
| 07:35 | <vagrantc> alkisg: where does snponly.efi come from?
| |
| 07:35 | <alkisg> I think it's just a build target of ipxe, it should only involve a couple of lines changed in the debian ipxe package
| |
| 07:35 | There's the "BIOS/UEFI driver" and the "IPXE drivers"
| |
| 07:35 | snponly means "use the internal UEFI driver"
| |
| 07:35 | ipxe.efi means "use the IPXE drivers"
| |
| 07:36 | So if e.g. I have a marvel card or whatever, that ipxe doesn't have a driver for, and my uefi driver works fine, it'll need snponly.efi to boot
| |
| 07:36 | <vagrantc> ok, let's get it enabled in the package ... but it does sound useful to have a wget option for distros that don't (yet) ship all the binaries
| |
| 07:36 | <alkisg> Normally, we would never need ipxe.efi; but in some cases the internal UEFI driver is broken, and there ipxe.efi *may* work
| |
| 07:37 | vagrantc: right; so, to sum up on who does what:
| |
| 07:37 | You please do handle getting snponly.efi on debian ipxe,
| |
| 07:37 | and I'll do the code/documentation about preferring local ipxe.efi etc etc, then falling back to wget with some warnings etc,
| |
| 07:38 | but, I won't do the gpg stuff, ok?
| |
| 07:39 | <vagrantc> that mostly sounds good ... just for clarity ... will the wget fallback be enabled by default? or will it just warn which are missing and mention the commandline option?
| |
| 07:39 | <alkisg> vagrantc: I think that it should wget snponly.efi currently, as it won't find it on disk, with the appropriate message,
| |
| 07:40 | ...actually, we can just do that with the --missing option in the documentation
| |
| 07:40 | So "ltsp ipxe" by default doesn't wget, but "following installation instructions" wgets snponly.efi
| |
| 07:41 | <highvoltage> alkisg: I loaded it via ipxe
| |
| 07:41 | <vagrantc> the important part to me is that it's clear when it's downloading unverified binaries and it's possible to opt-out somehow
| |
| 07:42 | <alkisg> highvoltage: I see that too; will fix it tomorrow
| |
| 07:42 | <vagrantc> so ... i'm inclined to supporting *some* verification method, if we don't yet have it more fully integrated
| |
| 07:42 | <alkisg> I probably uploaded something else than what I tested
| |
| 07:42 | <highvoltage> alkisg: cool
| |
| 07:42 | <alkisg> vagrantc: OK, I'll need your help in that part too then (the gpg stuff)
| |
| 07:43 | <vagrantc> alkisg: sure
| |
| 07:43 | <alkisg> Feel free to commit not-very-tested code and I can test/tweak it later
| |
| 07:44 | <vagrantc> alkisg: i'd say go ahead and do what you proposed, and then i'll have a better idea of where to hook in the verification
| |
| 07:44 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288) | |
| 07:45 | <alkisg> OK, it'll take me a while though as I have some other things scheduled first... :/
| |
| 07:45 | <vagrantc> sure
| |
| 07:45 | or i'll just dive in ... though sadly ltsp isn't high on my list still, despite being excited about the new version :)
| |
| 07:45 | <alkisg> :)
| |
| 07:46 | <vagrantc> maybe i have to actually do marketing to get clients who want ltsp :)
| |
| 07:47 | <alkisg> Haha, I do think LTSP needs some up to date marketing
| |
| 07:53 | statler has joined IRC (statler!~Georg@gwrz.lohn24.de) | |
| 07:58 | woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de) | |
| 07:59 | enoch85 has joined IRC (enoch85!25f71ea4@37-247-30-164.customers.ownit.se) | |
| 07:59 | <enoch85> good morning!
| |
| 08:00 | <alkisg> Good morning enoch85
| |
| 08:02 | <enoch85> alkisg, been talking to my boss some more and we have 7 Windows Sessions Hosts (Terminal Servers) which we diveded up to several just to have a backup in case one SH would go down. Bringing LTSP to the table means that if the LTSP server goes down, all connections die (when I've tested at least) which makes the LTSP server a single point of
| |
| 08:02 | failure. To prevent that, would it be possible to make LTSP load "an image" every time the client reboots the client PC, and then run everything on the client PC so that if the LTSP server goes down the clients aren't affected?
| |
| 08:03 | <alkisg> enoch85: sure, you can cache everything to ram when clients boots, both root / and the client home template, as long as RAM suffices
| |
| 08:03 | It'll need some code in LTSP19, it's not integrated yet, but just a bit
| |
| 08:04 | You may also install an nfs server on the windows servers
| |
| 08:04 | <enoch85> hmm, the clients we have are mixed with 1 GB and 2 GB RAM, looking at the when running it holds about 700 MB, so it's a close call
| |
| 08:04 | <alkisg> As you'll be needing that connection anyway
| |
| 08:05 | So both the image and home will be hosted on the windows servers themselves
| |
| 08:05 | <enoch85> so I won't get aroun the fact that the client sessions die as long as I have NFS on the LTSP host?
| |
| 08:05 | <alkisg> Your clients don't have a lot of ram, it's best to rely on NFS being available
| |
| 08:06 | One easy way is to have the clients select an NFS server out of multiple ones on boot. Windows servers may be NFS servers.
| |
| 08:06 | So that is both load balancing and avoiding the single point of failure
| |
| 08:07 | <enoch85> we have several ubuntu servers in our server farm. I'm more a Linux guy than a windows guy actually... so what you're saying is that we could set up several small NFS servers and host /home/guest from there?
| |
| 08:08 | <alkisg> Sure. ProxyDHCP replies can also do load balancing, so:
| |
| 08:08 | Suppose you replicate the ltsp server into 4 servers
| |
| 08:08 | Then the clients will boot from the one that replies first
| |
| 08:09 | <vagrantc> alkisg: it looks ipxe is even building it, so it might just be a one-liner to actually install it in the package...
| |
| 08:09 | <alkisg> (or you can configure where each client will boot etc)
| |
| 08:09 | vagrantc: great!
| |
| 08:09 | vagrantc: I can backport it to the ppa so then we won't need wget at all
| |
| 08:09 | (the ipxe package)
| |
| 08:09 | <vagrantc> right
| |
| 08:10 | <enoch85> alkisg so I replicate the LTSP server itself! but what about when I make a changes on the servers, how will that replicate to the other servers?
| |
| 08:10 | <alkisg> enoch85: one way is to use cephfs
| |
| 08:10 | <enoch85> each server would have it's own image right?
| |
| 08:10 | <alkisg> OK when that part is ready, I can give you access
| |
| 08:10 | <enoch85> hmm
| |
| 08:10 | <alkisg> Sorry
| |
| 08:10 | <vagrantc> alkisg: will try to build it to see exactly what's needed to fix the packaging when the time comes
| |
| 08:10 | <alkisg> I meant this: https://github.com/ltsp/ltsp/issues/37
| |
| 08:10 | <vagrantc> alkisg: but then i'll have to boot an x86 machine :)
| |
| 08:11 | <alkisg> Haha :D
| |
| 08:11 | God forbid!
| |
| 08:11 | <enoch85> lol --^
| |
| 08:11 | CephFS seems interessting,
| |
| 08:11 | <alkisg> enoch85: so, you may set up 2 or 3 machines as ltsp servers, and have common /srv and common /home with cephfs for them
| |
| 08:11 | And boot ltsp clients with cephfs,
| |
| 08:12 | so that then if you power off one of the servers, the clients will continue working fine with the other 2 servers
| |
| 08:12 | <enoch85> very interesting!
| |
| 08:12 | <alkisg> No downtime, and automatic balancing
| |
| 08:12 | There's a bit of complexity involved, and a bit of extra syncing, but the end result is no downtime
| |
| 08:12 | <vagrantc> yeah, cephfs is cool stuff
| |
| 08:13 | <alkisg> enoch85: remind me, your clients also need to run a linux session with e.g. a local browser, right?
| |
| 08:13 | <enoch85> alkisg how long would it take for you to put something like that togheter based on the fact that I already replicated the servers?
| |
| 08:13 | it only needs RDP, nothing else
| |
| 08:13 | it/they
| |
| 08:13 | <alkisg> Then that's the wrong path
| |
| 08:14 | I thought you were trying guest accounts; RDP only is a different thing
| |
| 08:14 | For RDP only, you don't even need /home
| |
| 08:14 | I would suggest then that you have a minimal chroot/vm, with just rdp, so that it's around 500 MB compressed,
| |
| 08:14 | <enoch85> the reason for the NFS stuff is that we would like to update the desktop icons from one account (guest)
| |
| 08:15 | 1. Client boots the PC
| |
| 08:15 | <alkisg> so that it's all cached in RAM, and then it just connects to one of the windows servers via load balancing or so
| |
| 08:15 | <enoch85> 2. Client sees 7 servers to choose from
| |
| 08:15 | 3. Double clicks his/her server
| |
| 08:15 | 4. COnnects
| |
| 08:15 | that's the whole idea
| |
| 08:15 | is there anything smarter?
| |
| 08:15 | <alkisg> Yeah no need for guest accounts then
| |
| 08:16 | <enoch85> hmm ok
| |
| 08:16 | <alkisg> You can have a minimal chroot, loaded e.g. over NFS, then cached in RAM, then it'll show a login screen with those 7 servers
| |
| 08:17 | <enoch85> how would we replace the servers in question? Just change the chroot and update the image?
| |
| 08:17 | would there still be a need for multiple ltsp servers and load balancing etc?
| |
| 08:18 | would the connection die if the server reboots with that soulution?
| |
| 08:20 | <alkisg> No, it wouldn't die
| |
| 08:20 | After the client boots, the ltsp server may be powered off
| |
| 08:20 | <enoch85> ok, then that sounds exactly what we would need
| |
| 08:21 | <vagrantc> though NFS will hang indefinnitely waiting for the server to come back if it needs something that isn't yet cached...
| |
| 08:22 | <enoch85> the only thing we will display for the end user is the 7 servers, and those won't change that frequeantly, maybe one new every 6 months or so
| |
| 08:22 | so alkisg how long time would you need to setup that soulution?
| |
| 08:22 | * vagrantc waves | |
| 08:22 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 08:22 | <alkisg> bye va
| |
| 08:22 | grantc
| |
| 08:23 | kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288, Remote host closed the connection) | |
| 08:23 | <enoch85> because then we could be running everything of one LTSP server since the client connection won't die upon server reboot or shutdown
| |
| 08:23 | <alkisg> enoch85: I guess 2-3 days, depending on how much I need to do vs you do after my instructions etc
| |
| 08:23 | Yes, it'll all be cached in RAM
| |
| 08:24 | <enoch85> I could do most of it if you instruct me I guess (hope)
| |
| 08:24 | <alkisg> E.g. if you want me to write that python program with the 7 servers, or if you'll do it
| |
| 08:24 | Do you know python/gtk or something?
| |
| 08:24 | <enoch85> aah, you woudl have to do that stuff, I didn't learn pything yet
| |
| 08:24 | pythion
| |
| 08:24 | python**
| |
| 08:25 | <alkisg> Well, you do want a menu with 7 servers, right?
| |
| 08:25 | <enoch85> I know bash somewhat https://github.com/nextcloud/vm
| |
| 08:25 | <alkisg> I don't mean just the "cache to network" bit, I mean the whole solution
| |
| 08:25 | Up to the point where you boss says "excellent, all work fine"
| |
| 08:25 | <enoch85> yes exactly
| |
| 08:25 | :)
| |
| 08:25 | <alkisg> So, around 15-20 hours for all these
| |
| 08:26 | <enoch85> ok, so 600€ ~
| |
| 08:26 | ?
| |
| 08:26 | would it be easy for us to add and remove servers once it's deployed and done?
| |
| 08:27 | <alkisg> Of course
| |
| 08:28 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:6436:27c4:c18f:3cd) | |
| 08:28 | <alkisg> Yes, I can promise "no more than 600€ even if it takes longer", and if it takes less hours, it'll be less; we can also talk over PMs for the details
| |
| 08:29 | <enoch85> yeah ok, I will talk to him and ask. we're on a tight budget here - even more tight as he will say "the current (old) soloution works" but it leaves ut with only being able to run Windows Server 2012
| |
| 08:29 | hehe
| |
| 08:30 | but why would python be needed? to programatically changed the servers page?
| |
| 08:30 | change*
| |
| 08:30 | (typing to fast)
| |
| 08:31 | <alkisg> You need a login screen; what will provide it?
| |
| 08:31 | A nice dialog that displays the options to the users
| |
| 08:31 | Or does rdesktop have such a menu?
| |
| 08:32 | <enoch85> I don't know if remmina would work
| |
| 08:32 | <alkisg> That's one of the parts that you could do then
| |
| 08:32 | <enoch85> problem with remmina is that it won't load dual screes
| |
| 08:33 | sec
| |
| 08:33 | <alkisg> Research and see if you can have everything working, including a gui with options, with remmina
| |
| 08:33 | If not, then you'd tell me "program that via python/gtk"
| |
| 08:33 | <enoch85> I stumbled across a script yesterday
| |
| 08:33 | will try to find it
| |
| 08:33 | <alkisg> OK
| |
| 08:33 | <enoch85> https://github.com/wyllianbs/xfreerdp-gui
| |
| 08:34 | <alkisg> Anyway, I think we need to take the rest private; I'll do some other paid work in the meantime, you talk to your boss, and if he OK's it we continue with PMs
| |
| 08:34 | <enoch85> maybe one could edit that to show the servers we would want
| |
| 08:34 | alkisg sounds good to me
| |
| 08:34 | <alkisg> Great
| |
| 08:34 | <enoch85> one last question
| |
| 08:35 | during my live tests from yesterday and today, the feedback is that it's very laggy, moving windows around is next to imnpossible e.g.
| |
| 08:35 | <alkisg> Also check if you want "each pc to connect to specific windows servers", or "each user to connect to specific server", or "no, selectable"
| |
| 08:35 | You can test that with a normal installation that doesn't involve LTSP at all
| |
| 08:35 | <enoch85> would this new soulution make it faster as everyting would be in RAM=
| |
| 08:35 | ?
| |
| 08:35 | <alkisg> No
| |
| 08:36 | <enoch85> ok
| |
| 08:36 | <alkisg> xfreerdp is faster than rdesktop afaik,
| |
| 08:36 | but RAM is about disk access, not about remote screen speed
| |
| 08:36 | <enoch85> yeah ok
| |
| 08:36 | anyway, ttyl
| |
| 08:37 | <alkisg> Your clients have intel GPUs if I recall correctly, right? So you just need to play with the correct programs/settings (xfreerdp, rdesktop etc) to make things as fast as you gen from there
| |
| 08:37 | *can
| |
| 08:37 | E.g. lowering bit depth to 16 might help
| |
| 08:38 | <enoch85> yeah, been thinking about that, amongst other things
| |
| 08:38 | update rdesktop to latest as well
| |
| 08:38 | 1.9.0 was just released
| |
| 09:02 | Da-Geek has joined IRC (Da-Geek!~Da-Geek@5.154.189.38) | |
| 09:49 | GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 240 seconds) | |
| 10:19 | kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:6436:27c4:c18f:3cd, Remote host closed the connection) | |
| 10:23 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:6436:27c4:c18f:3cd) | |
| 10:52 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 10:52 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 10:55 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Client Quit) | |
| 10:57 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 11:26 | os_a has joined IRC (os_a!~Thunderbi@195.112.116.22) | |
| 11:39 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 11:39 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 11:40 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 11:45 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 11:45 | alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg) | |
| 12:01 | eddytv has joined IRC (eddytv!~eddy@2620:11e:1000:6:45f7:694d:eb04:3235) | |
| 12:05 | section1 has joined IRC (section1!~section1@178.33.109.106) | |
| 12:12 | Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49) | |
| 12:12 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:14 | GodFather has joined IRC (GodFather!~rcc@c-69-136-132-171.hsd1.mi.comcast.net) | |
| 12:22 | GodFather has left IRC (GodFather!~rcc@c-69-136-132-171.hsd1.mi.comcast.net, Ping timeout: 245 seconds) | |
| 12:32 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Remote host closed the connection) | |
| 12:35 | GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net) | |
| 12:36 | Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49) | |
| 12:36 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:44 | Da-Geek has left IRC (Da-Geek!~Da-Geek@5.154.189.38, Remote host closed the connection) | |
| 12:45 | Da-Geek has joined IRC (Da-Geek!~Da-Geek@5.154.189.38) | |
| 12:55 | Da-Geek has left IRC (Da-Geek!~Da-Geek@5.154.189.38, Quit: Leaving) | |
| 12:56 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Remote host closed the connection) | |
| 13:06 | Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49) | |
| 13:06 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 14:51 | alkisg1 has left IRC (alkisg1!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 14:51 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 14:55 | os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Read error: Connection reset by peer) | |
| 14:56 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 14:58 | woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 15:01 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 16:22 | douglas_br has joined IRC (douglas_br!bb5f6554@187.95.101.84) | |
| 16:24 | woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de) | |
| 16:35 | GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 240 seconds) | |
| 16:57 | statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection) | |
| 17:49 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 17:59 | <vagrantc> alkisg: i'm pretty sure rpi3b+ supports pxe booting without an SD card and without any special loading
| |
| 17:59 | alkisg: it can even load the boot firmware from the network
| |
| 18:00 | it's been a while since i've tested
| |
| 18:00 | <alkisg> vagrantc: rpi4 shipped with broken network booting
| |
| 18:00 | I managed to netboot rpi3, but with many issues
| |
| 18:00 | ...same with rpi2 with bootcode.bin on the sd card
| |
| 18:01 | <vagrantc> yeah, rpi2 with bootcode.bin on the SD card
| |
| 18:01 | and boot firmware
| |
| 18:01 | (maybe)
| |
| 18:01 | <alkisg> They're supposed to fix rpi4 firmware with the next release due in a few weeks
| |
| 18:01 | <vagrantc> fwiw, i can test both rpi3b+ and rpi2b
| |
| 18:01 | <alkisg> I have 3 rpi2, 1 rpi3, 1 rpi4
| |
| 18:02 | But I do not care enough to prepare ltsp for rpis without help of someone that uses them
| |
| 18:02 | I even advice schools here to avoid them,
| |
| 18:02 | <vagrantc> so rpi4 will need an sd card when it's fixed? like rpi2?
| |
| 18:02 | yeah, i hear you
| |
| 18:02 | <alkisg> and, when some school buys rpis and then realizes the folly, I send pentium 4's to the school to replace the rpis
| |
| 18:02 | No, rpi4 has flashable eeprom
| |
| 18:02 | <vagrantc> ah
| |
| 18:03 | <alkisg> What about other arm devices?
| |
| 18:03 | I think uboot had support for pxelinux.cfg style configs?
| |
| 18:08 | It'll be very nice if we don't have to support local kernels/initrds and just have bootcode.bin in the sd card
| |
| 18:08 | It'll save us the trouble of getting ltsp.conf via other means than ltsp.img
| |
| 18:11 | <vagrantc> many recent systems support pxelinux.cfg style configs, yes.
| |
| 18:11 | recent systems on u-boot, that is, yes.
| |
| 18:12 | i'm not sure if they support multiple initrd images or not
| |
| 18:12 | now that accelerated graphics for a number of ARM systems is upstream, in really recent versions of kernel + mesa + other random stuff you might actually see reasonable performance for an LTSP client
| |
| 18:13 | at least in theory
| |
| 18:35 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Remote host closed the connection) | |
| 18:39 | douglas_br65 has joined IRC (douglas_br65!bd4cccba@189-76-204-186-pdtst-cf-1.visaonet.com.br) | |
| 18:39 | <douglas_br65> hello all
| |
| 18:40 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 18:43 | <douglas_br65> we put to work ltsp lab nice! but there are two screen out of resolution. yeah i did read the doc about ltsp xorg but i do not know how to start file or first read build xorg,sorry
| |
| 18:44 | <alkisg> douglas_br65: upload the output of `xrandr` from the client
| |
| 18:44 | <douglas_br65> thanks Mr. alkisg for all help
| |
| 18:44 | <alkisg> Normally you just need X_MODES=´"1024x768" "800x600" "640x480"´
| |
| 18:45 | (in ltsp.conf)
| |
| 18:45 | <douglas_br65> put this in ltsp.conf
| |
| 18:45 | ohhh right
| |
| 18:47 | <alkisg> You can also use X_PREFERREDMODE="1024x768", but X_MODES is more compatible, even for older drivers, vesa etc
| |
| 18:48 | <meo> re raspberry as far as I understand 3b is bootable with one time fuse enable, 3b+ is bootable by default
| |
| 18:49 | i have a couple of 3b+ so i can play with ltsp on it
| |
| 18:49 | <douglas_br65> put this in the client line yeah?
| |
| 18:49 | <alkisg> yes
| |
| 18:50 | meo: it has various issues, it's not very stable etc; personally I'll just wait until someone that really needs to use it comes along
| |
| 18:50 | lack of time, thousands of things to do etc
| |
| 18:51 | <meo> well sure
| |
| 18:51 | the use case is attractive enough for commercial purposes
| |
| 18:52 | e.g. call centers at 100 eur/seat for hardware and 0 license costs for software
| |
| 18:53 | <alkisg> rpi was already supported by ltsp for years; we didn't hear about such use cases
| |
| 18:54 | And 2 call centers that I know of, need windows VMs to run their programs :/
| |
| 18:54 | Let's hope they'll find uses for it, sure :)
| |
| 18:54 | <meo> I have a call center that runs on your ltsp
| |
| 18:55 | the profile is narrow
| |
| 18:55 | <alkisg> With no windows? Which software are you using?
| |
| 18:55 | <meo> web-based crm, linphone for sip, flock for internal comms
| |
| 18:56 | if you have live chat software or a desktop client crm, yeah that's out of the window
| |
| 18:56 | but as long as you're web based, it works
| |
| 18:57 | we are in fact considering converting the other, larger call center
| |
| 18:58 | but this is mostly due to the business owner not wanting to pay microsoft to upgrade win 7 to win 10
| |
| 18:59 | the other thing is that rp2 isnt realistically powerful enough for daily desktop usage
| |
| 18:59 | 3 is getting there and 4 would work near perfectly
| |
| 18:59 | <alkisg> One of my clients used linphone but had to change it with five9
| |
| 19:00 | So at that point we had to install windows VMs
| |
| 19:00 | rpi2 is a bit slower than pentium 4's
| |
| 19:00 | rpi4 is like old atoms, almost usable
| |
| 19:01 | but for 50 euros one can buy a refurbished pc that's 10 times faster
| |
| 19:01 | even in small form, low power etc
| |
| 19:01 | In any case it was good to see rpi4 almost usable
| |
| 19:01 | <meo> true, although in variances and not as available everywhere
| |
| 19:01 | <alkisg> With the new graphics drivers in a few years, it'll be ok
| |
| 19:01 | <meo> I did look at refurbished PCs locally
| |
| 19:01 | (Bulgaria)
| |
| 19:01 | <alkisg> !cheap-client
| |
| 19:01 | <ltsp> cheap-client: https://www.gearbest.com/tv-box-c_11262/?attr=2081-1279
| |
| 19:01 | <meo> 100-150 eur range
| |
| 19:02 | <alkisg> There are also tv boxes that are faster than rpis
| |
| 19:02 | with similar prices
| |
| 19:02 | (atom based)
| |
| 19:02 | <vagrantc> alkisg: i was overly optimistic about snponly.efi being built already.
| |
| 19:02 | <alkisg> Ouch :/
| |
| 19:03 | <douglas_br65> alkisg put the 3 option together or only 1024x768
| |
| 19:03 | <vagrantc> alkisg: the driver is included in the all drivers target, though
| |
| 19:03 | <alkisg> douglas_br64, I'll need the output of xrandr to tell you. What kind of screen, TFT, old CRT..?
| |
| 19:04 | <douglas_br65> tft
| |
| 19:04 | <vagrantc> alkisg: where'd you get snponly.efi from?
| |
| 19:04 | and how did they build it?
| |
| 19:05 | <alkisg> vagrantc: from boot.ipxe.org/snponly.efi
| |
| 19:05 | I guess they're building all targets
| |
| 19:05 | But there's also `make snponly.efi` or something
| |
| 19:06 | <vagrantc> make: *** No rule to make target 'snponly.efi'. Stop.
| |
| 19:07 | <alkisg> I don't recall the syntax off-hand
| |
| 19:08 | * vagrantc asks in #ipxe | |
| 19:10 | <douglas_br65> I will come back tomorrow and will study about tonight, thanks alkisg
| |
| 19:10 | <alkisg> np
| |
| 19:12 | douglas_br65 has left IRC (douglas_br65!bd4cccba@189-76-204-186-pdtst-cf-1.visaonet.com.br, Remote host closed the connection) | |
| 19:19 | <vagrantc> alkisg: ok, i have it built!
| |
| 19:19 | <alkisg> Yey!
| |
| 19:20 | <vagrantc> a one-liner
| |
| 19:22 | alkisg: i don't even know how to test that it's useful, but i can upload it for you somewhere
| |
| 19:23 | <alkisg> vagrantc: sure, I'll be able to test tomorrow morning
| |
| 19:23 | Or maybe someone else here can test sooner
| |
| 19:24 | <vagrantc> https://misc.aikidev.net/ipxe-WLqm8Vh/
| |
| 19:24 | <alkisg> (if you have an ltsp19 setup,you'd just need to overwrite /srv/tftp/ltsp/snponly.efi with it, and boot an uefi client)
| |
| 19:25 | <vagrantc> the first part i figured i could do, the second part i'd have to figure out how to do that with a virtual machine or something
| |
| 19:26 | <alkisg> I think it's rather easy in kvm but not in vbox... so I just skipped that and used real uefi clients :D
| |
| 19:26 | <vagrantc> ok, let's fire up my ltsp19 setup...
| |
| 19:29 | <alkisg> downloaded, will test it tomorrow
| |
| 19:31 | <vagrantc> hmmm.. where's my ltsp19 setup :)
| |
| 19:47 | kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:6436:27c4:c18f:3cd, Ping timeout: 246 seconds) | |
| 19:47 | <vagrantc> alkisg: sent the bug and CCed you ... can always mention that you've tested the updated change.
| |
| 20:00 | section1 has left IRC (section1!~section1@178.33.109.106, Quit: Leaving) | |
| 20:00 | douglas_br has left IRC (douglas_br!bb5f6554@187.95.101.84, Remote host closed the connection) | |
| 20:03 | <alkisg> vagrantc: ty, will do tomorrow morning; if you can comment there too it'll be nice: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927783
| |
| 20:03 | It's been 6 months now with no feedback there...
| |
| 20:20 | <vagrantc> alkisg: not much to say, it kind of speaks for itself (other than not using "diff -u")
| |
| 20:20 | alkisg: hopefully some new, simple bugs will nudge a new upload...
| |
| 20:21 | alkisg: i guess i can basically add a "tested-by" :)
| |
| 20:21 | though all this EFI is newish to me
| |
| 20:22 | my most modern laptop uses coreboot, my second most modern uses EFI but only under the hood, but in bios emulation mode with no way to disable
| |
| 20:24 | alkisg: i've got a kvm booted machine with tianocore, but it's not loading snponly.efi ...
| |
| 20:26 | i guess i'll wait for you to test if i can't figure it out
| |
| 20:31 | <alkisg> vagrantc: does ipxe.efi work there?
| |
| 20:33 | <vagrantc> alkisg: it doesn't download it via tftp ...
| |
| 20:34 | <alkisg> Sounds broken
| |
| 20:34 | <vagrantc> in the dnsmasq logs, it loads ltsp.ipxe, vmlinuz, ltsp.img and initrd.img and then boots
| |
| 20:35 | i'll wait for you to get a chance to test, sounds like :)
| |
| 20:35 | <alkisg> Sure, tomorrow morning
| |
| 20:36 | <vagrantc> although it only supports bin-x86_64-efi/snponly.efi ... but i guess i686 didn't tend to support EFI commonly
| |
| 20:37 | <alkisg> x86_32-efi is indeed rare
| |
| 20:51 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 21:03 | eddytv has left IRC (eddytv!~eddy@2620:11e:1000:6:45f7:694d:eb04:3235, Ping timeout: 264 seconds) | |
| 21:08 | eddytv has joined IRC (eddytv!~eddy@2620:11e:1000:220:35e4:d10e:ace1:afb9) | |
| 21:12 | woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 21:20 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:53 | eddytv has joined IRC (eddytv!~eddy@2601:402:4500:4670:7d06:3999:2510:c592) | |
| 22:02 | GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com) | |
| 22:40 | eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:7d06:3999:2510:c592, Quit: My computer has gone to sleep. ZZZzzz…) | |
| 22:50 | eddytv has joined IRC (eddytv!~eddy@2601:402:4500:4670:7d06:3999:2510:c592) | |
| 23:16 | eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:7d06:3999:2510:c592, Quit: My computer has gone to sleep. ZZZzzz…) | |
| 23:22 | eddytv has joined IRC (eddytv!~eddy@2601:402:4500:4670:7d06:3999:2510:c592) | |
| 23:22 | eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:7d06:3999:2510:c592) | |
| 23:42 | <vagrantc> alkisg: i have a fear i'm going to end up ipxe maintainer in debian again...
| |
| 23:44 | well, not again...
| |