Re: Rescue mode

["Alexander Maryanchick" <Sasha@GDev.msk.ru>]

>>> 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?
This is an issue for discussion.
/bin/shutdown is one of possibilities.
> Where are you proposing to store this flag so that LILO (or bootloader
> of choice) can get to it?
Boot sector of boot or root partition for example.

>> (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?
I don't like this idea. What if I use kdm?

>> A kernel issue!
> Yes, I can see that you think so.
I don't pretend to role of hard-core kernel hacker. But
- I think this feature is possible (because I know how to implement it in
windows.)
- I see no way to implement it via scripts or R3 applications, because
        - They also may be corrupted or deleted.
        - Require successful boot for their work.

>>>> - 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?
Yep.
> 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.
:-).
Kernel knows if it must run xdm at startup, right.
Then why it can not check what really happened?

>>> 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?
Yes, and the tree of critical files can be found by grep in rc.d
(without kernel collaboration) or by logging of forks and opens.

>> 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.
Oops... :-(. Sorry.
Clear definition is a hard task, especially with poor english.
What about such compomise:
I WISH the feature.
If your understand what I wish and think it is not kernel issue -
then I'll agree with you, and sorry for offtopic :-).
...Have we at least the definition of "boot"?

>> 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?

    xinitrc corrupted -> reboot:
boot 1 (xdm); crash
boot 2 (single or  emergency) <-- MUST BE ELIMINATED.
    Got sash instead of xdm :-(.
    Find the corrupted file (may require some minutes (or even hours) of
work and some reboots)
boot 3 (rescue) - old configuration
boot 4: Finally !

In 99% of cases the system can remember the latest stable configuration
and automaticaly restore it in case of crash.
This can save to user a lot of time.

>> 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?
An interesting question.
Unfortunately, windows is a large store for good ideas.
(The interface from Apple, NT kernel from NeXT, object architecture from
DCE, etc.
and of cause, many of their own ideas)
But fortunately, almost none of these ideas are really realized.
For example I can cite the advertisement:
"Windows 98 supports PnP, but unlike in Windows 95 it works..." :-)))
However, may be I shall not so fastidious when Billy will be in his place -
in jail. :-)
Sorry for 100% offtopic.


                            Best regards.

                                        Alexander.


-
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