I'd like to submit new version of mondo/mindi/mindi-busybox for gentoo (as been masked for a while)
I'm now the new maintainer and want to provide regularly ebuild for the project.
Latest versions are available at : ftp://ftp.mondorescue.org/gentoo/1.6
*** Bug 84106 has been marked as a duplicate of this bug. ***
devs, is there anything missing to get this back into portage?
Its been quite some months without any comment on this :(.
The 2.2.4 version is usable with a little tweaking, those are the things I remember are needed:
1) rename mondo ebuild to mondo-rescue (already reported upstream and scheduled for next release)
2) replace app-cdr/cdrtools with virtual/cdrtools
3) add parted in RDEPEND for mondo-archive (reported upstream, IIRC was then added to mindi ebuild)
4) modify mindi-busybox to make it compile with recent sys-apps/util-linux.
It needs page.h, is affected by bug 168599 (see comment 2).
In x86 arch it can compile, backup and restore (not tested by me), in amd64 it can compile and backup, but ISO created are a little tricky to use due to a bug, many symlinks aren't recreated, so many binaries fail to run. I wasn't able to debug this (yet).
Created attachment 133233 [details]
Modified mindi-busybox ebuild to link page.h to /usr/src/linux
Tested with x86 and amd64, please check and report back.
is your offer still valid?
If yes, have you incorporated the fixes from Talamona Francesco?
I am thinking about proxy-maintaining mondo-rescue, that means
I'll commit ebuilds that you provide if they compile cleanly...
Now the installation process is smooth, just download the ebuilds from the folder /gentoo/nover/test (for example from the italian mirror: http://www.dcl-arch.it/pub/mondorescue/gentoo/nover/test/) digest and unmask them.
The backup is working too.
I'm having some hiccups at restore, which I'm going to report to the mondo rescue mailing list, maybe for an x86 arch it can run to completion.
My Offer is still valid.
I integrated most of Francesco patches and even had a report from him today, with new bugs to fix ;-)
Compilation isn't an issue anymore. There are still issues to solve at restore time, but gentoo isn't alone here !
Francesco, you may want to try with the previous ebuild of mindi-busybox (compiled statically) that should solve your issue in the mean time.
So if you agree to proxy the ebuilds, that's ok for me.
Ok, so which ebuilds should I use?
(In reply to comment #8)
> Ok, so which ebuilds should I use?
ftp://ftp.mondorescue.org/gentoo/nover/test is indeed the right one, as 2.2.5 is still in beta stage.
Once 2.2.5 becomes final, which shouldn't be too long, then the URL will be ftp://ftp.mondorescue.org/gentoo/nover
03-05 00:53 --> I have some questions about your mondo ebuilds
03-05 00:54 --> currently, there are app-backup/mondo-rescue, sys-apps/mindi and sys-apps/mindi-kernel in gentoo portage. at ftp://ftp.mondorescue.org/gentoo/nover/test,
there are mondo, mondo-rescue, mindi and mindi-busybox
03-05 00:55 --> I guess mondo and mondo-rescue are the same and they just have another name
03-05 00:55 --> but what about mindi-kernel (which seems to be gone) and mindi-busybox (which seems to be new)?
03-05 01:11 --> so you're gone again
03-05 01:11 --> *sigh*
ok, so I just committed these package:
they are still package.mask'ed though.
can someone please review/test them and report? thanks!
(In reply to comment #11)
> ok, so I just committed these package:
> they are still package.mask'ed though.
> can someone please review/test them and report? thanks!
They do compile, install and backup.
I'am unable to do a restore booting a virtual machine with the iso created, it seems it doesn't contain the binaries needed to restore.
I've made some screenshot of various warning messages during boot, should I attach them to this bug report?
(In reply to comment #13)
> They do compile, install and backup.
> I'am unable to do a restore booting a virtual machine with the iso created, it
> seems it doesn't contain the binaries needed to restore.
> I've made some screenshot of various warning messages during boot, should I
> attach them to this bug report?
Bruno, can you please have a look when the screenshots are here? Thanks.
Created attachment 147770 [details]
9 screenshots of qemu 64 bit vm
The zip contains the screenshots taken during boot a short after, with a little comment and the command used to run the backup.
Thanks for the report. Could you also attach your /var/log/mondoarchive.log from the original system, and also, if possible the /var/log/mondorestore.log on the restored sustem (USB should work)
Created attachment 147871 [details]
attachment 1 [details]: host log
I can provide this one
Created attachment 147875 [details]
attachment 2 [details]: guest hosed
I'm unable to mount an USB key. So no log provided :-(
Feel free to ask for more file/tests
I created a little confusion using the reserver word "attachment", sorry
Ok, you're using an old test version I made during the 2.2.5 beta phase. Now the official 2.2.5 is out and normally the bug you're encoutering was fixed by that revision:
r1883 | bruno | 2008-02-06 10:13:31 +0100 (mer, 06 fév 2008) | 2 lines
Chemins modifiés :
ReadAllLink rewritten again to try to fix bug reports on ML. Needs more tests.
Current rev is 1892
Could you please retry with the version available at:
Created attachment 148125 [details]
backup and VM boot log
I upgraded to latest mindi version, and these are the requested logs. It took a lifetime to boot qemu with USB and then the key wasn't recognized as a block device... Good old floppy images came to the rescue :-)
The errors I see in your logs are the following:
Making 16384KB boot disk...............cp: cannot overwrite directory `./lib' with non-directory
udev device manager found
cp: cannot overwrite directory `./lib' with non-directory
This one is mindi's fault. I'm working on it at the moment.
mkfs.vfat 2.11 (12 Mar 2005)
Syntax error at line 3 column 0 in file /etc/mtools/mtools.conf: unrecognized keyword
this one is not mindi's fault.
(In reply to comment #23)
> mkfs.vfat 2.11 (12 Mar 2005)
> Syntax error at line 3 column 0 in file /etc/mtools/mtools.conf: unrecognized
> this one is not mindi's fault.
It's because of mtoolstest, it found mtools.conf unconfigured. Is it relevant? Should I provide more logs, now that mtoolstest is ok, or I have to wait while you work on the other issue?
I've been able to reproduce and fix the issue mentioned here.
Could you test it's also fixed for you ?
ebuilds are here:
Thanks for your patience and work on this.
It works great (after renaming mondo to mondo-rescue!). I was able to install, make it run, and to compare and nuke the virtual machine: success!
Wolfram it's up to you :-)