|00:08||mistik1_ has joined IRC (mistik1_!mistik1@unaffiliated/mistik1)|
|00:08||mistik1 has left IRC (mistik1!mistik1@unaffiliated/mistik1, Ping timeout: 245 seconds)|
|00:08||mistik1_ is now known as mistik1|
|00:14||risca has joined IRC (firstname.lastname@example.org)|
|00:30||mistik1 has left IRC (mistik1!mistik1@unaffiliated/mistik1, Ping timeout: 240 seconds)|
|00:30||joat has left IRC (email@example.com, Quit: bye)|
|00:32||mistik1 has joined IRC (mistik1!mistik1@unaffiliated/mistik1)|
|00:32||joat has joined IRC (firstname.lastname@example.org)|
|00:40||Lurk3r has joined IRC (Lurk3r!~Lurk3r@d50-98-141-108.bchsia.telus.net)|
|01:28||vagrantc has left IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net, Ping timeout: 265 seconds)|
|02:10||irule has left IRC (email@example.com, Ping timeout: 252 seconds)|
|02:12||adrianorg__ has left IRC (firstname.lastname@example.org, Ping timeout: 245 seconds)|
|02:41||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|02:56||Parker955_Away is now known as Parker955|
|04:13||Parker955 is now known as Parker955_Away|
|05:03||monteslu_ has joined IRC (email@example.com)|
|05:06||monteslu__ has left IRC (firstname.lastname@example.org, Ping timeout: 265 seconds)|
|05:20||Lurk3r has left IRC (Lurk3r!~Lurk3r@d50-98-141-108.bchsia.telus.net, Ping timeout: 260 seconds)|
|05:21||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 244 seconds)|
|05:52||irule has joined IRC (email@example.com)|
|06:20||risca has left IRC (firstname.lastname@example.org, Ping timeout: 245 seconds)|
|06:23||risca has joined IRC (email@example.com)|
|06:53||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|07:19||komunista has joined IRC (firstname.lastname@example.org)|
|07:27||loather has left IRC (email@example.com, Quit: This computer has gone to sleep)|
|08:22||monteslu_ has left IRC (firstname.lastname@example.org, Ping timeout: 260 seconds)|
|08:22||monteslu_ has joined IRC (email@example.com)|
|08:40||khildin has joined IRC (firstname.lastname@example.org)|
alkisg: I'll have a look later today, but yeah, going through all the symlinks and updating their destination to point to the right one sounds better than hardcoding them one by one
Hi stgraber, vagrantc said yesterday that he prefers to do them manually, but I agree with you :)
We'll need to change a few symlinks to point to common/ instead of server/ though
European timezone, I assume? welcome! :)
yeah, I arrived in Switzerland yesterday morning :)
got to go now though, family easter lunch ;)
Switzerland is nice!
Enjoy it. :-)
|08:57||Llama_be has left IRC (Llama_beemail@example.com, Quit: Changing server)|
|08:59||Llama_be has joined IRC (Llama_befirstname.lastname@example.org)|
|08:59||Trixboxer has joined IRC (Trixboxer!~Trixboxer@18.104.22.168)|
|09:59||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 276 seconds)|
|10:08||rickogden has joined IRC (email@example.com)|
|11:29||adrianorg__ has joined IRC (firstname.lastname@example.org)|
|11:29||adrianorg_ has joined IRC (email@example.com)|
|11:33||adrianorg__ has left IRC (firstname.lastname@example.org, Ping timeout: 246 seconds)|
|11:41||alexqwesa has left IRC (email@example.com, Quit: Хана X'ам !!!)|
|11:51||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|12:11||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)|
|12:12||khildin has left IRC (firstname.lastname@example.org, Quit: I'm gone, bye bye)|
|12:46||adrianorg_ has left IRC (email@example.com, Read error: Operation timed out)|
|13:13||Trixboxer has left IRC (Trixboxer!~Trixboxer@22.214.171.124, Quit: "Achievement is not the end, its the beginning of new journey !!!")|
|13:20||risca has left IRC (firstname.lastname@example.org, Quit: Lämnar)|
|13:36||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|14:07||tessier has left IRC (tessier!~treed@kernel-panic/copilotco, Ping timeout: 252 seconds)|
|14:07||tessier has joined IRC (email@example.com)|
|14:07||komunista has left IRC (firstname.lastname@example.org, Ping timeout: 248 seconds)|
|14:49||irule has left IRC (email@example.com, Ping timeout: 260 seconds)|
|15:01||tessier has left IRC (firstname.lastname@example.org, Read error: Operation timed out)|
|15:13||rickogden has left IRC (email@example.com, Quit: Leaving.)|
|15:18||vagrantc has joined IRC (firstname.lastname@example.org)|
|15:28||tessier has joined IRC (email@example.com)|
|15:48||* alkisg waves to vagrantc... would you have time for an epoptes upload tomorrow? Should I prepare the version+changelog?|
alkisg: the check for ltsp boot seems over-broad, though ...
It's even wrong, as the |ltsp check also matches the init=/sbin/init-ltsp part
I think I'd prefer to check only for init=/sbin/init-ltsp, and if someone wants to "fake" it, he can use fake_init=/sbin/init-ltsp
Ah, you mean in epoptes?
Let me see...
though probably in all cases
That's the main check: grep -qs "init=/sbin/init-ltsp" /proc/cmdline && exit 0
...which is what I said above too
alkisg: there's another check in epoptes-client/epoptes-client
This one, is for compatibility for older ltsp versions: egrep -qs 'ltsp|nfs|nbd' /proc/cmdline
+ egrep -qs 'ltsp|nfs|nbd' /proc/cmdline
it will catch any non-ltsp nfs or nbd boot as well, though
|15:52||komunista has joined IRC (firstname.lastname@example.org)|
Yes, but if they're netbooted, they don't want epoptes running in all clients either
So they'll have to provide the EPOPTES variable somehow
...although I also check for getltscfg existance
calling getltscfg directly will only catch lts.conf changes, not ltsp_confid.d changes as well
or other ltsp_config logic
Indeed, but running epoptes from a fat client is a rare use case, I didn't think it would be worth it to take into account local ltsp_config.d scripts
Erm, running epoptes daemon _on_ a fat client
Not the GUI, which is easily done with remoteapps
is it so much worse to check for the presence of ltsp_config and sourcing that?
i'd consider calling getltscfg directly deprecated, really.
It pollutes the environment too much
I've done it in epoptes-client
additionally, since you're looking for a single environment variable, getltscfg EPOPTES would be better.
it would only look for that variable
Oh, cool, I've forgotten about that
|15:58||* vagrantc forgets the exact syntax|
getltscfg -c /var/lib/tftpboot/lts.conf LDM_DIRECTX
vagrantc: about the pxe menus... I propose that ltsp-update-kernels generates menus such as this: https://bugs.launchpad.net/ltsp/+bug/976350
We want different tftp directories for nbd vs nfs
In ltsp-pnp, I'm extracting the kernel from the squashfs/btrfs image itself, not from the chroot, in case there are mismatches due to updates
For NFS, I'm creating symlinks to $CHROOT/boot
So, I have TFTP/ltsp/i386 and TFTP/ltsp/i386~nfs
I used ~ for sort -frV to sort it lower than the nbd one, if available
I only create the nfs symlink if I find the chroot in /etc/exports,
and I only create the nbd dir if I find it in /etc/nbd-server/conf.d/ltsp_name.conf
When all that is done, the "master" update-pxe-menus" needs only to INCLUDE those menus, and put another DEFAULT at the bottom
Does that sound reasonable?
Current code, the pxelinux_cfg() function isn't ready yet, the other two functions are: http://pastie.org/3750640
komunista: if vagrantc uploads epoptes tomorrow, that means that today is the last day for translations, because it takes some hours for launchpad to commit the changes
alkisg: shouldn't need different tftp directories for nbd vs. nfs ... ?
ah, i see.
Use case: export disk with nbd and nfs, then update chroot
NFS works, NBD has problems
right, i commented on the first thing you said before reading more
It also allows for a cleaner way to handle parameters, menus or not etc, as each dir (nbd/nfs/other arches) gets its own pxelinux.cfg/default
alkisg: why not mount the NBD image to a separate dir?
You mean to symlink tftp to it?
We don't want them always mounted, do we?
I temporarily mount it to a temp dir to fetch the kernels, and umount it afterwards
alkisg: it would seem simpler to me to leave it mounted (read-only, for filesystems that matter)
then you just have to re-mount when the image updates ... otherwise evertything works "as normal"
alkisg: also, check in /etc/exports.d
Hmmm I don't know I don't like the idea of having many mounted loop back devices just to save some MB from the tftp dir...
alkisg: but you won't see chroot-specific configuration in /etc/exports*, as the whole /opt/ltsp is typically exported
and that's really the better way to do it ... you want to export one-level higher than your mount point, otherwise you have to restart nfs-server when you delete and re-create /opt/ltsp/i386 for example
but overall, sounds like a good direction :)
OK, I'll completely ignore /opt/ltsp/arch exports then, to make it simpler, and check for all dirs if I find /opt/ltsp in /etc/exports*
i mean, it's technically allowable to export /opt/ltsp/ARCH, but there are drawbacks
Any comments on the tftp dir names? I put "i386" and "i386~nfs", so that NBD is preferred over NFS (I assume if one has both, he wants the users to default to the faster one, and when he wants e.g. to test, he can manually select nfs)
why ~ ?
For sort -frV to put it lower
So that it defaults to nbd
why not i386-nbd and i386-nfs ?
just to make it explicit
...I thought about that too, and then I thought that i386-nfs would come before i386-nbd, and I wouldn't like that, ...
...but now that you say it, it'd be better to list the dirs in ascending order,
and just the kernels in descending
So yup you're right once more :)
at least i'm not babbling pointlessly :)
alkisg: what is it about your proposed menu entries that are significantly different from the existing menu entries?
alkisg: for pxelinux.cfg
vagrantc: they have labels that can be used by the pxelinux menus systems
And they list all available kernels
So people can try older or custom kernels if they want to
So the master pxelinux.cfg can just include all those
no need to force IPAPPEND=3 ?
|16:30||* vagrantc would like to default to IPAPPEND=2|
The IPAPPEND 3 line would be configurable as it is now
And the bootprompt options too
alkisg: done ;-)
komunista: nice, thanks!
vagrantc: typically, the chroot update-kernels would generate those menus, I just do it separately now because ltsp-pnp will be released after precise
And the server ltsp-update-kernels will just copy them
(although it'll need to take care about the nbd vs nfs parameters)
So the bootprompt_options should only list the extra parameters, not the nbd or nfs specific ones
E.g. quiet splash or whatever else the user wants
...maybe IPAPPEND 3 or not needs to be decided on the server too... it's a server setting, not a client one
OK after babbling, I think that the chroot only needs to provide the distro specific parameters, quiet, splash, vt_handoff etc
i guess all our chroots now support both NFS and NBD ... at least on debian/ubuntu ?
without changes in the chroot
But we don't want to list them in the pxe menu if the user hasn't enabled nfs or nbd
So, checking /etc/nbd-server/conf.d and /etc/exports* sounds appropriate...
alkisg: what if we generate the current menus, with additional entries for all the versioned kernels?
vagrantc: they don't have MENU LABEL statements
that might be easy to implement, and wouldn't mess with the status quo
And no help text
we can add a few things, i'm just thinking of code ordering
The "new" pxelinux.cfg format is compatible with the older booting method
er, versioning ... using the unversioned symlinks as the default entry
If one has boot filename = ltsp/i386/pxelinux.cfg, it'll work as expected, with the latest kernel
I've seen cases where the vmlinuz symlink is broken
So I wouldn't worry too much about keeping a customized symlink as the default,
defaulting to the newest kernel sounds good enough for me...
and they're deprecated in debian ...
so i'll need to use linux-version to ensure the proper ordering
In which cases does sort -frV not sort the kernels correctly?
alkisg: it works today, but the only thing that the debian kernel team promises to not break is linux-version.
OK, I was thinking for some backwards compatibility + less dependencies, i.e. to postpone it until linux-version is widely available
alkisg: i think upstream can use "sort" and debian can use linux-version if it's available
http://packages.ubuntu.com/search?keywords=linux-base => 11.10 onward
So with a hard Depends: linux-base, ltsp wouldn't install on 10.04, it'd better be a Recommends: instead, and that would also cause it not to be installed in ubuntu chroots as recommends==off by default there... :-/
As you said, if it's available, fine
I think that the only unclear part that remains is the bootprompt_options split between server / client
NFS vs NBD is decided on the server, IPAPPEND 3 too
The rest should probably be decided by the client
ro initrd=initrd.img nbdport=2000 nbdroot=:ltsp_i386 nbdserver=10.160.31.10 root=/dev/nbd0 => server too
init=/sbin/init-ltsp quiet splash plymouth:force-splash vt.handoff=7 nbd_proxy=false nocompcache => client
...I guess we need to parse the command line and strip/replace known parameters
And leave the unknown ones
So, ltsp-update-kernels on the server, will modify pxelinux.cfg/default appropriately, in the TFTP dir (which for NFS is the same as the CHROOT/boot dir)
I don't think there's need for ltsp-update-kernels on the server to touch CHROOT/etc/update-kernels.conf on the client
*on the chroot
|16:52||* alkisg thinks he has all the info he needs, on to coding all that... :)|
|16:59||monkeydiver has joined IRC (email@example.com)|
|17:03||monteslu__ has joined IRC (firstname.lastname@example.org)|
alkisg: fun and adventures :)
|17:06||monteslu_ has left IRC (email@example.com, Ping timeout: 265 seconds)|
|17:14||Parker955_Away is now known as Parker955|
|17:23||loather has joined IRC (firstname.lastname@example.org)|
|17:27||markit has joined IRC (email@example.com)|
I'm fighting with disabling the suspend/hybernate stuff. Kde dev says depends on underlying GNU/linux stuff, but what should work does not
anyone solved it?
maybe I'm becoming stupid... can't find anymore how file a bug in lauchpad :(
|18:16||monkeydiver has left IRC (firstname.lastname@example.org, Quit: Leaving)|
|18:32||rickogden has joined IRC (email@example.com)|
|18:36||adrianorg_ has joined IRC (firstname.lastname@example.org)|
|18:41||joat has left IRC (email@example.com, Quit: bye)|
|18:55||rickogden has left IRC (firstname.lastname@example.org, Quit: Leaving.)|
|19:16||joat has joined IRC (email@example.com)|
mmm squid3 seems killed by dnsmasq at startup
anyone with 12.04 and squid3?
(and dnsmasq, of course)?
|19:33||alexqwesa has joined IRC (firstname.lastname@example.org)|
|20:03||mistik1 has left IRC (mistik1!mistik1@unaffiliated/mistik1, Ping timeout: 276 seconds)|
|20:04||mistik1 has joined IRC (mistik1!mistik1@unaffiliated/mistik1)|
|20:05||markit has left IRC (email@example.com, )|
|20:44||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)|
|20:44||vagrantc has left IRC (firstname.lastname@example.org, Ping timeout: 240 seconds)|
|20:55||alexqwesa has left IRC (email@example.com, Quit: Хана X'ам !!!)|
|21:07||komunista has left IRC (firstname.lastname@example.org, Quit: Leaving.)|
|21:32||tessier has left IRC (email@example.com, Changing host)|
|21:32||tessier has joined IRC (tessier!~treed@kernel-panic/copilotco)|
|21:54||bergerx has left IRC (firstname.lastname@example.org, Quit: Leaving)|
|21:55||alexqwesa has joined IRC (email@example.com)|
|23:11||Lurk3r has joined IRC (Lurk3r!~Lurk3r@d50-98-141-185.bchsia.telus.net)|
|23:25||irule has joined IRC (firstname.lastname@example.org)|