LTSP 5 is the next generation of the Linux Terminal Server Project that uses the distribution to provide all the non-LTSP-specific bits. At http://dev.gentoo.org/~dberkholz/ltsp/ I detailed some of the info. setup.txt: what's needed for a manual terminal server setup ltsp.txt: initial estimate of what's needed to port LTSP-5 Gentoo/: contains initial port of some ltsp-build-client plugins
Any update on this? LTSP5 on Gentoo will be really appreciated! I can help with testing..
I spent some time working on ltsp-build-client last weekend. It's still nowhere near ready. I'm now pushing my commits to upstream bzr, so you can track progress there.
Can you give me any URLs/etc.? I am not that familiar with LTSP 5, I was using LTSP 4.2 to the moment and now I definitely need an updated X server for LTSP clients..
If you aren't going to be developing it, any URLs I gave you would be totally pointless because it's unusable.
is there some kind of roadmap, for gentoo ltsp-5?
Roadmap in terms of a time frame? Not really. In terms of what stuff needs to be done, I could tell you if you care.
Update: Work is actively going on right now on this. We now have a project overlay, although the state of things is still completely unusable, and Johnny Robeson is doing a bunch of work right now.
i have a problem with the gnome-applets-2.20/2.22.1 keyboard layout switcher on the terminals: it switches with left click only for the first click, and does not show the changes, it just switches the layout, it switches the layout with rightclick/groups/select, but again does not show the changes. i tried it with the combination of a gentoo terminal-server and terminals:ltsp4-2, debian/stable ltsp-client, debian/testing ltsp-client-0.99debian11 with the same results. and i could not find a solution for this. now i'am about to try test this issue with a gentoo as the terminal. i could build anything for that, except the ltsp client scripts. and here comes the previous post. i'd be happy to test your work, in whatever phase it is. i can imagine fetching your client-scripts/init-scripts onto a self-built gentoo-netboot-root, where i'd use current gentoo xorg-server. i could copy over the debian ltsp initrd/initscripts/screen.d/build_xorg_config and hack them to run an X -query for me, but i thought i could help ltsp on gentoo. so is there anything usable i could start with?
(In reply to comment #8) > so is there anything usable i could start with? I think there will be pretty soon. We've got something that installs and boots. I'm not sure about upgrades yet. I'll see if I can get the code into the upstream repositories over the next couple of weeks, and I'll post news here.
(In reply to comment #7) > Update: Work is actively going on right now on this. We now have a project > overlay, although the state of things is still completely unusable, and Johnny > Robeson is doing a bunch of work right now. > Where is the overlay please ?
You can browse it at http://git.overlays.gentoo.org/gitweb/?p=proj/ltsp.git;a=summary (click "tree"), and the URLs to download it with "git clone" are also on that page (use the first one).
Created attachment 161599 [details] /etc/ltsp/quickstart/profile.qs Current status is quite promising. I've successfully built the client (customized genkernel in the client root to include my networking module in /usr/share/genkernel/x86/modules_load & rebuilt initrd) and hand-configured the server's NFS/dnsmasq/pxelinux. I have an uncommitted version of the quickstart profile to enable ccache and binpkg creation, which does a pretty reasonable job of saving time on repeat builds. It's attached.
the gentoo-ltsp branch has been merged into ltsp-trunk I'll soon be asking for testers once i write some basic documentation in gentoo's guidexml format
the next steps for ltsp5 for gentoo involve custom configuration for genkernel so that it can include network modules in the initramfs and remove the other drivers that slow loading of the initramfs on boot If anybody wants to join me in #ltsp to discuss how we can proceed further on this issue without completely hacking genkernels installed config that would be wonderful
I can help you if you want. I have a server and a few node where I need to use ltsp. Netboot is working, the client works. X starts, I can connect to the xdmcp server. However, I don't understand how to put ltsp upon that. Polytan
(In reply to comment #15) > I can help you if you want. > > I have a server and a few node where I need to use ltsp. > > Netboot is working, the client works. X starts, I can connect to the xdmcp > server. However, I don't understand how to put ltsp upon that. > > Polytan > i just missed you in #ltsp on freenode the other day. try back again my nick is johnny that goes for anybody else following this bug too
Installed the ltsp-server from the ltsp git overlay of Mon, 26 Jan 2009 18:47:58 +0000. Upon entering ltsp-build-client i get: Installing into: /opt/ltsp/x86 * Sanity checking config * kernel_sources not set...assuming gentoo-sources * logging_daemon not set...assuming syslog-ng * Sanity checking partition config for x86 * bootloader not set...assuming grub * Fetching and unpacking stage tarball * Preparing chroot * Installing portage tree * 'none' specified...skipping * Setting root password * Setting timezone * Building kernel * could not emerge kernel sources * Cleaning up after install failure error: LTSP client installation ended abnormally Where does the error message come from? I can help test things, I lurk in #ltsp with nick knipwim.
same here: ltsp-build-client --dist Gentoo Default Quickstart profile: /etc/ltsp/quickstart/profile.qs Installing into: /opt/ltsp/x86 * Sanity checking config * kernel_sources not set...assuming gentoo-sources * logging_daemon not set...assuming syslog-ng * Sanity checking partition config for x86 * bootloader not set...assuming grub * Fetching and unpacking stage tarball * Could not fetch stage tarball * Cleaning up after install failure error: LTSP client installation ended abnormally fetching failed :( and i see there could be a conf file in /etc/ltsp/ltsp-build-client.conf, but i don't know what to put into, so i miss a ltsp-build-client.conf.example in /usr/share/doc/ltsp-server-9999/ btw, the step "Cleaning up after install failure" does not remove my /opt/ltsp/x86/
# ltsp-build-client --debug --dist Gentoo --stage-uri http://mirrors.evolva.ro/gentoo/releases/x86/current/stages/stage3-x86-2008.0.tar.bz2 Installing into: /opt/ltsp/x86 * Sanity checking config * kernel_sources not set...assuming gentoo-sources * logging_daemon not set...assuming syslog-ng * Sanity checking partition config for x86 * bootloader not set...assuming grub * Fetching and unpacking stage tarball * Preparing chroot * Installing portage tree * 'none' specified...skipping * Setting root password * Setting timezone * Building kernel * could not build generic kernel * Cleaning up after install failure error: LTSP client installation ended abnormally so how can i continue or at least find out where is the problem? is there a log i should look at?
> so how can i continue or at least find out where is the problem? > is there a log i should look at? > Add "--quickstart-verbose" to the end of the ltsp-build-client command and it will show all the external command output. A more verbose error should then be visible.
i found the genkernel log in the client tree, i had not loaded the loop module on the host. now it's building the clients' kernel. thanks
(In reply to comment #21) > i found the genkernel log in the client tree, > i had not loaded the loop module on the host. > now it's building the clients' kernel. > thanks > i'm going to make ltsp-build-client check for this
emergiing failed becouse of a download error. i made chroot emerge --resume in the client tree, but i don't know what else the script would have done. is the emerging the final step? if not can it be made to? can i resume the script?
i restarted the script: /var/tmp/portage/net-misc/ltsp-client-9999/work/ltsp-client-9999 >>> Source compiled. >>> Test phase [not enabled]: net-misc/ltsp-client-9999 >>> Install ltsp-client-9999 into /var/tmp/portage/net-misc/ltsp-client-9999/image/ category net-misc install: cannot stat `localapps/localapps-menu/*': No such file or directory !!! doins: localapps/localapps-menu/* does not exist ACCESS DENIED open_wr: /etc/lts.conf cp: cannot create regular file `/etc/lts.conf': Permission denied >>> Completed installing ltsp-client-9999 into /var/tmp/portage/net-misc/ltsp-client-9999/image/ --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-3974.log" open_wr: /etc/lts.conf -------------------------------------------------------------------------------- * QA Notice: file does not exist: * * doins: localapps/localapps-menu/* does not exist >>> Failed to emerge net-misc/ltsp-client-9999, Log file: >>> '/var/tmp/portage/net-misc/ltsp-client-9999/temp/build.log' .... * could not emerge extra packages * Cleaning up after install failure error: LTSP client installation ended abnormally
emerged with FEATURES="-sandbox" the ltsp-client, then ldm, but i don't know how to resume/finish the ltsp-build-client
(In reply to comment #25) > emerged with FEATURES="-sandbox" the ltsp-client, then ldm, but i don't know > how to resume/finish the ltsp-build-client > you shouldn't have to do any of that, I'll try to correct the localapps files stuff in the next day or so
> and i see there could be a conf file in /etc/ltsp/ltsp-build-client.conf, but > don't know what to put into, so i miss a ltsp-build-client.conf.example in > /usr/share/doc/ltsp-server-9999/ > > btw, the step "Cleaning up after install failure" does not remove my > /opt/ltsp/x86/ > /etc/ltsp/ltsp-build-client.conf is not necessary for anybody to use and the cleanup is the same as every other distro. It is not cleaned up on purpose if all the ltsp maintainers decide that it should, then we will follow as well
Two things, for now: - shouldn't x11-misc/ldm be a dependency for net-misc/ltsp-client? - x11-misc/ldm should depend on app-text/iso-codes; My first emerge failed with (excerpt, i have the complete build log): IOError: [Errno 2] No such file or directory: '/usr/share/xml/iso-codes/iso_639.xml' make[2]: *** [locales] Error 1 make[2]: Leaving directory `/var/tmp/portage/x11-misc/ldm-9999/work/ldm-9999' It emerged fine after emerging iso-codes.
(In reply to comment #28) > Two things, for now: > > - shouldn't x11-misc/ldm be a dependency for net-misc/ltsp-client? > - x11-misc/ldm should depend on app-text/iso-codes; > > My first emerge failed with (excerpt, i have the complete build log): > > IOError: [Errno 2] No such file or directory: > '/usr/share/xml/iso-codes/iso_639.xml' > make[2]: *** [locales] Error 1 > make[2]: Leaving directory `/var/tmp/portage/x11-misc/ldm-9999/work/ldm-9999' > > It emerged fine after emerging iso-codes. > yes.. will add iso-codes soon
Is there any particular reason why Funtoo is chosen to get the stages, except for them being named convenient ("http://www.funtoo.org/linux/gentoo/${ARCH}/stage3-${ARCH}-current.tar.bz2)? Took the liberty of asking Gentoo Releng to rename their stages (http://bugs.gentoo.org/show_bug.cgi?id=268481) I made some documentation (http://en.gentoo-wiki.com/wiki/LTSP) of which some parts (or all) can be written in guidexml. Which parts or none? The iso-codes dependency is not committed yet.
(In reply to comment #29) > (In reply to comment #28) > > Two things, for now: > > > > - shouldn't x11-misc/ldm be a dependency for net-misc/ltsp-client? > > - x11-misc/ldm should depend on app-text/iso-codes; > > > > My first emerge failed with (excerpt, i have the complete build log): > > > > IOError: [Errno 2] No such file or directory: > > '/usr/share/xml/iso-codes/iso_639.xml' > > make[2]: *** [locales] Error 1 > > make[2]: Leaving directory `/var/tmp/portage/x11-misc/ldm-9999/work/ldm-9999' > > > > It emerged fine after emerging iso-codes. > > > yes.. will add iso-codes soon > iso-codes still not added. Overlay hasn't been updated since 26 Jan 2009 and now there is a dependency problem with cairo. I'm not sure which packages depend on it as I've already worked past this by editing the ltsp-build-client file. I simply added spawn_chroot "emerge -1 --newuse cairo" before the spawn_chroot "emerge -k --newuse --update --deep world" in the pre_install_extra_packages() routine. I'm not sure this is the correct way to fix this, but it works for me. Now it halts building ldm because of the iso-codes dependency. I will try to figure out where to put the emerge of iso-codes (probably in the pre_install_extra_packages as I did with cairo). I would really appreciate an update to the tree though as I have been desperately waiting for a way to install LTSP5 in Gentoo and now I am starting to roll out servers and I really don't want to use openSUSE ;). Thanks, Andrew
I see ISO-codes is now committed, but I can't test it as I cannot emerge ldminfod. testltsp ~ # emerge ldminfod Calculating dependencies... done! >>> Verifying ebuild manifests >>> Emerging (1 of 1) net-misc/ldminfod-9999 from ltsp * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... * This ebuild uses EBZR_BRANCH which is not supported anymore * by the bzr.eclass. Please report this to the ebuild's maintainer. * * ERROR: net-misc/ldminfod-9999 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2359: Called bzr_src_unpack * environment, line 385: Called die * The specific snippet of code: * die "EBZR_BRANCH still defined"; * The die message: * EBZR_BRANCH still defined * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/net-misc/ldminfod-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-misc/ldminfod-9999/temp/environment'. * This ebuild is from an overlay named 'ltsp': '/usr/local/portage/layman/ltsp/' *
(In reply to comment #32) > I see ISO-codes is now committed, but I can't test it as I cannot emerge > ldminfod. > > testltsp ~ # emerge ldminfod > Calculating dependencies... done! > > >>> Verifying ebuild manifests > > >>> Emerging (1 of 1) net-misc/ldminfod-9999 from ltsp > * checking ebuild checksums ;-) ... > [ ok ] > * checking auxfile checksums ;-) ... > [ ok ] > * checking miscfile checksums ;-) ... > [ ok ] > >>> Unpacking source... > * This ebuild uses EBZR_BRANCH which is not supported anymore > * by the bzr.eclass. Please report this to the ebuild's maintainer. > * > * ERROR: net-misc/ldminfod-9999 failed. > * Call stack: > * ebuild.sh, line 49: Called src_unpack > * environment, line 2359: Called bzr_src_unpack > * environment, line 385: Called die > * The specific snippet of code: > * die "EBZR_BRANCH still defined"; > * The die message: > * EBZR_BRANCH still defined > * > * If you need support, post the topmost build error, and the call stack if > relevant. > * A complete build log is located at > '/var/tmp/portage/net-misc/ldminfod-9999/temp/build.log'. > * The ebuild environment file is located at > '/var/tmp/portage/net-misc/ldminfod-9999/temp/environment'. > * This ebuild is from an overlay named 'ltsp': > '/usr/local/portage/layman/ltsp/' > * > It appears that a change the the bzr.eclass is to blame for this. However, I was able to get past this by editing the ldminfod-9999.ebuild and appending the EBZR_BRANCH path to the end of the EBZR_REPO_URI path. ala testltsp ldminfod # diff ldminfod-9999.ebuild.orig ldminfod-9999.ebuild 8,9c8,9 < EBZR_REPO_URI="http://bazaar.launchpad.net/~ltsp-upstream/ltsp/" < EBZR_BRANCH="ldm-trunk" --- > EBZR_REPO_URI="http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk" > # EBZR_BRANCH="ldm-trunk" BTW, EBZR_BRANCH also appears in the ltsp-server-9999.ebuild, ltsp-client-9999.ebuild, ltspfs-9999.ebuild and the ldm-9999.ebuild. Thanks for everyones work. It is much appreciated!
(In reply to comment #32) fixed and committed
(In reply to comment #34) > (In reply to comment #32) > > fixed and committed > same problem here: * Messages for package sys-fs/ltspfs-9999: * * ERROR: sys-fs/ltspfs-9999 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2835: Called bzr_src_unpack * environment, line 562: Called bzr_fetch * environment, line 540: Called die * The specific snippet of code: * ${EBZR_FETCH_CMD} ${EBZR_OPTIONS} "${repository}" "${EBZR_BRANCH_DIR}" || die "${EBZR}: can't branch from ${repository}."; * The die message: * bzr.eclass: can't branch from http://bazaar.launchpad.net/~ltsp-upstream/ltspfs/ltspfs-trunktrunk. * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/sys-fs/ltspfs-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-fs/ltspfs-9999/temp/environment'. * This ebuild is from an overlay named 'ltsp': '/usr/local/portage/layman/ltsp/'
(In reply to comment #35) > (In reply to comment #34) > > (In reply to comment #32) > > > > fixed and committed > > * Messages for package sys-fs/ltspfs-9999: * * ERROR: sys-fs/ltspfs-9999 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2835: Called bzr_src_unpack * environment, line 562: Called bzr_fetch * environment, line 540: Called die * The specific snippet of code: * ${EBZR_FETCH_CMD} ${EBZR_OPTIONS} "${repository}" "${EBZR_BRANCH_DIR}" || die "${EBZR}: can't branch from ${repository}."; * The die message: * bzr.eclass: can't branch from http://bazaar.launchpad.net/~ltsp-upstream/ltspfs/ltspfs-trunktrunk. * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/sys-fs/ltspfs-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-fs/ltspfs-9999/temp/environment'. * This ebuild is from an overlay named 'ltsp': '/usr/local/portage/layman/ltsp/' ============ * Messages for package net-misc/ldminfod-9999: * * ERROR: net-misc/ldminfod-9999 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2346: Called bzr_src_unpack * environment, line 387: Called bzr_fetch * environment, line 370: Called die * The specific snippet of code: * ${EBZR_UPDATE_CMD} ${EBZR_OPTIONS} "${repository}" || die "${EBZR}: can't merge from ${repository}."; * The die message: * bzr.eclass: can't merge from http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunktrunk. * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/net-misc/ldminfod-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-misc/ldminfod-9999/temp/environment'. * This ebuild is from an overlay named 'ltsp': '/usr/local/portage/layman/ltsp/' * ================ * ERROR: net-misc/ltsp-server-9999 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2364: Called bzr_src_unpack * environment, line 387: Called bzr_fetch * environment, line 365: Called die * The specific snippet of code: * ${EBZR_FETCH_CMD} ${EBZR_OPTIONS} "${repository}" "${EBZR_BRANCH_DIR}" || die "${EBZR}: can't branch from ${repository}."; * The die message: * bzr.eclass: can't branch from http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunktrunk. * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/net-misc/ltsp-server-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-misc/ltsp-server-9999/temp/environment'. * This ebuild is from an overlay named 'ltsp': '/usr/local/portage/layman/ltsp/' * ============ diff ldminfod-9999.ebuild ldminfod-9999.old.ebuild 8,9c8 < EBZR_REPO_URI="http://bazaar.launchpad.net/~ltsp-upstream/ltsp/" < EBZR_BRANCH="ldm-trunk" --- > EBZR_REPO_URI="http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk" ============= diff ltspfs-9999.ebuild ltspfs-9999.old.ebuild 10,11c10 < EBZR_REPO_URI="http://bazaar.launchpad.net/~ltsp-upstream/${PN}/" < EBZR_BRANCH="ltspfs-trunk" --- > EBZR_REPO_URI="http://bazaar.launchpad.net/~ltsp-upstream/${PN}/ltspfs-trunk" ========= diff ltsp-server-9999.ebuild ltsp-server-9999.old.ebuild 10,11c10 < EBZR_REPO_URI="http://bazaar.launchpad.net/~ltsp-upstream/ltsp/" < EBZR_BRANCH="ltsp-trunk" --- > EBZR_REPO_URI="http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk"
(In reply to comment #32) Please add an emerge info.
(In reply to comment #37) > (In reply to comment #32) > > Please add an emerge info. > please ignore my previous post, emerge --sync fixed all that. other things that popped up during installation: 1. I needed to add PACKAGES="xorg-server" to /etc/ltsp/ltsp-build-client.conf for LDM to load 2. originally bad choice of chroot dir as listed at http://en.gentoo-wiki.com/wiki/LTSP made /etc/init.d/ltsp-client-setup and /usr/share/ltsp/ltsp_config fail to correctly detect SERVER - THAT SEEMS TO HAVE BEEN FIXED BY CHOOSING /opt/ltsp/x86 AS CHROOT DIR 3. with most recent portage, client fails to fetch lts.conf from /opt/ltsp/tftproot/ltsp/x86 with references to missing libreadline.so.5. In general I think its a good idea to add gentoolkit to extra_packages() of /etc/ltsp/quickstart/profile.qs and add spawn_chroot "revdep-rebuild" to post_install_extra_packages()
I am following the directions on the wiki page (http://en.gentoo-wiki.com/wiki/LTSP) to build LTSP 5 for my amd64 system. I'm in the Client Configuration section and I'm having trouble with the ltsp-build-client script. Running it with --quickstart-verbose, I'm seeing this output as the build fails: spawn_chroot(): wrapping command 'emerge ldm ltsp-client' in chroot script spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' !!! Your current profile is deprecated and not supported anymore. !!! Please upgrade to the following profile if possible: default/linux/x86/10.0 To upgrade do the following steps: # Check 'eselect profile list'. # Find the number that corresponds with the default/linux/x86/10.0 profile. # Use 'eselect profile set <number>' to set a new /etc/make.profile symlink. # # Reference: http://www.gentoo.org/doc/en/gentoo-upgrading.xml # See: "General instructions" in Section 3. "Profile updating instructions" Calculating dependencies ... done! emerge: there are no ebuilds built with USE flags to satisfy ">=sys-fs/udev-143[extras]". !!! One of the following packages is required to complete your request: - sys-fs/udev-146-r1 (Change USE: +extras) (dependency required by "media-sound/pulseaudio-0.9.19" [ebuild]) (dependency required by "net-misc/ltsp-client-9999" [ebuild]) (dependency required by "ltsp-client" [argument]) * could not emerge extra packages * Cleaning up after install failure runstep(): executing pre-hook for failure_cleanup spawn(): running command 'mv /tmp/install.log /tmp/install.log.failed' spawn(): running command 'umount /opt/ltsp/x86/usr/portage/packages' spawn(): running command 'umount /opt/ltsp/x86/usr/portage' spawn(): running command 'umount /opt/ltsp/x86/usr/local/portage' spawn(): running command 'umount /opt/ltsp/x86/sys' spawn(): running command 'umount /opt/ltsp/x86/proc' spawn(): running command 'umount /opt/ltsp/x86/dev' error: LTSP client installation ended abnormally I have the install.log.failed file if that would be useful. I have "extras" in my make.conf file and I have keyworded ~amd64 for all the packages in the overlay. I have udev-146-r1[devfs-compat extras] installed on the system, so it should be able to fulfill >=sys-fs/udev-143[extras]. I did notice when I booted the last time (2.6.31) that I got the SYSFS_DEPRECATED messages... could that be related?
(In reply to comment #39) > I am following the directions on the wiki page > (http://en.gentoo-wiki.com/wiki/LTSP) to build LTSP 5 for my amd64 system. I'm > in the Client Configuration section and I'm having trouble with the > ltsp-build-client script. > > Running it with --quickstart-verbose, I'm seeing this output as the build > fails: > > spawn_chroot(): wrapping command 'emerge ldm ltsp-client' in chroot script > spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' > > !!! Your current profile is deprecated and not supported anymore. > !!! Please upgrade to the following profile if possible: > default/linux/x86/10.0 > > To upgrade do the following steps: > # Check 'eselect profile list'. > # Find the number that corresponds with the default/linux/x86/10.0 profile. > # Use 'eselect profile set <number>' to set a new /etc/make.profile symlink. > # > # Reference: http://www.gentoo.org/doc/en/gentoo-upgrading.xml > # See: "General instructions" in Section 3. "Profile updating instructions" > > > Calculating dependencies ... done! > > emerge: there are no ebuilds built with USE flags to satisfy > ">=sys-fs/udev-143[extras]". > !!! One of the following packages is required to complete your request: > - sys-fs/udev-146-r1 (Change USE: +extras) > (dependency required by "media-sound/pulseaudio-0.9.19" [ebuild]) > (dependency required by "net-misc/ltsp-client-9999" [ebuild]) > (dependency required by "ltsp-client" [argument]) > > * could not emerge extra packages > * Cleaning up after install failure > runstep(): executing pre-hook for failure_cleanup > spawn(): running command 'mv /tmp/install.log /tmp/install.log.failed' > spawn(): running command 'umount /opt/ltsp/x86/usr/portage/packages' > spawn(): running command 'umount /opt/ltsp/x86/usr/portage' > spawn(): running command 'umount /opt/ltsp/x86/usr/local/portage' > spawn(): running command 'umount /opt/ltsp/x86/sys' > spawn(): running command 'umount /opt/ltsp/x86/proc' > spawn(): running command 'umount /opt/ltsp/x86/dev' > error: LTSP client installation ended abnormally > > I have the install.log.failed file if that would be useful. > > I have "extras" in my make.conf file and I have keyworded ~amd64 for all the > packages in the overlay. I have udev-146-r1[devfs-compat extras] installed on > the system, so it should be able to fulfill >=sys-fs/udev-143[extras]. > > I did notice when I booted the last time (2.6.31) that I got the > SYSFS_DEPRECATED messages... could that be related? > I have exactly the same problem as you, and no SYSFS_DPRECATED messages.
(In reply to comment #40) I figured out what was wrong. The "extras" USE flag was not enabled in the chrooted environment. So I edited /etc/ltsp/quickstart/profile.qs and in line 104 where it says: USE="alsa pulseaudio svg xml X -cups" I added "extras": USE="alsa pulseaudio svg xml X -cups extras" Seems to have solved that problem. Thanks Marco
Thanks for that tip, Marco! That did indeed resolve that particular problem, but I still have an "ended abnormally" situation. The error I get when building ldm is: ----------------------------------------------------------------------------- ldm-dialog.o: In function `link_clicked': ldm-dialog.c:(.text+0x5e): undefined reference to `gtk_label_get_current_uri' collect2: ld returned 1 exit status make[2]: *** [ldm-dialog] Error 1 make[2]: Leaving directory `/var/tmp/portage/x11-misc/ldm-9999/work/ldm-9999/misc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/x11-misc/ldm-9999/work/ldm-9999' make: *** [all] Error 2 -----------------------------------------------------------------------------
(In reply to comment #42) I didn't have any isses, the install completed successfully. I do not use gtk though, and I have -gtk set in USE. Marco
When you say you "have -gtk set in USE" do you mean in your /etc/make.conf, or in your /etc/ltsp/quickstart/profile.qs?
(In reply to comment #44) In make.conf. Marco
(In reply to comment #45) > > In make.conf. Okay, thanks for the clarification. Perhaps Donnie or someone else can address my gtk library issue.
I added "-gtk" to the USE flags in /etc/ltsp/quickstart/profile.qs, but ldm still failed to build. This time with the error: -------------------------------------------------------------------------------- >>> Emerging (129 of 130) x11-misc/ldm-9999 from ltsp * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... * bzr update start --> * repository: http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk Tree is up to date at revision 1224. * exporting ... * begin bootstrap --> * bootstrap with a file: autogen.sh configure.ac:8: installing `./install-sh' configure.ac:8: installing `./missing' gtkgreet/Makefile.am: installing `./depcomp' Copying file mkinstalldirs Copying file po/Makefile.in.in Please add the files codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 from the /usr/share/aclocal directory to your autoconf macro directory or directly to your aclocal.m4 file. You will also need config.guess and config.sub, which you can get from ftp://ftp.gnu.org/pub/gnu/config/. ./autogen.sh: line 11: intltoolize: command not found * * ERROR: x11-misc/ldm-9999 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2376: Called bzr_src_unpack * environment, line 375: Called bzr_src_prepare * environment, line 363: Called bzr_bootstrap * environment, line 291: Called die * The specific snippet of code: * "./${EBZR_BOOTSTRAP}" || die "${EBZR}: can't execute EBZR_BOOTSTRAP."; * The die message: * bzr.eclass: can't execute EBZR_BOOTSTRAP. -------------------------------------------------------------------------------- I guess the gtk library error was a symptom, not the problem...
(In reply to comment #42) > Thanks for that tip, Marco! That did indeed resolve that particular problem, > but I still have an "ended abnormally" situation. The error I get when > building ldm is: > ----------------------------------------------------------------------------- > ldm-dialog.o: In function `link_clicked': > ldm-dialog.c:(.text+0x5e): undefined reference to `gtk_label_get_current_uri' > collect2: ld returned 1 exit status > make[2]: *** [ldm-dialog] Error 1 > make[2]: Leaving directory > `/var/tmp/portage/x11-misc/ldm-9999/work/ldm-9999/misc' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/var/tmp/portage/x11-misc/ldm-9999/work/ldm-9999' > make: *** [all] Error 2 > ----------------------------------------------------------------------------- > I've made an ldm-2.0.50 which fetches the ldm revision before the upstream implementation of "gtk_label_get_current_uri". If you want the last version, the currently unstable gtk+-2.18 and glib-2.21 are needed on the client. Sync the ltsp overlay to get it.
I sync'd the overlay with layman and "eix ldm" shows both teh 2.0.50 and 9999 versions, but it shows both versions as "~*". I have x11-misc/ldm in /etc/portage/package.keywords, but my system is amd64 and maybe it's marked stable for ~x86? At any rate, another ltsp-build-client yielded the same error as the last (the intltoolize error): -------------------------------------------------------------------------------- >>> Emerging (129 of 130) x11-misc/ldm-2.0.50 from ltsp * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... * bzr update start --> * repository: http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk Tree is up to date at revision 1224. * exporting ... * begin bootstrap --> * bootstrap with a file: autogen.sh configure.ac:8: installing `./install-sh' configure.ac:8: installing `./missing' gtkgreet/Makefile.am: installing `./depcomp' Copying file mkinstalldirs Copying file po/Makefile.in.in Please add the files codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 from the /usr/share/aclocal directory to your autoconf macro directory or directly to your aclocal.m4 file. You will also need config.guess and config.sub, which you can get from ftp://ftp.gnu.org/pub/gnu/config/. ./autogen.sh: line 11: intltoolize: command not found * * ERROR: x11-misc/ldm-2.0.50 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2375: Called bzr_src_unpack * environment, line 375: Called bzr_src_prepare * environment, line 363: Called bzr_bootstrap * environment, line 291: Called die * The specific snippet of code: * "./${EBZR_BOOTSTRAP}" || die "${EBZR}: can't execute EBZR_BOOTSTRAP."; * The die message: * bzr.eclass: can't execute EBZR_BOOTSTRAP. --------------------------------------------------------------------------------
I checked for intltoolize on my system, and intltool is installed and intltoolize is in /usr/bin. It isn't, however, in /opt/ltsp/x86/usr/bin, so if the build is happening within the chroot, it won't be finding it. I think part of my confusion is that I do not clearly understand how the chroot is used by the tools, especially when the target arch of the chroot is x86 and the arch of my system is amd64. What documentation would be good to give me a better understanding of the environment in which the ltsp-build-client is failing so that I can better diagnose and fix it myself? Thanks!
I did a sync of the overlay and ltsp-client was updated, so I'm trying again (it's still building). I noticed that I still get this warning: !!! Your current profile is deprecated and not supported anymore. !!! Please upgrade to the following profile if possible: default/linux/x86/10.0 Is that something I can fix?
I still get the same error when emerging ldm-2.0.50, "intltoolize: command not found"...
(In reply to comment #51) > !!! Your current profile is deprecated and not supported anymore. > !!! Please upgrade to the following profile if possible: > default/linux/x86/10.0 > > Is that something I can fix? > Download a Gentoo stage (http://mirrors.kernel.org/gentoo/releases/x86/autobuilds/) instead of the default stage from Funtoo. This bug will be changed upstream soon, the build-client will get a stage from Gentoo by default.
I used current-stage3/stage3-i486-20091229.tar.bz2 from the link you gave, and I didn't see the profile error, but the 130-package emerge still failed on ldm-2.0.50 with the intltoolize error.
Is there a document that outlines how the build process works? I'd like to manually build intltool before building the other parts of the ltsp client chroot or make intltool a dependency of it. If there's an easy way to do that or something that would save me time in tracking it down myself, that would be great!
(In reply to comment #55) > Is there a document that outlines how the build process works? I'd like to > manually build intltool before building the other parts of the ltsp client > chroot or make intltool a dependency of it. If there's an easy way to do that > or something that would save me time in tracking it down myself, that would be > great! > When you call ltsp-build-client, it loads any commandline arguments, the Linux vendor and the plugins. These are located in /usr/share/ltsp/plugins. Some of the plugins are common, used by all distributions, and some are specific to Gentoo. The first plugin in common/001-load-configuration-file loads the ltsp-build-client configuration file, which is used during the install. Another important plugin is located in Gentoo/010-bootstrap and it loads Quickstart together with a profile. You can view the Quickstart program in /usr/share/quickstart, the quickstart script contains all the install steps. Furthermore, I installed a clean ltsp-server and with that, installed a clean, default ltsp-client (both x86/i686). I did not experience your problems with intltool. The current upstream ltsp-server now automatically downloads the correct latest stage from Gentoo (the one I used). You can also reach me at #ltsp (knipwim).
I tried again, pulling down a new stage3 tarball and now the build works fine for me. Wim, thanks for the guide on how the build works, it is very helpful! I guess I'll continue forward with the configuration and see how LTSP5 is better than 4! Thanks for the help, everyone!
There should be tftp use flag (like dhcp) in ltsp-server ebuild in case we have already working tftp/dhcp pxe-infrastructure. Smth like this: IUSE="dhcp +nfs tftp" RDEPEND=" tftp? (virtual/tftp)
emerge ltsp-server albatros2 stages # rm -rf /opt/ltsp/amd64/ && ltsp-build-client --dist Gentoo --stage-uri file://opt/ltsp/stages/stage3-amd64-20100121.tar.bz2 --quickstart-verbose Default Quickstart profile: /etc/ltsp/quickstart/profile.qs Installing into: /opt/ltsp/amd64 * Sanity checking config * you must specify a stage_uri * kernel_sources not set...assuming gentoo-sources * logging_daemon not set...assuming syslog-ng * Sanity checking partition config for amd64 * bootloader not set...assuming grub error: LTSP client installation ended abnormally albatros2 stages # ls -l /opt/ltsp/stages/ итого 262024 -rw-r--r-- 1 root root 140939882 Янв 21 13:33 stage3-amd64-20100121.tar.bz2 -rw-r--r-- 1 root root 127093186 Янв 19 22:26 stage3-i686-20100119.tar.bz2 Any ideas?
I got the chroot to build, so that's good. I looked at the configs on the wiki page and was able to configure dhcpd and tftp-hpa. I'm still not running, but the terminal is trying to boot. The problems I have: ltsp-update-kernels fails with: Updating /tftpboot directories for chroot: /opt/ltsp/x86 Skipping invalid chroot: /opt/ltsp/stages Skipping invalid chroot: /opt/ltsp/tftproot /opt/ltsp/x86 is the chroot for / on the terminals and /opt/ltsp/stages and tftproot are the correct directories for the tftproot and stages (why is stages needed?). I could get the terminal to boot, though, if I manually moved kernel-genkernel-x86-2.6.31-gentoo-r6 and initramfs-genkernel-x86-2.6.31-gentoo-r6 into the tftproot. The wiki page says to add two lines to /opt/ltsp/tftproot/pxelinux.cfg/default (and one has an error). However, without "label linux" above those lines, the load will fail. I added the label and the terminal attempts to boot. The terminal (a Dell Optiplex GX1) suffers a kernel panic because when it goes to NFS mount /, it says the network is unreachable.
ltsp-build-client rebuilds the entire environment. Is there a way to just rebuild the kernel in the chroot?
When that terminal boots, it looks like the kernel decides that it has a tg3 network interface, but it's got a 3C95x NIC. I'm thinking that might be part of the problem. So I downloaded the gentoo install iso install-x86-minimal-20100119.iso and thought I'd check to see if that can ID the NIC right. Well, that disk boots up to where it's checking for the WD7000 and then hangs. Maybe this is a problem with the support of this hardware. I have another system that I might try as a terminal to see if that one works better. I checked the LTSP docs, but they didn't give any indication that one can specify a particular NIC driver for a terminal -- which would allow me to force the 3C95x driver over the tg3.
I tried another terminal, one much more capable than the Dell. It has an RTL network card in it and using LTSP 4.2, it works pretty well. When I booted it against my latest build of LTSP 5, it panicked at the same point as the Optiplex: When it tries to mount /, it says "Network Unreachable." I rebuilt the client chroot on Saturday, so I have the latest build of the client environment... I'm at a loss. I am using a different DHCP server and TFTP server than the wiki page outlines, but it's odd that it's being this difficult for me. I may just have to put it aside and try it again at a later date.
I have been reviewing the wiki page for the LTSP install. I am quite confused with the "Finishing the Install" section. It reads: ------------------------------------------------------------------------------ Some things still need to be done after building the environment. First up is the kernel, which needs to be put in your tftroot. In the default setup, this is copied from the chroot in /opt/ltsp and copied to the tftproot in an ltsp subdir in /var/lib/tftpboot, /tftpboot and /srv/tftp, if one exists. Calling ltsp-update-kernels with a different tftproot location: ltsp-update-kernels --tftpdirs="/opt/tftproot" Your pxelinux configuration has to be updated to reflect the changes in the setup. While you might want to use your previous kernel (if it has the necessary options), setting the nfs root is certainly needed. File: /opt/ltsp/tftproot/pxelinux.cfg/default kernel -kernel-YOURKERNELVERSION append initrd=initramfs-YOURKERNELVERSION root=/dev/nfs ip=dhcp nfsroot=YOURSERVERIP:/opt/ltsp/x86 ------------------------------------------------------------------------------ I see that the kernel needs to be copied from the chroot in /opt/ltsp to somewhere. Looking in /opt/ltsp/x86/boot, I see initramfs-genkernel-x86-2.6.31-gentoo-r6 and kernel-genkernel-x86-2.6.31-gentoo-r6. The wiki page says I need to copy the kernel and initramfs "the tftproot in an ltsp subdir in /var/lib/tftpboot, /tftpboot and /srv/tftp, if one exists". Is that merely saying "copy the kernel and initramfs to your tftp root (in my case /opt/ltsp/tftproot)? That is how I read it, but the listing of those three paths makes it confusing to me. But then I call ltsp-update-kernels with my ftproot location. What does this step do? Does it modify the kernel or initramfs? When I do run it (as root), I get the following output: --------------------------------------------------------------------------- /opt/ltsp>sudo ltsp-update-kernels --tftpdirs="/opt/ltsp/tftproot" Password: Updating /opt/ltsp/tftproot directories for chroot: /opt/ltsp/x86 Skipping invalid chroot: /opt/ltsp/tftproot --------------------------------------------------------------------------- I'm not sure why it thinks that /opt/ltsp/tftproot (the tftp root directory) would be a chroot. How can I check to see that the ltsp-update-kernels did what it was supposed to do? The terminals fail the same way whether I run it or not. I also found that even before the device probe there's a message from IP config that complains that the network is not available (even though it was able to load the kernel and, presumably, the initramfs files. I have tried this on stations with 3C95x and RTL network cards which work well with LTSP 4.2.
I'm guessing that most people who are having success with LTSP-5 under Gentoo are following the direction in the wiki (http://en.gentoo-wiki.com/wiki/LTSP)? I've started using dnsmasq and atftp as the page recommends and have followed the directions exactly, I believe. However, right off the bat I can see that the pxelinux.cfg/default file is located but it contains an error. Would anyone who has successfully gotten LTSP 5 working under Gentoo be willing to help me with this via email?
Changed the /opt/ltsp/tftproot paths in the wiki to /var/lib/tftpboot.
Created attachment 220349 [details] New source URI for sys-apps/quickstart Tried to install ltsp-server and during emerge of sys-apps/quickstart-9999 from the ltsp overlay I got the error: * subversion check out start --> * repository: http://agaffney.org/repos/quickstart/trunk svn: OPTIONS of 'http://agaffney.org/repos/quickstart/trunk': could not connect to server (http://agaffney.org) * ERROR: sys-apps/quickstart-9999 failed: * subversion: can't fetch to /usr/portage/distfiles/svn-src/quickstart/trunk from http://agaffney.org/repos/quickstart/trunk. I reported this to the maintainer of sys-apps/quickstart-9999 and he replied: > The quickstart repo is now located at git://git.agaffney.org/quickstart.git. > Please file a bug with the ltsp maintainer. I attached my new quickstart-9999.ebuild.
(In reply to comment #67) > I attached my new quickstart-9999.ebuild. Thanks, committed it. What to do about the 0.6 version is on my todo list.
Created attachment 220833 [details, diff] Patch for typo in profile.qs On my next try to build the ltsp chroot I got the error: ltsp-build-client --purge-chroot Default Quickstart profile: /etc/ltsp/quickstart/profile.qs Installing into: /opt/ltsp/x86 /etc/ltsp/quickstart/profile.qs: line 140: syntax error near unexpected token `}' /etc/ltsp/quickstart/profile.qs: line 140: `}' This was caused by space characters ahead of an EOF mark instead of the required tabs in line 76.
Tried to load a config file with ltsp-build-client and got error: ltsp-build-client --config=/etc/ltsp/ltsp-build-client.conf /usr/sbin/ltsp-build-client: line 181: option_tc/ltspltsp_build_client.conf_value=true: No such file or directory (By the way: The man page names the option as "--conf" but the script requires "--config".) I had to change "false" to "true" in line 3 of /usr/share/ltsp/plugins/ltsp-build-client/common/001-load-configuration-file: add_option "config" "`eval_gettext "load a user specific configuration file"`" "advanced" "false" for loading the config file.
I just updated my overlay early this morning and tried rebuilding the client, but it fails with the error: * Building kernel spawn_chroot(): wrapping command 'emerge gentoo-sources' in chroot script spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' !!! /etc/make.profile is not a symlink and will probably prevent most merges. !!! It should point into a profile within /usr/portage/profiles/ !!! (You can safely ignore this message when syncing. It's harmless.) !!! If you have just changed your profile configuration, you should revert !!! back to the previous configuration. Due to your current profile being !!! invalid, allowed actions are limited to --help, --info, --sync, and !!! --version. * could not emerge kernel sources * Cleaning up after install failure ... Looking at the install.log.failed file, I just see: Sat Feb 27 12:54:49 EST 2010: Building kernel Sat Feb 27 12:54:49 EST 2010: spawn_chroot(): wrapping command 'emerge gentoo-sources' in chroot script Sat Feb 27 12:54:49 EST 2010: spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' Sat Feb 27 12:54:50 EST 2010: Error: could not emerge kernel sources Sat Feb 27 12:54:50 EST 2010: Cleaning up after install failure Sat Feb 27 12:54:50 EST 2010: runstep(): executing pre-hook for failure_cleanup Sat Feb 27 12:54:50 EST 2010: spawn(): running command 'mv /tmp/install.log /tmp/install.log.failed' which is about the same thing.
Created attachment 221619 [details] Ebuild for the ltsp-docs package. I missed the lts.conf man page and as there was no ltsp-docs ebuild in the ltsp overlay wrote on by myself. For building the PDF manual it needs app-text/dblatex from bug 129368. As this installs its main binary as "docbook2latex" instead of "dblatex" to avoid collisions with other latex packages (on my machine dev-tex/tex4ht contains "/usr/bin/dblatex") I had to change "dblatex" in configure.in to "docbook2latex" (patch see next attachment).
Created attachment 221621 [details, diff] dblatex patch for ltsp-docs-5.2
I was puzzled by the fact that no matter what I configured in lts.conf the ldm always startet on vt1. So I looked through the startup scripts and found that changing the last line of /usr/share/ltsp/screen.d/ldm in the ltsp chroot (ltsp-client-5.2) from xinit $xinitrc /usr/sbin/ldm -- ${DISPLAY} vt${TTY} ... to xinit $xinitrc /usr/sbin/ldm -- ${DISPLAY} vt${SCREEN_NUM} ... fixed this for me. If I understand the scripts correctly the TTY variable is set through the line ". /usr/share/ltsp/screen-x-common" at the beginning of /usr/share/ltsp/screen.d/ldm by "TTY=$(fgconsole)". And at least in all my tests fgconsole returned "1" there. The $SCREEN_NUM is exported by /usr/share/ltsp/screen_session that lastly calls the /usr/share/ltsp/screen.d/ldm script.
Sound didn't work for me and I found this in /var/log/messages of the client: ... pulseaudio[xxxx]: main.c: Failed to create '/var/lib/pulse': Read-only file system The fix was to add /var/lib/pulse to rw_dirs in /etc/conf.d/ltsp-client-setup: rw_dirs="/var/lib/xkb /var/lib/pulse /var/log ..." and of course create the mount point in the chroot: mkdir /var/lib/pulse This mkdir should be done by a ltsp-build-client plugin like Debian/010-pulseaudio-tweaks.
I always got the warning WARNING: /var/cache/localapps does not exist on client boot. This is caused by ltsp-build-client creating /var/cache/ltsp-localapps/ but /etc/conf.d/ltsp-client-setup (of the client chroot) using /var/cache/localapps/.
(In reply to comment #75) > Sound didn't work for me ... Oh, forgot to mention that I also had to correct the wrong path for setfacl in /usr/share/ltsp/ltsp-init-common where /usr/bin/setfacl is used but sys-apps/acl-2.2.47 installs it as /bin/setfacl.
Fixed the quickstart profile syntax error upstream and in ltsp-server-5.2-r1. The newline at the end is generated somewhere else, it's not in the upstream code. A custom config file option fix is also committed upstream.
Tried "SYSLOG = remote" in lts.conf but it didn't work. Not even the /etc/syslog-ng/syslog-ng.conf file was created on the client. This is caused by the line . /usr/share/ltsp/ltsp-init-common in the start() function of /etc/init.d/ltsp-client-setup covering the definitions of the following local funtions in ltsp-client-setup: - load_modules() - configure_localdev() - configure_console() - configure_resolver() - configure_syslog() - configure_fstab() - bind_mounts() - bind_unmounts() - run_rcfiles() As ltsp-build-client installed syslog-ng and the ltsp-client-setup version of configure_syslog() uses /etc/syslog-ng/syslog-ng.conf I supposed that the local versions of these functions should be used and so removed their conterparts from /usr/share/ltsp/ltsp-init-common as none of them is used in another init.d-script. With these modifactions /etc/syslog-ng/syslog-ng.conf was created on the client but the syslog-ng daemon complained about a missing @version line in the config file assuming version 2.1 and it didn't log anything so I reworked the configure_syslog() function. I'll attach my patches below.
Created attachment 223611 [details, diff] Patch for /usr/share/ltsp/ltsp-init-common of net-misc/ltsp-client-5.2
Created attachment 223613 [details, diff] Patch for /etc/init.d/ltsp-client-setup of net-misc/ltsp-client-5.2
Created attachment 223709 [details, diff] Patch for /etc/init.d/ltsp-client-setup of net-misc/ltsp-client-5.2 Oh, should have checked my last improvement (asking syslog-ng about its version) before attaching the patch here: syslog-ng doesn't like "@version: 3.0.4" it wants "@version: 3.0". Fixed this in the new patch.
Created attachment 224267 [details, diff] Patch for /etc/init.d/ltsp-client-setup of net-misc/ltsp-client-5.2 Further improvement: Use /usr/share/doc/syslog-ng-${syslog_version}/syslog-ng.conf.gentoo.3.0.bz2 as a base syslog-ng.conf and then just add two lines for remote logging.
Tried to set XKBMODEL, XKBLAYOUT, XKBVARIANT and XKBOPTIONS in lts.conf but they weren't used because /usr/share/ltsp/xinitrc.d/I10-x-keyboard-settings did nothing as there was no /usr/bin/setxkbmap command in the chroot. I installed it and it works now but I think x11-apps/setxkbmap should be added to RDEPENDS in the ltsp-client ebuild.
Local devices (e.g. mounting an usb stick) did not work for me. Debugging as recommended in https://wiki.ubuntu.com/DebugLocalDev I passed all tests but the last one. Executing this on the client I got: ssh -X -S /var/run/ldm_socket_<ldm_pid>_<my_server_ip> <my_server_ip> "/usr/sbin/ltspfsmounter /tmp add" Couldn't read LTSPFS_TOKEN atom. Error: progarm not installed setuid root: Success (this typo ^^ is by the way in the code of /usr/bin/lbmount from sys-fs/ltspfs) So /usr/bin/lbmount wants to be installed setuid root. I changed that by hand. The other error was caused by a missing xprop command in the client chroot so that /usr/share/ltsp/xinitrc.d/I05-set-ltspfs_token couldn't run its xprop -root -f LTSPFS_TOKEN 8s -set LTSPFS_TOKEN $(cat $ltspfs_token) After emerging x11-apps/xprop in the client chroot mounting my usb stick works. So x11-apps/xprop should move from DEPEND to RDEPEND in ltsp-client-5.2.ebuild.
(In reply to comment #85) > So x11-apps/xprop should move from DEPEND to RDEPEND in ltsp-client-5.2.ebuild. To correct myself here: The right way certainly is RDEPEND="${DEPEND} ..."
(In reply to comment #76) > I always got the warning > WARNING: /var/cache/localapps does not exist > on client boot. > > This is caused by ltsp-build-client creating /var/cache/ltsp-localapps/ but > /etc/conf.d/ltsp-client-setup (of the client chroot) using > /var/cache/localapps/. > Didn't mention it above but I "fixed" this for me by a mv /var/cache/ltsp-localapps /var/cache/localapps in the chroot. This turned out to be the wrong way to "fix" it because now the ldm rc-script /usr/share/ldm/rc.d/X01-localapps can't write to it's LOCALAPPS_CACHE=/var/cache/ltsp-localapps causing the mount of user's home dir to fail. So I mv /var/cache/localapps /var/cache/ltsp-localapps moved the dir back, changed /var/cache/localapps to /var/cache/ltsp-localapps in /etc/conf.d/ltsp-client-setup and rebootet the thinclient. Now local apps work and can access my mounted home dir on the client. So the right bug fix is this change in /etc/conf.d/ltsp-client-setup of the net-misc/ltsp-client-5.2 package: 18c18 < copy_dirs="/root /home /etc/conf.d /etc/udev/rules.d /var/cache/localapps" --- > copy_dirs="/root /home /etc/conf.d /etc/udev/rules.d /var/cache/ltsp-localapps"
Created attachment 228869 [details, diff] Patch for /etc/init.d/ltsp-client-setup of net-misc/ltsp-client-5.2 Update to my ltsp-client-setup.patch: The sed command in configure_console() didn't expand the $CONSOLE_KEYMAP variable but replaced "us" by the string "${CONSOLE_KEYMAP}".
(In reply to comment #79) The functions in ltsp-init-common can be used by other distro's using ltsp. Those cannot be removed. Upstream fixes: - Removed the configure_syslog in the local one, setting ltsp-client up to use sysklogd by default. Made necessary changes in ltsp-client-setup.confd and quickstart profile, server logger needs to listen to udp also. - Removed configure_localdev,fstab,bind_unmounts from local init, they are the same in the common one. - Applied your configure_console sed line fix (renamed function to configure_keymap) - Called configure_resolver before ltsp-init-common is loaded, fixing hostname resolving. - Fixed localapps bindmount dir in client setup. All those will be available in 5.2.3.
(In reply to comment #74) Only to correct a typo here: > changing the last line of /usr/share/ltsp/screen.d/ldm in the ltsp chroot > (ltsp-client-5.2) from The file is not part of net-misc/ltsp-client but of x11-misc/ldm and I had to change the mentioned line (see comment #74) again after upgrading today: [ebuild U ] x11-misc/ldm-2.1.2 [2.0.50]
Hi Guys, I'm having the same problem even when the stage_uri is specified by two ways: one, in /etc/ltsp/ltsp-build-client.conf and also tried by parameter of the command (--stage-uri file://opt/ltsp-5/stages/stage4-pentium4-lambda-2009.0.tar.bz2) I always get: --- * you must specify a stage_uri --- error: LTSP client installation ended abnormally Any one have a clue why it fails? Thanks. (In reply to comment #59) > emerge ltsp-server > albatros2 stages # rm -rf /opt/ltsp/amd64/ && ltsp-build-client --dist Gentoo > --stage-uri file://opt/ltsp/stages/stage3-amd64-20100121.tar.bz2 > --quickstart-verbose > Default Quickstart profile: /etc/ltsp/quickstart/profile.qs > Installing into: /opt/ltsp/amd64 > * Sanity checking config > * you must specify a stage_uri > * kernel_sources not set...assuming gentoo-sources > * logging_daemon not set...assuming syslog-ng > * Sanity checking partition config for amd64 > * bootloader not set...assuming grub > error: LTSP client installation ended abnormally > > albatros2 stages # ls -l /opt/ltsp/stages/ > итого 262024 > -rw-r--r-- 1 root root 140939882 Янв 21 13:33 stage3-amd64-20100121.tar.bz2 > -rw-r--r-- 1 root root 127093186 Янв 19 22:26 stage3-i686-20100119.tar.bz2 > > Any ideas? >
(In reply to comment #91) > Any one have a clue why it fails? I think the syntax for options with values is --option=value and so the man page should be updated. Maybe older versions of ltsp-build-client used/allowed --option value too?
(In reply to comment #92) > (In reply to comment #91) > > Any one have a clue why it fails? > I think the syntax for options with values is > --option=value > and so the man page should be updated. > > Maybe older versions of ltsp-build-client used/allowed > --option value > too? > Hi, ltsp-build-client --quickstart-profile=/etc/ltsp/quickstart/profile.qs --stage-uri=http://www.fierro-soft.com.ar/downloads/linux/stage4-pentium4-lambda-2009.0.tar.bz2 --quickstart-debug --quickstart-verbose --- * you must specify a stage_uri --- And in: /etc/ltsp/ltsp-build-client.conf STAGE_URI=http://www.fierro-soft.com.ar/downloads/linux/stage4-pentium4-lambda-2009.0.tar.bz2 --- * you must specify a stage_uri --- The same problem...
(In reply to comment #93) I can't reproduce this. Even with option --stage-uri http://... it works here. So my guess in comment #92 was wrong. Maybe we have different versions of ltsp packages? I have net-misc/ltsp-server-5.2.2 sys-fs/ltspfs-0.6 sys-apps/quickstart-9999 where the quickstart source is from the git repository git://git.agaffney.org/quickstart.git * at the commit: f637367a5c1c0ccc109d3db5671877df61ec092a * branch: master according to the installation log. I suspect quickstart as your error message "you must specify a stage_uri" comes from its /usr/share/quickstart/modules/config.sh module.
(In reply to comment #94) > Maybe we have different versions of ltsp packages? I have I have exactly version like you, and also reinstalled again to obtain latest from git. Still i have that problem. > > I suspect quickstart as your error message "you must specify a stage_uri" comes > from its /usr/share/quickstart/modules/config.sh module. > I will have to dig...
Attaching the install.log: http://pastebin.com/F6uTDCke
Now, i've assigned manually in config.sh the variable stage_uri and I don't have that error anymore, but another: http://pastebin.com/N5e7tARv Any tip?
(In reply to comment #97) > Now, i've assigned manually in config.sh the variable stage_uri and I don't > have that error anymore, but another: http://pastebin.com/N5e7tARv > Any tip? > Finally I've found why Gustavo was having this errors. The problem are using "es_AR" as locale and with that locale, a core function of quickstart, "isafunc" doesn't works. The bug is on /usr/share/quickstart/modules/stepcontrol.sh, line 6: "if [ -n "$(type ${func} 2>/dev/null | grep "function")" ]; then" . In spanish, type returns "es una función", so grep doesn't works. Unfortunately, I didn't found how to patch the function. But using "en_US" locale, ltsp-build-client worked fine.
after ltsp-build-client stopped with "no stage_uri" (or something) i followed the manual howto without unionfs on http://flowledge.nl/gentoo/ltsp/. Now my thinclient loads the kernel but stops while trying to write to the root-fs but its read-only. This is my whole /etc/fstab: shm /dev/shm tmpfs nodev,nosuid,noexec 0 0 Do i need unionfs??
(In reply to comment #99) > Do i need unionfs?? > Use the "official" install guide at http://en.gentoo-wiki.com/wiki/LTSP. By default bind_mounts are used instead of unionfs.
(In reply to comment #100) > Use the "official" install guide at http://en.gentoo-wiki.com/wiki/LTSP. By > default bind_mounts are used instead of unionfs. > ok, but ltsp-build-client doesnt work (x86 & amd64). client is now booting but i have no '/usr/share/ltsp/ltsp-init-common' although net-misc/ltsp-client-5.2 is installed. i think thats the reason for the following output on the thinclient at startup: remounting root fs read/write Skipping /etc/mtab initialization (ro root?) you must be root to do this skip missing mtab no such file trying open /dev/ROOT /dev/BOOT cant create lock file Full text here: http://forums.gentoo.org/viewtopic-p-6361057.html#6361057
(In reply to comment #101) where can i get '/usr/share/ltsp/ltsp-init-common'?
i use a fresh installation with kernel-2.6.34-gentoo-r1, x86, changed my locale to en_US, now ltsp-build-client stops with: 2010-07-24 21:39:57 (357 KB/s) - `/opt/ltsp/x86/stage3-i486-20100622.tar.bz2' saved [135444026/135444026] fetch_http_https_ftp(): exit code from wget was 0 spawn(): running command 'tar -C /opt/ltsp/x86 -xjpf /opt/ltsp/x86/stage3-i486-20100622.tar.bz2' runstep(): executing post-hook for unpack_stage_tarball * Preparing chroot prepare_chroot(): copying /etc/resolv.conf into chroot spawn(): running command 'cp /etc/resolv.conf /opt/ltsp/x86/etc/resolv.conf' prepare_chroot(): mounting proc spawn(): running command 'mount -t proc none /opt/ltsp/x86/proc' prepare_chroot(): bind-mounting /dev spawn(): running command 'mount -o bind /dev /opt/ltsp/x86/dev' prepare_chroot(): bind-mounting /sys spawn(): running command 'mount -o bind /sys /opt/ltsp/x86/sys' * Installing portage tree runstep(): executing pre-hook for install_portage_tree spawn(): running command 'mkdir /opt/ltsp/x86/usr/portage' spawn(): running command 'mount /usr/portage /opt/ltsp/x86/usr/portage -o bind' spawn(): running command 'mkdir -p /usr/portage/packages/x86' spawn_chroot(): wrapping command 'mkdir -p /usr/portage/packages' in chroot script spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' spawn(): running command 'mount /usr/portage/packages/x86 /opt/ltsp/x86/usr/portage/packages -o bind' spawn(): running command 'mkdir /opt/ltsp/x86/usr/local/portage' spawn(): running command 'mount /usr/local/portage /opt/ltsp/x86/usr/local/portage -o bind' mount: special device /usr/local/portage does not exist spawn(): running command 'mkdir -p /opt/ltsp/x86/etc/portage/package.keywords' install_portage_tree(): tree_type is none * 'none' specified...skipping * Setting root password spawn_chroot(): wrapping command 'echo 'root:password' | chpasswd -m' in chroot script spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' * Setting timezone runstep(): executing pre-hook for set_timezone spawn(): running command 'rm /opt/ltsp/x86/etc/localtime' spawn(): running command 'cp /opt/ltsp/x86/usr/share/zoneinfo/Europe/Berlin /opt/ltsp/x86/etc/localtime' spawn(): running command '/bin/sed -i 's:#TIMEZONE="Factory":TIMEZONE="Europe/Berlin":' /opt/ltsp/x86/etc/conf.d/clock' * Building kernel runstep(): executing pre-hook for build_kernel spawn_chroot(): wrapping command 'emerge portage' in chroot script spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' [Errno 2] No such file or directory: '/usr/local/portage/layman/make.conf' in /etc/make.conf spawn_chroot(): wrapping command 'emerge gentoo-sources' in chroot script spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' [Errno 2] No such file or directory: '/usr/local/portage/layman/make.conf' in /etc/make.conf * could not emerge kernel sources * Cleaning up after install failure runstep(): executing pre-hook for failure_cleanup spawn(): running command 'mv /tmp/install.log /tmp/install.log.failed' spawn(): running command 'umount /opt/ltsp/x86/usr/portage/packages' spawn(): running command 'umount /opt/ltsp/x86/usr/portage' spawn(): running command 'umount /opt/ltsp/x86/usr/local/portage' umount: /opt/ltsp/x86/usr/local/portage: not mounted * could not unmount /opt/ltsp/x86/usr/local/portage spawn(): running command 'umount /opt/ltsp/x86/sys' spawn(): running command 'umount /opt/ltsp/x86/proc' spawn(): running command 'umount /opt/ltsp/x86/dev' error: LTSP client installation ended abnormally
(In reply to comment #103) > [Errno 2] No such file or directory: '/usr/local/portage/layman/make.conf' in > /etc/make.conf > spawn_chroot(): wrapping command 'emerge gentoo-sources' in chroot script > spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' > [Errno 2] No such file or directory: '/usr/local/portage/layman/make.conf' in > /etc/make.conf > * could not emerge kernel sources ok, layman moved from '/usr/local/portage/' to '/var/lib/' or what?
ltsp-build-client: the script doesnt recognize method 'file://' for STAGE_URI. i used gentoo stages but besides i found out that funtoo stages are now in tar.xz format what the script doesnt like. (tar xJf for tar.xz) i got: 'Invalid PORTDIR_OVERLAY (not a dir): '/var/lib/layman/ltsp'' so i copied the folder /var/lib/layman to /usr/local/portage/ or was it vice versa?? after kernel kompilation i got something like 'couldnt emerge lvm', i think because its masked(x86). not shure but i think the howto doesnt contain the possibility to build a x86 client on amd64.
ltsp-5.2.3 is in the tree. Also patched for new layman default storage dir.
(In reply to comment #98) The problems were all related to the language issue I think. I sent this fix to the maintainer of quickstart: /usr/share/quickstart/modules/stepcontrol.php if [ -n "$(type ${func} 2>/dev/null | grep "function")" ]; then becomes if [ $(command -v ${func}) ]; then
ltsp-server-5.2.3-r1 doesn't emerge with useflag nfs due to a block (see below) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. ('ebuild', '/', 'net-nds/portmap-6.0', 'merge') pulled in by net-nds/portmap required by ('ebuild', '/', 'net-misc/ltsp-server-5.2.3-r1', 'merge') ('installed', '/', 'net-fs/nfs-utils-1.2.2-r2', 'nomerge') pulled in by net-fs/nfs-utils required by ('ebuild', '/', 'net-misc/ltsp-server-5.2.3-r1', 'merge') hmm... do we need both? thank you for your overlay! markus
Hello, i tried ltsp-server-5.2.3-r1 with locale en_US, stopped with: stage_uri=file:///opt/ltsp/x86/stages/stage3-i486-20100622.tar.bz2 ... install_portage_tree(): tree_type is none * 'none' specified...skipping ... runstep(): executing pre-hook for build_kernel spawn_chroot(): wrapping command 'emerge portage' in chroot script spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' [Errno 2] No such file or directory: '/var/lib/layman/make.conf' in /etc/make.conf spawn_chroot(): wrapping command 'emerge gentoo-sources' in chroot script spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' [Errno 2] No such file or directory: '/var/lib/layman/make.conf' in /etc/make.conf * could not emerge kernel sources Do i need another stagefile?
(In reply to comment #108) nfs-utils-1.2.2-r2 is still unstable on x86 and amd64, so I won't make changes to the ltsp-server ebuild just yet. And no, I don't think you need both, only nfs-utils will do. (In reply to comment #109) Looks like you don't have your layman storage at /var/lib/layman (the layman 1.3 default). Just make a symlink from your layman makefile to /var/lib/layman/make.conf.
ltsp-5.2.4 is in the tree.
(In reply to comment #110) /var/lib/layman/make.conf is present
(In reply to comment #112) i changed in "/etc/ltsp/quickstart/profile.qs" pre_build_kernel() { # FIXME: upgrade to porage 2.2 to resolve blockers since 2008.0 spawn_chroot "emerge portage" to pre_build_kernel() { # FIXME: upgrade to porage 2.2 to resolve blockers since 2008.0 spawn_chroot "mkdir -p /var/lib/layman/ltsp" spawn "cp /var/lib/layman/make.conf ${chroot_dir}/var/lib/layman/" spawn_chroot "emerge portage" now the script solved this step and is compiling the kernel while am writing this comment...
(In reply to comment #113) > (In reply to comment #112) > > now the script solved this step and is compiling the kernel while am writing > this comment... > and now stopped with: spawn_chroot(): wrapping command 'emerge ldm ltsp-client' in chroot script spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' /etc/profile.env: line 12: warning: setlocale: LC_CTYPE: cannot change locale (de_DE.iso885915@euro) Calculating dependencies... done! emerge: there are no ebuilds to satisfy "ldm". * could not emerge extra packages
in the howto in section 'Finishing the Install' the location of pxelinux.cfg/default is '/opt/ltsp/tftproot/' but in section 'DHCP' it reads 'tftp-root=/var/lib/tftpboot' (in /etc/dnsmasq.conf). so i had to change '/var/lib/tftpboot/pxelinux.cfg/default'
Manfred, I have the same issue with emerging ldm. Since I'm using ltsp git repository to emerge ltsp, it looks like chroot /opt/ltsp cannot "see" ltsp repository which is under /var/lib/layman/ltsp directory - cannot see ebuil files. I tried to play with quickstar profile, to emerge layman before extra packages, but couldn't sync ltsp repository as I had to use the trick from comment #113. So, chroot cannot see my $PORTDIR_OVERLAY and that's the place where ebuilds for ldm are. Any ideas?
(In reply to comment #116) > Any ideas? You have to remount them under the chroot. Before emerging in the chroot I call: mount -t proc proc /opt/ltsp/x86/proc mount --bind /dev /opt/ltsp/x86/dev mount --bind /usr/portage /opt/ltsp/x86/usr/portage mount --bind /var/lib/layman /opt/ltsp/x86/var/lib/layman When the work is done I unmount them again.
(In reply to comment #117) Patched for proper bind mounts in ltsp-server-5.2.4-r1
Horst, Wim, thaks for very quick response, client installation went OK.
(In reply to comment #111) > ltsp-5.2.4 is in the tree. > Just updated to net-misc/ltsp-client-5.2.4 and first thought it's broken because no ldm login screen appeared, I only saw the boot messages. But then I found that these lines in /usr/share/ltsp/screen_session: # Wait until this is the active vt before launching the screen script while [ $(fgconsole) -ne ${SCREEN_NUM} ]; do sleep 2 done combined with my SCREEN setup in lts.conf (SCREEN_01 is undefined!): SCREEN_02 = shell SCREEN_03 = shell SCREEN_04 = shell SCREEN_05 = shell SCREEN_06 = shell SCREEN_07 = ldm caused the client to stay on vt1 (showing the boot messages). As soon as I switched to say vt7 by CTRL-ALT-F7 the ldm starts up there and finally showed the login screen as expected. The same holds for the shells on vt2 to vt6. To determine the initial active screen after boot I added START_SCREEN = 07 to my lts.conf and changed /usr/share/ltsp/screen_session to: while [ ${SCREEN_NUM} -ne ${START_SCREEN} ] && \ [ $(fgconsole) -ne ${SCREEN_NUM} ]; do sleep 2 done
I have a working installation of gentoo LTSP 5 for about 50 terminals. During an update of the client system (emerge -auvDN world on the chrooted system) my Xorg was upgraded from 1.6.5 to 1.7.7. Everything was fine, except that whenever I type something like '192' on the keyboard, the client xorg server gets resetted. It happens in every condition, even in the ldm login screen. I also tried to use masked xorg-server 1.8.2 but the results are the same. Is this happening to anyone? Thank you
(In reply to comment #121) > I have a working installation of gentoo LTSP 5 for about 50 terminals. > During an update of the client system (emerge -auvDN world on the chrooted > system) my Xorg was upgraded from 1.6.5 to 1.7.7. Everything was fine, except > that whenever I type something like '192' on the keyboard, the client xorg > server gets resetted. It happens in every condition, even in the ldm login > screen. > I also tried to use masked xorg-server 1.8.2 but the results are the same. > Is this happening to anyone? > Yes, almost the same here. I have the same problem but with other keyboard combination (a letter followed by three numbers). In ldm login I can't reproduce it. I have the same problem on several terminals and using ldm or xdmcp for login. Xorg 1.7.7 - ltsp-client-5.2.4
(In reply to comment #122) > (In reply to comment #121) > > I have a working installation of gentoo LTSP 5 for about 50 terminals. > > During an update of the client system (emerge -auvDN world on the chrooted > > system) my Xorg was upgraded from 1.6.5 to 1.7.7. Everything was fine, except > > that whenever I type something like '192' on the keyboard, the client xorg > > server gets resetted. It happens in every condition, even in the ldm login > > screen. > > I also tried to use masked xorg-server 1.8.2 but the results are the same. > > Is this happening to anyone? > > > > Yes, almost the same here. I have the same problem but with other keyboard > combination (a letter followed by three numbers). In ldm login I can't > reproduce it. > > I have the same problem on several terminals and using ldm or xdmcp for login. > > Xorg 1.7.7 - ltsp-client-5.2.4 > In my case the problem was caused by both a console and the X server both starting on the same terminal /dev/tty1. Then key-presses were sent to both and certain key-presses "9" and "(" caused the X server to restart. I solved it by editing /opt/ltsp/x86/usr/share/ltsp/screen.d/ldm and changing the very last line as below FROM #xinit $xinitrc /usr/sbin/ldm -- ${DISPLAY} vt${TTY} -auth ${XAUTHORITY} ${X_ARGS} -br >/dev/null 2>&1 TO xinit $xinitrc /usr/sbin/ldm -- ${DISPLAY} vt7 -auth ${XAUTHORITY} ${X_ARGS} -br >/dev/null 2>&1 It is not elegant and I am sure there must be a proper way of getting the correct value into ${TTY}.
(In reply to comment #123) > In my case the problem was caused by both a console and the X server both > starting on the same terminal /dev/tty1. Then key-presses were sent to both > and certain key-presses "9" and "(" caused the X server to restart. > > I solved it by editing /opt/ltsp/x86/usr/share/ltsp/screen.d/ldm and changing > the very last line as below > > FROM > #xinit $xinitrc /usr/sbin/ldm -- ${DISPLAY} vt${TTY} -auth ${XAUTHORITY} > ${X_ARGS} -br >/dev/null 2>&1 > > TO > xinit $xinitrc /usr/sbin/ldm -- ${DISPLAY} vt7 -auth ${XAUTHORITY} ${X_ARGS} > -br >/dev/null 2>&1 > > It is not elegant and I am sure there must be a proper way of getting the > correct value into ${TTY}. > I had a similar workaround in ltsp-client-5.2 (see comment #74 above) but since ltsp-client-5.2.4 I use an unchanged /opt/ltsp/x86/usr/share/ltsp/screen.d/ldm and a new variable START_SCREEN to determine the initial active screen after boot (see comment #120 above).
(In reply to comment #124) Thank you. Now the X server works perfectly. I have now another question about local devices. I was trying to integrate in some way the insertion and removal of usb sticks and cdrom in kde4, so I found on the web that there should have been a directory /etc/ltspfs/mounter.d on the ltsp server, but it is not the case. So I manually created the directory, I put a python script inside it and magically it worked: I can now write my custom integration scripts handling the add/remove events. These scripts are ran from /usr/sbin/ltspfsmounter on the ltsp server. USB sticks work perfectly, but cdroms not so much: the first time a cdrom is inserted into the drive, cdpinger finds and mounts it, but after 2-3 sec the links /dev/cdrom, /dev/dvd, /dev/cdrw that points to the actual device /dev/sr0, are removed, resulting in the cdpinger syslog message: "Device %s disappeared. Exiting". My question is: anybody knows who is actually removing my links? The strange thing is that if I manually recreate the link and restart cdpinger on the client, cdrom works fine. Thank you!
(In reply to comment #125) I did some debugging and I found that udev was removing my symlinks. I then managed to get my cdrom working by adding "udevadm control --reload-rules" in /etc/conf.d/local.start of the ltsp server. Are you experimenting the same issue? Thank you
(In reply to comment #126) sorry... it was /etc/conf.d/local.start of the chrooted environment
(In reply to comment #120) No solution as of yet, my workaround is to put SCREEN_01 = ldm in the lts.conf. Issued a bugreport upstream (https://bugs.launchpad.net/ltsp/+bug/687296), feel free to comment further there.
Hi guys, today I was trying to build the client on latest LTSP and I got this: http://pastebin.com/3uDizxi4 Any tip? Thanks.
(In reply to comment #129) I got the same error, apparently the python3.1 interpreter is selected by default, resulting in the bzr compile fail. Posted a separate bug for the problem (http://bugs.gentoo.org/show_bug.cgi?id=350148). You can set the 2.6 version in the quickstart profile (http://en.gentoo-wiki.com/wiki/LTSP#Known_Issues).
(In reply to comment #130) > (In reply to comment #129) > I got the same error, apparently the python3.1 interpreter is selected by > default, resulting in the bzr compile fail. Posted a separate bug for the > problem (http://bugs.gentoo.org/show_bug.cgi?id=350148). > > You can set the 2.6 version in the quickstart profile > (http://en.gentoo-wiki.com/wiki/LTSP#Known_Issues). > I was thinking that, after reading that Python3.x were used as interpreter. Thanks, I will try :)
After upgrading from ldm-2.1.3 to ldm-2.2, the LDM_SESSION (fluxbox) from lts.conf does not start. Instead I log into tvm (https://bugs.launchpad.net/ltsp/+bug/689381). Anyone else got this issue?
(In reply to comment #132) > Anyone else got this issue? Not exactly the same since I don't use LDM_SESSION. In my case after upgrading to x11-misc/ldm-2.2 [2.1.3] net-misc/ltsp-client-5.2.5 [5.2.4] ldm didn't start at all. The thinclient stayed on vt1 with the final message: no more processes left in this runlevel (Note that I have this in lts.conf: SCREEN_02 = shell SCREEN_03 = shell SCREEN_04 = shell SCREEN_05 = shell SCREEN_06 = shell SCREEN_07 = ldm START_SCREEN = 07 ) But switching to vt7 by ctrl-alt-f7 started ldm. This was caused by ltsp-client-5.2.5 overwriting my changes from comment #74 in /usr/share/ltsp/screen.d/ldm and from comment #120 in /usr/share/ltsp/screen_session After reapplying these changes the thinclient switches to vt7 and ldm starts.
Hi! Since some months i didn't installed LTSP5 in Gentoo. Now, in a new server i have new problems and i cant figure out where is the source of that. The terminal boots ok, loads the kernel but when it tries to mount devs, it says that is on read only file system: http://img688.imageshack.us/img688/9297/ltsp5gentoo.png (this continues). What could be the problems? (using latest LTSP an rechecked the howto if missing something) I don't know if this is a new bug. Thanks in advance. Cheers.
(In reply to comment #134) > Hi! > > Since some months i didn't installed LTSP5 in Gentoo. Now, in a new server i > have new problems and i cant figure out where is the source of that. The > terminal boots ok, loads the kernel but when it tries to mount devs, it says > that is on read only file system: > http://img688.imageshack.us/img688/9297/ltsp5gentoo.png (this continues). > What could be the problems? (using latest LTSP an rechecked the howto if > missing something) > I don't know if this is a new bug. > > Thanks in advance. > > Cheers. > Ok, diggin a little bit more, I've rebuild the client again and I saw that chroot/etc/conf.d/ltsp-client-setup and chroot/init.d/ltsp-client-setup does not exist! Which that means this could be the problem. It is a bug? Cheers.
(In reply to comment #134) > but when it tries to mount devs, it says that is on read only file system: > http://img688.imageshack.us/img688/9297/ltsp5gentoo.png (this continues). Note: Better write down the error messages here as your uploaded image will vanish some day and then nobody knows what it's all about. As the first error in your image says: can't create lock file /etc/mtab~9792: Read-only file system ... i guess that your ltsp-build-client run didn't create the /etc/mtab -> /proc/mounts symlink. On my system this symlink was created by /etc/ltsp/quickstart/profile.qs from sys-apps/quickstart-9999 and it's ebuild fetches newer versions from a git repo. And as the ebuild's version never raises quickstart will not be updated by an "emerge -DuN world". Maybe your quickstart is too old and not compatible with the new ltsp-server package? If that's right an update of quickstart (by rebuilding it, as an "emerge -u" would do nothing since you already have version 9999): emerge quickstart and then rebuild the client chroot should help.
(In reply to comment #136) > (In reply to comment #134) > > but when it tries to mount devs, it says that is on read only file system: > > http://img688.imageshack.us/img688/9297/ltsp5gentoo.png (this continues). > Note: Better write down the error messages here as your uploaded image will > vanish some day and then nobody knows what it's all about. > > As the first error in your image says: > can't create lock file /etc/mtab~9792: Read-only file system ... > i guess that your ltsp-build-client run didn't create the > /etc/mtab -> /proc/mounts > symlink. On my system this symlink was created by > /etc/ltsp/quickstart/profile.qs > from sys-apps/quickstart-9999 and it's ebuild fetches newer versions from a git > repo. And as the ebuild's version never raises quickstart will not be updated > by an "emerge -DuN world". Maybe your quickstart is too old and not compatible > with the new ltsp-server package? > > If that's right an update of quickstart (by rebuilding it, as an "emerge -u" > would do nothing since you already have version 9999): > emerge quickstart > and then rebuild the client chroot should help. > Yes, I was diggin there before reading this post so I've copied a more updated profile and now I am building the Client. For sure that was the problem. Will see.. Thanks!
(In reply to comment #137) Hi again. I've re-installed again LTSP and Quickstart to catch newest profile. Now i have another problem at the end of LTSP client install: runstep(): executing post-hook for install_extra_packages spawn(): running command 'ln -sf /proc/mounts /opt/ltsp/x86/etc/mtab' spawn_chroot(): wrapping command 'dbus-uuidgen --ensure' in chroot script spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' /var/tmp/spawn.sh: line 2: dbus-uuidgen: command not found * Adding and removing services spawn_chroot(): wrapping command 'rc-update add ltsp-client-setup boot' in chroot script spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' * ltsp-client-setup added to runlevel boot spawn_chroot(): wrapping command 'rc-update add ltsp-client default' in chroot script spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' * ltsp-client added to runlevel default spawn_chroot(): wrapping command 'rc-update add hald default' in chroot script spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' * rc-update: '/etc/init.d/hald' not found; aborting * could not add service hald to the default runlevel * Cleaning up after install failure runstep(): executing pre-hook for failure_cleanup spawn(): running command 'mv /tmp/install.log /tmp/install.log.failed' spawn(): running command 'umount /opt/ltsp/x86/var/lib/layman' spawn(): running command 'umount /opt/ltsp/x86/usr/portage/packages' spawn(): running command 'umount /opt/ltsp/x86/usr/portage' spawn(): running command 'umount /opt/ltsp/x86/sys' spawn(): running command 'umount /opt/ltsp/x86/proc' spawn(): running command 'umount /opt/ltsp/x86/dev' error: LTSP client installation ended abnormally It seems that /etc/init.d/hald does not exist...
(In reply to comment #138) I had to add "hal openssh" to PACKAGES variable in /etc/ltsp/ltsp-build-client.conf to work. After the missing hal, also openssh was missing which gave me and error trying to add ssh to default runlevel. After this, LTSP client was build correctly. Now i will test if works... Cheers. > (In reply to comment #137) > > Hi again. I've re-installed again LTSP and Quickstart to catch newest profile. > Now i have another problem at the end of LTSP client install: > > runstep(): executing post-hook for install_extra_packages > spawn(): running command 'ln -sf /proc/mounts /opt/ltsp/x86/etc/mtab' > spawn_chroot(): wrapping command 'dbus-uuidgen --ensure' in chroot script > spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' > /var/tmp/spawn.sh: line 2: dbus-uuidgen: command not found > * Adding and removing services > spawn_chroot(): wrapping command 'rc-update add ltsp-client-setup boot' in > chroot script > spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' > * ltsp-client-setup added to runlevel boot > spawn_chroot(): wrapping command 'rc-update add ltsp-client default' in chroot > script > spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' > * ltsp-client added to runlevel default > spawn_chroot(): wrapping command 'rc-update add hald default' in chroot script > spawn(): running command 'linux32 chroot /opt/ltsp/x86 /var/tmp/spawn.sh' > * rc-update: '/etc/init.d/hald' not found; aborting > * could not add service hald to the default runlevel > * Cleaning up after install failure > runstep(): executing pre-hook for failure_cleanup > spawn(): running command 'mv /tmp/install.log /tmp/install.log.failed' > spawn(): running command 'umount /opt/ltsp/x86/var/lib/layman' > spawn(): running command 'umount /opt/ltsp/x86/usr/portage/packages' > spawn(): running command 'umount /opt/ltsp/x86/usr/portage' > spawn(): running command 'umount /opt/ltsp/x86/sys' > spawn(): running command 'umount /opt/ltsp/x86/proc' > spawn(): running command 'umount /opt/ltsp/x86/dev' > error: LTSP client installation ended abnormally > > It seems that /etc/init.d/hald does not exist... >
Ok guys, I've the same problem as which I reported on #134 about "Read-only file system". :(
(In reply to comment #140) > Ok guys, I've the same problem as which I reported on #134 about "Read-only > file system". :( > Uff, this is a nightmare. I had to modify the exports file to rw to make it work: /opt/ltsp *(rw,no_root_squash,async,no_subtree_check) When I always used ro in last LTSP installations. Now it get stuck trying to start eth0 device: "Starting eth0..." And does not continue....
(In reply to comment #141) > (In reply to comment #140) > > Ok guys, I've the same problem as which I reported on #134 about "Read-only > > file system". :( > > > > Uff, this is a nightmare. I had to modify the exports file to rw to make it > work: > > /opt/ltsp *(rw,no_root_squash,async,no_subtree_check) > > When I always used ro in last LTSP installations. > > Now it get stuck trying to start eth0 device: > > "Starting eth0..." > > And does not continue.... > Ok... now I’ve chrooted LTSP, deleted net.eth0 symlink and it continues. Still no LDM login. Now if I reboot the client, again I have many errors complaining Read-only filesystem...
(In reply to comment #141) > Uff, this is a nightmare. I had to modify the exports file to rw to make it > work: > > /opt/ltsp *(rw,no_root_squash,async,no_subtree_check) That's not the correct solution. If you have a similar "Read-only file system" problem than me in comment #75 the fix is to add the offending directory path to rw_dirs in /etc/conf.d/ltsp-client-setup.
(In reply to comment #143) > (In reply to comment #141) > > Uff, this is a nightmare. I had to modify the exports file to rw to make it > > work: > > > > /opt/ltsp *(rw,no_root_squash,async,no_subtree_check) > That's not the correct solution. If you have a similar "Read-only file system" > problem than me in comment #75 the fix is to add the offending directory path > to rw_dirs in /etc/conf.d/ltsp-client-setup. > I know that is not a correct solution. Anyway does not work "right" either... I don’t know what else to check. I will have to reinstall everything again as last choice...
Created attachment 265749 [details] ltsp-client-core data directory of the ubuntu package tarball containing ltsp-remoteapps* scripts
Hello. I would like to share my experience with ltsp-remoteapps. ltsp-remoteapps is a really exciting feature that allows user to run server apps from a client session. It is very useful, for example, when you want to run firefox locally: browsing the web it happens that you need to open some pdf or some other file, so you have two cases: 1) you have the needed application on the client or 2) you need to call back the application from the terminal server. I did not find ltsp-remoteapps in any version of gentoo ltsp, so I decided to download an ubuntu ltsp-client package (attachment) and extract from there necessary scripts. In particular, there are three files: ltsp-remoteappsd, ltsp-remoteapps and X51-remoteapps. In order to get remote apps working you have to follow these steps: 1) copy ltsp-remoteappsd in /usr/share/ltsp of the chrooted environment 2) copy X51-remoteapps in /usr/share/ldm/rc.d of the chrooted environment 3) copy ltsp-remoteapps in /usr/bin 4) add to your lts.conf the key REMOTE_APPS=True. These simple steps will allow you to have remote apps working on gentoo ltsp: to try it, just try launching a local xterm (ltsp-localapps xterm) and then try to execute for example ltsp-remoteapps ooffice. Once you are sure remote apps are working, you can configure firefox to run remote applications for opening files. For these steps I make use of one KDE4 executable. 1) you need to have a shared /tmp directory between ltsp client and ltsp server: firefox puts there temporarily downloaded file. I shared /tmp with nfs from the server. I also tried to avoid the sharing of /tmp, launching firefox with the environmental variable TMP set to something like ~/.firefox_tmp. But this does not work because the home directory is mounted via sshfs to the client and firefox tries to create some sockets in the temporary folder. Sockets, as far as I know, are not supported by sshfs. 2) create an "application wrapper" script in /usr/bin of the chrooted environment. The content of the script should be: ltsp-remoteapps kioclient exec $@ 3) chmod +x the script 4) modify /etc/mailcap of the chrooted environment accordingly I hope this will help someone.
Just tried an update world on my LTSP Server and got: !!! The following update has been skipped due to unsatisfied dependencies: net-misc/ltsp-server:0 emerge: there are no ebuilds to satisfy ">net-fs/nfs-utils-1.5". (dependency required by "net-misc/ltsp-server-5.2.6[nfs]" [ebuild]) I think this is an typo in the ebuild and it should say ">net-fs/nfs-utils-1.1.5" as there is no version 1.5 of nfs-utils in the tree.
(In reply to comment #147) > I think this is an typo in the ebuild and it should say > ">net-fs/nfs-utils-1.1.5" as there is no version 1.5 of nfs-utils in the tree. Terribly sorry about that. Just pushed the proper changes.
Made a ltsp-server-5.2.6-r1 with some needed quickstart plugin fixes.
I have some ThinClients that need CONFIGURE_X = Y X_MODE_0 = 1600x1200 in lts.conf to start X with the correct resolution. But after updating ltsp-client: [ebuild U ] net-misc/ltsp-client-5.2.6 [5.2.5] they came up with 800x600. Debugging the startup scripts I finally found that the XS* scripts (and especially XS90-assembleXorgConf) in /usr/share/ltsp/screen-session.d/ were not sourced by this code in /usr/share/ltsp/screen-x-common: # Run files prefixed with XS* in /usr/share/ltsp/screen-session.d/ if [ -d "/usr/share/ltsp/screen-session.d/" ]; then for script in $(run_parts_list /usr/share/ltsp/screen-session.d/ XS); do . $script done fi This again was caused by the find command in run_parts_list() of /usr/share/ltsp/ltsp-common-functions: find -L "$1" -mindepth 1 -maxdepth 1 -type f $find_opts | ... not listing the XS* scripts. I had to change the definition of find_opts from find_opts="-name $2\*" to find_opts="-name $2*" to fix this. So unlike the commit comment of revision 1802 (http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/1802) which says "Dereference asterisk in find_opts. Otherwise, this fails sometimes." for me it _always_ fails _with_ the asterisk in find_opts.
(In reply to comment #150) I can't help you with this. I recommend posting a bug report on https://bugs.launchpad.net/ltsp or contacting Gideon (he did the 1802 commit) on irc.
To the maintainer -- are you aware that virtual/tftp which is a required dependency, has been removed from the main portage tree? See bug #359125.
(In reply to comment #151) > (In reply to comment #150) > > I recommend posting a bug report on https://bugs.launchpad.net/ltsp ... Did this (https://bugs.launchpad.net/ltsp/+bug/772446) and in commit 1808 (http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/1808) the bug is fixed.
I just added a new-style virtual to the overlay. Please try it out and let me know if there are any issues.
Pushed ltsp 5.2.9, added ltsp-remoteapps to the client according mgariepy's instructions. http://www.nubae.com/logs/ltsp20110324_pg1.html
Pushed ltsp-server 5.2.17, added support for excluding packages from the chroot and providing a custom kernel sources and config from ltsp-build-client.conf. See ltsp-build-client --extra-help for more info. Also, made quickstart-20101128-r2 with a separate build_kernel and build_initramfs, the initramfs is always created now.
Hi guys, I have problems trying to use custom kernel file when building ltsp client (latest, new server installation) with Gentoo: http://pastebin.com/7SSW9cHN. The conf. is: KERNEL_CONFIG_URI=file:///etc/kernels/kernel-config-x86-2.6.39-gentoo-r3 which is a file that exist in fact: -rw-r--r-- 1 root root 91933 ago 11 19:00 /etc/kernels/kernel-config-x86-2.6.39-gentoo-r3 (also tried to put it in other places with not luck). Cheers.
Btw, I temporary modified /usr/share/quickstart/modules/install_steps.sh to directly copy the file instead of symlink it and works so far.
(In reply to comment #157) I think it's because the config is symlinked, not copied. The genkernel command is executed in a chroot environment, and the symlink cannot link outside it. For your setup to work, the config should already be in the chroot, for instance in file:///opt/lts/x86/etc/kernels/kernel-config-x86-2.6.39-gentoo-r3 (update the config as well). You can copy the config to your chroot in the quickstart profile, in pre_build_kernel(). I used the tftp download option (since you already require an tftp server), to avoid these difficulties.
Hi, Today trying to install LTSP5, there is a problem by fetching ldminfod (net-misc/ldminfod-20110131): http://pastebin.com/P8egxsZG. Any idea? Thanks.
(In reply to comment #160) > Hi, > > Today trying to install LTSP5, there is a problem by fetching ldminfod > (net-misc/ldminfod-20110131): http://pastebin.com/P8egxsZG. > > Any idea? > > Thanks. BTW, trying to obtain it again (by deleting the ebuild folder) I get more info: http://pastebin.com/Z5ZJ0bUe
(In reply to comment #161) > (In reply to comment #160) > > Hi, > > > > Today trying to install LTSP5, there is a problem by fetching ldminfod > > (net-misc/ldminfod-20110131): http://pastebin.com/P8egxsZG. > > > > Any idea? > > > > Thanks. > > BTW, trying to obtain it again (by deleting the ebuild folder) I get more info: > > http://pastebin.com/Z5ZJ0bUe Nevermind... was a proxy problem...
Hi Guys, I am having troubles trying to build a 32Bits clients inside Gentoo 64Bits environment: kernel/bounds.c:1: error: code model 'kernel' not supported in the 32 bit mode kernel/bounds.c:1: sorry, unimplemented: 64-bit mode not compiled in Thats on the Kernel step. I've set ARCH=x86 on /etc/ltsp/ltsp-build-client.conf and in a second try added --arch=x86 on ltsp-build-client command with same results. What I am missing? Or there is a bug? Thanks.
(In reply to comment #163) > Hi Guys, > > I am having troubles trying to build a 32Bits clients inside Gentoo 64Bits > environment: > > kernel/bounds.c:1: error: code model 'kernel' not supported in the 32 bit mode > kernel/bounds.c:1: sorry, unimplemented: 64-bit mode not compiled in > > Thats on the Kernel step. I've set ARCH=x86 on /etc/ltsp/ltsp-build-client.conf > and in a second try added --arch=x86 on ltsp-build-client command with same > results. > > What I am missing? Or there is a bug? > > Thanks. I think I should never work anymore TOO LATE :P... I was using the wrong Kernel config file ¬¬. Lets try again :D Sorry...
Made 5.2.17 stable, version bump to 5.2.18 in which kicktoo can also be used as ltsp-build-client installer. Also, maintaining documentation at wiki.gentoo.org. While running in private beta at the time of this post, the credentials can be found in http://forums.gentoo.org/viewtopic-t-822241-postdays-0-postorder-asc-start-125.html
Hi guys, I'm trying to build latest LTSP client and I get: http://pastebin.com/TH5VQb28 Any idea?
(In reply to comment #166) > Hi guys, > > I'm trying to build latest LTSP client and I get: http://pastebin.com/TH5VQb28 > > Any idea? I'm guessing this has something to do with bzr 2.2 being incompatible with python 2.7 (and bzr 2.4 still unstable on x86) [https://bugs.gentoo.org/show_bug.cgi?id=383751]. Add the following to the quickstart profile (in pre_install_portage_tree), and rebuild. Be sure to remove the binary package build of bzr to force a rebuild. cat >> ${chroot_dir}/etc/portage/package.keywords <<- EOF dev-vcs/bzr EOF
Hi, Today i've trying latest LTSP and there is a problem when building the client. It stays here and does nothing: * Fetching and unpacking stage tarball fetch(): protocol is file fetch_file(): Symlinking local file /opt/ltsp-new/stages/stage3-i686-current.tar.bz2 to /opt/ltsp-new/i686/stage3-i686-current.tar.bz2 spawn(): running command 'tar -C /opt/ltsp-new/i686 -xvpj /opt/ltsp-new/i686/stage3-i686-current.tar.bz2' For some reason does not uncompress anything. Any tip? Thanks.
(In reply to comment #168) Are you using quickstart or kicktoo? And latest versions of either? Can I assume you have enough diskspace? Can you confirm it actually downloaded a compressed stage file? (by uncompressing it manually)
(In reply to comment #169) > (In reply to comment #168) > > Are you using quickstart or kicktoo? And latest versions of either? Latest version and using quickstart (I will test with kicktoo now...) > Can I assume you have enough diskspace? No, I have a lot of space. > Can you confirm it actually downloaded a compressed stage file? (by > uncompressing it manually) I can uncompress it just fine. Also I've tested assigning STAGE variable manually and the same thing happens. Thanks.
Ok, the problem was with the version 5.2.19 (I've forgot that I had the entries in package.keywords). Now using 5.2.18-r2 and works good.
Is me again... New problem building LTSP client: http://pastebin.com/ZCuyxb8h Cheers...
(In reply to comment #170) > (In reply to comment #169) > > (In reply to comment #168) I've tried to reproduce this issue with ltsp-server-5.2.19 and quickstart-20101128-r2. I used the packaged quickstart.profile without edits and target ARCH i686 (in ltsp-build-client.conf). ltsp-build-client downloaded stage3-i686-20120207.tar.bz2 and unpacked it without problems.
(In reply to comment #173) Testing now on a pentium3. The unpacking there shows the same behaviour as your bug, but eventually it's finished unpacking the stage and continues the install. When you're seemingly stuck at the stage unpacking, do a top in another term on the server. If it is unpacking, bzip2 should be at the top of the list.
Hi! I will test the new LTSP on new servers as well (we are always installing new servers for our clients) and I will let you know how is working. Thanks!!
Updated ltsp-server to 5.3. During the ltsp-build-client, the chroot's gentoo profile is linked to the ltsp profile in the ltsp overlay (/var/lib/layman/ltsp/profiles). This profile now contains any specific portage settings which are needed to complete an unattended install. Any changing requirements from ever changing packages can now be updated directly in the overlay without applying them to upstream first. The plan now is to migrate to ltsp-client-5.3. In this update, any normal client can be upgraded to an ltsp-client and booted optionally. This requires another method of doing the client setup, making the installation of one incompatible with a 5.2 client. Both methods will remain supported for some time though.
Added ltsp-server and ltsp-client 5.3.3 to the overlay. No changes in server except the possibility to build 5.3 clients, the default is still set to 5.2. For more info on the 5.3 client, look at http://wiki.gentoo.org/wiki/LTSP#5.3_Client
ltsp-build-client --purge does not umount var/lib/layman, usr/portage and usr/portage/packages from the chroot, which it maybe should do to prevent it from deleting things outside of the chroot.
Thanks to a tip from Tom Ribbens, a fix was made for downloading the lts.conf file from the correct ARCH dir in the tftproot. The bug was that i686 was translated to x86 when determining the arch. A patch was made for this in ltsp-client-5.2.12-r1 The fix for > ltsp-client-5.3.3 is only included upstream, and available upon the next release. So, if you upgrade to one of the above versions, make sure to check that <tftproot>/ltsp/x86 is changed to <tftproot>/ltsp/i686.
Released ltsp client and server 5.3.7. I think these will be on the road for stabilization. Some notes on 5.3.7. - If you're upgrading to ltsp-client-5.3.7, you should also re-emerge ltspfs-1.1. - The clean function for ltsp-update-kernels now works on Gentoo. It removes default genkernel stuff for all kernel versions not in the chroot.
ltsp-server-5.3.7 and kicktoo-0.4.2 are now stable for amd64 and x86. Check the previous comment for specific issues to 5.3.7. When rebuilding an ltsp client from binary packages, you run into a "python_get_implementational_package) is not installed" issue at the libxcb install. Apparently it's build with python:2.7, but the stage3 doesn't include this anymore and neither is it pulled by the libxcb binary package. To solve this, add the following inside the pre_install_extra_packages() function of your installer profile: spawn_chroot "emerge python:2.7" I've included it by default in future installer profile files. Also, tftp client is still built wrong. Check out "lts.conf not downloading at client boot" in http://wiki.gentoo.org/wiki/LTSP#Troubleshooting
Introducing ltsp-server-5.4.0 in which a lot of upstream restructuring was done, allowing for a better distinction between common and distro-specific code. The big changes are Kicktoo as the default installer, installing a 5.3 client by default, and installing python:2.7 by default. One new feature is to prevent purging a client if and bind mounts are still active in it. Also, the upstream server ip changed from 192.168.0.1 to 192.168.67.1, so if you're server ip isn't hardcoded to something else, your new clients will look for the server in the wrong place. The 5.4.0 will remain in ~arch pending bugfix releases in the 5.4 series.
After a 2 month wait for a new ltsp-server and 4 months for a new ltsp-client, today both release at 5.4.3. The server part is just a version bump for 5.4.2 and therefore released stable, the only major change is the running of localepurge at the end of a client build. Furthermore, like 5.4.2, Kicktoo is the default installer and the 5.3+ the default installer profile. The client part contains a lot of bug fixes since 5.3.7. The most important change is that you have to set $SYSLOG_HOST in your lts.conf to activate remote logging. Also happy news for clients is the stabilization of glibc-2.15, and the resulting tftp-client buffer overflow bug (#357083). And last but not least, LTSP has a new website (http://www.ltsp.org)! Add your user story to show your Gentoo support.
Great! I will test it as soon I can. :)
Three months since the last release, Gentoo LTSP bumps to 5.4.4 with two major changes. First, the installation profiles are updated to work again after the /etc/make.[conf|profile] to /etc/portage move. For this reason, the server part will release to stable sooner than normal. Second, it's possible to generate an NBD bootable system. More specifically, by setting INITRAMFS_BUILDER="dracut", the build process generates a Dracut initramfs which allows a boot from an NBD image. I consider this feature still in testing, and some manual server configuration is still required to make it work as intended. The wiki page contains instructions on how to do this. Other changes include: * the removal of dependencies of packages in EXCLUDE * an INPUT_DEVICES install option for the inclusion of X11 input devices besides the default mouse and keyboard Also, an LTSP make.profile update took place which lets xorg-server always be built from source. This makes sure that build time dependencies for xorg-server always get included on the system and in turn solves problems with X not starting after a build from binary packages. For more information refer to bug #379545.
No new release yet, but I've decided to remove Quickstart support to build a client. The main reason for this is I don't want to maintain the profile config files anymore. Also, NBD installs are not possible with Quickstart. The recommended installer program is Kicktoo, which is under active development. If you haven't changed, you should do so soon. I'll remove the dependency from the ltsp-server ebuild entirely and remove the quickstart profiles from the installation. The profiles will be kept upstream under 'obsolete'. The timeline for this is probably somewhere in the first half of 2013, later rather than sooner. In the meanwhile, only the kicktoo profile files will be updated with new changes.
Just changed the overlay to set VIDEO_CARDS="fbdev vesa" by default. So, if you're depending on the usual profile defaulted list and use other video cards, you'll have to set them in your ltsp-build-client.conf The cards you set there will overwrite the new default fbdev and vesa settings. Made this change because of (my) recent problems with new 1.13 drivers, and the recent default inclusion of the xf86-video-vmware driver.
And again about three months after the previous one, the LTSP 5.4.5 is released. In this period, release source tarballs were made available on Launchpad. Most of the recent LTSP ebuilds now download the source from those instead of downloading a separate bzr branch. This version implements the recently added dynamic man page generation. This means Gentoo is the first implementing distro to have a distro specific ltsp-build-client man page, with all Gentoo's --extra-help options! Other Gentoo specific changes include: * Using the 13.0 make profile. * Setting video cards in default ltsp-build-client.conf (fbdev vesa intel mach64 radeon sis via). * Making it easier to add specific network modules in the generated genkernel initramfs (see http://wiki.gentoo.org/wiki/LTSP#Configuration for details). * Supporting non-default locations for the Portage packages and distfiles directories.
Hi, I've a problem and my thin clients can finish to boot (LTSP 5.4.4). As test case, I've created it via VBox. Here is the error http://s2.postimage.org/pz46m69jt/ltsp_5_4_4.png Any idea? There is something I've missing? Since latest builds from different LTSP I always come to this part. I don't know what could be the problem. Thanks.
Hi. I have the problem with mount home folder for LOCALAPPS (LOCALAPPS is True in the lts.conf file). After logged with ldm and running some local application, it is runs, but home folder is empty! I logged in with the same user to the thin station and did the next actions: $ cd /home/someuser $ rm -rf * (delete the newly created files with local application) $ cd .. $ sshfs someuser@ltspserver:/home/someuser /home/someuser SSHFS hangs without returns to the command line. Then I switched to the next console and saw /home folder with midnight commander. There is "someuser" folder with 000 rigths and she is red. Even root user can not switch to this directory (permission denied). Next I doing ctrl+c in the previous console for the break sshfs, then $ fusermount -u /home/someuser Now the folder is readable for root and the owner. Next I tried another step: $ mkdir /home/someuser/111 $ sshfs someuser@ltspserver:/home/someuser /home/someuser/111 It is mounts fine. Ok. I unmount folder again and tried with root priveleges: # sshfs someuser@ltspserver:/home/someuser /home/someuser It is mounts too and all files and folders has true permissions (someuser:users), but if I try to create any file as the someuser it says that permissions denied! In other words, I can not mount over home folder (8-o). I tried to ask Google about sshfs mount over home folder, but no results. I heard something about pam and rights, but nothing understand. ltsp-client: 5.4.3 ldm: 2.2.1 sshfs: 2.4 fuse: 2.9.1 FUSE kernel interface: 7.19 Sorry for my English. Please help me. Thank You wery much.
(In reply to comment #189) > Hi, I've a problem and my thin clients can finish to boot (LTSP 5.4.4). As > test case, I've created it via VBox. Here is the error > http://s2.postimage.org/pz46m69jt/ltsp_5_4_4.png > > Any idea? There is something I've missing? Since latest builds from > different LTSP I always come to this part. I don't know what could be the > problem. > > Thanks. May be lost CONFIG_TMPFS=y or CONFIG_DEVTMPFS=y in the kernel configuration?
(In reply to comment #191) > (In reply to comment #189) > > Hi, I've a problem and my thin clients can finish to boot (LTSP 5.4.4). As > > test case, I've created it via VBox. Here is the error > > http://s2.postimage.org/pz46m69jt/ltsp_5_4_4.png > > > > Any idea? There is something I've missing? Since latest builds from > > different LTSP I always come to this part. I don't know what could be the > > problem. > > > > Thanks. > > May be lost CONFIG_TMPFS=y or CONFIG_DEVTMPFS=y in the kernel configuration? Yep, I have both options in the kernel from chroot. :(
I find the bug! May be.. This is about sshfs mount. I opened up the source code and found a piece of code, where the mount sshfs. The path to an already installed file is /usr/share/ldm/rc.d/X01-localapps And рere is a piece of code: --- # If the user's home directory is not located in the root cow device, assume # that it has already been mounted with other means, e.g. with FSTAB_x. if [ "$(stat -c %m "$LDM_HOME")" != "/" ]; then unset SSHFS_HOME else export SSHFS_HOME=true sshfs -o ${follow_home_symlinks}allow_other,ControlPath=${LDM_SOCKET} ${LDM_SERVER}:${LDM_HOME} ${LDM_HOME} fi --- In my case, the command $(stat -c %m "$LDM_HOME") returns "/home" instead of "/" and mounting interrupted ($LDM_HOME = "/home/someuser"). After replacing if [ "$(stat -c %m "$LDM_HOME")" != "/" ]; then to if [ "$(stat -c %m "$LDM_HOME")" != "/home" ]; then everything works fine! What is this? Bug or feature? :)
(In reply to comment #186) > The recommended installer program is Kicktoo, which is under active > development. If you haven't changed, you should do so soon. Tried to do so today but got: --2013-04-03 19:34:09-- https://github.com/r1k0/kicktoo/archive/v0.4.5.tar.gz Resolving github.com... 207.97.227.239 Connecting to github.com|207.97.227.239|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://nodeload.github.com/r1k0/kicktoo/tar.gz/v0.4.5 [following] --2013-04-03 19:34:09-- https://nodeload.github.com/r1k0/kicktoo/tar.gz/v0.4.5 Resolving nodeload.github.com... 207.97.227.252 Connecting to nodeload.github.com|207.97.227.252|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2013-04-03 19:34:10 ERROR 404: Not Found. On https://github.com/r1k0/kicktoo/tags I only see a "v1" package.
Hi, I have the same problem with kicktoo. Tried to modify the ebuild to use https://github.com/r1k0/kicktoo/archive/master.zip but does not install correctly. Any fix soon? really need it. Thanks.
Fix just uploaded. The maintainer decided to wipe the whole git history and start over, removing the existing tags and connected github downloads. I had the sources for 0.4.5 and 0.5.0 still on my computer, and published tar.gz's for those.
Local devices (e.g. mounting an usb stick) again did not work for me. Don't know when this changed but now /usr/share/ldm/rc.d/X10-delayed-mounter isn't used anymore but udev through the rules in /usr/share/ltspfs/udev/ltspfsd.rules calls the script /lib/udev/ltspfs_entry to call the ltspfsmounter via ssh on the server: /usr/bin/ssh $SSH_OPTS -S ${LDM_SOCKET} ${SERVER} \ "$DISPLAY_INFO /usr/sbin/ltspfsmounter ${MOUNTPOINT} $action" And this call failed: The desktop icon in my session was created but the /media/<username>/<Stick> directory was missing. During debugging I found that in the above ssh-call both $SSH_OPTS and $DISPLAY_INFO were empty. This was caused by the line IS_DIRECTX=$(pgrep -f -l ${LDM_SOCKET}.*DISPLAY) that didn't get the whole command line with all args but only pid and command name. It seems that the author of this script used a POSIX pgrep command (from it's man page: "-l Long output format. ...") but the pgrep from sys-process/procps in Gentoo isn't POSIX and states in it's man page: -l, --list-name List the process name as well as the process ID. (pgrep only.) -a, --list-full List the full command line as well as the process ID. (pgrep only.) So in /lib/udev/ltspfs_entry I changed the line to IS_DIRECTX=$(pgrep -f -a ${LDM_SOCKET}.*DISPLAY) and could access my USB device again.
(In reply to Gustavo A. Díaz from comment #189) > Hi, I've a problem and my thin clients can finish to boot (LTSP 5.4.4). As > test case, I've created it via VBox. Here is the error > http://s2.postimage.org/pz46m69jt/ltsp_5_4_4.png > > Any idea? There is something I've missing? Since latest builds from > different LTSP I always come to this part. I don't know what could be the > problem. > > Thanks. Hi guys, can someone help with this please? Thanks.
(In reply to Gustavo A. Díaz from comment #198) > Hi guys, can someone help with this please? Thanks. Had the same error some weeks ago but didn't follow the link to the screenshot on your first post in #189. I had to activate the new Kernel option (introduced in 3.6 I think) "Root file system on NFS" here: File systems ---> [*] Network File Systems ---> <*> NFS client support [ ] NFS client support for NFS version 2 [*] NFS client support for NFS version 3 [*] Root file system on NFS (NEW) It took me a long time to find this because I previously had [*] Network File Systems ---> <M> NFS client support and with this setting the "Root file system on NFS" was not displayed.
Thanks for reply :) I just did the same configuration and that option does not appear :( Here the screen: http://postimg.org/image/m2l4bz46v/
(In reply to Gustavo A. Díaz from comment #200) > I just did the same configuration and that option does not appear :( Hm. Then maybe another precondition is missing. I just searched in menuconfig for CONFIG_ROOT_NFS and it says: Symbol: ROOT_NFS [=y] Type : boolean│ Prompt: Root file system on NFS Defined at fs/nfs/Kconfig:134 Depends on: NETWORK_FILESYSTEMS [=y] && NFS_FS [=y]=y && IP_PNP [=y] Location: -> File systems (1) -> Network File Systems (NETWORK_FILESYSTEMS [=y]) As your screenshot shows you have NETWORK_FILESYSTEMS and NFS_FS enabled, so it should be a missing IP_PNP.
Ok, found the CONFIG by editing the file directly but after doing a --clean all. Seems that the config file i was using didnt had that one included. Anyways, I've enabled that one but still i have the same result. I don't know which could be the problem but before this, I've installed, implemented and configured LTSP many times and never had this problem... :(
(In reply to Gustavo A. Díaz from comment #202) Sorry, but then I can't tell you why your kernel failes on mounting the NFS root but from the error messages I'm pretty sure the kernel failes on mounting the NFS root. In my case I could see some more messages on the screen: >> Attempting to mount NFS root on ***.***.***.***:/opt/ltsp/486 with options ro,nolock,rsize=1024,wsize=1024 mount: mounting ***.***.***.***:/opt/ltsp/486 on /newroot failed: Protocol not supported !! NFS Mounting failed.Is the path correct ? >> Booting (initramfs).mount: mounting /dev on /newroot/dev failed: No such file or directory unmount: can't mount /dev: Device or resource busy *: Failed to move and unmount the ramdisk $fs! >> ERROR: your real /dev is missing file required too boot (console and null). BusyBox v 1.20.2 (2013-03-22 14:43:15 CET) multi-call binary. Usage switch_root [-c /dev/console] NEW_ROOT NEW_INIT [ARGS] Free initramfs and switch to another root fs: chroot to NEW_ROOT, delete all in /, move NEW_ROOT to /, execute NEW_INIT. PID must be 1. NEW_ROOT must be a mountpoint. -c DEV Reopen stdio to DEV after switch Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 Pid : 1, comm: switch_root Not tainted 3.7.9-gentoo-VIA #1 Call Trace: ... If you have the part "mount ... failed: Protocol not supported", too, then your kernel definitely has no support for NFS-Root. If not then there must be another reason that the NFS-mount failes.
Similar to your debug appears when I don't have the proper ethernet driver compiled in. But is not the case. Maybe i need to add these options to the kernel of my server? or is only needed by the ltsp client side?
(In reply to Gustavo A. Díaz from comment #204) The first line in your screenshot is *: Failed to move and unmount the ramdisk $fs! What does the kernel say in the lines before?
Here: http://postimg.org/image/41p4x04f5/
(In reply to Gustavo A. Díaz from comment #206) > Here: http://postimg.org/image/41p4x04f5/ So your udhcpc client failes: Sending discover ... Sending discover ... Sending discover ... No lease, failing and without a network connection the NFS mount failes. Is it now standard to use a dhcp client? I don't. I have the option CONFIG_IP_PNP_DHCP enabled and use "ip=dhcp" in the kernel command line: udev root=/dev/nfs ip=dhcp nfsroot=<server-ip>:/opt/ltsp/486 ...
Ok, now that message is gone, but does not mount NFS. I've tested nfs mount and does work right. :(
(In reply to Gustavo A. Díaz from comment #208) > Ok, now that message is gone, but does not mount NFS. I've tested nfs mount > and does work right. > > :( Just forgot: NFS says connection time out... weird. Since works like I said.
Guys, today i've installed a new Fresh Gentoo server and new fresh LTSP installation. Followed and RE-read twice the ltsp wiki (http://wiki.gentoo.org/wiki/LTSP) and no matter what, I end in the same problem and posted in https://bugs.gentoo.org/show_bug.cgi?id=177580#c189. I don't know what else to do anymore... I always have to go back and use a old LTSP 5.x chroot that i have around... :(
Ok, I don't know which is the problem, but i've created a VirtualBox thin client to boot from there and make some testing. Then the same problem. Now switched the emulated network interface to the intel Intel PRO/1000 and boot fine! I don't know why the real thin cliente does not boot, since i have many network cards drivers compiled in: MODULES_NET="8139cp 8139too atl2 atl1 atl1c e100 e1000 e1000e forcedeth fealnx mii ne2k-pci davicom icplus libphy sis190 sis900 skge sky2 sundance tg3 dmfe tulip via-rhine rtl8187 r8169"
About jetpipe: I am seeing that python-daemon and pyserial are not installed by default in the chroot which is needed by /usr/sbin/jetpipe: import serial import daemon Maybe should be included in the client build profile?, since jetpipe it is. Cheers.
Guys, I have a problem when setting a thin client to login from other server. With LDM does not work, no matter if i setup another server IP it just login in the local one. Now, If I use XDMCP I have black screen, even if I set for local server (and is enabled in /etc/X11/gdm/custom.conf). Any idea? Thanks. PD: LTSP 5.4.4
Hi guys, after solved all my question. now LTSP is working just fine. Now I have a problem (and I've said it to alkisg), that RCFILE_ does not work in Gentoo. Example: RCFILE_01 = /etc/init.d/fiscal-epson_tty. The file exis in /opt/ltsp/i686/etc/init.d/fiscal-epson_tty. Is this implemented in Gentoo port of LTSP?
Hi! Since I'dont know how to execute init scripts per thin client, I just created the file 60-rcScripts inside /usr/share/ltsp/init-ltsp.d/60-rcScripts (inside chroot) with the content: for script in $(env|grep ^RC_SCRIPT_|sed -e s/^RC_SCRIPT_[0-9]*\=//); do rc-update add $script default done So you can just add lines in lts.conf like this: RC_SCRIPT_01 = my-rc-script When the thin client start, it will add in default runlevel and then start. Hope it helps anyone :)
(In reply to Gustavo A. Díaz from comment #215) > Hi! Since I'dont know how to execute init scripts per thin client, I just > created the file 60-rcScripts inside > /usr/share/ltsp/init-ltsp.d/60-rcScripts (inside chroot) with the content: > > for script in $(env|grep ^RC_SCRIPT_|sed -e s/^RC_SCRIPT_[0-9]*\=//); do > rc-update add $script default > done > > So you can just add lines in lts.conf like this: > > RC_SCRIPT_01 = my-rc-script > > When the thin client start, it will add in default runlevel and then start. > > Hope it helps anyone :) Hello, i try to setup LTSP on my fresh gentoo server (client& server amd64) with no success, first have profile probleme the 10.0 do not exist # nano -w /etc/ltsp/profiles/kicktoo-5.3.profile <---> Line 84 update with: ln -s "/var/lib/layman/ltsp/profiles/default/linux/${MAIN_ARCH}/13.0/ltsp/" "${chroot_dir}/etc/portage/make.profile" <---> i replace 10.0 by 13.0 and that ok second have many error with LC_CTYPE warning: setlocale: LC_CTYPE: cannot change locale (fr_FR.UTF-8): No such file or directory third: the command: ltsp-update-kernels --tftpdir="/opt/tftproot" do not work with error invalid option « --tftpdir="/opt/tftproot" » when i boot with my client have kernel error: >> Determining root device ... !! Block device /var/lib/tftpboot is not a valid root device ... !! Could not find the root block device in . Please specify another value or: press Enter for the same, type "shell" for a shell, or "q" to skip... root block device() :: Could you send me your'e detailled method to setup LTSP on Gentoo ? the wiki seem to be light or it's me ? Thanks You
(In reply to Christophe DAPREMONT from comment #216) > (In reply to Gustavo A. Díaz from comment #215) > > Hi! Since I'dont know how to execute init scripts per thin client, I just > > created the file 60-rcScripts inside > > /usr/share/ltsp/init-ltsp.d/60-rcScripts (inside chroot) with the content: > > > > for script in $(env|grep ^RC_SCRIPT_|sed -e s/^RC_SCRIPT_[0-9]*\=//); do > > rc-update add $script default > > done > > > > So you can just add lines in lts.conf like this: > > > > RC_SCRIPT_01 = my-rc-script > > > > When the thin client start, it will add in default runlevel and then start. > > > > Hope it helps anyone :) > > Hello, i try to setup LTSP on my fresh gentoo server (client& server amd64) > with no success, > > first have profile probleme the 10.0 do not exist > # nano -w /etc/ltsp/profiles/kicktoo-5.3.profile > <---> > Line 84 update with: > ln -s "/var/lib/layman/ltsp/profiles/default/linux/${MAIN_ARCH}/13.0/ltsp/" > "${chroot_dir}/etc/portage/make.profile" > <---> > i replace 10.0 by 13.0 and that ok > > second have many error with LC_CTYPE > warning: setlocale: LC_CTYPE: cannot change locale (fr_FR.UTF-8): No such > file or directory > > third: the command: > ltsp-update-kernels --tftpdir="/opt/tftproot" > do not work with error invalid option « --tftpdir="/opt/tftproot" » > > when i boot with my client have kernel error: > > >> Determining root device ... > !! Block device /var/lib/tftpboot is not a valid root device ... > !! Could not find the root block device in . > Please specify another value or: press Enter for the same, type "shell" > for a shell, or "q" to skip... > root block device() :: > > Could you send me your'e detailled method to setup LTSP on Gentoo ? > the wiki seem to be light or it's me ? > > Thanks You solved the third with this, after i build the client: i copy manually the kernel files in appropriate directory ... # cp /etc/kernels/kernel-config-x86_64-3.10.7-gentoo /var/lib/tftpboot # chown christophe /var/lib/tftpboot/kernel-config-x86_64-3.10.7-gentoo # rm -r /opt/ltsp/amd64 # ltsp-build-client --config=/etc/ltsp/ltsp-build-client-S207.conf # ltsp-update-sshkeys # cp /var/lib/tftpboot/ltsp/amd64/* /var/lib/tftpboot the client boot but now have this error: server [192.168.0.5] 9571 (?) : Connection refused ...
now i can boot thin amd64 client but have only console no ldm manager... I wan't to use fat amd64 client, that not implemented with gentoo anybody have some informations?
Hi, i compile the gentoo ltsp server kernel manually without genkernel have one important network module: "bonding" (need to be compiled in module mode for setting mode from OS) when i prepare ltsp thin client i launch # genkernel --no-install --no-clean --menuconfig --gconfig all i adapt setting for matching with my thin client hardware (different from server), and by exemple remove bonding, not needed on thin client # cp /etc/kernels/kernel-config-x86_64-3.10.7-gentoo /var/lib/tftpboot # ltsp-build-client --arch=amd64 --config=/etc/ltsp/ltsp-build-client.conf That remove my "bonding" module for server and at server reboot no bonding... There is a way for separate genkernel LTSP activity for thin client setup and server kernel config?
