|00:31||vagrantc_ has joined IRC (vagrantc_!~vagrant@unaffiliated/vagrantc)|
|00:33||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 240 seconds)|
|02:25||vagrantc_ is now known as vagrantc|
|05:12||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)|
|05:38||Fenuks has joined IRC (Fenuks!~Fenuks@22.214.171.124)|
|05:52||pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 276 seconds)|
|05:58||pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)|
|06:20||alkisg_away is now known as alkisg|
Yey, new LTSP/LDM :)
|06:31||ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)|
|06:38||Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)|
|06:45||jinnjus has joined IRC (jinnjus!~user1@CPE788df72324c1-CM788df72324c0.cpe.net.cable.rogers.com)|
|07:10||vmlintu has joined IRC (email@example.com)|
|07:26||uXus has left IRC (uXus!~uXus@126.96.36.199, Remote host closed the connection)|
|07:29||mikkel has joined IRC (firstname.lastname@example.org)|
|08:05||Softeisbieger has joined IRC (Softeisbieger!~Softeisbi@ip-88-152-12-13.hsi03.unitymediagroup.de)|
|11:34||alkisg is now known as alkisg_away|
|11:50||gvy has joined IRC (gvy!~mike@altlinux/developer/mike)|
|12:16||Softeisbieger has left IRC (Softeisbieger!~Softeisbi@ip-88-152-12-13.hsi03.unitymediagroup.de, Ping timeout: 245 seconds)|
|12:28||Softeisbieger has joined IRC (Softeisbieger!~Softeisbi@ip-88-152-12-13.hsi03.unitymediagroup.de)|
|13:07||cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)|
|13:12||markit has joined IRC (email@example.com)|
|13:31||Fenuks has left IRC (Fenuks!~Fenuks@188.8.131.52, Ping timeout: 248 seconds)|
|14:05||Softeisbieger has left IRC (Softeisbieger!~Softeisbi@ip-88-152-12-13.hsi03.unitymediagroup.de, Ping timeout: 250 seconds)|
|14:15||brentb has joined IRC (brentb!32f78141@gateway/web/freenode/ip.184.108.40.206)|
good morning everyone
|14:17||Softeisbieger has joined IRC (Softeisbieger!~Softeisbi@ip-88-152-12-13.hsi03.unitymediagroup.de)|
With some help last week I was able to install ltsp using the ltsp-pnp. It is now up and running, but I have a strange error I was hoping to get some help with.
When I network boot and connect, it is showing the wireless icon instead of the ethernet icon. On top of that, it shows there is no connection, but I do have internet connection.
Does the machine actually have a wireless card?
the physical machine booting, yes
That's probably why.
Network Manager seems to like to give priority to the wireless card.
sorry, got pulled away for an IT issue.
hmm, I can try turning off the wifi card (physical switch) or disabling the card via device manager?
Simplest would be disabling the wifi in bios.
That will require the least amount of effort.
ah, i could try that. I just noticed that I already have the physical switch for wifi turned off. I will try the bios change.
brentb: that's network manager running, but it's not allowed to manage the ethernet card of ltsp, so as to prevent users from disconnecting it
|14:48||alkisg_away is now known as alkisg|
It's there so that you can manage other cards if you have them, or add VPN networks etc
If you don't want that, you can remove it from lts.conf RM_SESSION_SERVICES directive
Sorry, RM_SYSTEM_SERVICES, like this:
RM_SYSTEM_SERVICES="apache2 bluetooth clamav-daemon clamav-freshclam dnsmasq mysql nbd-server network-manager nfs-kernel-server nmbd php5-fpm shared-folders smbd ssh squid3 whoopsie x2goserver"
Removing network manager also removes the applet from ltsp fat clients
I suppose it does not harm anything, so I don't need to remove it. I thought it was a bug or misconfiguration
|14:55||ben_roose has joined IRC (firstname.lastname@example.org)|
Nope, it's a feature :)
Yesterday I think you mentioned testing the thin vs thick client, where was that setting to toggle between?
right now it is running at whatever the default is.
sudo ltsp-config lts.conf, if you haven't done that already,
then sudo nano /var/lib/tftpboot/ltsp/i386.conf,
and put LTSP_FATCLIENT=False under the [Default] section there
|15:30||gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving)|
|15:31||Softeisbieger has left IRC (Softeisbieger!~Softeisbi@ip-88-152-12-13.hsi03.unitymediagroup.de, Ping timeout: 250 seconds)|
|15:43||Fenuks has joined IRC (Fenuks!~Fenuks@220.127.116.11)|
|15:43||Softeisbieger has joined IRC (Softeisbieger!~Softeisbi@ip-88-152-12-13.hsi03.unitymediagroup.de)|
I don't have that directory... I have /var/lib/tftpboot/ltsp/amd64/lts.conf
I see a default area in there that I can add the line to.
Do I need to "update the client image" after modifying this file?
No, you just need to restart the clients
If you installed with amd64 cd, you can only boot 64bit clients now
|15:49||Mazhive has joined IRC (Mazhiveemail@example.com)|
I don't think that will be a problem, but if it becomes one I can re-install. I have been keeping notes on how to install.
is ther some one who can help me , ive been set up a debian 7 as a ltsp and build the client arch i386 and amd64 still my client laptop does not boot up.
my ltsp has no dhcp this is done by my router.
set up the dhcp options into the router..
|15:56||Softeisbieger has left IRC (Softeisbieger!~Softeisbi@ip-88-152-12-13.hsi03.unitymediagroup.de, Remote host closed the connection)|
Mazhive: did you follow a tutorial, some wiki page?
using debian wheezy it's install automatic.. apt-get install ltsp-server
made sure it did not start dhcp
after that change dhcp options in my cisco router
i thought this should work now.. but along the way propably something went wrong..
Did you put next-server, boot-filename, and rootpath in your router? 3 things?
yes.. wait ill copy the dns masq
|16:27||m3741 has joined IRC (firstname.lastname@example.org)|
ltsp has an example ltsp-server-dnsmasq.conf for you to see the directives, but I think that's ^ the one you're missing
|16:31||Mazhive_one has joined IRC (Mazhive_oneemail@example.com)|
yep i just rebooted my router i saw a misconfiguration
|16:31||Mazhive_one has left IRC (Mazhive_onefirstname.lastname@example.org, Client Quit)|
|16:32||Mazhive has left IRC (Mazhiveemail@example.com, Ping timeout: 272 seconds)|
|16:32||Mazhive has joined IRC (Mazhivefirstname.lastname@example.org)|
|16:41||Fenuks has left IRC (Fenuks!~Fenuks@18.104.22.168, Ping timeout: 256 seconds)|
|16:43||robb_nl has joined IRC (email@example.com)|
|16:46||Fenuks has joined IRC (Fenuks!~Fenuks@22.214.171.124)|
|16:57||markit has left IRC (firstname.lastname@example.org, Quit: Konversation terminated!)|
|16:58||Mazhive_one has joined IRC (Mazhive_oneemail@example.com)|
|17:02||m3741 has left IRC (firstname.lastname@example.org, Quit: My Mac has gone to sleep. ZZZzzz…)|
|17:06||m3741 has joined IRC (email@example.com)|
|17:06||m3741 is now known as m3741-a|
|17:06||m3741-a is now known as m3741|
|17:07||m3741 is now known as m3741-a|
|17:07||m3741-a is now known as m3741|
|17:07||m3741 is now known as m3741-a|
|17:08||m3741-a is now known as m3741|
|17:51||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
|17:58||Mazhive has left IRC (Mazhivefirstname.lastname@example.org, Ping timeout: 240 seconds)|
|18:05||jb0 has left IRC (email@example.com, Ping timeout: 250 seconds)|
vagrantc: good job on releasing ltsp/ldm :)
alkisg: i largely just uploaded, you did most of the work... and whoever it was that came up with the ldm multi-screen patch
|18:20||robb_nl has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
though i did catch a bugfix here and there
I'm not 100% sure that uploading that patch was a good idea, we'll see...
|18:20||* vagrantc neither|
I'm afraid in some cases people will see a blank screen while they have a single-monitor (and a ghost monitor) setup...
it could be really annoying with hidden screens
vagrantc: is there any chance that you could upload a new (small) release of epoptes, in the next e.g. 3-4 days? Phantomas was thinking of fixing an issue with screen locking...
If Phantomas fixes it in e.g. 2 days, and you upload e.g. in 4, with medium priority, it can still make it for 16.04
alkisg: happy to
if that's the plan, i'll hold off on backporting to jessie till then too
Cool! It's up to Phantomas as he also has some exams, hopefully we'll hear from him within a couple of days...
I think I also made epoptes lintian-free
|18:26||* vagrantc claps!|
Ah, about mentioning revisions in bzr commits like "r2689" etc, ok, I'll stop doing that in case we ever switch to git _and_ try to preserve history...
I didn't know git didn't have a serial number for commits
It's strange that they don't list one, since history is supposed to be immutable
(of course it wouldn't be the same when 2 branches merge, but we don't plan to merge old history, ever...)
alkisg: it just has sha1sums
history in git is not at all immutable
|18:33||Fenuks has left IRC (Fenuks!~Fenuks@126.96.36.199, Ping timeout: 260 seconds)|
So it would be possible for e.g. poettering to merge commits #1000 to #10000 from systemd, and other devs would pull, and get their history rewritten?!
sort of. it's just different
the concept of a linear history with git basically doesn't exist
it maintains many parallel universes
which is good for quantum state
|18:37||* alkisg fears some devs read too many stories from the marvel universe(s)... :D|
|18:38||* vagrantc has been reading 1800s sci-fi lately|
do you recommend that before learning git ? to understand the multiverse concept first ?
In reality though, I don't think r2689 will ever have a different number whatever VCS we use, it's just that git doesn't like to display a counter there
If we did rewrite history, it could change, but we don't do that, so...
ogra_: well, really parallel universes didn't really come into the literature until the early-mid 1900s
alkisg: even if we never switched VCSes, i still think referencing a commit by number means to know what it's referencing i have to look up the commit ... which is cumbersome
alkisg: so i thank you for your offer to switch habits :)
But I do want to reference the other commit...
So that readers can then see what was undone, and why...
I can stop using a serial number, and I can put some extra documentation there, but I still want to reference the original commit
alkisg: if you could at least include some english text for context in addition to the commit number, i would really like that
Btw, if git allows rewritting history, we could easily replace rXXXX with git's SHA-1 sums while migrating :)
too much hassle
And it's easier to see the other commit then, good UIs support clicking on such hyperlinks
Nah, I've done it many many times while changing forum software + servers (URLs), while maintaining users + posts
Ah, a more serious issue...
Intel and AMD decided to put microcode blobs in the kernel
So, each initrd is now tailored (by update-initramfs) to the current CPU the LTSP server has
with git-remote-bzr it pushes back and forth, so conversion happens on the fly, and so rewriting commits isn't really viable
So, an Intel "X" cpu on the server, will have microcode for "X", and it won't have microcode for Intel's "Y" nor AMD's "Z" processors
We can modify the ltsp server to include all the microcode, but it makes the initrd a bit larger
right, that's what i figured
how much is "a bit larger"
Or we can hope that the microcode isn't too important and can be loaded later on from the real system, after the initramfs stage
|18:50||* vagrantc has always liked being able to swap disks without having to worry about compatibility in general|
in my experience you can run happily without microcode
I did some tests but I don't remember the results, in general the microcode is a few KB, but there are hundreds of them, and will be more in the future
E.g. one of the recent bugs fixed was a specific multiplication with specific operands
Hopefully the initramfs won't be affected by such bugs, and then a service can load the microcode from the real system
The weird thing is that they just append the microcode, they don't really include it in the initramfs cpio
It's supported by the kernel, but it makes zcat initrd | cpio -i fail
hopefully it has some check to validate the microcode is appropriate for the CPU...
Yup, it does
That's where we can play with intel settings
Increase in size: from 36968783 to 37711485
...if we also include AMD's, let's say 1 MB larger
(it's lame that we have such a big initramfs though, it can't be uncompressed in under 100 MB RAM...)
They should use squashfs instead, and keep it compressed even in RAM :D
then you have the overhead of needing some kind of overlay
or some kind of tmpfs mounts at a few points
which i guess isn't all that hard
vagrantc: sometimes I'm wondering if it wouldn't be much faster to provide the initramfs and the init-ltsp.d part in a read-only NFS file system, which would then pivot_root to the nbd cow system... afaik, the kernel does have some basic nfs support embedded, doesn't it?
alkisg: i doubt we'll be able to get the kernels to enable built-in NFS support.
i mean, technically, yes, but in a distribution kernel? not likely to happen
vagrantc: I have this: CONFIG_NFS_COMMON=y
Isn't that enough?
alkisg: you also need CONFIG_NFS_*
and an NFS root option
|20:00||m3741 has left IRC (email@example.com, Ping timeout: 276 seconds)|
Isn't that a kernel cmdline option?
it requires kernel support
was happy to abandon that so many years ago
OK so the stock kernel can't netboot... it would be nice if it could, even with just the undi stack...
not without an initramfs... :P
I was seeing all those NFS*=y options and I thought it would be supported without an initramfs
|20:03||* vagrantc is trying to figure out why building the ltsp package embeds dates in the *.mo files, but calling the same commands manually doesn't|
er, embeds the current date
i think the translations are currently only for ltsp-build-client
and are largely out of date
|20:08||* alkisg thinks we need to find a sponsor and rewrite the whole thing almost from scratch as ltsp 6 :)|
there's something to be said for that
but the bounties campaign is going so well, this might slow that down!
Well, only 1 person commented there on the list so it didn't gain any traction at all
And the google summer of code idea was turned down by jammcq...
|20:14||robb_nl has joined IRC (firstname.lastname@example.org)|
oh wow, i think i finally figured it out
|20:33||alkisg is now known as alkisg_away|
+$(DOMAIN).pot: $(shell xgettext -L Shell -o $(DOMAIN).pot $(GETTEXTFILES))
hah, line-breaks didn't represent that correctly
|20:39||yisraeldov has joined IRC (email@example.com)|
sbalneav: i think you merged some updates to libpam-sshauth ... do you plan to make a new upstream release?
sbalneav: there's a trivial build failure due to packaging that i haven't fixed on debian for some time, as i wasn't sure of the state of libpam-sshauth
|21:10||brentb has left IRC (brentb!32f78141@gateway/web/freenode/ip.188.8.131.52, Quit: Page closed)|
|21:16||vmlintu has left IRC (firstname.lastname@example.org, Ping timeout: 245 seconds)|
vagrantc: Sure, I could bump the version number. I'll do it this week.
|22:12||ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)|
|22:25||Mazhive has joined IRC (Mazhiveemail@example.com)|
|22:32||gbaman has joined IRC (firstname.lastname@example.org)|
|22:43||Mazhive_one has joined IRC (Mazhive_oneemail@example.com)|
|22:45||Mazhive has left IRC (Mazhivefirstname.lastname@example.org, Ping timeout: 260 seconds)|
|23:23||robb_nl has left IRC (email@example.com, Remote host closed the connection)|
|23:33||gbaman has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|23:33||gbaman has joined IRC (email@example.com)|
|23:56||jb0 has joined IRC (firstname.lastname@example.org)|
|23:59||ben_roose has left IRC (email@example.com, Remote host closed the connection)|