Using rescuecd !?

[David Timms]

Chris Snook wrote:
> William Case wrote:
...
>> I have a list of about 20 questions that could be answered and explained
>> so that I would feel confident in using the rescuecd rather than feeling
>> like I am making it up as I go along.
...
> This isn't unnecessary incomprehensibility, it's failsafe simplicity.
> 
>> Any ideas?  Can these changes be considered a bug?
> 
> The existing behavior is simple, functioning as designed, widely 
> documented, and familiar to a lot of people.  There's nothing inherently 
> wrong with rescue mode *for what it was designed to do*.  The problem is 
> that rescue mode wasn't designed for a new user.  We really need a 
> user-friendly recovery console, but it should be an application that 
> works on top of the existing rescue mode that the experts already know, 
> not a replacement for it.

It would be nice to prompt user yes/no to chroot to the users system if 
found, rather than requiring the typing.

Other things that I consider could be useful; perhaps in a ncurses text 
interface like setup:
- test if there is bootable grub -> suggest needs fixing and perform 
best guess grub-install xxx
- test if there is grub.conf points to kernel bits, and root= is OK.
- test if there is at least a kernel's boot bits installed / available
- test if the /etc/fstab points to legit things {eg for times when eg a 
partition has become unmountable, or swap part is no longer there}.
- offer to backup and mod fstab to # non-essential bits {like 
non-root/boot drives}
- test rpm command works
- test yum works
- offer to rpm -V important == needed to boot packages, mentioning 
missing packages considered essential. {eg after --nodeps fu's}
- offer to rpm -Va
- offer to fsck
- offer to selinux relabel {listing files modified, and logging for 
later perusal}.
- offer to make some room on an empty fs
- offer to install a kernel from release|updates|updates-testing
- offer info on how to show the grub menu - and set grub.conf to wait 
for user
- offer to copy a heap of kernel boot parameters into a grub entry - so 
that the user can delete most and try one at a time out.
- {better} offer to copy a current grub entry, name it X modified, and 
allow the user to select only compatible parameters to try. {and set it 
default}
- offer to copy a current grub entry and append runlevel -  with 
descriptions
- offer to install rescue mode onto the hard disk in a separate 
partition or in the /boot if there is enough room, and add a grub option 
  for it.
- an option to not chroot, and instead attempt to start the user's 
system as a virtual machine ...?

- offer to remove options it added to grub/ fstab etc.
- change rescue cd to have a basic menu with rescue as the default 
option {rather than an attempt at upgrade / install}
- run package-cleanup --problems
- check for issues like the F6 wrong arch kernel install.
- update clamAV defs and perform a system scan.
- update chkrootkit / rkhunter and run a rk scan.
- gui to run gparted or s-c-lvm
- lvm tools assistance.
- test root/ a user login files {passwd etc} are coherent
- all tests, from the lowest level - boot up, or a particular test if 
the user has an idea.
- easy way to ftp/http a file from a local network {eg no internet 
access} or from the internet {eg an older kernel or whatever} ~ mc ?

Well, that is my twenty or so things that I have had to do over the last 
few years. William, what would you add to that ?

By the way, you could create a fedoraproject wiki page so that 
interested parties could put/edit their ideas into one place. Once this 
becomes considered you could file a RFE [request for enhancement] in 
bugzilla.

DaveT.