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


Channel log from 26 November 2013   (all times are UTC)

00:01telex has left IRC (telex!~telex@freeshell.de, Ping timeout: 272 seconds)
00:03telex has joined IRC (telex!~telex@freeshell.de)
00:12freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
00:38gbit has left IRC (gbit!~chatzilla@unaffiliated/gbit, Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018])
00:52willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Computer has gone to sleep.)
00:58freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
01:11willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
01:13willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Client Quit)
01:19lmds_ has left IRC (lmds_!~lmds@tui.pi-et-ro.net, Read error: Connection reset by peer)
01:53xcom has left IRC (xcom!~wtf@pdpc/supporter/professional/seri, Ping timeout: 246 seconds)
02:00xcom has joined IRC (xcom!~wtf@23.30.88.89)
02:00xcom has joined IRC (xcom!~wtf@pdpc/supporter/professional/seri)
02:14gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
02:19gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Ping timeout: 264 seconds)
02:26Parker955 is now known as Parker955_Away
02:27Parker955_Away is now known as Parker955
03:01PhoenixSTF has left IRC (PhoenixSTF!~rudi@78.29.159.239, Quit: Leaving)
03:30willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
04:11Fenuks has joined IRC (Fenuks!~Fenuks@109.202.25.212)
04:17gbaman has joined IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com)
04:17Fenuks has left IRC (Fenuks!~Fenuks@109.202.25.212, Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/)
04:18Fenuks has joined IRC (Fenuks!~Fenuks@109.202.25.212)
04:22gbaman has left IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com, Ping timeout: 246 seconds)
04:23willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Computer has gone to sleep.)
04:48alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
04:55
<alkisg>
Good morning
04:55* vagrantc waves
04:55
<alkisg>
Ubuntu has a separate ltspfs package from debian just for "+ltspfs_LDFLAGS = -pthread" ?
04:55
<vagrantc>
alkisg: yup
04:55
<alkisg>
We can't put that in a conditional?
04:56* vagrantc pushed it upstream
04:56
<vagrantc>
but maybe that was not the right thing to do?
04:57
<alkisg>
Ah, nice. Sure, since ltspfs.c is using pthreads, we should link to it.
04:57
<vagrantc>
still worked fine fo rme
04:57* alkisg got some build warnings from launchpad for ltspfs on ...lucid!
04:57
<alkisg>
From our daily recipe...
04:57
https://launchpad.net/~ltsp-upstream/+archive/daily/+build/5268323/+files/buildlog_ubuntu-lucid-amd64.ltspfs_0.9%2Bbzr160%2B201311260034-0ubuntu1%2B3%7Eubuntu10.04.1_FAILEDTOBUILD.txt.gz
05:03* alkisg removes daily translations commits for ldm for yet one more time...
05:03brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-oaheeminmmughjxh, Ping timeout: 245 seconds)
05:03mgariepy has left IRC (mgariepy!mgariepy@ubuntu/member/mgariepy, Ping timeout: 245 seconds)
05:04mgariepy has joined IRC (mgariepy!mgariepy@ubuntu/member/mgariepy)
05:04brunolambert has joined IRC (brunolambert!brunolambe@nat/revolutionlinux/x-hbkbsrajbbiupful)
05:05lns has joined IRC (lns!~lns@pdpc/supporter/professional/lns)
05:13brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-hbkbsrajbbiupful, Read error: Connection reset by peer)
05:17alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
05:30alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
06:21gbaman has joined IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com)
06:25gbaman has left IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com, Ping timeout: 246 seconds)
06:56alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 252 seconds)
07:04work_alkisg has left IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr, Ping timeout: 272 seconds)
07:10work_alkisg has joined IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr)
07:11work_alkisg is now known as alkisg
07:11
<alkisg>
vagrantc: about the pxelinux.cfg/default mess.... I think it's still too complicated
07:11
I suggest we reimplement it like this:
07:12
Use standard names for symlinks: vmlinuz, vmlinuz-i386 vmlinuz-pae, vmlinuz-amd64 etc
07:12
This will also help people that use pxelinux.cfg/01-mac-address entries, and if we ever implement a gui for such files, it will also help there too, so symlinks are nice to have in any case,
07:13
Then, update-kernels would only generate pxelinux.cfg/default if it doesn't exist. It wouldn't touch it otherwise. It would put the distro defaults there.
07:14
So people would just need to manually edit pxelinux.cfg/default, they wouldn't need to change any configuration files which make it complicated
07:14
The standard symlink names could be the same for all distros that support ltsp, unrelated to the real kernel names that each distro has
07:16
And the symlinks would also help people implementing global menus in /var/lib/tftpboot/pxelinux.cfg
07:17
<vagrantc>
alkisg: symlinks are kind of deprecated on Debian
07:18
<alkisg>
vagrantc: We'll manage them ourselfves, we wouldn't rely on the symlinks generated by the kernel packages
07:18
<vagrantc>
alkisg: the kernel team wants people to start using versioned files in bootloaders and whatnot... meh.
07:19
managing those symlinks can be an adventure... but i guess we're already doing that with the versioning code
07:19
<alkisg>
Right
07:19
It'll simplify things, not make them worse
07:19
Because now we have to do it in many places
07:20
While after that proposed implementation, only the kernel postinst would generate the symlinks, then the pxelinux.cfg generation code would be distro/kernel agnostic
07:20
<vagrantc>
hmmm.
07:20
wait, the kernel postinst will generate symlinks?
07:20
<alkisg>
The hook, update-kernels
07:20
<vagrantc>
where we have the update-kernels hook, ok.
07:21
<alkisg>
For example, I can't even remember the steps needed to make pxelinux.cfg/default changes stick currently :D
07:21
While with that implementation, we'd tell people "just go ahead and edit the files in tftp"
07:21
<vagrantc>
alkisg: getting those symlinks standardized across distros might not be so simple.
07:21
<alkisg>
Why not?
07:22
<vagrantc>
alkisg: amd64 vs. x86_64? i386 vs. i686 ?
07:22
<alkisg>
We only care about things supported by pxelinux, ifcpu64 and the like
07:22
We can't differentiate about other things anyway
07:23
We can name them as pxelinux does
07:23
<vagrantc>
ah.
07:23
good call.
07:23
<alkisg>
We don't care at all about the actual filename that each distro uses
07:23gbaman has joined IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com)
07:24
<alkisg>
That part, getting the newer kernel for i386/non-pae/amd64, would be our only distro-specific code, along with the default kernel parameters
07:24
And if one wants to switch to nfs etc, he'd just manually update the file. Once.
07:24
<vagrantc>
well, pxelinux doesn't really implement a naming sceme
07:24
scheme
07:24
alkisg: the kernel update hooks are distro specific
07:25
alkisg: i don't think any other distros are using update-kernels
07:25
but it would be nice to bring everybody back on the same page
07:25
<alkisg>
Well, to update the initramfs, all distros have some hook, right?
07:25
<vagrantc>
i guess, we could go with -32, -pae, -64 ...
07:25* alkisg check the pxelinux wiki...
07:26
<alkisg>
Is that the newest thing? http://www.syslinux.org/wiki/index.php/Ifcpu.c32
07:27
Branching based on processor flags?! :)
07:27
<vagrantc>
steps to make changes stick: edit <chroot>/etc/ltsp/update-kernels ; ltsp-chroot /usr/share/ltsp/update-kernels ; ltsp-update-kernels
07:27
alkisg: that's been around a while
07:27
if you really want some fun: http://www.syslinux.org/wiki/index.php/Lua.c32
07:27
<alkisg>
Aren't we using this one now? http://www.syslinux.org/wiki/index.php/Ifcpu64.c32
07:27
Woah!
07:28gbaman has left IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com, Ping timeout: 246 seconds)
07:28
<vagrantc>
alkisg: yes, we're using ifcpu64 ... although not by default, even.
07:29
<alkisg>
So with Lua we could do hardware detection and _then_ add kernel parameters? Nice!!!
07:30* vagrantc nods
07:31
<vagrantc>
that is getting a bit adventurous, should probably fix our defaults a simpler way first :)
07:33freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
07:34
<vagrantc>
alkisg: http://www.syslinux.org/wiki/index.php/Cmd.c32
07:34
that looks really useful
07:34
<alkisg>
moment, phone...
07:34* vagrantc is so tired of cutting and pasting append lines
07:43
<alkisg>
Back. OK, so my main new ideas here are "don't use configuration files as an intermediate step, just let the user edit pxelinux.cfg/default", and "expect one or more standard symlinks to avoid the need to update pxelinux.cfg/default, and to help users that use pxelinux.cfg/01-mac-address files"
07:43
Do those sound like good motivation for implementing a few changes?
07:43
We already have a vmlinuz symlink, we just don't demand it and we don't use it in pxelinux.cfg/default...
07:44
It's not actually necessary to standarize the -32, -64, -pae labels, those could be optionally implemented per distro, and a wiki page would instruct the user on how to use ifcpu64 etc
07:44
<vagrantc>
also, i'd like to get back to where ltsp-update-kernels could just create symlinks
07:45
alkisg: but it'd be a lot simpler to standardize on those labels
07:45
and they're essentially what ifcpu64 supports.
07:45
and then there's things like arm boards starding to support pxe ...
07:46
but they don't really use pxelinux, as far as i can tell, just parse the configuration file format.
07:46
alkisg: so, the thing i'm wondering about pxelinux.cfg/default that we generate once is... what happens when we want to change the default parameters?
07:47
<alkisg>
vagrantc: standard symlinks would help even if the kernel is loaded locally, e.g. we could add a grub.d entry to add the local ltsp kernel...
07:47
<vagrantc>
as ltsp upstream
07:48alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
07:49
<vagrantc>
alkisg: or we just generate it once, and then let the user update their pxelinux.cfg manually?
07:49
<alkisg>
"what happens when we want to change the default parameters?" => in a package upgrade?
07:49
Yup, that's the idea, we only generate it if it doesn't exist
07:49
<vagrantc>
alkisg: yeah, like when we switched to requiring init=/sbin/init-ltsp
07:49
alkisg: or was it init=/sbin/ltsp-init ?
07:49
<alkisg>
init-ltsp
07:49
<vagrantc>
alkisg: or was it simply putting ltsp on the commandline?
07:49
in the span of a couple months, we changed that several times
07:50
<alkisg>
For example, if tftpd supported symlinks to /etc, would ship pxelinux.cfg/default as a conffile and put a symlink in tftp
07:50
...we could actually do that now to, and copy it to tftp
07:50
<vagrantc>
alkisg: dnsmasq tftp supports that, but tftpd-hpa doesn't. atftpd does, although it may require configuration. regular tftpd, not sure.
07:50
<alkisg>
/etc/ltsp/pxelinux-default
07:51
And have update-kernels copy it to tftp if it doesn't exist
07:51
And it can be distro specific, as the kernel parameters are distro specific
07:51
<vagrantc>
so, here we get back to the server-side or client-side? botth can have requirements about what sane values are...
07:52
<alkisg>
Client side, it would be a conffile of ltsp-client-core
07:52
If one wants an nbd ubuntu chroot on a debian nfs server, he'd have to edit it manually
07:53
<vagrantc>
does ubuntu still use -generic for kernel on amd64?
07:53
<alkisg>
Yup
07:54
<vagrantc>
so you can install both an i386 32-bit kernel and amd64 64-bit kernel in the same environment...
07:54
can't
07:54* alkisg hasn't tried that
07:55
<vagrantc>
it's not possible if they have filename conflicts...
07:55
works fine on debian.
07:55
but that's not a huge issue, really.
07:56
<alkisg>
The default in i386 after 12.04 is -pae, but it doesn't have a pae name, it's named -generic
07:56
Because there's no non-pae kernel available
07:57
<vagrantc>
alkisg: so, what's now the update-kernels hook would merely become a symlink generator ... in /boot/ of the client chroot ? and ltsp-update-kernels would actually copy files from both the <chroot>/boot/ and <chroot>/etc/ltsp/pxelinux* ?
07:57
<alkisg>
vagrantc: do you still want the files in /boot?
07:57
<vagrantc>
to <tftpdirs>/ltsp/<chroot>/pxelinux ?
07:58
alkisg: well, that's where my distro puts kernels, it would be an ordeal to move them elsewhere... ?
07:58
<alkisg>
Why not just leave the /etc/ltsp/pxelinux conffile in the chroot?
07:58
<vagrantc>
alkisg: ah, yes, that's what i was saying
07:58
<alkisg>
No I meant that update-kernels would do nothing wrt pxelinux.cfg
07:58
<vagrantc>
yes.
07:58
<alkisg>
And ltsp-update-kernels would copy from CHROOT/etc
07:58
<vagrantc>
yes.
07:59
<alkisg>
Cool. That's pretty simple, and I prefer it from autodetection, supporting a whole lot of features, but with a big complexity
07:59
Now, the chroot conffile doesn't have to be a pxelinux.cfg file
07:59
It can just list the default kernel parameters
08:00
ltsp-update-kernels can use them to generate pxelinux.cfg/default files on the server, only if they don't exist
08:00
<vagrantc>
alkisg: although i'd really like the ability to have a list of versioned kernels and a menu of NFS, NBD, NFS_LOOP_IMG ... etc
08:01
<alkisg>
I don't think the complexity involved is worth the trouble.. we can't expect all distros to have the "appetite" to implement that
08:01
<vagrantc>
fair enough.
08:01
<alkisg>
You can do that from a hook in ltsp-update-kernels, locally on your pc
08:02
<vagrantc>
if ltsp-update-kernels had run-parts or plugin dirs ...
08:02
then i could do whatever crazy i wanted :)
08:03
alkisg: so, with dnsmasq, we could actually put /opt/ltsp into the tftp dir, and not bother copying the contents of boot out of the chroot into $tftp
08:03
<alkisg>
ltsp-update-image now would only copy the default file if it doesn't exist, so you can wrap it with a /usr/local/bin/ltsp-update-image launcher and do whatever you want afterwards
08:03
<vagrantc>
er, rather point dnsmasq's tftp to /opt/ltsp
08:04
<alkisg>
vagrantc: that wouldn't work in ubuntu, vmlinuz is readable only by root
08:04
<vagrantc>
ltsp-update-kernels ?
08:04
<alkisg>
To chmod +r it from update-kernels?
08:04
<vagrantc>
alkisg: it's currently chmod +r as part of update-kernels...
08:04
alkisg: ltsp-update-image, or ltsp-update-kernels ?
08:04
<alkisg>
The copy, not the original kernel... right?
08:05
<vagrantc>
alkisg: i think currently it just makes itt readable, but i don't really remember
08:05
which is about the stupidest security measure i've ever heard of.
08:05
<alkisg>
Also since we've started using loopback images (ltsp-pnp, VMs), having a kernel copy sound fine
08:05
(kernel copy in tftpboot/)
08:06
<vagrantc>
alkisg: but it's silly when you're not doing that
08:06
but for simplicity... always do the same thing
08:06
<alkisg>
Right, not worth saving a few MB disk space
08:06
<vagrantc>
alkisg: so we'd copy whatever the symlinks are poinging to do un-symlinked files?
08:07
alkisg: it's more the forgetting to run ltsp-update-kernels that i'm worried about than disk space... lost troubleshooting time
08:07
<alkisg>
cp copies the target, not the symlink, right?
08:07
<vagrantc>
depends on how you call it
08:08
<alkisg>
So after all that nice chat, revised idea:
08:08
The conffile I was talking about before, is our current /etc/ltsp/update-kernels.conf file, it'll just need a lot less variables there
08:08
ltsp-client-core ships that, but never uses it
08:09
And ltsp-update-image reads it and generates tftp/pxelinux.cfg/default only if it doesn't exist
08:09
<vagrantc>
ltsp-update-kernels?
08:09
<alkisg>
yes, sorry
08:09
And the update-kernels hook takes care of the symlinks
08:09
(versioning etc etc)
08:10
And that way we don't haved to clean up older kernels in tftp
08:10
<vagrantc>
what copies files to tftpboot?
08:10
<alkisg>
As we're just overwriting vmlinuz with the latest version pointed by the symlink
08:10
ltsp-update-kernels
08:10
<vagrantc>
yeah, that's what i was getting at.
08:11
(or vmlinux)
08:11
<alkisg>
So we don't have symlinks in the tftp, we have actual files copied by symlink targets in the chroot :)
08:11
<vagrantc>
right
08:11
<alkisg>
Sound pretty simple and easy to implement...
08:12
<vagrantc>
which simplifies house-cleaning
08:12
alkisg: but i don't really like leaving the user on their own to do manual updates
08:12
alkisg: so we should have "ltsp-config pxe --overwrite"
08:13
which updates it based on the current chroot(s)
08:13
<alkisg>
Nice. One other idea is this:
08:13
<vagrantc>
(or images, etc)
08:13
<alkisg>
every time ltsp-update-kernels runs, it stores somewhere the md5sum of chroot/etc/our conf file and the md5sum of the pxelinux.cfg/default file it generated
08:14
On the next run, if the conf file changed, but pxelinux.cfg/default didn't, then it can update it without prompting the user
08:14
<vagrantc>
yes, that occurred to me also
08:14
dpkg conffile handling :)
08:14
<alkisg>
I.e. what conffiles in /etc usually do... but I don't think that's worth the overhead either
08:14
ltsp-config pxe --overwrite is a lot more simple :D
08:14
Or, ltsp-update-kernels --overwrite
08:15
<vagrantc>
i like the "ltsp-config" as a one-stop configuration interface
08:15
though "ltsp-update-kernels --overwrite" maybe could call ltsp-config ...
08:15
<alkisg>
ltsp-update-kernels needs to loop-mount the /opt/ltsp/images/ltsp-pnp-i386.img image in order to see the chroot /etc, /boot
08:16
And since it already copies files there... I think it should also do the pxelinux.cfg file generation
08:16
<vagrantc>
hmmm.
08:16gbaman has joined IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com)
08:17* vagrantc doesn't even mention yaboot
08:17
<vagrantc>
oops, i did.
08:17
it's pretty much the same, though, really.
08:18
alkisg: you're also talking about generating a single pxelinux.cfg/default per server, as opposed to one per chroot/image ?
08:19
<alkisg>
With standard kernel names etc, it should be easier to do now...
08:20
<vagrantc>
alkisg: i still think we should leave it under $tftpdir/ltsp/pxelinux*
08:20
<alkisg>
Yup, I'm proposing that too. A single tftpboot/pxelinux.cfg/ltsp file, with a pxelinux.cfg/default that includes ltsp
08:20
Why?
08:21gbaman has left IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com, Ping timeout: 248 seconds)
08:21
<alkisg>
When a new chroot is added, the user would have to run ltsp-update-image --overwrite, to generate a new file that includes that chroot
08:22
The pxelinux.cfg/default file wouldn't be touched, to allow for user defined menus, defaults, whatever
08:22
(when I say ltsp-update-image, I always mean -kernels, sorry :D)
08:23
I.e. pxelinux.cfg/ltsp is only overwritten with ltsp-update-kernels --ovewrite, and pxelinux.cfg/default is only created if it doesn't exist, as it only has one INCLUDE line etc
08:23
<vagrantc>
alkisg: what about always generating the pxelinux.cfg/ltsp-autogenerated, and only overwriting pxelinux.cfg/default with it if not present?
08:23
that would make it relatively clear what updates to apply manually, if they needed to.
08:24
alkisg: ah, include could work to.
08:25
alkisg: so, how would ltsp-update-kernels update the pxelinux* files if you have multiple images and multiple chroots? would it iterate through them all, build a list, and generate the end result?
08:26
<alkisg>
So if the user wants to completely avoid pxelinux.cfg/ltsp, he could modify pxelinux.cfg/default as he pleases, using the standarized symlinks etc. We'd never touch that file.
08:26
<vagrantc>
sure.
08:26
could even leave comments to that effect
08:27
<alkisg>
Yes, it would iterate between all the images, chroots etc
08:27
<vagrantc>
but i think it would be *good* to always generate what would be generated by --overwrite, and sit it right next to the manually editable file...
08:28
which makes it easy to always use the autogenerated stuff
08:28
<alkisg>
vagrantc: OK, so: we document that pxelinux.cfg/ltsp is always regenerated, and if one wants to edit it, he should copy its contents to pxelinux.cfg/default, and remove the INCLUDE line
08:28* vagrantc nods
08:29
<vagrantc>
i think that would be the best of both
08:29
<alkisg>
There's no sense in a ltsp-update-kernels --overwrite parameter in that way
08:29
<vagrantc>
exactly
08:29
<alkisg>
Nice and simple, I like it
08:29
<vagrantc>
and then they'd have a proper example to refer to if they ever broke their config
08:29
<alkisg>
They could diff between them, right
08:30
<vagrantc>
we could even mark the autogenerated one as read-only
08:30
<alkisg>
Would it make sense to have the pxelinux.cfg/default shipped by ltsp-server in /etc/ltsp ?
08:31
And ltsp-update-kernels to blindly copy it to tftp each time?
08:31
(with an INCLUDE directive in it)
08:31
<vagrantc>
i'm not sure i follow ...
08:31
<alkisg>
Up to now, we were saying that ltsp-update-kernels generates /default
08:31
<vagrantc>
how would it support multiple arbitrary chroots?
08:32
<alkisg>
But /default has static content, just a few doc lines and an INCLUDE
08:32
The arbitrary chroots etc are in /ltsp
08:32
<vagrantc>
ah.
08:32
<alkisg>
And we're saying that the user would modify /default, if he ever needed to
08:32
<vagrantc>
i think it still has the problem of not understanding when it got overwritten
08:33
<alkisg>
ltsp-update-kernels can add a header in /default that it was copied from /etc and it will be overwritten and instruct people to do any changes in /etc..
08:33
The benefit would be that people wouldn't ever need to go to tftpboot
08:33
(we'll move lts.conf out of there in the future too)
08:34
<vagrantc>
and could also be marked read-only
08:34
<alkisg>
(and we might have 01-mac-address files autogenerated by ltsp configuration + ltsp-update-kernels in the future)
08:34
<vagrantc>
(and ltsp-update-kernels would have to un-mark it's read-only bits)
08:35
alkisg: i don't know why exactly, but since this stuff is getting generated by ltsp tools, i think it should live in $tftpdir/ltsp/
08:36
alkisg: for example, i have existing LTSP servers that use $tftpdir/pxelinux.cfg/ that have complicated configuration files that would get overwritten
08:37* alkisg takes 5' for a cigarette and to thing about what vagrantc new, valid point...
08:37
<alkisg>
*tr -d 'what'
08:37
<vagrantc>
that might get overwritten ...
08:37mikkel has joined IRC (mikkel!~mikkel@80-199-146-42-static.dk.customer.tdc.net)
08:37
<vagrantc>
though technically, someone may have used $tftpdir/ltsp/pxelinux.cfg/default too...
08:38
but i feel more comfortable "taking that over".
08:38
<alkisg>
vagrantc: you're right, so I discard my latest suggestion and move back to the exactly previous one
08:38
I.e. generate tftpboot/pxelinux.cfg/default only if it doesn't exist, with a single include line
08:39
People with weird pxelinux.cfg/defaults then would put whatever they want, and would have to remember the ltsp include line
08:39
<vagrantc>
and autogenerate pxelinux.cfg/ltsp ?
08:40
with both documentation, comments and read-only safeguards?
08:41
<alkisg>
To sum up:
08:41* vagrantc had fun with the last rewrite of all this stuff
08:42
<alkisg>
pxelinux.cfg/default: generated only if it exists, contains a single include line to ltsp, and documents that sysadmins can edit it however they like
08:42
pxelinux.cfg/ltsp: always regenerated, and documents that people should *copy* it to ltsp-local and modify /default accordingly, if they need static content
08:42
Done... :)
08:43
<vagrantc>
ltsp-local ?
08:43
<alkisg>
in the sense of /usr/share/local
08:43
<vagrantc>
ah, rather than merging it into /default ?
08:44
could just append it to /default and do away with the include?
08:44
<alkisg>
I.e. a local static copy of ltsp, that the sysadmin prefers over /ltsp, and can diff it if he needs to, etc
08:44
Sure
08:44
Better :)
09:03bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 248 seconds)
09:04bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
09:11alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 248 seconds)
09:12vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
09:25gbaman has joined IRC (gbaman!~gbaman@host86-171-227-31.range86-171.btcentralplus.com)
09:42alkisg is now known as work_alkisg
09:52alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
10:04GrembleBean has joined IRC (GrembleBean!~Ben@bmex-gw.bristolwireless.net)
10:27gbaman has left IRC (gbaman!~gbaman@host86-171-227-31.range86-171.btcentralplus.com, Remote host closed the connection)
10:43freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
11:02khildin has joined IRC (khildin!~khildin@ip-213-49-87-35.dsl.scarlet.be)
11:08workingcats has joined IRC (workingcats!~workingca@212.122.48.77)
11:33vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi)
11:39Fenuks has left IRC (Fenuks!~Fenuks@109.202.25.212, Ping timeout: 245 seconds)
11:56epoptes_user5 has joined IRC (epoptes_user5!517df50d@gateway/web/freenode/ip.81.125.245.13)
12:23slackish has left IRC (slackish!amcphall@mcphall.org, Ping timeout: 240 seconds)
12:30slackish has joined IRC (slackish!amcphall@mcphall.org)
12:44alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out)
12:47alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
13:23brunolambert has joined IRC (brunolambert!brunolambe@nat/revolutionlinux/x-trysvbaruwwwzwtf)
13:29willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
13:35willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Textual IRC Client: http://www.textualapp.com/)
13:36khildin has left IRC (khildin!~khildin@ip-213-49-87-35.dsl.scarlet.be, Quit: I'm gone, bye bye)
14:01bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
14:37Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
14:54cliebow has joined IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us)
14:54alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
15:07bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Quit: Goin' down hard)
15:14lifeboy has joined IRC (lifeboy!~roland@105-236-171-186.access.mtnbusiness.co.za)
15:15
<lifeboy>
Hi all
15:16mikkel has left IRC (mikkel!~mikkel@80-199-146-42-static.dk.customer.tdc.net, Quit: Leaving)
15:18
<lifeboy>
Still not quite there yet after the "crash" of my Ubuntu 10.04 client with the 12.04 server... After booting I get dropped in busybox with the message "Failed to connect to nbd server"
15:19
However, when I then enter "nbd-client 172.16.0.1 2002 /dev/nbd0" I get connected??
15:21
Anyone have an idea of what's going wrong? The client chroot is like is was, except for the updates I did to udhcpc and busybox. Could that cause this?
15:22mmetzger has joined IRC (mmetzger!~mmetzger@99-71-214-107.lightspeed.mdldtx.sbcglobal.net)
15:38
<Hyperbyte>
lifeboy, hiiiiiiii
15:39* lifeboy waves at Hyperbyte
15:40
<lifeboy>
and I found the culprit...
15:42
in pxelinux.cfg/default there is a "nbdroot=ltsp_i386" parameter that get added to the "append ro initrd=initrd.img" line.
15:42
removing that, let's the client boot
15:43
eh... lets the client boot :-)
15:43
actually it's: nbdroot=:ltsp_i386
15:45alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
15:48GrembleBean has left IRC (GrembleBean!~Ben@bmex-gw.bristolwireless.net, Quit: I Leave)
15:49
<lifeboy>
Now to figure out how to remove that...
15:52willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
15:55
<lifeboy>
Ah, when I change it to nbdroot=172.16.0.1:2002/ltsp_i386 it boots...
15:55
However, although I have an updated ldm, I still get 'Failed to load session "ubuntu"' when I log in on the client. That's because I have uninstalled unity to get back to gnome-classic
16:02telex has left IRC (telex!~telex@freeshell.de, Remote host closed the connection)
16:02freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
16:04telex has joined IRC (telex!~telex@freeshell.de)
16:04
<lifeboy>
Where does ldm get the window-manager config? ie where can I dig around for this issue?
16:29
Ok, I need to understand something: On an Ubuntu 12.04 server, is the packaged version of LTSP supported or not? I have an issue with ltsp-update-image in ltsp-server 5.3.7-0ubuntu2.6 wrt the option that can be set. sbalneav, stgraber, alkisg, vagrantc, what's the policy or how do I deal with this?
16:37khildin has joined IRC (khildin!~khildin@ip-213-49-87-35.dsl.scarlet.be)
16:40
<lifeboy>
If I manually set options as in: ltsp-update-image -a i386 -o "nbdport=2002" -I "3" -S "172.16.0.1" -p "2002", everything gets set, except for the -p option, which results in "append ro initrd=initrd.img nbdport=2002 nbdroot=172.16.0.1:ltsp_i386" in pxelinux.cfg/default. I'm having trouble figuring out what the client-update-image script does and why it doesn't work...
16:54vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
16:58Parker955 is now known as Parker955_Away
17:00Parker955_Away is now known as Parker955
17:17khildin has left IRC (khildin!~khildin@ip-213-49-87-35.dsl.scarlet.be, Quit: I'm gone, bye bye)
17:21khildin has joined IRC (khildin!~khildin@ip-213-49-87-35.dsl.scarlet.be)
17:26laprag has joined IRC (laprag!~laprag@ti0071a380-dhcp1620.bb.online.no)
17:29laprag has left IRC (laprag!~laprag@ti0071a380-dhcp1620.bb.online.no, Remote host closed the connection)
17:29laprag has joined IRC (laprag!~laprag@ti0071a380-dhcp1620.bb.online.no)
17:33kev_j has left IRC (kev_j!~Kevin@web.ta-realty.com, Remote host closed the connection)
17:44highvoltage has left IRC (highvoltage!~highvolta@ubuntu/member/highvoltage, Read error: Operation timed out)
18:20lns has left IRC (lns!~lns@pdpc/supporter/professional/lns, Remote host closed the connection)
18:32xet7 has joined IRC (xet7!~xet7@a88-112-147-81.elisa-laajakaista.fi)
18:48freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
18:52lns has joined IRC (lns!~lns@pdpc/supporter/professional/lns)
18:58workingcats has left IRC (workingcats!~workingca@212.122.48.77, Quit: Leaving)
19:06alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
19:10
<alkisg>
lifeboy: the packaged version of ltsp in 12.04 is support by ubuntu, not by ltsp upstream. So only high priority bugs or security issues are usually addressed...
19:11
And, instead of trying to solve all those issues with 12.04 server and 10.04 client, let me repeat that it would be waaay easier to use 12.04 + greek ppa packages, with wheezy client
19:14willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Textual IRC Client: http://www.textualapp.com/)
19:16
<lifeboy>
Alkisg, the Ubuntu support makes sense, yes. What are the greek ppa packages? I had a wheezy client, but there were too many different issues (although I can't remember them now). I'm quite prepared to have a go at it again... at least I understand the different aspects somewhat better by now!
19:17
<alkisg>
lifeboy: see the IRC logs of the last time we talked months ago, when I suggested the same route :)
19:17
!greek-ppa
19:17
<ltsp>
Error: "greek-ppa" is not a valid command.
19:17
<lifeboy>
Yes, I remember that well :-)
19:18
<alkisg>
!greek-schools-ppa
19:18
<ltsp>
greek-schools-ppa: https://launchpad.net/~ts.sch.gr/+archive/ppa/ supports LTS Ubuntu releases with newer LTSP versions, bug fixes etc
19:18
<lifeboy>
Ah!
19:18
<alkisg>
The version of ltsp there matches the version in wheezy
19:18
So you won't have any issues with nbd configuration etc
19:19
<lifeboy>
Ok, I'll set up a test system and play with it, since I have the 10.04 clients booting now and don't want to break them again!
19:20
<alkisg>
Install Ubuntu desktop in VM1. Add the greek schools ppa. Install a wheezy desktop in VM2. Create a wheezy chroot. Transfer it to your ubuntu VM1. That's about it.
19:20
*forgot a step, install ltsp in ubuntu after adding the greek schools ppa, not before
19:53gbaman has joined IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com)
20:08
<lifeboy>
alkisg, thanks, will do and hopefully this time round I'll get it right! :-)
20:09
Didn't have the greek schools ppa before. It will probably make the difference between failure and success.
20:10
<vagrantc>
alkisg: so, back to ltsp-update-kernels ...
20:11
alkisg: i still think we should copy over all kernel versions...
20:11
<alkisg>
vagrantc: why the mess?
20:11
<vagrantc>
alkisg: i don't see any other way to support arbitrary kernels, and some architectures nearly require a different kernel for each board
20:11
alkisg: also, how will we distinguish between vmlinuz-32 in two different chroots?
20:12
<alkisg>
vagrantc: the kernels and symlinks go in /ltsp/arch, so both of them would be there
20:12
<vagrantc>
alkisg: and while the pxelinux support isn't there, you need to have the kernel files, or other arbitrary files, copied into the tftp dir.
20:12* alkisg tries to catch up... :D
20:13
<vagrantc>
alkisg: also, how to support an image and chroot with the same name, but not necessarily the same... while i'm in detail-oriented mode.
20:13
i guess the answer to that is: we don't
20:14
<alkisg>
About image and chroot, we prefer the image (already) afaik
20:14
<vagrantc>
but i remember having lots of confusion with ltsp-update-kernels either pulling from the chroot or the image file, and it being confusing
20:14
<alkisg>
About the 2 different chroots, I don't see any issues, it'll be e.g. tftp/ltsp/i386/vmlinuz and tftp/ltsp/amd64/vmlinuz
20:14
<vagrantc>
alkisg: i think the image files should have their own tftp space
20:14
<alkisg>
I agree with that
20:15
Ah sorry
20:15
<vagrantc>
alkisg: i.e. $tftp/ltsp/i386 and $tftp/ltsp/i386.img, maybe?
20:16
<alkisg>
And insert an entry to boot the first with nfs and the second one with nbd?
20:16
<vagrantc>
alkisg: but arm and other architectures often require files other than vmlinuz, vmlinux, or even pretty much arbitrary names
20:16
<alkisg>
Example?
20:16
<vagrantc>
uImage, uInitrd ... there was even some bizarre thing that require some arbitrary filename
20:17
<alkisg>
And the respective pxelinux.cfg command line is?
20:17
kernel uImage ?
20:17
<vagrantc>
alkisg: i think the simplicity of simply copying what lands in /boot is easier than trying to maintain an arbitrary number of compatibility lines
20:17
alkisg: there isn't necesarily pxelinux support, but they still can tftp boot
20:17
alkisg: how about this ...
20:18
alkisg: copy <arch>/boot to $tftp/ltsp/<arch>/boot/ and wipe it out every time.
20:19
alkisg: and then $tftp/ltsp/<arch>/pxelinux* can reference boot/
20:19
alkisg: recent versions of arm also require a dtb file in addition to kernel files, and those should be available via tftp
20:20
(although unfortunately those aren't always in /boot)
20:20
but they should be..
20:20
<alkisg>
vagrantc: so, a use case that happens a lot here
20:20
Client with mac-address needs nomodeset
20:21
So the sysadmin creates pxelinux.cfg/01-mac-address with: kernel vmlinuz
20:21
How would he do that, without us providing symlinks?
20:21
<vagrantc>
alkisg: we can still provide the symlinks, but still copy the whole of boot
20:22
alkisg: we can put the symlinks in $tftp/ltsp/<arch>/vmlinu*, which refer to files in $tftp/ltsp/<arch>/boot/
20:22
<alkisg>
Symlinks would be done by update-kernels in the chroot, right?
20:23
Because they're distro and arch specific...
20:23
<vagrantc>
true true, so pxelinux.cfg would have to point to boot/vmlinuz, then.
20:23
this is, of course, assuming that /boot is even distro-agnostic...
20:24
<alkisg>
Basically tftp/ltsp/<arch>/boot is our current tftp/ltsp/<arch>, minus lts.conf, and plus the symlinks?
20:24
<vagrantc>
alkisg: pretty much ...
20:25
<alkisg>
Can you give me an example of how some weird arm board boots?
20:25
(e.g. a web link to read...)
20:29
Suppose we have an arm client with a kernel name of uImage-3.2.bin
20:29
Then it gets updated to uImage-3.3.bin
20:29
How will the client be informed about the name change? Via some script, or by the user manually editing files?
20:29
<vagrantc>
alkisg: i guess, i'm not worried about out-of-the box support, i just want all the files to be available that are present in boot
20:30
<alkisg>
If the user needs to update a file manually, it'll be easier for him to do the copy with the standard target name, rather than file editing
20:31
If a script does that, then the script can create the symlink
20:31
<vagrantc>
but we cannot predict the multitude of possible naming schemes required
20:31
<alkisg>
We can copy all the targets of all the symlinks inside /boot...
20:34laprag has left IRC (laprag!~laprag@ti0071a380-dhcp1620.bb.online.no, Remote host closed the connection)
20:34
<alkisg>
I don't like deleting things that we didn't create
20:35
Some times a specific client boots with kernel .38 but not with .39 and up
20:35
I copy that kernel to have it after the kernel upgrade + purging of the previous versions
20:36laprag has joined IRC (laprag!~laprag@ti0071a380-dhcp1620.bb.online.no)
20:37laprag has left IRC (laprag!~laprag@ti0071a380-dhcp1620.bb.online.no, Client Quit)
20:37
<vagrantc>
alkisg: so copy it to $tftp/ltsp/<arch>/ rather than $tftp/ltsp/<arch>/boot/
20:38
<alkisg>
True...
20:38
<vagrantc>
and adjust your pxelinux configurations accordingly
20:39
alkisg: the basic idea is to have stuff that our scripts can overwrite blindly, without reservation, but still allow the user to override what they want to override.
20:39
<alkisg>
Btw ltsp-update-kernels could also store the list of files it copied from the chroot the last time it ran, so that it knows what to delete the next time
20:39
<gbaman>
After all that plaguing for help (mainly from vagrantc and alkisg), have now got something to show for my work with LTSP and the Raspberry Pi :)
20:39
https://github.com/gbaman/RaspberryPi-LTSP
20:40
<vagrantc>
alkisg: that seems overly complicated, just purge everything and recopy :)
20:40
<alkisg>
vagrantc: OK, you convinced me :)
20:41
<vagrantc>
alkisg: i.e. pxelinux.cfg/ltsp and boot should just be blindly overwritten every time.
20:42* alkisg tries to sum all these up in his brain...
20:44
<alkisg>
vagrantc: suppose we commit all this after ltspd is implemented, so no lts.conf in /ltsp/<arch>
20:44
What else is there under /ltsp/<arch>? Do we even need a /boot subdir, or can we use <arch> instead?
20:45
pxelinux.cfg files won't be there anymore
20:45cliebow has left IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us, Quit: Ex-Chat)
20:45
<vagrantc>
alkisg: oh, if $tftp/ltsp/ is where we're writing things, yeah, we probably don't need the subdir.
20:46
<alkisg>
The symlinks would be created in $CHROOT/boot, right?
20:46
Not in some subdir there..., correct?
20:46
<vagrantc>
they could be, yes.
20:48
<alkisg>
Again, suppose that a client needs nomodeset
20:48
For a debian chroot it would need a different command line than for an ubuntu chroot
20:49
...can we do that with a single tftp/pxelinux.cfg/01-mac-address file?
20:49
<vagrantc>
boot either ?
20:49
<alkisg>
I.e. do we miss anything by moving pxelinux.cfg from the <arch> subdir to the top tftp dir?
20:49vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 264 seconds)
20:50
<vagrantc>
only if we make it impossible for the user to fix it.
20:50mattcen has left IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au, Ping timeout: 245 seconds)
20:51mattcen has joined IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au)
20:52
<vagrantc>
gbaman: the licensing of your boot.img is questionable :)
20:54
<gbaman>
Perhaps, but is anyone going to complain?
20:54
is a rather pain to do it any other way
20:54
<alkisg>
vagrantc: I think I'm OK with all parts that we talked about
20:54
<gbaman>
means downloading an entire pi image
20:54
<vagrantc>
gbaman: you could probably trim that images down a lot smaller, too.
20:55
alkisg: i think i am too :)
20:55
<gbaman>
along what lines vagrantc?
21:01khildin has left IRC (khildin!~khildin@ip-213-49-87-35.dsl.scarlet.be, Quit: I'm gone, bye bye)
21:09lns has left IRC (lns!~lns@pdpc/supporter/professional/lns, Quit: Leaving)
21:26
<alkisg>
!learn raspberrypi as https://github.com/gbaman/RaspberryPi-LTSP
21:26
<ltsp>
The operation succeeded.
21:26
<gbaman>
?
21:27
<vagrantc>
people ask about it all the time
21:29
<gbaman>
wonders if LTSP just learnt my script... :)
21:31
Is still wondering what that meant, Looks at alkisg and vagrantc
21:32
<vagrantc>
we could probably actually merge some of that into ltsp, actually.
21:32
!raspberrypi
21:32
<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
21:32
<alkisg>
!raspberrypi
21:32
<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
21:32
<alkisg>
Hehe :)
21:32
<gbaman>
Ha ha!
21:32
<vagrantc>
gbaman: it's easy for people to reference
21:32
<alkisg>
ltsp is a note-taking bot
21:32
<gbaman>
!raspberrypi
21:32
<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
21:32* gbaman wants a note taking bot now :)
21:33
<gbaman>
LTSP needs a nice GUI btw
21:33
<alkisg>
For what?
21:33
<gbaman>
managing
21:33
<alkisg>
what? settings? users? pcs?
21:34
<gbaman>
YES
21:34
all of that!
21:34
<alkisg>
user management is not an ltsp task :)
21:34
<gbaman>
configuring it though is
21:34
thats why I made a whiptail GUI
21:35
as there is no hope of teachers in schools with Pis being interested in this if they have to learn a pile of complex commands
21:36
<alkisg>
They want to teach programming in pi but they don't want to learn bash? :P
21:36
<vagrantc>
pick your poisons carefully
21:36
<alkisg>
ltsp-config dnsmasq, ltsp-config lts.conf, ltsp-update-image -c /, easy stuff :)
21:36
<gbaman>
ltsp on a pi is rather complicated
21:37
<alkisg>
sudo apt-get install ltsp-pi-chroot then
21:37
Make such a package...
21:37
<gbaman>
I am no expert programmer :(
21:38
<vagrantc>
gbaman: it wouldn't be hard to turn what you did into an add-on to ltsp-server.
21:42
<gbaman>
what I was rather basic
21:43
*did
21:43
had no real error detection
21:43
and is really only designed for a clean debian install
21:44
was also my first real proper bash script :)
21:44
and I still prefer python!
21:45
<vagrantc>
first thing to learn about bash scripting, is you should either use plain sh or a more sophisticated language :)
21:45
<gbaman>
:)
21:45alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
21:46
<gbaman>
well, only way to interact with LTSP is via bash, so would need a lot of Popen
21:46
in python
21:47
<vagrantc>
no, you could write sh scripts instead of bash scripts :P
21:48
<gbaman>
though sh scripts were bash scipts?
21:52
<bennabiy>
sh = old shkool
21:54
<gbaman>
go on?
21:56
<vagrantc>
gbaman: /bin/bash is *mostly* compatible with /bin/sh, but that *mostly* is what gets you into trouble.
21:56
<gbaman>
then why not just bash?
21:57
<vagrantc>
gbaman: if you need features that require /bin/bash, instead of /bin/sh, you should probably use a more capable language.
21:57
at least, that's my philosophy.
21:58
<gbaman>
:)
21:58* bennabiy semi agrees...
21:58
<vagrantc>
bash is a bit bloated for programming, though i use it for an interactive shell.
21:59
that said, ltsp-build-client uses /bin/bash :)
22:00
the crazy argument processing implementation for it actually does require it, but it's the only thing that does.
22:02
use /bin/bash selectively, i guess is what i'm getting at, rather than defaulting to it.
22:02
<gbaman>
*wonders if his script will run with dash instead*
22:03
I do rather like whiptail
22:08gbaman has left IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com, Remote host closed the connection)
22:13alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 264 seconds)
22:17gbaman has joined IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com)
22:23gbaman has left IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com, )
22:33gbaman has joined IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com)
23:03Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.)
23:05gbaman has left IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com, Quit: Mango IRC for iOS and OS X, http://mediaware.sk/mango)
23:22freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
23:24lns has joined IRC (lns!~lns@pdpc/supporter/professional/lns)