Summary: | mondo-rescue and mindi have not updated correctly | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matthew East <matthew.east> |
Component: | Current packages | Assignee: | App-Backup Team <app-backup> |
Status: | RESOLVED WONTFIX | ||
Severity: | major | CC: | andreas.kotowicz, bruno, cancellettopugno, gentoo-bz, jcranmer01, postmaster, wschlich |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 106497 | ||
Bug Blocks: | |||
Attachments: |
/var/log/mondo-archive.log
ebuild proposal for mindi ebuild proposal for mondo |
Description
Matthew East
2005-01-23 14:14:45 UTC
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. |