[K12OSN] LTSP 4.4.1 client booting fails
sales at ecosolutions.com.au
Thu Jun 8 02:19:28 UTC 2006
On Wed, 2006-06-07 at 13:21 -0700, Eric Harrison wrote:
> Gavin Chester wrote:
> > On Tue, 2006-06-06 at 16:01 -0700, Eric Harrison wrote:
> >> Gavin Chester wrote:
> > This time around with 4.4.1, I produced two types of failures:
> > 1/ I broke a successful install by adding new packages. I suspect
> > trouble arose because of an unsuccessful install of the NVidia kernel
> > module, but I have no proof.
> The Livna repository has the NVidia drivers pre-packages. Proprietary
> drivers are still bad, but having them properly packaged at least makes
> it less risky...
> rpm --enablerepo=livna install kmod-nvidia xorg-x11-drv-nvidia
Thanks for pointing me to that, Eric. I previously tried installing
nvidia by yumex, but the module reported failure to load on boot. I
will give the other (above) a try when I've backed up my currently
working system ;-) I can't say nvidia caused problems, but it was at
that time my network services 'switched off' and clients would not get
> > 2/ When re-installing several more times, I again chose an LTSP system,
> > but somehow caused it fail (as an LTSP system) by choosing to
> > 'customise' my package selection. I tried manually configuring
> > services, following the LTSP documentation, but didn't succeed.
> I played around a bit with this on the K12LTSP 5.0 beta, which is not
> exactly the same but its behavior should be similar.
> Once I picked "customize", I could de-select the LTSP packages. It seems
> to me that this is reasonable behavior, if you *specifically* tell the
> installer you don't want it to install the LTSP packages it should not
> install the LTSP packages (even if you picked the LTSP install category).
> The other issue I found is that if I de-selected ALL packages EXCEPT the
> LTSP packages, the were a couple of oddities such as the dhcp client was
> not installed (i.e. eth1 could not use DHCP to get an IP address). While
> this is clearly an out-liner issue, it is one that could likely be dealt
> with in a reasonable fashion. I'll see what I can do.
When I say "failed installs" I mean that K12 did not function
automagically after install. To be specific, in a couple of failed
installs I chose the 'custom' install option and then made sure I chose
the LTSP and K12 packages. In other failed installs I chose the 'LTSP'
install option and then went ahead and individually chose a smorgasboard
of packages, making sure to choose the LTSP and K12 packages again.
When I finally got install to work automagically I chose the 'LTSP'
install option and then did NOT dare touch any package selections (save
substituting kde for gnome).
> The initialize script is installed with the LTSP packages. If you don't
> install the LTSP packages, the LTSP initialization script won't be
> installed either.
> > Perhaps a feature request, if I could be so bold of your hard-pressed
> > time:
> > After installing, a script runs at first boot to see if the K12LTSP
> > packages were chosen.
> One issue is that K12LTSP is often used to build stand-alone desktops,
> proxy servers, etc. To support such multiple purposes, I can't FORCE the
> installation of the LTSP packages. As long as the LTSP packages are
> optional (installed by default with the LTSP option, not installed by
> default with the Fedora option), it is possible for people to shoot
> themselves in the foot if they choose to customize the packages that are
> In the feature request above, it is suggested that firstboot check to
> see if the LTSP packages were installed... how does that fix the case
> where the user manually chose not to install the LTSP packages?
> It is a real interesting challenge making the system both flexible and
> foolproof ;-)
And a fantastic and tireless job you have been gifting the community for
many years now, Eric. Thank you.
You seem to have misunderstood my feature request, though. I meant that
if a user does not choose any LTSP/K12 optional packages (goes for a
stock Fedora install, say) then they are not affected by any K12
firstboot scripts. If they have chosen any/all of the LTSP/K12 optional
packages then a script at firstboot scans to see that all components are
installed and activated, or runs the initialisation script, as needed.
Kind of a backup to your install scripts :-)
That sort of request may be very problematic to implement, but would
catch instances where someone faithfully thought that they would end up
with a K12 terminal server, but by choosing the packages in a
'non-standard' way, they instead ended up with a vanilla Fedora install.
Just a thought. I'm wiser to it now, but others may need it _blatantly_
documented if the firstboot concept is not (or, can not be) developed
as a feature. I guess if you do such a good job of making things easy
for people, they always ask to have it made even easier ;-)
More information about the K12OSN