Bug 598134 - [LTSP] ltsp-build-client :ERROR: fc13 is unsupported
Summary: [LTSP] ltsp-build-client :ERROR: fc13 is unsupported
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: ltsp (Show other bugs)
(Show other bugs)
Version: 13
Hardware: All Linux
low
medium
Target Milestone: ---
Assignee: DaGeek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-31 14:18 UTC by Frederic Hornain
Modified: 2011-06-27 17:11 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 17:11:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch (402 bytes, patch)
2010-06-08 19:57 UTC, Marcos Saraiva
no flags Details | Diff
Screenshot of LTSP Running on Fedora 13 (152.64 KB, image/png)
2010-09-11 22:25 UTC, DaGeek
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 652896 None None None Never

Description Frederic Hornain 2010-05-31 14:18:24 UTC
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:

Comment 1 mayost_sharon 2010-06-07 12:19:35 UTC
Hello

I have the same error message and I have tried versions of FEDOR 13 32BIT and also on 64bit

Thanks

Comment 2 Marcos Saraiva 2010-06-08 19:55:20 UTC
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.

Comment 3 Marcos Saraiva 2010-06-08 19:57:32 UTC
Created attachment 422332 [details]
patch

Comment 4 Adrie Taniwidjaja 2010-06-09 10:11:03 UTC
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 ?

Comment 5 Marcos Saraiva 2010-06-09 12:59:18 UTC
(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

Comment 6 Adrie Taniwidjaja 2010-06-10 03:44:20 UTC
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 ?

Comment 7 seth vidal 2010-06-17 17:47:57 UTC
It might be worth turning this ticket into an AWOL maintainer ticket and start looking for a new maintainer.

Comment 8 DaGeek 2010-06-18 06:07:40 UTC
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 ?

Comment 9 Adrie Taniwidjaja 2010-06-22 04:08:52 UTC
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.

Comment 10 Adrie Taniwidjaja 2010-06-30 14:51:13 UTC
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@au.interpath.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 ?

Comment 11 q2dg 2010-08-02 22:20:04 UTC
I don't understand how a so exciting system-management software is so ignored by Red Hat. Reconsider, please!!!

Comment 12 Odin Nøsen 2010-08-11 11:19:56 UTC
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... :-(

Comment 13 DaGeek 2010-08-11 11:54:39 UTC
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@redhat.com
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

Comment 14 seth vidal 2010-08-11 13:39:44 UTC
DaGeek - come by #fedora-devel and I'll see what I can do about access to the pkg for you.

Comment 15 q2dg 2010-08-13 10:45:08 UTC
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.

Comment 16 DaGeek 2010-08-13 13:59:25 UTC
(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.

Comment 17 DaGeek 2010-09-08 08:29:26 UTC
 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 ***

Comment 18 DaGeek 2010-09-09 13:54:45 UTC
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@redhat.com
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)

Comment 19 DaGeek 2010-09-11 09:56:04 UTC
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@redhat.com
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

Comment 20 DaGeek 2010-09-11 22:25:07 UTC
Created attachment 446701 [details]
Screenshot of LTSP Running on Fedora 13

Comment 21 q2dg 2010-09-14 15:35:58 UTC
THANKS THANKS THANKS THAAANKS!!!

Comment 22 q2dg 2010-09-15 00:47:20 UTC
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.

Comment 23 Warren Togami 2010-09-26 03:46:54 UTC
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.

Comment 24 Norman Gaywood 2011-02-02 04:56:56 UTC
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.

Comment 25 Bug Zapper 2011-06-02 12:37:13 UTC
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

Comment 26 Bug Zapper 2011-06-27 17:11:08 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.