03:05 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
07:18 | woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de) | |
08:16 | statler has left IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de, Remote host closed the connection) | |
09:08 | statler has joined IRC (statler!~Georg@gwrz3.lohn24.de) | |
10:20 | os_a has joined IRC (os_a!~Thunderbi@195.112.116.22) | |
12:17 | section1 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:51 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
13:09 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 240 seconds) | |
13:24 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
13:46 | enoch88483838 has joined IRC (enoch88483838!25f71ea4@37-247-30-164.customers.ownit.se) | |
13:46 | gdi2k 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:47 | gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.27) | |
13:55 | os_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:15 | gvy 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:21 | gvy 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:31 | gvy 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:22 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
16:34 | GodFather 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:10 | vagrantc 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:44 | statler has left IRC (statler!~Georg@gwrz3.lohn24.de, Remote host closed the connection) | |
18:53 | gdi2k 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:28 | kjackal has joined IRC (kjackal!~quassel@209.121.128.189) | |
19:29 | gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.27) | |
19:38 | <alkisg> I guess some users install 2-3 times though :)
| |
19:39 | gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.27, Ping timeout: 240 seconds) | |
19:40 | woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection) | |
19:46 | gdi2k 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:04 | section1 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:20 | gdi2k 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:42 | kjackal 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:27 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
21:32 | kjackal has joined IRC (kjackal!~quassel@209.121.128.189) | |
22:01 | kjackal 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:18 | kjackal has joined IRC (kjackal!~quassel@209.121.128.189) | |
23:42 | ltspuser456 has joined IRC (ltspuser456!d510b783@hypernet.the.forthnet.gr) | |
23:58 | kjackal has left IRC (kjackal!~quassel@209.121.128.189, Ping timeout: 276 seconds) | |
23:59 | kjackal has joined IRC (kjackal!~quassel@209.121.128.189) | |