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


Channel log from 19 October 2015   (all times are UTC)

00:19gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
00:30gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Read error: Connection reset by peer)
00:31gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
01:00gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection)
01:35gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
01:41gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 240 seconds)
02:29fnurl has left IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95, Ping timeout: 246 seconds)
02:38gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
02:39fnurl has joined IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95)
02:42gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 264 seconds)
02:46fnurl has left IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95, Ping timeout: 246 seconds)
03:26vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 252 seconds)
03:33fnurl has joined IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95)
04:25work_alkisg has left IRC (work_alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 250 seconds)
04:31cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 272 seconds)
04:34fnurl has left IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95, Ping timeout: 246 seconds)
04:40gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
04:40Tex has left IRC (Tex!4ac0a1b7@gateway/web/freenode/ip.74.192.161.183, Quit: Page closed)
04:43alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
04:45gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 268 seconds)
05:07vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi)
05:53ricotz has joined IRC (ricotz!~ricotz@p5B2A97BA.dip0.t-ipconnect.de)
05:53ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
06:02cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
06:28mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
06:45
<alkisg>
ogra_: can I install `ltsp-client` over e.g. a "raspberry 2 snappy ubuntu core" system?
06:45
I.e. is it possible to mix .debs and snappy?
07:00alkisg is now known as work_alkisg
07:07uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek)
07:11uXus has joined IRC (uXus!~uXus@217.77.222.72)
07:19khildin has joined IRC (khildin!~khildin@ip-213-49-116-188.dsl.scarlet.be)
07:41manosZ has joined IRC (manosZ!c23fefeb@gateway/web/freenode/ip.194.63.239.235)
07:49work_alkisg has left IRC (work_alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 240 seconds)
07:53manosZ has left IRC (manosZ!c23fefeb@gateway/web/freenode/ip.194.63.239.235, Quit: Page closed)
07:53
<maldridge>
alkisg: my understanding is no, you cannot mix debs and snappy
08:06khildin has left IRC (khildin!~khildin@ip-213-49-116-188.dsl.scarlet.be, Ping timeout: 240 seconds)
08:25khildin has joined IRC (khildin!~khildin@ip-213-49-116-188.dsl.scarlet.be)
08:39alkisg_web has joined IRC (alkisg_web!4e5783d7@gateway/web/freenode/ip.78.87.131.215)
08:48khildin has left IRC (khildin!~khildin@ip-213-49-116-188.dsl.scarlet.be, Ping timeout: 255 seconds)
08:48
<alkisg_web>
!raspberrypi
08:48
<ltsp>
raspberrypi: (#1) LTSP with raspberry pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#2) To use a similar environment to LTSP on the raspberry pi http://berryterminal.com/, or (#3) https://github.com/gbaman/RaspberryPi-LTSP, or (#4) https://pi-ltsp.net
08:56larryni has joined IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com)
09:11gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
09:16sutula has left IRC (sutula!~sutula@207-118-165-192.dyn.centurytel.net, Quit: ZNC - http://znc.sourceforge.net)
09:16mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 250 seconds)
09:16sutula has joined IRC (sutula!~sutula@207-118-165-192.dyn.centurytel.net)
09:20
<ogra_>
alkisg_web, no, you cant mix deb with snap ... you can run a container that can handle debs or you can use snapcraft (https://developer.ubuntu.com/en/snappy/snapcraft/ ... (an example of a bip snap: http://bazaar.launchpad.net/~ogra/+junk/ircproxy/files you only need snapcraft.yaml and some glue)) to roll a snap from debs easily
09:21
(lauchpad has automated snap building (via recipe) available https://code.launchpad.net/~ogra/+snap/ircproxy)
09:22mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
10:02andygraybeal has left IRC (andygraybeal!~andy@h232.76.191.173.dynamic.ip.windstream.net, Ping timeout: 240 seconds)
10:13andygraybeal has joined IRC (andygraybeal!~andy@h17.73.191.173.dynamic.ip.windstream.net)
10:21ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 250 seconds)
10:22ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
10:24SYS64738 has joined IRC (SYS64738!~SYS64738@159.213.93.166)
10:24
<SYS64738>
hi
10:30
<alkisg_web>
Hello
10:44gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
10:48Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
10:57andygraybeal has left IRC (andygraybeal!~andy@h17.73.191.173.dynamic.ip.windstream.net, Ping timeout: 240 seconds)
11:06
<alkisg_web>
gbaman: the Greek schools ppa now supports armhf as well, i.e. it provides new ltsp versions for rpi2
11:07* alkisg_web is working on a tutorial on how to build thin or fat rpi2 ubuntu chroots with that ppa
11:10andygraybeal has joined IRC (andygraybeal!~andy@h227.20.30.71.dynamic.ip.windstream.net)
11:14alkisg_web has left IRC (alkisg_web!4e5783d7@gateway/web/freenode/ip.78.87.131.215, Quit: Page closed)
11:14larryni has left IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com, Ping timeout: 264 seconds)
11:25alkisg_web has joined IRC (alkisg_web!4e5783d7@gateway/web/freenode/ip.78.87.131.215)
11:52alkisg_web has left IRC (alkisg_web!4e5783d7@gateway/web/freenode/ip.78.87.131.215, Quit: Page closed)
11:57kione has joined IRC (kione!57806687@gateway/web/freenode/ip.87.128.102.135)
11:57
<kione>
hello! Awesome piece of software!
11:58
i habe a setup of ubuntu 14.04 ltsp-pnp and ran into a problem with gnome-keyring (evolution, online accounts...) at client sides, some hints?
12:01lbssousa has joined IRC (lbssousa!~laercio@177.143.30.47)
12:31danau11 has left IRC (danau11!~durban@66.251.57.114)
12:34kione has left IRC (kione!57806687@gateway/web/freenode/ip.87.128.102.135, Quit: Page closed)
12:38khildin has joined IRC (khildin!~khildin@ip-213-49-116-188.dsl.scarlet.be)
13:10Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)
13:17lbssousa has left IRC (lbssousa!~laercio@177.143.30.47, Quit: lbssousa)
13:54ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
14:18alkisg_web has joined IRC (alkisg_web!4e5783d7@gateway/web/freenode/ip.78.87.131.215)
14:29virara has joined IRC (virara!c3391364@gateway/web/freenode/ip.195.57.19.100)
14:45mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
14:52Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
15:04gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 246 seconds)
15:17lbssousa has joined IRC (lbssousa!~laercio@177.143.30.47)
15:22bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy)
15:52gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
16:08gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Read error: Connection timed out)
16:09gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
16:11
<alkisg_web>
Finally, ltsp-build-client now runs fine for rpi2 and ubuntu 12.04/14.04+ :)
16:11
<ogra_>
congrats !
16:11
<alkisg_web>
Now, time for optimizations + internationalizing sch-scripts... <=== Phantomas :)
16:12
<ogra_>
heh
16:12
just make greek the default lang of ltsp !
16:13
and drop all that internationalizing
16:13
(finally a reason to learn greek !)
16:13
<alkisg_web>
Haha, that's not a bad idea :D
16:13
We'll also have a wiki with documentation and instruct people that don't know greek to use google translate :D
16:13
<ogra_>
yeah !
16:20Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas, Quit: Leaving.)
16:22vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:23Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
16:25danau11 has joined IRC (danau11!~durban@66.251.57.114)
16:26danau11 has left IRC (danau11!~durban@66.251.57.114)
16:29ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Ping timeout: 264 seconds)
16:29thedarkener has left IRC (thedarkener!~thedarken@c128.thedarkener.com, Ping timeout: 264 seconds)
16:31thedarkener has joined IRC (thedarkener!~thedarken@c128.thedarkener.com)
16:31
<alkisg_web>
vagrantc: the greek schools ppa now also supports rpi2 :D
16:31
In my ltsp-build-client.conf, I needed this: CROSS_ARCH_EMULATOR="/usr/bin/qemu-arm-static"
16:31
I didn't saw that in your how-to, how did you avoid using it?
16:33
*didn't see, meh
16:35
(with ubuntu chroots, not raspbian)
16:37
<vagrantc>
alkisg_web: cross-architecture support is in the ltsp-build-client hooks for debian
16:38
<alkisg_web>
vagrantc: but only if you set it, right?
16:38
Same in the ubuntu ltsp-build-client plugins...
16:38
But I didn't see you set it in your how-to
16:39* ogra_ guesses you only need the right --arch arg
16:39
<vagrantc>
alkisg_web: look at Debian/002-cross-arch
16:40* alkisg_web sees that Ubuntu/002-cross-arch is a symlink to that
16:40
<alkisg_web>
Hmmm I set ARCH=armh in ltsp-build-client.conf instead of passing it to the command line, I wonder if that's to blame...
16:41
*armhf
16:41
So qemu-debootstrap sets CROSS_ARCHITECTURE?
16:42
*CROSS_ARCH_EMULATOR, sorry
16:42
<vagrantc>
alkisg_web: the use of qemu-debootstrap should avoid the need for CROSS_ARCH_EMULATOR
16:42ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
16:42
<vagrantc>
CROSS_ARCH_EMULATOR is legacy from before qemu-debootstrap existed
16:43
<alkisg_web>
OK, let me retry it then
16:43
<vagrantc>
or, in theory, if qemu-debootstrap was missing a particular combination of things, you could manually set it
16:43
<alkisg_web>
Maybe I'm missing some qemu package...
16:43
<vagrantc>
qemu-user-static is what's needed in debian...
16:44
<alkisg_web>
vagrantc: ah, I do have a more specific question, would your chroots have /opt/ltsp/armhf/usr/bin/qemu-arm-static, and if so, what put it there?
16:44
<vagrantc>
qemu-debootstrap
16:45
(and yes to the first part of your question)
16:45
<alkisg_web>
OK, then I guess something goes wrong in that "if" inside 002-cross-arch, debugging...
16:45
thanks!
16:46
vagrantc: ah, and another question if you don't mind, about the sd cards preparation
16:46
I'm thinking that in the future we can have an image based on u-boot
16:46
So that we don't need any ltsp-specific code for that
16:46
If that's a good idea, then in the meantime, we could host an image with one specific kernel that can boot rpi2,
16:47
and have an init-ltsp.d hook that updates the kernel+initrd in the sd card
16:47
If that's acceptable, then the only code in ltsp for that is that init-ltsp.d hook
16:47
The instructions for the users would be pretty easy, "wget + dd, and it'll be automatically updated on first boot"
16:48
<ogra_>
well, in case of the RPi, where does your build get the binary blob bootloader from ?
16:48
<vagrantc>
you would basically need a different u-boot image for each board
16:49
i haven't found the rpi u-boot to be useable, though
16:49Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
16:49
<ogra_>
(ubuntu is actually building different uboot binaries from its uboot package ... but that wont help you with rpi)
16:49
<vagrantc>
i mean, it boots, but graphics are wonky, and various other problems result
16:49
<ogra_>
vagrantc, works fine, but you need to chainload
16:49
<alkisg_web>
ogra_: we can have instructions for people that want to build the sd card image from scratch, those would say "git clone rpi-bootloader + fetch kernel from ubuntu mainline ppa" etc
16:49
But for users it would just be wget + dd
16:49
<ogra_>
and you need to tell uboot to load the DT from ram (0x100 IIRC)
16:50
<vagrantc>
ogra_: i've never really seen it work fine ... i've seen it boot using u-boot, but various features are borked ... notably i could only get 640x480 video.
16:50
<ogra_>
we use it on snappy, it is rock solid here
16:50
<vagrantc>
huh
16:50
ogra_: you building from mainline u-boot?
16:50
<ogra_>
but you need the blob and all config has to come from it
16:50
yes
16:51
the prob is that uboot cant use its own DT
16:51
<vagrantc>
something different from the firmware used to boot a kernel without u-boot ?
16:51
<ogra_>
it needs to be pulled from ram where the blob has put it
16:51
not much different, no
16:51
<vagrantc>
maybe recent firmware works better ... i probably only tried with oldish firmwares
16:51
<ogra_>
we need the bootloader scripting functionality from uboot in snappy for the rollback and stuff
16:51* vagrantc should give it another go
16:52
<ogra_>
which is why i have to chainload it
16:52
technically the blob still does the whole HW setup before loading uboot
16:52
<vagrantc>
alkisg_web: but if you want to implement the auto-updating stuff, sure
16:52
<alkisg_web>
ogra_: what do you mean by "chainload"?
16:52
<ogra_>
so its a no-op if you dont rely on any of its scripting functions
16:53
alkisg_web, instead of the kernel.img the blob loads the uboot.img for me
16:53
<vagrantc>
alkisg_web: still need the GPU binary firmware blob gunk.
16:53
<alkisg_web>
vagrantc: we can have the autoupdates until uboot works, do we have any other/better ideas?
16:53
<ogra_>
uboot then loads kernel and initrd and boots them
16:53
<alkisg_web>
ogra_: but uboot can load the kernel+initrd from the network, right?
16:53
<ogra_>
by design uboot will never work standalone on that hardware
16:53
yes, that falls under "scripting" :)
16:54gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving)
16:54
<alkisg_web>
I think they say that their latest version has usb 2 support i.e. networking
16:54
Sure, the binary blob will be there...
16:54
<ogra_>
right, it should be netbooting fine
16:54
<alkisg_web>
It's like "ipxe.iso", users don't need the source for it, if they can put that in a client they then forget about it
16:54
<vagrantc>
that was the whole reason i started messing with u-boot on rpi/rpi2
16:55
the network boot support
16:55
<alkisg_web>
They don't need new versions frequently, so it wouldn't be much effort to have one small sd image for each board
16:55
<vagrantc>
then we don't need to update the kernel+initrd ... just u-boot and boot-scripts when needed
16:55
alkisg_web: you're just talking about rpi, not arm in general?
16:56
<alkisg_web>
In theory it would be similar, right? Although I don't have any other arm boards to try with...
16:56
<ogra_>
apart from the spcific needs for the blob it would likely be similar
16:56
<alkisg_web>
In the ltsp side, for auto-updating, we'd just need a kernel parameter, e.g. ltsp.boot_device=sda1
16:56
<ogra_>
but you need some decent graphics chip ... which kind of reduces the possible boards
16:57
<vagrantc>
alkisg_web: well, actually, sane versions of u-boot will scan for boot devices in a predictible patter ...
16:58
alkisg_web: patter ... so you wouldn't even need to specify the boot device
16:58
<alkisg_web>
I mean if we're not using u-boot
16:58
If we're using u-boot, there's no kernel in the sd card to update
16:58
<vagrantc>
there is no standard for arm.
16:58
u-boot is about the closest thing, and that's even wildly varying
16:58* alkisg_web thinks we lost it a bit :)
16:59
<vagrantc>
other than the rpi, i haven't worked with any boards that boot without using u-boot.
16:59
<alkisg_web>
So, the user downloads "ltsp-pi.img", a 20 mb image that contains the blob and a premade kernel+initrd for ltsp
16:59
<ogra_>
well, if you have a uboot supported board that also has a builtin NIC, chances are good that you can just get by with only uboot on the SD
17:00
<vagrantc>
yeah, u-boot only on the SD would be my recommendation
17:00
but that's going to be fairly board specific
17:00
<ogra_>
yep
17:00
and that even goes down into the config
17:01
<vagrantc>
there's no hope for proxydhcp, though ... so you might need to hard-code the server info unless you've control of the DHCP server
17:01
<ogra_>
boards can (and many do) define their own variable names etc
17:01
<alkisg_web>
u-boot accepts patches for proxydhcp
17:01
<vagrantc>
yes, though we could target boards that stick to a standard boot scheme like config_distro_bootcmd
17:01
alkisg_web: that's the attitude!
17:02
<alkisg_web>
vagrantc: I'll leave it up to you to try it with u-boot, and I'll implement the auto-updating stuff in the meantime
17:02
<vagrantc>
that's basically what debian has done for debian-installer support
17:02
<alkisg_web>
It's also needed for some cases where ipxe doesn't work
17:02
<vagrantc>
only support boards that adhere to the config_distro_bootcmd feature
17:02Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)
17:03
<vagrantc>
alkisg_web: i've already implemented the bootscript stuff in update-kernels
17:03
<alkisg_web>
vagrantc: I don't think so... what does it do?
17:03
<vagrantc>
alkisg_web: so it should support any network-boot capable config_distro_bootcmd adhering u-boot
17:03
<alkisg_web>
I mean the part where the client gets the new initrd from the nbd squashfs image, and writes it to its /dev/mmc* or /dev/sd*
17:03
and then reboots
17:04
That would be in init-ltsp.d
17:04Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
17:04
<alkisg_web>
If you mean boot.scr, well, I didn't get u-boot running with rpi2
17:05
The end result from that solution would be an ltsp-rpi2.img image
17:06
<vagrantc>
alkisg_web: yes, i think it would be simpler to install u-boot once and use u-boot's network boot support ...
17:06* alkisg_web thinks we lost it a bit
17:06
<alkisg_web>
I can see 2 solutions, and neither one works now
17:07
<vagrantc>
but rpi/rpi2 are a pain, because they require that janky firmware image
17:07
<alkisg_web>
solution 1, u-boot: I haven't seen it work with rpi2, it needs to be investigated more, i'm not sure it'll work with the current upstream u-boot
17:07
solution 2, an init-ltsp.d script that syncs the kernels locally to the client's sd card (or disk) when they're out of date
17:07
<vagrantc>
there are general use-cases for solution 2 ... so may as well implement it
17:08
<alkisg_web>
In both cases we'd need to provide an ltsp-rpi2.img image, either with only u-boot and the blob, or with ltsp's kernel+initrd and the blob
17:08
<vagrantc>
right
17:08
<alkisg_web>
I will implement 2, and if you or someone else wants to implement 1, then I think we'll be able to say "ok it's implemented" when we have an image for it
17:08
<vagrantc>
for solution 1, it already works with numerous boards, but the rpi family are a bunch of special snowflakes.
17:09
<alkisg_web>
How do you prepare the image for the other boards?
17:09
Manually? Do we want to develop an ltsp-tool for it?
17:09
<vagrantc>
which image are you talking about?
17:09
<alkisg_web>
To boot rpi2, users will need to dd an image to an sd card
17:09
<ogra_>
and which board ?
17:09
:)
17:09
<alkisg_web>
Let's focus on that for a bit
17:09
<vagrantc>
most boards don't require an image, they just have u-boot installed ... sometimes out-of-the box ... and you turn it on.
17:10
<alkisg_web>
How will they build the image?
17:10
No cmdline or boot.scr needed?
17:10
<vagrantc>
boot.scr comes off the network
17:10
<alkisg_web>
So there are devices that boot from the network out of the box?
17:10
<vagrantc>
or, can, if it's not stupid
17:10
yes.
17:10
<alkisg_web>
OK, nice
17:11
<vagrantc>
basically, rpi makes simple things hard, but has great marketing.
17:11
<alkisg_web>
Then for the moment solution 2 will have to do, if in the future rpi2 or rpi3 comes with u-boot we'll see :)
17:15
<maldridge>
you do have to admit though that boot-strapping the GPU to then boot the CPU is a very clever solution to a problem that should never have existed
17:16
<vagrantc>
there are a lot of things like that one could admit, but what good would it do? :)
17:16
<maldridge>
fair point
17:18
<vagrantc>
alkisg_web: in all cases, rpi and rpi2 will always have to generate some sort of image.
17:19
alkisg_web: many other arm devices will probably want to have an SD image generated with u-boot on it ... though that process is dd'ing a file or files to the right location on the SD card.
17:19
alkisg_web: neither of which *should* be ltsp-specific
17:21
though to get things like hard-coded server ip and such, it may require generating a boot.scr on local mediea
17:22
<maldridge>
what about pulling those from DNS? you could use a TXT record, or more likely, a SRV record
17:22
<vagrantc>
typically they get pulled from DHCP ...
17:22
the main use-case for hard-coding server IP is when you don't have control of the network
17:23
<maldridge>
fair, I was looking at the case on the Pi where you had control of DNS, but not DHCP
17:23
though I guess that is a very rare use-case
17:23
<alkisg_web>
maldridge: dns doesn't work in debian/ubuntu's initramfs
17:24
<vagrantc>
i don't think u-boot supports DNS either ...
17:24
<maldridge>
oh? That's annoying, I've done a custom initramfs for long enough I am probably too used to having all my tools there
17:24
vagrantc: certain versions of it do, but I think mainline doesn't
17:26
<vagrantc>
mainline is really the only sane way forward...
17:27* vagrantc can't possibly follow the 1.2 trillion non-mainline repositories of u-boot and the linux kernel
17:28
<vagrantc>
alkisg_web: i just don't want to get too caught up on rpi, is all ... sounds like you've got reasonable plans forward
17:29
<alkisg_web>
vagrantc: it doesn't need much, just a bit of troubleshooting and an init-ltsp.d script
17:29
the ppa did take a lot of time... having to build and rebuild a lot of times because qemu segfaults on msgfmt...
17:34
<vagrantc>
alkisg_web: what's your PPA doing?
17:36
!rpi
17:36
<ltsp>
I do not know about 'rpi', but I do know about these similar topics: 'r'
17:36
<vagrantc>
!raspberrypi
17:36
<ltsp>
raspberrypi: (#1) LTSP with raspberry pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#2) To use a similar environment to LTSP on the raspberry pi http://berryterminal.com/, or (#3) https://github.com/gbaman/RaspberryPi-LTSP, or (#4) https://pi-ltsp.net
17:37
<vagrantc>
alkisg_web: it seems like first you'll need to generate the boot image, and then get the init-ltsp.d stuff
17:37
as you'll need the image to update...
17:39
i guess kernel/initrd updates for the generic case don't need that
17:39
generic, meaning non-rpi
17:44danau111 has joined IRC (danau111!~durban@66.251.57.114)
17:45danau111 has left IRC (danau111!~durban@66.251.57.114)
18:00
<alkisg_web>
vagrantc: the ppa has new ltsp versions that solve all those overlay/login issues, and I may also put xserver-turbo and ubuntu's latest raspi2 kernel there
18:01
<vagrantc>
ah.
18:01* vagrantc wonders if ubuntu's kernel is any better than raspbian's
18:02
<ogra_>
well, its mainline plus the RPi patches on top
18:02
<alkisg_web>
[20:39] <vagrantc> i guess kernel/initrd updates for the generic case don't need that ==> /me didn't understand that
18:02
<ogra_>
not sure what raspbian is
18:02
(what kernel i mean)
18:02
<alkisg_web>
ogra_: can I just copy that kernel to my ppa, even for 12.04/14.04?
18:03
<ogra_>
i use the 4.2 kernel on 15.04 ... at least for that i can say it is flawless
18:03
<alkisg_web>
Cool, I'll try it
18:03
<ogra_>
i would assume it works for the older releases too
18:06
<alkisg_web>
Meh, ltspfs is still failing to build on launchpad due to Changelog missing... https://launchpadlibrarian.net/221657625/buildlog_ubuntu-trusty-i386.ltspfs_1.4~r178%2Bp145%2B201510190401~ubuntu14.04.1_BUILDING.txt.gz
18:21
<vagrantc>
ogra_: i think raspbian's kernel is following the rpi foundation 3.18, last i looked ... but it's been a while
18:21
ogra_: how big is the patchset for 4.2 ?
18:21
<alkisg_web>
Yup, the CROSS_ARCH_EMULATOR issue was because I was defining ARCH in the .conf file, instead of passing --arch in the cmdline... (so that ended up setting HOST_ARCH=armhf)
18:22
<ogra_>
vagrantc, i dont know ... our kernel team maintains it ... bt enough to justify its own source package obviously
18:22
<vagrantc>
ogra_: sure.
18:22
or invasive enough, if not large enough... :)
18:23
alkisg_web: you could implement the kernel/initrd updating without implementing the rpi boot image stuff
18:24
<alkisg_web>
Once I boot the rpi2, I'll just dd it's sda1, and that will be the boot image...
18:25
<vagrantc>
alkisg_web: you're using ubuntu for the OS?
18:26
<alkisg_web>
Yes, 12.04/14.04+
18:26fncs has joined IRC (fncs!ba95552c@gateway/web/freenode/ip.186.149.85.44)
18:26
<alkisg_web>
Chroot version the same as the server
18:26
<vagrantc>
alkisg_web: raspbian has a bootloader firmware package they ship, so we could in theory build it that way.
18:26
<alkisg_web>
The bootloader firmware is in a lot of places, git, debian, ubuntu...
18:26
<vagrantc>
but that involves making a partition table with a fat partition and copying the files off it
18:27* vagrantc doesn't think debian has the firmware
18:27
<alkisg_web>
raspbian, sorry
18:27fncs has left IRC (fncs!ba95552c@gateway/web/freenode/ip.186.149.85.44, Client Quit)
18:28
<vagrantc>
one problem i've had is the firmware and kernel for the rpi tend to need to be upgraded together
18:28
i've had problems running a newer kernel on older firmware, or older kernel on newer firmware
18:28
did i mention rpi makes everything hard?
18:28
<alkisg_web>
Ouch... I did boot an rpi2 with an ubuntu kernel and a jessy/raspbian firmware though
18:29
...wheezy too, I think
18:29
It took me a few hours to realize that ubuntu-mate's "initrd7.img" wasn't used at all and I had to define it in config.txt
18:30
<vagrantc>
sometimes it works! yay! sometimes it doesn't! boo!
18:30
<alkisg_web>
Haha
18:30
<vagrantc>
maybe it's gotten better
18:30myrdd has joined IRC (myrdd!~quassel@55d43dab.access.ecotel.net)
18:30
<alkisg_web>
If that's true, it will break ltsp automatic kernel updates though
18:30
<vagrantc>
something to experiment with... :)
18:33
<ogra_>
vagrantc, you need to supply the DTB to the bootloader (and replace all the overllays too)
18:34
it definitely works fine with newer kernels
18:40
<vagrantc>
last i looked rpi supported config_distro_bootcmd, which would load the .dtb by default
18:42
<ogra_>
well, afaik the dtb name is hardcoded ... as well as the location
18:42
so you need to copy it out of /lib/firmware/device-tree where the kernel package usually puts it
18:52
<vagrantc>
the dtb name in u-boot is autodetected on boot for rpi
18:52
<ogra_>
you cant use dtbs in uboot on the rpi
18:53
<vagrantc>
and there's apparently no rpi2 .dtb files in linux mainline, not even linux-next.
18:53
<ogra_>
it has to be loaded by the blob and uboot needs to read it from ram
18:53
if you load it from disk in uboot the kernel will automatically fall back to use ATAGs
18:53
and ignore the dtb completely ...
18:53
<vagrantc>
for shame.
18:53
<ogra_>
which means only half your hardware works
18:54
<vagrantc>
this is probably why it's never worked for me...
18:54
<ogra_>
loadfdt=fdt addr 0x100; fdt get value args /chosen bootargs
18:54* vagrantc rethinks booting up the rpi boards ever again
18:54
<ogra_>
thats what i have to run before boot
18:55vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Ping timeout: 240 seconds)
18:55
<ogra_>
it also makes sure the MAC as well as the board serial end up in the $args var ... which i then append to the cmdline
18:56
<vagrantc>
so when you say it works fine, you mean it requires a lot of jiggery... :)
18:56
<ogra_>
else uboot gives you only a minimal cmdline and your MAC goes totally random
18:56
well, it requires that one line above :)
18:56
<maldridge>
s/works fine/for certain definitions of works/
18:56
<ogra_>
(you dont need to use $args indeed ... )
18:56
<vagrantc>
raspberry-special-snowflake-pi
18:57
<ogra_>
the point is, the dtb can only be loaded by the blob and uboot can only use it if it reads it from ram
18:57
(and the blob has name and location hardcoded afaik)
18:57
<vagrantc>
and the blob loads them from the SD media?
18:59lbssousa has left IRC (lbssousa!~laercio@177.143.30.47, Quit: lbssousa)
19:22decontamin4t0R has joined IRC (decontamin4t0R!~decontami@unaffiliated/decontamin4t0r)
19:23
<vagrantc>
alkisg_web: i've just requested access to upload to jessie-backports... so should be able to upload epoptes and start on LTSP related backports soon
19:23
<alkisg_web>
vagrantc: that would be very nice, it was only of the reasons I started the ppa thing...
19:23
s/only/one
19:27
vagrantc: I would need to be a DM to upload something to debian myself, right? e.g. epoptes or ltsp to sid...
19:28
<vagrantc>
alkisg_web: yup
19:31
<decontamin4t0R>
what's epoptes? I'm searching the doc and finding nothing... THinking on testing it.
19:31
<vagrantc>
!epoptes
19:31
<ltsp>
epoptes: Epoptes is a computer lab administration and monitoring tool. It works on Ubuntu and Debian based labs with LTSP or non-LTSP servers, thin and fat clients, standalone workstations, NX clients etc. More info: http://www.epoptes.org
19:32
<decontamin4t0R>
!help
19:32
<ltsp>
(help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
19:32
<decontamin4t0R>
uh cool
19:32
thx
19:33decontamin4t0R has left IRC (decontamin4t0R!~decontami@unaffiliated/decontamin4t0r, Quit: IOI - Failure. Please swing off your seat.)
19:36alkisg_web has left IRC (alkisg_web!4e5783d7@gateway/web/freenode/ip.78.87.131.215, Quit: Page closed)
19:39khildin has left IRC (khildin!~khildin@ip-213-49-116-188.dsl.scarlet.be, Quit: I'm gone, bye bye)
19:43Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)
20:32adrianorg has left IRC (adrianorg!~adrianorg@189.114.159.64, Ping timeout: 250 seconds)
20:34adrianorg has joined IRC (adrianorg!~adrianorg@177.18.50.146)
20:40ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:30manosm has joined IRC (manosm!3e01f59c@gateway/web/freenode/ip.62.1.245.156)
21:30
<manosm>
good evening
21:31
I am a teacher and I would like to establish 4 ltsp networks together for labs. How can I do it?
21:32
<maldridge>
manosm: that's still pretty broad, have you read the documentation for LTSP yet?
21:32
<manosm>
I have only one router and a managed switch. Is it possible to do it only by using to nics on every server?
21:33
No because probably I will be lost.
21:33
I need some basic instructions to follow
21:34
<maldridge>
manosm: I would highly encourage you to read the documentation, but the short answer is that you can almost certainly run LTSP assuming your computers support network booting, and that you have a decently powerful server
21:35
<manosm>
I would like to have 4 servers. Every server must control each lab pcs
21:36
<maldridge>
manosm: is your goal to have reliability of more servers, or to have seperate control over each classroom with a program such as epoptes (so that you can watch what each classroom is doing seperately)
21:36
<manosm>
seperate control
21:36
<maldridge>
manosm: one moment please
21:38
<manosm>
is it possible with two nics per server?
21:39
Another question: Can a ltsp lan work without internet access?
21:39
<maldridge>
manosm: my suggestion would be to cluster the 4 available servers into a single ltsp backend, then use epoptes to group the classrooms into individual units. I'm trying to find the page from the documentation that explains how.
21:40
<manosm>
Thanks! Q: if I follow this way I need a very strong pc?
21:41
...or the 4 servers can share the work with the thin clients?
21:44
<maldridge>
The 4 servers would balance the load among themselves with the thin clients selecting whichever server is most available at the time; I have not personally set up a cluster that way before, but I know there are those that have.
21:46
<manosm>
ok. can you give more info?
21:46
if it is possible...
21:52
<maldridge>
manosm: can you clarify your question
21:53
<manosm>
if it possible to give me more help now according to the documentations you were looking for.
21:55
<maldridge>
yes, what specifically are you trying to understand, this is quite a broad topic -- setting up an LTSP system
21:57
<manosm>
so the info about "my suggestion would be to cluster the 4 available servers into a single ltsp backend, then use epoptes to group the classrooms into individual units." is in there
21:58
What about internet? can I have a ltsp net without internet connection?
21:59
<maldridge>
you can run LTSP without internet, but it will be very labor intensive to update the servers without internet access
21:59
<manosm>
the reason I ask is because sometimes we do not have internet connection but labs must work locally
22:00
<maldridge>
actually, how many students are you planning to support
22:00
?
22:00
<manosm>
I think max 32
22:01
<maldridge>
oh, you don't need to mess with a cluster then, that would be way too much work for only 32 students
22:01
<manosm>
...so what can be better?
22:01
<maldridge>
you said you had a managed switch? Are you familiar with its management capabilities?
22:02
<manosm>
I will find a way. I was thinking about subnets
22:02
<maldridge>
given the number of students, I would set it up thusly:
22:02
each lab has a vlan assigned to it which is not routed
22:03
each server connects both to the lab's vlan, and to a vlan which is connected to the internet
22:03
<manosm>
estimate that its lab has around 10 pcs
22:03
<maldridge>
each lab has epoptes running such that you can view what students are doing, but only in that particular lab
22:04
<manosm>
yes 4 server with epoptes
22:04
which particular lab?
22:05
<maldridge>
by that I mean that the teacher computer is only capable of seeing the students in that lab, not in other labs (each lab has a teacher computer in this example)
22:05
<manosm>
yes ok
22:05
<maldridge>
you could have a single epoptes server that is able to view all the labs, but I'm not familiar with epoptes enough to know how you would group the lab machines
22:07
<manosm>
yes but all terminals will be on one servers. and its a lot of work
22:07
one server
22:11
for me the simplest thought is having 4 servers with epoptes. On every server around 10 terminals. But how can i do it without conficts?
22:11
<maldridge>
manosm: I'm about to disconnect temporarily from my local network, I will return in ~10 minutes
22:12
<manosm>
Ok for me is too late. In Greece its 1:10 am. Thanks for all. Good night
22:16
<maldridge>
np, good luck
22:17
alkisg is in your TZ and he is one of the senior people of the project, I'd ping him if you get the chance
22:17manosm has left IRC (manosm!3e01f59c@gateway/web/freenode/ip.62.1.245.156, Quit: Page closed)
22:38
<vagrantc>
doh.
22:38
that's all readonable stuff
22:38
not only in the same TZ ... in the same country :)
22:38
reasonable stuff ...
22:38
it's not an unheard of installation to have a single server per classroom
22:39
it really depends on what the actual constraints are
22:52
<maldridge>
vagrantc: that just seems very inneficient wrt epoptes, is there a way to have that span the muliptle sub-networks
22:53
<vagrantc>
well, in those cases a single teacher typically manages each classroom, so would have epoptes for each classroom
22:53
on the server
22:55
<maldridge>
what about the case where you also have a central helpdesk and you'd like them to be able to jump in, is there a way to do that?
22:55
I may be fundamentally missing how epoptes works
22:56
<vagrantc>
in epoptes, clients connect to the server ... if you have a central helpdesk they'd just have to connect to the server for the appropriate room
22:58
<maldridge>
so there is a server, a teacher component, and a client componenet; is that correct?
22:58
<vagrantc>
server, a GUI to access the server, and a client to connect to the server, sure.
22:59
<maldridge>
ok, so as long as you expose the server to the upstream network, an outside user could connect to the classroom
22:59
now you still have the issue of home folder roaming and login roaming, but I suppose that is a simple matter of ldap and nfs (though not so simple at all)
23:00
<vagrantc>
ah, yes, homedir roaming wouldn't work well in those setups.
23:00
<maldridge>
I guess you could use an NFS server in an upstream network, but that starts to get complex really fast
23:55uncmar has joined IRC (uncmar!~unkmar@host-74-221-188-129.VALOLT1.epbfi.com)
23:55* uncmar waves and looks around the room.
23:56
<uncmar>
Hey there vagrantc! Nice to see a familiar name.
23:56
<vagrantc>
uncmar: familiar from where? :)
23:57
<uncmar>
From here. Been over a year since you last assited me.
23:57
System has been working very well. I think low memory has been the biggest issue. I'm looking to try two things.
23:58
First. All those sytems already have an HDD with Linux. IE: they have a swap partition that could be mounted.
23:59
Second. Debian 8 has been out for a little while. Has LTSP moved forward with that?