Red Hat Bugzilla – Bug 55556
RFE:Give the installer the ability to save state
Last modified: 2007-04-18 12:37:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.5) Gecko/20011011
Description of problem:
It would be nice to have a feature where the installer can save it's state
( current position in the install process, user entered information like
package selection, disk partitioning, etc. ) as it runs, so that a failed
install can be restarted without having to re-do things like package
selection, disk partitioning, etc. For that matter, if it dies after
copying the packages to disk, it would be nice if one could restart an
install without it re-copying the packages, as well.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Actual Results: na
Expected Results: na
It would be nice if this saved state information, from the installer, could
be saved to a floppy or other media, at the user's discretion, and then
reused for future installs as well.
I.E., if I spend 20 minutes hand selecting the exact packages I want to
install, I would like for that info to be part of what is saved, so I can
do another install later, and retrieve the package selection from disk.
katzj, couldn't this be done with slight modifications to the autokickstart and
interactive kickstart stuff? Basically, when an install crashes, would it be
possible to dump the debug contents to a floppy, and then dump the data from the
installation so far to a floppy too? Then when you start the install again, say
'linux ks=floppy', and anaconda would pull in whatever information it had, and
then do an interactive kickstart install and just present the screens that had
no entries on the floppy? This would be really cool.
It's easy to dump information... it's harder to have it do exactly what you
expect. Kickstart information doesn't contain information on type of install
(eg Workstation, Server, etc) which has an effect on what options are passed.
And assuming the initial state is correct isn't quite what is wanted easier.
There should be some way to get the expected outcome though... just requires a
bit more thought on implementation details.
+1 nospamacolivernospam at nc dot rr dot com
I've helped a number of people install linux and this is usually their biggest
complaint and reason for having me help.
I haven't had a total crash in the installer type problem myself since the 5.x
releases ( I always bring my own CDs ) with the exception of network installs
which is understandable. (but this could help with this as well)
+1 :) (i've had a couple crashes where this feature would have been really
I can't remember when my last non-network based RH-installer crash was. . I'm
pretty sure it was 6.0 or 6.1. The CDs were good, the previous version worked
on there, so I think that box just skipped a release until the next version.
I'd have reported it but the website didn't work so well for me in those days
and "installer didn't work" was about all the info I could have provided because
it just used to hang.
It might be nice to have that tracing especially for network-based installs.
I relize this might not pass the 90% rule as the installer gets more stable.
But BAD CDs happen. RH makes them, I make them, etc. As a stop gap measure
that should pass the 90% rule:
For CDs I think a solid CRC check would go along way. It just looks real bad
when a CD produced by RH goes wrong and they don't know why. (A message that
says "CRC check failed go buy yourself another copy" would go far and be ahead
of those boys in redmond whose installer does reall funny things when
scratched..) I relize the CRC could hang on the check but "Checking that the CD
is valid (s to skip)" printed right before it hung would probably be a good big
fat hint to most people. Do this in text mode before all the fancy stuff comes up.
Deferring this bug at this time, we may revist in the future. We write out a
kickstart file currently with most the information required to kickstart a clone
of the machine being installed. The need to restart crashed anaconda attempts
from a save file is not currently a priority.
I do not see us implementing this request.