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


Channel log from 25 December 2013   (all times are UTC)

00:08gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
00:09SeRi has joined IRC (SeRi!~wtf@pdpc/supporter/professional/seri)
00:15gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 260 seconds)
00:58willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
01:54Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 252 seconds)
02:32* vagrantc remembers hating dummy ChangeLog files.
02:40Fenuks has joined IRC (Fenuks!~Fenuks@5.128.82.13)
02:45SeRi has left IRC (SeRi!~wtf@pdpc/supporter/professional/seri, Remote host closed the connection)
02:45SeRi has joined IRC (SeRi!~wtf@pdpc/supporter/professional/seri)
02:59SeRi has left IRC (SeRi!~wtf@pdpc/supporter/professional/seri, Ping timeout: 252 seconds)
03:01clepto is now known as ChadLepto
03:06SeRi has joined IRC (SeRi!~wtf@pdpc/supporter/professional/seri)
03:15sbalneav has left IRC (sbalneav!~sbalneav@mail.legalaid.mb.ca, Quit: WeeChat 0.3.8)
03:17sbalneav has joined IRC (sbalneav!~sbalneav@50.71.200.173)
03:25SeRi has left IRC (SeRi!~wtf@pdpc/supporter/professional/seri, Quit: leaving)
03:56alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
03:57
<alkisg>
http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2512 !!! :)
03:58* alkisg waves to vagrantc
04:00
<alkisg>
Re: r2513, I don't think we can delete everything until (a) we use a master location for pxelinux.cfg/01-mac-address files and lts.conf, and (b) until we notify the users to backup those files...
04:07
Or at least, we could back them up to our new master location for them before deleting them...
04:41* alkisg thinks he would postpone moving lts.conf to a master location until ltspd is implemented, when we'll completely move lts.conf out of tftp...
05:09alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
05:18gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
05:23gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds)
05:54monteslu has left IRC (monteslu!~monteslu@ip68-109-175-67.ph.ph.cox.net, Read error: Operation timed out)
06:17alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
06:32Parker955_Away is now known as Parker955
06:39
<vagrantc>
alkisg: ok, so we copy files into a sub-dir
06:39
and the symlinks should point there, maybe.
06:39
i.e. <tftpdir>/ltsp/<arch>/boot/
06:39
which is a straight copy of <chroot>/boot
06:40
<alkisg>
The symlinks could be in the subdir...
06:40
<vagrantc>
alkisg: i'm not sure the code for stripping off the versioning is reliable, though.
06:40
alkisg: i'm thinking just copy the whole subdir, it's simpler.
06:41
purge and copy it.
06:41
<alkisg>
Sure, the symlinks are already inside /boot, no need to change them
06:42
<vagrantc>
all that would change is instead of copying the files to <tftpdir>/ltsp/<arch>/ we copy them to <tftpdir/ltsp/<arch>/boot/
06:42
<alkisg>
I'm just not sure if we want to have <arch>/boot, or just move everything out of <arch> (lts.conf, pxelinux.cfg etc) and consider <arch>==/boot
06:42
<vagrantc>
which is new, and we can purge that safely.
06:42
that's how i implemented it, but you point out we'd have to at least move lts.conf out of there.
06:42
<alkisg>
The plan is to have <tftpdir>/pxelinux.cfg, or <tftpdir>/ltsp/pxelinux.cfg?
06:43
<vagrantc>
dunno if there's anything else we'd need to worry about...
06:43
alkisg: i want <tftpdir>/ltsp/pxelinux*
06:43
alkisg: that leaves the top-level dir for other things to mess with, if for some reason it's needed. it keeps ltsp only modifying ltsp related files.
06:44
<alkisg>
We wouldn't modify <tftpdir>/pxelinux.cfg/default if it exists anyway, so I'm not sure <tftpdir>/ltsp/pxelinux* is needed...
06:45
Using subdirs might make it more difficult due to changed paths for kernels etc
06:45
(more difficult to maintain a global pxelinux.cfg)
06:45
<vagrantc>
alkisg: what advantage do we gain by putting it in the top-level dir?
06:45
<alkisg>
Simplicity...
06:46
<vagrantc>
i don't think one subdir is any more complex than the top-level subdir.
06:46
<alkisg>
How can one include ltsp in a submenu of his global configuration, without changing the relative kernel paths?
06:46
<vagrantc>
it will still all be relative to <tftpdir>/ltsp/
06:46
ah, i see what you're getting at.
06:46
<alkisg>
E.g. suppose I change my dnsmasq configuration to /pxelinux.0 (which I wouldn't need to do if ltsp did that for me),
06:47
then I can't just INCLUDE ltsp/pxelinux.cfg/default from my main config file
06:47
Because the paths wouldn't work
06:47
<vagrantc>
ok, so including the subfiles does have some simplicity in the top-level dir...
06:48
<alkisg>
And in the dnsmasq configuration itself :)
06:48
<vagrantc>
i don't see any difference in the dnsmasq configuration...
06:48
or dhcpd, or whatever.
06:48
<alkisg>
I'd have to manually update the boot filename if I wanted a global configuration
06:49
And ltsp-config dnsmasq --overwrite would ruin it for me on next releases
06:49
<vagrantc>
i think there's a way to make it relative to the include...
06:49
<alkisg>
What are the benefits of _not_ using a global configuration, since we're not touching pxelinux.cfg/default if it already exists?
06:49
<vagrantc>
i guess that's fair...
06:50
it's one of those gut feelings to put it in a sub-dir...
06:50* vagrantc wonders if any distro's don't use /boot
06:50
<vagrantc>
alkisg: did i win you over on copying the whole of boot to <tftp>/ltsp/<arch>/boot ?
06:51
<alkisg>
I was getting to that... :D So if we're moving the configuration, why not do it the first time the "new" ltsp-update-kernels runs?
06:51
I.e. if we find an lts.conf, move it to /
06:51
<vagrantc>
so that we don't have to have that crazy kernel_cleanup code which is so error-prone.
06:51
<alkisg>
And if /lts.conf already exists, move it to /lts-arch.conf or something
06:52
Then I'm OK with deleting the whole /ltsp/arch dir
06:52
<vagrantc>
alkisg: and where would boot be copied to?
06:52
<alkisg>
/ltsp/arch
06:52
Like they are now...
06:52
<vagrantc>
ok, so check for some files to backup first, then purge it?
06:53
<alkisg>
Yup
06:53
<vagrantc>
so far, only lts.conf, maybe the pxelinux.cfg/*
06:53
<alkisg>
lts.conf and pxelinux.cfg/01-* sound fine to me
06:53
Actually I don't mind if we just do this logic:
06:54
if lts.conf or pxelinux.cfg exist, move the whole dir to /ltsp.backups/arch
06:54
...and let the user manually get them from there
06:54
Whatever you prefer
06:55
<vagrantc>
that sounds good.
06:56
<alkisg>
The new ltsp-update-kernels can also omit copying subdirs from boot, to skip existing pxelinux.cfg/ (or grub/) dirs
06:56
<vagrantc>
should we default to a global lts.conf?
06:57
<alkisg>
Yes, it sounds good enough until ltspd is implemented
06:57
<vagrantc>
alkisg: omitting anything is a lot more complicated than: rm -rf <dir> ; cp -a <boo> <dir>
06:57
<alkisg>
cp * instead of cp -r
06:58
That even takes care of resetting the kernel to readable, I think...
06:58
<vagrantc>
alkisg: i'm not sure i catch the advantage of that?
06:58
<alkisg>
$ du -sh /boot/grub/
06:58
4,6M /boot/grub/
06:58
<vagrantc>
cp -a would preserve permissions, but cp -r i don't think so...
06:58
<alkisg>
Why would I want that in my tftp dir?
06:59
<vagrantc>
you and your ltsp-pnp :P
06:59
<alkisg>
fat clients get grub too...
06:59
It's part of ubuntu-desktop
06:59
And, it would make this issue go away:
06:59
<vagrantc>
ubuntu silliness :P
06:59
<alkisg>
A user has an old chroot that has boot/pxelinux.cfg
07:00
He updates update-kernels.conf etc if we need it, then runs ltsp-update-kernels,
07:00
which detects pxelinux.cfg in tftp and moves it to backup,
07:00
but then, cp -r would copy pxelinux.cfg again, resulting in pxelinux.cfg appearing again, i.e. endless backups
07:00
<vagrantc>
and doesn't re-copy the old one...
07:00
right.
07:02
although 'cp *' would be noisy with subdirs...
07:02
cp $(find -type f -depth 1 ) ?
07:03
<alkisg>
Yup, or something similar
07:05
<vagrantc>
cp $(find $BOOT -maxdepth 1 -type f) $TFTPDIR/ltsp/$ARCH/
07:06
seems overly complicated to me.
07:06
but i guess you've got some stuff to exclude...
07:08
<alkisg>
Excluding subdirs makes it also possible to delete the contents of <tftpdir>/ltsp/<arch>/* without its subdirs, i.e. leaving pxelinux.cfg/ as it is there, and only moving lts.conf to <tftpdir>
07:08
...thus no ltsp.backups dir
07:09
<vagrantc>
cp $(find $BOOT -maxdepth 1 -type f -o -type l) $TFTPDIR/ltsp/$ARCH/
07:09
<alkisg>
Don't forget to quote :)
07:09
<vagrantc>
it's highly functioning pseudocode
07:10
<alkisg>
That way (moving only lts.conf to <tftpdir>) upgrades should be automatic for the "default" case...
07:10
<vagrantc>
if lts.conf already exists there (i.e. multiple chroots)
07:10
??
07:10
<alkisg>
Move it to <tftpdir>/lts.conf-<arch>-XXXX ?
07:10
<vagrantc>
and this makes it more important for lts.conf to only be served via tftp ...
07:11
rather than from NFS...
07:11
<alkisg>
We'll switch to ltspd anyways, don't worry too much about that
07:11
<vagrantc>
so, this kind of begs the question ...
07:11
these are fairly invasive changes for a not-yet-major upgrade
07:12
<alkisg>
True, I'd go with the symlinks only for now, and leave the moving parts for when ltspd is ready
07:12
<vagrantc>
it doesn't seem too hard to maintain backwards-compatibility
07:12
<alkisg>
That way the sysadmin would need to worry about creating a new "lts.conf" once, without all his LDM_* variables, in /etc, in the new format etc etc
07:12
<vagrantc>
ah, leave all the menu generation where it is, and people can manually configure things if they need to.
07:13
but the symlinks make it easier for that manual configuration
07:13* vagrantc sighs
07:13
<alkisg>
Right, and also us not overwriting pxelinux.cfg/default
07:13
<vagrantc>
will have to re-write the cleanup_kernels code to not delete the new symlinks.
07:14
right.
07:14
when i saw all that code, i just wanted to purge the whole thing, though.
07:14
it just seems like a lot of hard-coded values.
07:14
<alkisg>
Don't worry you'll do it in the ltsp6 tree :)
07:15
<vagrantc>
well, i should revert it for ltsp-trunk for the moment.
07:16
but really, those rules for finding out "generic" names ... not sure they're reliable.
07:16
it seems to work for all the kernels i know about on debian and ubuntu.
07:16
at least for wheezy+ and precise+
07:16
no idea what would work for other distros
07:16
<alkisg>
You mean the sed line?
07:17
We could strip KERNEL_PREFIX and KERNEL_SUFFIX instead of using sed
07:17
<vagrantc>
alkisg: that's not enough, we need to strip out the version
07:18
in order to have unversioned symlinks
07:18
it does make use of kernel_prefix and kernel_suffix ...
07:18
.
07:21
<alkisg>
So, kernel_versions() doesn't correcty sort the kernels per variant if the distro doesn't define LIST_KERNELS?
07:21gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
07:22
<vagrantc>
that works fine, it's stripping the version off to know what to call the unversioned symlink...
07:22
i.e. vmlinuz-3.9-56-generic needs to translate to vmlinuz-generic
07:22
but what about vmlinuz-3.12-1-rt-amd64
07:23clepto has joined IRC (clepto!~chadlepto@c-71-237-229-76.hsd1.or.comcast.net)
07:23clepto has joined IRC (clepto!~chadlepto@unaffiliated/chadlepto)
07:23
<vagrantc>
is -rt- part of the version, or part of the featureset/variant?
07:24
<alkisg>
You're right...
07:24
<vagrantc>
i made the assumption that $version ends with *-trunk-, *-N-, *-NN- or *-NNN- (for good measure)
07:24
that's how the sed code works.
07:25
<alkisg>
So then if we require a sed line that matches the version, we don't really need all the KERNEL_PREFIX/SUFFIX things
07:25
<vagrantc>
well, still want those for sorting.
07:25
<alkisg>
We can extract the version numbers and sort them
07:26ChadLepto has left IRC (ChadLepto!~chadlepto@unaffiliated/chadlepto, Ping timeout: 272 seconds)
07:26
<vagrantc>
i basically used the prefix/suffix code to get me a list of versions, and from that produce a list of variants, and then use the kernel prefix/suffix code to give me the most recent version of each variant.
07:26gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 260 seconds)
07:26
<vagrantc>
alkisg: but how do you split the version number from the variant/featureset?
07:26
<alkisg>
In other words, we could ask distros to provide a sed expression that matches kernels and returns (with \(.*\)) the version string
07:27
<vagrantc>
for arbitrary featuresets.
07:27
<alkisg>
We wouldn't need KERNEL_PREFIX/SUFFIX then
07:27* vagrantc doesn't want to have to figure out all of the possible variants, of which new ones are introduced every release cycle, and old ones are removed.
07:28
<vagrantc>
we're literally talking hundreds of variants
07:28
for a given release, let alone tracking them over time.
07:28
<alkisg>
I don't get it. Why isn't just a single sed expression enough?
07:28* vagrantc awaits to see this simple sed expression
07:29
<alkisg>
OK, let me see what line you already used...
07:29
<vagrantc>
http://packages.debian.org/search?keywords=linux-image-3
07:29
<alkisg>
Hmm no that one tries to be distro-agnostic, it does too much... let me get you one for ubuntu first
07:31
<vagrantc>
i tried to keep it as simple as i could, but i know it's distro-specific.
07:31
<alkisg>
echo vmlinuz-3.12.0-7-generic | sed 's/\(vmlinuz-\)\([0-9.-]*\)\(-.*\)/prefix=\1, version=\2, suffix=\3/'
07:31
prefix=vmlinuz-, version=3.12.0-7, suffix=-generic
07:31
I.e. the sed line would take a name as input, and output its 3 components
07:32
Completely distro specific, but that's all we ask from a distro
07:32
...and possibly a way to match with the equivalent initrd :)
07:33
...better include the dash to the version, i.e.:
07:34
echo vmlinuz-3.12.0-7-generic | sed 's/\(vmlinuz-\)\([0-9.-]*\)\(.*\)/prefix=\1, version=\2, suffix=\3/'
07:34
prefix=vmlinuz-, version=3.12.0-7-, suffix=generic
07:34
So then symlink = $prefix$suffix
07:34
<vagrantc>
vmlinuz-3.10-0.bpo.2-rt-686-pae ?
07:34
my code fails with that too, though.
07:35
<alkisg>
$ echo vmlinuz-3.10-0.bpo.2-rt-686-pae | sed 's/\(vmlinuz-\)\([0-9.-]*\)\(.*\)/prefix=\1, version=\2, suffix=\3/'
07:35
prefix=vmlinuz-, version=3.10-0., suffix=bpo.2-rt-686-pae
07:35
Isn't that correct?
07:35
<vagrantc>
but the version is 3.10-0.bpo.2
07:35
rt-686-pae is the suffix
07:35
notably, bpo kernels are *stupidly* done. but meh.
07:36
works with most kernels i've thrown at it so far thouh.
07:36
<alkisg>
Can you describe a way to separate the version without worrying about how to code it?
07:36
E.g. does it always have a single dash?
07:37
<vagrantc>
also fails with vmlinuz-3.2.0-4-686-pae
07:37
<alkisg>
Or, are dots NOT part of the suffix, always?
07:37
<vagrantc>
i don't know that i can describe a universal rule.
07:38
that's why i'm wondering how to accomplish it in even a distro-specific way.
07:38
<alkisg>
"version is up to the second dash"?
07:39
<vagrantc>
vmlinuz-3.12-1-rt-amd64 vmlinuz-3.10-0.bpo.2-rt-686-pae vmlinuz-3.2.0-4-686-pae
07:40
seems to hold true for those three.
07:40
<alkisg>
linux-image-2.6-486
07:40
Not true for that one...
07:40
<vagrantc>
that's a package name, not a vmlinuz.
07:40
<alkisg>
Ah sorry
07:41
<vagrantc>
it's a metapackage that probably pulls in a linux-image-2.6.XX-N-486
07:41
the second dash seems to at least currently hold true for debian.
07:41
<alkisg>
I think it's valid in ubuntu too
07:42
<vagrantc>
if you're just talking about version string, 3.12-1-rt-amd64
07:42
<alkisg>
echo vmlinuz-3.10-0.bpo.2-rt-686-pae | sed 's/\(vmlinuz-\)\([^-]*-[^-]*-\)\(.*\)/prefix=\1, version=\2, suffix=\3/'
07:42
prefix=vmlinuz-, version=3.10-0.bpo.2-, suffix=rt-686-pae
07:43
$ echo vmlinuz-3.12.0-7-generic-pae | sed 's/\(vmlinuz-\)\([^-]*-[^-]*-\)\(.*\)/prefix=\1, version=\2, suffix=\3/'
07:43
prefix=vmlinuz-, version=3.12.0-7-, suffix=generic-pae
07:43
Seems ok so far...
07:44
We could even ask it as a distro specific function instead of in a conffile
07:44
So that we don't restrict them to sed
07:44
<vagrantc>
sed 's/\(vmlinu[xz]-\)\([^-]*-[^-]*-\)\(.*\)/prefix=\1, version=\2, suffix=\3/'
07:44
also handles powerpc :)
07:45
and other oddballs.
07:46
<alkisg>
To reconstruct the initrd, we'd need a variable like INITRD="initrd-$version$suffix"
07:46* alkisg googles for other distro's kernel and initrd names...
07:47
<vagrantc>
$initrdprefix$version$initrdsuffix
07:48
alkisg: we've got several listed in the slightly older version of ltsp-update-kernels
07:49* vagrantc wishes git-bzr handled symlinks
07:50
<vagrantc>
alkisg: see the last commit and all the code i removed for Fedora, Debian and Ubuntu, at least.
07:51
<alkisg>
So, if we want to implement it as functions, we want:
07:51
split_kernel_name() => sets $VERSION and $VARIANT
07:51
construct_initrd_name($VERSION, $VARIANT) => echoes the initrd name
07:52
We put our sed lines there, and let other distros override them
07:52
<vagrantc>
sure.
07:53
i guess the old ltsp-update-image code doesn't give us the three parts...
07:55* vagrantc broke the ltsp-trunk checkout trying to use bzr's "branches" features.
07:55
<alkisg>
I don't see e.g. the gentoo kernel name in the older ltsp-update-image...
07:56* vagrantc neither
07:57
<vagrantc>
i know not many distros use our current "update-kernels" code, not sure about how many re-implement "ltsp-update-image"
07:57
but i'd really like to get it more in sync across distros
07:58* alkisg boots a few VMs to check the kernel names...
07:58
<vagrantc>
livecds?
07:58
<alkisg>
Yeah
08:00staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
08:02
<alkisg>
openSUSE-12.3-GNOME-Live-i686.iso: vmlinux-3.7.10-1.1-default.gz vmlinuz-3.7.10-1.1-default, and vmlinuz/initrd symlinks, but initrd-3.7.10-1.1-default doesn't exist, probably to save space
08:03
...the sed line should work there too
08:04andygraybeal__ has left IRC (andygraybeal__!~andy@h41.207.213.151.dynamic.ip.windstream.net, Remote host closed the connection)
08:05
<alkisg>
Fedora-16-i686-Live-Desktop.iso: vmlinuz-3.1.0-7.fc16.i686. No symlinks. Needs custom sed line.
08:08staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 272 seconds)
08:14
<alkisg>
Well, in the default function, if there's no match with the 2 dashes, we can just return prefix=$name, version=empty, suffix=empty...
08:15
...so then it will work for the simple case and only 1 symlink will be generated
08:16* vagrantc just fixed ltsp-update-kernels to not delete the newly created links
08:16
<vagrantc>
although it can leave dangling symlinks...
08:18
alkisg: so it'll return the most recently versioned kernel, as ... vmlinuz ? vmlinuz-default ?
08:19
<alkisg>
Nah, we can't do it, we can't even match the initrd name then
08:19
We should error out if that function can't match $VERSION and $VARIANT
08:20
And tell the user to request a distro-specific function override
08:20
<vagrantc>
it might be possible that there is no initrd...
08:20
but not being able to check... is a bad assumption.
08:21
<alkisg>
Currently we have: append ro initrd=initrd.img${version:+-"$version"} $CMDLINE_LINUX_DEFAULT $(eval echo '$CMDLINE_'$method)
08:21
<vagrantc>
what about fuzzy matching?
08:21
<alkisg>
...do you think we'll want to put the initrd=init.img also in a variable in case there's no initrd?
08:21
<vagrantc>
probably not worth the efforts... distros should implement functions.
08:22
<alkisg>
Hmmm ok we could do that too,
08:22
if the function that returns the initrd name just returns empty,
08:23
then there's no initrd, and we can omit it in the append line, ...although something's wrong here, ...
08:23
<vagrantc>
then it could just be a missing initrd, or a bug in the distro-specific code.
08:23
we could assume the former, and let distros sort out their own bugs...
08:23gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
08:24
<vagrantc>
hopefully this is moving in a direction that will lead to more distros using it...
08:24
<alkisg>
We'd require the distro to override the function if it wants an empty initrd
08:24
But there's a problem here
08:24
<vagrantc>
yeah, i guess we're pretty dependent on initrd for ltsp in debian/ubuntu, at least for the moment...
08:24
<alkisg>
If we're using functions instead of sed lines, we can't use them from the server side code
08:25* vagrantc nods
08:25
<alkisg>
So sed expressions in update-kernels.conf sound better
08:25
<vagrantc>
what would they generate, though? another configuration file?
08:25
oh, the server-side reads the client-side code?
08:25
conf
08:26
<alkisg>
They'd return VERSION and VARIANT in \1 and \2
08:26
Or, a tab separated output, whatever
08:27gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Read error: Operation timed out)
08:27
<alkisg>
The client side doesn't generate a pxelinux.cfg, the server side does,
08:27
<vagrantc>
and we'd eval the sed output?
08:27
<alkisg>
so yeah, we want to be able to find out the VERSION and VARIANT to create better menus etc
08:28
So after all that, there's no need to create symlinks in the client either, sorry :(
08:28
The server side can do it
08:28
<vagrantc>
:P
08:28* vagrantc passes the baton
08:29
<vagrantc>
i've done my damage
08:29
<alkisg>
Good night, I'll write those up in gobby
08:31
<vagrantc>
ok, really need to use a new branch for this, rather than committing to trunk.
08:31Parker955 is now known as Parker955_Away
08:31
<vagrantc>
i thought i had it good enough, but clearly... meh.
08:31
<alkisg>
Or better yet in the wiki, check for a link in irclogs
08:31
<vagrantc>
wiki? meh.
08:31
<alkisg>
For the distros to read it
08:31
<vagrantc>
ah that.
08:32
probably a post to ltsp-developer, too
08:32
pointing at said wiki
08:32
<alkisg>
Sure, once we finish it :)
08:32
<vagrantc>
finish? we're not going to ask for input? :P
08:33* vagrantc waves
08:33vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
09:02gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
09:04bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 272 seconds)
09:05bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
09:18freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
09:25Fenuks has left IRC (Fenuks!~Fenuks@5.128.82.13, Ping timeout: 240 seconds)
09:27cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 252 seconds)
09:30cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
09:50Fenuks has joined IRC (Fenuks!~Fenuks@5.128.82.13)
10:05Fenuks has left IRC (Fenuks!~Fenuks@5.128.82.13, Ping timeout: 240 seconds)
10:09Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
10:22gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
10:25Fenuks has joined IRC (Fenuks!~Fenuks@5.128.82.13)
10:29
<alkisg>
vagrantc, Phantomas: http://wiki.ltsp.org/wiki/Dev:PXEConfig
10:29
cyberorg: ^
10:29
(btw happy Christmas to anyone that celebrates it...)
11:00Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.)
11:05gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
11:11gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 252 seconds)
11:15alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
11:22gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
11:30monteslu has joined IRC (monteslu!~monteslu@ip68-109-175-67.ph.ph.cox.net)
11:38Fenuks has left IRC (Fenuks!~Fenuks@5.128.82.13, Ping timeout: 246 seconds)
12:11cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Remote host closed the connection)
12:11F-GT has left IRC (F-GT!~phantom@ppp59-167-136-109.static.internode.on.net, Ping timeout: 246 seconds)
12:18cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
12:34freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Ping timeout: 240 seconds)
12:49willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
12:50freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
12:52willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Client Quit)
13:14clepto is now known as ChadLepto
13:38andygraybeal has joined IRC (andygraybeal!~andy@h41.207.213.151.dynamic.ip.windstream.net)
14:55F-GT has joined IRC (F-GT!~phantom@ppp59-167-136-109.static.internode.on.net)
15:02stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Quit: reboot)
15:10stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber)
15:13pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 245 seconds)
15:18gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
15:18pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
15:49gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
15:55gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds)
15:57staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
16:03staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 272 seconds)
16:34alexqwesa_ has joined IRC (alexqwesa_!~alex@109.172.12.47)
16:35alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 272 seconds)
16:52khildin has joined IRC (khildin!~khildin@ip-213-49-87-240.dsl.scarlet.be)
16:53gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
16:57gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 272 seconds)
17:10gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
17:21alkisg has joined IRC (alkisg!~alkisg@ppp005054016004.access.hol.gr)
17:21alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
18:37sbalneav has left IRC (sbalneav!~sbalneav@50.71.200.173, Ping timeout: 240 seconds)
18:38sbalneav has joined IRC (sbalneav!~sbalneav@50.71.200.173)
18:40sbalneav has left IRC (sbalneav!~sbalneav@50.71.200.173, Client Quit)
18:44vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
18:49telex has left IRC (telex!~telex@freeshell.de, Remote host closed the connection)
18:52telex has joined IRC (telex!~telex@freeshell.de)
18:52
<vagrantc>
alkisg: any news? :)
18:52
<alkisg>
vagrantc: Morning! :) http://wiki.ltsp.org/wiki/Dev:PXEConfig
18:52
With those, at least the implementation is really simple
18:53
And we can *omit* shipping /etc/ltsp/update-kernels.conf, and we can also ignore any old existing ones because of the different variable names
18:54
E.g. if this implementation ships with 14.04, the older 12.04 chroots will still be working fine there
18:56sbalneav has joined IRC (sbalneav!~sbalneav@50.71.200.173)
19:03
<vagrantc>
alkisg: it only supports NBD and NFS commandline?
19:03
<alkisg>
vagrantc: no, the idea is the they'd list whatever they support there
19:03
<vagrantc>
so FOO_CMDLINE ?
19:03
<alkisg>
CLICFS_CMDLINE, LOCAL_CMDLINE, whatever
19:03
Yes, and server side, BOOT_METHODS is intersected with those
19:03
<vagrantc>
what about COMMON_CMDLINE ?
19:04
<alkisg>
That's because we used to split it in 2 parts
19:04
I don't think it's worth it to split it in 2 parts
19:04* vagrantc found it nice to only update a single variablle
19:04
<vagrantc>
for common things ... but hrm.
19:04* alkisg found it a bit more complicated :)
19:05
<alkisg>
The wiki page is just a draft, we surely can change whatever we want there
19:06
vagrantc: btw, isn't ip=dhcp the default? Why do we have it there?
19:06
And, if "splash" doesn't bother debian, we could have the same code in debian and ubuntu...
19:07
(splash helps in debian too, if someone installs plymouth - https://wiki.debian.org/plymouth)
19:08
<vagrantc>
alkisg: no top-level pxelinux.cfg ?
19:08* alkisg thought we could postpone that till ltsp6
19:09
<alkisg>
Because of the changes involved in the placement of lts.conf
19:09
<vagrantc>
ok, so this basically moves the configuration file generation server-side.
19:09
<alkisg>
Yes, client side only provides a .conf file, server side does the work
19:09
<vagrantc>
and if the chroot generates it's own configs, that's fine, we ignore them
19:10
<alkisg>
I don't know if that proposal can cover all the weird stuff like nbi image parameters, yaboot, yabba dabba doo etc
19:10
<vagrantc>
yeah, but it's a good starting point.
19:11
you might want to copy pxelinux.0 and yaboot from the chroot
19:11
<alkisg>
I think the implementation should be quite easy
19:11
<vagrantc>
yes, it looks quite elegant
19:12
alkisg: ltsp-update-kernels should read ltsp-update-kernels.conf, not update-kernels.conf?
19:12
<alkisg>
We could copy everything, I don't mind, and change the BOOT_FILES parameter to "RM_FILES"... which should be internal mostly, rarely in the config file
19:12
Both
19:12
ltsp-update-kernels.conf from the server, update-kernels.conf from the chroot
19:13
...and both shouldn't exist by default, at least on debian and ubuntu
19:14* alkisg would also take the opportunity to strip all the non-working code like the nbi.img generation... :)
19:14* vagrantc nods
19:15
<vagrantc>
the BOOT_METHODS will be needed to determine boot order
19:15
<alkisg>
In debian, when you have both nfs and nbd, what order do you prefer?
19:15
<vagrantc>
currently prefers NFS
19:15
menu generates both
19:16
defaulting to NFS
19:16
<alkisg>
If one goes to the trouble of configuring NBD, doesn't that mean he prefers NBD for the default/
19:16
?
19:17* vagrantc things about NFSIMG support
19:17
<vagrantc>
thinks
19:17
alkisg: i guess you could make that case
19:17
<alkisg>
We *will* have some internal initialization of BOOT_METHODS for the boot order, I'm just trying to see if it could be common to a few distros..
19:17
<vagrantc>
sure
19:17
<alkisg>
For Ubuntu, I don't mind, if it sees /etc/exports.d/ltsp it can default to NFS, otherwise to NBD
19:17
So it's purely up to you...
19:18
<vagrantc>
i'm perfectly happy shipping a configuration file
19:18
<alkisg>
The problem I've seen with configuration files is that we change them too often :)
19:19
<vagrantc>
number of times i've said to edit a file to add some value, and people respond with "but the file doesn't exist! is something wrong?!"
19:19ltsp_ has joined IRC (ltsp_!4edf849e@gateway/web/freenode/ip.78.223.132.158)
19:19
<vagrantc>
alkisg: then we need to be less foolish in how much we change them.
19:19
<alkisg>
Sure, we _should_ ship configuration files when > 10% of the users need to edit them
19:20
But I don't think more than 2% of the ubuntu sysadmins will ever need to define BOOT_ORDER...
19:20
*BOOT_METHODS
19:20
<ltsp_>
hello
19:20
<alkisg>
Hello
19:20
<vagrantc>
alkisg: that's where ltsp-config could come in handy
19:20
alkisg: it could generate the configuration file from a template
19:21
<ltsp_>
No response from server, restarting..." Error from LTSP Client <== help me please not speak english
19:21* alkisg wonders what other distros use more... NFS or NBD... or CLICFS?!
19:21* vagrantc doesn't know CLICFS
19:21
<vagrantc>
ltsp_: what language do you prefer?
19:22
<alkisg>
I don't know if I'm writing it right, the opensuse thing
19:22
<ltsp_>
french
19:22
<alkisg>
ltsp_: which linux distribution and version?
19:22
<ltsp_>
xubuntu
19:22
<alkisg>
12.04?
19:22
<ltsp_>
13.10
19:22
<alkisg>
!sshkeys
19:22
<ltsp>
sshkeys: If you changed your LTSP server IP on Ubuntu, your clients will be unable to login. To fix this, you need to run: sudo ltsp-update-sshkeys && sudo ltsp-update-image
19:23
<alkisg>
cyberorg: hey! What are you using by default? NBD, NFS, AOE?
19:24
https://fedorahosted.org/k12linux/wiki/NBDRootConfiguration => By default LTSP on Fedora uses NFS to mount the root filesystem over the network and boot the thin clients.
19:25
http://en.opensuse.org/SDB:KIWI-LTSP_How_it_works => The squashfs image is then served via NBD server and used by client as nbdroot.
19:25
<ltsp_>
no reponse again
19:26
<alkisg>
!SCREEN_02 | echo ltsp_:
19:26
<ltsp>
ltsp_: SCREEN_02: To get a root shell on an Ubuntu thin client: https://help.ubuntu.com/community/UbuntuLTSP/ClientTroubleshooting#Using_a_shell_SCREEN
19:26
<alkisg>
Get a root shell, and there, run: ssh user@server
19:26
Replace "user" with a username that exists on the server. Leave "server" exactly as it is, don't replace it.
19:27
vagrantc: http://wiki.gentoo.org/wiki/LTSP#NFS_and_Xinetd => The chroot environments are shared with NFS.
19:28
So debian, fedora and gentoo default to NFS, while ubuntu and opensuse to NBD
19:28
If we can check for the existance of one of them, we can then use the other one as the default :)
19:30
...or we can just default to BOOT_METHODS="NFS NBD AOE" and then try to autodetect if they're supported. If autodetection fails on some distro, they'd need to specify BOOT_METHODS.
19:32
vagrantc: do debian chroots support nbd by default? I.e. is nbdclient usually preinstalled?
19:32ltsp_ has left IRC (ltsp_!4edf849e@gateway/web/freenode/ip.78.223.132.158, Quit: Page closed)
19:33ltsp_ has joined IRC (ltsp_!~ltsp@pla25-5-78-223-132-158.fbx.proxad.net)
19:33
<ltsp_>
re
19:33
<vagrantc>
alkisg: supports NBD out of the box, as long as the server does and the right commandline arguments are passed
19:34
<alkisg>
OK so I think all the things we're talking about can be exactly the same for debian and ubuntu, except maybe for the "splash" parameter
19:36
<vagrantc>
specifying splash if there's no splash should work fine, right?
19:36
i can test that later
19:37
<alkisg>
I believe so, yeah
19:37
<vagrantc>
alkisg: i think we should re-use CMDLINE_NFS and CMDLINE_LINUX_DEFAULT from the old update-kernels.conf
19:38
<alkisg>
vagrantc: we'll want to allow the distro's INITRD name, we didn't have support for it back then
19:38
E.g. gentoo calls it "initramfsXXX"
19:38
And we hardcoded it to initrd.img
19:38
<vagrantc>
ah.
19:38
<alkisg>
That's why I included the INITRD variable in NFS_CMDLINE ...
19:39
<vagrantc>
but i don't think gentoo used that infrastructure, so it's a non-issue
19:39
<alkisg>
It didn't, but I thought we said we'll try to attract them to use the same code...
19:39
<vagrantc>
yes, but they can use the future code, no?
19:40
<ltsp_>
bye bye
19:40ltsp_ has left IRC (ltsp_!~ltsp@pla25-5-78-223-132-158.fbx.proxad.net, Remote host closed the connection)
19:40
<alkisg>
But if we reuse CMDLINE_NFS and LINUX_DEFAULT, their meaning will change now if we include INITRD inside them
19:40
<vagrantc>
alkisg: why do we need to include initrd there?
19:41
<alkisg>
Hmm good point, we can keep it hardcoded now that we know INITRD_NAME
19:41* alkisg assumes the kernel parameter "initrd=" is the same for all distros...
19:41
<vagrantc>
it's technically a pxelinux parameter
19:41
<alkisg>
I think the kernel uses it too
19:42
But anyway it's the same on gentoo too: append initrd=initramfs-YOURKERNELVERSION root=/dev/nfs nfsroot=YOURSERVERIP:/opt/ltsp/i686 real_init=/sbin/init-ltsp
19:42
They don't have "ro" though
19:42
<vagrantc>
it's probably fine with "ro"
19:42
alkisg: i like thhis direction
19:43* vagrantc needs to take a break
19:43
<alkisg>
:)
19:43
<vagrantc>
should have more time tomorrow
19:43
<alkisg>
vagrantc: suppose I have a 12.04 chroot, with NBD_CMDLINE="blabla plymouth:force-splash", and then I upgrade it to 14.04, and ltsp doesn't ship update-kernels.conf there
19:43
<vagrantc>
maybe later today, too
19:43
<alkisg>
Will update-kernels.conf be removed? will it stay the same?
19:44
If it'll stay the same, I'll get plymouth:force-splash on 14.04, which we don't want...
19:44
Anyways, go to relax, we'll talk later :)
19:44
<vagrantc>
don't follow you ... it doesn't ship update-kernels.conf, so it wouldn't be possible to remove ... ?
19:44
<alkisg>
When a package gets upgraded,
19:44
and the previous version shipped a .conf, and the newer doesn't,
19:44
<vagrantc>
ah, by default, it will leave the old version around
19:44
<alkisg>
...does the .conf file stay?
19:44
Right
19:45
<vagrantc>
unless the packaging marks it as obsoleted
19:45
<alkisg>
So that was one additional reason why I wanted to rename the variables...
19:45
<vagrantc>
but technically, wee should maintain compatibility
19:45
<alkisg>
I don't think we want to obsolete it
19:45
OK go take that break, talk to you later :)
19:45* vagrantc isn't so averse to shipping the .conf files
19:45
<vagrantc>
we can ship updates through upgrades...
19:46* alkisg would prefer shipping as less .conf files as he could, until ltsp 6.5 :D
19:47
<alkisg>
Ouch another 12 messages, /me disables daily commits until those are fixed...
19:49
"we can ship updates through upgrades..." ==> true I forgot about that...
19:56
<vagrantc>
only problem is if they changed, it will prompt them ... but a user upgrading the chroot is a fairly sophisticated user already, so they'd better be able to handle configuration file changes :)
20:02vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
20:02adrianorg has left IRC (adrianorg!~adrianorg@187.115.110.41, Ping timeout: 264 seconds)
20:03adrianorg has joined IRC (adrianorg!~adrianorg@187.113.249.22)
20:08danishman has joined IRC (danishman!~kvirc@62-243-156-218-static.dk.customer.tdc.net)
20:25alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
20:35danishman has left IRC (danishman!~kvirc@62-243-156-218-static.dk.customer.tdc.net, Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
21:08alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
21:21Patina_ has joined IRC (Patina_!~tomas@dhcp-5-103-105-144.seas-nve.net)
21:23Patina_ has left IRC (Patina_!~tomas@dhcp-5-103-105-144.seas-nve.net, Remote host closed the connection)
21:39Patina has left IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net, Remote host closed the connection)
21:42Patina has joined IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net)
21:51alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
22:22khildin has left IRC (khildin!~khildin@ip-213-49-87-240.dsl.scarlet.be, Quit: I'm gone, bye bye)
22:56gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
23:06gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
23:42vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)