IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 3 October 2015 (all times are UTC)
| 01:10 | work_alkisg is now known as alkisg | |
| 01:11 | <alkisg> vagrantc: sorry for the nbd-server-stop typo, thanks for the fix
| |
| 01:13 | <vagrantc> alkisg: happy to be useful. :)
| |
| 01:13 | <alkisg> So, phantomas says it's ok for an epoptes release
| |
| 01:14 | <vagrantc> yeah, got the email
| |
| 01:14 | <alkisg> I could try to integrate some of the patches that cyberorg and lbssousa sent, before releasing...
| |
| 01:14 | * vagrantc is still struggling with what the best way forward for LTSP in Debian is | |
| 01:14 | <alkisg> NFS?
| |
| 01:15 | <vagrantc> that's the main blocker...
| |
| 01:15 | encrypted swap needs some looking into
| |
| 01:15 | might have some time this weekend to dive in, but if i can't come to a resolution i'll still need to spend a bit of time switching the default to NBD
| |
| 01:16 | <alkisg> Do you have to decide/change that now? Isn't NFS overlay support going to be fixed before stretch is released?
| |
| 01:16 | <vagrantc> i struggle with uploading a package in which the default supported configuration is utterly broken...
| |
| 01:16 | <alkisg> True, that... :-/
| |
| 01:17 | <vagrantc> i guess it technically could depend on the jessie kernel... heh.
| |
| 01:18 | alkisg: the support is there for aufs in the kernel, but would have to maintain a dkms package for each kernel version
| |
| 01:19 | and haven't yet tested how well it works with linux 4.x
| |
| 01:19 | <alkisg> vagrantc: or, persuade them to keep it compiled because of this problem?
| |
| 01:19 | https://lists.debian.org/debian-kernel/2014/12/msg00136.html
| |
| 01:19 | "I am assuming that this will cover the needs of Debian live systems, so I've dropped aufs from the Debian packaging. "
| |
| 01:19 | what if you tell them "no, it doesn't, let's do that when nfs is working"
| |
| 01:19 | ...and have a link with the upstream issue for the broken nfs support
| |
| 01:20 | They can drop it in stretch+1 then...
| |
| 01:21 | <vagrantc> i spent a bit of time hashing it over with ben (the debian kernel maintainer) and struggled for a couple days during debconf to test patches for NFS support ...
| |
| 01:22 | i probably need to start filing bugs on LTSP in debian to mark other bugs as blocking LTSP's bugs...
| |
| 01:22 | <alkisg> For the "squashfs file over nfs" initramfs patches, while it's a good thing to have support for, I think I prefer nbd instead of that solution
| |
| 01:23 | <vagrantc> i've still found NBD to be a little flaky when it comes to updating images...
| |
| 01:23 | <alkisg> I didn't get that one, what do you mean?
| |
| 01:24 | <vagrantc> the whole "restart nbd-server kicks off all the active clients" thing?
| |
| 01:24 | also, temporary networking failures seem to cause NBD to crash
| |
| 01:24 | <alkisg> updating an image doesn't require server restart
| |
| 01:24 | <vagrantc> but it doesn't free up the disk space from the deleted images until all the clients reboot
| |
| 01:25 | <alkisg> teachers here report that "we have networking issues or unplug cables etc, but the clients then continue to work, why does epoptes thumbnails stop appearing"
| |
| 01:25 | (epoptes automatically disconnects after 15 seconds)
| |
| 01:25 | ...maybe those issues have been resolved?
| |
| 01:25 | <vagrantc> i seem to recall having those issues recently...
| |
| 01:25 | with this new install i've set up
| |
| 01:26 | <alkisg> About the deleted image not being freed up, isn't that exactly what it's supposed to do?
| |
| 01:26 | If you could find a way to reproduce it, we could ping wouter or try if xnbd fixes it
| |
| 01:26 | <vagrantc> yes, but i've run out of disk space on a few servers when frequently rebuilding images
| |
| 01:27 | and it's one of those mysterious "why is all the disk space taken up, when I can plainly see that there is plenty of disk space" mental frustrations
| |
| 01:28 | i've gotten in the habit of running "lsof | grep deleted" regularly
| |
| 01:29 | <alkisg> If one is frequently rebuilding images, he should also reboot the clients frequently...
| |
| 01:29 | I don't find that a significant issue, I think that allowing the clients to continue to work while having already deleted the file is the correct thing to do,
| |
| 01:30 | except maybe for ls, df etc to be somehow more verbose and say where the empty space is
| |
| 01:30 | but that's another story
| |
| 01:30 | <vagrantc> i agree ... but it's baffled myself and my *coworkers* on many occasions
| |
| 01:30 | <alkisg> What I could like though is for mksquashfs, nbd etc to be able to produce and use diff images
| |
| 01:31 | Like, "compress this directory tree for me, but somehow make use of the previous image I did 5 hours ago"
| |
| 01:31 | Either to save compression time, or to make a second i386.img.diff file that either nbd-server could use directly, or the ltsp clients in /dev/nbd1 indirectly
| |
| 01:31 | <vagrantc> i think i know how to do that...
| |
| 01:32 | there's mksquashfs -apend
| |
| 01:32 | <alkisg> I think that doesn't compare things, it just appends them
| |
| 01:32 | <vagrantc> or rather, -noappend
| |
| 01:33 | sure, so you generate the diff and append any changes...
| |
| 01:33 | <alkisg> Like, first loop mount it read-only, then generate the .diff in /tmp/, and then unmount it and call mksquashfs -append?
| |
| 01:34 | *diff with rsync
| |
| 01:34 | <vagrantc> something like that
| |
| 01:34 | kind of annoying, but would probably really speed up compression and save a lot of space
| |
| 01:35 | alkisg: could also do an overlay FS with the RO squashfs image, and then simply append what's in the COW
| |
| 01:36 | <alkisg> For manual changes? Sure, but that doesn't reflect actual chroot or ltsp-pnp style changes, right?
| |
| 01:36 | I think I would prefer it if ltsp supported one small .diff image
| |
| 01:37 | <vagrantc> might be possible...
| |
| 01:37 | oh, we could add the .diff images to the overlay layers
| |
| 01:37 | <alkisg> like the concept of full backups every once in a while, and one differencial (not incremental)
| |
| 01:37 | Right
| |
| 01:37 | <vagrantc> that'd be cool.
| |
| 01:38 | <alkisg> That way the deleted images would be small, as only the differencial would be deleted
| |
| 01:38 | (frequently)
| |
| 01:38 | ltsp-update-image --quick or --full
| |
| 01:39 | <vagrantc> like the premise, though do want to get a new upstream version uploaded before implementing... :)
| |
| 01:39 | <alkisg> The default being quick if the .diff is under some size or with a date comparison
| |
| 01:44 | Btw I reported the nbd-server stop/start issue upstream in systemd, lennart says "won't fix": https://github.com/systemd/systemd/issues/1445
| |
| 01:48 | <vagrantc> alkisg: i guess nbd-server should have a proper .service file, then...
| |
| 01:49 | <alkisg> vagrantc: until all those services have proper .service files, a quick fix is to put the :pidfile = stanza in them
| |
| 01:50 | I'll put it in epoptes, it doesn't hurt...
| |
| 01:53 | vagrantc: so, what are your planning dates for releasing ltsp/epoptes? Do I have time to send more fixes in?
| |
| 01:53 | <vagrantc> alkisg: reported a bug in Ubuntu/Debian about nbd-server start/stop ?
| |
| 01:53 | <alkisg> No, I didn't
| |
| 01:54 | <vagrantc> alkisg: might be worth doing, since upstream basically said "wontfix"
| |
| 01:54 | <alkisg> I had spent 10 hours straight at that time, reporting other bugs with wily
| |
| 01:54 | so I thought I'd use my time somewhere where it would help more
| |
| 01:54 | <vagrantc> alkisg: probably won't release either before late Sunday, more likely monday
| |
| 01:55 | <alkisg> Cool
| |
| 01:55 | * vagrantc has been saying that for each week for the last 3 weeks, notably | |
| 01:55 | <alkisg> For now, I'm troubleshooting a bug where thin clients don't login with lubuntu 14.04
| |
| 01:55 | * vagrantc has just been kind of hoping the NFS issue would fix itself in newer kernels... | |
| 01:56 | <alkisg> If you delay it for 10 more days, you'll probably have some rpi2 related fixes from me as well :D
| |
| 01:56 | <vagrantc> oh, nice.
| |
| 01:56 | <alkisg> Someone sent me 3 of them, so I'll be playing a bit with them...
| |
| 01:56 | <vagrantc> alkisg: i've got an rpi2 as well, so i could test the fixes, workarounds, etc.
| |
| 01:56 | <alkisg> That's nice!
| |
| 01:57 | <vagrantc> i've also got an older model rpi B (256MB ram)
| |
| 01:57 | <alkisg> Basically I want the tftp folder to map what should go in the card's boot partition,
| |
| 01:58 | <vagrantc> unfortunately, the boot partition needs non-free firmware bits :(
| |
| 01:58 | <alkisg> and maybe an ltsp-create-bootable-image tool or something similar, to format/copy to the SD cards
| |
| 01:58 | <vagrantc> notably, the GPU boots the CPU, not the other way around...
| |
| 01:58 | <alkisg> Doesn't the raspbian chroot include those?
| |
| 01:58 | <vagrantc> i think it's possible to include them, sure.
| |
| 01:59 | with rpi2, you should be able to actually run straight Debian armhf, and only pull in a handful of raspbian packages.
| |
| 01:59 | <alkisg> Which one would you recommend?
| |
| 02:00 | If raspbian is focused to rpi, maybe they'd make a better default? For our examples/ltsp-build-client-rpi.conf sample file, that is...
| |
| 02:02 | <vagrantc> honestly, probably both ... as raspbian is needed to support older rpi, and the performance gains from armv7 are probably not huge ... but the raspbian packages do lag a bit from Debian ... so i tend to prefer Debian for as much as you can get away with, and raspbian only for the necessary bits ("bootloader", kernel, etc.)
| |
| 02:02 | i guess you could use a hybrid approach with armel ...
| |
| 02:03 | <alkisg> Well maybe we can just ship a couple of different example ltsp-build-client.conf files
| |
| 02:03 | <vagrantc> which could support all of the above ... but armel takes more of a performance hit
| |
| 02:03 | <alkisg> With different sources.list and default packages
| |
| 02:03 | <vagrantc> yeah, i see valid use cases for all of the above
| |
| 02:03 | although really, raspberrypi foundation needs to get their kernel patches upstreamed !!!%#$@%@#
| |
| 02:04 | <alkisg> Haha
| |
| 02:04 | Were you successfull in emulating a PI's boot process with qemu?
| |
| 02:04 | * vagrantc wonders if the "bootloader" firmware is acceptible for debian non-free section | |
| 02:04 | <alkisg> I was only able to do it with some kernel that I downloaded from the internet
| |
| 02:04 | <vagrantc> alkisg: can't imagine that would be feasible ... too much closed-source hardware/software
| |
| 02:04 | <alkisg> ...named kernel-qemu
| |
| 02:05 | <vagrantc> it might just be pretending
| |
| 02:05 | <alkisg> I just wanted to see a typical armhf booting, not specifically the pi
| |
| 02:06 | <vagrantc> oh, i think the cubieboard is mainlined in qemu, but i haven't successfully booted with it
| |
| 02:06 | do have a physical cubieboard
| |
| 02:06 | <alkisg> What loads the kernel and cmdline.txt file? Is something like uboot hardcoded somewhere in some ROM?
| |
| 02:09 | <vagrantc> the GPU loads the binary firmware which loads the cmdline.txt and kernel and ... boots the CPU.
| |
| 02:09 | the rpi is a most unusual architecture
| |
| 02:10 | <alkisg> ah, the binary firmware is also the "bootloader"...
| |
| 02:10 | can read vfat, load the kernel...
| |
| 02:10 | <vagrantc> the rpi stuff is nothing like any of the other boards.
| |
| 02:10 | other boards look for code to execute in NAND or SD (such as u-boot), and then the code does whatever it does
| |
| 02:11 | <alkisg> So cmdline.txt is completely pi-specific, not common to other boards
| |
| 02:11 | <vagrantc> yes
| |
| 02:12 | some builds of u-boot support uEnv.txt, which sets some u-boot environment variables ... can also load and execute u-boot scripts (often .scr) which are basically just u-boot shell commands.
| |
| 02:13 | <alkisg> Android also doesn't use uboot, right? So I don't think I have any device that uses it, yet...
| |
| 02:14 | So anyway, since integrating those patches about making LDM more verbose, I've had several regressions
| |
| 02:14 | E.g. now the verbose part says "user@server's password: "
| |
| 02:14 | ...i.e. it waits for me to give it a password, while I already gave it to ldm
| |
| 02:20 | * vagrantc was thinking of doing quick LDM and ltspfs (virtually no changes there) uploads | |
| 02:20 | <vagrantc> alkisg: but if the patches you're looking at are for LDM, i suppose i should wait
| |
| 02:21 | <alkisg> vagrantc: my plan is to have LTSP in wily working, I don't know what that will involve...
| |
| 02:21 | (and also all other wily-related bugs at least file in launchpad, if not worked around in ltsp/sch-scripts)
| |
| 02:21 | <vagrantc> alkisg: 11.04 ?
| |
| 02:21 | <alkisg> *filed
| |
| 02:21 | 15.10
| |
| 02:21 | <vagrantc> alkisg: er, 16.04
| |
| 02:21 | oh.
| |
| 02:21 | <alkisg> As a preparation for 16.04, yes
| |
| 02:29 | can't open display, nice lubuntu... :-/
| |
| 02:29 | * alkisg hates xauthority issues | |
| 02:35 | <alkisg> Half of the times, the client boot process stucks at "A start jobs is running for LSB : raising network interfaces"
| |
| 02:39 | hey cool, systemd quickly shows that `networking start` spawned `udevadm settle`, which is still running
| |
| 02:39 | Once udevadm settle was done, 1 minute later, the boot process continued
| |
| 02:40 | (2 minutes later, the timeout period of udevadm settle)
| |
| 02:43 | OK lubuntu 15.10 works fine with the defaults, i.e. without LDM_DIRECTX=True (with ltsp-trunk of course)
| |
| 02:43 | Now to see why LDM_DIRECTX=True is now broken... :-/
| |
| 02:45 | <vagrantc> but regular ubuntu works?
| |
| 02:45 | <alkisg> ...s/now/later/ :)
| |
| 02:45 | I'm not sure
| |
| 02:46 | I was trying with fat clients, not things
| |
| 02:46 | *thins
| |
| 02:46 | I'll check it out later on in the morning
| |
| 02:46 | <vagrantc> oh wow
| |
| 02:53 | alkisg is now known as work_alkisg | |
| 03:04 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 05:05 | <cyberorg> work_alkisg, i may have mentioned before, on suse we use unionfs-fuse for nfsroot since few years now
| |
| 05:06 | <work_alkisg> cyberorg: ah, wait for vagrantc to show up, he's the one using nfs
| |
| 05:06 | Here we've developed and are used ltsp-pnp by default, so no nfs possible
| |
| 05:07 | *are using
| |
| 05:08 | <cyberorg> also using prebuilt images solves building and compression time for everyone
| |
| 05:09 | <work_alkisg> prebuilt images are not possible here, each school has its own needs, so they learn to use software center and then they go to sch-scripts and select update image from the menus
| |
| 05:09 | <cyberorg> see https://github.com/openSUSE/kiwi/blob/master/modules/KIWILinuxRC.sh mountSystemUnionFS
| |
| 05:09 | <work_alkisg> E.g. some need proprietary software that is not redistributable, impossible to include to prebuilt images
| |
| 05:10 | <cyberorg> yup, then they have to unpack and repack the prebuilt image like https://sourceforge.net/p/kiwi-ltsp/wiki/Customizing%20Image/
| |
| 05:11 | <work_alkisg> Selecting a package from software center is much easier, supported and documented
| |
| 05:11 | That's why we moved away from chroots
| |
| 05:11 | Even installing packages in chroots was broken at times, with dbus, upstart etc
| |
| 05:12 | If lxc allows chroots to be bootable with xorg and all, like VMs, it may make them easy again
| |
| 05:12 | <cyberorg> wonder what machinectl would bring
| |
| 05:14 | <work_alkisg> The main point is not to reinvent the wheel; users want to maintain a desktop machine, they should be able to do it in the traditional desktop way, install a desktop cd, use software center to install packages, have popup update messages etc etc
| |
| 05:15 | ltsp-pnp is good in that they not only maintain a desktop instead of a chroot, they only maintain _one_ desktop, because the server is reused as a template for the clients
| |
| 05:15 | So even if lxc etc are optimized, ltsp-pnp will still be better as long as it works
| |
| 05:16 | (and fortunately it appears more stable than chroots so far)
| |
| 05:16 | <cyberorg> yup, not sure anything else will give that advantage
| |
| 06:27 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi) | |
| 06:44 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 07:45 | F-GT has left IRC (F-GT!~phantom@ppp121-44-57-79.lns20.syd4.internode.on.net, Read error: Connection reset by peer) | |
| 07:46 | epoptes_user7 has joined IRC (epoptes_user7!58b521fb@gateway/web/freenode/ip.88.181.33.251) | |
| 07:49 | epoptes_user7 has left IRC (epoptes_user7!58b521fb@gateway/web/freenode/ip.88.181.33.251, Client Quit) | |
| 10:32 | work_alkisg is now known as alkisg | |
| 10:36 | fnurl has joined IRC (fnurl!650e83dc@gateway/web/freenode/ip.101.14.131.220) | |
| 10:41 | komunista has joined IRC (komunista!~slavko@87.244.209.121) | |
| 10:42 | komunista has left IRC (komunista!~slavko@87.244.209.121) | |
| 10:50 | fnurl has left IRC (fnurl!650e83dc@gateway/web/freenode/ip.101.14.131.220, Quit: Page closed) | |
| 11:16 | <alkisg> OK I got the 15.10 issue, http://cgit.freedesktop.org/xorg/xserver/commit/?id=cc59be38b7eff52a1d003b390f2994c73ee0b3e9
| |
| 11:29 | adrianorg has left IRC (adrianorg!~adrianorg@179.182.75.70, Ping timeout: 260 seconds) | |
| 11:31 | adrianorg has joined IRC (adrianorg!~adrianorg@177.204.77.140.dynamic.adsl.gvt.net.br) | |
| 11:38 | riddle has left IRC (riddle!riddle@us.yunix.net, Quit: Lost terminal) | |
| 11:39 | riddle has joined IRC (riddle!riddle@us.yunix.net) | |
| 15:24 | khildin has joined IRC (khildin!~khildin@ip-62-235-42-27.dial.scarlet.be) | |
| 15:48 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |
| 15:48 | khildin has left IRC (khildin!~khildin@ip-62-235-42-27.dial.scarlet.be, Ping timeout: 265 seconds) | |
| 16:13 | cor_geeks has joined IRC (cor_geeks!~cor@cpe-76-92-215-174.kc.res.rr.com) | |
| 16:14 | cor_geeks is now known as eadthem_cor | |
| 17:18 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
| 17:24 | khildin has joined IRC (khildin!~khildin@ip-62-235-42-27.dial.scarlet.be) | |
| 17:41 | <alkisg> !arcfour
| |
| 17:41 | <ltsp> arcfour: http://en.wikipedia.org/wiki/RC4 is an SSH cipher which is more than 2 times faster than the default aes128-ctr. To enable it, set LDM_SSHOPTIONS="-o Ciphers=arcfour128,chacha20-poly1305@openssh.com,aes128-ctr".
| |
| 18:41 | andygraybeal has left IRC (andygraybeal!~andy@40.133.169.240, Read error: Connection reset by peer) | |
| 18:42 | andygraybeal has joined IRC (andygraybeal!~andy@40.133.169.240) | |
| 19:12 | khildin has left IRC (khildin!~khildin@ip-62-235-42-27.dial.scarlet.be, Remote host closed the connection) | |
| 19:40 | <alkisg> !forget arcfour
| |
| 19:40 | <ltsp> The operation succeeded.
| |
| 19:41 | <muppis> Wasn't usable after all?
| |
| 19:41 | <alkisg> !learn arcfour as `http://en.wikipedia.org/wiki/RC4 is an SSH cipher which is more than 2 times faster than the default aes128-ctr. To enable it, set LDM_SSHOPTIONS="-o Ciphers=arcfour128". It's deprecated since Ubuntu 15.04.
| |
| 19:41 | <ltsp> Error: No closing quotation
| |
| 19:42 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 19:42 | <alkisg> !learn arcfour as `http://en.wikipedia.org/wiki/RC4 is an SSH cipher which is more than 2 times faster than the default aes128-ctr. To enable it, set LDM_SSHOPTIONS="-o Ciphers=arcfour128". It's deprecated since Ubuntu 15.04 and it needs to be manually enabled in sshd_config.`
| |
| 19:42 | <ltsp> The operation succeeded.
| |
| 19:42 | <alkisg> !arcfour
| |
| 19:42 | <ltsp> arcfour: http://en.wikipedia.org/wiki/RC4 is an SSH cipher which is more than 2 times faster than the default aes128-ctr. To enable it, set LDM_SSHOPTIONS="-o Ciphers=arcfour128". It's deprecated since Ubuntu 15.04 and it needs to be manually enabled in sshd_config.
| |
| 19:43 | * alkisg ended up doing a lot of version checks lately... haven't done so since trying to make some websites compatible with IE4 :( | |
| 19:55 | alkisg is now known as work_alkisg | |
| 20:05 | vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Ping timeout: 264 seconds) | |
| 21:15 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 22:38 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 252 seconds) | |
| 23:11 | adrianorg has left IRC (adrianorg!~adrianorg@177.204.77.140.dynamic.adsl.gvt.net.br, Ping timeout: 272 seconds) | |
| 23:11 | adrianorg has joined IRC (adrianorg!~adrianorg@177.204.77.140.dynamic.adsl.gvt.net.br) | |
| 23:13 | gbaman has joined IRC (gbaman!~gbaman@host81-139-206-234.in-addr.btopenworld.com) | |
| 23:16 | eadthem_cor has left IRC (eadthem_cor!~cor@cpe-76-92-215-174.kc.res.rr.com, Quit: Leaving) | |