Bug#403454: mindi does rm -Rf /home !
On Sat, Dec 23, 2006 at 09:55:29AM +1100, Andree Leidenfrost wrote: Would you be able to send your two patches to the BTS, one attached to #403454 and the second one attached to a new bug report for the LABEL issue? I think this way we'd minimise the risk of me getting it wrong. (I am a bit nervous because of the freeze as I have really only one shot to get it right.) Sure. Attached here is an oneliner fix for rm -Rf /home I've also reported the other one to BTS (no bug# yet, still waiting for it to process the message) But I'll be visiting LCA2007 in Sydney in mid-January, so direct interrogation is an option :) Hey, I'll be there as well, so it would be great to catch up! :-) However, I defintiely want to fix the issue at hand and the label issue as well as soon as possible. I know, I see the etch is frozen now. Both patches are trivial, so they shouldn't be a problem. -- Opinions above are GNU-copylefted.--- mindi/mindi (révision 919) +++ mindi/mindi (copie de travail) @@ -2985,7 +2985,7 @@ FindIsolinuxBinary FindLiloBinary fi -grep -F $TMP_ROOT /proc/mounts | grep -F tmpfs /dev/null 2 /dev/null TMP_ROOT=/home LogIt Changing TMP_ROOT to $TMP_ROOT because you're using tmpfs for /tmp\n ; # tmpfs doesn't like Mindi and /tmp, for some reason +grep -F $TMP_ROOT /proc/mounts | grep -F tmpfs /dev/null 2 /dev/null TMP_ROOT=/home/tmpmondo mkdir -p $TMP_ROOT LogIt Changing TMP_ROOT to $TMP_ROOT because you're using tmpfs for /tmp\n ; # tmpfs doesn't like Mindi and /tmp, for some reason rm -f /tmp/mindi_lo trap Aborted SIGTERM DONE=\r\t\t\t\t\t\t\t\tDone.
Bug#403454: mindi does rm -Rf /home !
Hi Bruno, Thanks a lot for your response! On Thu, 2006-12-21 at 23:23 +0100, Bruno Cornec wrote: Matija Nalis said on Thu, Dec 21, 2006 at 09:35:08PM +0100: both have been fixed promptly in upstream. Ok I'm happy that they are now indeed fixed. I really like debian users as they give feedback ;-) I might send you a patch to try against mindi-2.20-1. Would you be able to test it? I think you don't need to pass time on that Andree. I'll publish soon 2.2.1 which will fix that. You'll just have to update your packages. Unfortunately, a new upstream version in Debian is not currently an option as we are in freeze. I can really only fix RC bugs at the moment. I intend to get this fixed over the weekend, i.e. no later than 24 Dec 06. I'd prefer that we fix the remaining differences in mindi ;-) Maybe this could be something to sort out during LCA2007? FYI, the server currently runs your mindi 2.20-1 recompiled for sarge with only patches for above two problems, and it works ok. Great ;-) But I'll be visiting LCA2007 in Sydney in mid-January, so direct interrogation is an option :) Yep, I'll be there too ;-)) Bruno. -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#403454: mindi does rm -Rf /home !
Hi Matija, Thanks a lot for your response! On Thu, 2006-12-21 at 21:35 +0100, Matija Nalis wrote: On Thu, Dec 21, 2006 at 10:38:35PM +1100, Andree Leidenfrost wrote: Looking at the mailing list thread it looks like the patch listed in both the mailing list thread and in trac ticket 100 is the same and did not work because you wrote in the mailinglist thread in response to the patch: [...] Mondo doesn't run now, but at least it does not destroy the /home. Last version that I had used before, and which had created backups successfully was 2.06-4 (Andree's debian package, rebuilt for sarge) [...] No, that patch actually DID fix the rm -Rf /home problem correctly. It is just that I had _two_ major problems to start with: (1) the critical one in trac ticket 100 about rm -Rf /home, (I reported this one in Debian BTS as #403454) (2) the important bug about misdetection of LABEL= in /etc/fstab on debian because of hardcoded /bin/cut path (wrong path on debian) see http://sourceforge.net/mailarchive/message.php?msg_id=37518492 (I did not report this one on Debian BTS yet. Should I?) Yes, that would be very good. We are in freeze, so having bugs properly documented before I can address them was one essential prerequisite to get the fix into Etch before the release. both have been fixed promptly in upstream. Ok, I see. Thanks for clarifying that. I might send you a patch to try against mindi-2.20-1. Would you be able to test it? I intend to get this fixed over the weekend, i.e. no later than 24 Dec 06. I can run tests (one run per day -- big server, takes a long time) and give feedback until 28 Dec; after that I'll be unavailable until end of January. FYI, the server currently runs your mindi 2.20-1 recompiled for sarge with only patches for above two problems, and it works ok. Would you be able to send your two patches to the BTS, one attached to #403454 and the second one attached to a new bug report for the LABEL issue? I think this way we'd minimise the risk of me getting it wrong. (I am a bit nervous because of the freeze as I have really only one shot to get it right.) Andree Leidenfrost @ Debian Developer Sydney - Australia But I'll be visiting LCA2007 in Sydney in mid-January, so direct interrogation is an option :) Hey, I'll be there as well, so it would be great to catch up! :-) However, I defintiely want to fix the issue at hand and the label issue as well as soon as possible. -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#403454: mindi does rm -Rf /home !
Andree Leidenfrost said on Sat, Dec 23, 2006 at 09:47:48AM +1100: I think you don't need to pass time on that Andree. I'll publish soon 2.2.1 which will fix that. You'll just have to update your packages. Unfortunately, a new upstream version in Debian is not currently an option as we are in freeze. I can really only fix RC bugs at the moment. Well upstream is the king. Let me propose you something: I can publish a new 2.2.0-3 which is equal to 2.2.1 if it's more convenient for you. Of course I'm cheating. But I have a problem if Etch only contains 2.2.0 on my side. I'd prefer that we fix the remaining differences in mindi ;-) Maybe this could be something to sort out during LCA2007? That was in my planning for LcA 2007 ;-) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpzjzMZvXi0e.pgp Description: PGP signature
Bug#403454: mindi does rm -Rf /home !
tags 403454 + pending thanks Hi Matija, Thank you for reporting this bug and for giving the pointers below. Looking at the mailing list thread it looks like the patch listed in both the mailing list thread and in trac ticket 100 is the same and did not work because you wrote in the mailinglist thread in response to the patch: [...] Mondo doesn't run now, but at least it does not destroy the /home. Last version that I had used before, and which had created backups successfully was 2.06-4 (Andree's debian package, rebuilt for sarge) [...] So, I need to look into this in a bit more detail. In the latest stable mindi SVN revision [1005] it looks like the code has just been commented out: FindIsolinuxBinary FindLiloBinary fi # BERLIOS: Remove as too dangerous and now useless #grep -F $MINDI_TMP /proc/mounts | grep -F tmpfs /dev/null 2 /dev/null MINDI_TMP=/home/tmpmondo mkdir -p $MINDI_TMP LogIt Changing MINDI_TMP to $MINDI_TMP because you're using tmpfs for /tmp \n ; # tmpfs doesn't like Mindi and /tmp, for some reason trap Aborted SIGTERM DONE=\r\t\t\t\t\t\t\t\tDone. I am just not sure whether commenting this out depends on other changes or not. [Bruno: Would you be able to shed some light on this?] I might send you a patch to try against mindi-2.20-1. Would you be able to test it? I intend to get this fixed over the weekend, i.e. no later than 24 Dec 06. Best regards, Andree On Sun, 2006-12-17 at 11:22 +0100, Matija Nalis wrote: Package: mindi Version: 2.20-1 Severity: critical Sometimes mindi decides to set TMP_ROOT to /home (if /tmp is mounted as tmpfs), and then at the cleanup phase does rm -Rf $TMP_ROOT. In practice, this resulted in losing whole /home directory. thread describing the problem in detail can be found at http://sourceforge.net/mailarchive/message.php?msg_id=37329155 The bug has since been fixed upstream, see http://trac.mondorescue.org/ticket/100 -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#403454: mindi does rm -Rf /home !
On Thu, Dec 21, 2006 at 10:38:35PM +1100, Andree Leidenfrost wrote: Looking at the mailing list thread it looks like the patch listed in both the mailing list thread and in trac ticket 100 is the same and did not work because you wrote in the mailinglist thread in response to the patch: [...] Mondo doesn't run now, but at least it does not destroy the /home. Last version that I had used before, and which had created backups successfully was 2.06-4 (Andree's debian package, rebuilt for sarge) [...] No, that patch actually DID fix the rm -Rf /home problem correctly. It is just that I had _two_ major problems to start with: (1) the critical one in trac ticket 100 about rm -Rf /home, (I reported this one in Debian BTS as #403454) (2) the important bug about misdetection of LABEL= in /etc/fstab on debian because of hardcoded /bin/cut path (wrong path on debian) see http://sourceforge.net/mailarchive/message.php?msg_id=37518492 (I did not report this one on Debian BTS yet. Should I?) both have been fixed promptly in upstream. I might send you a patch to try against mindi-2.20-1. Would you be able to test it? I intend to get this fixed over the weekend, i.e. no later than 24 Dec 06. I can run tests (one run per day -- big server, takes a long time) and give feedback until 28 Dec; after that I'll be unavailable until end of January. FYI, the server currently runs your mindi 2.20-1 recompiled for sarge with only patches for above two problems, and it works ok. Andree Leidenfrost @ Debian Developer Sydney - Australia But I'll be visiting LCA2007 in Sydney in mid-January, so direct interrogation is an option :) -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403454: mindi does rm -Rf /home !
Matija Nalis said on Thu, Dec 21, 2006 at 09:35:08PM +0100: both have been fixed promptly in upstream. Ok I'm happy that they are now indeed fixed. I really like debian users as they give feedback ;-) I might send you a patch to try against mindi-2.20-1. Would you be able to test it? I think you don't need to pass time on that Andree. I'll publish soon 2.2.1 which will fix that. You'll just have to update your packages. I intend to get this fixed over the weekend, i.e. no later than 24 Dec 06. I'd prefer that we fix the remaining differences in mindi ;-) FYI, the server currently runs your mindi 2.20-1 recompiled for sarge with only patches for above two problems, and it works ok. Great ;-) But I'll be visiting LCA2007 in Sydney in mid-January, so direct interrogation is an option :) Yep, I'll be there too ;-)) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403454: mindi does rm -Rf /home !
Package: mindi Version: 2.20-1 Severity: critical Sometimes mindi decides to set TMP_ROOT to /home (if /tmp is mounted as tmpfs), and then at the cleanup phase does rm -Rf $TMP_ROOT. In practice, this resulted in losing whole /home directory. thread describing the problem in detail can be found at http://sourceforge.net/mailarchive/message.php?msg_id=37329155 The bug has since been fixed upstream, see http://trac.mondorescue.org/ticket/100 -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
