Bugzilla Bug 79262

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 an attachment (id=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 an attachment (id=93706) [details]
ebuild proposal for mindi

Created an attachment (id=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.