There are new stable versions of Mondo (2.0) and Mindi (1.0). Reproducible: Always Steps to Reproduce:
I'm happy to release e-builds for Mondo and Mindi if a Gentoo developer will assist me in the crafting of a script to automate the process.
Created attachment 34874 [details] Ebuilds and Digests for Mondo 2.02, Mindi 1.02 and Mindi-Kernel 1.00 Attached are the ebuilds and digests for the latest stable Mondo-Rescue which fixes problems with Gentoo. Included are ebuilds and digests for Mondo 2.02, Mindi 1.02 and Mindi-Kernel 1.00. Mondo is dependent on Mindi and Mindi is dependent on Mindi-Kernel. Thanks.
It is my understanding from the docs that lilo is not a requirement anymore. Mondo-rescue and mindi will work with grub. Can we get the mindi ebuild changed to reflect this? (either/or instead of just lilo) Reading their boards it does look like it requires grub .92 or better. =C=
Mondo-rescue still uses lilo for mounting the CDs/DVDs when restoring from backup. It is compatible with a system that uses grub for a bootloader though. -G.Y.
I'm going to toss this back to the wranglers, because while I did do the initial import, I have never used this package and as I am now a barely active dev, I can't be trusted to maintain things I don't use.
Installed all packages without a problem. Executed mondoarchive and it gave this error. /usr/bin/mondoarchive: line 1: cd: /var/tmp/portage/mondo-rescue-2.02/work/mondo-2.02/mondo/mondoarchive: No such file or directory gcc: main.o: No such file or directory gcc: mondo-cli.o: No such file or directory gcc: ../common/.libs/libmondo: No such file or directory gcc: ../common/.libs/libmondo-newt: No such file or directory
Had the same errors. Relied on "make uninstall" and "make clean" when testing and those didn't get the job done. So basically the mondo-rescue ebuild is a wash. Mindi works though:(
Created attachment 34893 [details] Working? Ebuilds and Digests for Mondo-Rescue, Mindi and Mindi-Kernel I completely redid the ebuild for mondo-rescue, the solution being far simpler than the prior ebuild. Please try this out and see if mondo-rescue works for you. Thanks, -G.Y.
Here's the output from this ebuild. # emerge mondo-rescue Calculating dependencies ...done! >>> emerge (1 of 1) sys-apps/mondo-rescue-2.02 to / >>> md5 src_uri ;-) mondo-2.02.tgz mkdir: `/usr/share/mondo/post-nuke.sample/usr/bin/post-nuke' exists but is not a directory >>> Unpacking source... >>> Unpacking mondo-2.02.tgz to /var/tmp/portage/mondo-rescue-2.02/work >>> Source unpacked. ./configure: ./configure: Permission denied !!! ERROR: sys-apps/mondo-rescue-2.02 failed. !!! Function econf, Line 365, Exitcode 126 !!! econf failed NOTE: I got this error with the last one as well. I forgot to mention that I had to patch the ebuild to change the permissions on configure before it would work. The one in the tar file won't execute. =C=
How did you change the permissions? I have no problems with permissions but that's with letting the portage download the tarball instead of dropping it into /usr/portage/distfiles. Please let me know so I can fix it. The other error about post-nuke not being a directory is easy to fix: mkdir -p /usr/share/mondo/post-nuke.sample/usr/bin/post-nuke should be mkdir -p /usr/share/mondo/post-nuke.sample/usr/bin Thanks, -G.Y.
I'll tell you but no laughing at me. I don't do ebuilds. In src_compile I added a line to the beginning chmod 777 configure that did the trick. There's probably a better way to do it though. I made the change you suggested, did the emerge and this is what I get: --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-sys-apps_-_mondo-rescue-2.02-13580.log" open_wr: /usr/share/mondo/post-nuke.sample/usr/bin/post-nuke -------------------------------------------------------------------------------- =C=
Created attachment 34944 [details] Mondo-Rescue ebuild with just a few changes --- Last Attempt This should--hopefully--fix everything. If you're testing be sure to delete old symlinks from /usr/bin (mondoarchive mondorestore mondo-makefilelist). This ebuild installs those three in /usr/sbin without symlinking. FYI:the only changed file in this tarball is mondo-rescue-2.02.ebuild. Thanks, -G.Y.
For some reason Portage fails to create the post-nuke.sample directory and its subdirectories. It seems to treat it as a file instead of a directory. Can anyone confirm that this is a bug in Portage? This is an extremely simple ebuild and should install from source without problems, but the directory has a funky name. I'm referring to the mondo-rescue-2.02.ebuild in mondo-rescue3.tar.gz make[4]: Entering directory `/var/tmp/portage/mondo-rescue-2.02/work/mondo-2.02/mondo' cp -R post-nuke.sample /usr/share/mondo/ ACCESS DENIED mkdir: /usr/share/mondo/post-nuke.sample cp: cannot create directory `/usr/share/mondo/post-nuke.sample': Permission denied --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-sys-apps_-_mondo-rescue-2.02-3210.log" mkdir: /usr/share/mondo/post-nuke.sample -------------------------------------------------------------------------------- Thanks, -G.Y.
Still get this: Calculating dependencies ...done! >>> emerge (1 of 1) sys-apps/mondo-rescue-2.02 to / >>> md5 src_uri ;-) mondo-2.02.tgz >>> Unpacking source... >>> Unpacking mondo-2.02.tgz to /var/tmp/portage/mondo-rescue-2.02/work >>> Source unpacked. ./configure: ./configure: Permission denied !!! ERROR: sys-apps/mondo-rescue-2.02 failed. !!! Function econf, Line 365, Exitcode 126 !!! econf failed
Created attachment 35029 [details] Working mondo-rescue ebuild? This mondo-rescue ebuild should work -- included the "chmod 777 configure" as suggested and did away with the "make DESTDIR={D} install" that was causing all the trouble. Little did I know it was calling make install, and that was causing the access violations. I appreciate any feedback in making this functional. Would better cleanup from an unmerge be a good idea? ( like deleting /usr/share/mondo ?)
Created attachment 35032 [details] A working mondo-rescue-2.02 ebuild. Finally!:) This ebuild cleans up after itself, removing /usr/share/mondo. Please try this and see if it works and maybe if I'm lucky it can go into ~x86. Thank you. -G.Y.
Created attachment 35049 [details] A Working Mondo-Rescue with "cannot stat /usr/share/mondo/autorun" fixed Just thought I'd get it right. When backing up, Mondo complained about autorun not being in /usr/share/mondo. Fixed now. This is my first ebuild ever so I apologize for all the attachments. And unless there are problems it'll be my last post to this ebuild request. Thank you, -G.Y.
Created attachment 35052 [details] Final mondo-rescue-2.02 ebuild with images directory in html docs fixed Six wouldn't be lucky so here's number seven. Found out dohtml doesn't copy the images directory for the docs. So attached are ebuilds for Mondo Rescue and Mindi. And one for Mindi-Kernel that isn't changed much except for the specified download URL. Everything is fixed and should work just dandy. Thanks, -G.Y.
Created attachment 35053 [details] Final mondo-rescue-2.02 ebuild with images directory in html docs fixed Six wouldn't be lucky so here's number seven. Found out dohtml doesn't copy the images directory for the docs. So attached are ebuilds for Mondo Rescue and Mindi. And one for Mindi-Kernel that isn't changed much except for the specified download URL. Everything is fixed and should work just dandy. Thanks, -G.Y.
*** Bug 56412 has been marked as a duplicate of this bug. ***
woot! I emerged all 3 of them again and they worked. Looks like we are ready for ~x86. =C=
Spoke too soon. Yes, it all compiles and installs but it won't run. # mondoarchive /usr/sbin/mondoarchive: line 1: cd: /var/tmp/portage/mondo-rescue-2.02/work/mondo-2.02/mondo/mondoarchive: No such file or directory gcc: main.o: No such file or directory gcc: mondo-cli.o: No such file or directory gcc: ../common/.libs/libmondo: No such file or directory gcc: ../common/.libs/libmondo-newt: No such file or directory If I remember correctly, mondoarchive is a shell script that is build in the make process. make puts directory info in it about where the libs are and such. Since where they are when make is run is NOT where they are when mondoarchive is run, these are incorrect. =C=
Created attachment 35075 [details] Work in progress attached -- Mondo-Rescue and related packages Did an rm -rf /var/tmp/portage/mondo-rescue-2.02 and get the exact same error you got. My god-awful luck:( Will research econf + autoconf and read all of the Gentoo Developer docs, hopefully get it working within two weeks, and post one final attachment. Am attaching what I've done so far just in case someone more experienced wants to pitch in. Thanks for testing so thoroughly -- wouldn't have wanted it get to ~x86 in this shape! And I must have emerged and unmerged a couple dozen times.
After viewing mondoarchive with less I know what you mean now. Yep, it's a script & depends entirely on being built in-place. Posted to the mondo-devel list about this and hope Gentoo will eventually be supported. Nice working with you.
Created attachment 35092 [details] Mondo-Rescue working ebuild -- At long last!!! Try this. A Mondo-Rescue developer straightened me out -- for some reason the binaries are in the .libs directories for mondoarchive/.libs/mondoarchive & same thing for mondorestore. I've been referencing/installing the wrong files.
Complete unmerge of all 3 ebuilds and then emerged them using new ebuilds provided. mondoarchive seems to work now! (At least it runs, that's a good sign) Thanks for your help. =C=
Thanks for your help, Cal! This was my first ebuild as a raw n00b and I really made a mess of things. Couldn't have gotten it working without your assistance. -G.Y.
Created attachment 35219 [details] Mondo Resue 2.02 with final fixes Found an unnecessary line "dodir /usr/lib" and removed it because dolib runs install -d. There was as well a broken symlink in /usr/lib that's fixed now. And I've updated the deps to reflect what was installed on my system when the Mondo Rescue packages were built. Though I don't know if that's the proper way to handle the deps. Have used it to back-up and everything seems to work so far. Thank you for your patience. -G.Y.
Created attachment 35392 [details] Mondo-Rescue with fixes Had to specify the full package name for CDRTools in the dependencies & couldn't find a workaround. Also removed the line "MYDIR=/usr" Please give this a try and let me know if it works for you. -G.Y.
Comment on attachment 35392 [details] Mondo-Rescue with fixes mindi-kernel ebuild doesn't work properly
Created attachment 35719 [details] Mondo-Rescue -- media now boots Fixed it so both the mondorescue disk and the first of the backup set now boot properly. Also added a dependency on buffer for the mondo-rescue ebuild, and corrected the mondo-rescue and mindi ebuilds' dependency line for cdrtools. Please try this and post here if it works. Thanks, -G.Y.
Created attachment 35920 [details] Mondo Rescue Ebuilds with Mindi Post-Remove cleanup The directory /usr/share/mindi wasn't being removed upon unmerge due to the /usr/share/mindi/rootfs directory lingering. Fixed it. Please test this, now that it seems functional.
the ebuild seems to compile nice. mondoarchive seems also to work until I get this: Done with: Primary Volume Descriptor Block(s) 1 Writing: Eltorito Volume Descriptor Start Block 17 mkisofs: Uh oh, I cant find the boot image 'isolinux.bin' ! :-( write failed: Input/output error Failed to burn DVD #1. Retry? seems like the file can't be found. but is here: /usr/lib/syslinux/isolinux.bin
The DVD drivers are unstable so Mondo has a problem with writing direct to a DVD. There's been discussion on the Mondo-Devel list about this. Try making an ISO image and burning it to DVD if possible.
trying to just make an iso fails aswell, as mkisofs is needed for that.
Are you running Mondo Rescue as root? Also what is your hardware and are you running the 2.6 kernel? I've had no problems creating ISOs and burning to CDRWs, even after reinstalling the entire OS & all apps from scratch.
It works for me wasn't the right answer here. I may have found a solution to your problem on the Mondo-Devel list: ******************************************************************** From: Hugo Rabson <hugo@mo...> RE: Re: mondoarchive and mkisofs 2004-07-03 13:50 "mkisofs: Uh oh, I cant find the boot image "isolinux.bin" !" OK, so it doesn"t like your isolinux/syslinux version. Try using lilo instead. # man mondoarchive Look for "-o" -Hugo
I've tried that aswell but it doesn't work either.
Have you tried running just the GUI, mondoarchive with no flags?
I've just tried it. it works! so there must be something wrong with the passing of command line arguments (which I need for automaticated backups)
Parsing of command line args isn't related to the ebuild though. All I can figure is the args should be mostly in the same order as when stepping through the GUI. Also it doesn't seem to like groupings of flags such as -DvE (instead of single flags like -D -v -E). Hope this helps. For more info you could post to the mondo devel list.
File digest-mindi-kernel-1.0 provided with attachment 35920 [details] should be named digest-mindi-kernel-1.0-r1.
Created attachment 36255 [details] Mondo Rescue with mindi-kernel digest renamed Renamed digest-mindi-kernel-1.0 to digest-mindi-kernel-1.0-r1 as suggested.
Please close this bug. There are new versions of Mondo Rescue (2.03) and Mindi (1.03) out & the build process has changed entirely to autotools -- no more "install" section in the Makefile. I'm unfamiliar with autotools and so can't write an ebuild for Mondo-2.03. Thanks. -G.Y.
Alright... I'm working on ebuilds for mondo-2.10 and mindi-1.10.
also will get ebuilds for 2.03/1.03 since they are latest "stable".
OK... I just commited the following: sys-apps/mindi-1.03 sys-apps/mondo-rescue-2.03 and I package masked: sys-apps/mindi-1.10 sys-apps/mondo-rescue-2.10 for those who want to test. Ah, I also update the mindi-kernel ebuild a bit. Closing... Have a good one, Jay
mindi-kernel-1.0-r1 emerges fine mindi-1.03.ebuild will emerge after fixing the digest. mondo-rescue-2.03.ebuild dies: >>> emerge (1 of 1) sys-apps/mondo-rescue-2.03 to / >>> md5 src_uri ;-) mondo-2.03.tgz >>> Unpacking source... >>> Unpacking mondo-2.03.tgz to /opt/tmp/portage/mondo-rescue-2.03/work >>> Source unpacked. * Patching ${S}/ltmain.sh... * Applying portage-1.4.1.patch... * Applying max_cmd_len-1.5.0.patch... ./configure: ./configure: Permission denied !!! ERROR: sys-apps/mondo-rescue-2.03 failed. !!! Function econf, Line 362, Exitcode 126 !!! econf failed This one is odd: mindi-1.10.ebuild Continued download failed on this file, which conflicts with `-c'. Refusing to truncate existing file `/opt/portage/distfiles/mindi-1.10.tgz'. >>> Resuming download... >>> Downloading http://www.microwerks.net/~hugo/download/MondoCD/TGZS/mindi-1.10.tgz --19:09:29-- http://www.microwerks.net/%7Ehugo/download/MondoCD/TGZS/mindi-1.10.tgz => `/opt/portage/distfiles/mindi-1.10.tgz' Resolving www.microwerks.net... 198.68.233.7 Connecting to www.microwerks.net[198.68.233.7]:80... connected. HTTP request sent, awaiting response... 200 OK The file is already fully retrieved; nothing to do. !!! Couldn't download mindi-1.10.tgz. Aborting.
ok, this bug should be closed. subsequent bugs need to go on new bugs since this bug was to have packages in portage. which they are in portage.
