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


Channel log from 2 September 2015   (all times are UTC)

00:50cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 240 seconds)
00:54cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
00:55dgroos has joined IRC (dgroos!~dgroos@mail.troop187.org)
01:28AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-vnsnhecartnmzzov, Quit: Connection closed for inactivity)
02:05
<dgroos>
My ltsp-pnp clients are now booting. That is good!
02:06
I use powerbroker for AD binding and during login, things are confusing:
02:08
On the one hand, a student attempts to login, a terminal screen is briefly shown, and they are returned to the login screen (here’s the terminal message: http://ibin.co/2EDD519nwZjN
02:10
On the other hand, when I look in /home I see that login at least partly succeeded since students now have a home directory—though only with 3 items.
02:11
Based on the briefly visible terminal screen linked above, I thought that the Cisco AnyConnect software might be causeing problems—make sense?
02:12
<maldridge>
that looks much more like the final outputs from the terminal booting up, are you sure that the system has a graphical environment available?
02:13
<dgroos>
So, I searched for the name of the cisco package/s so I could use the RM_SYSTEM_SERVICES option in lts.conf so that it wouldn’t be copied to the client…
02:13
maldridge: hi!
02:13
<maldridge>
greetings
02:14
<dgroos>
Well, some more strange stuff…
02:15
my test user is able to boot in unity—worked last night, and this user does go through AD, too. But…
02:16
Something different—When I first logged in last night with the test user, I left the session in it’s default settings, flashback maybe or fallback (which I had installed).
02:17
I wonder if a user first logs in with a flashback session, they are there-after able to log in with the ubuntu/unity session.
02:17
is that possible?
02:18
<maldridge>
well, one thing that will kill the ability to login is a lack of home folder
02:18
<dgroos>
I should have tried logging in with a different test user with flashback…
02:18
<maldridge>
are your users home folders being mounted from the network
02:18
?
02:18
<dgroos>
No, they are on the ltsp server.
02:19
isn’t a home folder created upon first login?
02:19
<maldridge>
not generally
02:19
you'd need pam_mkhome for that, but iirc ltsp short circuits around the pam stack
02:21
<dgroos>
That’s right! I remember that there is some preference in powerbroker I need to set so as home folders are created…
02:22
hmmm… I’ll check that out tomorrow, as well as trying to log in first with the flashback session.
02:22
So you think it has nothing to do with the cisco program?
02:22
<maldridge>
yeah, I'm not really familiar with powerbroker, but home folders is my guess
02:23
flashback might be actually making folders, that isn't really standard; No, I don't think it has to do with the cisco program
02:24
<dgroos>
OK, I’ll check the docs for powerbroker tonight. I’ll let you know what I find out tomorrow. Gracias again for you help.
02:26
<maldridge>
cool, I've not played with powerbroker, we ditched our windows domain this last summer; I'm interested to know how it works
02:26
it could be quite good with ltsp
02:28
<dgroos>
I used its previously-branded “likewise-open” version since 2010. I really like it since I don’t have to deal with student learning a new log in/dealing with forgotten passwords etc.
02:44dgroos_ has joined IRC (dgroos_!~dgroos@vpn.mpls.k12.mn.us)
02:46dgroos has left IRC (dgroos!~dgroos@mail.troop187.org, Ping timeout: 246 seconds)
02:46dgroos_ is now known as dgroos
03:31dgroos has left IRC (dgroos!~dgroos@vpn.mpls.k12.mn.us, Ping timeout: 268 seconds)
03:59vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
04:31telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
04:32telex has joined IRC (telex!teletype@94.247.40.156)
05:00ltsp has left IRC (ltsp!~pe-LTSP@76-10-176-231.dsl.teksavvy.com, Remote host closed the connection)
05:03ricotz has joined IRC (ricotz!~rico@p5B2A82A5.dip0.t-ipconnect.de)
05:03ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
05:10work_alkisg is now known as alkisg
06:51vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi)
08:33khildin has joined IRC (khildin!~khildin@ip-213-49-84-113.dsl.scarlet.be)
08:33
<alkisg>
Guys, https://bugs.launchpad.net/ltsp/+bug/1352038 needs an SRU, if anyone is using Ubuntu 14.04 (I'm still on 12.04) then do the SRU request because ltsp-pnp will not work with 14.04.3
08:34
stgraber, do I have rights to upload a new ltsp version myself, or are you needed to approve the SRU? ^
08:34
(sorry, not a full new ltsp version, only the updated ltsp-update-image script from r2661)
08:50vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Ping timeout: 252 seconds)
09:04mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
09:05alkisg is now known as work_alkisg
09:55NeonLicht has joined IRC (NeonLicht!~NeonLicht@darwin.ugr.es)
10:51telex has left IRC (telex!teletype@94.247.40.156, Ping timeout: 272 seconds)
10:52telex has joined IRC (telex!teletype@freeshell.de)
11:41Faith has joined IRC (Faith!~paty@unaffiliated/faith)
12:08telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
12:10telex has joined IRC (telex!teletype@freeshell.de)
12:19adrianorg has left IRC (adrianorg!~adrianorg@187.113.216.236, Ping timeout: 272 seconds)
12:21adrianorg has joined IRC (adrianorg!~adrianorg@201.22.230.187)
12:27uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek)
12:29vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
12:32uXus has joined IRC (uXus!~uXus@217.77.222.72)
12:34F-GT has left IRC (F-GT!~phantom@ppp121-44-204-54.lns20.syd7.internode.on.net, Read error: No route to host)
12:36
<vagrantc>
work_alkisg:
12:37
work_alkisg: looking at ltsp-update-image ... does it do any bind mounts anymore? you added comments about bind mounts
12:37F-GT has joined IRC (F-GT!~phantom@ppp121-44-204-54.lns20.syd7.internode.on.net)
12:53vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi)
13:10championofcyrodi has left IRC (championofcyrodi!~cott@50-205-35-98-static.hfc.comcastbusiness.net, Ping timeout: 265 seconds)
13:30work_alkisg is now known as alkisg
13:31
<alkisg>
Hi vagrantc
13:32
No, I completely skipped them since by doing it your way they weren't needed anymore
13:32
The lower layers are ro...
13:32* vagrantc just tested out the new ltsp-update-image
13:32
<vagrantc>
ok, so it's just cruft in the comments about bind mounts, then
13:32
i thought so, so yay
13:32
<alkisg>
Ah, I haven't removed those? Sorry
13:33
They were left over because I started with my previous revision
13:33
<vagrantc>
right
13:33
no worries, it works. :)
13:33
<alkisg>
With overlay(fs), it was possible to not see the work dirs at all, for them to be inside chroot/.work
13:33
And not see the tmp dir either, tmpdir=cowdir
13:34
<vagrantc>
i should test with aufs too
13:34
<alkisg>
I did some tests with aufs, it seemed to work
13:34
<vagrantc>
ah, good.
13:34
<alkisg>
With a separate /boot as well
13:35
<vagrantc>
the module handling was a bit confusing ... first you check if it's already loaded... and prioritize modules already loaded?
13:35
<alkisg>
Yup
13:35
<vagrantc>
no idea how that will handle with built-ins.
13:35
<alkisg>
So that we don't modify the server's modules
13:35
I'm using sys/module like you said, so it should be fine
13:35
overlay > overlayfs > aufs,
13:35
but if e.g. aufs is loaded and the others aren't, it's used instead
13:36
<vagrantc>
ah, it only loads the module if one of the preferred modules isn't already loaded?
13:36
<alkisg>
Right
13:36
E.g. suppose a server has aufs loaded and while it supports overlay, it doesn't have it loaded. We'll use aufs.
13:36
<vagrantc>
although modprobe is confusing in that it's also used to check if the feature is enabled (module or otherwise)
13:36
<alkisg>
So no modprobes/rmmods involved at all
13:37
No, modprobe isn't used to check if it's enabled
13:37
<vagrantc>
but that's just weirdness in modprobe
13:37
<alkisg>
I use sys/module there
13:37
modprobe overlayfs in ubuntu says "ok" but loads "overlay" instead
13:37
So it was useless for checking
13:37
<vagrantc>
sure
13:38
so the only question remaining, which isn't a huge deal, is how it behaves if aufs/overlay(fs) are built-in rather than modules.
13:38
<alkisg>
The same, afaik
13:38
For which part are you worried?
13:39
<vagrantc>
weather it leaves /sys/module/$X where X is a builtin
13:39
er, weather it exists
13:40
<alkisg>
I think `ls /sys/module` shows that all build-ins are there
13:40
# We also want to bind-mount whatever submounts the chroot has, e.g. /boot. ==> # We also want to mount whatever submounts the chroot has, e.g. /boot.
13:41
<vagrantc>
alkisg: sounds good.
13:42
alkisg: i see at least one built-in that is listed in /sys/module so yeah, that should work. and it's a fairly unlikely case... most distros build those as modules as far as i know
13:42
<fiesh>
is there a way to make ldm log more verbosely? I do not understand why the ssh times out, and it doesn't tell me any more
13:42
<vagrantc>
alkisg: you want the honors of committing it?
13:43
<fiesh>
tcpdump would be my only hope to find out something otherwise
13:43
<alkisg>
vagrantc: the "bind" part? haha, if you allow me a --overwrite :P You'd do one uncommit and then pull :)
13:43
fiesh: try ssh user@server from screen_02
13:43
!screen_02
13:43
<ltsp`>
screen_02: To get a root shell on an Ubuntu thin client: https://help.ubuntu.com/community/UbuntuLTSP/ClientTroubleshooting#Using_a_shell_SCREEN
13:43
<vagrantc>
alkisg: i'd rather see a fixup commit :P
13:43
<fiesh>
normal ssh works just fine
13:44
<alkisg>
fiesh: replace "user" with an existing username, and leave "server" exactly as it is, don't put the server hostname there
13:44
<fiesh>
oh
13:44
<alkisg>
When you try that, tell me if you saw any warnings about keys
13:44
<fiesh>
where is "server" supposed to be defined, in /etc/hosts?
13:44
<alkisg>
vagrantc: haha ok, is that all?
13:44
fiesh: ltsp automatically puts it in /etc/hosts while the client boots
13:44
<fiesh>
ah, ok, thanks!
13:45
I'll try really quickly..
13:45
<vagrantc>
alkisg: there was an ltsp-config --overwrite patch phantomas proposed, i think ... i haven't checked it over yet
13:45
i'll also look through some of the other bugs, but otherwise am ready to commit
13:45
<alkisg>
OK that's a different issue, I meant with ltsp-update-image, e.g. bad english language in the comments or something...
13:45
<vagrantc>
alkisg: nothing that jumped out at me
13:45
<alkisg>
Cool
13:47
<vagrantc>
hrm. ltsp-config --overwrite works for me ...
13:47
<fiesh>
hmm ok, it tries to add the server ECDSA host key to .ssh/known_hosts
13:47
so I guess the key isn't known to the client, which is surprising to me, because the old (working) image's /etc and the new image's /etc don't really differ
13:47
<alkisg>
fiesh: now switch to vt7 and try to login again
13:48
<vagrantc>
ah, the --overwrite issue was specific to ltsp-config nbd-server
13:48
<fiesh>
in particular their /etc/ssh/ssh_known_hosts are the same
13:49
<alkisg>
vagrantc: pushed
13:50
<vagrantc>
alkisg: thanks.
13:50
<fiesh>
aha! fuck my life... there are two keys in ssh_known_hosts, one the ecdsa key, and the dss key -- and it seems the update from ssh 6.7 to 6.9 changed the behavior somehow to make it care about that, because it finds one conflicting and the other not
13:51
alkisg: thanks, now I can fix this
13:51
<alkisg>
fiesh: you're welcome
13:52
vagrantc: do you want us to have a quick look at the bugs list, in case we can solve something quickly before releasing?
13:53ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
13:55
<maldridge>
alkisg: not sure if you read all your scrollback, but was there a better way to solve dgroos tftp issue?
13:55
<vagrantc>
alkisg: it'd be good
13:55
https://bugs.launchpad.net/ltsp/+bug/1273680
13:55
one-liner patch
13:55
not sure i have a jetpipe setup to test...
13:56
https://bugs.launchpad.net/ltsp/+bug/1487333
13:56
<alkisg>
maldridge: ltsp-pnp uses dnsmasq for tftp, not tftpd-hpa, so they probably conflict with each other
13:56
<vagrantc>
the ltsp-config --overwrite nbd-server ... onyl concern is that it might needlessly overwrite /etc/nbd-server/config
13:57
<maldridge>
alkisg: given that he had no process running for tftp, is there something to configure dnsmasq automagically for ltsp and/or start it?
13:57
<vagrantc>
https://bugs.launchpad.net/ltsp/+bug/1483682
13:57
<alkisg>
maldridge: the instructions are in the ltsp-pnp page that dgroos had already followed
13:57
!ltsp-pnp
13:57
<ltsp`>
ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
13:57
<vagrantc>
poweroff/reboot issues in ubuntu
13:58
<alkisg>
maldridge: he probably missed doing the "disable ubuntu's internal dnsmasq" steps or something
13:58
vagrantc: that last one will be hard to solve
13:58
<maldridge>
ah
13:59
<alkisg>
vagrantc: I know exactly what needs to be done, and why it fails, but I don't know how to tell systemd to run the code at the appropriate point
13:59
<vagrantc>
alkisg: i'm fine with putting it off
13:59
<alkisg>
Cool, let's postpone that one
14:00
About jetpipe, I don't have a working setup either, let's ask in the channel... :)
14:00
GUYS IS SOMEONE USING PRINTER=xxx IN LTS.CONF, SO THAT HE CAN TEST A ONE-LINE PATCH? https://bugs.launchpad.net/ltsp/+bug/1273680
14:00
<vagrantc>
heh
14:01* alkisg feels his vocal chords stressed after so much yelling :P :D
14:01
<vagrantc>
well, as long as we can start jetpipe ... we can test if NMAP crashes it ...
14:01
i guess we can't test that it doesn't break printing, though
14:02* alkisg doesn't see anything urgent+easy in https://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;dist=unstable;archive=0;src=ltsp;repeatmerged=0 ...
14:03
<alkisg>
LP #816139 Kiosk mode fails when using generated xorg.conf ==> I think this one can be solved by using a relative path
14:03* vagrantc wonders how many of those "fix committed" bugs are released
14:04
<alkisg>
vagrantc, usually I'm changing those to "fix released" when you release them in debian
14:04
<vagrantc>
alkisg: relative to what
14:04
<alkisg>
Relative to PWD
14:05
I.e. instead of /path/to/xorg.conf, to use something like ../path/to/xorg.conf
14:05
<vagrantc>
yeah, i think X has silly ideas about the security of relative paths...
14:06
<alkisg>
Related, I think that xorg in debian runs as the user with kms drivers, and as root with non-kms ones
14:06
So to reproduce it one would need a kms driver
14:06
<vagrantc>
easy enough to test https://bugs.debian.org/785636
14:07
dbus dependency for SCREEN_XX to work
14:07
well, in the near future, X should run as a user in all cases ... seem to recall hearing about that at debconf
14:09
<alkisg>
That will break the kiosk login in all cases :D
14:09
<vagrantc>
wheee
14:11
https://bugs.launchpad.net/ltsp/+bug/1300728 some quoting issue in LDM?
14:11* alkisg was reading that one now...
14:12
<alkisg>
I think he just misunderstood the code
14:12
The unlocking is not working because of pam, not because of that
14:12
I'm marking it as invalid
14:13
...or ok as incomplete to be less rude :)
14:13mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
14:14championofcyrodi has joined IRC (championofcyrodi!~cott@50-205-35-98-static.hfc.comcastbusiness.net)
14:14AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-xuztxchcqskbmcsh)
14:16
<alkisg>
lauri: ping?
14:16
<vagrantc>
i'd say invalid, because it's actually a problem in another system entirely... maybe include a link to the LDM_HASH_PASS stuff or something?
14:17
<alkisg>
It won't solve the unlocking problem
14:17
I did mark it invalid though
14:17* alkisg checks the locale a-z issue, https://bugs.launchpad.net/ltsp/+bug/1491066
14:17
<vagrantc>
maybe it was a thin client?
14:18
i guess i'd better enable estonian on my LTSP server :)
14:18
<alkisg>
I think it's lightdm that unlocks the keyring, so using su or ssh won't cut it
14:20
We could probably fool pam_gnome_keyring so that it thinks that su/ssh is lightdm that calls it, but I don't think it's trivial
14:24
for SCRIPT in $(find -L $RCDIRS -type f -name "$SCRIPTS" -printf '%f\n' |
14:24
tr ' ' '\n' | egrep ^[0-9a-zA-Z_\-]*$ | sort -u)
14:24
Hmm that could sort them the wrong way, messing up everything...
14:27
Although the effect would be limited to X50-<here>, i.e. the possibly wrong sorting would come after the X50- part
14:28
<vagrantc>
we really need predictible sorting rules...
14:31
<alkisg>
Actually we shouldn't rely on sorting after the numeric part
14:32
We currently do, but I think that's bad, if one renames the script after the numeric part it can break it
14:32
<vagrantc>
how would you not rely on sorting?
14:33
<alkisg>
Example: /usr/share/ldm/rc.d/X50-generate-env needs to be ran after /usr/share/ldm/rc.d/X50-dmrc-processing
14:33
So it should be X51-generate-env instead
14:34
Saying "50" there should mean "I don't care if it runs in parallel with all the other 50's"
14:34
<vagrantc>
all of our code is sequential
14:35
what i don't want is to have to renumber the scripts all the time...
14:35
i guess there might be some cod ethat could run in parallel... but we're nowhere near implementing anything like that
14:36
<alkisg>
I think the numbers there are supposed to change when something relies on something else
14:38
<vagrantc>
if we're going to switch to dependency based, we should drop numbered ordering entirely
14:38
<alkisg>
No, I mean that the number ordering doesn't imply letter ordering too
14:38
Let me find a better example...
14:39
<vagrantc>
i think i understand what you're saying, it would just be a lot of code to implement
14:39
<alkisg>
No I'm not expressing it correctly, I don't want to run things in parallel (which would btw be just a couple of lines of code), I just want the numbers to mean something
14:40
<vagrantc>
well, i would rather avoid numbers entirely
14:40
if you're going to go to such lengths
14:40
they're a lazy way of defining code ordering, and prone to huge amounts of rewriting
14:41
<alkisg>
Suppose some software defines that other packages can drop configuration at /etc/program.d/
14:41
And it says, 20- is for packages, 50- for the sysadmin etc
14:42
Well, 20- means that you don't have any guarantee that your script will run before or after other scripts from other packages
14:42
but you do have a guarantee that it will run before the sysadmin scripts
14:42
<vagrantc>
sure
14:42
<alkisg>
That's what I'm trying to say that I like it when "numbers have a meaning, but letters not"
14:43
<vagrantc>
but such distinctions are silly ... if a sysadmin needs to run it during the "20" phase, then the whole thing breaks down
14:43
<alkisg>
So for us, X50 would be some specific step, but we wouldn't go to such lengths as to implement dependency checking...
14:44
<vagrantc>
for, say, configuration files, that can make sense, but for arbitrary hooks, not so much
14:45
<alkisg>
In the end what I'm asking is to increase the number when something significant happens, e.g. "passwd is ready" or "home/username is mounted"
14:45
Anyway, it's not a big deal. For now we do need letter ordering as well though.
14:46
So changing a-z to [:alpha:] isn't enough... we'd need to temporarily unset LANGUAGE, LC_ALL, and set LANG=C.UTF-8
14:46
RIght?
14:46
<vagrantc>
but the interoperability in those numbers can be nightmarish ... if ltsp and ltspfs have ldm hooks ... getting all the numbers to line up correctly can result in a domino effect
14:47
alkisg: forcing the locale to C.UTF-8 seems the sanest approach to me.
14:47
alkisg: or *maybe* C if there's some worry about backportability
14:47Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo)
14:47* vagrantc isn't sure how new C.UTF-8 is
14:47
<alkisg>
I think we tried it in wheezy and it was there
14:47
<vagrantc>
works for me, then.
14:51* vagrantc will commit the patch to ltsp-config but leaving nbd-server/config alone.
14:57
<stgraber>
alkisg: try to upload it, if it doesn't let you, let me know and I'll sponsor
14:58
<alkisg>
stgraber: can I file the SRU and also do the upload, or it'd better be done by 2 different people?
14:58
The verification step would be done by dgroos, not by me, of course...
14:58
<stgraber>
alkisg: you can, I usually do that when fixing my bugs :)
14:59
<alkisg>
Hehe, nice
14:59
<stgraber>
alkisg: even validation can be done by the uploader nowadays, otherwise most SRU would be stuck in -proposed :(
14:59
let me know when it's uploaded and I'll review it in the queue and if all good, let it into -proposed
14:59
<alkisg>
Thanks, I'll wait for a while in order to get more people motivated to do SRUs, but if noone does it, I'll do it myself later on
15:01* vagrantc is thinking about adding a recommends on dbus to resolve https://bugs.debian.org/785636
15:02
<vagrantc>
technically, maybe it needs a depends ... and ltsp-client/ldm will pull in dbus anyways...
15:03
<alkisg>
We don't actually need dbus though, do we?
15:03
<vagrantc>
for SCREEN_XX to work with systemd, we do in debian.
15:03
<alkisg>
Why?
15:03
<vagrantc>
that's a more complicated question
15:03
<alkisg>
Isn't that just a lame workaround that the bug reported found?
15:04
*reporter
15:04
<vagrantc>
i guess a better workaround would be to implement screen scripts as systemd service files...
15:04
<alkisg>
I think the problem there is that we don't support systemd properlyl
15:04
Right
15:05
The fact that installing dbus happens to mysteriously resolve the issue, doesn't sound like a good workaround...
15:06
So I'd say, leave the bug open and we'll re-check it after we properly support systemd. It's for ltsp-client-core without ltsp-client anyway, which isn't the default installation...
15:06
systemd supports services with instances, I think that's what we need for ltsp screens
15:07
Those will override the getty instances, so the problem will be solved properly
15:07
(we could also completely deprecate SCREEN_02=shell completely and replace it with ROOT_PASSWORD_HASH=xxx")
15:11
<vagrantc>
alright, will keep the workaround out of the code, it's a smple workaround documented in the bug itself
15:13khildin has left IRC (khildin!~khildin@ip-213-49-84-113.dsl.scarlet.be, Ping timeout: 265 seconds)
15:25khildin has joined IRC (khildin!~khildin@ip-80-236-242-25.dsl.scarlet.be)
15:50Faith has joined IRC (Faith!~paty@unaffiliated/faith)
16:20geekgirl has joined IRC (geekgirl!ce4a3d81@gateway/web/freenode/ip.206.74.61.129)
16:41
<alkisg>
vagrantc: I pushed fixes for LP #1491066 but I was in a bit of a hurry, so they need a review...
16:41
both ltsp + ldm
16:41* alkisg waves
16:41alkisg is now known as work_alkisg
16:42* vagrantc will look
17:02Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo)
17:14geekgirl has left IRC (geekgirl!ce4a3d81@gateway/web/freenode/ip.206.74.61.129, Ping timeout: 246 seconds)
18:21F-GT has left IRC (F-GT!~phantom@ppp121-44-204-54.lns20.syd7.internode.on.net, Ping timeout: 250 seconds)
18:21F-GT has joined IRC (F-GT!~phantom@ppp121-44-204-54.lns20.syd7.internode.on.net)
19:09
<vagrantc>
work_alkisg: any reason why cleanup.d/50-update-kernels only runs update-kernels if /boot/pxelinux.cfg doesn't exist?
19:09
work_alkisg: seems like it should be safe to run in either case.
19:18telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
19:20telex has joined IRC (telex!teletype@freeshell.de)
19:30khildin has left IRC (khildin!~khildin@ip-80-236-242-25.dsl.scarlet.be, Ping timeout: 244 seconds)
19:35
<vagrantc>
after applying phantomas's patch, i get noise every time i run ltsp-update-image about not overwriting the nbd config files...
19:37TheProf has joined IRC (TheProf!~TheProf@76-10-176-231.dsl.teksavvy.com)
19:41work_alkisg is now known as alkisg
19:42
<alkisg>
vagrantc: about 50-update-kernels, that file should be deleted completely
19:42
I only wrote that because at the time you refused to do it on postinst
19:42
<vagrantc>
i don't think we're doing it on postinst yet...
19:43
<alkisg>
Right, I tried to convince you a couple times but we didn't reach a decision :)
19:43
<vagrantc>
introduce some more bugs to convince me :P
19:44
<alkisg>
Hehe
19:44
<vagrantc>
honestly, i guess we should just do it from ltsp-client-core.postinst
19:44
<alkisg>
Yup!!!! Finally!!! :)
19:44
<vagrantc>
because how it happens now depends on if ltsp-client-core was installed before or after linux-image-*
19:45
which is stupid and confusing
19:45
though i really did like having it only in the image file...
19:45
<alkisg>
Yup. But above that, cleanup is for cleaning up things, not for running update-kernels
19:46
Having it only in the image file is a big problem in some cases,
19:46
e.g. when ltsp-update-image -c path/to/vdi is used instead of /
19:46
...at that example, I may want to directly serve the .vdi instead of cleaning it up...
19:46
<vagrantc>
this feature i've been hearing about for years... :)
19:47
<alkisg>
Serving a raw btrfs image doesn't need any new code....
19:47
(btrfs for compression, it could be ext4 too...)
19:48
ltsp-update-kernels currently will read pxelinux.cfg frominside it
19:48
I wrote that part of the code years ago, it's been functional ever since...
20:12
pumpkin time :)
20:13alkisg is now known as work_alkisg
20:15* vagrantc waves
21:07TheProf has left IRC (TheProf!~TheProf@76-10-176-231.dsl.teksavvy.com)
21:10ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
21:14vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Ping timeout: 260 seconds)
21:45NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, Ping timeout: 246 seconds)
22:11Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Read error: No route to host)
22:21dgroos has joined IRC (dgroos!~dgroos@vpn.mpls.k12.mn.us)
22:22ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
22:46dgroos has left IRC (dgroos!~dgroos@vpn.mpls.k12.mn.us, Quit: dgroos)
23:22vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)