IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 26 November 2013 (all times are UTC)
| 00:01 | telex has left IRC (telex!~telex@freeshell.de, Ping timeout: 272 seconds) | |
| 00:03 | telex has joined IRC (telex!~telex@freeshell.de) | |
| 00:12 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 00:38 | gbit has left IRC (gbit!~chatzilla@unaffiliated/gbit, Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018]) | |
| 00:52 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Computer has gone to sleep.) | |
| 00:58 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 01:11 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
| 01:13 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Client Quit) | |
| 01:19 | lmds_ has left IRC (lmds_!~lmds@tui.pi-et-ro.net, Read error: Connection reset by peer) | |
| 01:53 | xcom has left IRC (xcom!~wtf@pdpc/supporter/professional/seri, Ping timeout: 246 seconds) | |
| 02:00 | xcom has joined IRC (xcom!~wtf@23.30.88.89) | |
| 02:00 | xcom has joined IRC (xcom!~wtf@pdpc/supporter/professional/seri) | |
| 02:14 | gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com) | |
| 02:19 | gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Ping timeout: 264 seconds) | |
| 02:26 | Parker955 is now known as Parker955_Away | |
| 02:27 | Parker955_Away is now known as Parker955 | |
| 03:01 | PhoenixSTF has left IRC (PhoenixSTF!~rudi@78.29.159.239, Quit: Leaving) | |
| 03:30 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
| 04:11 | Fenuks has joined IRC (Fenuks!~Fenuks@109.202.25.212) | |
| 04:17 | gbaman has joined IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com) | |
| 04:17 | Fenuks has left IRC (Fenuks!~Fenuks@109.202.25.212, Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) | |
| 04:18 | Fenuks has joined IRC (Fenuks!~Fenuks@109.202.25.212) | |
| 04:22 | gbaman has left IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com, Ping timeout: 246 seconds) | |
| 04:23 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Computer has gone to sleep.) | |
| 04:48 | alkisg 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:03 | brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-oaheeminmmughjxh, Ping timeout: 245 seconds) | |
| 05:03 | mgariepy has left IRC (mgariepy!mgariepy@ubuntu/member/mgariepy, Ping timeout: 245 seconds) | |
| 05:04 | mgariepy has joined IRC (mgariepy!mgariepy@ubuntu/member/mgariepy) | |
| 05:04 | brunolambert has joined IRC (brunolambert!brunolambe@nat/revolutionlinux/x-hbkbsrajbbiupful) | |
| 05:05 | lns has joined IRC (lns!~lns@pdpc/supporter/professional/lns) | |
| 05:13 | brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-hbkbsrajbbiupful, Read error: Connection reset by peer) | |
| 05:17 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 05:30 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 06:21 | gbaman has joined IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com) | |
| 06:25 | gbaman has left IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com, Ping timeout: 246 seconds) | |
| 06:56 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 252 seconds) | |
| 07:04 | work_alkisg has left IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr, Ping timeout: 272 seconds) | |
| 07:10 | work_alkisg has joined IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr) | |
| 07:11 | work_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:23 | gbaman 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:28 | gbaman 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:33 | freedomrun 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:48 | alexqwesa 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:16 | gbaman 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:21 | gbaman 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:37 | mikkel 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:03 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 248 seconds) | |
| 09:04 | bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com) | |
| 09:11 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 248 seconds) | |
| 09:12 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 09:25 | gbaman has joined IRC (gbaman!~gbaman@host86-171-227-31.range86-171.btcentralplus.com) | |
| 09:42 | alkisg is now known as work_alkisg | |
| 09:52 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 10:04 | GrembleBean has joined IRC (GrembleBean!~Ben@bmex-gw.bristolwireless.net) | |
| 10:27 | gbaman has left IRC (gbaman!~gbaman@host86-171-227-31.range86-171.btcentralplus.com, Remote host closed the connection) | |
| 10:43 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 11:02 | khildin has joined IRC (khildin!~khildin@ip-213-49-87-35.dsl.scarlet.be) | |
| 11:08 | workingcats has joined IRC (workingcats!~workingca@212.122.48.77) | |
| 11:33 | vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi) | |
| 11:39 | Fenuks has left IRC (Fenuks!~Fenuks@109.202.25.212, Ping timeout: 245 seconds) | |
| 11:56 | epoptes_user5 has joined IRC (epoptes_user5!517df50d@gateway/web/freenode/ip.81.125.245.13) | |
| 12:23 | slackish has left IRC (slackish!amcphall@mcphall.org, Ping timeout: 240 seconds) | |
| 12:30 | slackish has joined IRC (slackish!amcphall@mcphall.org) | |
| 12:44 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out) | |
| 12:47 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 13:23 | brunolambert has joined IRC (brunolambert!brunolambe@nat/revolutionlinux/x-trysvbaruwwwzwtf) | |
| 13:29 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
| 13:35 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Textual IRC Client: http://www.textualapp.com/) | |
| 13:36 | khildin has left IRC (khildin!~khildin@ip-213-49-87-35.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 14:01 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
| 14:37 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 14:54 | cliebow has joined IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) | |
| 14:54 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 15:07 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Quit: Goin' down hard) | |
| 15:14 | lifeboy has joined IRC (lifeboy!~roland@105-236-171-186.access.mtnbusiness.co.za) | |
| 15:15 | <lifeboy> Hi all
| |
| 15:16 | mikkel 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:22 | mmetzger 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:45 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 15:48 | GrembleBean has left IRC (GrembleBean!~Ben@bmex-gw.bristolwireless.net, Quit: I Leave) | |
| 15:49 | <lifeboy> Now to figure out how to remove that...
| |
| 15:52 | willianmazzardo 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:02 | telex has left IRC (telex!~telex@freeshell.de, Remote host closed the connection) | |
| 16:02 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 16:04 | telex 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:37 | khildin 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:54 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 16:58 | Parker955 is now known as Parker955_Away | |
| 17:00 | Parker955_Away is now known as Parker955 | |
| 17:17 | khildin has left IRC (khildin!~khildin@ip-213-49-87-35.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 17:21 | khildin has joined IRC (khildin!~khildin@ip-213-49-87-35.dsl.scarlet.be) | |
| 17:26 | laprag has joined IRC (laprag!~laprag@ti0071a380-dhcp1620.bb.online.no) | |
| 17:29 | laprag has left IRC (laprag!~laprag@ti0071a380-dhcp1620.bb.online.no, Remote host closed the connection) | |
| 17:29 | laprag has joined IRC (laprag!~laprag@ti0071a380-dhcp1620.bb.online.no) | |
| 17:33 | kev_j has left IRC (kev_j!~Kevin@web.ta-realty.com, Remote host closed the connection) | |
| 17:44 | highvoltage has left IRC (highvoltage!~highvolta@ubuntu/member/highvoltage, Read error: Operation timed out) | |
| 18:20 | lns has left IRC (lns!~lns@pdpc/supporter/professional/lns, Remote host closed the connection) | |
| 18:32 | xet7 has joined IRC (xet7!~xet7@a88-112-147-81.elisa-laajakaista.fi) | |
| 18:48 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 18:52 | lns has joined IRC (lns!~lns@pdpc/supporter/professional/lns) | |
| 18:58 | workingcats has left IRC (workingcats!~workingca@212.122.48.77, Quit: Leaving) | |
| 19:06 | alkisg 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:14 | willianmazzardo 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:53 | gbaman 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:34 | laprag 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:36 | laprag has joined IRC (laprag!~laprag@ti0071a380-dhcp1620.bb.online.no) | |
| 20:37 | laprag 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:45 | cliebow 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:49 | vmlintu 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:50 | mattcen has left IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au, Ping timeout: 245 seconds) | |
| 20:51 | mattcen 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:01 | khildin has left IRC (khildin!~khildin@ip-213-49-87-35.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 21:09 | lns 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:45 | alkisg 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:08 | gbaman has left IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com, Remote host closed the connection) | |
| 22:13 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 264 seconds) | |
| 22:17 | gbaman has joined IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com) | |
| 22:23 | gbaman has left IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com, ) | |
| 22:33 | gbaman has joined IRC (gbaman!~gbaman@host81-130-56-61.in-addr.btopenworld.com) | |
| 23:03 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.) | |
| 23:05 | gbaman 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:22 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 23:24 | lns has joined IRC (lns!~lns@pdpc/supporter/professional/lns) | |