|00:01||alkisg has joined #ltsp|
|00:52||Faithful has quit IRC|
|01:17||Faithful has joined #ltsp|
|01:54||gnunux has joined #ltsp|
|02:00||cyberorg has quit IRC|
|02:17||mikkel has joined #ltsp|
|02:49||Selveste1_ has quit IRC|
|03:18||Selveste1_ has joined #ltsp|
|03:19||Selveste1_ has quit IRC|
|03:19||Selveste1 has joined #ltsp|
|03:34||Selveste1_ has joined #ltsp|
|03:34||Selveste1 has quit IRC|
stgraber: cisco routers do not work with clientid='', i.e. they don't send a dhcp offer so the clients won't boot
Are you sure that's the only way to prevent dhcp3-server from needing 2 IPs per client?
|04:41||highvoltage has joined #ltsp|
|05:03||highvoltage has quit IRC|
|05:05||highvoltage has joined #ltsp|
stgraber: I tested here locally with dhcp3-server and *without* sending a clientid (i.e. the default udhcpc behavior) and my client used the same IP address that it had in PXE...
So I think we should ditch the clientid hack altogether...
|05:17||johnny has joined #ltsp|
|05:21||klausade has joined #ltsp|
|05:28||cyberorg has joined #ltsp|
|05:36||gnunux has quit IRC|
Uhm, and maybe we can send a patch for udhcpc so that it doesn't send a clientid at all (not send an empty one)
|06:03||hersonls has joined #ltsp|
|06:24||Selveste1_ has quit IRC|
|06:28||pmatulis has joined #ltsp|
|06:34||Barbosa has joined #ltsp|
|06:35||ogra_cmpc has quit IRC|
|06:42||scottmaccal has joined #ltsp|
|07:07||gnunux has joined #ltsp|
|07:18||Selveste1_ has joined #ltsp|
|07:29||Selveste1_ has quit IRC|
|07:30||Selveste1_ has joined #ltsp|
|07:34||scottmaccal has quit IRC|
|07:34||Selveste1__ has joined #ltsp|
|07:35||Selveste1_ has quit IRC|
|07:35||ogra has quit IRC|
|07:36||Faithful has quit IRC|
|07:36||ogra has joined #ltsp|
|07:37||alkisg has quit IRC|
|07:47||Barbosa has quit IRC|
|08:08||alkisg has joined #ltsp|
|08:16||Selveste1__ has quit IRC|
|08:16||Selveste1__ has joined #ltsp|
|08:21||Gadi has joined #ltsp|
|08:22||komunista has joined #ltsp|
|08:23||Selveste1__ has quit IRC|
|08:30||vbundi has quit IRC|
|08:36||komunista has quit IRC|
|08:38||Selveste1__ has joined #ltsp|
|08:39||ogra_cmpc has joined #ltsp|
|08:45||Nikratio has joined #ltsp|
|08:45||komunista has joined #ltsp|
On my Ubuntu karmic ltsp clients, the /etc/hosts file is always garbled. After the server ip, I have about 30 "-f\n" entries, before the final "-f server" line. If I restart /etc/init.d/ltsp-client-setup, the file is generated correctly. Anyone has an idea where to look for the problem?
|08:51||yodan has joined #ltsp|
Nikratio: can you try to specify SERVER=ip in lts.conf?
I think that bug was solved some months ago, but I don't remember the exact details
Which BTS was it in?
Bug Tracking System
So I can look it up
I'm not sure if it was in any BTS, but if it was, it was in launchpad
|08:54||Selveste1__ has quit IRC|
We may have fixed it without filing any bug reports, though
ah, ok. I'll try the lts.conf change then
|08:56||vmlintu has joined #ltsp|
yes, that fixed it
OK, don't bother with it anymore, it was fixed for Lucid (even though I don't remember the commit #)
great, thanks again
|09:05||Nikratio has left #ltsp|
|09:06||pmatulis has quit IRC|
|09:10||pmatulis has joined #ltsp|
|09:22||Faithful has joined #ltsp|
|09:24||alkisg has quit IRC|
|09:25||vmlintu has quit IRC|
|09:26||alkisg has joined #ltsp|
|09:30||vmlintu has joined #ltsp|
|09:35||pmatulis has quit IRC|
|09:36||mikkel has quit IRC|
|09:37||pmatulis has joined #ltsp|
|09:37||mischko has joined #ltsp|
|09:38||bobby_C has joined #ltsp|
|10:18||lipinski has joined #ltsp|
How can I troubleshoot a hanging client? It starts up fine, and I can log in, start applications, but eventually it hangs and the screen is semi-frozen. Mouse still moves, but can't click on anything or do anything.
Looking for some insight on how to start troubleshooting....
Does it answer to ping?
|10:24||yodan has quit IRC|
I'm trying a new test where I start up firefox and just let it sit at the home page. I'm thinking maybe Facebook or some page like that is causing a problem.
I just don't know how to start troubleshooting it. Where would logs be? Do I have to add sshd to the client to be able to get in and check things out? , etc..?
|10:26||thunsucker has joined #ltsp|
Having sshd on the client helps a lot
To get logs, you have to enable remote logging on the server. Which distro are you running?
|10:33||pmatulis has quit IRC|
|10:33||pmatulis has joined #ltsp|
|10:36||vagrantc has joined #ltsp|
|10:44||Selveste1__ has joined #ltsp|
|10:45||gnunux has quit IRC|
|10:46||pmatulis has quit IRC|
|10:46||pmatulis has joined #ltsp|
vmlintu: Sorry, got pulled away... I'm currently running Ubuntu 9.10. I'm going to be upgrading to 10.04 LTS in the next week or so (maybe Beta 2, maybe wait for official release)..
So, I really am trying to "band-aid" this hang problem to late me until I can get the server on 10.04
Try first installing sshd in the chroot
Once you can login to the client, try running at least top or some similar tool to see if there's something unusual when it freezes
lipinski: how much memory does the client have?
I haven't run 9.10 in production so I cannot say much about its quirks
lipinski: is it all your clients or just a few? if it's more than 1 how much memory does the server have and how many clients you running
i have an issue right now at one of my installs, the server doesn't have enough memory (i'm guessing) because sound is choppy on when using the rdesktop script
i connect from a ubuntu laptop to the same terminal servers and all is well
but if less than 5 clients are on, there are no sound issues
thunsucker: rdesktop from a launcher on the linux desktop or as a screen script?
|11:22||epaphus has joined #ltsp|
lipinski: I have one clinet with the same problem
and it seems to graphic card related
when I kill frozen GUI apps, the client works...
it has problem for example with wbar, lxsession-logout and sometime with other apps too
no messages in any log, no problem by ssh to client... only apps do not works...
|11:37||staffencasa has joined #ltsp|
|11:40||emence has quit IRC|
The client was working fine for a long time. I had server problems, so upgraded. Server is now running an Intel i3 with a new MB and 4GB RAM. I have only 1 client.
The primary use of the client if for Firefox. If I kill Firefox process on the server, the client "unfreezes".
How much ram does the client have?
I think only 256MB.
and, is firefox running as a localapp?
Any other localapps? 256 should be plenty for only thin client use...
no localapps at all. This is a "straightforward" ltsp install.
client is a dumb as can be :)
Hmmm and if you kill firefox and it unfreezes, then it shouldn't be ram related
alkisg: I rebuild the image and that's how I fixed the eth problem I was having the other evening (when you were helping me)..
Now, client runs great - except for this annoying hang.
|11:53||mikeshultz has joined #ltsp|
Let me try a different app, i.e., OpenOffice or something and see if that hangs.
|11:54||sahil has joined #ltsp|
After adding local firefox on ubuntu 9.10 and doing the thin-client nat setup, my clients will boot and display the login manager but I am unable to login, what gives?
It's almost like it's causing the entire desktop on the client to hang. mouse still responds, but I can't click on anything.
sahil: try `sudo ltsp-update-sshkeys && sudo ltsp-update-image`
|11:56||Faithful has quit IRC|
I never looking into LTSP processes before:
7028 7027 0 08:16 pts/0 00:00:00 bash -c echo LTSPROCKS; /bin/sh -
|12:02||sahil has quit IRC|
|12:13||Selveste1___ has joined #ltsp|
|12:14||Selveste1__ has quit IRC|
|12:18||GodFather has joined #ltsp|
lipinski: I have 15 the same clients and only one go to this problem
komunista: odd. I'm trying a different Application besides firefox now. Next step would be to use sshd and see if I can tell what's going on on the client itself - maybe a stray process or something...
alkisg, ever heard of anything like this in karmic? try to play a sound and the volume just starts lowering itself until it is completely quiet?
it happens with flash player, exaile, and mplayer
or anywhere even..
not just karmic :)
does pulseaudio auto lower the volume on overdrive?
i have no idea
i have yet to see an overdrive setting :)
Karmic allows you to overdrive your speakers... send more than 100% to them
(in gnome-mixer how's that applet called)\
gnome-mixer ? or gnome-alsamixer ?
lipinski: I find no solution :-(
I have dropbear in client's chroot, but when it freeze, I see nothing wrong on it...
|12:27||ogra_cmpc has quit IRC|
guess that doesn't work over ssh -X :)
hmm.. i'm still getting freezes on my fat client setup
|12:30||ogra_cmpc has joined #ltsp|
even after nbd swap seems to be on
it shows swap on the terminal
but it doesn't seem to get used
swapping is broken in karmic
It was fixed 1-2 months ago
broken in what way
i think i had fixed it
by upgrading to stgraber-ppa
some swap shows up when i run top on the fat client terminal
Is that compcache?
|12:32||slidesinger has quit IRC|
But if you upgraded AND updated the initramfs, yeah, it should be fixed
hmm.. not sure
updated the initramfs how?
i didn't manually update the initramfs
sudo chroot /opt/ltsp/i386 update-initramfs -u && sudo ltsp-update-kernels
ah.. and that doesn't need the image updated.. because the kernel is already gotten
i confused myself for a second
the problem with the sound just started happening
i see no reason why..
none of the sliders move
in any of the volume control apps
i think it might be the amp itself.. altho that would be weird
we have it hooked up to 1/8 inch jack => rca y cable
Well you know who's the sound expert here... you should ask him :)
|12:53||GodFather has quit IRC|
|12:59||highvoltage has quit IRC|
|13:05||mischko has quit IRC|
|13:05||GodFather has joined #ltsp|
|13:09||jammcq has joined #ltsp|
|13:21||GodFather has quit IRC|
|13:33||Lns has joined #ltsp|
|13:34||GodFather has joined #ltsp|
|13:35||rjune has joined #ltsp|
|13:36||C_Tek has joined #ltsp|
|13:37||highvoltage has joined #ltsp|
|13:39||asmok has joined #ltsp|
ltsp-cluster works just fine in karmic
but in lucid ltsp-cluster-control admin page is empty
here is bug report: https://bugs.launchpad.net/ltsp-cluster/+bug/563263
any fix, if it is php parse problem?
Gadi: ^^^ You are being summoned ;)
not Gadi, but stgraber
gadi, graber, potato, ...
|13:43||lipinski has left #ltsp|
I did a workshop few days ago about ltsp-cluster/karmic - sorry for finnish, once again, but pics are universal language ;-) http://blog.ubuntu-fi.org/2010/nurmon-kouluihin-ltsp-klusteri/
anyone played with ltsp-cluster in lucid?
cyberorg had the same problem in 6 Oct 2009 (with the T_GOTO syntax error), maybe he found a solution for it?
|13:47||GodFather has quit IRC|
alkisg: bug report about that?
I don't think so... you can see the ltsp logs though (see the topic for the link)
I'll try to find
There is no archive for 2009 or 2008, just 2007, 2006?
I wonder how mess it is if I just copy whole ltsp-cluster-conrol php dir from karmic to the lucid?
I wonder why this bug is back when karmic is just ok... only stephanie can handle this, i think or someone from revolution linux...
|13:59||GodFather has joined #ltsp|
stephanie marco is great singer, stephane graber can handle this one :-)
let's leave that for stephane, he will read that bug report
asmok: we didn't update the package in lucid at all so installing karmic's won't work
I'm guessing that the control center simply doesn't work with 5.3
so it's better stick with karmic?
vagrantc: thanks for pointing to lxsession with thin client shutdown, it is very nice function ;-)
|14:18||Alex227 has joined #ltsp|
asmok: can you try applying that patch to /usr/share/ltsp-cluster-control/
asmok: if it works, I'll upload that to lucid
|14:19||Alex227 has left #ltsp|
|14:19||staffencasa has quit IRC|
alkisg: did ubuntu get the patch into gnome-session to support LTSP logouts?
er, LTSP shutdown/reboot
vagrantc: nope :(
They thought it was too much of a hack
I'll try that, first I'll have to remember how to patch, it's really been some time when dealing patch file ;-) be patient, i start now ;-)
alkisg: the whole concept?
We need to tell sbalneav to get it upstream to gnome :)
i don't think that's gonna happen until you can pass it down via dbus to the client
vagrantc: I'm not sure if it was the xprop setting that bothered them or the code path where the patch was applied, the maintainer didn't have much time to talk so...
it always always be hacky trying to fix it in that way
johnny: do you think it's easier to send upstream dbus patches than gnome-session patches?
asmok: cd /usr/share/ltsp-cluster-control && sudo patch -p0 < path/to/the/patch
alkisg, i don't think the solution would be acceptable upstream is all
by gnome folks
it's too specific to one situation
grr. more dbus-daemon. I'd be happier if that thing didn't lock up so frequently
johnny: so then what do you propose? To maintain an ltsp-specific branch of dbus?
|14:28||GodFather has quit IRC|
it just seems more likely that a dbus proxy or router would be more generic and useful for ohter things
unlike the specific hacky way of logging out
stgraber: you are hero of the day ;-)
asmok: it works correctly ?
atching file Admin/index.php
patching file Admin/util/functions.php
patching file Admin/util/setup.php
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 198 with fuzz 2.
good, releasing a new version + uploading to lucid then
|14:34||staffencasa has joined #ltsp|
there are still messages in apache2's error.log, but admin page works now, this kind of
vagrantc: one cleaner thing to propose is to have the applet reboot/shutdown entries hidden when the CK session is not active (e.g. in ltsp and nx sessions). That wouldn't be hackish at all. We'd lose the ability to shutdown from the menus, but it'd at least make sense.
alkisg: i thought that was already implemented in older versions?
vagrantc: yes there was a patch in fusa for that, but fusa got dropped and the patch wasn't transfered to the new indicator applet
vagrantc: but this wouldn't be an ltsp - specific patch; it would check CK instead
asmok: uploaded to lucid
asmok: seems like php 5.3 is quite verbose ;)
I won't spend too much time making it happy as we are simply rewritting everything at the moment ...
good to know
i finish now my lucid setup and them boot first test tc
|14:41||GodFather has joined #ltsp|
stgraber: HP Mini 2133 as a TC: http://ltsp.pastebin.com/WE1v7rHi
lucid works great now, only one app server ;-D
and you got that super slick and fast flickerless boot ?
|14:54||GodFather has quit IRC|
stgraber: wow that sounds nice
thunsucker: here it's basically the pxelinux loading sequence, then a splash for 10s without any flicker/black screen, then directly the login prompt
|14:56||pmatulis has quit IRC|
i have lots of t5125/t5135, i hope i got them to work too, there is something bad after login, but now i can test them with lucid - t5125 drops after login to the login screen again, let's see if i find something. they work with hardy just fine...
i now boot t5125...
the oldest HP I have here is a 5735
and I have some 5745
I noticed the same problem yesterday with lucid - after login my via based thin client just went back to login screen
After I set LDM_DIRECTX=false and X_COLOR_DEPTH=16, it started working ok, so I didn't investigate it further
have you disabled compiz?
Removing compiz didn't help with my box
It's some via based box with 1GHz CPU and 512Mb of memory
vmlintu: i try your setup too
sorry, my mind is mixed up
LDM_DIRECTX=Y and X_COLOR_DEPTH=16 were the working ones
|15:11||C_Tek has quit IRC|
asmok: for some clients, disabling compiz helps:
alkisg: "compiz" :: if compiz is giving you problems, one way to disable it for all users is: sudo gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type string --set /desktop/gnome/session/required_components/windowmanager metacity
yes i did it, it is in my/stephane howto ;-) wai a minute, some good news coming ;-)
t5125 (september 2006 model) works now! http://ltsp.pastebin.com/nsRqfq8t
|15:24||staffencasa has quit IRC|
asmok: these are all via chipsets?
it is awful slow to boot, but then no problem. I once again own a beer to stephane and veli-matti ;-) I think we can do something for that in Tampere ;-D right ;-)
(using openchrome driver)?
I was using the default driver for the box and it has been openchrome at least until now. I actually didn't even check that yesterday..
here is something from ltsp-cluster check: http://ltsp.pastebin.com/nNUF3ufq
yeah, I find the openchrome driver to be lacking in the "sane defaults" department
|15:31||Selveste1___ has quit IRC|
The same box started using the internal speaker for audio now..
this is what ltsp-cluster says before loginvideo: apollo cle266 integrated castlerock graphics (rev 03)
|15:33||staffencasa has joined #ltsp|
yes sound work for t5125
|15:34||ogra_cmpc has quit IRC|
this was really good session, now i really can start to plan how to turn my hardy dhcp-failover setup to the ltsp-cluster setup, i got over 100 t5125/t5135 at my daughter's school. thank you everybody and good night!
|15:38||asmok has left #ltsp|
|15:46||Selveste1___ has joined #ltsp|
|15:47||ogra_cmpc has joined #ltsp|
|16:02||hersonls has quit IRC|
|16:20||thunsucker has left #ltsp|
hrm. gpxe and recent versions of qemu don't play well together...
tho, they are prolly worth a lot of points in the game of Scrabble
see, now isn't that all that matters?
seems like ltsp-update-sshkeys is creating an empty file for me... but when i re-run it, it works fine.
ssh running the first time?
ah, yes. sshd is running.
not with legs
Gadi: when you re-wrote it, does it not use the local files at all? i.e. it always scans the network?
I believe so
|16:33||* Gadi can be so presumptuous|
lets have a look-see
reading directly from the files themselves is a lot safer...
also, doesn't require the local machine to have sshd running
also got some reports that it was taking an inordinate amount of time at boot
ok ok ok
is it too late to fix? is the party over?
|16:35||* vagrantc plays a kazoo|
what? we're not at a party?
|16:35||* Gadi puts his pants back on|
that might be a good slogan... "SSH: Don't get caught with your pants down."
ltspfs seems completely broken in testing :(
ah, false alarm... i haven't tested these other files yet...
vagrantc: fixed, commited, pushed
oh, and test while singing "pants on the ground" to Lns
if you could guage the skills of an open source programmer to the personality quirks demonstrated on IRC...hahaha
gadi, you'd be a millionaire
|16:58||Gadi has left #ltsp|
just like gadi to fix something and disappear :)
at least he took his pants with him.
vagrantc: are you going to debconf?
seems to work
highvoltage: yes, you?
highvoltage: we met in sevilla years back, no?
vagrantc: yep, looking forward to seeing some familiar people and meeting new debian folk
vagrantc: yes, indeed
vagrantc: you are probably more memorable than I am, I thought you were interesting :)
i'm trying to concince some LTSP folks to crash debconf to do some ltsp hacking
what's next on the line for ltsp?
that would be great. stgraber is also going
|17:09||komunista has quit IRC|
stgraber: ah, didn't know you were going! :)
|17:35||Lns has quit IRC|
|17:36||Lns has joined #ltsp|
|17:40||Lns has quit IRC|
|17:43||jammcq has quit IRC|
|17:48||alkisg has quit IRC|
|17:59||bobby_C has quit IRC|
|18:00||mikeshultz has quit IRC|
|18:07||mischko has joined #ltsp|
|18:10||Faithful has joined #ltsp|
vagrantc: it's only 5-6 hours away from here ;)
doh, would have liked that revert two weeks before ... now I'm starting sshd in d-i just to have ssh-keyscan do its magic :)
will be great to drop that in Maverick
stgraber: i'm sure you'e busy as all get-out right now, but was wondering if you might get a chance to update the ltsp-trunk/fr.po soonish?
stgraber: thanks :)
i know folks have tried in the past, but i wonder if we could ever get a signle .po file for each language in ldm...
|18:35||litlebuda has joined #ltsp|
|18:35||mischko has quit IRC|
|18:38||NeonLich1 has quit IRC|
|18:44||Faithful has quit IRC|
|18:46||staffencasa has quit IRC|
|18:52||NeonLicht has joined #ltsp|
|19:01||egghead has joined #ltsp|
running ubuntu 9.10, using ltsp on a 64bit machine, tring to boot i386 clients (using usb drive) but get i think the i386 client trys to load in from /opt/ltsp/images/amd64 instead of the /opt/ltsp/images/i386 image, any one know if there is a config file to change the boot image for different clients?
|19:04||epaphus has quit IRC|
egghead, do you have both kinds of clients egghead ?
or just i386?
johnny, yes, both
is there a config file for ltsp that points to /opt/ltsp/images?
or maybe for tfpboot?
|19:18||rjune has quit IRC|
i think problem is i boot (from usb drive) i386 kernel and then it trys to load the amd64 image
but cant figure out how to change the boot image dir for i386 clients
first you have to install the image
ltsp-build-client --arch i386
i did that
|19:24||rjune has joined #ltsp|
|19:43||robbie_ has joined #ltsp|
|19:52||waldo323 has joined #ltsp|
|20:10||Faithful has joined #ltsp|
|20:12||slidesinger has joined #ltsp|
vagrantc: the result of g_strconcat should be freed.
so do this instead:
Ryan52: and you say you don't contribute much anymore :)
gchar * foo = g_strconcat("<b>", _("Verifying password. Please wait."), "</b>", NULL);
// I missed a semi colon on the set_message line
Ryan52: gchar on the same line? or with the other gchar at the top of the function?
still having sound problems @ my store
no, guess not. do it like sec.
gchar * foo;
the volume starts at a normal level
foo = g_strconcat(.........);
|20:24||epaphus has joined #ltsp|
and then just gets quieter until tis gone
|20:24||* Ryan52 is being rushed to leave by his dad...so cya.|
|20:26||egghead has left #ltsp|
|20:51||robbie_ has quit IRC|
|21:07||epaphus has quit IRC|
|21:09||waldo323 has quit IRC|
|21:11||pem725 has quit IRC|
|21:35||try2free has joined #ltsp|
|21:53||try2free has quit IRC|
hmmm... the LDM_LOGIN_TIMEOUT doesn't seem to be working...
ah, it apparently needs to work in conjunction with LDM_GUESTLOGIN
|21:59||* vagrantc is playing with ldm to randomly select a supported language to display and autologin/autologout|
seems to be biased towards polish.
it would be tricky to implement... but would be cool if the language selection could also change the greeter language
sounds tricky to implement (on the fly gettext language change)
a fairly brutal way would be to re-exec the greeter
but GDM changes the language when you select a different langauge, no?
well, ldm has decent support for 17 languages :)
i haven't done a very good job of asking folks to translate the rc.d and ltsp-cluster-info bits... the tools i use to send out the translations don't support multiple po files (as far as i know), and it would be confusing to send out multiple translation requests for a single package...
vagrantc: that sounds like a fun project.
Ryan52: oh, sparked your interest, have i? :)
Ryan52: changing the ldm UI to a new locale if the user selects a new locale?
ideally checking if it's a valid locale on the local system...
doesn't hurt to try it anyway...it'll just fall back to the original string.
hm...one problem, tho. some of the text is translated on the server side by the ssh daemon.
Ryan52: none of that is translated anymore
any messages are just relayed through
they are translated if the server's default language is a different language.
because then sshd would translate it.
|22:24||* vagrantc doesn't see how that matters|
Ryan52: regarding the fallback, if the default locale != C and they try to switch to an unsupported locale, then it will fall back to C ...
if the servers language is spanish, and the ldm user selects french, half the interface would be in french and half in spanish.
and if the ldm translation for french isn't complete, some of the interface may even be english.
incomplete translations aren't anything we can do anything special about
Ryan52: but the server/thin-client language differences are already handled... it sets the locale variables when logging in via ssh...
that doesn't affect the strings relayed from sshd, tho.
no worse off than it is now.
in any case :)
i'm not sure it ignores the locale variables...
currently, we can set the locale for the LDM UI with standard environment variables LANG, LC_ALL, etc. and LDM_LANGUAGE sets the user's locale for the logged in session, or alternately by selecting the language from the menu.,
but if the menu selection could both set the LDM UI and the user's soon-to-be logged in session, that would be nice.
|22:32||* vagrantc wonders how GDM or KDM do it|
it's really easy.
well then... :)
you just need to change the locale and set all of the strings again.
changing the locale is simple, generate_locale_list.py does it for example.
|22:43||try2free has joined #ltsp|
hm, GDM just restarts.
well that's kind of cheating. :P
|22:49||Faithful has quit IRC|
|22:55||alkisg has joined #ltsp|
|23:01||rjune has quit IRC|
stgraber: turns out that we already have the latest udhcp version in Lucid, it's embedded in busybox!
So we can actually drop the udhcpc dependency, stop installing udhcpc, and just use busybox udhcpc -C
|23:03||rjune has joined #ltsp|
|23:04||try2free has left #ltsp|
|23:07||Faithful has joined #ltsp|
|23:09||rjune has quit IRC|
Dah no there are 2 busybox versions, busybox-static has it, while busybox-initramfs doesn't. So maybe we should file a bug against busybox-initramfs and ask that they include udhcpc in their Makefile.
|23:16||epaphus has joined #ltsp|
|23:21||rjune has joined #ltsp|
|23:24||alkisg has quit IRC|
|23:53||try2free has joined #ltsp|
|23:54||vagrantc has quit IRC|