00:11 | epaphus2 has left IRC (epaphus2!~epaphus@200.122.149.9, Ping timeout: 252 seconds) | |
00:12 | NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, Ping timeout: 252 seconds) | |
00:12 | NeonLicht has joined IRC (NeonLicht!~NeonLicht@darwin.ugr.es) | |
00:14 | freedomrun has left IRC (freedomrun!~quassel@89.142.248.83, Remote host closed the connection) | |
00:14 | killermike has joined IRC (killermike!~killermik@2.26.103.46) | |
00:14 | epaphus2 has joined IRC (epaphus2!~epaphus@200.122.149.9) | |
00:20 | monteslu_ has joined IRC (monteslu_!~monteslu@ip68-109-174-213.ph.ph.cox.net) | |
00:23 | monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 260 seconds) | |
00:53 | vedranm has left IRC (vedranm!~vedranm@inf2.ffri.hr, Quit: leaving) | |
01:32 | Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving) | |
01:53 | adrianorg_ has left IRC (adrianorg_!~adrianorg@186.213.152.248, Ping timeout: 265 seconds) | |
02:21 | vagrantc has left IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net, Ping timeout: 245 seconds) | |
03:02 | andy__ has left IRC (andy__!~andy@h247.95.31.71.dynamic.ip.windstream.net, Ping timeout: 240 seconds) | |
03:30 | killermike has left IRC (killermike!~killermik@2.26.103.46, Remote host closed the connection) | |
03:30 | killermike has joined IRC (killermike!~killermik@2.26.103.46) | |
03:50 | Parker955_Away is now known as Parker955 | |
04:00 | alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net) | |
04:12 | andygraybeal has left IRC (andygraybeal!~andy.gray@obsidian.casanueva.com, Excess Flood) | |
04:13 | andygraybeal has joined IRC (andygraybeal!~andy.gray@obsidian.casanueva.com) | |
04:34 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, *.net *.split) | |
04:37 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
04:50 | Parker955 is now known as Parker955_Away | |
05:02 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
05:12 | <alkisg> Plymouth fails to start even if I just put init=/sbin/init in grub, so it's not ltsp-init's fault
| |
05:32 | Something evil, probably plymouth itself, checks for init=* in the kernel command line, and hides plymouth in that case
| |
05:33 | stgraber: By renaming /sbin/init to /sbin/init.real, and /sbin/ltsp-init to /sbin/init, plymouth worked fine. I'll file a bug in plymouth about it.
| |
05:39 | Found it, in plymouth's changelog:
| |
05:39 | * Restored code to disable Plymouth's graphical plugins when an alternate
| |
05:39 | init= is given on the kernel command-line, otherwise init=/bin/bash
| |
05:39 | doesn't work so well when Plymouth is in the initramfs.
| |
05:40 | plymouth (0.8.1-1), 26 Mar 2010
| |
05:52 | They do support another kernel command line parameter to force showing the splash screen though: plymouth:force-splash
| |
05:52 | ...which works
| |
05:57 | stgraber: so we can either put that additional kernel parameter in pxelinux.cfg/default, or if you could ask scott@ubuntu... if he wants to restrict disabling the graphical plugins only in the init=/bin/bash or even init=/bin/* cases.
| |
05:58 | Even if he just allows /sbin/init*, we can name ours /sbin/init-ltsp
| |
06:02 | Filed a bug about it, https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/930865
| |
06:08 | <muppis> Does Plymouth have any other functionality than just showing splash?
| |
06:12 | At work we faced a problem where plymouth caused a hang in ro nfs root. Tried to remove, but depencies were something incredible that we looked other way round.
| |
06:13 | Which was not what we wanted, but works.
| |
06:47 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 240 seconds) | |
07:01 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
08:12 | loather has left IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep) | |
08:24 | <alkisg> In case anyone's interested, I just wrote a 'how to create an nbd file-based "partition", for development purposes, to be able to quickly do changes in the chroot without having to run ltsp-update-image' all the time:
| |
08:24 | https://help.ubuntu.com/community/HowToSetupLTSPDevelEnvironment#Using_an_NBD_file-based_.22partition.22
| |
09:02 | khildin has joined IRC (khildin!~khildin@ip-80-236-223-208.dsl.scarlet.be) | |
09:18 | <alkisg> /dev/nbd0 /rofs btrfs...!!! Cool! Exporting btrfs compressed images works by default on Precise
| |
09:19 | So it's possible to only have a fat chroot in a file, /opt/ltsp/images/i386.img, without needing /opt/ltsp/i386 and without ever needing to run ltsp-update-image
| |
09:22 | freedomrun has joined IRC (freedomrun!~quassel@89.142.248.83) | |
09:24 | <alkisg> qemu can use a file-based partition as a VM hard disk, right? So it should now be almost possible to maintain fat chroots graphically
| |
09:36 | freedomrun_ has joined IRC (freedomrun_!~quassel@89.142.248.83) | |
09:37 | freedomrun has left IRC (freedomrun!~quassel@89.142.248.83, Ping timeout: 252 seconds) | |
10:16 | khildin has left IRC (khildin!~khildin@ip-80-236-223-208.dsl.scarlet.be, Ping timeout: 240 seconds) | |
10:19 | adrianorg_ has joined IRC (adrianorg_!~adrianorg@187.115.110.202) | |
10:29 | khildin has joined IRC (khildin!~khildin@ip-80-236-212-243.dsl.scarlet.be) | |
10:55 | freedomrun_ has left IRC (freedomrun_!~quassel@89.142.248.83, Remote host closed the connection) | |
11:25 | piet has joined IRC (piet!5b605e82@gateway/web/freenode/ip.91.96.94.130) | |
11:27 | <piet> hi folks, got my fat-clients run completely. Everythings runs fine. There are only error-messages messing up my boot-screen . . .
| |
11:29 | <No caching mode page present> and <Assuming write cache: write through> are showing up . . .
| |
11:29 | freedomrun has joined IRC (freedomrun!~quassel@89.142.248.83) | |
11:30 | <piet> according to dmesg it has something to do with sdb2 which is a sound stick for audio with a little fat where win-divers are located . . .
| |
11:30 | this thing is only readeable si that might have something to do with it . . .
| |
11:32 | my Question now is: is there any chance to get rid of the message screwing up the boot screen, because there is no other negative effect.
| |
11:41 | andy__ has joined IRC (andy__!~andy@h247.95.31.71.dynamic.ip.windstream.net) | |
11:43 | Yet_another_Bill has left IRC (Yet_another_Bill!billy@nat/redhat/x-jqcjudpixndyzmep, Quit: Good night ^_^) | |
11:48 | <alkisg> piet: if you put it in the server and run dmesg, don't you see the same messages?
| |
11:48 | (or in any other machine, not ltsp-clients...)
| |
11:49 | freedomrun has left IRC (freedomrun!~quassel@89.142.248.83, Remote host closed the connection) | |
12:09 | <piet> no, I have an ubuntu set on the local disc of the fat client. Starting that no message appears.
| |
12:23 | monteslu_ is now known as monteslu | |
12:36 | toscalix has joined IRC (toscalix!~toscalix@85.137.146.26.dyn.user.ono.com) | |
12:41 | piet has left IRC (piet!5b605e82@gateway/web/freenode/ip.91.96.94.130, Quit: Page closed) | |
12:44 | Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71) | |
12:52 | piet has joined IRC (piet!5b605e82@gateway/web/freenode/ip.91.96.94.130) | |
12:53 | <piet> @alkisg: so back again I just checked the dmesg-log and indeed the message shows up there, as well. Means the problem is not ltsp-orientated . . .
| |
12:55 | @alkisg I aspected this. Because I don't want to write to this medium necessarlily - I don't mind the problem but under native ubuntu the error message appaears in the log, but not on boot-screen . . .
| |
12:55 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Remote host closed the connection) | |
12:56 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
12:56 | <alkisg> piet: grep append /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
| |
12:56 | What's the output of that command?
| |
12:56 | <piet> @alkisg My question was : Is there a chance to prevent this message while booting?
| |
12:56 | <alkisg> (on your server)
| |
12:58 | <piet> wait a minute I'll try it . . .
| |
12:59 | @alkisg # grep append /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default append ro initrd=initrd.img quiet splash nbdname=ltsp_i386
| |
13:01 | <alkisg> Sounds OK... piet, please file a bug about this in launchpad
| |
13:01 | !ubuntu-bug
| |
13:01 | <ltsp`> alkisg: ubuntu-bug: To file a bug report for Ubuntu LTSP, go to https://bugs.launchpad.net/ubuntu/+source/ltsp
| |
13:02 | <piet> @alkisg ok, I will try my best, thank You
| |
13:12 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
13:17 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
13:37 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
13:53 | khildin has left IRC (khildin!~khildin@ip-80-236-212-243.dsl.scarlet.be, Read error: Operation timed out) | |
14:01 | Parker955_Away is now known as Parker955 | |
14:08 | komunista has joined IRC (komunista!~slavko@adsl-195-098-005-032.dynamic.nextra.sk) | |
14:12 | khildin has joined IRC (khildin!~khildin@ip-80-236-212-243.dsl.scarlet.be) | |
14:13 | [GuS] has joined IRC ([GuS]!~MysT@unaffiliated/gus/x-663402) | |
14:29 | mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk) | |
14:54 | ba has joined IRC (ba!~ba@airport.kg) | |
14:55 | <ba> hi guys! can you tell me..how to determine how much megabytes sends LTSP server to the CLIENT before it shows LDM? umm, I guess it's completely depends on a nbd image right?
| |
15:00 | toscalix has left IRC (toscalix!~toscalix@85.137.146.26.dyn.user.ono.com, Remote host closed the connection) | |
15:13 | <komunista> ba: I never measure this exactly, but it sends the initrd image, NBD image is not send at all, but mounted via network and after this mount (IMO) only needed files are transferred, to they can be executed/readed and some communication between ldm and ldm server happens...
| |
15:14 | <ba> komunista, got it!
| |
15:14 | komunista, thank you!
| |
15:30 | is there any way to mount nbd image allowing writes? (i.e not readonly). Say to update it from one Client and then make it readonly again.
| |
15:32 | <piet> @alkisg: Did my best: https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/931007, never did that before, one time will always be the 1st time ;-) hope that's professional enough :)
| |
15:33 | <alkisg> piet: very nice :)
| |
15:33 | ba: are you using fat clients?
| |
15:33 | <ba> alkisg, yes
| |
15:34 | <alkisg> Currently it's not possible, unless if you switch from nbd to nfs and export it rw and mount only one client etc etc, it's messy
| |
15:34 | In some of the next versions it'll be much easier to do it
| |
15:34 | <ba> alkisg, 12.04? :D
| |
15:34 | <alkisg> You'll even be able to boot the chroot with vbox and customize it there
| |
15:35 | Half of the necessary stuff will be there in 12.04, but not all of it
| |
15:35 | So it will be possible in 12.04 but it will still not be very easy to do it
| |
15:35 | <ba> alkisg, is there any new features coming with 12.04? so we can test?
| |
15:35 | alkisg, I would love to test..
| |
15:36 | <alkisg> ba: currently it's not really ready for user testing, only experienced users/developers may help now
| |
15:36 | In a couple of weeks, it will be
| |
15:37 | <ba> alkisg, ok. cool. Btw it would be extremely demanding feature since not all the stuff can be installed within the server and ltsp-chroot. Like drivers etc. If we could mount with write permissions we could install those drivers and turn them back to readonly mode..
| |
15:37 | alkisg, Citrix's Provisioning Server supports it :D
| |
15:38 | <alkisg> Yeah, I know how cool it will be. E.g. install ubuntu in a client with drivers and everything, apt-get install ltsp-client, copy the result to the server, ready
| |
15:38 | No ltsp-build-client necessary
| |
15:38 | <ba> alkisg, exactly
| |
15:38 | <alkisg> Personally I don't care at all about citrix or any other companies though... :D
| |
15:39 | <ba> alkisg, ok. me too now. I avoid their products :D
| |
15:39 | <alkisg> I'm not selling ltsp so I'm not competitive :P
| |
15:39 | I'm just using it in my classrooms :D
| |
15:39 | <ba> alkisg, ok ok..I just mentioned it for ideas
| |
15:40 | alkisg, if it's not a secret how much clients do you have?
| |
15:40 | <alkisg> It's fun thought that I first thought about this, then tried to implement it, and then a week or so ago I heard that citrix was doing the same thing
| |
15:40 | No it's not a secret, personally I've only one school lab but I'm supporting about 250 schools with about 12 clients each
| |
15:41 | <ba> alkisg, cool
| |
15:46 | <alkisg> About new features... the main new feature is what you're saying, i.e. a new direction where the chroots will be able to be upgraded or booted from normal PCs too, or even you'll be able to install ltsp-client to a normal pc and boot it as an ltsp client
| |
15:46 | But it's halfway there, not ready yet
| |
15:48 | <khildin> alkisg: does this mean you can have a local copy of the chroot on a standard client?
| |
15:49 | <alkisg> khildin: yes, it also means you can install your distro normally on a standard client and then install ltsp-client, and that's your ltsp chroot, without using ltsp-build-client at all
| |
15:49 | <khildin> that is the best news I have heard in a looooong time... ^^
| |
15:49 | how will it deal with updates on the LTSPserver?
| |
15:50 | is there a check mechanism that compares local copy with server chroot?
| |
15:50 | <alkisg> You can e.g. have 8.04 chroots with 12.04 servers now, they're not much related to the server
| |
15:50 | Ah no I didn't mean what you understood
| |
15:50 | <khildin> then what?
| |
15:50 | <alkisg> It will be possible to boot the local pc with that, yes, but the copying is your responsibility
| |
15:51 | <khildin> can you use a different distro/desktopmanager in chroot than installed in server?
| |
15:51 | <alkisg> Now it's not possible to boot the local pc with an ltsp chroot even if you transfer it yourself
| |
15:51 | Sure, you can
| |
15:52 | <khildin> What will be necessary to have that check/copy done automaticly?
| |
15:53 | <alkisg> Someone to implement it? :D Maybe using rsync over ro NFS?
| |
15:53 | But it'll be slow, I don't like that method
| |
15:53 | I'd prefer a caching solution instead of that
| |
15:53 | <khildin> Actualy I am busy coordinating a desktop sollution for Zentyal server.... and LTSP is one of the possible options...
| |
15:54 | <alkisg> What is a "desktop solution" ?
| |
15:56 | <ba> alkisg, nice. any other tasty features? :D P.S: move on please :D
| |
15:56 | <khildin> a desktop client that actualy is centrally manageble by a sys admin
| |
15:57 | <alkisg> And why rsync locally instead of just netbooting it without a hard disk?
| |
15:58 | <khildin> to limit local bandwith usage?
| |
15:58 | <alkisg> I don't think that will work, updates are very large, caching would limit the bandwidth 10 times better
| |
15:59 | <khildin> cache localy?
| |
15:59 | fine with me... :)
| |
15:59 | <alkisg> Yes, whatever the client reads from the network, to store it locally to be reused later, as long as it's not changed on the server
| |
15:59 | <khildin> that's what I am looking for ...
| |
15:59 | <alkisg> Though I don't know of anyone working on implementing this :)
| |
15:59 | <khildin> would be great
| |
16:00 | and also would be usable for 'road warriors' that are not on the network
| |
16:00 | or am I asking too much now?
| |
16:00 | :D
| |
16:00 | <alkisg> Sure, it would
| |
16:00 | <ba> alkisg, can you confirm that currently if Fat Clients changes something (like installs a program) all the changes are in RAM and not on the server?
| |
16:01 | <alkisg> ba: yup
| |
16:01 | Also he normally can't install anything, sudo doesn't work
| |
16:01 | <ba> alkisg, but it's root (with SCREEN_02=shell)
| |
16:01 | <alkisg> ok then
| |
16:01 | As you said it
| |
16:01 | <ba> alkisg, I am installing stuff and testing there normally
| |
16:02 | alkisg, I was just wondering...if nbd is read only..where does it store it's changes
| |
16:02 | <alkisg> a tmpfs in the client RAM
| |
16:02 | nbd on the server, tmpfs in ram, both merged with aufs or overlayfs
| |
16:02 | <ba> alkisg, and in no way in the server?
| |
16:02 | <alkisg> Right
| |
16:02 | <ba> alkisg, thanks! (I was wondering why my server becomes out of space sometimes..strange)
| |
16:03 | <alkisg> When you run ltsp-update-image and clients are booted, then the /opt/ltsp/images/i386.img file is deleted, but the space isn't freed,
| |
16:03 | until all clients are rebooted and connections closed
| |
16:04 | <ba> alkisg, how is that possible? (file is deleted but the space isn't freed)
| |
16:04 | alkisg, but it makes sense 100%
| |
16:04 | <alkisg> That's how linux does it, files in use are not freed
| |
16:04 | <ba> alkisg, it explains everything
| |
16:05 | <alkisg> That's also how updates work, while you're using the existing programs/services etc
| |
16:05 | (apt-get update)
| |
16:05 | <ba> alkisg, but after ltsp-update-image is finished my clients shows a lot of squashfs errors. Does it mean that they are not connected to server anymore?
| |
16:06 | <alkisg> They shouldn't show squashfs errors. Yes, it probably means they lost the nbd connection.
| |
16:07 | <ba> alkisg, my server is Ubuntu server 11.10 32bit. mmm.
| |
16:07 | <alkisg> Another new feature (which doesn't come from ltsp) is btrfs, you can create a partition-in-a-file, even with btrfs compression=on, and serve that
| |
16:07 | <ba> alkisg, thank you! finally I know what's the h*** was happening
| |
16:07 | <alkisg> So you won't need ltsp-update-image at all
| |
16:07 | * alkisg goes back to writing some code... | |
16:08 | <ba> alkisg, this is...awesome! (btrfs, I am waiting for it many months) P.S: see ya
| |
16:27 | markit has joined IRC (markit!~insegnant@dynamic-adsl-84-223-84-28.clienti.tiscali.it) | |
16:28 | <knipwim> i'm wondering how big a typical thin client nbd image is for others distro's then gentoo
| |
16:29 | i'm at 394mb now
| |
16:30 | <markit> hi, I've a pc that goes to 800x600 or something more instead of 1280x1024. In lts.conf I've put [00:15:f2:54:bf:9d] and then XRANDR_MODE_0=1280x1024 but seems not to take effect
| |
16:30 | maybe hw does not support? or is not taken ?
| |
16:30 | or should mac address be in capital letters?
| |
16:31 | <knipwim> the mac adress is ok
| |
16:32 | killermike has left IRC (killermike!~killermik@2.26.103.46, Remote host closed the connection) | |
16:47 | <knipwim> [GuS]: i may have a clue on the tftp ltsp download issue
| |
16:51 | <alkisg> knipwim: about 773 MB in Ubuntu 10.04
| |
16:52 | 280 MB the compressed nbd image
| |
16:52 | markit: what's the output of xrandr in that pc?
| |
16:57 | Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com) | |
17:01 | <stgraber> alkisg: Scott James Remnant is no longer active in Ubuntu development but my time is the one maintaing plymouth so I can have a look
| |
17:03 | alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg) | |
17:03 | <stgraber> alkisg: 17:01 < stgraber> alkisg: Scott James Remnant is no longer active in Ubuntu development but my time is the one maintaing plymouth so I can have a look
| |
17:03 | alkisg1: ^
| |
17:03 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 245 seconds) | |
17:04 | <stgraber> alkisg1: ok, I found the bit in the code that does it, it doesn't actually check for the value of init=, it just exits whenever init= is set
| |
17:05 | alkisg1 is now known as alkisg | |
17:05 | <stgraber> alkisg: can you add "plymouth:force-splash" to your boot command line?
| |
17:05 | <alkisg> Hey stgraber, I'm going to pick up my kids, I'll be back in 10 minutes or so
| |
17:05 | <stgraber> alkisg: this should bypass the check and show the splash
| |
17:05 | <alkisg> stgraber: see the pad notes
| |
17:05 | Yes, it does
| |
17:05 | <ba> knipwim, my image is 1.5Gigs
| |
17:06 | <knipwim> ba: fat client?
| |
17:06 | <ba> markit, look at your X logs
| |
17:06 | knipwim, ummm yeah :D
| |
17:06 | knipwim, you are right
| |
17:07 | <alkisg> stgraber: err sorry I meant see the bug report, I wrote the possible workarounds there: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/930865
| |
17:07 | (but also see the pad for non-plymouth-related stuff)
| |
17:07 | bbiab
| |
17:21 | <markit> ba: I've set a different resolution and in fact it uses it, the strange is that I've 12 SAME pc that gets automatically teh correct resolution
| |
17:21 | and that one that does not, even if forced
| |
17:21 | I've resetted the bios to defaults, and re-set like the others, but no way
| |
17:21 | very strange, I give up for today
| |
17:22 | <ba> markit, so you have 12 SAME pc's and ONE of them behaving strangely? is that correct>?
| |
17:22 | <markit> ba: yes!
| |
17:23 | <ba> markit, i.e. it's not using forced resolution?
| |
17:23 | khildin has left IRC (khildin!~khildin@ip-80-236-212-243.dsl.scarlet.be, Ping timeout: 260 seconds) | |
17:23 | <markit> ba: none of them use anything in lts.conf and work fine except one
| |
17:23 | <ba> markit, have you looked at your X logs? (in a thin client itself)
| |
17:23 | <markit> at least, the MB is the same, maybe bios version could be different
| |
17:23 | <ba> markit, graphic card is the same?
| |
17:24 | <markit> ba: sorry not, I missed your post (was working in the room with some wires) and disconnected and put away that foulty
| |
17:24 | ba: is shown in x logs? I've no live cd to try
| |
17:24 | <ba> markit, use SCREEN_02=shell and look at your /var/log/X.0.log (or something)
| |
17:24 | <markit> oh, well, I've one, sysrescuecd, let me check
| |
17:25 | <ba> markit, no! you have to check the X logs in your Client's machine and not in your server
| |
17:26 | markit, and look for "EE" or "WW" messages in that file (/var/log/Xorg.0.log or /var/log/Xorg.1.log)
| |
17:26 | <markit> ba: ok, I was going to boot the client with systrescue cd and look at lspci
| |
17:26 | but ok :)
| |
17:26 | <stgraber> alkisg: I've replied on the pad. I'll upload a new snapshot now.
| |
17:27 | <ba> markit, your issue looks like a graphics driver issue
| |
17:27 | <alkisg> stgraber: back, reading...
| |
17:28 | markit: your client boots in 800x600, right? Why not upload the output of xrandr so that we can see it?
| |
17:28 | <markit> ba: yes, the strange thing is that affects only one
| |
17:28 | alkisg: it boots at 960x800 or something, I forced to 800x600 and took the parameter, so it sees my config
| |
17:29 | <stgraber> alkisg: uploading now
| |
17:29 | <alkisg> markit: ok, since it boots you don't need sysresccd or anything
| |
17:29 | <markit> let me log there and connect to konversation
| |
17:29 | <ba> markit, are you using it as a fat client?
| |
17:29 | <markit> thin client
| |
17:30 | markit_client has joined IRC (markit_client!~federico4@dynamic-adsl-84-223-84-28.clienti.tiscali.it) | |
17:30 | <markit_client> hi, xrandr says
| |
17:30 | Screen 0: minimum 320 x 240, current 960 x 600, maximum 960 x 600
| |
17:30 | so it's gotting it's maximum
| |
17:31 | <alkisg> markit_client: try X_HORZSYNC=30-88 and X_VERTREFRESH=55-72 in lts.conf
| |
17:31 | <markit> is a 17" lcd screen
| |
17:32 | (just in case you know those parameters can break it :))
| |
17:32 | markit_client has left IRC (markit_client!~federico4@dynamic-adsl-84-223-84-28.clienti.tiscali.it, Remote host closed the connection) | |
17:32 | <ba> markit, btw (lol) how about monitors? are they same too?
| |
17:32 | <markit> yes
| |
17:33 | I umplugghed from a OK pc and plugged there
| |
17:34 | <alkisg> stgraber: we can't do the complete switch to using the nbd initramfs script + the nbdroot=host:port/path, because we need udhcpc for network configuration, right? (I don't, but I think it was needed for dhcp updates?)
| |
17:34 | <markit> alkisg: much better but monitor says "out of range!!!" :)
| |
17:34 | <alkisg> markit: do you have epoptes?
| |
17:34 | in that lab?
| |
17:34 | <markit> how could not have? :) sure
| |
17:34 | <alkisg> OK, open a root console for that client,
| |
17:34 | run: export $(/usr/share/epoptes-client/get-display)
| |
17:34 | <markit> last time I tried did not worked
| |
17:34 | <alkisg> and then: xrandr
| |
17:35 | <markit> do you mean "root remote"?
| |
17:35 | <alkisg> Root, local
| |
17:35 | <markit> ok
| |
17:35 | <stgraber> alkisg: yeah, we need udhcpc otherwise IPs will be given to other clients and the existing one will just freeze
| |
17:35 | <markit> alkisg: I've a blank screen and the cursor, no prompt
| |
17:35 | <ba> markit, wait
| |
17:35 | <stgraber> alkisg: new ltsp is building in the ppa now
| |
17:35 | <markit> and the title of the window is "socat"
| |
17:36 | <ba> markit, I think alkisg meant you to use SCREEN_02=shell or something
| |
17:36 | <alkisg> stgraber: normally dhcp3-server pings before giving the ip elsewhere, but ok, let's not do things in a hurry. But note that we *can't* use nbdroot=xx now, since nbd uses that
| |
17:36 | <markit> alkisg: but really, better you mind ltsp project, your time is much better spent there is not urgent here
| |
17:36 | ba: do you know epoptes project? www.epoptes.org
| |
17:37 | <alkisg> markit: can you put LDM_AUTOLOGIN, LDM_USERNAME and LDM_PASSWORD for that user, so that it automatically logs in?
| |
17:38 | It's easier to check with xrandr the monitor timings then
| |
17:38 | <ba> markit, no
| |
17:38 | <stgraber> alkisg: yeah, but the setups where we had the issue is with a cluster of DHCP servers serving > 10000 IPs over hundreds of VLANs with the firewalling preventing the DHCP servers from talking to the clients (like most corporate/governement network will do)
| |
17:38 | (the switches relay the DHCP queries so the DHCP server never talks to the clients directly)
| |
17:38 | <ba> markit, (thanks for the link!, very interesting)
| |
17:39 | <alkisg> stgraber: ok, in the future we may try ipappend 3 in the initramfs, and dhclient --renew-ip-or-something in the real file system, but let's leave all that for later. So currently we can't use the nbd script.
| |
17:40 | <stgraber> yeah, we can try that for 12.10
| |
17:40 | <alkisg> stgraber: do you mind if we have a really long kernel command line? boot=ltsp_nbd plymouth:force-splash init=/sbin/ltsp-init etc?
| |
17:40 | That's 3 additional parameters from previously...
| |
17:40 | <stgraber> alkisg: nope, as long as it's not longer than the maximum size, I'm fine ;)
| |
17:40 | <alkisg> Hehe, no, it's not
| |
17:40 | <markit> alkisg: ok, I removed the timing thing (not to break the monitor) and added those parameters, ok?
| |
17:41 | <alkisg> markit: no leave the timings too
| |
17:41 | ...but,
| |
17:41 | also put: XRANDR_MODE_0=1024x768
| |
17:41 | <markit> native res is 1280x1024
| |
17:41 | <alkisg> It doesn't matter
| |
17:41 | We just want the output of xrandr, when not limited by broken EDID
| |
17:41 | But I suppose you're *sure* that the monitor can show more than 960xwhatever,right?
| |
17:42 | <markit> yes, really sure
| |
17:42 | <alkisg> ok
| |
17:42 | <markit> btw,. now works fine
| |
17:43 | and no error from the monitor about frequency
| |
17:43 | <alkisg> Nice, what's the output of xrandr now?
| |
17:43 | <markit> epoptes root local? let me try
| |
17:43 | <alkisg> markit: no now do user-local
| |
17:43 | It's easier since you logged in
| |
17:44 | <markit> you mean I go there and open a terminal there, right?
| |
17:44 | <alkisg> markit: no, from epoptes
| |
17:44 | Open terminal > user, local
| |
17:45 | <markit> alkisg: I get a blank window with a cursor but no prompt
| |
17:45 | and if I enter a command and press ENTER nothing happens
| |
17:45 | <alkisg> markit: something's wrong there, we need to see what it is, but ok go and try it locally on the client
| |
17:46 | <[GuS]> knipwim: sorry, just recently read you
| |
17:46 | <markit> locally tells me that max res is now 1680x1200
| |
17:46 | <[GuS]> knipwim: what could be the problem?
| |
17:46 | <knipwim> nice
| |
17:46 | * [GuS] brb | |
17:46 | <alkisg> markit: ok, now try xrandr -s 1280x1024
| |
17:48 | <markit> ehm I'm already at that res
| |
17:48 | I set that in lts.conf
| |
17:48 | <alkisg> Ah ok then
| |
17:48 | So you're good to go :)
| |
17:48 | <markit> yes, but don't know why :) does not matter at all now, thanks a LOT
| |
17:48 | <alkisg> If you have time, I'd like to see why user > local terminal etc does not work
| |
17:48 | markit: it's because the driver couldn't read properly your monitor's timings
| |
17:49 | [GuS] has left IRC ([GuS]!~MysT@unaffiliated/gus/x-663402, Remote host closed the connection) | |
17:49 | Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving) | |
17:49 | <markit> alkisg: I have time sure
| |
17:49 | <alkisg> stgraber: btw I've just tried to make a btrfs "partition" in /opt/ltsp/images/i386.img with dd/mkfs.btrfs, then I loop-mounted -o compress that to /opt/ltsp/i386 and then I ran ltsp-build-client. The result was 1.3 Gb while `du -sh` showed 2.4 Gb, pretty good. I'm sure that can now be directly booted with `nbd-server -c`, without tmpfs/aufs, and with init=/sbin/ltsp-init. :)
| |
17:50 | markit: vnc? alkisg.dyndns.org
| |
17:50 | (from the server and maybe after that from the client too)
| |
17:52 | <markit> ok, done from the server
| |
17:52 | I've modified lts.conf in the meantime
| |
17:52 | removing autologin, should I put there again?
| |
17:52 | <alkisg> no need
| |
17:52 | <markit> (was not reading chat...)
| |
17:52 | <alkisg> markit: since you have a thin client, you need x11vnc -noshm -connect alkisg.dyndns.org
| |
17:53 | <stgraber> alkisg: well, one client will be able to boot it if exported read/write but that's it. Otherwise you'll need nbd's copy-on-write which will kill your network because all the writes will happen on the server
| |
17:54 | <alkisg> stgraber: nbd-server -c is copy on write, yes
| |
17:54 | And the diff is only about 10 mb per client
| |
17:54 | ...which would go on the client tmpfs, so sometimes in NBD_SWAP, so again on the server anyway
| |
17:54 | <stgraber> right, that'd indeed work but would be pretty bad in case of disconnects not to mention what happens when you have 5000 clients ;)
| |
17:55 | <alkisg> I think it's much less than what the clients need while booting
| |
17:55 | <stgraber> not to mention a "dd if=/dev/urandom of=/tmp/blah" on a client will kill your server ;)
| |
17:55 | <alkisg> Caching is still local to the client
| |
17:56 | It'll write as much as the virtual disk free space, which can be arranged to be e.g. 500 mb
| |
17:57 | I haven't tried anything in such big setups, but for low-end clients the result was more free mem locally ==> faster client
| |
17:57 | markit: can you login to that client and vnc to me from there?
| |
17:58 | <markit> witrh the above command?
| |
17:58 | -noshm?
| |
17:58 | <alkisg> Yes
| |
17:58 | <stgraber> yeah, offering a few more storage options might be interesting in the future but I'd likely keep squashfs+overlayfs+tmpfs as the default as it's well tested (that's what we have for the livecds) and works pretty well
| |
18:00 | <alkisg> Sure. stgraber btw we try to allocate swap from the server in ltsp_nbd for clients with <100 mb ram, I think that can be moved to initramfs-scripts.d too, should I put it there?
| |
18:00 | So that the 2 tries for NBD swap allocation are merged into one (and remove it from ltsp-init-common)
| |
18:00 | <stgraber> yes, there shouldn't be any change between doing it from initramfs or doing it just before init
| |
18:01 | <alkisg> We're on the real file system now, so I think we can use the encryption stuff which we couldn't do from the initramfs
| |
18:01 | The 60 seconds delay isn't there for thin clients, and I've yet to try the emit thing you told me for the fat clients which have the problem
| |
18:02 | <stgraber> I'm actually surprised thin clients don't have the issue, they actually probably do but it's just not visible as what we care about is started before that
| |
18:03 | actually, I have an idea which should fix both cases
| |
18:03 | can you write a new /etc/network/interfaces containing only:
| |
18:03 | auto lo
| |
18:03 | iface lo inet loopback
| |
18:03 | auto <current interface>
| |
18:03 | iface <current interface> inet manual
| |
18:04 | where <current interface> will likely be eth0 (not sure if we currently hardcode eth0 in the initramfs code)
| |
18:05 | hmm, actually, not sure that'll work ...
| |
18:05 | alkisg: on the machine where you get the 60s delay, can you look at what's in /etc/network/interfaces?
| |
18:05 | <alkisg> stgraber: yeah that code works, the interfaces is like you said above
| |
18:06 | <stgraber> alkisg: ok, might be worth trying to remove eth0 from /etc/network/interfaces, only keeping the loopback in there
| |
18:06 | <alkisg> No then network-manager breaks the connection completely
| |
18:06 | <stgraber> ah right, network manager ... ;)
| |
18:06 | <alkisg> Give me some minutes to check a problem with epoptes on markit's class and I'll try more tests, including the emit thing, or removing more services...
| |
18:07 | <stgraber> ok, you need to emit static-network-up then, having it emitted for both thin and fat clients would be best
| |
18:08 | alkisg: http://paste.ubuntu.com/839388/ should do the trick
| |
18:08 | alkisg: that's an upstart job to dump in /etc/init/ of the client
| |
18:09 | <alkisg> ty, will try it in a few
| |
18:09 | khildin has joined IRC (khildin!~khildin@ip-80-236-212-243.dsl.scarlet.be) | |
18:13 | <alkisg> markit: the epoptes daemon needed a restart, but I don't know what troubled it. Can you mail me /var/log/epoptes.log?
| |
18:13 | It should be working ok from now on...
| |
18:13 | <markit> sure, give me privately your email
| |
18:13 | <alkisg> alkisg at gmail
| |
18:14 | ba has left IRC (ba!~ba@airport.kg) | |
18:15 | <markit> done, I've to run thanks a lot
| |
18:15 | markit has left IRC (markit!~insegnant@dynamic-adsl-84-223-84-28.clienti.tiscali.it, Remote host closed the connection) | |
18:16 | mikkel has left IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk, Ping timeout: 248 seconds) | |
18:19 | dptech has joined IRC (dptech!~dptech@can06-1-82-242-223-39.fbx.proxad.net) | |
18:22 | map7 has left IRC (map7!~map7@teksup41.lnk.telstra.net, Ping timeout: 245 seconds) | |
18:22 | map7 has joined IRC (map7!~map7@teksup41.lnk.telstra.net) | |
18:28 | vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net) | |
18:31 | mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk) | |
18:39 | <alkisg> Meh I didn't update ltsp_nbd and the code that adds "eth0 manual" to /etc/network/interfaces ran twice... let me remove that and test again...
| |
18:39 | vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Quit: leaving) | |
18:41 | vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net) | |
18:43 | vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Client Quit) | |
18:45 | vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net) | |
18:47 | vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net) | |
18:50 | <alkisg> Without the duplicate "eth0 manual" entry, a VM thin client boots in 50'. Not too bad, but we may want to remove more services...
| |
18:52 | As a fat client too, so stgraber I didn't even have to try the upstart job you suggested.
| |
18:54 | vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Quit: leaving) | |
18:54 | vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net) | |
18:54 | <alkisg> ...btrfs does eat up a lot of ram though :(
| |
18:57 | <stgraber> alkisg: cool
| |
18:58 | <alkisg> !ubuntu-2d
| |
18:58 | <ltsp`> alkisg: ubuntu-2d: To select ubuntu-2d as your default session, put this line in your lts.conf: LDM_SESSION="gnome-session --session=ubuntu-2d"
| |
19:06 | <alkisg> stgraber: about resolvconf, did you put the relevant code in nfs-bottom/ltsp?
| |
19:07 | mkdir -p /run/resolvconf/interface/ ==> that's missing "$rootmnt" in front...
| |
19:07 | But shouldn't we move that too, to the initramfs-scripts ?
| |
19:08 | Let's save the initramfs environment to ltsp_config, and move that code from nfs-bottom/ltsp to initramfs-scripts.d...
| |
19:10 | Errr we basically don't need nfs-bottom/ltsp at all now, do we?
| |
19:12 | <stgraber> alkisg: it's not missing $rootmnt
| |
19:12 | alkisg: /run in the initramfs is moved to $rootmnt/run at the end of the initramfs script
| |
19:13 | alkisg: so the initamfs script needs to create it in /run/ for it to appear in $rootmnt/run afterwards
| |
19:13 | <alkisg> stgraber: ah, I see, so something else goes wrong and it doesn't end up in the real system
| |
19:14 | <stgraber> it does in current Ubuntu (5.2.16) with the code I copy/pasted from trunk, so something after that broke it
| |
19:14 | do you see /run/resolvconf/interfaces/LTSP at all in your case?
| |
19:14 | <alkisg> No
| |
19:15 | <stgraber> ok, that's pretty weird
| |
19:15 | <alkisg> Ah and /me needs to remember to disable screensaver locking for fat clients... it's broken now with gsettings
| |
19:16 | <stgraber> alkisg: oh, I think I know why. 50-resolv-conf contains $rootmnt in the checks
| |
19:16 | alkisg: as it's called in the chroot, it shouldn't have $rootmnt there
| |
19:17 | <alkisg> stgraber: hmmm well, I've switched to using init=/sbin/ltsp-init, right?
| |
19:17 | So DNS_SERVER isn't available at that point if we don't save it before
| |
19:18 | We can copy /tmp/net-eth0.conf somewhere in the real system, if we need it, or store the vars we want to ltsp_config
| |
19:19 | <stgraber> ok, I fixed 50-resolv-conf but it'll need the final /run to be mounted (that's the case if ran from ltsp-init, not if ran though chroot in initramfs) and requires the environment variables to be set
| |
19:20 | yeah, if we want to deal with resolv.conf from initramfs-scripts, we need to save the environment, otherwise we need to keep doing it in ltsp_nbd
| |
19:20 | <alkisg> stgraber: to save the vars in ltsp_nbd: http://paste.ubuntu.com/839513/
| |
19:21 | ***in ltsp_config, I mean
| |
19:22 | grep -v '=$' /tmp/net-*.conf >> "$rootmnt/var/cache/ltsp/ltsp_config"
| |
19:22 | <stgraber> looks reasonable
| |
19:22 | and I assume you already source ltsp_config in init-ltsp?
| |
19:22 | <alkisg> Yes, it's done by ltsp-common-functions
| |
19:46 | Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!") | |
19:48 | alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg) | |
19:50 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 260 seconds) | |
19:50 | alkisg1 is now known as alkisg | |
19:58 | vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Ping timeout: 260 seconds) | |
20:06 | komunista has left IRC (komunista!~slavko@adsl-195-098-005-032.dynamic.nextra.sk, Quit: Leaving.) | |
20:14 | sepski has left IRC (sepski!~sep@40.211.jostedal.no, Ping timeout: 240 seconds) | |
20:34 | markit has joined IRC (markit!~marco@88-149-177-66.staticnet.ngi.it) | |
20:41 | piet has left IRC (piet!5b605e82@gateway/web/freenode/ip.91.96.94.130, Quit: Page closed) | |
21:13 | dptech has left IRC (dptech!~dptech@can06-1-82-242-223-39.fbx.proxad.net, Quit: When two people dream the same dream, it ceases to be an illusion. KVIrc 3.4.2 Shiny http://www.kvirc.net) | |
21:18 | loather has joined IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net) | |
21:24 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
21:43 | mikkel has left IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk, Quit: Leaving) | |
21:48 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Quit: Goin' down hard) | |
21:51 | khildin has left IRC (khildin!~khildin@ip-80-236-212-243.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
22:10 | loather-work has joined IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net) | |
22:13 | veloutin has left IRC (veloutin!~veloutin@modemcable121.135-59-74.mc.videotron.ca, Read error: Connection reset by peer) | |
22:34 | ByPasS has left IRC (ByPasS!pbernier@nat/revolutionlinux/x-pqilphefkadalwcs, Ping timeout: 245 seconds) | |
22:34 | ByPasS has joined IRC (ByPasS!pbernier@nat/revolutionlinux/x-djfshhamszrvsmtj) | |
22:39 | alexqwesa_ has joined IRC (alexqwesa_!~alex@alexo-veto.broker.freenet6.net) | |
22:39 | alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Read error: Connection reset by peer) | |
23:28 | loather-work has left IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep) | |
23:43 | markit has left IRC (markit!~marco@88-149-177-66.staticnet.ngi.it, ) | |