Re: Rescue mode

[Greg Mildenhall <greg@networx.net.au>]

On Sun, 7 Mar 1999, Alexander Maryanchick wrote:
> >> -  to show rescue menu only in two cases:
> >>     - The previous boot failed.
> > Define "failed".
> Two (or more) variants (analogs for "FS was not cleanly unmounted"):
> - Crashed. (Flag "ShutdownSuccessful" is not set)
How do you decide whether the shutdown was successful?
Do you want /bin/shutdown to set this flag somewhere before it shuts
everything down?
Where are you proposing to store this flag so that LILO (or bootloader
of choice) can get to it?

> - Flag "BootSuccessful" is not set.
I have no idea where you intend to set this.

> (For example, login, xdm,... not crashed in 5 second)
You would like xdm to set it if it notices it's been running 5 seconds?
Each to their own, I suppose, but now you are getting out of the realms of
what a distributor would be willing to do. You'll have to customise.

> A kernel issue!
Yes, I can see that you think so. You just haven't explained where the
kernel comes into it yet. As far as I (and probably anyone) can tell, you
are suggesting an interaction between userspace and bootloader.

> 
> >> - to have always ready to use system image (kernel, startup scripts,
> etc.).
> > A distribution issue.
> Nope. See below.
Whatever you write below can't make having a ready-to-use system image a
non-distribution issue. Perhaps you mean you have a kernel issue to
discuss somewhere below and mistyped "Yes, but see below."

> >> - updated automaticaly after every successful configuration change.
> A kernel issue. It requires reliable "BootSuccessful" flag.
The plot thickens. From this I can glean that you want the kernel to set
this "BootSuccessful" flag, right?
On what do you intend the kernel to base it's estimation of the
successfulness of the boot? Certainly it will be hard to convince Linus to
let the scheduler check for a process of commandline "xdm*" exceeding 5
seconds of runtime, and set a flag at that point.

> > Define "successful configuration change".
> 1. Critical files was changed (not the same in root and rescue image)
So a selection of files in /etc/, /boot/, and /usr/X11R6/bin, then?

> 2. At least one boot was not failed (the definition was given ealier)
I could really handle a clearer and more detailed  definition than that,
if you would so oblige me.

> Mustdie(TM) uses another method.
> In rescue mode it ignores non-critical conf. files (autoexec) at boot and at
> run time and non-critical drivers (recognized by flags in header).
> This way is also a kernel issue.
Really? Is it not easier to omit these things from the alternate kernel
image and startup scripts than to give the kernel a database of drivers
it must not load and initscripts it should refuse to run in the event of a
given flag being set?
Perhaps you misunderstand what a kernel is? I would recommend David A.
Rusling's excellent text which you can find at:
http://metalab.unc.edu/linux/LDP/tlk/tlk.html
amongst other places.

> > Given a definition, I am sure you can easily implement a method to copy
> > whatever you consider to be the necessary configuration information to
> > wherever LILO knows to look for it.
> Yes, I can implement an ugly hack, but I can not implement
> even 100% of windows rescue mode functionality.
What functionality do you feel would be missing?
Perhaps if you chose to implement this idea in userspace instead you would
find it easier to provide more of the functionality you desire, and could
avoid such "ugly hacks".

> IMHO, if feature is worse then in mustdie - then the feature is absent.
So you feel that any feature that is in windows is only one step up from
absent? If this is the case, it could go some way to explaining why
you are finding it so hard to come up with a good implementation of a
windows feature? Perhaps a good implementation is impossible, and the best
we can hope for is "marginally better than absent".

-Greg Mildenhall

-
Linux-future: thinking about the future of the Linux kernel
Archive:      http://humbolt.nl.linux.org/lists/
Wish list:    http://users.ox.ac.uk/~mert0236/linux-future.html