Red Hat Bugzilla – Bug 458965
ltsp-build-client, multi client archs, /var/cache/chroot conflicts
Last modified: 2008-08-13 22:58:13 EDT
Description of problem: /usr/sbin/ltsp-build-client needs to keep separate yum /var/cache/chroot caches for each client architecture. The rpms themselves don't clash, but the mirrorlists.txt and repomd.xml files do. Version-Release number of selected component (if applicable): ltsp-server-5.1.15-1.fc9.x86_64 How reproducible: I think this is what I did Steps to Reproduce: 1.ltsp-build-client 2.ltsp-build-client --arch=x86_64 3.ltsp-build-client Actual results: fails to rebuild the i386 architecture in step 3 Expected results: Additional info:
This is a well known annoying problem. The only workaround is to rename the repositories in the kickstart file. ltsp-i386.ks: repo --name=released-9 --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-9&arch=i386 repo --name=updates-9 --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f9&arch=i386 repo --name=temporary-9 --baseurl=http://togami.com/~k12linux-temporary/fedora/9/i386/ Perhaps 'released-9-i386'. And we have to do it for all archs in a unique fashion.
> Perhaps 'released-9-i386'. > > And we have to do it for all archs in a unique fashion. That works. Tested with i386 and x86_64. Patch to */ltsp-*.ks attached.
Created attachment 314217 [details] patch to /etc/ltsp/kickstart/Fedora/*/ltsp-*.ks to avaoid /var/cache/chroot conflicts
Can't use that patch yet. We need common.ks to be reorganized so the arch-specific stuff lives in the arch specific ks files. You can have multiple %package sections between the kickstart files, this is one hint of how to split it up.
OK, I was thinking about the other problem, but this seemed to be a separable issue. Since the arch-specific ks files are arch-specific, can't the custom packages be added in there, rather than another include file? e.g. 9/ltsp-i386.ks ------------------------- # Kickstart Definition for Client Chroot for i686 and generic i386 ... %include ../common.ks kernel.i686 glibc.i686 %end 9/ltsp-i586.ks ------------------------- # Kickstart Definition for Client Chroot for i586 ... %include ../common.ks kernel.i586 glibc.i386 %end 9/ltsp-x86_64.ks # Kickstart Definition for Client Chroot for x86_64 ... %include ../common.ks kernel.x86_64 glibc.x86_64 %end then remove kernel and glibc from common.ks (and whatever else... openssl???) If this sounds ok in principle, I'll prepare another patch for you.
Created attachment 314234 [details] patches to: /etc/ltsp/kickstart/Fedora/* for both issues I've tested these, including --arch=i586 getting kernel.i586 in its chroot. (see next patch also)
Created attachment 314235 [details] add support for --arch=i586 Adds support for --arch=i586 as a special case, instead of degrading the normal i686 case.
> Adds support for --arch=i586 as a special case, instead of degrading the normal > i686 case. This actually doesn't help at all. Keeping the least common denominator i586 is the best we can do for this. Also arch output is never i586. Regarding the other patches, please try this. Rather than %end after the include, have %package and %end in both files independently. I subsequently learned that you can have multiple %package sections. Also did you checkout ltsp-trunk? Make sure you're starting out from the freshest version.
Created attachment 314253 [details] ltsp-trunk patch for the same, without i586 bits, with separate includes
Created attachment 314256 [details] new file: server/configs/kickstart/Fedora/common-i386.ks
Created attachment 314258 [details] new file: server/configs/kickstart/Fedora/common-x86_64.ks
Created attachment 314260 [details] new file: server/configs/kickstart/Fedora/common-i686.ks
Created attachment 314261 [details] new file: server/configs/kickstart/Fedora/8/ltsp-x86_64.ks
Created attachment 314262 [details] new file: server/configs/kickstart/Fedora/9/ltsp-x86_64.ks
Created attachment 314263 [details] new file: server/configs/kickstart/Fedora/10/ltsp-x86_64.ks
It is a bit time consuming to manually apply multiple patches. Could you please upload your own bzr tree at a URL somewhere? I could easily grab it then, and your name would show up on the checkin history, which is a good thing.
I hope I did this right. Its my first use of bzr. I've commited my changes in my local tree. http://john.ellson.com/ltsp-trunk/
Very close to proper. Please do the following. 1) Rename your local directory to ltsp-ellson or any other name to denote that it is your personal tree. 2) When you commit, begin the description with "Fedora: " before describing the commit. This is because this commit is specific to Fedora. Only checkins that are more general can commit without a prefix. Please upload this new tree. I can pull from it and push it with your name to the real ltsp-trunk.
Done: http://john.ellson.com/ltsp-ellson/
Named correctly, but I don't see your checkin now. bzr commit bzr push
Oops, I was hoping you weren't too quick. I just uncommitted and recommitted to fix up my email address in the log. Please try again. Next, I was trying to extend this to a ppc chroot, but discovered that this isn't going to work on a i386 server because ltsp-build-client tries to do a "setarch ppc". I suppose this is so that %post scripts work in the ppc rpms? Is there some other plan for getting chroots populated on incompatible architectures?
You pretty much need a ppc host in order to create a ppc chroot. But once the chroot is created we could tarball it and offer it for people to download. Then we find out if our magic in the default dhcpd.conf for ppc actually does anything. BTW, have you been following our project homepage and k12linux-devel-list? That is a lot more appropriate place to discuss this development than Bugzilla. Welcome onboard. =)