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


Channel log from 19 March 2020   (all times are UTC)

00:00
<markit>
don't know hat algorithm alkis is using, wondering if could be used a better compression algorithm slow in the compression phase but very fast in decompression
00:00
<map7>
yes that could be it.
00:00
I'm going to reboot my client and watch the clients CPU as I start libreoffice
00:02
<markit>
Compressors available: gzip (default), lzo, xz.
00:02
I've tried and no core was saturated, but try you too
00:06
I could try to compress with lzo and see what happens
00:08
<map7>
no core was saturdated for me either
00:10
<markit>
ltsp image -m "-comp lzo" /
00:11
seems much slower to create...
00:15
<map7>
I'm testing lzo also
00:17
28seconds blank screen
00:17
no real difference
00:21
just testing xz now for completeness
00:23
<markit>
I'm still at 69% of image creation :(
00:24
<map7>
45seconds with xz
00:25
I've got 32threads for compression on the server that's why it's compressing fast
00:28
<markit>
me 4 inside a vm :)
00:28
LoBo loads still in 15"
00:31
with iftop -ni bond0 I see that during libo load, the speed of the interface is between 30 and 80Mb/s, so very slow
00:32
that's why for a 80MB file it takes 10 seconds, I suppose
00:32
<map7>
is that the NFS link or IMG uncompression speed affecting that?
00:33
Changing the compression between gzip, lzo and xz seems to change the timings
00:33
so maybe there is something to the compression
00:35
<markit>
map7: what do you mean? Seams that nfs is not processing fast as it should
00:36
<map7>
I mean what is being accessed over the NFS share? Is it just a straight copy or is it trying to access the image in which it might not be the NFS share
00:37
<markit>
the server "exports" the image with nfs
00:38
the client does not seem to "mount" in a normal way like for homes, since I think has to be considered a block device like an hard disk
00:38
<map7>
ok
00:38
<markit>
so probably is some /dev/loop0 that you see with df -h in the client
00:39
like /dev/loop0 4,3G 4,3G 0 100% /run/initramfs/ltsp/0/looproot
00:41
<map7>
ok, so it uses squashfs could squashfs itself be slowing this down?
00:43
<markit>
from mount on the client: /run/initramfs/ltsp on / type overlay (rw,relatime,lowerdir=/run/initramfs/ltsp/0/looproot,upperdir=/run/initramfs/ltsp/0/up,workdir=/run/initramfs/ltsp/0/work)
00:44
I would love just to change "relatime" to "noatime" for better performances but dubt is the real issue here
00:45
I've the feeling that everything is ok (no error, timeouts, retransmissions, slow disk I/O) but never the less things don't go as fast as they could
00:45
<map7>
I'm using two NVMe drives with 5GB/s read/write (Corsair MP600) there shouldn't be an IO problem here
00:46
I'm going to try zstd for compression
00:46
<markit>
map7: I'm GMT+1 timezone, 1.45 am here
00:46
<map7>
markit: Thanks for your help
00:46
looks like we are on the same path.
00:46
<markit>
map7: I wolud love to improve speed myself
00:46
<map7>
It's 11:46am here
00:47
I'll let you know if I find anything
00:47
<markit>
but I think that without alkisg we can't find any solution, or maybe he did a lot of test and there is NO solution
00:47
<map7>
yeah when he comes online I'll share what we have tested today
00:48
<markit>
I'm depressed by my lack of troubleshooting abilities :(
00:48
I've no deep knowledge of what is going on, so is just a "try and guess" aproach
00:48
<map7>
I feel your pain
00:55
markit: When I do my dd to RAM the blank screen goes down to 5seconds
00:55
PRE_INITRD_BOTTOM_IMAGE_TO_RAM="dd if=/root/images/x86_64.img of=/dev/null"
00:55
00:57
with zstd compressed image
00:57
Libreoffice is down to 4s cold and 1.5s warm
00:57
not bad
01:02
<markit>
map7: incredible! Is zstd is supported by mksquashfs?
01:03
man says "Compressors available: gzip (default), lzo, xz."
01:03
maybe is a PRE_INITRD_BOTTOM_IMAGE_TO_RAM effect instead?
01:04* markit trying zsdt, seems supported
01:05
<vagrantc>
the manpage sometimes lags ... look at "mksquashfs --help" to see what compressions are supported, but you'll also need kernel support as well
01:15
<markit>
vagrantc: thanks
01:18
map7: here with zstd libo loads in 11" instead of 15"
01:21
mmm found that at startup client is contacting some Amazon IP :(
01:21
maybe checking for updates, but everything should have been disabled sigh
01:25
<map7>
yes it supports zstd on my machine
01:27
<markit>
map7: your performance is almost due only by PRE_INITRD_BOTTOM_IMAGE_TO_RAM
01:27
you are doing a sort of "pre-warm-boot"
01:28
but I'm surprised that boot time doesn't increase dramatically since you are tranferring the whole image, some GB
01:28
<map7>
overall boot time does increase
01:28
but I'm only timing the 'blank' screen
01:29
I'm not so worried adding time to the boot as we don't really reboot fat-clients here
01:29
it's more the time to start applications I'm worried about
01:29
ultimately I would like both the boot and apps to load fast
01:29
<markit>
and you are comparing new ltsp with old ltsp5, still fat clients?
01:30
<map7>
our old ltsp5 system is currently using thin-clients
01:30
and it's on debian 8
01:30
<markit>
with ltsp5 I was faster in boot time, but just because i.e. 16.04 kernel was 50MB while now is around 100MB in size
01:31
<map7>
you could manually compile the kernel and get it back down to that size
01:31
<markit>
oh, I see... nothing can be faster than thin clients
01:31
map7: I don't care do it at every upgrade, fat was never fast
01:31
but I'm wondering if it could be much faster
01:32
I don't see bandwidth saturation, cpu saturation, disk I/O saturation BUT is slow... how is that?
01:33
if you have network transfer that is 10x slower than what should be, of course less data = fater boot/load, but the main problem is "why 10x slower?"
01:33
<map7>
did you try zstd compression with the PRE_INITRD_BOTTOM_IMAGE_TO_RAM line?
01:33
<markit>
I've 3.8GB image and 2GB client :)
01:34
and is pointless, since of course "local access" (to ram) is fast
01:34
I want to discover and improve the .img access by the clients
01:35
<map7>
yeah just thinking we have two problems here, the decompression of the image on the client and the NFS transfer over the squashfs loop mount thing
01:39
zstd image over NFS the blank screen went for 25secs
01:39
zstd in local RAM the blank screen went for 5secs
01:39
only difference was I copied the img into RAM
01:46
<markit>
with wireshark I've a lot of warnings regarding nfs "there is some bitmap data left undissected", but don't understand if is a wireshark problem while capturing
01:46
in any case there are a lot of calls as GETATTR or LOOKUP
01:47
<map7>
right I've only got a basic understanding of wireshark
01:47
I put an '&' on the end of my 'dd' and it didn't hold up the boot and it's still fast
01:47
<markit>
seems that even if the "raw data" transfer is not high, libo does tons of file system requests
01:48
and nfs is slow for that... that remainds me an old, unresolved problem about NFS and Kde with regards to /home
01:48
<map7>
could we use a samba mount instead?
01:50
<markit>
I've no idea
01:53
<map7>
Are you using NFSv4?
01:53
does NFSv4 overcome this limitation?
01:53
<markit>
mount says so, but wireshark says V3
01:54
<map7>
cat /proc/fs/nfsd/versions
01:54
<markit>
in any case, libo load was a matter of 46.000 packets exchanged
01:54
<map7>
It shows me that version 3 is enabled, but you can force v4
01:54
<markit>
-2 +3 +4 +4.1 +4.2
01:54
<map7>
same
01:54
does it choose the lowest when connecting?
01:55
maybe disabling 3,4 & 4.1 will force it to use the latest protocol
01:55
which might be worth testing
01:55
https://wiki.debian.org/NFSServerSetup
01:55
<markit>
client "mount" shows vers=4.2 for homes, dont' know how the access is done for the .img
02:00
in general the performance of NFS versions 3, 4 and 4.1 are fairly similar, at least in these tests
02:00
(googling about nfs differences of performance)
02:06
<map7>
hmmm, I disabled nfsv3 and now it doesn't boot
02:09
<markit>
restarted the nfs server?
02:09
<map7>
yes i did
02:09
i've just set it back to v3 and restarted nfs server and it boots again
02:10
so maybe it's forcing a v3 mount for the image
02:10
<markit>
also if you change exports, AFAIR you have to issue this command exportfs -a don't know if you change other parameters
02:10
maybe, I've the feeling that without alkisg we are just wasting time
02:15gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.19, Ping timeout: 264 seconds)
02:17vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 246 seconds)
02:18vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
02:29gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.18)
02:31
<markit>
3.30 am here, sleep time :) bye map7, let me know if you find anything useful
02:31markit has left IRC (markit!~marco@mail.ammdomus.it, )
04:11gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.18, Ping timeout: 250 seconds)
04:18
<alkisg>
map7: install an OS locally on a client to be able to compare local OS vs LTSP
04:19
Comparing "launching on a quad core client for the first time" with "launching on a 32 core server while home is already cached" isn't really meaningful
04:20
LTSP should be similar to a local installation on a rotational disk
04:22
And of course thins may load apps a few times faster when the server is faster, but the screen updates are thousand of times slower than fats
04:22
!thin-client-deprecation
04:22
<ltspbot>
thin-client-deprecation: The new LTSP doesn't support thin clients (remote Xorg), but it does support low-spec netbooted clients with remote desktop (xfreerdp, x2go etc). Read more in https://github.com/ltsp/community/issues/32
04:23
<alkisg>
4 gbps per client isn't really feasible at this point; thin clients will become a good option again when we'll have server hardware that will be able to compress one vp9 stream per client real time
04:24
...possibly in 10 years or so :)
04:24
<map7>
alkisg: Yeah. I managed to get the boot blank screen down from 33seconds to 5 seconds by using the 'dd' command + zstd compression
04:24
<alkisg>
map7: is that boot blank screen, or login blank screen?
04:25
<map7>
just before the login screen appears
04:25
<alkisg>
When you say login, I assume you mean lightdm, right?
04:25
<map7>
and instead of 15 seconds to start libreoffice it's now 4seconds
04:25
<alkisg>
At that point, you're supposed to be seeing systemd console messages
04:25
<map7>
lightdm yes
04:25
<alkisg>
Services starting etc, not black
04:26
<map7>
I see the services start, then a blank screen, then lightdm
04:26
<alkisg>
Which desktop environment are you using?
04:26
Maybe your client is trying to use wayland and fails
04:26
And then falls back to xorg
04:26
<map7>
xfce4
04:26
<alkisg>
Do you have gdm3 installed? Or just lightdm?
04:27
<map7>
just lightdm
04:28
<alkisg>
And that's on buster?
04:28
<map7>
no that's on bullseye "testing"
04:28
<alkisg>
Maybe they switched lightdm to wayland too there
04:29
<map7>
I'm about to test buster with the PPA ltsp 20.3 and build a chroot image
04:29
<alkisg>
I think you should test local OS
04:29
This will have useful results
04:29
It's a different thing to "try to optimize debian" than "trying to optimize ltsp"
04:29
<map7>
with debian 11 bullseye?
04:30
<alkisg>
With the same OS that you're trying with LTSP, so yeah
04:30
To compare the same version, not different versions
04:30
If you see that local OS is also slow, then you can have the goal of "optimizing debian", which is unrelated to ltsp
04:30
<map7>
on an SSD or rotational disk?
04:30
<alkisg>
The best test would be rotational
04:31
SSD would also be useful too, but LTSP is more close to the rotational speed, which is still a valid installation option, debianites would care to optimize it
04:31
E.g. Ubuntu 12.04 booted in 12 secs, while Ubuntu 20.04 boots in 50 secs, in local OS
04:31
So this reflects in LTSP too
04:31
<map7>
ok fair enough
04:32
is that recorded from grub menu to login?
04:32
<alkisg>
Yes
04:34
zstd should indeed be specified as the default compression, wherever it's supported, but it's only available in the latest OSes like 20.04 and bullseye
04:34
<map7>
is there any downside to doing the 'dd to ram' trick?
04:34
<alkisg>
Fortnately we can set that in ltsp.conf
04:34
Apart from transferring a lot of GB while the client boots, no
04:35
33 seconds blank screen sounds like a real problem though, I have a 2 seconds blank screen here before lightdm shows, without using caching
04:36
A local OS installation will prove if that delay is a debian issue or a networking/ltsp issue
04:36
<map7>
yes, 'markit' was also having the same problem
04:36
<alkisg>
Nah
04:36
I saw marking boot screen, there were no 33 sec delays
04:37
<map7>
ok, maybe it was just the delay on starting libreoffice which was the same
04:37
<alkisg>
Markit was also trying to optimize, and with my help he got it from 1.40 down to 40 or something, but there were no 33 sec delays involved
04:38
LO needs around 15 secs for first launch here, around the same as local installations
04:38
The second launch is a lot faster, like 2 secs, as it's cached
04:39
(including caching /home*
04:39
echo 3 > /proc/sys/vm/drop_caches both on the server and client can help in some tests
04:39* alkisg waves, later... :)
04:40
<map7>
cool thanks
05:27gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.19)
05:41vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
06:11gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.19, Ping timeout: 250 seconds)
06:16gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.18)
06:17
<alkisg>
Back
06:39woernie has joined IRC (woernie!~werner@pD9E8BE9E.dip0.t-ipconnect.de)
07:08gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.18, Ping timeout: 246 seconds)
07:36gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.19)
08:06
<Klimm>
https://egw.lohn24.de/intern/?page_name=NachrichtenLG&category_id=99&item=1342769
10:23statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
10:31gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.19, Remote host closed the connection)
10:42shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer)
10:42shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi)
10:52markit has joined IRC (markit!~marco@mail.ammdomus.it)
10:54
<markit>
hi map7 :)
10:57Teridon has joined IRC (Teridon!~Teridon@dragon.teridon.com)
11:02
<markit>
hi alkisg, yesterday me and map7 have tried to understand the ltsp bottlenecks, but we have a lot of dubs and found no solution :)
11:02
<alkisg>
markit: see irclogs, I already commented a bit
11:02
irclogs.ltsp.org
11:02
<markit>
thanks
11:11
alkisg: libo starts in 5 seconds in my virtual server (on ssd), but 15" in the client
11:11
but what surprises me is that there seem not to be any "saturation" during the process
11:11
i.e. if I reboot client and re-load libo, server has cached it so no disk I/O, CPU on server and client side don't reach 100% (none of the 4 cores)
11:11
and seems that bandwidth (iftop) peackes at 70Mb/s, while connection is at 1Gb
11:11
seems like nfs is really "lazy" in sending the image
11:11markit has left IRC (markit!~marco@mail.ammdomus.it, Remote host closed the connection)
11:11markit_2 has joined IRC (markit_2!~marco@mail.ammdomus.it)
11:11markit_2 is now known as markit
11:11
<alkisg>
markit: it's request/receive/process loops
11:12
If it's cached locally, e.g. on the second run, then it's faster
11:12
<markit>
sorry, disconnected... don't know what was sent in this channel
11:12
<alkisg>
Since it involves both net AND cpu, and they don't run in parallel, then none of them is maxed out
11:12
It's normal, it also happens with ssd and rotational
11:13
In your server sdd, it's already cached as well, so you're using ram, not disk
11:13
And of course ssd is faster than gigabit lan, while rotational is about the same
11:13
So to compare apples with apples, and not oranges, try to compare libreoffice speed in local installation with rotational disk with ltsp
11:14
That's what we expect to have the same speed. If it doesn't, then that needs solving
11:14
But if LO needs 15 locally on rotational disk (which it does here), then there's not much to optimize
11:14
To reach SSD speeds with LAN, you'd need 10 gbps cards, not 1 gbps...
11:15
<markit>
I don't get the reasoning, sorry. If I've 1Gb/s lan I have around 80MB/s, since libo file is 80MB, should take 1 second to "travel" from server to client
11:15
<alkisg>
Only if there's no CPU involved
11:15
You're thinking "cp"
11:15
It's not
11:15
<markit>
let's say that is a little slower... 5 seconds? not 15!
11:16
but cpu is not saturated at all in both sides
11:16
<alkisg>
"fetch me that file. OK, waiting. Now i'll process it and make a dbus call. OK now fetch me that other file. Now I want that little sector there"
11:16
All processes EXCEPT benchmarks/cp etc work that way
11:17
They ask a few things from disk, then they do some CPU tasks, so they don't max out either the disk or the cpu
11:17
Because they don't work in parallel. They wait for result from disk, then use cpu, and disk just waits until cpu is finished processing
11:17
That's why "readahead" was developed, to try to predict what the next disk call will be, and fetch it while CPU is processing
11:18
And of course readahead only succeeds in 10% of the cases, it can't predict the future disk requests properly
11:18
You need example?
11:18
loop: (read icon from disk, draw icon to screen)
11:19
This doesn't max out neither disk nor CPU
11:20
IF the libreoffice programmers did that though:
11:20
loop: (read icon from disk, receive it *asynchronously* and *then* draw it), that would max out one of them
11:20
This is very usual in network programming, doing CPU tasks WHEN disk/net data is received, but it's not very usual in normal programming, as it's more difficult
11:24
<markit>
I see, but in local disk I see "spikes" and high load of cpu or I/O when I run big programs, while with LTSP I see only slow load, that is surprising
11:25
<alkisg>
One net/cpu loop needs e.g. 1 msec. For the spike to register, you need e.g. 10 msec. So, they'll never show up as net will stop the cpu from maxing out for 10 msec
11:25
This is the same even if you use SSD but you clear the cache
11:25
Remember, you are not clearing the cache, so you're not using SSD, you're measuring RAM cache speed, which needs only CPU
11:26
Boot without VM, in a local disk, even SSD
11:26
Then run echo 3 > /proc/sys/vm/drop_caches
11:26
Then run libreoffice
11:26
<markit>
here is fast
11:26
<alkisg>
And compare with that :)
11:26
<markit>
5 seconds as well, on ssd
11:26
<alkisg>
With VM?
11:26
Because VM caches the data
11:26
<markit>
no, my computer
11:27
<alkisg>
OK do vnc for me to see
11:27
!vnc-edide
11:27
<ltspbot>
vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
11:27
<alkisg>
or:
11:27
!vnc-dide
11:27
<ltspbot>
vnc-dide: To share your screen with me, run this: sudo apt-get --yes install x11vnc; x11vnc -connect srv1-dide.ioa.sch.gr - this is a reverse connection, it doesn't need port forwarding etc.
11:27
<markit>
splash screen after 1 second, and libo after 3
11:27
<alkisg>
OK, let's see it together
11:27
<markit>
I've a 4K screen
11:27
<alkisg>
I don't mnid
11:28
*mind
11:28
<markit>
I'm on debian sid, do I have to install epoptes then?
11:28
<alkisg>
No do the second variant, with just x11vnc
11:28
!vnc-dide
11:28
<ltspbot>
vnc-dide: To share your screen with me, run this: sudo apt-get --yes install x11vnc; x11vnc -connect srv1-dide.ioa.sch.gr - this is a reverse connection, it doesn't need port forwarding etc.
11:29
<alkisg>
markit: it disconnected
11:29
run it again
11:30
<markit>
ok
11:31
<alkisg>
Meh you have the broken old x11vnc
11:31
No
11:31
Hrm
11:32
markit: 9 seconds
11:32
And didn't max out anything
11:33
What you were counting is the RAM/cache speed
11:33
Not disk speed. As it was already cached in RAM
11:34
9 sec without cache, 2 sec with cache
11:35
When only cache is used, then only CPU is used, that's why it maxes out CPU
11:35
This is the same in LTSP too, if you cache everything, it maxes CPU and loads in 2 secs
11:35
<markit>
I dropped the cache, maybe I missed the "sync"
11:36
yes, but if SERVER caches LiBo, and then client runs it, seems to me that should run much faster
11:36
<alkisg>
Nope. It's the network that's "slow", we don't care at all if the server has cached it or not
11:36
Server disk speed = 500 MB/sec = 5 gbps. Network speed = 1 gbps, much less than the disk speed
11:37
<markit>
ok, and no better protocol or whatever to make it run faster?
11:37
<alkisg>
To cache it in the client
11:37
<markit>
let me test lan speed of the VM, just to be sure
11:37
of course :)
11:37
<alkisg>
That's what map7 does, it caches everything with "dd" when the client boots
11:38
So if everything is in RAM, then everything is fast, except for /home
11:38
And if one wants to be even faster, he can cache (read) /home/username as well
11:38
<markit>
I've a 4GB image and we boot clients every lesson
11:38
btw, epoptes says speed is 2Gb/s since I've 2 lan bounded
11:39
(round robin)
11:39
but sure, if local is 9 seconds, client 15 sounds good
11:40
<alkisg>
local with rotational is more than 15 ;)
11:40
It's only ssd that's 9
11:40
<markit>
ok, btw default 8 nfs daemond are enough for 25 clients?
11:40
<alkisg>
2 gb to many clients, not one client, right?
11:41
<markit>
2.5 to the single client, the "nic" is virtual
11:41
<alkisg>
The clients use bonds too?
11:41
Ah, virtual client, ok
11:41Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
11:41
<markit>
to be fair, should "virtually" run at 10Gbs, but maybe there is some setup to do
11:42
<alkisg>
In any case, waiting for 1 min for the pc to boot, and 10 sec for soffice or firefox to run, sound rather acceptable to me
11:42
So I don't give it more thought than that
11:42
<markit>
btw, I've always considered vnc a very slow, laggish protocol, how can you work in my 4K screen without issues?
11:42
<alkisg>
IRC and terminal needs minimal bandwidth. I'm not trying to browse or watch youtube :)
11:43
I see one frame per 3 seconds :)
11:43
And that's only because it's a small window there
11:43
Full screen, I'd see one frame per minute :D
11:44
<markit>
I see, sure
11:44
ok, I had big hopes that we could have made ltsp run much faster just discovering a simple bottleneck :( Maybe next time ;P
11:45
<alkisg>
Haha, you'll need to make libreoffice launch in 5 seconds in rotational (which means a whole lot of optimizations in the libreoffice, kernel, libc code) and then ltsp will get them too :)
11:46
OK lunch time, see you later guys
11:46
<markit>
also "decompressing" inidrd.img takes 10 seconds
11:46
ok, thanks a lot, see you :)
11:46
<alkisg>
Decompression time is the same with or without ltsp; hopefully they'll switch to zstd which is better
11:47
<markit>
I'll have a loot at ltsp.conf to put zstd as default for ltsp imgage
12:02markit has left IRC (markit!~marco@mail.ammdomus.it, )
12:16Mikaela has left IRC (Mikaela!~Mikaela@unaffiliated/mikaela, Quit: Mikaela)
12:17Mikaela has joined IRC (Mikaela!~Mikaela@unaffiliated/mikaela)
12:52Teridon1 has joined IRC (Teridon1!~Teridon@dragon.teridon.com)
12:56Teridon has left IRC (Teridon!~Teridon@dragon.teridon.com, Ping timeout: 250 seconds)
13:28sunweaver has joined IRC (sunweaver!~sunweaver@fylgja.das-netzwerkteam.de)
13:28
<sunweaver>
alkisg: I have a question regarding LTSP
13:29
but first question: are you and your loved ones well?
13:29
Here comes the question... Everyone is crazy about homeoffice these days.
13:29
I have a running LTSP next generation installation running and one customer that boots over PXE.
13:30
Now they ask for conversion of the netboot images into ISO images to be booted from a USB stick.
13:30
Is that something that has been done before with an LTSP image?
13:30
If no, do you have some concept in mind to make that happen?
13:31
The customer is willing to pay upstream development (me contributing to LTSP) for that.
13:34
<MWALTERS>
would remoting into the LTSP server be a viable alternative?
13:34
(x2go)
13:34
<sunweaver>
MWALTERS: nope. The user shall RDP into a Windows Terminal Server.
13:35
MWALTERS: I modified the LTSP image in a way that it acts as a X2Go Thinclient, running X2Go, but only with DirectRDP sessions configured in X2Go Client
13:35* sunweaver is from X2Go upstream btw.
13:35
<MWALTERS>
So you're using LTSP as a launchpad to have them RDP intoa windows client? Why not ask them to RDP straight into the Terminal server?
13:36
RDP gateway seems like the correct answer in this situation, doesn't it?
13:36
s/windows client/windows server
13:37
<sunweaver>
basically yes, but the customer does not want to have their own devices in the company's network.
13:38
basically, what you say is what I told the customer, too.
13:38
<MWALTERS>
Gotcha ;)
13:38
<sunweaver>
But they don't want to see the employees' Windows machines on their network.
13:38
so, this is where the LTSP boot stick comes into play.
13:38
<MWALTERS>
I mean... they don't have to. I'm sure you also explained that.
13:38
<sunweaver>
sure, I did.
13:39
<MWALTERS>
It seems like you already thought of reasonable alternatives. I'll defer to the LTSP folks from here :)
13:39
<sunweaver>
thanks!
13:39
<MWALTERS>
Handing out USB drives and trying to explain how to boot from them to end-users sounds... tiring. ;)
13:40
<sunweaver>
MWALTERS: that won't be my job. And many of them are used to that, but with IGEL tc images on USB stick. They are to be replaced now.
13:40
(it will be the site admin's job...)
13:40
<MWALTERS>
Give that person a raise :)
13:40
<sunweaver>
not my call ;-)
13:47
alkisg: ^^^ my question is still open... Hope to hear from you soon.
14:16shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer)
14:18shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi)
14:22
<alkisg>
Back, reading...
14:24
!local-boot
14:24
<ltspbot>
local-boot: If you want LTSP fat clients on a low-speed network, you can put i386.img on e.g. C:\Boot\LTSP\i386.img and use this command line in pxelinux.cfg: APPEND ro initrd=ltsp/i386/initrd.img init=/sbin/init-ltsp root=/dev/sda1 rootflags=ro loop=/Boot/LTSP/i386.img; IPAPPEND 3
14:24
<alkisg>
!liveusb
14:24
<ltspbot>
Error: "liveusb" is not a valid command.
14:25
<alkisg>
!learn liveusb as My attempt at a multiboot USB stick: https://github.com/alkisg/liveusb
14:25
<ltspbot>
The operation succeeded.
14:25
<alkisg>
sunweaver: you can tell grub to boot from inside a squashfs, and you can use liveusb in order to have a USB drive based on grub that is bootable under BIOS or UEFI
14:26
Since you don't need any server connections for /home or users or authentication, I don't think any changes to LTSP are needed at all...
14:27
Btw, I'm currently working on booting ltsp.img + windows.vmdk from a USB stick, for a client ;)
14:28
(i.e. VM windows on a stick)
14:38
(btw I hope you and yours are fine too; but from what I'm hearing, Germany is so organized that's not afraid from any viruses :))
15:31
<sunweaver>
alkisg: thanks a lot for feedback!
15:32
<alkisg>
np, ping me if anything's needed
15:32
<sunweaver>
Nice! Will look into this tonight.
15:33
German government seems very organized, but many people here are reluctant to "obey". Other than in China, the German approach is a democratic approach. But many people here seem resistant against good advice.
15:33
We (family) have self-quarantined ourselves and only leave home for the absolute necessary.
15:34
I am looking forward to playing with liveusb.
15:34
(is it something that should go to Debian?)
15:34
<alkisg>
Nah
15:34
Just an image with both grub-pc and grub-efi, and an easy method to dd it
15:35
so that it works under secure boot, plain uefi, or bios
15:35
...by just dropping .iso in a folder... and also supports windows setup... I give it to teachers here to make it easier for them to format standalone PCs
16:02shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer)
16:03shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi)
16:14shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer)
16:15shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi)
16:18shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer)
16:18shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi)
16:18shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer)
16:19shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi)
16:20shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Max SendQ exceeded)
16:21shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi)
16:41statler has left IRC (statler!~Georg@gwrz.lohn24.de)
16:43vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
18:03Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Remote host closed the connection)
18:04Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49)
18:23Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Remote host closed the connection)
18:25Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
19:04Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Remote host closed the connection)
19:05Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49)
19:36woernie has left IRC (woernie!~werner@pD9E8BE9E.dip0.t-ipconnect.de, Ping timeout: 250 seconds)
19:36woernie has joined IRC (woernie!~werner@pD9E8BE9E.dip0.t-ipconnect.de)
19:59quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: WeeChat 2.6)
20:02quinox has joined IRC (quinox!~quinox@ghost.qtea.nl)
20:41shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer)
20:41Teridon1 has left IRC (Teridon1!~Teridon@dragon.teridon.com, Remote host closed the connection)
20:43shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi)
20:48shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer)
20:48shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi)
20:54woernie has left IRC (woernie!~werner@pD9E8BE9E.dip0.t-ipconnect.de, Remote host closed the connection)
21:30GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com)
21:34GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 240 seconds)
21:47shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer)
21:48shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi)
22:00vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 246 seconds)
22:12Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
22:34GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com)
22:57GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 240 seconds)
22:59markit has joined IRC (markit!~marco@mail.ammdomus.it)
23:41GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com)