Hi there, Last night there was an update to mondo-rescue and mindi (NOTE: there was no update to mindi-kernel) and I cannot run mondoarchive anymore. The following error message: ------------------------------- root@kallisto mdke # mondoarchive Initializing... See /var/log/mondo-archive.log for details of backup run. Checking sanity of your Linux distribution Please install 'mindi'. I cannot find it on your system. There may be hyperlink at http://www.mondorescue.com which will take you to the relevant (missing) package. Could not ascertain mindi's version number. You have not installed Mondo and/or Mindi properly. Please uninstall and reinstall them both. Fatal error... Please reinstall Mondo and Mindi. ---FATALERROR--- Please reinstall Mondo and Mindi. Please try the snapshot (the version with 'cvs' and the date in its filename)to see if that fixes the problem. Please don't bother the mailing list withyour problem UNTIL you've tried the snapshot. The snapshot contains bugfixeswhich might help you. Go to http://www.mondorescue.org/download/download.htmlFor more information. Log file: /var/log/mondo-archive.log FYI, I have gzipped the log and saved it to /tmp/MA.log.gz Mondo has aborted. Execution run ended; result=254 Type 'less /var/log/mondo-archive.log' to see the output log -------------------------- I have uninstalled mondo-rescue, mindi and mindi-kernel and reinstalled them without success. I am using an x86 system, but the packages are ~x86. I will also report a further problem I have had with these packages which i have a hunch is related. With the previous versions (i.e. before last night's updates), I made backup cds beautifully, burned them, but then when I booted them in "compare" mode, I got the error: FATAL: kernel too old. I was using the DEFAULT kernel from mindi, not my gentoo kernel. I reported this error to the mondo-rescue list and the developer told me that he thought this is a gentoo bug. Is there something screwy going on with the mondo-rescue, mindi and mindi-kernel packages? Reproducible: Always Steps to Reproduce: 1. Upgrade mondo-rescue and mindi (~x86 tree) 2. Run mondoarchive 3. Actual Results: Fails with the error reproduced in the bug Expected Results: Work! root@kallisto mdke # emerge info Portage 2.0.51-r14 (default-linux/x86/2004.3, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.10-gentoo-r4 i686) ================================================================= System uname: 2.6.10-gentoo-r4 i686 Mobile Intel(R) Celeron(R) CPU 2.00GHz Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Jan 6 2005, 19:47:39)] distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r5 sys-devel/automake: 1.8.5-r1 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.2-r7 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -ftracer -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -ftracer -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distcc distlocks sandbox sfperms" GENTOO_MIRRORS="http://mir.zyrianes.net/gentoo/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.uk.gentoo.org/gentoo-portage" USE="x86 X acpi alsa audio avi bash-completion berkdb bitmap-fonts cdr crypt divx4linux dvd dvdread encode f77 fam flac font-server foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 imagemagick imlib jpeg libg++ libwww mad mikmod motif mpeg ncurses nls nptl nptlonly oggvorbis pam pdflib perl png python quicktime readline real sdl slang sse ssl svga tcpd tiff truetype truetype-fonts type1-fonts xml2 xmms xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, PORTDIR_OVERLAY
please post the contents of /var/log/mondo-archive.log
Created attachment 49378 [details] /var/log/mondo-archive.log yes sorry I should have done that straight away! Find attached the /var/log/mondo-archive.log
--8<-- running: mindi -V > /tmp/mondo-run-prog-thing.tmp 2> /tmp/mondo-run-prog-thing.err --------------------------------start of output----------------------------- sh: line 1: mindi: command not found --------------------------------end of output------------------------------ ...ran with res=32512 Could not ascertain mindi's version number. You have not installed Mondo and/or Mindi properly. Please uninstall and reinstall them both. --8<-- note the "sh: line 1: mindi: command not found". Is mindi in your path?!
here is a view of /usr/sbin/mindi: it is a dud link: lrwxrwxrwx 1 root root 22 Jan 23 21:46 mindi -> /usr/share/mindi/mindi That file is not there, and not only that, afaics its not anywhere! Let me know if there is anything further I can do, if not then I suppose this file is no longer to be found in the package!! Matt
ok, there's a problem with the mindi-1.11 tarball. let me get this sorted out with the mondo devs. please remerge 1.10 in the meantime.
Have you had an luck on this? I think that the kernel image provided in the old tarball was also out of date: it seems to be a 2.4 kernel whereas the rest of the stuff is built with 2.6 headers. I got the error "FATAL: kernel too old" when booting it. thanks, Matt
no luck, they don't seem to care about the issues I posted to the list :-(
Has Mondo-rescue been resolved or not? in package.mask it referes to bug 106497 yet when you pull this up it doesn't seem to exist anymore When I request open bugs "mondo" I get three Could someone please clarify is mondo-rescue resolved I see it wants to emerge mindi-0.86, mindi-kernel-1.0 and mondo-rescue-1.65. Are these working? Thanks barry
(In reply to comment #8) > Has Mondo-rescue been resolved or not? > in package.mask it referes to bug 106497 > yet when you pull this up it doesn't seem to exist anymore > When I request open bugs "mondo" I get three > Could someone please clarify is mondo-rescue resolved > I see it wants to emerge mindi-0.86, mindi-kernel-1.0 > and mondo-rescue-1.65. > Are these working? > Thanks > barry > When I try to access bug # 106497, I get "access denied". What's up with that? I've been using Mondo 2.04 successfully for quite some time. /usr/sbin/mindi needs to be a link to /usr/share/mindi/mindi. I posted a diff to run against mindi and some instructions on how to make it work. I thought I posted it on gentoo's forums, but I can't find it. I know I posted it on the mondorescue forum, but that site seems to be dead now.
can't access this bug either (106497). Access denied
IIRC details about security related bugs may be restricted to developer only...
well, I can't access it either...
(In reply to comment #12) > well, I can't access it either... > Does anyone have a projected timescale when this may be resolved? I can archive my 2.4 kernel successfully, but I presently have no way to back up my 2.6 kernel.
Just for your information, I'm re-working the build process concerning mindi and mondo and hope to have soon the possibility to produce ebuild version of mondo/mindi at the same time as I produce RPMs currently. I still need to read a bit in order to understand the process here, but at least my tool chain is up to date to host gentoo now ;-) I'll announced progress asap. Bruno.
Hello, I've just published a new version of mondo/mindi which fixes some bugs, and could begin to provide solutions for gentoo issues reported here. I've also tried to work on a ebuild version updated, which I attach here for comment. Let me know how to procede now.
Created attachment 93706 [details] ebuild proposal for mindi
Created attachment 93707 [details] ebuild proposal for mondo
I published a first set of packages with the ebuild files (the mindi one had a bug) at ftp://ftp.mondorescue.org/gentoo/1.6/ let me know if you think there are still issues with them. Bruno.
I don't see any big problems, apart from some commented code and non-quoted ${D}.
I have corrected (I hope) these 2 problems. What are then the next steps (I do not forget that some bugs are still in the code). And what is gentoo's process to deal withwhat are upstream bugs vs packagng bugs ?
New versions available at ftp://ftp.mondorescue.org/gentoo/1.6
Ha! You fell into the common pitfall of quoting ${A} :) In this case no problem, but if multiple files would have been downloaded they would have been seen as one. (won't work of course) So don't quote ${A} :) Upstream (code) bugs, depending on their severity keep a package in ~arch, package .mask, or completely remove it from portage. Ebuild issues are of concern of the Gentoo devs. I would say, if your ebuild installs the programs such that they fully work, your work is done on them now. (The minor issues are corrected when they go into the tree.) Is the security issue from bug #106497 fixed?
Thanks for your feedback. Changed again at the same URL. I will followup on bug #106497 in the appropriate bug report.
This bug should now be closed and a new version of mondo and mindi should be added from upstream (which I maintain) using the latest 2.2.0 (mondo) and 1.2.0 (mindi) available from ftp://ftp.mondorescue.org/gentoo/1.6 I will shortly add the new required mindi-busybox package as well there.
I haven't tried a restore yet, but I was able to successfully create a pair of backup DVDs with the latest version of mondo and mindi (2.2.0 and 1.2.0) on an amd64 dual-core system. Ignore mindi-kernel, and use the command switch '-k /boot/kernel-2.6.17-gentoo-r8', replacing the kernel path with whatever kernel you're actually booting from. I had to mess around a little with the ebuild files to get it to build (though only to correct a couple of minor differences between file naming conventions). Looks like it is ready to add back into portage once the ebuild file naming issues are corrected. Jeff
A newer version (2.2.1) with ebuild packages is available at ftp://ftp.mondorescue.org/gentoo/1.6 Please provide feedback and info for return back in gentoo's tree.
Although I needed to rename the ebuild to mondo-rescue-2.2.3, the install went juste fine. I ran into an error during the backup : ---evalcall---1--- Making catalog of / ---evalcall---2--- TASK: [***********.........] 55% done; 13:16 to go ---evalcall---E--- Done. Dividing filelist into sets Dividing filelist into sets. Please wait. Fatal error... call_filelist_chopper() -- filelist not found! Here's the log : http://rdv.shadowprojects.fr/mondo-archive.log Someone has managed to compile mindi-busybox (1.2.1 or 1.2.2) with success ?
Humm the version you run, is the old one (from your log): --------------------------------end of output------------------------------ ...ran just fine. :-) Mondo Archive v2.10 --- http://www.mondorescue.org running on i386 architecture ----------------------------------------------------------- This is NOT 2.2.3 Your path may have an issue.
Sorry, I have uploaded the wrong file. http://rdv.shadowprojects.fr/mondoarchive.log is the good file (Mondo Archive v2.2.3-1355).
The problem is clearly shown here: [Main] libmondo-filelist.c->mondo_makefilelist#1786: mkdir -p /Available/mondo.scratch.339/mondo.scratch.26702/archives [Main] libmondo-filelist.c->mondo_makefilelist#1788: cp -f /Available/tmp.mondo.16587/tmp.mondo.22675/tmpfs/filelist.full /Available/mondo.scratch.339/mondo.scratch.26702/archives/ [Main] libmondo-filelist.c->mondo_makefilelist#1790: mv -f /Available/tmp.mondo.16587/tmp.mondo.22675/tmpfs/filelist.full /Available/tmp.mondo.16587/tmp.mondo.22675 [Main] libmondo-filelist.c->mondo_makefilelist#1791: Freeing variables [Main] libmondo-filelist.c->mondo_makefilelist#1797: Exiting Done. Dividing filelist into sets Dividing filelist into sets. Please wait. [Main] libmondo-filelist.c->call_filelist_chopper#214: filelist /Available/mondo.scratch.339/mondo.scratch.26702/archives/filelist.full not found [Main] newt-specific.c->fatal_error#380: Fatal error received - 'call_filelist_chopper() -- filelist not found!' What I do not understand is why when the dir is created and the file copied to it, then just after it's not there anymore :-( Are cp and mv with -f special commands on gentoo ? Could they return true when an error occurs ? Could you also retry specifying a -S and -T dir just in case ?
$ mondoarchive -O -E "/usr/portage/distfiles/ /var/tmp/portage/portage/" -r -N -k /boot/vmlinuz-2.6.19-gentoo-r5 -s 4810m -9 -e -l GRUB -d /dev/cdrom1 -S /var/tmp/isos -T /var/tmp The error is the same : [Main] libmondo-filelist.c->mondo_makefilelist#1784: Copying new filelist to scratchdir [Main] libmondo-filelist.c->mondo_makefilelist#1786: mkdir -p /var/tmp/isos/mondo.scratch.4378/mondo.scratch.29228/archives [Main] libmondo-filelist.c->mondo_makefilelist#1788: cp -f /var/tmp/tmp.mondo.14848/tmp.mondo.27136/tmpfs/filelist.full /var/tmp/isos/ mondo.scratch.4378/mondo.scratch.29228/archives/ [Main] libmondo-filelist.c->mondo_makefilelist#1790: mv -f /var/tmp/tmp.mondo.14848/tmp.mondo.27136/tmpfs/filelist.full /var/tmp/tmp.m ondo.14848/tmp.mondo.27136 [Main] libmondo-filelist.c->mondo_makefilelist#1791: Freeing variables [Main] libmondo-filelist.c->mondo_makefilelist#1797: Exiting Done. Dividing filelist into sets Dividing filelist into sets. Please wait. [Main] libmondo-filelist.c->call_filelist_chopper#214: filelist /var/tmp/isos/mondo.scratch.4378/mondo.scratch.29228/archives/filelist.full not found [Main] newt-specific.c->fatal_error#380: Fatal error received - 'call_filelist_chopper() -- filelist not found!' [Main] newt-specific.c->fatal_error#398: OK, I think I'm the main PID. [Main] newt-specific.c->fatal_error#406: I'm going to do some cleaning up now. [Main] newt-specific.c->fatal_error#407: killall mindi 2> /dev/null /var/tmp/isos/mondo.scratch.4378/mondo.scratch.29228/archives/ is empty I'm gonna try to look if the file is really moved to the temporary directory during the catalog building.
filelist.full created in /var/tmp/tmp.mondo.15512/tmp.mondo.10242/tmpfs/filelist.full (final size 26 Mb) filelist.full copied to /var/tmp/isos/mondo.scratch.18785/mondo.scratch.15580/archives/ (directory is empty !) filelist.full moved to /var/tmp/tmp.mondo.15512/tmp.mondo.10242 (directory contain tmpfs/) Why is mondo trying to move filelist.full to its parent folder ? So, the cp and mv aren't working !!! linux ~ # ll /var/tmp/tmp.mondo.15512/tmp.mondo.10242 total 12K drwx------ 3 root root 4,0K mai 4 09:10 . drwxr-xr-x 3 root root 4,0K mai 4 09:10 .. drwxr-xr-x 2 root root 4,0K mai 4 09:20 tmpfs linux ~ # ll /var/tmp/tmp.mondo.15512/tmp.mondo.10242/tmpfs/ total 26M drwxr-xr-x 2 root root 4,0K mai 4 09:20 . drwx------ 3 root root 4,0K mai 4 09:10 .. -rw-r--r-- 1 root root 26M mai 4 09:20 filelist.full -rw-r--r-- 1 root root 17 mai 4 09:19 skeleton.txt.new linux ~ # ll /var/tmp/isos/mondo.scratch.18785/mondo.scratch.15580/archives/ total 8,0K drwxr-xr-x 2 root root 4,0K mai 4 09:10 . drwx------ 3 root root 4,0K mai 4 09:10 ..
Strangely enough I had the same error myself this morning. After analysis on my side, it was because a filesystem was full and so the copy could not be performed correctly. Could you check on your side as well ? What fives df -T ? Also in your log, you also have that issue: libmondo-fork.c, line 375: Command failed (Cannot allocate memory) Do you have any swap available on the system ? What gives free ?
linux ~ # df -T Sys. de fich. Type 1K-blocs Occupé Disponible Capacité Monté sur /dev/hda3 ext3 37879048 7320368 28634496 21% / udev tmpfs 122580 2668 119912 3% /dev cachedir tmpfs 37879048 7320368 28634496 21% /lib/splash/cache /dev/hda1 ext2 101086 16402 79465 18% /boot shm tmpfs 122580 0 122580 0% /dev/shm (I know it's bad to have only one partition) linux ~ # free total used free shared buffers cached Mem: 245160 239168 5992 0 832 25932 -/+ buffers/cache: 212404 32756 Swap: 489972 272308 217664 And to be more accurate : http://linux.irmcmaghreb.org/server-config/
Could you try rather with "-S /var/tmp/scratch -T /var/tmp/temp" just to be sure Also what is the cache tmpfs dir you have ? free shows that your system seems to be loaded in term of memory, and even swap. Could it be that the command failed due to lack of memory ? (mondo uses a certain amount when running for the moment). Ands is cp -f handled in a special way ?
tmpfs is a dynamically expandable/shrinkable ramdisk, and will use almost no memory if not populated with files. cp -f isn't handled in a special way so I don't know while it isn't working. Perhaps it's due to the lack of memory ? But that would be strange. I can't do anything about the memory, as the server is used for emails (postfix, amavis, clamd, fetchmail & procmail), I can't stop everything just for testing. I'll try to run mondoarchive at night, while the server is less loaded.
Mmh, it's definitely a memory problem. Almost all the memory is used by the applications and the used swap is near 100%. As I said before, I will shut every other daemon down this night and try again.
When will the mondo-2.0.9.ebuild hit portage?
This bug turned into a chatroom about stuff that doesn't exist in the tree, closing. See bug 176738 if you are still interested in this package.
