Bug#505111: will suggest removal from testing
On Sat, 07 Aug 2010, Neil McGovern wrote:
> Well, it seems that other people haven't taken an interest in the bug,
> and we've now frozen, again.
Yes. And the justifications in the bug report for not fixing the underlying
issues go like this: we should take actions which are guaranteed to destroy
user data on certain specific scenarios in our "rescue" image, because we
must insist on some "userfriendly" functionality that simply cannot be made
100% safe in all scenarios.
Duh.
Can we PLEASE rename this from "rescue" image to "safe mode" image, and
document in its boot screen that it should NEVER be used in a system with
filesystem or RAID problems?
Because right now, our "rescue" image is certainly unsuitable for dealing
with entire classes of filesystem and block device problems. A true rescue
system does not autostart RAID volumes (*and* has a kernel that won't do it
automatically either), or lvm, or mounts partitions. It does not touch
anything in the system being rescued without explicit command by the
operator (which *CAN* be made user friendly if one wants, using GUIs or
text-mode menu interfaces, etc).
This has nothing to do on how common the data loss scenarios described
in this bug report are (and indeed the RAID component problem is
unlikely to be the most common scenario). It has everything to do with
these scenarios REALLY happening in practice (regardless of their
rarity) and being scenarios where one would try to use a "rescue" image
to clean things up, and our "rescue" image could make the problem much
worse when used.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: