Rescue mode

[Martin Sivak]

Hi,

I'd like to start discussion about the rescue mode purpose and look in the newui environment.

Currently we have just a shell encapsulated in very simple menu (with the possibility of calling firstaidkit tasks .. of which we have about two working..).

I see the following common use cases:

1) Somebody with a hosed bootloader, but the system and hardware are OK
2) Somebody who needs to do partitioning stuff to fix something
3) Reseting root password for users who forgot
4) Real rescue when hardware fails (including a graphic card malfunction)
5) Rescue tasks for corporate customers using serial console hardware (with possibly not working NICs or network)
6) Our QA sometimes used kickstarted rescue to do testing tasks (commonly in virt environment with no NICs)

I suppose we could use the hub and spoke model for the first three cases, but the fourth and fifth one is going to be harder. We cannot rely on GUI when the cause might be in graphic adapter (or there is no adapter at all).

So tell me what you think or if you know more use cases.

--
Martin Sivák
[e-mail]
Red Hat Czech
Anaconda team / Brno, CZ

[John 'Warthog9' Hawley]

On 06/27/2012 02:11 PM, Martin Sivak wrote:
> Hi,
>
> I'd like to start discussion about the rescue mode purpose and look in the newui environment.
>
> Currently we have just a shell encapsulated in very simple menu (with the possibility of calling firstaidkit tasks .. of which we have about two working..).
>
> I see the following common use cases:
> Somebody with a hosed bootloader, but the system and hardware are OK
> Somebody who needs to do partitioning stuff to fix something
> Reseting root password for users who forgot
> Real rescue when hardware fails (including a graphic card malfunction)
> Rescue tasks for corporate customers using serial console hardware (with possibly not working NICs or network)
> Our QA sometimes used kickstarted rescue to do testing tasks (commonly in virt environment with no NICs)
>
> I suppose we could use the hub and spoke model for the first three cases, but the fourth and fifth one is going to be harder. We cannot rely on GUI when the cause might be in graphic adapter (or there is no adapter at all).
>
> So tell me what you think or if you know more use cases.

