IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 19 October 2015 (all times are UTC)
| 00:19 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 00:30 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Read error: Connection reset by peer) | |
| 00:31 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 01:00 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection) | |
| 01:35 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 01:41 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 240 seconds) | |
| 02:29 | fnurl has left IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95, Ping timeout: 246 seconds) | |
| 02:38 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 02:39 | fnurl has joined IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95) | |
| 02:42 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 264 seconds) | |
| 02:46 | fnurl has left IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95, Ping timeout: 246 seconds) | |
| 03:26 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 252 seconds) | |
| 03:33 | fnurl has joined IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95) | |
| 04:25 | work_alkisg has left IRC (work_alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 250 seconds) | |
| 04:31 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 272 seconds) | |
| 04:34 | fnurl has left IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95, Ping timeout: 246 seconds) | |
| 04:40 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 04:40 | Tex has left IRC (Tex!4ac0a1b7@gateway/web/freenode/ip.74.192.161.183, Quit: Page closed) | |
| 04:43 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 04:45 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 268 seconds) | |
| 05:07 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi) | |
| 05:53 | ricotz has joined IRC (ricotz!~ricotz@p5B2A97BA.dip0.t-ipconnect.de) | |
| 05:53 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 06:02 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 06:28 | mikkel 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:00 | alkisg is now known as work_alkisg | |
| 07:07 | uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek) | |
| 07:11 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 07:19 | khildin has joined IRC (khildin!~khildin@ip-213-49-116-188.dsl.scarlet.be) | |
| 07:41 | manosZ has joined IRC (manosZ!c23fefeb@gateway/web/freenode/ip.194.63.239.235) | |
| 07:49 | work_alkisg has left IRC (work_alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 240 seconds) | |
| 07:53 | manosZ 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:06 | khildin has left IRC (khildin!~khildin@ip-213-49-116-188.dsl.scarlet.be, Ping timeout: 240 seconds) | |
| 08:25 | khildin has joined IRC (khildin!~khildin@ip-213-49-116-188.dsl.scarlet.be) | |
| 08:39 | alkisg_web has joined IRC (alkisg_web!4e5783d7@gateway/web/freenode/ip.78.87.131.215) | |
| 08:48 | khildin 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:56 | larryni has joined IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com) | |
| 09:11 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
| 09:16 | sutula has left IRC (sutula!~sutula@207-118-165-192.dyn.centurytel.net, Quit: ZNC - http://znc.sourceforge.net) | |
| 09:16 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 250 seconds) | |
| 09:16 | sutula 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:22 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 10:02 | andygraybeal has left IRC (andygraybeal!~andy@h232.76.191.173.dynamic.ip.windstream.net, Ping timeout: 240 seconds) | |
| 10:13 | andygraybeal has joined IRC (andygraybeal!~andy@h17.73.191.173.dynamic.ip.windstream.net) | |
| 10:21 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 250 seconds) | |
| 10:22 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 10:24 | SYS64738 has joined IRC (SYS64738!~SYS64738@159.213.93.166) | |
| 10:24 | <SYS64738> hi
| |
| 10:30 | <alkisg_web> Hello
| |
| 10:44 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 10:48 | Faith has joined IRC (Faith!~paty_@unaffiliated/faith) | |
| 10:57 | andygraybeal 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:10 | andygraybeal has joined IRC (andygraybeal!~andy@h227.20.30.71.dynamic.ip.windstream.net) | |
| 11:14 | alkisg_web has left IRC (alkisg_web!4e5783d7@gateway/web/freenode/ip.78.87.131.215, Quit: Page closed) | |
| 11:14 | larryni has left IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com, Ping timeout: 264 seconds) | |
| 11:25 | alkisg_web has joined IRC (alkisg_web!4e5783d7@gateway/web/freenode/ip.78.87.131.215) | |
| 11:52 | alkisg_web has left IRC (alkisg_web!4e5783d7@gateway/web/freenode/ip.78.87.131.215, Quit: Page closed) | |
| 11:57 | kione 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:01 | lbssousa has joined IRC (lbssousa!~laercio@177.143.30.47) | |
| 12:31 | danau11 has left IRC (danau11!~durban@66.251.57.114) | |
| 12:34 | kione has left IRC (kione!57806687@gateway/web/freenode/ip.87.128.102.135, Quit: Page closed) | |
| 12:38 | khildin has joined IRC (khildin!~khildin@ip-213-49-116-188.dsl.scarlet.be) | |
| 13:10 | Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving) | |
| 13:17 | lbssousa has left IRC (lbssousa!~laercio@177.143.30.47, Quit: lbssousa) | |
| 13:54 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 14:18 | alkisg_web has joined IRC (alkisg_web!4e5783d7@gateway/web/freenode/ip.78.87.131.215) | |
| 14:29 | virara has joined IRC (virara!c3391364@gateway/web/freenode/ip.195.57.19.100) | |
| 14:45 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 14:52 | Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas) | |
| 15:04 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 246 seconds) | |
| 15:17 | lbssousa has joined IRC (lbssousa!~laercio@177.143.30.47) | |
| 15:22 | bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy) | |
| 15:52 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 16:08 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Read error: Connection timed out) | |
| 16:09 | gbaman 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:20 | Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas, Quit: Leaving.) | |
| 16:22 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 16:23 | Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net) | |
| 16:25 | danau11 has joined IRC (danau11!~durban@66.251.57.114) | |
| 16:26 | danau11 has left IRC (danau11!~durban@66.251.57.114) | |
| 16:29 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Ping timeout: 264 seconds) | |
| 16:29 | thedarkener has left IRC (thedarkener!~thedarken@c128.thedarkener.com, Ping timeout: 264 seconds) | |
| 16:31 | thedarkener 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:42 | ben_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:49 | Faith 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:54 | gvy 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:02 | Faith 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:04 | Faith 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:44 | danau111 has joined IRC (danau111!~durban@66.251.57.114) | |
| 17:45 | danau111 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:26 | fncs 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:27 | fncs 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:30 | myrdd 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:55 | vmlintu 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:59 | lbssousa has left IRC (lbssousa!~laercio@177.143.30.47, Quit: lbssousa) | |
| 19:22 | decontamin4t0R 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:33 | decontamin4t0R has left IRC (decontamin4t0R!~decontami@unaffiliated/decontamin4t0r, Quit: IOI - Failure. Please swing off your seat.) | |
| 19:36 | alkisg_web has left IRC (alkisg_web!4e5783d7@gateway/web/freenode/ip.78.87.131.215, Quit: Page closed) | |
| 19:39 | khildin has left IRC (khildin!~khildin@ip-213-49-116-188.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 19:43 | Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving) | |
| 20:32 | adrianorg has left IRC (adrianorg!~adrianorg@189.114.159.64, Ping timeout: 250 seconds) | |
| 20:34 | adrianorg has joined IRC (adrianorg!~adrianorg@177.18.50.146) | |
| 20:40 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:30 | manosm 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:17 | manosm 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:55 | uncmar 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?
| |