Red Hat Bugzilla – Bug 462228
ltsp-client MUST NOT be installed on the server
Last modified: 2008-10-24 06:33:51 EDT
Description of problem:
If ltsp-client is mistakenly installed on the ltsp server (or any, non ltsp-client host) it silently modifies the behavior of mkinitrd such that future upgrades of the kernel will fail - e.g.by trying to mount root via NFS.
Minimally the desription returned from "yum --info ltsp-client" should provide loud and clear warnings.
Better would be for ltsp-client to refuse to install if it is not being installed into an ltsp chrooted image.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. on a regular fedora box, yum install ltsp-client
future kernel upgrades fail by looking for root over nfs
Should not be possible to install ltsp-client on the server.
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]
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
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-220.127.116.11-29.fc9.i686.PAE.img 18.104.22.168-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.
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 @@
case "$(uname -m)" in
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.