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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100807133736.ga9...@khazad-dum.debian.net
