00:08 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
00:09 | SeRi has joined IRC (SeRi!~wtf@pdpc/supporter/professional/seri) | |
00:15 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 260 seconds) | |
00:58 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
01:54 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 252 seconds) | |
02:32 | * vagrantc remembers hating dummy ChangeLog files. | |
02:40 | Fenuks has joined IRC (Fenuks!~Fenuks@5.128.82.13) | |
02:45 | SeRi has left IRC (SeRi!~wtf@pdpc/supporter/professional/seri, Remote host closed the connection) | |
02:45 | SeRi has joined IRC (SeRi!~wtf@pdpc/supporter/professional/seri) | |
02:59 | SeRi has left IRC (SeRi!~wtf@pdpc/supporter/professional/seri, Ping timeout: 252 seconds) | |
03:01 | clepto is now known as ChadLepto | |
03:06 | SeRi has joined IRC (SeRi!~wtf@pdpc/supporter/professional/seri) | |
03:15 | sbalneav has left IRC (sbalneav!~sbalneav@mail.legalaid.mb.ca, Quit: WeeChat 0.3.8) | |
03:17 | sbalneav has joined IRC (sbalneav!~sbalneav@50.71.200.173) | |
03:25 | SeRi has left IRC (SeRi!~wtf@pdpc/supporter/professional/seri, Quit: leaving) | |
03:56 | alkisg 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:09 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
05:18 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
05:23 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds) | |
05:54 | monteslu has left IRC (monteslu!~monteslu@ip68-109-175-67.ph.ph.cox.net, Read error: Operation timed out) | |
06:17 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
06:32 | Parker955_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:21 | gbaman 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:23 | clepto has joined IRC (clepto!~chadlepto@c-71-237-229-76.hsd1.or.comcast.net) | |
07:23 | clepto 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:26 | ChadLepto 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:26 | gbaman 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:00 | staffencasa 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:04 | andygraybeal__ 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:08 | staffencasa 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:23 | gbaman 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:27 | gbaman 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:31 | Parker955 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:33 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
09:02 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
09:04 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 272 seconds) | |
09:05 | bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com) | |
09:18 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
09:25 | Fenuks has left IRC (Fenuks!~Fenuks@5.128.82.13, Ping timeout: 240 seconds) | |
09:27 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 252 seconds) | |
09:30 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
09:50 | Fenuks has joined IRC (Fenuks!~Fenuks@5.128.82.13) | |
10:05 | Fenuks has left IRC (Fenuks!~Fenuks@5.128.82.13, Ping timeout: 240 seconds) | |
10:09 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
10:22 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection) | |
10:25 | Fenuks 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:00 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.) | |
11:05 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
11:11 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 252 seconds) | |
11:15 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
11:22 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
11:30 | monteslu has joined IRC (monteslu!~monteslu@ip68-109-175-67.ph.ph.cox.net) | |
11:38 | Fenuks has left IRC (Fenuks!~Fenuks@5.128.82.13, Ping timeout: 246 seconds) | |
12:11 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Remote host closed the connection) | |
12:11 | F-GT has left IRC (F-GT!~phantom@ppp59-167-136-109.static.internode.on.net, Ping timeout: 246 seconds) | |
12:18 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
12:34 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Ping timeout: 240 seconds) | |
12:49 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
12:50 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
12:52 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Client Quit) | |
13:14 | clepto is now known as ChadLepto | |
13:38 | andygraybeal has joined IRC (andygraybeal!~andy@h41.207.213.151.dynamic.ip.windstream.net) | |
14:55 | F-GT has joined IRC (F-GT!~phantom@ppp59-167-136-109.static.internode.on.net) | |
15:02 | stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Quit: reboot) | |
15:10 | stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber) | |
15:13 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 245 seconds) | |
15:18 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection) | |
15:18 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
15:49 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
15:55 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds) | |
15:57 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
16:03 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 272 seconds) | |
16:34 | alexqwesa_ has joined IRC (alexqwesa_!~alex@109.172.12.47) | |
16:35 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 272 seconds) | |
16:52 | khildin has joined IRC (khildin!~khildin@ip-213-49-87-240.dsl.scarlet.be) | |
16:53 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
16:57 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 272 seconds) | |
17:10 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
17:21 | alkisg has joined IRC (alkisg!~alkisg@ppp005054016004.access.hol.gr) | |
17:21 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
18:37 | sbalneav has left IRC (sbalneav!~sbalneav@50.71.200.173, Ping timeout: 240 seconds) | |
18:38 | sbalneav has joined IRC (sbalneav!~sbalneav@50.71.200.173) | |
18:40 | sbalneav has left IRC (sbalneav!~sbalneav@50.71.200.173, Client Quit) | |
18:44 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
18:49 | telex has left IRC (telex!~telex@freeshell.de, Remote host closed the connection) | |
18:52 | telex 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:56 | sbalneav 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:19 | ltsp_ 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:32 | ltsp_ has left IRC (ltsp_!4edf849e@gateway/web/freenode/ip.78.223.132.158, Quit: Page closed) | |
19:33 | ltsp_ 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:40 | ltsp_ 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:02 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
20:02 | adrianorg has left IRC (adrianorg!~adrianorg@187.115.110.41, Ping timeout: 264 seconds) | |
20:03 | adrianorg has joined IRC (adrianorg!~adrianorg@187.113.249.22) | |
20:08 | danishman has joined IRC (danishman!~kvirc@62-243-156-218-static.dk.customer.tdc.net) | |
20:25 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
20:35 | danishman 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:08 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
21:21 | Patina_ has joined IRC (Patina_!~tomas@dhcp-5-103-105-144.seas-nve.net) | |
21:23 | Patina_ has left IRC (Patina_!~tomas@dhcp-5-103-105-144.seas-nve.net, Remote host closed the connection) | |
21:39 | Patina has left IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net, Remote host closed the connection) | |
21:42 | Patina has joined IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net) | |
21:51 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
22:22 | khildin has left IRC (khildin!~khildin@ip-213-49-87-240.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
22:56 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection) | |
23:06 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
23:42 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |