When running mondoarchive, mktemp repeatedly shows error messages indicating that it can't find files/directories. I tried executing mktemp separately and got the same error. I think its because the higher level directories of where mktemp is trying to create a file do not exist (were never created). Reproducible: Always Steps to Reproduce: 1.Run mondoarchive 2.Elect to save images to hard disk 3.cat /var/log/mondo-archive.log | grep cannot | more to see error messages Actual Results: Your boot loader is GRUB and it boots from /dev/ide/host0/bus0/target0/lun0/disc //tmp.mondo.18234 Calculating size of all biggiefiles (in total) biggielist = //tmp.mondo.18234/biggielist.txt Reading it... Closing... Finished calculating total size of all biggiefiles mindi --custom //tmp.mondo.18234 //mondo.scratch.28130/images "FAILSAFE" "" "" 210997 "no" no "" yes 120 7 "" yes no Executing mindi --custom //tmp.mondo.18234 //mondo.scratch.28130/images "FAILSAFE" "" "" 210997 "no" no "" yes 120 7 "" yes no You are using Mindi-Linux v0.86 to make boot+data disks I shall include Mindi's failsafe kernel, not your kernel, in the boot disks. However, you are still running your kernel. If Mindi fails to create your disks then it may still be a result of a problem with your kernel. Analyzing dependency requirements 4% - 9% \ 13% | 18% / 22% - 27% \ 31% | 36% / 40% - 45% \ 50% | 54% / 59% - 63% \ 68% | 72% / 77% - 81% \ 86% | 90% / 95% - 100% \ Done. Making complete dependency listmktemp: cannot make temp file //tmp.mondo. 18234/mindilinux/2671/mindilinux/tempdepfile.lesJWb: No such file or directory /usr/sbin/mindi: line 706: 1: ambiguous redirect 1% -mktemp: cannot make temp file //tmp.mondo. 18234/mindilinux/2671/mindilinux/tempdepfile.ONXBuf: No such file or directory /usr/sbin/mindi: line 706: $tempdepfile: ambiguous redirect 3% \mktemp: cannot make temp file //tmp.mondo. 18234/mindilinux/2671/mindilinux/tempdepfile.pBMCke: No such file or directory /usr/sbin/mindi: line 706: $tempdepfile: ambiguous redirect 5% |mktemp: cannot make temp file //tmp.mondo. 18234/mindilinux/2671/mindilinux/tempdepfile.C6txRh: No such file or directory /usr/sbin/mindi: line 706: $tempdepfile: ambiguous redirect Expected Results: Error messages should not appear I've tried posting this as a bug to mindi/mondo but have had no reply. Could it be gentoo specific?
Looks like it could be specific to the security fixes, but I'm not sure. I've fixed it on my machine, but won't inflict it on anyone else because I'm sure there's a more clever way of getting this to work. Maybe there's a more serious reason this is happening? ;-D Anyway, GenerateGiantDependencyList() tries to write a file to $TMP_ROOT/mindilinux before the directory exists. I added a 'mkdir $TMP_ROOT/mindilinux' at line 704 of /usr/sbin/mindi; everything seems to work now. I don't know if this just needs to be added to the patchfile, or if a new patchfile needs to be written, or if there's a more serious problem afoot that needs to be fixed, but it worksforme(TM).
I developed a more cowardly method of getting around this. Since its an old ebuild and I don't know my way around ebuilds yet, I tried compiling and installing the latest versions via RPM. i.e. (assuming you have emerged rpm) 1. I got the latest mindi & mondo in .src.rpms 2. Installed the src rpms -->rpm -Uvh mindi-0.87-1.src.rpm -->rpm -Uvh mondo-1.67-1.src.rpm 3. Modified SPEC files to satisfy dependancies by adding a "provides:" entry for each dependancy (requirement). I of course made sure these dependancies really were satisfied :-) --> cd /usr/src/redhat/SPECS --> tinker with SPEC files adding "provides;" entries. Also commented out a build requirement from memory 4. Generated an rpm; --> rpmbuild -ba <SPEC FILE> for both spec files 5. Installed the newly created RPMS --> cd ../RPMS/i386 --> rpm -Uvh <rpm file> I'm saying all this from memory but I think that the paths/file names are correct. Now when I mondoarchive it works and I have the latest version! OK it may not be the neatest way of doing things but if an ebuild is really old and doesn't work then why not. As a side note I'm thinking this may not be possible for all rpms because there may be assumptions about file locations of the dependancy packages. e.g. gentoo might put files in /usr/lib whereas an rpm puts it in /usr/local/lib. In any case I did not find this problem with mondo/mindi.
I've received confirmation from the mindi/mondo bugzilla that this bug is specific to version .86 of mindi and is fixed in version .87. http://geek.j2solutions.net/bugzilla/show_bug.cgi?id=126 Any chance of getting an updated ebuild for mindi? I'd do this myself but I'm not confident enough with ebuilds yet.
mindi 1.03 is in portage and does not seem to have this bug. Closing.
