[Pkg-ltsp-devel] features i'd like to work on
Vagrant Cascadian
vagrant at freegeek.org
Tue Jul 4 16:28:00 UTC 2006
On Tue, Jul 04, 2006 at 09:16:57AM -0300, Otavio Salvador wrote:
> Vagrant Cascadian <vagrant at freegeek.org> writes:
>
> > the first one is a wrapper around chroot that does special things like
...snip...
> I like the idea but I found some problems with current code:
>
> - arch detection is debian dependent. There's already made code to be
> generic in set-arch and you might do a look at it;
yeah, it was just a quick and dirty implementation. if you read the
TODO comments, you'll notice i was aware of this :P
> - impossibility to set ROOT to something different of /opt/ltsp while
> in ltsp-build-client it's possible;
> The way the I see to workaround this issues is to use a ltsp common
> plugin repository to set the architecture and root running same code
> that will be run by ltsp-build-client.
yeah, i was thinking some of this stuff could be moved into some common
functions.
> The most complicated problem
> is, when the user use --base it won't be passed to ltsp-chroot and
> then we'll need to pass the commandline option. That won't make too
> much difference of current way to do it.
which could be handled by setting the ROOT environment variable, or
putting a configuration file in /etc, or adding a commandline argument
to ltsp-chroot (all of this was possible with the lessdisks version).
i'd kind of like to improve support for non-standard install locations
anyways, but that's another issue :)
the lessdisks script i largely based ltsp-chroot on is:
http://dev.lessdisks.net/projects/lessdisks/browser/trunk/install/usr-sbin/lessdisks-chroot
> > i'd also like to split some of the functionality found in
> > ltsp-update-kernels get split into the ltsp-client package, and have it
> > run chrooted(or in the case of a different architecture, on a privledged
> > client with write access of some sort). then the ltsp-update-kernels
> > package would mostly just copy files into place(and maybe run chrooted
> > scripts if the architecture is supported), rather than the special
> > network-bootable preparations(mknbi, yaboot, netabootwrap, etc). this
> > way we could get support for multiple architectures.
>
> I didn't understand this last one. If we remove mknbi and like we
> loose support to anything but pxe. No?
what i was suggesting was to move that code (mknbi, yaboot,
netabootwrap, etc) into a script within the chroot that gets run
chrooted (or on a priveledged client if the arch is incompatible).
so ltsp-update-kernels would do something like this:
* look for chroots with supported architecture
* run chrooted script (for mknbi, yaboot, netabootwrap, etc)
* copy images and/or kernels into the tftp directory
* other tweaks (such as pxe configuration)
live well,
vagrant
More information about the Pkg-ltsp-devel
mailing list