Bug#315004: raidtools2: Ignoring /etc/raidtab breaks upgrade to mdadm
Hello, On Tue, 2005-08-09 at 20:44 +0100, Martin Michlmayr wrote: Hi Adam (et al.), Sorry for not responding earlier but I've been travelling and quite busy and completely forgot about this issue. As I said, I don't know what the ideal situation is. The nice thing about the transition package is that it provides some kind of upgrade path: it depends on the package you need and has a NEWS entry telling you what to do. It will work for most (easy) configurations. It will not work for complex systems. I assumed the sys admins of such people would either read the docs or could deal with breakage. But who knows. Maybe a debconf message should be added; maybe the package should be removed altogether. If you think you have a good solution, please talk to the stable release manager and NMU this package at will. Thanks, I'll produce a patch by next week and give this a try. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315004: raidtools2: Ignoring /etc/raidtab breaks upgrade to mdadm
Hi Adam (et al.), Sorry for not responding earlier but I've been travelling and quite busy and completely forgot about this issue. As I said, I don't know what the ideal situation is. The nice thing about the transition package is that it provides some kind of upgrade path: it depends on the package you need and has a NEWS entry telling you what to do. It will work for most (easy) configurations. It will not work for complex systems. I assumed the sys admins of such people would either read the docs or could deal with breakage. But who knows. Maybe a debconf message should be added; maybe the package should be removed altogether. If you think you have a good solution, please talk to the stable release manager and NMU this package at will. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315004: raidtools2: Ignoring /etc/raidtab breaks upgrade to mdadm
Greetings, First, sorry about the very negative tone of my message. I had meant to start it with First the good news: thanks for the transitional raidtools2 package! But with emotions running high and a rush to get this out at the end of the day, I neglected this important part of the report. And thank you Matthijs for the link into the release notes, I should have caught that. On Tue, 2005-06-21 at 22:12 +0100, Martin Michlmayr wrote: * Adam C Powell IV [EMAIL PROTECTED] [2005-06-19 20:02]: The transition from raidtools2 to mdadm breaks all installations with more than one RAID array That the transitional raidtools2 package entered sarge just days before the release (and that sarge had zero testing cycles, unlike potato or woody) means that there was just about zero testing for it, and it is too late for those admins who like me have since rebooted had the same problem. But for those who have not needed to reboot, please upload a fix (translate raidtab to something mdadm understands?) or a *prominent* debconf warning (maybe even a warning in the raidtools2 description) to testing-proposed-updates. The fact that raidtools2 entered sarge relatively late doesn't really have much to do with it since it was pretty clear what would break and what wouldn't. However, our assumption was that most people would use RAID devices that are set to autoconfiguration (and therefore don't need a configuration file for mdadm to work) and that the rest would be experienced enough to read the release notes or NEWS.Debian after an upgrade. While there's no debconf message, there is a clear NEWS.Debian message which explains exactly what you need to do. I see. Unfortunately, I focused on the Issues to be aware of for sarge section, and since it wasn't there, assumed my upgrade would go smoothly, particularly since I had been using sarge on this server since late March. Perhaps this notice, or a reference to it, should go in section 5 for r1? With 104 NEWS.Debian files on my system, it's probably best to assume that people will not read those during the upgrade. I'm not sure about what to do. Obviously, the situation isn't ideal but I thought a dummy package depending on mdadm and including a NEWS.Debian was better than nothing at all - since it will work for most people. In any case, I'm not sure how many people will not have upgraded before r1 given that kernel security fixes are schedulded to come out before. If you have any idea about a good solution that is acceptable for r1, I'd certainly like to hear it. But personally I'm not sure what to do. I understand. For the most part it's spilt milk at this point. Would you accept a patch with a prominent debconf warning? Although there are hundreds of debconf dialogs during a typical upgrade, at least one can be sure that this crosses the admin's screen, in contrast to NEWS.Debian. I suppose this illustrates why we need to be more careful with testing during the release process next time... Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315004: raidtools2: Ignoring /etc/raidtab breaks upgrade to mdadm
Hi, We know that there was no testing cycle for Sarge (badly enough) but we made a release note for this and you can find it here: http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#s-mdadm If we make a patch that does the transition from /etc/raidtab to mdadm.conf, i'm afraid that we get more trouble. Regards, Matthijs Mohlmann Adam C Powell IV wrote: Package: raidtools2 Version: 1.00.4 Severity: grave Justification: breaks reboot for sites with multiple RAID arrays Tags: sarge Greetings, The transition from raidtools2 to mdadm breaks all installations with more than one RAID array because /etc/raidtab is ignored during autodetection. I discovered this surprise on reboot, when the order of my site's RAID arrays was switched, and disabling autodetection (which intuition said would use /etc/raidtab) of course resulted in none of them being mounted. So I tried to remove mdadm but of course raidtools2 depends on it (since raidtools2 is empty). (Actually, a grad student noticed the problem when booting our server after a scheduled power outage while I was away. He of course had no idea of what was happening, so our site was down for the better part of a day as a result! The only clue I had was that mdadm had been installed as a dependency of raidtools2...) That the transitional raidtools2 package entered sarge just days before the release (and that sarge had zero testing cycles, unlike potato or woody) means that there was just about zero testing for it, and it is too late for those admins who like me have since rebooted had the same problem. But for those who have not needed to reboot, please upload a fix (translate raidtab to something mdadm understands?) or a *prominent* debconf warning (maybe even a warning in the raidtools2 description) to testing-proposed-updates. If the right place for this is mdadm then please reassign it. I would be happy to produce a candidate patch. Thanks, -Adam signature.asc Description: OpenPGP digital signature
Bug#315004: raidtools2: Ignoring /etc/raidtab breaks upgrade to mdadm
* Adam C Powell IV [EMAIL PROTECTED] [2005-06-19 20:02]: The transition from raidtools2 to mdadm breaks all installations with more than one RAID array That the transitional raidtools2 package entered sarge just days before the release (and that sarge had zero testing cycles, unlike potato or woody) means that there was just about zero testing for it, and it is too late for those admins who like me have since rebooted had the same problem. But for those who have not needed to reboot, please upload a fix (translate raidtab to something mdadm understands?) or a *prominent* debconf warning (maybe even a warning in the raidtools2 description) to testing-proposed-updates. The fact that raidtools2 entered sarge relatively late doesn't really have much to do with it since it was pretty clear what would break and what wouldn't. However, our assumption was that most people would use RAID devices that are set to autoconfiguration (and therefore don't need a configuration file for mdadm to work) and that the rest would be experienced enough to read the release notes or NEWS.Debian after an upgrade. While there's no debconf message, there is a clear NEWS.Debian message which explains exactly what you need to do. I'm not sure about what to do. Obviously, the situation isn't ideal but I thought a dummy package depending on mdadm and including a NEWS.Debian was better than nothing at all - since it will work for most people. In any case, I'm not sure how many people will not have upgraded before r1 given that kernel security fixes are schedulded to come out before. If you have any idea about a good solution that is acceptable for r1, I'd certainly like to hear it. But personally I'm not sure what to do. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315004: raidtools2: Ignoring /etc/raidtab breaks upgrade to mdadm
Package: raidtools2 Version: 1.00.4 Severity: grave Justification: breaks reboot for sites with multiple RAID arrays Tags: sarge Greetings, The transition from raidtools2 to mdadm breaks all installations with more than one RAID array because /etc/raidtab is ignored during autodetection. I discovered this surprise on reboot, when the order of my site's RAID arrays was switched, and disabling autodetection (which intuition said would use /etc/raidtab) of course resulted in none of them being mounted. So I tried to remove mdadm but of course raidtools2 depends on it (since raidtools2 is empty). (Actually, a grad student noticed the problem when booting our server after a scheduled power outage while I was away. He of course had no idea of what was happening, so our site was down for the better part of a day as a result! The only clue I had was that mdadm had been installed as a dependency of raidtools2...) That the transitional raidtools2 package entered sarge just days before the release (and that sarge had zero testing cycles, unlike potato or woody) means that there was just about zero testing for it, and it is too late for those admins who like me have since rebooted had the same problem. But for those who have not needed to reboot, please upload a fix (translate raidtab to something mdadm understands?) or a *prominent* debconf warning (maybe even a warning in the raidtools2 description) to testing-proposed-updates. If the right place for this is mdadm then please reassign it. I would be happy to produce a candidate patch. Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
