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


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

03:05vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
07:18woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de)
08:16statler has left IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de, Remote host closed the connection)
09:08statler has joined IRC (statler!~Georg@gwrz3.lohn24.de)
10:20os_a has joined IRC (os_a!~Thunderbi@195.112.116.22)
12:17section1 has joined IRC (section1!~section1@178.33.109.106)
12:43
<alkisg>
ppastats.py -r=bionic 'ts.sch.gr/ppa' ==> ltspfsd 1.5-2+t201807160629~ubuntu18.04.1 6350
12:43
Not bad, if the greek schools ppa has more than 6.000 ltsp installations, there should be more around that don't use it...
12:44
AFAIK the greek installations might be 1350, which means 5000 are the non-greek installations
12:51Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
13:09alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 240 seconds)
13:24alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
13:46enoch88483838 has joined IRC (enoch88483838!25f71ea4@37-247-30-164.customers.ownit.se)
13:46gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.28, Read error: Connection reset by peer)
13:47
<enoch88483838>
alkisg hey, I can see that you're busy, but when you have time; I have tried several different things in the new version and it won't just work: https://github.com/ltsp/community/wiki/Single-guest-session-over-NFS
13:47
it's just like the rsync command isn't run
13:47
when I run it manually it works
13:47gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.27)
13:55os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Quit: os_a)
13:57
<alkisg>
enoch88483838: can we vnc?
13:57
!vnc-edide
13:57
<ltsp>
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
13:57
<enoch88483838>
sure, one sec
14:01
ok
14:04
<alkisg>
-R, --relative use relative path names
14:04
enoch88483838: that parameter was wrong
14:05
You only wanted -a there, not -aAR
14:05
<enoch88483838>
it doesn't work without it either
14:05
when I synced manually inside the session it worked with that
14:05
and the "Guest session" wiki uses it
14:05
<alkisg>
Because you cd'ed there
14:05
<enoch88483838>
aaa
14:05
<alkisg>
Fix the wiki then :)
14:05
Put the pass
14:07
<enoch88483838>
do you happen to know how to make xfreerdp2 desktop enteries?
14:07
rdesktop is kind of slowish
14:07
<alkisg>
I'm sure I could look it up
14:08
<enoch88483838>
I'll send you some more $$$
14:08
<alkisg>
So
14:08
You're mounting /home/guest with fstab
14:08
Yet you sync with POST_INIT
14:08
<enoch88483838>
it seemed to do the trick
14:08
<alkisg>
that's also wrong, it just wastes ram on the client
14:08
<enoch88483838>
let me test one thing
14:09
<alkisg>
Why do you need to "enable epoptes"?
14:10
OK tell me what you need wrt xfreerdp
14:10
A desktop entry that would connect to one server, and another for another server etc?
14:10
<enoch88483838>
you added that :)
14:10
yes, same setup as with rdesktop
14:10
but using xfreerdp
14:10
<alkisg>
ok
14:11
enoch88483838: in the issue, you say: @alkisg Upgraded to 19.11 and it stopped working. Any idea what could have caused that?
14:11
Is it really related to 19.11?
14:12
Or was that just the wrong -R parameter?
14:12
<enoch88483838>
it worked before the upgrade with my settings (same as yours are now but with rsync -aA ...)
14:12
ie before the testing
14:12
<alkisg>
I don't think the upgrade had anything to do at all with rsync
14:12
<enoch88483838>
I added the -R when it stopped working
14:12
<alkisg>
-aA would work,yes
14:13
-a implies -A, so it's the same whether you put it or not
14:13
<enoch88483838>
-aA was the original before the upgrade
14:13
<alkisg>
OK so it works the same way now
14:13
<enoch88483838>
I did the upgrade then it stopped working so I added -R
14:13
let me test one thing here...
14:13
<alkisg>
What stopped working, the syncing?
14:15
<enoch88483838>
yes
14:15
<alkisg>
enoch88483838: ok, the client should create it now on next boot
14:15
<enoch88483838>
ok, let's see
14:15
<alkisg>
I don't think it was related to the update at all; and we didn't even modify anything except remove the -R
14:15
<enoch88483838>
I'm amazed in that case as what you did, I did to
14:15gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving)
14:16
<enoch88483838>
after the upgrade it stopped working so I started to make changes
14:16
<alkisg>
Something else has happened, but it works now, so I can't find what happened
14:16
<enoch88483838>
ok, ot worked
14:16
strange
14:18
this is a single display btw
14:18
just testing now
14:18
<alkisg>
Hmm strange that epoptes can't detect the display
14:18
anyway, not important, continuing...
14:18
<enoch88483838>
ok :
14:18
:)
14:19
<alkisg>
enoch88483838: firewall?
14:20
enoch88483838: vnc crashed; run it again please
14:21gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
14:27
<enoch88483838>
sorry
14:28
what's the command for runnintg it in CLI?
14:28
<alkisg>
enoch88483838: x11vnc -connect srv1-dide.ioa.sch.gr
14:30
<enoch88483838>
I need to restart
14:30
sec
14:30
something happened
14:31gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving)
14:32
<enoch88483838>
now I can't make a -
14:32
sorry
14:32
worked
14:32
after 100 times :D
14:35
<alkisg>
enoch88483838: I didn't receive a connection
14:35
<enoch88483838>
sec, working on it
14:40
<alkisg>
enoch88483838: ouch it crashed again
14:40
vnc again
14:40
and I'll install the newer x11vnc from the greek schools ppa for you
14:40
<enoch88483838>
ok
14:41
<alkisg>
x11vnc -connect srv1-dide.ioa.sch.gr
14:42
OK the marco update is also fine, it solves bugs in nvidia
14:43
<enoch88483838>
okok
14:44
take the 2
14:44
thats the latest
14:47
slow disks on RAID5 yaya
14:49
<alkisg>
Heh, usually the bottleneck there is the CPU, not disk
14:51
<enoch88483838>
vnc still working?
14:52
<alkisg>
Yes
14:52
<enoch88483838>
ok
14:53
<alkisg>
I ran it manually
14:53
that's why it doesn't show in the dialog
14:53
<enoch88483838>
ah
14:53
<alkisg>
I used the loop command so that it wouldn't disconnect until I installed the new fixed version
14:54
<enoch88483838>
aah ok
14:56
<alkisg>
enoch88483838: what's your real screen resolution, can I increase the VM more?
14:57
<enoch88483838>
mine is big, but i'm using console so now I can't see half of the screen :D
14:58
timeout needs to be 3 seconds
14:58
it wouldn't login this time
14:59
<alkisg>
You can use lightdm-autologin-greeter for better autologin results
14:59
<enoch88483838>
sure
14:59
<alkisg>
It was developed just to work around that lightdm bug
14:59
<enoch88483838>
whatever is best
14:59
do it :)
15:00
<alkisg>
I'll paste the options here:
15:00
rdesktop 192.168.xxx -B -b -x 0x81 -P -D -r sound:local -f -k sv -d xxxx
15:00
Let me read the man page to translate them to xfreerdp options...
15:00
<enoch88483838>
ok
15:01
<alkisg>
-B = backingstore => why?
15:02
-b = bitmaps, probably slower, ignoring too,
15:02
<enoch88483838>
just tested, it was faster to my eyes at least
15:02
clear text -x 0:81
15:02
with broadband speed
15:03
<alkisg>
-x 0x81 => yeah shouldn't that be "-x b" ?
15:03
<enoch88483838>
no
15:03
<alkisg>
ah ok supports the flags
15:03
<enoch88483838>
beacuse that leaves out the clear text
15:03
<alkisg>
-P is caching,
15:03
-D is decorations,
15:03
-r redirection,
15:04
-f full screen
15:04
-k keyboard
15:04
-d domain
15:04
OK, let's see xfreerdp...
15:06
<enoch88483838>
sv = Sweidsh
15:06
Swedish*
15:06
the top one
15:07
/fonts
15:08
if you just do something basic POV I can imprve the tags later on
15:08
or switches
15:09
POC**
15:09
<alkisg>
OK, so far: /f /bpp 16 /kbd sv /d domain /compression /sound /bitmap-cache
15:12
<enoch88483838>
kbd should be the code, not sv
15:12
that's the thing, it should come up as a login in windows
15:12
which it doesn't
15:14
<alkisg>
Right, I wonder if it's the second version that broke that
15:14
Let me google a bit
15:15
<enoch88483838>
ok
15:17
the goal is to use a connection withiut username like rdesktop does it, so that the user can enter the username him/herself
15:18
or, make a tiny screen pre-login where the user enter the credentials
15:18
we have a script like that on another server for rdesktop
15:18
let me see if I can link it
15:19
<alkisg>
Strange, I would have bet that I've seen the login dialog with xfreerdp in the past
15:20
<enoch88483838>
ok, you can try V1 then
15:20
on the administrator account so that you don't have to re-image
15:20
<alkisg>
Reading this: https://github.com/FreeRDP/FreeRDP/issues/1358#issuecomment-65632723
15:22
https://github.com/FreeRDP/FreeRDP/issues/1358#issuecomment-362877384
15:22
<enoch88483838>
and the problem with remmina is that it doesn't show in full screen
15:22
yeah, tried that already
15:22
didn't work, but to be honest I never gave it a really good try
15:23
<alkisg>
enoch88483838: can we test with a user, so that we see that from command line it works fine?
15:23
<enoch88483838>
sure
15:23
I can type my password
15:26
<alkisg>
enoch88483838: the error says "bad username or password"
15:26
Try again
15:27
<enoch88483838>
nope
15:28
<alkisg>
enoch88483838: is it possible you're typing it wrong due to keyboard layout?
15:28
<enoch88483838>
no
15:28
<alkisg>
OK let's try rdesktop
15:28
<enoch88483838>
bo special signs or anything like that
15:29
that's what I want :)
15:30
whut
15:30
<alkisg>
Go to the console
15:30
Type some chars from your password, mixed, not in order
15:30
To see if they're typed properly
15:31
OK
15:31
First of all, can you see if it's fast?
15:31
<enoch88483838>
sure sec
15:31
<alkisg>
If it works better, THEN it makes sense to automate it
15:31
Otherwise there's no point
15:32
It also has vnc now so it might be slower, maybe I should disconnect
15:32
I closed vnc
15:33
<enoch88483838>
it's faster
15:33
<alkisg>
OK
15:33
So you need the development of a GUI that allows one to select server, domain, user, password etc?
15:33
And translate those to xfreerdp commands?
15:34
<enoch88483838>
there's a GUI already as yo posted, so implement that U guess
15:34
but that's something I could do myself
15:34
<alkisg>
Right
15:34
<enoch88483838>
was just curious on how to make it desktop enteries
15:34
<alkisg>
You just clone your existing desktop entries,
15:35
but they won't have the username
15:35
<enoch88483838>
yeah, so thta's an issue
15:35
<alkisg>
rdesktop asks the username, xfreerdp probably doesn't
15:35
That's why the GUI is needed
15:35
Although, I'm pretty sure freerdp shows the login UI...
15:35
<enoch88483838>
ok, I can fiddle around with it a bit and see if I can make it work
15:35
<alkisg>
I don't know if something's wrong now, or if something's changed, or if I remember wrong
15:36
<enoch88483838>
I don't know either actually
15:36
<alkisg>
It might also make sense to install the latest one from eoan repositories
15:36
<enoch88483838>
eoan?
15:36
gr?
15:36
<alkisg>
Ubuntu 19.10
15:36
<enoch88483838>
aah
15:38
<alkisg>
There's also a lightdm greeter for xfreerdp
15:38
So that the user wouldn't have to login as guest at all
15:38
<enoch88483838>
whuut
15:38
ok, that sounds like what we need
15:38
<alkisg>
I'm copying the latest packages from 19.10 to my ppa
15:39
<enoch88483838>
ok great!
15:39
<alkisg>
They'll need an hour to build etc
15:39
Ping me later to continue with these
15:39
<enoch88483838>
yea
15:39
okok
15:39
tomorrow :)
15:39
<alkisg>
OK
15:40
<enoch88483838>
thank you so far!
15:41
<alkisg>
You're welcome, thank you too
15:43
Aaah https://bbs.archlinux.org/viewtopic.php?id=191242 says the login screen used to show with windows 7
15:44
It's been years since I tested, so it might have been this
15:44
enoch88483838: read this: https://serverfault.com/questions/885080/is-it-possible-to-access-the-login-windows-screen-through-rdp
15:44
It requires server-side changes too
15:44
<enoch88483838>
checking
15:45
<alkisg>
It works with rdesktop just because it's older
15:45
It would probably work with xfreerdp if one disables nla too
15:45
<enoch88483838>
we can try
15:45
can we manually disable it?
15:45
we can specify rdp
15:46
instead of nla
15:46
/sec:<rdp|tls|nla|ext> force specific protocol security
15:47
<alkisg>
Right
15:47
Or /sec-rdp
15:47
<enoch88483838>
sec
15:47
will try
15:48
whats the sex.. command for keyboard layout?
15:48
setxmap
15:48
found it
15:48
<alkisg>
setxkbmap
15:49
sexy keyboard map :P
15:49
<enoch88483838>
haha yeah exaclty
15:49
woooooohaaa
15:50
/sec:/rdp worked!
15:50
ok, so problem solved
15:50
/sec:rdp **
15:50
thanks for the brainstorming
16:22gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
16:34GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 276 seconds)
17:24
<enoch88483838>
hi again alkisg
17:24
so I've setup the xfreerdp sessions now and it's MUCH faster
17:25
thank you very much!
17:25
there is one small thing left to do, dual monitors
17:25
I tried to enable the config you set before in ltsp.conf, but it didn't work
17:25
I will be here for about one hour more
17:26
just ping me if you have time (and energy), or we'll do it tomorrow
17:29
<alkisg>
enoch88483838: here
17:29
<enoch88483838>
nice!
17:30
vnc, need more $$?
17:30
<alkisg>
x11vnc -connect srv1-dide.ioa.sch.gr
17:33
<enoch88483838>
sec
17:33
need do fix firewall
17:35
<alkisg>
enoch88483838: which one of those has dual monitors?
17:36
<enoch88483838>
let me double checl
17:36
70
17:38
<alkisg>
enoch88483838: was the monitor connected when the client booted?
17:38
This seems different than before, now it's not detecting modes
17:38
<enoch88483838>
yes
17:38
I added your option, then rebooted
17:39
<alkisg>
And it's connected via DP?
17:39
<enoch88483838>
no, just one screen is live
17:39
but it can detect the other screen
17:39
look
17:40
<alkisg>
No need
17:40
<enoch88483838>
ok
17:40
<alkisg>
We forced it to see the screen
17:40
But, in hdmi, it can see modes
17:40
<enoch88483838>
there were some error output I thoughtyou wopuld like to see
17:40
<alkisg>
So, is it connected via DP?
17:40
<enoch88483838>
DP, correct
17:41
that will be hard to keep track
17:41
alot of maintainance if they change screens etc
17:42
<alkisg>
Let's see if it works first
17:42
<enoch88483838>
ok
17:42
<alkisg>
Whoops
17:42
vnc again please
17:42
From another tab
17:42
keep the root tab open for commands
17:44
enoch88483838: it's possible that it's just fixed in newer kernel/xorg
17:44
Or older ones :D
17:44
<enoch88483838>
sure :)
17:44
<alkisg>
In general kernel parameters shouldn't be needed...
17:44
<enoch88483838>
this is old machines
17:44
needed a newer bios to even boot 5.0
17:44
or anything higehr than 4.10
17:45
<alkisg>
Maybe we can revert to the stock 4.15 then
17:45
and the older xorg stack
17:45
18.04.1 comes with 4.15, and is never upgraded,
17:45
<enoch88483838>
are there any downsides?
17:45
but this works, right?
17:45
and it feels snappier
17:45
<alkisg>
18.04.2+ comes with 4.18 and then 5.0 and then 5.3 etc
17:45
<enoch88483838>
but that might just be placebo
17:45
<alkisg>
Did you try with 4.15?
17:45
If the clients work fine, there's no reason to use 5.x
17:46
<enoch88483838>
no, since this test is all about getting the latest and greatest
17:46
<alkisg>
and try to manage kernel parameters
17:46
18.04 has both kernels
17:46
You can just select the one you want
17:46
They're both properly maintained
17:46
And you still have the latest and greatest software in both cases, it doesn't change
17:46
<enoch88483838>
we can uninstall the one that aren't used and apt hold all the kernels
17:46
that's how I did before
17:46
<alkisg>
There's no need to apt hold
17:47
It's managed by different metapackages
17:47
<enoch88483838>
but I don't want to choose each time it boots
17:47
sec
17:47
will snapshot
17:47
<alkisg>
You don't
17:47
Anyway let's see if video=DP-1:e helped or not
17:47
And we'll talk about kernels after that
17:48
<enoch88483838>
ok snapshot done
17:48
ok
17:48
<alkisg>
Btw, did you say that it starts initially with dp output, then it switches to vga?
17:49
<enoch88483838>
hmm, let me see
17:49
the computer is on the other side of the hall
17:49
sec
17:51
<alkisg>
Also, I don't see the client in epoptes yet... :/
17:52
<enoch88483838>
it wasn't network booting
17:52
fixed now
17:53
and yes, it starts on DP, but switches after the kernel is loaded
17:53
the fix didn't work btw
17:53
:/
17:55
<alkisg>
enoch88483838: I think we should try with an older kernel/xorg
17:55
But I need to go afk for half an hour
17:55
See you later, or tomorrow, ok?
17:55
<enoch88483838>
yeah, same here
17:55
ok
17:56
np
17:56
ciao!
18:10vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
18:18* vagrantc wakes up to a new ltsp release
18:27
<alkisg>
Like the old times :D
18:29
I wanted to give that some testing, we can change things before uploadingto debian
18:30
See if you dont like something in the ltsp-binaries package/dependencies etc
18:44statler has left IRC (statler!~Georg@gwrz3.lohn24.de, Remote host closed the connection)
18:53gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.27, Ping timeout: 276 seconds)
19:12
<alkisg>
vagrantc: ppastats.py -r=bionic 'ts.sch.gr/ppa' ==> ltspfsd 1.5-2+t201807160629~ubuntu18.04.1 6350
19:12
I think that means that there was 6350 downloads of ltspfsd; minus 1350 greek schools, that would be ~5000 ltsp installations...
19:22
<||cw>
not including those behind caching proxies :)
19:28kjackal has joined IRC (kjackal!~quassel@209.121.128.189)
19:29gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.27)
19:38
<alkisg>
I guess some users install 2-3 times though :)
19:39gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.27, Ping timeout: 240 seconds)
19:40woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection)
19:46gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.27)
19:53
<vagrantc>
or more
19:53
but cool, you've got stats for the ppas :)
19:54
accuracy for such stats isn't really the goal... just getting a rough idea of trends
19:54
at least, that's my take :)
19:55
alkisg: i'll give it a look-over ... got a little more free time in the next couple days than usual
19:57
<alkisg>
great
19:57
In ltsp, i suggest ltsp-binaries | ipxe
19:58
So that ltsp-binaries is preffered
19:58
Is it a problem that it's not in debian?
19:58
<vagrantc>
it's ok-ish
19:59
there was a recent policy relaxation about that sort of thing
20:01
oh no, 0 and 1 booleans :P
20:01
<alkisg>
vagrantc: the kernel also uses these :D
20:02
And ltsp is minimalistic like the kernel :D
20:02
<vagrantc>
:P
20:02* vagrantc mumbles about unrelated changes in a single commit too
20:02
<vagrantc>
but overall, loving ltsp 19 :)
20:03
<alkisg>
Hey I did 2 commits just because I thought of you! Cut me some slack! :D
20:03
I also need to see what you were telling me about signed ... commits? tags?
20:04section1 has left IRC (section1!~section1@178.33.109.106, Quit: Leaving)
20:04
<vagrantc>
git tag --sign YOURTAG
20:04
i wouldn't recommend signed commits
20:05
<alkisg>
OK, that doesn't sound time consuming, I'll give it a looksee
20:05
<vagrantc>
obviously need access to a signing key :)
20:05
<alkisg>
I have one of those... not the whole story with subkeys etc, but it'll do
20:09
<vagrantc>
signing keys aren't terribly hard to add...
20:09
subkeys, that is
20:09
<alkisg>
It's what uploaded in the debian-maintainers keyring
20:09
<vagrantc>
then you can keep the master key in your sock drawer or something :)
20:09
<alkisg>
So it's my signing key
20:09
Yeah I got that part but it needs a few KB in my mind which I can't spare currently :P
20:09
<vagrantc>
a subkey allows you to use your signing key, but keep the primary key safe elsewhere
20:10
<alkisg>
Later, if I manage to have time to apply for DD...
20:10
<vagrantc>
fair enough
20:19
alkisg: does ltsp actually have any code the the regular /boot/initrd.img ?
20:19
<alkisg>
vagrantc: debian/ltsp.initramfs-hook
20:20
It's there for the "normal ltsp client installation" use case
20:20gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.27, Ping timeout: 265 seconds)
20:20
<alkisg>
Where initramfs injection isn't desired
20:21
Although I think I didn't get to the part where we'd add the code, it only has the dependencies now :D
20:21
<vagrantc>
heh
20:22
just adds modules, as far as i can tell
20:23
<alkisg>
I think I was planning to also copy the ltsp client code; then I wanted to extract that part into a function as it's used from 2 places; then I got sidetracked...
20:23
In any case, if we ever need it, it shouldn't be hard
20:23
<vagrantc>
sure
20:24
<alkisg>
I'm thinking we can also introduce a "MERGED_INITRD=1" ltsp.conf parameter, that would use initrd.img-original to store the original, and have initrd.img be the merged one, that would also include ltsp.img
20:24
<vagrantc>
whoah, you rename ipxe.efi to snponly.efi in the tftp dir?
20:25
<alkisg>
...if we need a boot manager that doesn't support multiple initrds
20:25
Yeah, it's to overcome the current debian's lack of snponly.efi
20:25
<vagrantc>
yeah, we'll probably need that for arm*
20:25
<alkisg>
It works
20:25
I do want to keep the names static, for simpler ltsp.ipxe menu
20:25
and dnsmasq.conf
20:26
<vagrantc>
sure
20:26
a little ... misleading, though :)
20:26
<alkisg>
Meh. It'll still say ipxe loading :P
20:26
<vagrantc>
heh
20:27
<alkisg>
We'll need to document that workaround anyway, for cases where snponly.efi won't work
20:27
<vagrantc>
if you're going to ever rename it ... maybe always rename it ?
20:27
<alkisg>
I'm only copying ipxe.efi over snponly.efi, if snponly.efi doesn't exist
20:27
It's a replacement; it doesn't always apply
20:27
"if snponly.efi is found, use it, otherwise get ipxe.efi in its place"
20:29
<vagrantc>
yeah, i get that, it's just snponly.efi isn't always snponly.efi
20:29
that's the confusing part
20:29
<alkisg>
What does "always rename it" mean in this context?
20:29
<vagrantc>
if the source is snponly.efi or ipxe.efi, rename it to ltsp-ipxe.efi or something
20:29
in the tftp dir
20:30
<alkisg>
Ah, use a third name...
20:30
<vagrantc>
right
20:30
that way you're not "pretending" to be snponly.efi when you're not
20:30
<alkisg>
Well, I expect snponly.efi to become available in debian when the new maintainer catches up.... :D
20:31
<vagrantc>
i suspect you'd see a fresh, new and improved ipxe in debian the moment the old maintainer says ok :P
20:31
<alkisg>
Also, we'll need that workaround to be applied by users too. ipxe.efi over snponly.efi, and ipxe.pxe over undionly.kpxe, in cases where the latter ones don't work properly
20:31
<vagrantc>
eeyk
20:31
<alkisg>
It would be more confusing to tell them "ltsp-ipxe.efi is snponly.efi in reality, but copy ipxe.efi over it because..."
20:31
<vagrantc>
it's just kind of messy, sure
20:31
<alkisg>
Well the default installation wouldn't be then; just snponly and undionly
20:31
<vagrantc>
symlinks?
20:32
<alkisg>
We do mention what we do in stdout
20:32
<vagrantc>
sure
20:32
<alkisg>
Installing ipxe.efi in snponly.efi etc
20:32
<vagrantc>
it's exactly why we're having this conversation, in fact :)
20:32
<alkisg>
Nah I think for the 5% that will need this, it'll cause more confusion for the other 95% that won't, if renames/symlinks are involved
20:33
<vagrantc>
ok, your call. i raised the issue :)
20:33
<alkisg>
And they'll do it manually anyway
20:33
That overwriting there is temporary, just until snponly gets in debian
20:33
So after a couple of years we'll be able to remove it from the code completely
20:37
<vagrantc>
word to the wise, don't run "ltsp ipxe" before running "ltsp image" :)
20:37
<alkisg>
It won't create entries, but it runs ok, right?
20:39
<vagrantc>
it defaulted to booting memtest86+
20:39
which, of course, wasn't there :)
20:39
<alkisg>
Ah, efi?
20:40
It would be if you booted with bios :D
20:42kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 265 seconds)
20:42
<vagrantc>
memtest86.0 doesn't work from this either
20:43
from bios boot
20:43
<alkisg>
Hrmm I haven't tested that, it's copied from /boot/memtest86+, I thought it would be pxe-bootable...
20:43
<vagrantc>
it downloads it and then immediately returns to the menu ... but that could be an issue in memtest86
20:43
<alkisg>
Maybe a different built is needed for pxe
20:44
Or maybe memdisk is needed to load it
20:45
I guess we could hide the menu if ltsp-binaries isn't installed...
20:45
<vagrantc>
all that said, it seems worth uploading to debian unstable in the current state
20:46
<alkisg>
Yey!
20:46
<vagrantc>
alkisg: though i'd prefer to put some of the things in recommends rather than suggests ... thoughts?
20:46
<alkisg>
Remember we want `apt install ltsp` to be for ltsp clients
20:46
Which one would you put in recommends?
20:46
<vagrantc>
oh.
20:47
<alkisg>
We may grow an ltsp-server package after ltsp5 has died
20:47
But for now I think this is the best course
20:47
<vagrantc>
i see
20:47
i keep forgetting about systems other than chrootless
20:47
i know i keep bringing it up :)
20:47
<alkisg>
Yeah those annoying users and their needs :P
20:48
chrootless for all, end of story :D
20:49
http://wiki.seanmadden.net/networking/pxeboot/memtest_over_pxeboot says that memtest.bin is supposed to be bootable over pxe
20:50
<vagrantc>
i definitely booted it with pxelinux in years past
20:50
<alkisg>
Hrm... I wonder if ipxe loads it in another way if it sees the .0 extension
20:50
<vagrantc>
right
20:50
<alkisg>
Ah right, we were using it in ltsp5 too
20:50
<vagrantc>
i think ltsp5 had some code to handle that
20:50
<alkisg>
Oh. This will be a problem then, if we'll need different file names
20:51
As memtest.0 can exit to pxe and hangs less etc...
20:51
I guess it'll work if we rename it to bin, but we'll need to special-case it in the ltsp.ipxe template
20:51
Let's file a bug report for this
20:52
<vagrantc>
rather than caching the whole kernel/initrd, just having a local install of ipxe would speed up boot a bit
20:52
<alkisg>
True
20:52
<vagrantc>
regarding eddytv's boot speed issue
20:52
it'd be a middle-road approach...
20:53
would need to cache/maintain very little locally
20:53
<alkisg>
Well it can even hardcode static IPs and completely avoid any dhcp requests :D
20:53
By using a local ipxe menu file
20:54
<vagrantc>
right!
20:55
i was kind of missing the IPAPPEND=3 option when looking at all these boots
20:55
<alkisg>
It's very easy to emulate it in the ipxe cmdline
20:55
${srv}:${ip}: etc
20:56
<vagrantc>
great
20:57
alkisg: so, any blockers to consider before uploading?
20:57
looks good enough to me, can always do another upload
20:57
<alkisg>
vagrantc: well only the memtest issue, but I don't think it's sooooo important
20:57
So yeah please go for it
20:58
<vagrantc>
i'll go ahead and tag the release, then
20:58
<alkisg>
Great
20:58
Feel free to commit --amend or whatever else
20:58
Nah vagrant doesn't do that :D
20:58
Hehe
20:58* alkisg waves, 'night, and hopefully will wake up to see another ltsp release...
20:59
<vagrantc>
i use git commit --amend a lot, just only with local changes :)
20:59
"git rebase -i" is amazing :)
21:06
uploaded ... should land in debian unstable in 3-16 hours :)
21:27Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
21:32kjackal has joined IRC (kjackal!~quassel@209.121.128.189)
22:01kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 250 seconds)
22:41
<vagrantc>
and i've orphaned ldm, ldm-themes and ltspfs :)
23:18kjackal has joined IRC (kjackal!~quassel@209.121.128.189)
23:42ltspuser456 has joined IRC (ltspuser456!d510b783@hypernet.the.forthnet.gr)
23:58kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 276 seconds)
23:59kjackal has joined IRC (kjackal!~quassel@209.121.128.189)