On Thu, Jun 26, 2014 at 03:29:23PM -0400, hazzmat wrote: > Also following advice from another thread I > googled up, I made a copy of the ltsp-build-client script to > my-ltsp-build-client and edited it to state VENDOR=Debian. > So my commandline for installing the client chroot environment was as follows: > # ./my-ltsp-build-client --purge-chroot --dist wheezy --mirror http:// > ftp.us.debian.org/debian/ --arch i386
As mentioned earlier, you should be able to use: VENDOR=Debian ltsp-build-client ... Rather than writing a wrapper script... overriding the VENDOR variable has been supported in ltsp-build-client upstream since 2012-05-19. the --purge-chroot argument should only be necessary if /opt/ltsp/$arch exists, such as from a prior failed or test run. > # ./my-ltsp-build-client --purge-chroot --mirror http://ftp.us.debian.org/ > debian --updates-mirror http://ftp.us.debian.org/debian --security-mirror > http: > //security.debian.org --dist wheezy --arch i386 --late-packages icewm It should just use the default mirrors... why it required that is surprising to me. > I then had some to-do with the nbd server and Debian not hitting it off. But > by > late morning, I had it switched over to NFS and the ThinkNiC was actually > loading the Debian 3.2. kernel. And I am now able to log on my example user to > his icewm desktop and surf the internet and print through the ltsp host. Yeah, Debian defaults to using NFS, although it can be configured to use either. Ubuntu defaults to NBD, though can be configured to use either. > However, I'm sure this is not the right way to do things. Yes, it's basically > running, but there's bound to be something wrong with an installation created > by ugly hacking like this. Overall, it should basiclly work, though as you've seen there may be a few glitches. What version of the ltsp-server package do you have? My biggest fear is the Ubuntu ltsp-server package may be missing some Debian-specific bugfixes, as the versions do tend to be a out of sync a bit. > For one thing there's no locale set appparently, > although I expect setting it via an option to the ltsp-build-client script > would take care of that when I do this for real on the "production" server. That's easy enough to set after the fact, too: sudo ltsp-chroot dpkg-reconfigure locales > I'm > not even sure what my question is - can the defects of this installation be > repaired in place? Or do I need to start over with a completely different > client build commandline and no hackery to the mirror related plugins? Ideally, you'd want to fix it or work around it with as few steps as possible, so passing arguments and such is probably better than fixing things after the fact. Overall, ltsp-build-client doesn't actually do much, especially in recent years, where we've moved some hacks into boot-time rather than install-time hacks. So there's not a whole lot to go wrong. If you really want to produce a clean build environment, you could install a Debian chroot and run ltsp-build-client from inside the chroot, and then move the resulting LTSP chroot/img out into the appropriate place on the Ubuntu server. live well, vagrant
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
