Bug 462228
| Summary: | ltsp-client MUST NOT be installed on the server | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John Ellson <john.ellson> | ||||||||
| Component: | ltsp | Assignee: | Warren Togami <wtogami> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | rawhide | CC: | axel.thimm, dant, ugo.viti | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2008-10-24 10:33:51 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 188611 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
John Ellson
2008-09-14 15:35:50 UTC
Nice catch! I tried to guard against damage like this by checking for /etc/ltsp_chroot in other places, but I forgot about the /etc/sysconfig/mkinitrd file that it began dropping in the filesystem recently. Here is what I'm thinking we should do: 1) ltsp-client must not ship any /etc/sysconfig/mkinitrd. I am not sure if we should simply ship nothing at that path, or %ghost it. I am leaning toward nothing, because then it wouldn't accidentally remove a config file left by someone else when you remove ltsp-client. 2) %post of ltsp-client should check for the existence of /etc/ltsp_chroot. If it does exist, copy and forcefully overwrite whatever is already at /etc/sysconfig/mkinitrd. ltsp-client already runs ltsp-chroot-setup during %post so this can be easily added to the existing plugins of chroot-setup. 3) ltsp-trunk/server/scripts/k12linux/chroot-creator already creates /etc/ltsp_chroot before the RPMS are installed in the chroot, so we are covered here. Could you please test this plan? I am going into surgery tomorrow so things will be a bit rough for me for a while. We definitely must fix this before K12Linux LTSP Terminal Server F9 Beta 2. And yes, warnings should be added to the description of the ltsp-client package. I'll attach the 3 proposed patches here. The two bzr changes can be pulled from http://john.ellson.com/ltsp-ellson/ The first two patches fix this bug: 1. cvs patch to: devel/ltsp.spec 2. bzr patch to: client/chroot-setup/k12linux/030-configure-client The third patch fixes a problem with: ltsp-client-build --arch=x86_64 that I encountered during testing. (It was reverting to i386) 3. bzr patch to: server/plugins/ltsp-build-client/common/001-set-arch Created attachment 316707 [details]
ltsp.spec changes
Created attachment 316708 [details]
change to cp mkinitrd on client only
Created attachment 316709 [details]
fix for breakage to: ltsp-client-build --arch=x86_64
Hi, I confirm this behaviour, I spent last hour figuring out because after kernel upgrade (from 2.6.25 to 2.6.26) my server can't boot any more and because initrd was so bigger respect my working initrd :-) parsed /sbin/mkinitrd script and discovered that mkinird read /etc/sysconfig/mkinitrd, rpm -qif /etc/sysconfig/mkinitrd discovered that was owned by ltsp-client. this solved the problem: rpm -e ltsp-client mkinitrd -f /boot/initrd-2.6.26.3-29.fc9.i686.PAE.img 2.6.26.3-29.fc9.i686.PAE A better fix could be to write ltsp-client mkinitrd config to /etc/sysconfig/mkinitrd.ltsp and change the update kernel scripts for ltsp clients with extra parameters providing the correct path of ltsp mkinitrd config file? I think this must be a priority update, because inadvertently installing ltsp-client can render unbootable the system. Best Regards I agree that this must be fixed soon. I have been in rough shape lately recovering from major surgery. I will make sure this is fixed soon. To be clear however, why are you installing ltsp-client on a non-LTSP system? Welcome back Warren. Hope your recovery is going well. Let me know if I can do anything to help with this. Regarding your clarification, arguably an LTSP-server is an LTSP-system ;-) John, I have reviewed your patches.
--- server/plugins/ltsp-build-client/common/001-set-arch 2008-02-12 12:09:37 +0000
+++ server/plugins/ltsp-build-client/common/001-set-arch 2008-09-15 01:50:44 +0000
@@ -36,7 +36,7 @@
x86_64|amd64)
case "$(uname -m)" in
x86_64)
- ARCH=amd64
+ ARCH=x86_64
common/001-set-arch is not used by any distribution. Everyone supplies their own 001-set-arch to override the common plugin because it is too flawed. It is possible that there remains a problem in our Fedora/001-set-arch, but it needs to be fixed there if so.
--- client/chroot-setup/k12linux/030-configure-client 2008-08-21 17:19:13 +0000
+++ client/chroot-setup/k12linux/030-configure-client 2008-09-15 01:47:25 +0000
@@ -49,3 +49,6 @@
# TEMPORARY: /var/lib/pulse/ must exist (we can remove this soon)
mkdir -p /var/lib/pulse/
+
+# install /etc/sysconfig/mkinitd for client kernel upgrades
+cp -f /etc/sysconfig/ltsp-mkinitrd /etc/sysconfig/mkinitrd
This shouldn't be necessary during ltsp-build-client time, but perhaps we will use it anyway because we want to override whatever is in /etc/sysconfig/mkinitrd in the case of upgrading to a newer version of ltsp-client.
I used basically your approach with slight changes. Will be released in ltsp-5.1.25. *** Bug 462993 has been marked as a duplicate of this bug. *** *** Bug 465132 has been marked as a duplicate of this bug. *** This was fixed in ltsp-5.1.26-1.fc9 in F9 updates for a while now. |