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: > > 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. 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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
