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.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