Use cases I think I typically use:
------
- Fixing or repairing raid arrays and similar things
- a mini, console only, live cd (that's trivially available)
- An easy way to get access to rsync and a couple of terminal windows
(keeping the ability to have multiple terminals would be *EXCEEDINGLY*
useful)
- Imaging machines
- Fixing grub because it's broken, again.

Most of these I really do just want to get dropped down to a shell,
without any other clutter and just go from there.    I idea of having
more automated tools for some things, like fixing the bootloader, but
maybe those should be presented separately from the rescue mode itself?
 I think the idea people have of rescue is to drop them down to the
barest metal possible to see what's wrong, and a gui may just add to the
problems.  Maybe separating out the more user-friendly automatable tasks
(again fixing the boot loader), into something like `repair` vs.
`rescue` might make sense?  Then if you select `repair` you can just
present a list of common easy push button fix options, similar to what
windows provides in their "boot repair" screens.  Just my $0.02 though.

A mini-request for them would be that yum actually worked, so that you
can add things on an as-needed basis (right now it doesn't, at least
when I tried it on an f16 one the other day)

- John 'Warthog9' Hawley
Chief Kernel.org Administrator

[J.H.]

On 06/27/2012 02:11 PM, Martin Sivak wrote:
> Hi,
>
> I'd like to start discussion about the rescue mode purpose and look in the newui environment.
>
> Currently we have just a shell encapsulated in very simple menu (with the possibility of calling firstaidkit tasks .. of which we have about two working..).
>
> I see the following common use cases:
> Somebody with a hosed bootloader, but the system and hardware are OK
> Somebody who needs to do partitioning stuff to fix something
> Reseting root password for users who forgot
> Real rescue when hardware fails (including a graphic card malfunction)
> Rescue tasks for corporate customers using serial console hardware (with possibly not working NICs or network)
> Our QA sometimes used kickstarted rescue to do testing tasks (commonly in virt environment with no NICs)
>
> I suppose we could use the hub and spoke model for the first three cases, but the fourth and fifth one is going to be harder. We cannot rely on GUI when the cause might be in graphic adapter (or there is no adapter at all).
>
> So tell me what you think or if you know more use cases.

Use cases I think I typically use:
------
- Fixing or repairing raid arrays and similar things
- a mini, console only, live cd (that's trivially available)
- An easy way to get access to rsync and a couple of terminal windows
(keeping the ability to have multiple terminals would be *EXCEEDINGLY*
useful)
- Imaging machines
- Fixing grub because it's broken, again.

Most of these I really do just want to get dropped down to a shell,
without any other clutter and just go from there.    I idea of having
more automated tools for some things, like fixing the bootloader, but
maybe those should be presented separately from the rescue mode itself?
 I think the idea people have of rescue is to drop them down to the
barest metal possible to see what's wrong, and a gui may just add to the
problems.  Maybe separating out the more user-friendly automatable tasks
(again fixing the boot loader), into something like `repair` vs.
`rescue` might make sense?  Then if you select `repair` you can just
present a list of common easy push button fix options, similar to what
windows provides in their "boot repair" screens.  Just my $0.02 though.

A mini-request for them would be that yum actually worked, so that you
can add things on an as-needed basis (right now it doesn't, at least
when I tried it on an f16 one the other day)

- John 'Warthog9' Hawley
Chief Kernel.org Administrator

[Kushal Das]

On Thu, Jun 28, 2012 at 1:41 AM, Martin Sivak  wrote:
> Somebody with a hosed bootloader, but the system and hardware are OK
> Somebody who needs to do partitioning stuff to fix something
> Reseting root password for users who forgot
> Real rescue when hardware fails (including a graphic card malfunction)
> Rescue tasks for corporate customers using serial console hardware (with possibly not working NICs or network)
> Our QA sometimes used kickstarted rescue to do testing tasks (commonly in virt environment with no NICs)
>
> So tell me what you think or if you know more use cases.

The one we (here in India) hear most of the times from the students is
missing grub  by windows (dual boot systems) and then they are
clueless on how to rescue. These are mostly first time users from
colleges.

Kushal

[Moray Henderson]

> -----Original Message-----
> From: Martin Sivak [mailto:[e-mail]]
> Sent: 27 June 2012 21:11
>
> Hi,
>
> I'd like to start discussion about the rescue mode purpose and look in
> the newui environment.
>
> Currently we have just a shell encapsulated in very simple menu (with
> the possibility of calling firstaidkit tasks .. of which we have about
> two working..).
>
> I see the following common use cases:
> Somebody with a hosed bootloader, but the system and hardware are OK
> Somebody who needs to do partitioning stuff to fix something
> Reseting root password for users who forgot
> Real rescue when hardware fails (including a graphic card
>
> malfunction)
> 5) Rescue tasks for corporate customers using serial console hardware
> (with possibly not working NICs or network)
> 6) Our QA sometimes used kickstarted rescue to do testing tasks
> (commonly in virt environment with no NICs)
>
> I suppose we could use the hub and spoke model for the first three
> cases, but the fourth and fifth one is going to be harder. We cannot
> rely on GUI when the cause might be in graphic adapter (or there is no
> adapter at all).
>
> So tell me what you think or if you know more use cases.

I've used a customised rescue mode for a long time, with a dialog-based menu.  It has functions to

- Reinstall grub
  - Re-create the initrd file
  - Change root password
  - Configure and start dropbear for ssh access
  - Restore system from backup tape or online backup

We have standard tape and online backup strategies for our servers so we know what's needed for a restore.  We did have "prepare system for modem dial-in", but we're removing that because hardly any of our system admins know what a modem is any more ;-)  We've also been considering adding 3G-dongle support.

Moray.
“To err is human; to purr, feline.”