Bug#505111: will suggest removal from testing
Well, it seems that other people haven't taken an interest in the bug, and we've now frozen, again. As there isn't a resolution in sight, I'll add a hint at the end of August for the removal of the package unless there's significant progress to fixing the issue. Neil -- liw the hacklab room is the one with a pirate flag, and a venezuelan flag, and a third flag liw the other hacklab room is the other hacklab room -- 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/20100807130820.ga3...@halon.org.uk
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 -- 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
Bug#505111: will suggest removal from testing
On Sat, 07 Aug 2010, Henrique de Moraes Holschuh wrote: 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? Well, my whole reply came out with a lot more annoyed tone than I wanted, and for that I apologise. I do understand that we don't have resources to fix this right now. But I still think we must do *something* simple (such as documenting this shortcoming somewhere people will see before the image has a chance to cause damage, i.e. in its boot screen) before releasing. Even if it means asking for a round of translations for the boot text yet again. -- 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/20100807135400.gb9...@khazad-dum.debian.net
Bug#505111: will suggest removal from testing
On Saturday 07 August 2010, Neil McGovern wrote: As there isn't a resolution in sight, I'll add a hint at the end of August for the removal of the package unless there's significant progress to fixing the issue. I still feel this is an overreaction as only the original reporter has ever seen the issue in practice. No one else has ever reported being affected by the issue. The described use case requires an combination of factors which is quite unlikely to occur in practice. I'm also CCing Colin Watson as he is the original author of rescue mode and its primairy maintainer. Maybe he'll be motivated to look into this or comment. -- 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/201008071631.24318.elen...@planet.nl
Bug#505111: will suggest removal from testing
On Sat, Aug 07, 2010 at 04:31:22PM +0200, Frans Pop wrote: On Saturday 07 August 2010, Neil McGovern wrote: As there isn't a resolution in sight, I'll add a hint at the end of August for the removal of the package unless there's significant progress to fixing the issue. I still feel this is an overreaction as only the original reporter has ever seen the issue in practice. No one else has ever reported being affected by the issue. The described use case requires an combination of factors which is quite unlikely to occur in practice. I'm also CCing Colin Watson as he is the original author of rescue mode and its primairy maintainer. Maybe he'll be motivated to look into this or comment. I just uploaded a fix that makes RAID assembly an explicit rescue menu item. -- Colin Watson [cjwat...@debian.org] -- 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/20100807144316.gp12...@riva.ucam.org
Bug#505111: will suggest removal from testing
On Sat, 07 Aug 2010, Frans Pop wrote: On Saturday 07 August 2010, Neil McGovern wrote: As there isn't a resolution in sight, I'll add a hint at the end of August for the removal of the package unless there's significant progress to fixing the issue. I still feel this is an overreaction as only the original reporter has ever seen the issue in practice. No one else has ever reported being affected I have seen it happen, as well. by the issue. The described use case requires an combination of factors which is quite unlikely to occur in practice. Fortunately. But the whole automount devices and partitions causes problems on _other_ failure scenarios, too. It is just plain not safe behaviour for rescue media. -- 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/20100807161122.ga23...@khazad-dum.debian.net
Bug#505111: will suggest removal from testing
On Sat, 07 Aug 2010, Colin Watson wrote: On Sat, Aug 07, 2010 at 04:31:22PM +0200, Frans Pop wrote: On Saturday 07 August 2010, Neil McGovern wrote: As there isn't a resolution in sight, I'll add a hint at the end of August for the removal of the package unless there's significant progress to fixing the issue. I still feel this is an overreaction as only the original reporter has ever seen the issue in practice. No one else has ever reported being affected by the issue. The described use case requires an combination of factors which is quite unlikely to occur in practice. I'm also CCing Colin Watson as he is the original author of rescue mode and its primairy maintainer. Maybe he'll be motivated to look into this or comment. I just uploaded a fix that makes RAID assembly an explicit rescue menu item. Thank you! -- 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/20100807161142.gb23...@khazad-dum.debian.net
Bug#505111: will suggest removal from testing
hi folks, unless you object soon, i will suggest the removal of these packages from testing. the rationale is (a mixture of these will apply to the package in question) - old rc bug with no resolution in sight - otherwise buggy - low popcon - not in stable please note that a removal from testing is not really that bad, the package would migrate back in in no time once the rc-bug is fixed! cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Bug#505111: will suggest removal from testing
On Wednesday 24 March 2010, Robert Lemmen wrote: unless you object soon, i will suggest the removal of these packages from testing. the rationale is (a mixture of these will apply to the package in question) This package should not be removed. The bug is partly theoretical and only affects a minority of use cases. -- 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/201003241451.42392.elen...@planet.nl
Bug#505111: will suggest removal from testing
On Wed, Mar 24, 2010 at 02:51:41PM +0100, Frans Pop wrote: This package should not be removed. The bug is partly theoretical and only affects a minority of use cases. ok, so you think it should be squeeze-ignore? do you think it should be ignored for any release in the future? or downgraded? having bugs which are marked as grave, but at the same time are ignored forever seems like a slightly suboptimal usage of the BTS... cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Bug#505111: will suggest removal from testing
On Wednesday 24 March 2010, Robert Lemmen wrote: On Wed, Mar 24, 2010 at 02:51:41PM +0100, Frans Pop wrote: This package should not be removed. The bug is partly theoretical and only affects a minority of use cases. ok, so you think it should be squeeze-ignore? do you think it should be ignored for any release in the future? or downgraded? having bugs which are marked as grave, but at the same time are ignored forever seems like a slightly suboptimal usage of the BTS... I think it should be fixed, but that the bug is not sufficient reason for removal of the package. Unfortunately the D-I team is understaffed. Leaving the bug at it's current (technically correct) severity will maybe help get other people to take in interest in it. -- 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/201003241526.3.elen...@planet.nl
