Description of problem: I have followed the procedure written at https://fedorahosted.org/k12linux/wiki/InstallGuide Version-Release number of selected component (if applicable): ltsp-vmclient-5.1.95-1.fc13.x86_64 ltsp-server-5.1.95-1.fc13.x86_64 ltspfs-0.5.13-1.fc12.x86_64 How reproducible: Step 9 of the given procedure - see above - ltsp-build-client to begin installation of the /opt/ltsp/i386 client chroot. [root@localhost ~]# ltsp-build-client ERROR: fc13 is unsupported. Steps to Reproduce: 0. Fresh install of FC13. 1. yum update 2. yum install ltsp-server 3. yum install ltsp-vmclient if you want the qemu-kvm PXE boot client launcher. Requires hardware virtualization support or it will be very slow and possibly unusable. 4. Uncomment the option_cache_value line in /etc/ltsp/ltsp-build-client.conf if you want to keep a local cache of packages to be installed in the client chroot. This might be useful if you keep testing newer versions of ltsp-server and you will be reinstalling the client chroot. Erase /var/cache/chroot if you no longer need this cache. 5. echo "/opt/ltsp *(ro,async,no_root_squash)" >> /etc/exports 6. ifup ltspbr0 This works fine for now, but after reboot it might not start up automatically unless you have service network running. NetworkManager does not know how to bring up TYPE=Bridge devices. You could enable service network with chkconfig network on then rebooting (or do it manually). service network will mostly co-exist with NetworkManager until you need to plug in a real client via ethernet. See NetworkSetup for more info. 7. for service in xinetd ltsp-dhcpd rpcbind nfs sshd; do chkconfig $service on; service $service restart; done 8. for server in ldminfod nbdrootd nbdswapd tftp; do chkconfig $server on; done 9.ltsp-build-client to begin installation of the /opt/ltsp/i386 client chroot. Actual results: ERROR: fc13 is unsupported Expected results: Additional info:
Hello I have the same error message and I have tried versions of FEDOR 13 32BIT and also on 64bit Thanks
I can also confirm this bug. I don't think this package got tested. For example, look at this file contents: [root@fedora13ltsptest 10]# cat /etc/ltsp/kickstart/Fedora/13/ltsp-i386.ks "# Kickstart Definition for Client Chroot for i386 # we are going to install into a chroot, such as /opt/ltsp/i386 install repo --name=rawhide-13-i386 --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=i386 #repo --name=temporary-13-i386 --baseurl=http://togami.com/~k12linux-temporary/fedora/13/i386/ %include ../common/common.ks %include ../common/arch/i686.ks %include ../common/release/13.ks" As you can see, it still points to RAWHIDE. For the bug in question, you can fix it by editing /etc/sysconfig/ltspdist and including a fc13 section. I've attached a simple patch to fix this. By the way, why are we still at 5.1.95? Upstream and most distros are already at 5.2-1, which has many improvements.
Created attachment 422332 [details] patch
Dear Marcos Saraiva, Yes it looks that this package has been abondon by Fedora, maybe it is because Waren Togami who is responsible for this things (ltsp) has been resign from Red Hat. I am agree with you that Fedora 13 should be upgrading to LTSP 5.2 instead still packaging the old LTSP (5.1.95) on a non working conditions. By the way I need this feature very much. While waiting what the Fedora team working for this I try to follow the patch you give. But I found it didn't work also. It gives me this output : [root@kopo etc]# ltsp-build-client Autoconfigured Kickstart: /etc/ltsp/kickstart/Fedora/13/ltsp-i386.ks Installing into /opt/ltsp/i386 Mounting /opt/ltsp/i386 for chroot installation Retrieving http://ftp.jaist.ac.jp/pub/Linux/Fedora/development/rawhide/i386/os/repodata/repomd.xml ...OK Retrieving http://ftp.jaist.ac.jp/pub/Linux/Fedora/development/rawhide/i386/os/repodata/4ed911d6e26543bfe8c5cb9b7b7c8080512d3d3d3a75b624beb22a758fead6c2-primary.sqlite.bz2 ...OK /usr/lib/python2.6/site-packages/imgcreate/errors.py:40: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 return str(self.message) Error creating image : Failed to find package 'kudzu' : No package(s) available to install error: LTSP client installation ended abnormally Does it because it still using the RAWHIDE repo ? Could you give me additional information where should the repo point to ?
(In reply to comment #4) > Dear Marcos Saraiva, > > Yes it looks that this package has been abondon by Fedora, maybe it is because > Waren Togami who is responsible for this things (ltsp) has been resign from Red > Hat. I am agree with you that Fedora 13 should be upgrading to LTSP 5.2 instead > still packaging the old LTSP (5.1.95) on a non working conditions. > > By the way I need this feature very much. While waiting what the Fedora team > working for this I try to follow the patch you give. But I found it didn't work > also. It gives me this output : > > > [root@kopo etc]# ltsp-build-client > Autoconfigured Kickstart: /etc/ltsp/kickstart/Fedora/13/ltsp-i386.ks > Installing into /opt/ltsp/i386 > Mounting /opt/ltsp/i386 for chroot installation > Retrieving > http://ftp.jaist.ac.jp/pub/Linux/Fedora/development/rawhide/i386/os/repodata/repomd.xml > ...OK > Retrieving > http://ftp.jaist.ac.jp/pub/Linux/Fedora/development/rawhide/i386/os/repodata/4ed911d6e26543bfe8c5cb9b7b7c8080512d3d3d3a75b624beb22a758fead6c2-primary.sqlite.bz2 > ...OK > /usr/lib/python2.6/site-packages/imgcreate/errors.py:40: DeprecationWarning: > BaseException.message has been deprecated as of Python 2.6 > return str(self.message) > Error creating image : Failed to find package 'kudzu' : No package(s) available > to install > error: LTSP client installation ended abnormally > > Does it because it still using the RAWHIDE repo ? > Could you give me additional information where should the repo point to ? Hi Adrie, We use our own repos here, but you can try this when using the official mirrors: rm -f /etc/ltsp/kickstart/Fedora/13/* cp /etc/ltsp/kickstart/Fedora/12/* /etc/ltsp/kickstart/Fedora/13/ for ARCH in i386 ppc x86_64; do sed -i /etc/ltsp/kickstart/Fedora/13/ltsp-$ARCH.ks -e 's/12/13/g'; done
Dear Marcos, Thank's for your info. It works now when I run ltsp-build-client. If you could share again, how could we make our own repository ? It would be nicer to have our own repository especially if we should configure many ltsp server. Using official mirror was very slow, especially for me with limited bandwidth available. By the way, did anyone have some information regarding rdesktop support on LTSP 5.2 ? Could rdesktop client now logging to ltsp server using rdesktop protocol ? It would be very nice if we could make Windows Client (using rdesktop) login to LTSP Server an running linux on their desktop. When will Fedora upgrade to LTSP 5.2 ?
It might be worth turning this ticket into an AWOL maintainer ticket and start looking for a new maintainer.
How much work is involved in maintaining this package... Is the RPM that different from the source project ? I used LTSP for a long time before I worked @ Red Hat and try to keep an eye on things, It would be a shame for Fedora/Red Hat/RHEL to fall behind with LTSP. I may be interested in maintaining/co-maintaining this package if needed.. Is anyone willing to help me co-maintain it ?
Dear DaGeek, How can I help you co-maintaining this package ? If I could do it I will try to help you co-maintaining this package. There was not much information after LTSP ver 5.0 even in it's home page, because it consider to be part of the distro now. Actually LTSP was very interesting topic, we hope some day LTSP will support rdesktop protocol so we can login to Linux machine from Windows machine easily, but rdesktop development itself looks like stagnant now. There is no sign that it will upgrade to the new version used on Windows 7 or Windows 2008 Server. What is the meaning of AWOL maintainer ticket and how to turn to that ? Have it done and found the new maintainer ? I think upgrading to ver 5.2 was very urgent for this package, and meanwhile fix this bug as soon as possible so everybody installing Fedora 13 could install LTSP even it still in the old version at least it works.
Another problem for this LTSP I found after following the information from Marcos Saraiva was that this configuration worked only for client with PXE boot. I found this after I boot my client that still use Etherboot. There was no boot file for the etherboot client. If we look at the dhcpd.conf in the /etc/ltsp/ folder we found this : # trick from Peter Rundle <peter.rundle.net> # newer PPC Macs if substring (option vendor-class-identifier, 0, 9) = "AAPLBSDPC" { filename "yaboot"; option vendor-class-identifier "AAPLBSDPC"; option vendor-encapsulated-options 01:01:02:08:04:01:00:00:01:82; } # really old ppc iMacs elsif substring (option option-221, 0, 5) = "Apple" { filename "yaboot"; option vendor-class-identifier "AAPLBSDPC"; option vendor-encapsulated-options 01:01:02:08:04:01:00:00:01:82; } # Etherboot ELF (only 5.4), should work with Coreboot elsif substring (option vendor-class-identifier, 0, 13) = "Etherboot-5.4" { filename "/ltsp/i386/elf.ltsp"; } # Etherboot NBI (older clients) elsif substring (option vendor-class-identifier, 0, 9) = "Etherboot" { filename "/ltsp/i386/wraplinux-nbi.ltsp"; } # PXE elsif substring (option vendor-class-identifier, 0, 9) = "PXEClient" { # NOTE: kernels are specified in /tftpboot/ltsp/i386/pxelinux.cfg/ filename "/ltsp/i386/pxelinux.0"; } # if all else fails (likely BOOTP), default to an NBI image else { filename "/ltsp/i386/wraplinux-nbi.ltsp"; } and if we look at the /var/lib/tftpboot/ltsp/i386 : [adrie@kopo i386]$ ls config-2.6.33.5-124.fc13.i686 pxelinux.0 grub pxelinux.cfg initramfs-2.6.33.5-124.fc13.i686.img System.map-2.6.33.5-124.fc13.i686 initrd.ltsp vmlinuz-2.6.33.5-124.fc13.i686 lts.conf We don't have : - elf.ltsp - wraplinux-nbi.ltsp How can we build this file ?
I don't understand how a so exciting system-management software is so ignored by Red Hat. Reconsider, please!!!
LTSP in Fedora is a critical application/server for our school - and I'm wondering why this bug isn't "assigned" yet. I need to know that LTSP is kept alive in Fedora. If not, we'll have to consider other options - in other words Ubuntu, but I really don't want that (I like the hardcore GPL policy that Fedora has :-). Yes, Marcos' hack works - but we can't use that as an argument in front of the school board... :-(
The project is not dead yet... The current Maintainer is very busy with 'Real World' stuff but has said he should be coming back to the community soon. I did offer to take over maintainer-ship along with a friend that is willing to help me keep up the maintenance. I can see that this is becoming an issue so I think i will try and step up and get things back on track and get things updated and fixed. But in order to fix these issues I need rights over the packages to allow me and others to make the changes needed. This is the bit of the process that takes a long time to get things sorted. I'm sure with just a few hours of hard work, myself and my partner in crime could get things back on track and working again with both F13 & F14. -- Gavin Spurgeon. gspurgeon Red Hat GLS Instructor EMEA Red Hat UK Ltd 64 Baker Street 4th Floor, London, W1U 7DF Mob: +44 7841 231160 Desk: +44 0207 009 4429 (Direct) Tel: +44 1252 362709 Fax: +44 1252 548116
DaGeek - come by #fedora-devel and I'll see what I can do about access to the pkg for you.
You could see https://launchpad.net/ltsp and https://launchpad.net/~ltsp-upstream It seems to be the most active development site about Ltsp nowadays.
(In reply to comment #15) > You could see https://launchpad.net/ltsp and > https://launchpad.net/~ltsp-upstream > It seems to be the most active development site about Ltsp nowadays. I did find this and I now have the latest version of ltsp downloaded ready for me to try and build the new v5.2.4 .rpm I have already managed to build a new v5.2.4 .src.rpm and now need to build a real package from it and test it before i push it up to the Fedora Repos.
Hi LTSP/Fedora Community. After a flurry of work over night I have finally managed to get some .rpm's ready for testing on x86_64 F13. I have uploaded them all to a tmp dir on one of my www sites so you can download and test them before I push them into Fedora. http://www.dageek.co.uk/ltsp/x86_64/ You should find all 3 of the .rpm files ready for testing. 40740cc693a3ef56bcd9ebb183af9d17 ltsp-client-5.2.4-1.fc13.x86_64.rpm 9904acb9ecff9166b10eed8b81d5cfdf ltsp-server-5.2.4-1.fc13.x86_64.rpm 744c4eb816bb5b2f86c256086d1be8c3 ltsp-vmclient-5.2.4-1.fc13.x86_64.rpm Please have a little play with these .rpm files *ON A TEST PLATFORM* and let me know if they are OK. I will reiterate... *** THESE ARE NOT READY FOR PRODUCTION USE ***
Hi LTSP/Fedora Community. I am working on the F13 issue with the ltsp upstream source and think I have a working version ready to roll into the next version of the 5.2.4-*.rpm I am doing all my testing on x86_64 but the changes I am making to the upstream files should work on both x86_64 & i386 versions of F13. As always, I will keep everyone as up2date as I can, as and when I have more info. Thank You for your continued understanding. -- Gavin Spurgeon. gspurgeon Red Hat GLS Instructor EMEA Red Hat UK Ltd 64 Baker Street 4th Floor, London, W1U 7DF Mob: +44 7841 231160 Desk: +44 0207 009 4429 (Direct) Tel: +44 1252 362709 Fax: +44 1252 548116 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA)
Hi LTSP/Fedora Community. I now have a fully working copy of LTSP for both i686 & x86_64 The New .rpm's are still located on my www server, and to make things a little easier I have also made a Yum Reop for both archs as well. The .repo file is @ http://www.dageek.co.uk/ltsp/ltsp.repo and the .rpm's them selves are also located @ http://www.dageek.co.uk/ltsp/i686/ http://www.dageek.co.uk/ltsp/x86_64/ Please have a play with these .rpm's and feed back any comments to me and/or the mailing lists. Once a few people have tested the .rpm's and given the all clear, I will push them up into the Official Fedora Repos Thank you all for your continued patience and understanding. -- Gavin Spurgeon. gspurgeon Red Hat GLS Instructor EMEA Red Hat UK Ltd 64 Baker Street 4th Floor, London, W1U 7DF Mob: +44 7841 231160 Desk: +44 0207 009 4429 (Direct) Tel: +44 1252 362709 Fax: +44 1252 548116
Created attachment 446701 [details] Screenshot of LTSP Running on Fedora 13
THANKS THANKS THANKS THAAANKS!!!
Hey, I've got some errors when I try to execute ltsp-build-client: ... Retrieving http://ftp.udc.es/fedora/linux/releases/13/Everything/i386/os/Packages/zenity-2.30.0-1.fc13.i686.rpm ...OK Retrieving http://ftp.udc.es/fedora/linux/releases/13/Everything/i386/os/Packages/zlib-1.2.3-23.fc12.i686.rpm ...OK warning: fontpackages-filesystem-1.42-1.fc13.noarch: Header V3 RSA/SHA256 Signature, key ID e8e40fde: NOKEY Traceback (most recent call last): File "/usr/share/yum-cli/callback.py", line 196, in callback UnicodeEncodeError: 'ascii' codec can't encode character u'\xb7' in position 9: ordinal not in range(128) error: python callback <bound method RPMInstallCallback.callback of <callback.RPMInstallCallback instance at 0xa8a2ecc>> failed, aborting! /var/tmp/imgcreate-RAK1La/install_root/var/lib/rpm: No such file or directory error: LTSP client installation ended abnormally Am I doing something wrong? it's a packet's problem? Or it's a problem about anything else? Thanks.
Hey folks. Sorry I was away for a while. I was busy moving and getting settled in my new job and city. I intend on resuming maintenance of LTSP-5.x in Fedora. I will examine gspurgeon's work and look at incorporating any necessary changes into upstream LTSP or Fedora git. gspurgeon, could you please e-mail me with your contact information? I could use your help to get me up to speed on what changed while I was away and how you would like to handle future maintenance.
ping? Would love to use F14 and LTSP. Am currently using an F12 box for the clients and an F14 for the application server but I'm sure I'm going to get stung with new hardware soon.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.