I know. It’s been a long process. And I’m not even fully satisfied with the results, as we do have unresolved bugs in this version. But as it also fixes some critical others that were expecting for a long time (3+ months), I didn’t want to delay more the release of this version.
So here it is. mondo 3.0.3, mindi 2.1.4 and mindi-busybox 1.18.5-3 are now availble from the master ftp server. And as given in the announce, most of the distributions (nearly 100 of them) also have packages ready for use. Once more couldn’t do it without project-builder.org š
The detailed change logs are available for mindi, mindi-busybox and mondo.
Among the main fixes brought by this version, a much better support of SLES 10, SLES 11 SP1, SLES11 SP2, especially for LVM and device exclusion, grub, keyboard.
I also received very, very valuable contributions from users, which helps producing a better version of course, and reduce the time of the resolution of the problem in the upstream version. Thanks again for helping ! Including on some very old bugs. And Victor being one of the most prolific.
There are even some new features such as the support of swaplabel or the inclusion of all tools part of minimal.conf now in the first boot part.
As said earlier, some bugs ar not fixed yet. I passed most of the week trying to fix the automatic mode where CTRL-ALT-DEL doesn’t work. I added support in 3.0.3 of an inittab file, but whatever the conf I use fo now, it doesn’t trigger a reboot when using the magic key or sending it from the KVM monitor. So be warned and use with care. I’ll report on the busybox ML as I still have the issue with 1.20.2, and try to get help from this community. Could well trigger the release of a new mindi-busybox (and maybe mindi) soon after this one.
In the serie of un-fixed bugs for lack of time for this time are some that a user reported as more important to fix soon:
- Ticket #628: 3.0.2-1 Fail to Restore from External Hard Disk – This is a very big issue here.
- Ticket #641: Specifying the Same Backup to NFS via CLI=Success via GUI=Fail – Although it is possible to work around this problem it is preventing the creation of exceptional backups by users with little knowledge of Mondo. A fix will be most welcome and will present a more appropriate impression of Mondo.
- Ticket #640: mondo.tmp.xxxxx & mondo.scratch.xxxxx Issues – This is not a critical issue. A fix will help with backup management and housekeeping tasks.
I globally agree these are also important to fix (even if less than Ticket 627). I also think we need to work on Ticket 656 as well. I’d like to get your comments as well in order to prioritize the fixes in the next version, as I can’t work full time on MondoRescue, so need to choose where to put my efforts.
Tags: Linux, Mondorescue, Open Source, project-builder.org, SLES
Bruno Cornec's Blog 
2013/05/23 at 17:15 |
Hi, would it be possible to have a “long time support version” of MondoRescue ? Changing version is a long process in production environment that implies a lot of testing. A stable version with bug correction, something that converge slowly to have no bug would be apreciated.
2013/05/24 at 00:54 |
I fully agree with you that it would be nice. And the only probability that it could happen would be that I could work full time on this. But I’m not payed to work on MondoRescue. I’m payed to be a FLOSS Technology Architect for HP, which sometimes include activities around MondoRescue, and that’s probably why you still have a quite well working tool today.
HP is able to deliver support around MondoRescue however, so you could ask the same question to your HP representative, so I could be asked to deliver it (and thus be payed for that so have more time to do it).
Anyway a no bug version is not for tomorrow, looking at the code base as it is still today. My rewrite is progressing very slowly so I’m still maintaining the current code base the best I can, trying to avoid breaking stuff, and bringing very few new features in fact, compared to what I’d like to do š¦ So the 3.0.x branch is already a stable one !!
Now even moving fro 3.0.3 to 3.0.4 will require some testing, so any change is costly in production, whatever the number of lines of code that I changed below the scene. A single line can break much more tuff sometimes than one hundred added to support a new feature completely separated from the rest of the code.
So long time support has a cost. And quite a high one. If you’re willing to pay for this, I may consider creating an “autoentrepreneur” structure to perform that. Why not after all, even if that’s really not my goal as of today. You can also try to hire another consultant that would provide that maintenance branch for you (hopefully reversing the patches upstream). do not expect to get that for free. This is more boring so would probably not be done for fun.
That’s all about the Red Hat/SUSE business model BTW.
2013/11/12 at 04:32 |
Yeah, I love the tag line. Just noticed it on a Mondorescue session.
:>