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


Channel log from 11 February 2008   (all times are UTC)

00:20achandrashekar_ has joined #ltsp
00:22
<achandrashekar_>
Hello. I have been researching some solutions for a lab setup. I came across setting up two ltsp servers of which one has ldap server installed. Past that I am confused as to "How" it works. From a client perspective that is. Can some one clarify the architecture?
00:24
<FuriousGeorge>
can anyone recommend a thin client that mounts elegantly onto an LCD?
00:25
achandrashekar_: im just researching too, but it appears ltsp is a way of managing chroot environments for diskless clients
00:25
they boot up off the network, and find their /boot and /root there
00:25
they just run X
00:26
<johnny>
yes
00:26
ldap would be for the servers to share user accounts off of
00:26
<achandrashekar_>
the out of the box ltsp part is not an issue..considering id use something like edubuntu
00:26
but the multiserver setup which i have been researching all day points me to ldap
00:26
instead of nis
00:26
<johnny>
use ldap
00:26
yeah
00:26
there are docs
00:27
you don't need any ltsp specific setup afaik
00:27
<achandrashekar_>
the docs!--are here - ? http://www.ltsp.org/twiki/bin/view/Ltsp/LDAP?
00:28
i followed as best as I could but Im really confused about the actual setup
00:29
<johnny>
what do you mean?
00:29
<achandrashekar_>
i planned on using one ltsp server with ldap on it. (i suppose ill need a client on the same box to authenticate with) and then the second box with ltsp authenticating to the first?
00:29
<johnny>
yes
00:29
<achandrashekar_>
how does the client know which box to get dhcp info? and tftp boot stuff to boot up?
00:30
<johnny>
it gets it from the box it is connected to
00:30
or are you not segmenting it?
00:30
<achandrashekar_>
not segmenting
00:30
ie..i planned to connect to same lan
00:31
because "i thought" that'd be how it works..but i must be mistaken by the setup
00:31
is the setup /doc the right one i was looking at or is there a clearer one?
00:31
<johnny>
well that ldap stuff doesnt have much to o with it
00:31
this is for after
00:31
<achandrashekar_>
i think im just confusing myself.....as usual :)
00:32
<johnny>
that's only for auth i think
00:32
after everything is already working
00:32
<achandrashekar_>
johnny would you mind a walk through or point me in the right direction for the setup...somewhere i am messing up my own perceived logic of how things should be hooked up.
00:32
<johnny>
i've never done anything so intensive
00:32
my setup is only 4 pcs
00:33
and even at the 2nd location, i'm maxing out at 20
00:33
<achandrashekar_>
i see.
00:33
<johnny>
i'm just going by what i've read
00:33
<FuriousGeorge>
johnny: must it be dhcp / ldap? if you always wanted the same clients to boot off the same server couldnt you do a static netboot
00:33
<johnny>
you could do static
00:33
but at the very least it seems like you could do the assigning in the dhcp server
00:34
<FuriousGeorge>
johnny: assigning the boot by mac address to correct pxe server?
00:34
<achandrashekar_>
ive read across to distinct websites where they have these large environments with ltsp with 4 servers.
00:34
<johnny>
ie: give all in range of 1-20 one tftp file
00:34
err one nbi.image
00:34
<FuriousGeorge>
gotcha
00:34
<johnny>
that's one way
00:34
<achandrashekar_>
i see.
00:34
<johnny>
that way you still take advantage of dhcp
00:35
<achandrashekar_>
okay.
00:35
<johnny>
i'm not sure if that is the recommended way
00:35
<achandrashekar_>
i was really confused as to how.
00:35
<johnny>
you can prolly minimize it to only serve one instance of the chroot across
00:35
<achandrashekar_>
on the dhcp server...i am aware of "next server" parameter...so i thought that is what is necessary
00:36
<FuriousGeorge>
achandrashekar_: what is it you arent understanding? the client pc doesnt have a disk, so it needs to find its data on the network. its a diskless x terminal with a nice administrative system by ltsp (at least thats how i think of it, i could be wrong)
00:36
<achandrashekar_>
i get that...
00:36
<johnny>
FuriousGeorge, i think he's wondering how they know to talk to one server vs another
00:36
<FuriousGeorge>
ahh
00:36
<achandrashekar_>
yes
00:36
that is it
00:36
<johnny>
there is no one way
00:37
the way i suggested is possible
00:37
and then nfs mounting homes
00:37
or you could setup one of those clustering file systems :)
00:38
<achandrashekar_>
for example if you have 4 boxes with ltsp, where one is an LDAP master, the others are clients and all authenticate with the LDAP master, then in theory or at least what i have read, the client box can boot of any of the 4 boxes. But yes..johnny's last post is the clue to all of this.
00:38
<johnny>
there is the LTS_SERVER parameter in lts.conf
00:38
<achandrashekar_>
because i get that using nfs as well, indicates mounting of the home drives
00:38
so in essence a combo of ltsp,nfs, and ldap
00:38
<johnny>
they will have to mount it in the computer they are on
00:39
dhcp really plays a major part in this..
00:39
dont forget it :)
00:40
<achandrashekar_>
yeah..
00:40
so ltsp setup on all of the servers requires dhcp...and hence that is the perplexing part. and all that i can figure out is that it uses some sort of "next server" parameter.
00:40
<johnny>
oh wait.. i wanted to clarify what you said before
00:40
<achandrashekar_>
or something.
00:40
<johnny>
to make sure we are square
00:41
you said "...then in theory or at least what i have read, the client box can boot of any of the 4 boxes..."
00:41
<achandrashekar_>
yes...is that not correct?
00:41
<johnny>
the user can login to any of those boxes
00:41
<FuriousGeorge>
since we are on the subject, i tend to install ipcop for my clients, which allows you to pass custom parameters to the dhcp server when you set up a fixed lease.... that would probably come in handy for ltsp, no?
00:42
<johnny>
the boxes will prolly always use the same serve
00:42
server*
00:42
ie: it won't use one of the 4
00:42
err
00:42
it will use a specific one of the 4
00:43
<achandrashekar_>
johnny: interesting..so one box actually produces the "boot" sequence and produces a login screen on the client. However, when actually logging in it logs into one of the 4?
00:43
and then authenticates to master?
00:44
<johnny>
and then prolly mounts the /home
00:44
from one of the others
00:45
how are you going to distribute home directories/
00:45
if you had a clustering fs , it wouldn't really matter i suppose
00:46
i don't know what's working well yet on that front tho
00:46
<achandrashekar_>
I see.
00:47
<johnny>
i'd love to do a job that involved deploying ltsp
00:48
the one deployment i have, is at our coffeeshop
00:48
<achandrashekar_>
cool! - i did a search against what you described and I found this! - http://doc.ubuntu.com/edubuntu/edubuntu/handbook/C/multiple-server-setup.html
00:48
<johnny>
i plan on doing a mobile classroom
00:48
<achandrashekar_>
the post above says exactly what you stated.
00:48
You will need to select one server to behave as the primary server. This server will be used to run additional services, hold users files, and network boot thin clients.
00:48
Secondary servers will be used only to run desktop sessions. They are simpler, and will be configured to use the central services from the primary server. Installing the package ltsp-server will install required software.
00:48
sorry for flood
00:50
<johnny>
hmm.. i didnt know it was that detailed :)
00:50
there's gotta be a nicer way to deploy packages
00:50
i bet the syncronization could be more automated
00:50
i also notice a small issue in there
00:51
<achandrashekar_>
yeah...know you see my "slight" confusion..lol
00:51
but it certainly makes more sense talking it out with you.
00:51
i will just have to give it a whirl.
00:52
<johnny>
i've learned alot from the one deployment i setup
00:52
even with just 4 plcs
00:52
pcs*
00:53
<achandrashekar_>
yeah..this stuff rocks.
00:53
:)
00:54
<johnny>
if you notice the replication of desktop profiles section
00:54
it doesn't mention that they can be deployed via http
00:55
so you can set that to your main server, just like the other stuff
00:56
<achandrashekar_>
yeah..ill have to simply work through a complete install of this and see how it falls into place.
00:56
the part i am interested in is the ldap authentication of one server against the other, and then having it "actually" work.
00:56
i think ill learn a bit about ldap in this process.
00:57
im kind of of "hung up" over it.
00:57
;)
00:58
johnny: thanks for the conversation.
00:58
will be back tomorrow to report progress.
00:59
and give it a whirl.
01:00achandrashekar_ has left #ltsp
01:13misui has joined #ltsp
01:20brillantejcoh has quit IRC
01:37subir has quit IRC
01:51emilk has joined #ltsp
01:55rcy is now known as noneck
01:56noneck is now known as rcy
02:49misui has quit IRC
03:01Q-FUNK has joined #ltsp
03:06Pascal_1 has joined #ltsp
03:13muep_ has quit IRC
04:42
<Pascal_1>
Bonjour !
05:25Egyptian[Home1 has joined #ltsp
05:26Egyptian[Home] has quit IRC
05:35mhterres has joined #ltsp
05:38otavio has joined #ltsp
06:05F-GT has quit IRC
06:06F-GT has joined #ltsp
06:13mhterres has quit IRC
06:13mhterres has joined #ltsp
06:18emilk_ has joined #ltsp
06:24cliebow has quit IRC
06:35emilk has quit IRC
06:38moldy_ has joined #ltsp
06:38moldy_ is now known as moldy
06:38
<moldy>
hi
06:38
i am looking for a good ltsp-compatible thin client to buy in europe
06:39
can anyone recommend anything? i am having trouble digging out useful information from google
06:40
<Q-FUNK>
moldy: yes, the thincan
06:41
<moldy>
Q-FUNK: looking at their website. is there any info on prices available?
06:41
Q-FUNK: ahh never mind :)
06:41
<Q-FUNK>
moldy: at the bottom of the page
06:41
<moldy>
found it
06:42
DBE61 looks interesting
06:42jammcq has quit IRC
06:43
<moldy>
Q-FUNK: do sound and access to local usb sticks work with the DBE61 and ltsp?
06:44
<Q-FUNK>
yes
06:44
<moldy>
Q-FUNK: nice
06:44
<Q-FUNK>
same as with all other hardware
06:44
actually, the Geode is pretty much the best supported chipset in Linux
06:45
<moldy>
Q-FUNK: where can i order a device?
06:46
<Q-FUNK>
use the response form
06:46
<moldy>
hm ok
06:53
i have an ubuntu server around here, is it recommendable to install the ltsp packages from ubuntu (for testing)?
06:53
<Q-FUNK>
yes
06:53
<moldy>
ok, thanks
06:54
<Q-FUNK>
moldy: if you use a thin can, you'll need updated packages for the graphic driver and for X, though.
06:56
<moldy>
for production, i have no problem installing other packages or compiling ltsp myself
06:56
for testing i will first just use a usual machine i think
06:58
<Q-FUNK>
starting with Hardy, you will not need to compile anything. all the patches have been merged.
06:58
it's only with Gutsy that you need to update some packages and rebuild the boot image.
06:59
<moldy>
i am running dapper here
07:00
is that still ltsp4?
07:01
the ubuntu package is version 0-something :)
07:08Pascal_1 has left #ltsp
07:10
<Q-FUNK>
dapper won't work
07:10
too old
07:11
most of the developments for LTSP happened during Gutsy and Hardy cycles.
07:13
<moldy>
i see
07:13
"won't work" means what it won't work at all?
07:14jammcq has joined #ltsp
07:14
<moldy>
(so i shoud install from an upstream package?)
07:15mikkel has joined #ltsp
07:16
<Q-FUNK>
many graphic drivers were not even in ubuntu back then.
07:16
also the whole build system was rather archaic.
07:17
you might wanna consider upgrading to at least Gutsy or even Hardy.
07:17
<moldy>
hm, i will consider it
07:17
<Q-FUNK>
the other thing is that many USB devices were not supported until recent kernels.
07:18
<moldy>
i would prefer not updating for just the first simple test though
07:18
<Q-FUNK>
then you would need to backport a few packages
07:18Blinny has joined #ltsp
07:19elisboa has joined #ltsp
07:19
<moldy>
7.10 is what? gutsy?
07:19
<Q-FUNK>
yes
07:20
<moldy>
hm, wondering how painful an update from dapper to gutsy will be :)
07:21
<Q-FUNK>
good question
07:21
here, using "aptitude" with the safe-upgrade mode, I generally get smooth upgrades.
07:21
<moldy>
it seems that a directupdate is not supported
07:22
<Q-FUNK>
that's possible
07:22
ubuntu tends to support only updating from one LTS release to another (in this case 6.06 to 8.04) or from immediately subsequent releases.
07:23
updating to other releases is also possible, but not supported.
07:24
<moldy>
hmm :-/
07:24
https://help.ubuntu.com/community/EdgyUpgrades reading that right now
07:24
what is gksu? i don't have it
07:25
please don't tell me that update-manager requires a gui...
07:25
<Q-FUNK>
I'm trying to remember which release was dapper?
07:25
<moldy>
6.06
07:25
<Q-FUNK>
right, the last LTS
07:25
<moldy>
according to tha paage an update to feisty is supported and from there to the next version and so on
07:26
but it seems they forgot about the server edition...
07:26
<Q-FUNK>
although we're still2 months form the release, it would porbably safer to update to 8.04
07:26
6.06 to 8.04
07:26
<moldy>
is there any documentation on how to do that?
07:26
<Q-FUNK>
there's probably instructions about that, since it was the last long-term release.
07:26
<moldy>
what's the codename for 8.04?
07:27
<Q-FUNK>
Hardy
07:27
<Blinny>
Last I read, LTS->LTS was planned for Hardy.
07:27
<moldy>
i assume just changing sources.list to hardy and running aptitude will break all sorts of stuff...
07:28
Q-FUNK: and the dapper ltsp packages don't work *at all*?
07:28
for now, i just want to see it "in action" basically
07:28
<Q-FUNK>
moldy: changing sources, only leaving the regular and security lines, then "aptitude update && aptitude safe-upgrade && aptitude safe-upgrade"
07:29
moldy: dapper packages work but, IIRC they are LTSP 4
07:29
<moldy>
Q-FUNK: that would be ok for now
07:29
<Q-FUNK>
and they only work with old hardware
07:29
<moldy>
for now i just want to do very basic testing, since i have never worked with ltsp before
07:29
<Q-FUNK>
the DBE61 drivers only appeared in Gutsy.
07:30
<moldy>
i am going to test on 8 year old thick client hardware anyway, for now
07:30
<Q-FUNK>
but for basic testing with a diskless computer and a network bootable card, it would work just fine
07:30
just that IIRC there was no auto-mounting of USB stick and other nic ehtings like that
07:30
<moldy>
basicaly i just want to see that i get the configuration process right, to spot possible difficulties for later :)
07:31
<Q-FUNK>
well, the configuration process also changed between 4 and 5
07:31
<moldy>
but btw, it's really stupid that the only supported application for performing a safe upgrade needs a fscking GUI!
07:31
<Q-FUNK>
a lot of things are much simpler on 5.0
07:31mhterres has left #ltsp
07:32
<Q-FUNK>
aptitude also works well for performing safe upgrades. it's just that ubuntu is primarily a desktop distro, so they recommend GUI tools for everything
07:32
what I usually do when I upgrade really old machines is:
07:33
<moldy>
Q-FUNK: hm. their documentation explicitly says not to use apt-get, and says nothing about aptitude
07:33
<Q-FUNK>
aptitude update && aptitude install dpkg aptitude && aptitude safe-upgrade
07:33
apt-get is deprecated.
07:33
I agree with not using APT.
07:33
aptitude is much better.
07:33
<moldy>
anyway, it seems i need to wait for the weekend before i can pursue ltsp any further
07:33
<Q-FUNK>
or actually, make that:
07:34
<moldy>
i cannot risk performing an update on that server during the week it seems :-/
07:34
<Q-FUNK>
aptitude update && aptitude install dpkg && aptitude install aptitude
07:34
<moldy>
Q-FUNK: what exactly do i modify in sources.list and what not?
07:34
<Q-FUNK>
followed by many instances of "aptitude safe-upgrade"
07:39slidesinger has joined #ltsp
07:56moldy has quit IRC
08:03cliebow_ has joined #ltsp
08:18Blinny has quit IRC
08:28Gadi has joined #ltsp
08:31Q-FUNK has quit IRC
08:43Q-FUNK has joined #ltsp
08:44
<Gadi>
sutula: ping
08:45
<cliebow_>
Gadi:rockS
08:45
<Gadi>
morning, cliebow_
08:45
:)
08:45
<Q-FUNK>
!g
08:45
<ltspbot>
Q-FUNK: "g" is Gadi!!!!!!!!!!!!!!!!!!!!!!!!
08:45
<cliebow_>
good morning!
08:45
<Gadi>
you're almost better than my morning cup of Joe
08:45
!Q
08:45
<ltspbot>
Gadi: Error: "Q" is not a valid command.
08:45* Gadi shakes his head
08:46
<Gadi>
silly ltspbot - doesnt know nothin
08:46
<Q-FUNK>
ah, mon capitaine. the Q continuum is shocked.
08:46
<Gadi>
who knew? Q-FUNK's a trekky
08:47
<cliebow_>
ltspbot factoids search --values
08:47
<ltspbot>
cliebow_: 'ltsp', 'sbalneav', 'icewm', 'frappr', 'wiki', 'debian', 'edubuntu', 'dhcpd', 'greyscreen', 'ltsp42', 'localdev', 'localdev', 'localdev', 'localdev', 'checklist', 'muekow', 'bestltspdistro', 'serversize', 'wireless', 'sound', 'topics', 'integration', 'lts.conf', 'pastebot', 'bootfloppy', 'ltsp5', 'tarball', 'download', 'monkeys', 'ogra', 'nfs', 'nfsnotresp', 'js', 's', 'troubleshooting', (1 more message)
08:47
<cliebow_>
ltspbot:set Q as Q-FUNK!
08:47
!Q
08:47
<ltspbot>
cliebow_: Error: "Q" is not a valid command.
08:48r3zon8 has joined #ltsp
08:49
<cliebow_>
ltspbot:set !Q as Q-FUNK!
08:49
!Q
08:49
<ltspbot>
cliebow_: Error: "Q" is not a valid command.
08:56nicoAMG has joined #ltsp
09:08mccann has joined #ltsp
09:11Guaraldo has joined #ltsp
09:15K_O-Gnom has joined #ltsp
09:23spectra has joined #ltsp
09:29
<Gadi>
ogra: u around?
09:35emilk_ has quit IRC
09:39
<Q-FUNK>
!q
09:39
<ltspbot>
Q-FUNK: Error: "q" is not a valid command.
09:39
<Q-FUNK>
meh
09:43
<ogra>
Gadi, here
09:43
Gadi, "1. Fix to not add "-X" to ssh cmd when in directx mode" not sure that will work, we might need the -X for the consolekit tunnel
09:47
<Gadi>
ah, good - got my email
09:47
:)
09:47
did a lot of ldm-hacking last night
09:47
starting to look more like a display manager :)
09:49
<ogra>
heh
09:49
yeah, i'm trying to get my pieces together for the last upstream checout before feature freeze
09:50
<Gadi>
ooh - Id love to get some of these fixes into hardy
09:50
not restarting X makes a HUGE difference for low-powered clients
09:51
or funky vid chips
09:51
<ogra>
well, feature freeze means no new upstream version, it doesnt mean i cant add patches to fix bugs ;)
09:52
<Gadi>
ah, the line is so fine you can hardly see it :)
09:56makghosh has joined #ltsp
10:03writeout has joined #ltsp
10:06
<writeout>
"PXE-E32: TFTP open timeout" TFTP
10:07
i renamed the /opt/ltsp/i386 to /opt/ltsp/i386.backup and did a new ltsp-build-client, is that why the tftp cant load on the client?
10:10
<cliebow_>
no
10:10
i have mixed results in pxe..depending on the card...
10:11
<writeout>
http://paste.ubuntu-nl.org/55609/
10:11
is my dhcp conf invalid?
10:11
in /etc/ltsp/dhcp.conf
10:18elisboa has quit IRC
10:21bobby_C has joined #ltsp
10:22elisboa has joined #ltsp
10:22
<cliebow_>
writeout, looks fine..
10:22elisboa has quit IRC
10:23
<writeout>
tnx
10:23
trying to remove everything with ltsp and dhcp and tftp and try again
10:25bobby_C has quit IRC
10:39staffencasa has joined #ltsp
10:47FuriousGeorge has quit IRC
10:48ogra_cmpc has joined #ltsp
10:48plamengr has joined #ltsp
10:50sutula has quit IRC
10:50jbrett has quit IRC
10:58Q-FUNK has quit IRC
10:59Q-FUNK has joined #ltsp
11:13ogra_cmpc has quit IRC
11:15ogra_cmpc has joined #ltsp
11:17Q-FUNK has quit IRC
11:19sutula has joined #ltsp
12:11Q-FUNK has joined #ltsp
12:13Topslakr| has quit IRC
12:14Blinny has joined #ltsp
12:16moldy has joined #ltsp
12:18moldy_ has joined #ltsp
12:20moldy has quit IRC
12:21moldy_ is now known as moldy
12:27Q-FUNK has quit IRC
12:36vagrantc has joined #ltsp
12:38slidesinger has quit IRC
12:38K_O-Gnom has quit IRC
12:40Q-FUNK has joined #ltsp
12:43indradg has joined #ltsp
12:57slidesinger has joined #ltsp
12:59writeout has quit IRC
12:59moldy has quit IRC
13:01gonzaloaf_laptop has joined #ltsp
13:05
<Blinny>
In LTSP5, lts.conf defaults to /var/lib/tftpboot/i386 or some such right? - I suppose the SERVER line is then removed from lts.conf and if you have multiple LTSP subnets then they're all served from one lts.conf ?
13:06
<vagrantc>
if you don't specify the SERVER line in lts.conf, then it sets SERVER to whereever the root filesystem is mounted from.
13:07moldy has joined #ltsp
13:07
<vagrantc>
so i would generally recommend not specifying SERVER
13:07vagrantc has quit IRC
13:08lns has joined #ltsp
13:13vagrantc has joined #ltsp
13:17
<Gadi>
vagrantc: see my email to ltsp-dev?
13:17
<Blinny>
Thanks vagrantc
13:19
<vagrantc>
Gadi: yes
13:19
Gadi: haven't reviewed the branch yet, but most of it sure sounds good.
13:20moldy has quit IRC
13:21
<Gadi>
vagrantc: Im looking forward to another set of eyes
13:21
:)
13:22
vagrantc: what happened to the rc.d scripts in the new ldm-trunk?
13:22
<vagrantc>
Gadi: there was something relating to ssh -X and LDM_DIRECTX which i think might not be right ... because the ltspfs scripts actually need access to the X server ...
13:22
<Gadi>
I don't see where they moved to
13:22
<vagrantc>
Gadi: all of the non-ltspfs ones were removed, and all of the ltspfs ones were moved to ltspfs
13:22
<Gadi>
vagrantc: I think I kept it for the sentinel connection but not the session connection
13:25Q-FUNK has quit IRC
13:25plamengr has quit IRC
13:39
<warren>
did Edubuntu make a terminal server LiveCD?
13:42Patina_ has joined #ltsp
13:42Patina_ has quit IRC
13:52
<vagrantc>
warren: i think it was attempted, but wasn't fast enough or something
14:04jbrett has joined #ltsp
14:09
<Gadi>
ogra: have you already made a debian/ dir for ldm-trunk? or should I just copy and modify the bits from the gutsy ltsp pkg?
14:11indradg_ has joined #ltsp
14:18Gato has joined #ltsp
14:18
<Gato>
Can someone help to connect by remote desktop using ubuntu server 7.10 + LTSP? the problem is when i put rdp_options = 192 168.1.2 screen_02 = rdesktop in lts.conf don't work, then sreen stil in black
14:19
<vagrantc>
Gadi: is rdesktop installed in your chroot ?
14:19
<cliebow_>
8~)
14:19
<Gato>
how can i see it?
14:19
<cliebow_>
Gato:listen top vagrantc
14:20
<Gato>
Where is chroot?
14:20
<cliebow_>
Gato:how a bout sudo chroot /opt/ltsp/i386 && apt-get install rdesktop..then ltsp-update-image
14:20
<Gato>
oki!
14:21
thanks a lot
14:21
<cliebow_>
dont quote me...
14:21K_O-Gnom has joined #ltsp
14:29indradg has quit IRC
14:30
<Gadi>
vagrantc: in some, yes
14:30
:)
14:30
<vagrantc>
oops.
14:32Blinny has quit IRC
14:35Gato_ has joined #ltsp
14:37
<warren>
grr
14:37
We don't call the arch 'amd64'
14:37
now how to fix this in a dist-neutral way...
14:41Gadi has left #ltsp
14:42
<vagrantc>
warren: honestly, i think this is exactly the case for plugins
14:43
<warren>
vagrantc, good point
14:43
<vagrantc>
warren: in fact, i replied but never sent the email ...
14:43
<warren>
vagrantc, i'd rather not add another file when it is just a tiny thing in common though.
14:43
vagrantc, do you have a x86_64 Debian system?
14:44
does Debian internally name it amd64?
14:44
when you type "arch"?
14:44
<vagrantc>
warren: no idea...
14:44
i have no amd64 systems to test on
14:45
warren: we've been using dpkg --print-architecture, which has it's own logic... and i think for debian-derived systems, that's the smart thing to do.
14:45* sutula volunteers that it is amd64 on Debian
14:46
<warren>
sutula, when you run "arch" it says amd64?
14:46* sutula tries
14:46
<vagrantc>
warren: arch returns i686 on my machine, but there is no "i686" architecture for debian.
14:46
warren: i'm running the i386 architecture ...
14:46
<sutula>
warren: Sorry...it returns x86_64
14:46
<warren>
hmm
14:46
<vagrantc>
warren: just sent the email.
14:48
<sutula>
...yet Debian commonly calls it amd64
14:49
<vagrantc>
basically, i think debian-derived distros should use the debian related tools for architecture, since it doesn't really correlate to the .... libc6? gcc? ?? conception of architecture
14:51Gato has quit IRC
14:51
<sutula>
fwiw, there is no /bin/arch on my desktop (unstable) machine...but there was one on my Etch/amd64
14:52* sutula heads to a meeting
14:52
<cliebow_>
ogra:anything i should watch for with alternate cd??
14:52Guaraldo has left #ltsp
14:57gonzaloaf_laptop has quit IRC
15:08K_O-Gnom has quit IRC
15:11gonzaloaf_laptop has joined #ltsp
15:23mikkel has quit IRC
15:23joebaker has joined #ltsp
15:28Gato_ has quit IRC
15:28makghosh has quit IRC
15:29cesar_ has joined #ltsp
15:29
<vagrantc>
oh gadi ...
15:29
<cesar_>
hello people
15:29
one question
15:30
when the terminal is loading the system
15:30
not load the module for sound in the cliente
15:30
client
15:31
the module is "cmpci"
15:31
how I can install this module in the server if is necesary?
15:32
or...... what is happend?
15:32cliebow_ has quit IRC
15:32
<cesar_>
when I execute a file .mp3 in xmms in the terminal client
15:33
the sound is playing in the server
15:34
in the client terminal shell I excecute this command
15:34
pci_scan /etc/audiolist
15:34
and I get "cmpci" for response
15:35IsleVegan has joined #ltsp
15:35
<cesar_>
may be I need install a module "cmpci" in the server ltsp?
15:36
<vagrantc>
cesar_: what linux distro and what release?
15:36
<cesar_>
Debian ltsp 2.6.18-5-amd64
15:37
ltspcfg - Version 0.16
15:37
ltspadmin - v0.17
15:38
ltsp-utils 0.25-1
15:38
<vagrantc>
cesar_: and you aren't using ltsp-server, right?
15:39
cesar_: ltsp-server and ltsp-utils are incompatible... so you need to make sure you only use one.
15:39
<cesar_>
yes
15:39
only ltsp-utils is installed
15:40
in my Debian
15:40
ps ax|grep lts
15:40
<vagrantc>
!sound
15:40
<ltspbot>
vagrantc: "sound" is http://wiki.ltsp.org/twiki/bin/view/Ltsp/Sound
15:40
<cesar_>
Ss 0:00 avahi-daemon: running [ltsp.local]
15:40
ok...
15:41
but I see the wiki page and I can't resolve the problem
15:41
<vagrantc>
cesar_: it sounds like your environment variables for remote sound aren't set
15:42
<cesar_>
one moment
15:42
in lts.conf
15:42
this is the set properties
15:42
SOUND = Y
15:42
SMODULE_01 = cmpci
15:43
SOUND_DAEMON = esd
15:43
VOLUME = 100
15:43
and any more
15:43
<vagrantc>
ok, so that sounds good.
15:44
<cesar_>
in the mailing lists and other page is similar configuration
15:44
but
15:44
when the terminal is loading modules
15:44
say
15:44
"FATAL: Module sound mcpci is not found"
15:45
<vagrantc>
cesar_: mcpci, or cmpci ?
15:45
<cesar_>
"it isn't loaded"
15:45
sorry
15:45
"cmpci"
15:46
this is the correct
15:46
:-)
15:46
it's write in lts.conf
15:46
but not working
15:46
<vagrantc>
ok, so it doesn't have the cmpci module ...
15:46Q-FUNK has joined #ltsp
15:46
<vagrantc>
which means your sound isn't going to work
15:47
<cesar_>
yes
15:47
how I can get the module
15:47
<vagrantc>
cesar_: so either you need to make sure that "cmpci" is the correct module name for the version of ltsp that you are using.
15:47
<cesar_>
or how I can install this module in the server
15:47
<vagrantc>
cesar_: or, you need to build the cmpci module for the kernel you're using for ltsp.
15:48
<cesar_>
this module need stay in /opt/ltsp/i386....
15:48
<vagrantc>
cesar_: how do you know it's "cmpci" ?
15:49
<cesar_>
because lspci in terminal say the next information
15:49
one minute
15:50
C-Media Electronics CM8738
15:50
this is the result for do "lspci" in the terminal computer
15:50
and searching in the web
15:51
<Q-FUNK>
ogra?
15:51
<cesar_>
"cmpci" is the name
15:51
for the module
15:51
<vagrantc>
cesar_: when you search on the web, did you find information specific to the version of ltsp you're using?
15:51
<cesar_>
mmm... I am not be sure
15:52
ok
15:53
vagrantc : thanks for your help
15:53
<vagrantc>
you need to find the module name for the specific kernel version you're using... ltsp 4.2 hasn't been updated in a long time. the module name may have changed since then.
15:53
<cesar_>
I am going to have english class now... am late
15:55
tomorrow I try with your advice
15:55
ok thanks for all
15:56
bye..
15:56
<warren>
vagrantc, I'm not so sure about a plugin for the arch issue
15:56
vagrantc, it is only one distro-specific line in 001-set-arch
15:56
vagrantc, there has to be a sane way to conditionalize that
15:56
<cesar_>
tomorrow I will connect at this channel
15:57
:-)
15:57
<jammcq>
warren: how about a simple translation
15:57
<warren>
jammcq, in what way?
15:57cesar_ has quit IRC
15:57
<jammcq>
well, I haven't seen the code
15:57
<warren>
x86_64)
15:57
case "$(uname -m)" in
15:57
x86_64)
15:57
ARCH=amd64
15:57
;;
15:57
<jammcq>
but basically, if you have 'x86_64' and the system needs 'amd64'
15:58
yeah
15:58
<warren>
jammcq, only Debian uses "amd64", we use x86_64
15:58
<jammcq>
ok, then the other way around
15:58
I prefer x86_64 myself
15:58
amd64 is misleading
15:58
<warren>
amd64 isn't even accurate, how do Intel users feel?
15:58
<jammcq>
exactly
15:58
every time I build a new server, I look at that and think.... is this the one I need?
15:58
<Q-FUNK>
there wasn't any emt64, at first
15:59
<jammcq>
right, but did they think that amd was the ONLY 64-bit game in town?
15:59
<vagrantc>
warren: yes, but it also likely applies to ppc vs. powerpc, and numerous other issues.
15:59
warren: look at the corresponding code in the debian plugin ...
16:00
<Q-FUNK>
jammcq: alpha was already its own separate arch.
16:00
<warren>
vagrantc, only a few lines?
16:00
<vagrantc>
warren: much, much simpler than the common plugin
16:00
<warren>
vagrantc, if Debian doesn't even use 001-setarch then why does the common plugin hardcode a Debianism?
16:00
<jammcq>
Q-FUNK: i'm thinking in the x86 world. I know alpha and ppc and sparc have 64-bits
16:01
<vagrantc>
warren: because it was written by people develping on debian and ubuntu?
16:01
<Q-FUNK>
jammcq: there was no other x86 64-bit player for a while
16:01
<warren>
OK, Ubuntu uses the common
16:01
<vagrantc>
warren: we used it originally, but i got a bug report about unexpected behavior of amd64 installing i386, so i made a simpler version for debian.
16:01
<Q-FUNK>
by the time intel reacted and came up with the emt64, it was already to late: the port was called amd64.
16:01
<warren>
I remember those days.
16:02
We had to rebuild everything turning off two registers in the gcc compiler because EM64T was based on an earlier draft of the AMD64 spec.
16:02
So our x86_64 binaries became a least common denominator between the two archs.
16:03
Intel doesn't use EM64T anymore. They have some other silly name I thought?
16:03
anyway
16:04
<vagrantc>
warren: i think the -set-arch code in common also made it impossible to install an amd64 ltsp environment, if i remember correctly.
16:04* vagrantc continues to use the debianism term ...
16:10
<warren>
vagrantc, so debian relies entirely on the config option for arch being set
16:10
vagrantc, where is it set?
16:10ogra has quit IRC
16:11ogra_cmpc has quit IRC
16:11ogra has joined #ltsp
16:11ogra_cmpc has joined #ltsp
16:24
<vagrantc>
warren: in debian's 000-basic-configuration plugin
16:24IsleVegan has quit IRC
16:25nicoAMG has quit IRC
16:25
<vagrantc>
warren: that sets the defaults, and then all later plugins override the defaults
16:25
<warren>
ahh
16:26
vagrantc, any suggestion how I can make it install a i386 chroot by default even on x86_64 unless overridden by a config option?
16:26
vagrantc, how are command line config options supposed to work?
16:26
vagrantc, ltsp-build-client --arch x86_64 ?
16:27
<vagrantc>
warren: sure.
16:27
warren: i think the common/001-set-arch is ridiculously overcomplicated
16:27
<ogra_cmpc>
lets just default to i386 in any case ?
16:27* ogra_cmpc wouldnt mind that as a default
16:28
<ogra_cmpc>
evening btw
16:28
<warren>
h
16:28
hi
16:28
<ogra_cmpc>
:)
16:29
having a proper powerpc build through quemu is utopic for the next two years imho ....
16:29
amd64 clients are rare ...
16:29
so defaulting to x86 in any case with optional overrides seems sane
16:29
<vagrantc>
amd64 clients are no rarer than the amd64 architecture ...
16:30
<warren>
I'm going to default to i386 for x86_64 servers
16:30
and ppc for ppc64
16:30
they can override easily if they want
16:30
<ogra_cmpc>
i have supported exactly one user who had amd64 cklients in my whole time in ltsp land
16:31
warren, my prob is that i provide CD installs .... so i need to have an option for it in any case
16:31
<vagrantc>
ogra_cmpc: it is trivial to write an ubuntu plugin for it
16:31
<ogra_cmpc>
on amd64 CDs we dont provide x86 poackages at all
16:32
vagrantc, i know, i'm still not eager to go through all the wikipages etc and fix the documented options we sue since ages
16:32
s/sue/use
16:32
<warren>
ogra_cmpc, your AMD64 CD is of limited usefulness on its own anyway
16:32
ogra_cmpc, given what most clients are...
16:32
<ogra_cmpc>
right
16:32
but it needs to work :)
16:32jammcq has quit IRC
16:32
<warren>
so again, not a big issue
16:33
<ogra_cmpc>
which forces me to have that option
16:33
<vagrantc>
ogra_cmpc: yes, but it would be easier to write logic sticking to the debian/ubuntu architecture namespace, overriding common/001-set-arch than to make common/001-set-arch work for all distros
16:34
<ogra_cmpc>
well, then lets drop 001-set-arch from common ...
16:34
i see no point for it being a common plugin
16:34* vagrantc thinks *most* distros will be able to use it
16:35
<warren>
Do *most* distros call it amd64?
16:35
<ogra_cmpc>
no idea
16:35
but we called it like that for the last two years in ltsp
16:35
<warren>
Given that glibc, uname, kernel all call it x86-64
16:35
x86_64 I mean
16:35
Debian isn't even using it anymore
16:35
<vagrantc>
warren: what i mean is that *most* distros should be able to use the "uname -m" output, but debian-derived distros are better using their own architecture namespace.
16:36
warren: what do you mean debian isn't even using it?
16:36
<ogra_cmpc>
warren, deboootstrap, dpkg and apt-get use it
16:36
<vagrantc>
warren: there is no architecture called x86_64 on debian.
16:36
<ogra_cmpc>
$ARCH is neither referring to kernel nor to libc ....
16:37
<warren>
vagrantc, the common/ file
16:37
I meant that file
16:37
<ogra_cmpc>
its an architecture option for the packaging systen
16:37
system
16:37
<warren>
calm down, I meant that file isn't used by Debian
16:37
<ogra_cmpc>
well, if we keep it in common it should work for us all
16:38
if it doent do that is should go from common
16:38* vagrantc sees no reason for all plugins in common to have to work for everybody
16:38
<ogra_cmpc>
else i dont really understand the point of having a common namespace
16:38
<vagrantc>
if it works for 8 out of 10 distros, chances are it's fine in common.
16:38
the distros that are freakish will just have to work around it, which is trivial to do.
16:38
<warren>
ogra_cmpc, I don't think 001-set-arch makes sense in common given that it doesn't work on Fedora derivatives
16:39
vagrantc, are you calling us freakish? =)
16:39
<vagrantc>
warren: no, i'm calling debian and ubuntu freakish
16:39
<ogra_cmpc>
well, most distros will be a derivative of one of the participating distros now... whats the prob of linking to the plugins your parent provides ?
16:40
warren, well, then put it into the Fedora dir and i'll link to the debian one
16:40
<vagrantc>
whatever. this is such a trivial issue.
16:40
<warren>
case "$MODE" in
16:40
commandline)
16:40
add_option "arch" "`eval_gettext "set the target architecture"`" "advanced" "true"
16:40
;;
16:40
configure)
16:40
if [ -n "$option_arch_value" ]; then
16:40
ARCH_OPT="$option_arch_value"
16:40
<ogra_cmpc>
i just dont see a point in it being in common
16:40* vagrantc doesn't see the point of dragging this out any longer
16:40
<warren>
vagrantc, if arch is set by command line option, will it still run the configure) part?
16:41
ogra_cmpc, I agree.
16:41
<vagrantc>
warren: that's the point.
16:41
<warren>
I mean...
16:41
configure)
16:41
if [ -n "$option_arch_value" ]; then
16:41
ARCH_OPT="$option_arch_value"
16:41
else
16:41
ARCH_OPT=$(uname -m | sed -e s/i.86/i386/ -e s/ppc.*/powerpc/)
16:41
fi
16:41
$option_arch_value can come from either the command line or an earlier plugin?
16:41
<vagrantc>
if the --arch flag is set to something, then $option_arch_value will be set
16:42
<warren>
ok thanks for verifying
16:42
<vagrantc>
$option_*_value is what the add_commandline_option function sets
16:42
<ogra_cmpc>
vagrantc, well, it breaks my current builds and i dont want to change it without talking it over, i agree it might be to much fuss about a small issue but i cant release without fixing it in any way
16:42
<vagrantc>
ogra_cmpc: i thought you were in upstream freeze a while ago anyways?
16:42
<ogra_cmpc>
vagrantc, wednesday
16:43
valentine freeze :P
16:43
vagrantc, do you plan to keep the 5.0.40 versioning for lenny ?
16:44
(so i dont get issues with MOM)
16:45
<vagrantc>
ogra_cmpc: well, until an upstream releases with a newer version, i plan to keep that for ltsp 5.0.40~bzr* ... ldm is using 2:0.1~bzr* and ltspfs is using 0.5.0~bzr*
16:46
<ogra_cmpc>
why the epoch for ldm ?
16:46
<vagrantc>
if the mips and mipsel buildd's EVER build a new package for ldm or ltsp
16:46
<ogra_cmpc>
lol
16:46slidesinger has quit IRC
16:46
<ogra_cmpc>
ok, i'll put it to 2.x and blacklist it in MOM
16:46
<vagrantc>
ogra_cmpc: because the version in the source is 0.1, though 0.1 has never yet been released, and when it was part of ltsp, it was 5.* ... so needed to use epoch
16:47
<ogra_cmpc>
the 0.1 is nonsense imho
16:47
its actually the 2.x release series
16:47
we should fix that upstream
16:47
<vagrantc>
well, we're stuck with the epoch in debian.
16:48
<ogra_cmpc>
yeah, sad for you, i luckily dont have mips
16:48
<vagrantc>
there's been no upstream release of ltsp, ltspfs or ldm since ltsp 4.2
16:48
so picking a good version string is a little challenging.
16:49
<ogra_cmpc>
well, for ldm its the second iteration of the code, i think a 2.x version makews sense here
16:49
<vagrantc>
basically, ltsp-client in lenny is broken
16:49
ogra_cmpc: i think originally, it was going to be called ldm2, version 0.1
16:49
<ogra_cmpc>
i havent evemn had the time tio check whats broken yet
16:49
only did a review of the changes
16:49
<vagrantc>
ogra_cmpc: i'magine our debian dirs are really out of sync
16:50
<ogra_cmpc>
mine isnt even in bzr yet :/
16:50* vagrantc glares a little
16:50
<ogra_cmpc>
i'll fix that with thi9s upload
16:50
<vagrantc>
gadi's been asking where to find the debian dir for various things
16:51* vagrantc grumbles about gadi's 8-feature monolithic patch
16:51
<ogra_cmpc>
apt-get source various-things
16:51
<Q-FUNK>
make universe
16:51
<ogra_cmpc>
i guess we wont be able to drop -X
16:52
consolekit (or rather ssh wont handle that)
17:00* ogra_cmpc wonders what to do with https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/172459
17:00
<ogra_cmpc>
i wonder why we hardcoded that
17:01
especially since that coede is from pere who never ever hardcodes anything
17:02
<warren>
Oh yes. Can we PLEASE branch ldm?
17:02
ldm-trunk should forge ahead with incompatible changes.
17:02
ldm-oldversionnumber should we a branch to continue on the old version?
17:02
<vagrantc>
warren: when there's a release ...
17:03
<warren>
You don't necessarily need a release
17:03
"branch point"
17:03
<ogra_cmpc>
there was someone who wanted to taske over maintenance of the ldm1 code
17:03
<warren>
ogra_cmpc, what is ldm1?
17:03
the current ldm-trunk or the older python?
17:03
<ogra_cmpc>
the python version
17:03
before the ldm2 rewrite we did last year
17:04
so imho the 2 should be somewhere in the naming scheme
17:04
<vagrantc>
warren: why not just branch using the incompatible changes *you* want to do, and then propose to merge them into ldm-trunk and branch the old version then?
17:05
<ogra_cmpc>
(preferably not directly attached to the name (i.e. ldm2) bit thats only my gut esthaethical feeling :))
17:05* vagrantc is not eagre to break compatibility
17:05
<ogra_cmpc>
s/bit/but/
17:05
why would we do that ?
17:05
<warren>
do what?
17:05
<ogra_cmpc>
and at what level
17:05
break compatibility
17:06
<warren>
ogra_cmpc, ldm as is is inadequate in many ways
17:06
<vagrantc>
warren: and works fine in many ways ...
17:06
<warren>
ogra_cmpc, for one, the current code can't work on fedora at all.
17:06
<ogra_cmpc>
??
17:06
<vagrantc>
warren: i'm not a big fan of breaking compatibility without specific reasons to do so.
17:06
<ogra_cmpc>
it just requires an ssh server
17:06
<warren>
ogra_cmpc, locale -a outputs too many languages
17:07
<ogra_cmpc>
whats the problem with it ?
17:07
<vagrantc>
warren: so your asking to break compatibility doesn't really speak to anything ...
17:07
<ogra_cmpc>
warren, well, then add a better query for the langs :)
17:07
i'm not opposed to steal the hack from gdm
17:07
<vagrantc>
apparently ubuntu doesn't handle "Default" as a login session, either.
17:08
so it only works when manually selecting which session
17:08
<warren>
I'll show it to you when I have something concrete in code
17:09
<vagrantc>
also, from what eharrison was saying, ldm cuts the output from ldminfod off at about 205 lines of output ... and he's experienced where you get 205 locales, and no session types or load rating
17:09
erg.
17:09
what i *meant* to say was: apparently ubuntu doesn't handle "Default" as a login session, either.
17:10Q-FUNK has quit IRC
17:10
<vagrantc>
gah!
17:10
what i *meant* to say was: apparently fedora doesn't handle "Default" as a login session, either.
17:11
<ogra_cmpc>
heh
17:12
vagrantc, well, there isnt really a need for listing 205 locales
17:12
gdm has some hackish code to cut down the list
17:12
i was hpoing to find the time to integrate that since we started ldm2
17:13
but i didnt yet
17:13
<warren>
ogra, gdm is completely rewriting it now
17:13* vagrantc wonders about a submenu ... since most locale's are the form of LANGUAGE_COUNTRY
17:14
<ogra_cmpc>
in any case i have a patch that makes it reload after the first password failure ... this "three attempts to type in your pw" is even confusing me
17:14
warren, so its good i didnt steal it yet :) i'll wait for a proper variant then ;)
17:15
vagrantc, well, i'd prefer a more descriptive (and localized) list than just the native locale value ...
17:15
and we'll need to handle dmrc at some point
17:15
<vagrantc>
indeed
17:16
<ogra_cmpc>
also on my list since ages
17:17mccann has quit IRC
17:26
<ogra_cmpc>
vagrantc, any opinion on https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/132397 ?
17:27
i'd like to add the listed fix
17:28* ogra_cmpc wonders what to do with all these xen related bugs *sigh*
17:28Furlow has joined #ltsp
17:29
<Furlow>
hi is there anyway to set the default session to gnome-session instead of what is already the default. Im using ubuntu
17:30
<ogra_cmpc>
sudo update-alternatives --config x-session-manager
17:30
that sets the system default
17:30
(run it on the server)
17:31
<Furlow>
thanks
17:34
<ogra_cmpc>
vagrantc, did i tell you, the mythbuntu guys wrote a mythtv kiosk plugin :)
17:35
<Furlow>
it provide this message when i run that command "(/usr/bin/gnome-session). Nothing to configure." which is okay but when i try to login on a client it requires me to select the session and the default one isn't /usr/bin/gnome-session would there be anything else I can try.
17:35
<ogra_cmpc>
now people can have a server with tv card in the basement and a fanless thin client with the player in the living room
17:36
Furlow, hmm, it uses the default system session, which release and ltsp version are that ?
17:41
<Furlow>
ltsp-server-5.0.39 ltsp-server-standalone-5.0.39 ltspfs-0.5-0ubuntu2 ldm-5.0.39 ltsp-client-5.0.39 ltsp-client-core-5.0.39 ltspfsd-0.5-0ubuntu2
17:41
<ogra_cmpc>
thats gutsy then, right ?
17:41
<Furlow>
yeah
17:42
<ogra_cmpc>
did you add anything to your lts.conf ?
17:42
<Furlow>
yes I did let me get the output, im only using one client so far
17:43
<ogra_cmpc>
i9fr its more than three lines use the pastebot
17:43
!pastebot
17:43
<ltspbot>
ogra_cmpc: "pastebot" is The LTSP pastebot is at http://pastebot.ltsp.org. Please paste all text longer than a line or two to the pastebot, as it helps to reduce traffic in the channel. A link to the content will be pasted in the channel.
17:45
<ltsppbot>
"Furlow" pasted "my lts.conf" (6 lines) at http://pastebot.ltsp.org/442
17:45gonzaloaf_laptop has quit IRC
17:45sonjag has joined #ltsp
17:45
<Furlow>
there it is
17:46
<ogra_cmpc>
no need for
17:46
SOUND=Y
17:46
LOCALDEV=Y
17:46
NBD_SWAP=N
17:47
these are the defaults anyway
17:47
<Furlow>
okay
17:47sonjag has left #ltsp
17:47sonjagonzalez has joined #ltsp
17:47
<ogra_cmpc>
beyond that i dont see a reason that should prevent the default session from being run
17:47
<Furlow>
I was just experimenting although they don't do anything
17:48
<ogra_cmpc>
all ldm (the display manager) does is execute /etc/X11/XSession on the server ...
17:49
which by default will execute what ever the alternatives system is set to
17:49
(should be gnome-session)
17:50
what do you get if you just supply username and password at the greeter and hit enter ?
17:51gonzaloaf_laptop has joined #ltsp
17:53
<Furlow>
I will check that file and see if there is anything i can do, The problem is it does list metacity on the client and i selected to see if i get same results as the default session and I did so im guessing metacity is the default although it doen't list it with sudo update-alternatives --config x-session-manager and to your last question i get a blank screen and no flashing lights on my switch (indicating that no data is being s
17:54* ogra_cmpc reads the last comment and looks at vagrantc
17:54
<ogra_cmpc>
:P
17:55
Furlow, the selection you made only applied to the session you logged in to ... it doesnt change the default
17:55
check /var/log/auth.log and the users ~/.xsession-errors
17:56
it should list some erros indicating whats wrong
17:56
<Furlow>
I know that, but it happens as soon as i start up, i just selected it to see if it might be the problem
17:56
<vagrantc>
Furlow: try creating a new user and seeing if they get the same broken session
17:57
ogra_cmpc: regarding blindly copying all /etc/apt/apt.conf* stuff over, i think it's a bad idea. there are *so many* possible settings there, that it's hard to guage which would be appropriate for the thin-client.
17:57
<ogra_cmpc>
yeah, thats right
17:58
<vagrantc>
ogra_cmpc: i think simply pointing out the use of the http_proxy environment variable, or maybe even a commandline option to set that variable would be better.
17:58
<ogra_cmpc>
but i also thi9nk we're running on the same hardware with the same network
17:58
hmm
17:59
<vagrantc>
ogra_cmpc: yes, but some packages drop files into /etc/apt/apt.conf.d/ and i'm not sure how they'd behave if their corresponding package wasn't installed
17:59
<ogra_cmpc>
probably just a chec k if http_proxy is set and then export it in the client env
17:59
<vagrantc>
ogra_cmpc: you mean, check the configuration files?
18:00
<ltsppbot>
"Furlow" pasted "auth.log" (2 lines) at http://pastebot.ltsp.org/443
18:01
<vagrantc>
looking for Acquire::http::proxy "foo"; is trivial, but it could also be in the Acquire configuration block, http::proxy "foo"; or maybe even Acquire block, and the http block within the Acquire block, and proxy "foo";
18:02
<Furlow>
The lights on my switched blinked as i logged in that time and in auth.log it would show that it did get the password but does not indicate any x server crash
18:04
<ltsppbot>
"Furlow" pasted "auth.log" (2 lines) at http://pastebot.ltsp.org/444
18:04
<Furlow>
it uses a different port when selecting the gnome-session
18:05alekibango has joined #ltsp
18:08
<ltsppbot>
"Furlow" pasted "~/.xsession-errors" (24 lines) at http://pastebot.ltsp.org/445
18:08
<Furlow>
well that would explain
18:08
<vagrantc>
warren: your new set-arch plugin looks like there's no possible way to install amd64 on amd64 ... is that intentional?
18:10
warren: the --arch x86_64 would still result in ARCH=i386
18:11
warren: er, x86_64 on x86_64 ...
18:14
<Furlow>
would anyone know what i can do to fix my problem i you read my pastes
18:15
<ogra_cmpc>
Furlow, sudo apt-get remove xserver-xgl
18:15
(its unsupported for a reason ;) )
18:17
<Furlow>
I don't run a stand alone sever and I intend to use it to boost the performance of my laptop so will that remove my the desktop effects on the server machine
18:18
<ogra_cmpc>
you intend to use the most cpu intensive variant of getting composite to work to boost your system performance ?
18:18* ogra_cmpc scratches haed
18:19
<Furlow>
no
18:19
sorry bad wording
18:19
<ogra_cmpc>
:)
18:19
well, xgl isnt integrated with ltsp in any way
18:20
afaik they use an xsession script in /etc/X11/Xsession.d
18:20
<Furlow>
i mean i intend to use ltsp to boost my laptop performance and i wanted to know if "apt-get remove xserver-xgl" would remove the desktop effects on my server
18:20
<ogra_cmpc>
you need to hack up that script to not start xgl if LTSP_CLIENT exists in the sessions environment
18:22
it will remove the xgl xserver ... depends what kind of graphics card you have, afaik xgl only helps wiht composit4e with a certain amount of ati cards ... for all other HW you should use the defauklt method ubuntu ships
18:22
<Furlow>
hum it says its a directory, do open one of the scripts in that folder
18:23
<ogra_cmpc>
well there should be a script with xgl in the filename
18:23
<Furlow>
I got it
18:23
so what do i need to ass
18:23
add
18:23
sorry
18:24
<ogra_cmpc>
nol idea, i dont know xgl :) just makwe sure it doesnt use the xgl server
18:24
<Furlow>
Okies I will try and figure that out myself but thanks for help
18:25
<ogra_cmpc>
i9'd really suggest not using xgl
18:25
<Furlow>
is there an alternative i have ati by the way
18:26
<ogra_cmpc>
well, ati either works with compiz in the default install (just check teh checkbox in teh settings)
18:26
<Furlow>
surely you need xgl so compiz will work???
18:26
<ogra_cmpc>
or you are one of the few souls that actually have one of the three or four cards that actually *need* xgl
18:27
<Furlow>
I think that I am
18:27
i've had many great troubles with xgl and compiz and what not
18:28
<ogra_cmpc>
well in any case fglrx (the ati binary driver) forces xgl ... if you use the free driver the majority of ati cards works out of the box
18:28
well, easy solution, use sane softwarer
18:28
(xgl doesnt belong in that realm)
18:30
the majority of cards should work without and extra software in ubuntu just by switching on the desktop effects
18:32
xgl actually runs a second xserver inside the running xorg server to get composite ... that means you always run two x servers
18:32
which indeed quite heavily eats your ressources
18:39
<Furlow>
yeah i guess so, long time since i fiddled with xgl and im using fglrx, I will try to use the free driver, i think my problem stemed from needing higher resolutions and the card would not produce it with out fglrx that was with a crt and since then I have switch to a lcd i got second hand for free
18:40
<ogra_cmpc>
ah
18:41
<Furlow>
i guess it might just be easier to switch to nvidia form ati in the future which is what i will do
18:41
<ogra_cmpc>
or get intel
18:41sonjagonzalez has quit IRC
18:41
<ogra_cmpc>
(unless youre a heavy gamer or 3D professional)
18:41
<Furlow>
yeah or intel which is what the laptop is
18:42
thanks for your help i have to go now
18:42Furlow has left #ltsp
18:43joebaker has quit IRC
18:46gonzaloaf_laptop has quit IRC
18:49SteveWrightNZ has joined #ltsp
18:50
<SteveWrightNZ>
blank terminals after apt-get dist-upgrade - any hint ?
18:50
(ubuntu latest)
18:51
terminals boot, dont start X
18:51
<ogra_cmpc>
latest meaning hardy or latest release ?
18:51
<SteveWrightNZ>
how to tell ?
18:51
7.10 gutsy
18:51
<ogra_cmpc>
lsb_release -a
18:51otavio has quit IRC
18:51
<ogra_cmpc>
ah
18:52
how exactly did you dist-upgrade ?
18:53
<SteveWrightNZ>
using the GUI updater
18:53
"7.10 is available - do u wanna?" etc
18:53
<ogra_cmpc>
well, that doesnt update the client environment at all
18:53
<SteveWrightNZ>
k
18:53
<ogra_cmpc>
it doesnt change anything in there
18:53
<SteveWrightNZ>
so why it stop if from working then ?
18:54
update the chroot as well ?
18:54
<ogra_cmpc>
no idea, how exactly does the screen look like if it finished booting ?
18:54
<SteveWrightNZ>
black, blinking cursor
18:54
top left ;-)
18:55
<ogra_cmpc>
so it properly boots...
18:55
thats the only thing that could have been influenced by a server upgrade
18:55
<SteveWrightNZ>
yes it boots
18:56
then busybox pops up
18:56
after a few mins
18:56
<ogra_cmpc>
you must have changed anything ... did you add any options to your lts.conf or so ?
18:56
<SteveWrightNZ>
no
18:56
<ogra_cmpc>
you said you egt a blinking cursor ...
18:56
<SteveWrightNZ>
yes this is true
18:56
<ogra_cmpc>
\now you say busybox pops up
18:56
<SteveWrightNZ>
yes I did say that
18:57
<ogra_cmpc>
so do you end up in a busybox or do you end up at a blinking cursor ?
18:57* ogra_cmpc is confused
18:57
<SteveWrightNZ>
perhaps someone else has seen this fault
18:58
<ogra_cmpc>
again ... how exactly does the screen look like if it *finished* booting
18:58
<SteveWrightNZ>
(initramfs)_
18:58
<ogra_cmpc>
do you have a busybox shell or not ?
18:58
ah
18:58
ok
18:59
did you get any questions about changed config files during the upgrade ?
18:59
<SteveWrightNZ>
yes
18:59
<ogra_cmpc>
do you remember the packages/files ?
18:59staffencasa has quit IRC
19:00
<SteveWrightNZ>
it is quite likely the dist-upgrade overwrote a valid conf file
19:00
not really, but I would likely recall the names if I saw then again
19:00
I should have written this down but oh well
19:00
<ogra_cmpc>
dhcpd.conf, inetd.conf would be relevant
19:00
<SteveWrightNZ>
not those
19:00
dhcpd is working
19:00
as it booted
19:01
<ogra_cmpc>
well, check if nbdrootd is still listed in inetd.conf
19:01
<SteveWrightNZ>
ok
19:01
brb
19:01
<ogra_cmpc>
thats responsible for the root fs
19:01gonzaloaf has joined #ltsp
19:01
<vagrantc>
ogra_cmpc: commented on lp#132397 with some tricks that might be palatable
19:02
<ogra_cmpc>
thanks :)
19:02
<SteveWrightNZ>
ogra_cmpc: no it is not mentioned
19:02gonzaloaf_laptop has joined #ltsp
19:02
<vagrantc>
not beautiful ...
19:02
<ogra_cmpc>
SteveWrightNZ, oh, weird
19:03
SteveWrightNZ, 2000 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdrootd /opt/ltsp/images/i386.img
19:03
<SteveWrightNZ>
ok trying
19:03
<ogra_cmpc>
there should be this line
19:04
<SteveWrightNZ>
done, inetd restarted, rebooting
19:05
black screen, blinking cursor
19:05
<ogra_cmpc>
btw, you can drop splash and quiet from /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default to get more debugging info
19:05
<SteveWrightNZ>
ah ok
19:06
aha
19:06
<ogra_cmpc>
you should also see the nbd mount attempt in the daemon.log on the server
19:06
<SteveWrightNZ>
NFS over TCP not available
19:06
<ogra_cmpc>
gutsy doesnt use nfs
19:06
<SteveWrightNZ>
/ltsp/i386/nbi.img
19:06
alt-F1
19:07
<ogra_cmpc>
(at least not unless you enabled it manually with some effort)
19:07
<warren>
vagrantc, are you sure?
19:07
<vagrantc>
but if the chroot wasn't updated, it's still feisty or older, isn't it?
19:07
<SteveWrightNZ>
this error loops continually on the terminal
19:07
chroot was not dist-update d
19:07
<vagrantc>
warren: i am pretty sure.
19:07
<warren>
oh
19:07
oops
19:07
<ogra_cmpc>
vagrantc, hmm, right, i didt read dist/upgarde as distro upgarde
19:08
*dist-upgrade
19:08
warren, he's right
19:08
<SteveWrightNZ>
chroot is stil fiesty
19:09
<ogra_cmpc>
SteveWrightNZ, sudo mv /opt/ltsp/i386 /opt/ltsp/i386.feisty && sudo ltsp-build-client
19:10
<vagrantc>
warren: the way the plugin is written, ARCH_OPT always gets set to something, and you have all cases of when ARCH_OPT is set to x86_64 to have it set ARCH=i386
19:10
<SteveWrightNZ>
ok
19:10
<warren>
yeah
19:10
I'm thinking how best to fix this.
19:10
so it is overridale
19:10
overrideable
19:10
<ogra_cmpc>
put ARCH=i386 into the *) option :)
19:10
<SteveWrightNZ>
sudo mv /opt/ltsp/i386 /opt/ltsp/i386.feisty && sudo ltsp-build-client // running now
19:10
<warren>
ia64 makes no sense to be in that list.
19:10* vagrantc didn't like that plugin code from the instant it was written
19:11
<ogra_cmpc>
and only override on ppc/x86_64
19:11
warren, ubuntu has an ia64 builld (and actually ltsp is working on that i heard)
19:11
<vagrantc>
i sat there, looking over otavio's shoulder, saying ... this is a bad idea.
19:12
ogra_cmpc: does ia64 support i386 chroots ?
19:12
<warren>
vagrantc, sort of
19:12
vagrantc, it is a complete mess
19:12
<ogra_cmpc>
not by definition of our code, no
19:12
<vagrantc>
no, i mean can you chroot to an i386 chroot on an ia64 architecture?
19:12
<warren>
vagrantc, some ia64 has extra hardware to run i386, most ia64 lacks that hardware and intel wrote a binary-only emulation layer that lives in /emul/i386
19:13
<ogra_cmpc>
vagrantc, but its a quick way to get a wroking netboot env ;)
19:13
<warren>
vagrantc, but if it lives in /emu/i386 what happens if you run stuff in a chroot elsewhere? I don't know.
19:13
<vagrantc>
so the sort answer is "not really"
19:13
<warren>
vagrantc, the kernel has nasty hacks to sort of use /emul/i386 as if it were a root
19:13
<ogra_cmpc>
i doubt you have much fun on an ia64 ltsp server anyway
19:13
<warren>
yea
19:13
ia64 really sucks
19:14gonzaloaf_laptop has quit IRC
19:14* vagrantc has been nudging to drop all arches but i386, amd64 and powerpc for debian's ltsp packages
19:14
<ogra_cmpc>
makes as much sense as having an s390 build
19:14
vagrantc, arm would make sense for debian i suppose
19:15* ogra_cmpc would love to do/have arm support, but ubuntu doesnt support arm
19:15
<vagrantc>
ogra_cmpc: when we have tested netboot stuff for arm, i'd consider it
19:16
ogra_cmpc: right now the only netboot stuff that's tested is i386, powerpc and amd64 (and the latter two not very thoroughly tested), as well as untested code for sparc and alpha.
19:16
<ogra_cmpc>
doesnt familiar have working netboot modes for arm ?
19:16
sparc works afaik
19:17
<vagrantc>
sparc doesn't work at all with debian unstable or testing
19:17
<ogra_cmpc>
fabio said so back in edgy/feisty some point
19:17
<vagrantc>
well, not with the network booting used in initramfs-tools ...
19:17
<ogra_cmpc>
i didnt hear any recent sparc info
19:17
<vagrantc>
bugs in klibc-utils
19:18
<ogra_cmpc>
well, ubuntu supports sparc and we have a netinstall image
19:18
so it must work somehow with our initramfs
19:18
s/supports/supported (we dont anymore afaik)
19:18
<vagrantc>
ogra_cmpc: well, debian-installer netinstall probably uses dhcp3-client instead of ipconfig from klibc-utils
19:19
<ogra_cmpc>
oh, right, that might be
19:19
<vagrantc>
ogra_cmpc: so i hacked around ipconfig ... and then nfsmount from klibc-utils also broke ...
19:19
ogra_cmpc: maybe it would work with nbd
19:20
<ogra_cmpc>
just use mount
19:20
<vagrantc>
well, mount doesn't work for nfs mounts from the initramfs eitehr
19:20
tried that
19:20
<ogra_cmpc>
huh ?
19:20
<vagrantc>
yup
19:20
<ogra_cmpc>
i used it in ltsp before
19:20
<vagrantc>
so have i
19:20
but the versions in sid don't work
19:20
<ogra_cmpc>
weird
19:21
<vagrantc>
they give some error about looking for /sbin/mount.nfs ... which doesn't exist on the server which can do nfs mounts using /bin/mount
19:21
<ogra_cmpc>
ah
19:22
<SteveWrightNZ>
why couldn't have done sudo chroot /opt/ltsp/i386 && apt-get dist-upgrade ?
19:22
<ogra_cmpc>
vagrantc, add nfs/common to your initramfs :)
19:22
grr
19:23
<vagrantc>
ogra_cmpc: nfs-common ?
19:23
<ogra_cmpc>
why do you english guys just have to change all key positions
19:23
yeah
19:23
thats where mount.nfs lives
19:23
<warren>
ogra, ASCII begins with American =)
19:23
<ogra_cmpc>
pfft
19:23
<vagrantc>
ogra_cmpc: but it's not even needed ...
19:24
<ogra_cmpc>
warren, no reason to change y and z or / and -
19:24
vagrantc, i think mount requires such stuff nowadays
19:25
<vagrantc>
ogra_cmpc: ah, you're right ... it's there. ok ... i'll give sparc a couple more tries.
19:25
<warren>
ogra_cmpc, the QWERTY layout was an arbitrary layout designed to slow down typing so the keys of the typewriter wouldn't get stuck together as people typed too fast.
19:25
<ogra_cmpc>
hehe, really ?
19:25
<warren>
ogra_cmpc, yeah. My mom has one of those old typewriters. If I type too fast they get stuck
19:25
<vagrantc>
ogra_cmpc: altough really... having to hack the initramfs to use dhcp3-client and /bin/mount and /sbin/mount.nfs ... not my idea of fun
19:25
but i guess that would at least be useful troubleshooting feedback
19:26
<ogra_cmpc>
warren, well, i have such a thing here as well, but i didnt know there was a case in human history that early already where usability workarounds tried to overcome hardware issues
19:27
i wouldnt have tought that was the reason for the layout :)
19:27
<vagrantc>
that's just dvorak conspiracy theorists.
19:28* ogra_cmpc always tought layouts were defined by the frequency a letter shows up in a language
19:28* vagrantc notes that it is based on frequency... just not necessarily in the way you might think
19:28
<ogra_cmpc>
vagrantc, well, its only a special hook for sparc, you dont need to copy iy into a normal one :)
19:29
<warren>
ogra_cmpc, it was designed so you wouldn't type keys that are close together so they don't get stuck
19:31joebaker has joined #ltsp
19:32spectra has quit IRC
19:33gentgeen__ has quit IRC
19:34
<vagrantc>
well, i just pushed the ldm guest login button patches to ldm... hopefully now i can say goodbye to sdm! :)
19:36
<ogra_cmpc>
youre becoming a C coder eh ? :)
19:36
<vagrantc>
ogra_cmpc: no, Ryan52 has been rocking it out!
19:36
ogra_cmpc: i mean, i'm a better C patcher than i was
19:37
between a few ldm and ltspfs patches, i'm slowing moving beyond totally clueless
19:38
<ogra_cmpc>
ah, well, your patches looked quite sane
19:39
<vagrantc>
but most of the heavier work has been done by Ryan52
19:39
<ogra_cmpc>
you will need the consolekit changes to openssh for the recent gnome btw
19:40
<vagrantc>
ogra_cmpc: what's recent?
19:40
<ogra_cmpc>
not sure if colin applied them to debian and synced tha6t
19:40
the current dev version
19:40
<vagrantc>
looking at a few stages of freeze over the next few months
19:40
<ogra_cmpc>
(2.21 ... upcoming 2.22 release)
19:40
lenny will likely have 2.20
19:41
but for sid you'll need it
19:41
<vagrantc>
currently 2.20 in unstable, 2.14 in lenny ...
19:41
<ogra_cmpc>
woah, really ?
19:41
2.14 is ages old
19:43
<vagrantc>
ogra_cmpc: looks like it hasn't ever migrated from sid to lenny ... it's the same version that's in etch
19:43
<ogra_cmpc>
are you sure its 2.14 ?
19:43
oh
19:43
thats bitter
19:44
a new release with the same old desktop software is a bad idea
19:44
<vagrantc>
i'magine it'll make it to 2.20
19:45
<ogra_cmpc>
depending on your freezes
19:47
<vagrantc>
there's a few RC bugs, and some slow buildd's ...
19:48
<ogra_cmpc>
i thought the slow arches would be ignored now
19:48
<vagrantc>
i don't think any architecture re-qualification has happened yet ...
19:48
<ogra_cmpc>
intresting ...
19:49
i remember when it was discussed 2 years ago when elmo went to that special ftpmasters meeting
19:50
2 years and still no change is quite slow ...
19:50* ogra_cmpc noticed today that ian murdoc seems to work for sun now ...
19:51
<ogra_cmpc>
doing opensolaris desktop integration
20:08
<SteveWrightNZ>
I: Retrieving startup-tasks ## stuck here why ?
20:20
<jcastro>
warren: around?
20:20
<warren>
jcastro, what's up?
20:25rjune has quit IRC
20:33joebaker has quit IRC
20:35joebaker has joined #ltsp
20:55
<warren>
case "$ARCH_OPT" in
20:55
i386)
20:55
case "$(uname -m)" in
20:55
x86_64|ia64|i386|i486|i586|i686)
20:55
ARCH=i386
20:55
;;
20:55
esac
20:55
this part actually doesn't make sense
20:56
It is *possible* to install a i386 chroot on ppc host with qemu.
20:56
qemu can be either a full VM or process-level VM
21:01joebake1 has joined #ltsp
21:02joebaker has quit IRC
21:06jammcq has joined #ltsp
21:06
<SteveWrightNZ>
hello Jim
21:07
<jammcq>
hey SteveWrightNZ, how's it goin?
21:07
<SteveWrightNZ>
good good, and how are you ?
21:07
Ubuntu+LTSP is very good now
21:08
<jammcq>
yeah, they've done a fantastic job
21:08
and i'm doing well. mostly watching the development these days
21:08
<SteveWrightNZ>
the old days of attaching scanners with hammer and saw are over
21:08
ok
21:09
how are the k12ltsp lads doing ?
21:09
<warren>
SteveWrightNZ, working on it
21:09
<jammcq>
umm, well, I guess
21:09
<warren>
SteveWrightNZ, i'm the only one working on it, been hampered by health problems
21:09
<SteveWrightNZ>
hi warren
21:09
oh thats not so good
21:09
<jammcq>
warren: are you working on anything other than ltsp integration?
21:09
<warren>
jammcq, yes, a few other unrelated things unfortunately
21:10
<jammcq>
hmm
21:10
<warren>
jammcq, and our mkinitrd and chroot install problems have been much larger than I thought.
21:10
jammcq, it turns out that nobody else has anything like my problem
21:10
pieces are finally falling together now though.
21:10
<SteveWrightNZ>
does FC slide together with LTSP as well as Ubuntu does ?
21:11
<warren>
SteveWrightNZ, it will by Fedora 9
21:11
<SteveWrightNZ>
nice
21:11
<warren>
SteveWrightNZ, currently due to be released late April
21:11
<jammcq>
warren: cool. keep chipping away at it, and eventually it'll look great
21:11
<SteveWrightNZ>
nice
21:13oh207 has quit IRC
21:13oh207 has joined #ltsp
21:22joebake1 has quit IRC
21:22joebaker has joined #ltsp
21:42
<vagrantc>
warren: all you need now is one more "
21:43
- [ "$ARCH_OPT" == "x86_64 ] && ARCH_OPT=i386
21:43
+ [ "$ARCH_OPT" == "x86_64" ] && ARCH_OPT=i386
21:46
<MacIver>
that is soo evil
21:47* vagrantc grins
21:49
<vagrantc>
"LTSP: go ahead and be evil, the rest is allegedly google's motto"
21:50
<MacIver>
took me about 30 seconds to see wtf that was doing :-p
22:12Joris_ has joined #ltsp
22:12
<SteveWrightNZ>
after ltsp-build-client I get a black screen on the terminal with blinking cursor.. any hint ?
22:12
Ubuntu 7.10
22:15
<MacIver>
ltsp-update-*
22:22oh207 has quit IRC
22:25
<SteveWrightNZ>
thx
22:28Joris has quit IRC
22:35rjune has joined #ltsp
22:40subir has joined #ltsp
22:41
<SteveWrightNZ>
MacIver: no change
22:41joebaker has quit IRC
22:42
<SteveWrightNZ>
TFTTP: File not found /ltsp/i386/lts.conf
22:47
<MacIver>
weird error
22:47
did you get any errors from the build?
22:47
<SteveWrightNZ>
a few warnings
22:47
but hard to tell what is fatal or not
22:47
also, there is no lts.conf
22:48
well, there is but it has one line in it
22:48
[default]
22:48
LTSP_VERSION=5.0.39
22:51
<MacIver>
hmm, i'm no ltsp expert...i have only used it on edubuntu so far :-p
22:51
<SteveWrightNZ>
the terminal does its IP-Config
22:51
then just says ltsp login:
22:51
<MacIver>
does it get the kernel image?
22:51
<SteveWrightNZ>
yes it boots fine
22:51
<MacIver>
oh, so it does have the login prompt?
22:51
<SteveWrightNZ>
yes
22:51
just no X
22:51
<MacIver>
it's just that ldm is not starting?
22:51
<SteveWrightNZ>
so it seems yes
22:52
lts.conf has no config in it
22:52
is this correct ?
22:52
<MacIver>
that should be ok
22:52
<SteveWrightNZ>
there is also an error "unknown keyword in config file"
22:53
before loading vzlinuz
22:53
vmlinuz
22:54
<MacIver>
probably that LTSP_VERSION part... i never saw that as a lts option :-p
22:54
which makes me wonder where that file came from...
22:54
<SteveWrightNZ>
agreed
22:54
ltsp 5 lts.conf file where to get one from ?
22:55
with no lts.conf file it seems that should be resolved.. no ?
22:55
in the past, that was the heart of the terminal config
22:55
<MacIver>
on edubuntu it didn't come with one, but i could create my own if needed
22:55
<SteveWrightNZ>
but usually not needed ?
22:56
<MacIver>
not unless you are needing to set non-default, or machine specific settings
22:56
<SteveWrightNZ>
ok I will ignore this then
22:59
can I log onto the running terminal image ?
23:01
<MacIver>
you can if you add yourself as a user
23:14
<SteveWrightNZ>
adduser in the chroot ?
23:16
that didnt work.. rebooting..
23:17
how can a simple dist-upgrade go this wrong ?
23:27
<MacIver>
you need to adduser and the ltsp-update-image
23:32
<SteveWrightNZ>
oh
23:32
I'm going to retry sudo ltsp-build-client
23:47
<vagrantc>
SteveWrightNZ: you dist-upgraded from what to what?
23:47
<SteveWrightNZ>
fiesty to gutsy
23:48
7.04 to 7.1
23:48
and I am left with a screaming heap
23:48
or is it a steaming pile ?
23:48
server is fine
23:49
terminals boot but no X