mondo-devel Mailing List for Mondo Rescue

Hugo,

Not sure if you really want to hear this stuff.

Line 502 of mindi
    [ "$KBDEPTH" -gt "128" ] && Die "Edit $MINDI_HOME/mindi and disable 
FindAndAddUserKeyboardMappingFile (line 1170, approx.)"

could not be changed to 

    [ "$KBDEPTH" -gt "128" ] && Die "Edit $MINDI_HOME/mindi and disable 
FindAndAddUserKeyboardMappingFile (line 1240, approx.)"



Possible bug in the keyboard map stuff.

line 477 of mindi
mp=`find $KEYDIR/keymaps | grep "i[3-8]86" | grep "$locale" | grep -vx "#.*"` 

I don't know what it should be as I can't program but I think the grep 
"$locale" should exclude /usr/ from matches or better still just look at the 
filename part of the name only.

My reasoning is that my locale winds up being "us" the above code matches 
every single keyboard map beacuse mappath starts off /usr. If I run the find 
command above a get basically every keyboard map that is under the i386 
directory.

The code then maps 7 keyboard maps and stops
Added kbd map /usr/lib/kbd/keymaps/i386/azerty/azerty.kmap.gz
Added kbd map /usr/lib/kbd/keymaps/i386/include/azerty-layout.inc.gz
Added kbd map /usr/lib/kbd/keymaps/i386/include/euro.inc.gz
Added kbd map /usr/lib/kbd/keymaps/i386/include/windowkeys.inc.gz
Added kbd map /usr/lib/kbd/keymaps/i386/include/compose.inc.gz
Added kbd map /usr/lib/kbd/keymaps/i386/include/linux-with-two-alt-keys.inc.gz
Added kbd map /usr/lib/kbd/keymaps/i386/include/linux-keys-bare.inc.gz

Only problem is that when I boot I wind up with the azerty keyboard. I know I 
can comment out the line to stop the whole process but I was trying to figure 
out why this happened. 

So am I on the right track?


-- 
Best Regards,

David Price

> -----Original Message-----
> From:	Hugo Rabson [SMTP:hu...@bt...]
> Sent:	Thursday, January 31, 2002 2:06 PM
> To:	Alleman, Lowell; mon...@li...
> Subject:	Re: [Mondo-devel] mondo-tarme:  self-compiled version
> consistently fails
> 
	> On Thursday 31 January 2002 6:20 pm, Alleman, Lowell wrote:
> > Why is it not possible for me to recompile mondo-tarme, and have a
> working
> > copy when I'm done?  The version from the tarball works -- how is it
> > compiled?
> 
> Use 'install.sh' to compile Mondo-tarme. If it doesn't work on your PC
> after 
> you compiled it then there is some problem with your distro but I couldn't
> 
> even start to guess what it is. If you can compile the code then a
> run-time 
> problem must exist, probably the result of a conflict between two of the 
> libraries present in your distro. Perhaps you have multiple versions of 
> ncurses installed, or newt, or glibc, or something like that.
> 
	[Alleman, Lowell]  
	If it is a problem with my distro or my installation, then why is it
listed in the FAQ section of the README file?  Apparently I'm not the first
to have this problem.  You simply state the that, "your compiler may be
fubar," but what does that mean?  I've never had problems compiling other
software.  Please explain this to me.

> Is there some special reason why you won't just use the precompiled 
> executable, if it works? 
> 
	[Alleman, Lowell]  
	I do use the precompiled version, especially since that's all that
works right now.  But I would really expect the compile to work anyway,
especially since it is done by the install.sh script.   (BTW:  why not just
use make? Type "make" to build the code, then running "make install' as root
to install it.... I'll gladly submit a makefile if you'd like.)

	I wanted to compile the source because I prefer to use SRPMs.  (BTW:
I had to remove some hardcoded directory names in the spec file, they aren't
needed anyway:   /usr/src/RPM/mondo-x.yy.tar.gz  -->  mondo-x.yy.tar.gz)

> > SuSE-7.3 (with all the updates available)
> Red Hat 7.2
> 
> > If there is a simple answer to this question, great!  I'd like to hear
> it.
> gcc-2.96-98
> 
	[Alleman, Lowell]  
	I'm running gcc-2.95.3-124.
	It's hard to say if that is causing a problem or not, since 2.96 is
a RedHat invention.

> -Hugo

Sorry to intrude on the path issues here, but I have some additional input 
based on some recent problems I've had...

I agree with others that a standard user install should be in /usr/local, 
and a distro's package should install in /usr - this is typical - and it's 
not just a debian issue - I noticed your RPM packages install mondo in 
/usr/bin, not /usr/local/bin.

Either way - my problem is that it installs into /usr/bin or 
/usr/local/bin. I think it should be in "sbin" instead.

Case in point: bin is in the path of non-root users.
When I run mondo-archive as non-root - I get the following:
mkdir: cannot chdir to directory, '/root': Permission denied
/usr/bin/mondo-archive: $LOGFILE: ambiguous redirect
/usr/bin/mondo-archive: '/var/log/mondo-archive.log: Permission denied

You really need to be root to run this program - the default isodir is 
/root/images/mondo. You also need to be root to write to /var/log.

BTW - this isn't even trying to run a backup... This is running 
"mondo-archive --help" as non-root! Looking at the source - just using the 
help flag will cause all sorts of things to happen...

Anyway, IMHO, a program that is used for system administration, and should 
only be run by root, needs to be in sbin.

~Jonathan

I'm running into a problem with mondo creating iso images on the wrong fs.

Running mondo-archive with --isodir /opt/iso/ causes the scratch dir to be 
created in /home.

I ran it from a cwd of /opt/iso. Which makes /opt/iso/tmp.mondo.9999 and 
/home/mondo.scratch.9999.

This is a problem. I chose /opt because it's a separate physical hdd. That 
disk has 1.9GB free. My root / is mounted on hda. It usually has between 
600 and 750mb free. When mondo uses it, all of a sudden I have about 50mb 
free and other programs start crashing. (I use 80min CDR's, so it's 700MB 
ISO's...)

mondo-archive --help says:
	--scratchdir <path>	scratch space used to build CD ISOs; if you don't 
specify, Mondo will create a loopfs in isodir

Seems like - if I don't specify it will be created in /home, not isodir. I 
even updated to mondo 1.37.
The issue is somewhere around line 1281-1285 in mondo-archive. I'd make a 
diff, but I'm not sure what the best way to fix it is. Line 1284 sets it to 
/home/mondo.scratch.$$, but this is before parameters are read - so setting 
it to $isodir/mondo.scratch.$$ here wouldn't help - isodir doesn't yet 
reflect what I put on the command line.
Maybe changing it here, and right after isodir is set from a command line 
option would work.
Or, change your help text ;-)

Other than that - mondo's working great. I'm using it on RH7.2 to make 
weekly backups for work. I just backup my data files, not the entire 
system. I use cdrw's every week, and 80min cdr's once a month. Take them 
home, rotate the cdrw's, and I've got a pretty decent backup system. Thanks!

~Jonathan

On Thursday 31 January 2002 6:20 pm, Alleman, Lowell wrote:
> Why is it not possible for me to recompile mondo-tarme, and have a working
> copy when I'm done?  The version from the tarball works -- how is it
> compiled?

Use 'install.sh' to compile Mondo-tarme. If it doesn't work on your PC after 
you compiled it then there is some problem with your distro but I couldn't 
even start to guess what it is. If you can compile the code then a run-time 
problem must exist, probably the result of a conflict between two of the 
libraries present in your distro. Perhaps you have multiple versions of 
ncurses installed, or newt, or glibc, or something like that.

Is there some special reason why you won't just use the precompiled 
executable, if it works?


> SuSE-7.3 (with all the updates available)
Red Hat 7.2

> kernel-2.4.16
2.4.18-pre3

> glibc-2.2.4-64
glibc-2.2.4-13

> mondo-1.24
mondo-1.50-pre1 (due out mid-Feb)

> mindi-0.55
mindi-0.56-pre3

> afio-2.4.6-252
afio-2.4.7

> bzip-1.0.1-104

> cdrecord-1.11.a06-6
cdrecord-1.10-4

> mkisofs-1.11.a06-6
mkisofs-1.10-4

> newt-0.50.8-201
newt-0.50.33-1

> slang-1.4.4-81
slang-1.4.4-4

> If there is a simple answer to this question, great!  I'd like to hear it.
gcc-2.96-98

-Hugo

This subject is mentioned in one of the FAQs, but there is no explanation
given.  Unless I missed it.

Why is it not possible for me to recompile mondo-tarme, and have a working
copy when I'm done?  The version from the tarball works -- how is it
compiled?

My first guess would be that there is some kind of library version
compatibility issue.  I suggest that we compile a list containing the
required library and other core packages, the versions of those packages and
then whether or not a locally compiled version works on your machine.  The
name of the distro would be good too.

SuSE-7.3 (with all the updates available)

kernel-2.4.16
glibc-2.2.4-64
mondo-1.24
mindi-0.55
afio-2.4.6-252
bzip-1.0.1-104
cdrecord-1.11.a06-6
mkisofs-1.11.a06-6
newt-0.50.8-201
slang-1.4.4-81


If there is a simple answer to this question, great!  I'd like to hear it.


Thanks,


Lowell Alleman
lo...@mf...

On 2002.01.31 17:11 Roadkill the Avatar of Misfortune wrote:
> From my understanding of the FHS, is that it's a guide for linux
> distro
> managers to setup the layout of linux operations systems that will
> hopefully
> not have cross compatability issues.

This pretty much catches the essence of it. (Although "standard" sounds 
much fancier than "guide" ;) ) That doesn't mean that the document is 
irrelevant for application developers. The more non-standard things you 
do with your installers, the more packagers have to mess around with it 
in order to prevent the world from becoming a horrible chaotic place. 
Both mindi and mondo currently installs in /usr/local/<appname>. 
Imagine if every single one of the 300 individual software packages 
installed on your system did the same. To prevent scenarios like that, 
packagers has to ensure that software installs in sane locations, and 
when a packager has to move stuff around, it increases the chance of 
introducing problems that were not there when the tarball left the 
author. The packager is pulling his hair over the extra work. The 
project maintainer is recieving mystery bug reports he can't reproduce. 
Everybody hurts. The morale of this story is that we should all marry 
the FHS and bear it's children ;) 
> Essentially what this means, is that mondo will need some extra
> options, as
> mentioned, to allow the installer to choose where mondo and mindi will
> be
> installed.    With a stock ./install.sh I would say that mondo should
> go into
> the /usr/local/ tree, but I'd suggest a command line option to the
> install.sh
> script, with something like ./install.sh --prefix=/usr  where "/usr"
> could
> actually be any dir tree available...  (assuming either the installer
> will
> look for all needed subdirs in the prefix and the decide if it can
> install..or make the dirs it needs if they are missing...)

This is partially what i'm talking about. In addition to this things 
would be all fluffy and nice if specific files installed in their 
intended locations. Binaries and scripts in ${prefix}/bin, libraries 
(are there any?) in ${prefix}/lib, arch-independent data files in 
${prefix}/share/<appname> and so on.

Jon

From my understanding of the FHS, is that it's a guide for linux distro 
managers to setup the layout of linux operations systems that will hopefully 
not have cross compatability issues.

Essentially what this means, is that mondo will need some extra options, as 
mentioned, to allow the installer to choose where mondo and mindi will be 
installed.    With a stock ./install.sh I would say that mondo should go into 
the /usr/local/ tree, but I'd suggest a command line option to the install.sh 
script, with something like ./install.sh --prefix=/usr  where "/usr" could 
actually be any dir tree available...  (assuming either the installer will 
look for all needed subdirs in the prefix and the decide if it can 
install..or make the dirs it needs if they are missing...)

And really this is only if you want mondo to be able to be distrubted with a 
distro (which I assume you do) otherwise really, this isn't something to 
worry about to much.....  People install software in all kinds of crazy 
place, for all kinds of crazy reasons...  that's why i recommend the --prefix 
tag for the install script

Roadkill the Avatar of Misfortune



On Thursday 31 January 2002 03:57, you wrote:
> OK, those of you who argued that I should move Mondo to /usr/local, please
> read the a ttached e-mail and explain why this guy is wrong. He is
> basically saying (a) I don't understand the FHS (which means _you_ don't
> because it was your idea) and (b) no-one can install Mondo without
> violating the FHS. If he is wrong, please explain how.
>
> Stan Benoit is currently working to make it possible to install Mondo
> almost anywhere, using a command-line switch sent to 'make' or something.
>
> -Hugo
>

Hi David,

Thank you for your suggestions.

On Thursday 31 January 2002 2:42 pm, David wrote:
> move line 1721 up to the top of the program 
Done.
> The 2nd last FAQ under the Mindi README
Done.
> New FAQ:
Done.

Mindi v0.56 will incorporate the changes you recommend. You're right: I 
should make it easier for users to change Mindi's global settings.

-Hugo

Me again.

Can I offer a few suggestions? Feel free to ignore as appropriate.

Suggestion 1:
move line 1721 up to the top of the program so it is easily configurable for 
people who need to like me (read people will a small root partition on which 
tmp sits). You could also consider moving some of the other fixed variables 
up there to.


Suggestion 2:
the 2nd last FAQ under the Mindi README
Q: When I run Mindi, it freezes when trying to figure out my local keyboard
   mapping. (Or, it just craps out, printing gibberish.) What do I do?
A: Find the call to FindAndAddUserKeyboardMappingFile. It's around line 1100
   or so. Comment it out.
It is actually now at 1240 in mindi 0.55. For those who are a bit vi or emacs 
challenged (me).

Suggestion 3:
New FAQ:
Q: When mindi is creating the disk images I get fatal errors. What is wrong
A: Is there enough room on your hard drive. Minid needs at least 50MBytes to 
create the images and unpack files even though you are only creating files a 
few megabytes. Do you have a graphical boot screen on lilo? if so try 
commenting out the line that calls it in your lilo.conf file (something like 
message=/boot/message) or rename the file. If all else fails you could 
re-install lilo.



-- 
Best Regards,

David Price

Just inserted the new line and it works fine even on my encentric system but 
I guess you already knew that. Thought it couldn't hurt to confirm it though.

Many thanks.

-- 
Best Regards,

David Price
----------------------------------------------------
On Thu, 31 Jan 2002 22:40, you wrote:
> bzip2 -dc $MINDI_HOME/lib.tar.bz2 | tar -x || Die "Cannot unzip
> lib.tar.bz2"

Try this instead:-

  bzip2 -dc $MINDI_HOME/lib.tar.bz2 | tar -x || Die "Cannot unzip lib.tar.bz2"

I'm betting '-x' will remain one of its switches for a good, long time. :-)

Thank you for taking the time to find the line in question and for proposing 
a potential fix.

-Hugo


On Thursday 31 January 2002 11:14 am, David wrote:
> I have found my problem relating to the failsafe kernel but am not much of
> a programmer so please help me.
>
> line 1800 of the mindi script
>
>  tar -x --use-compress-program bzip2 -f- < $MINDI_HOME/lib.tar.bz2 || Die
> "Cannot unzip lib.tar.bz2"
>
> the problem is tar -x --use-compress-program bzip2 -f- <
> $MINDI_HOME/lib.tar.bz2
>
> If I use the command
> tar -x -v --use-compress-program bzip2 -f- < /usr/local/mindi/lib.tar.bz2
>
> the command hangs it gets down to
> lib/modules/2.4.12-xfs/kernel/fs/xfs/xfs.o
> and then stops forever.
>
> It misses out the last 10 line items. Can anyone tell me why?
>
> Everything seems to work fine if I change the command to
> tar -x --use-compress-program bzip2 -f $MINDI_HOME/lib.tar.bz2 || Die
> "Cannot unzip lib.tar.bz2"
>
> So
>
> Question 1:
> If I do this have I stuffed anything else up?
>
> Questions 2:
> Why am I the only one with this problem?
>
> Question 3:
> If the redirect and stdin stuff really necessary? (ie what does it do?)
>
> I'm using the following redhat rpms
> bzip2-1.0.1-3
> tar-1.13.17-8

I have found my problem relating to the failsafe kernel but am not much of a 
programmer so please help me.

line 1800 of the mindi script

 tar -x --use-compress-program bzip2 -f- < $MINDI_HOME/lib.tar.bz2 || Die 
"Cannot unzip lib.tar.bz2"

the problem is tar -x --use-compress-program bzip2 -f- < 
$MINDI_HOME/lib.tar.bz2

If I use the command 
tar -x -v --use-compress-program bzip2 -f- < /usr/local/mindi/lib.tar.bz2 

the command hangs it gets down to 
lib/modules/2.4.12-xfs/kernel/fs/xfs/xfs.o  
and then stops forever.

It misses out the last 10 line items. Can anyone tell me why?

Everything seems to work fine if I change the command to 
tar -x --use-compress-program bzip2 -f $MINDI_HOME/lib.tar.bz2 || Die "Cannot 
unzip lib.tar.bz2"

So

Question 1:
If I do this have I stuffed anything else up?

Questions 2:
Why am I the only one with this problem?

Question 3:
If the redirect and stdin stuff really necessary? (ie what does it do?)

I'm using the following redhat rpms
bzip2-1.0.1-3  
tar-1.13.17-8 

Many thanks

David Price

--------------------------------------------------------------
On Thu, 31 Jan 2002 01:45, Hugo Rabson wrote:
> Does your LILO default to a graphical boot screen? Perhaps a picture is
> being incorporate in the boot-time menu instead of the text message.

It does. I have basically moved the /boot/messages file which is the graphic 
and replaced it with a text file with a few characters. I tried comenting out 
the 
message=/boot/message 
line in lilo.conf but it didn't seem to work. I'll play around with this a 
bit more later.

>
> Try reinstalling LILO or removing/renaming the graphic to force LILO to use
> the text message instead.
>
> -Hugo

-----snip--------------

Hi,

My name is Jon Svendsen, I'm voluntarily affiliated with the linux 
distribution Sorcerer (http://sorcerer.wox.org) where I among other 
things help maintain 3rd party software installation facilities in the 
distributions source based package manager. I'm temporarily subscribing 
to this list for the fun-and-games-like experience of discussing 
compliance with the  Filesystem Hierarchy Standard with you guys.

Please read my (admittedly rather harsh) e-mail on the subject which i 
understand has already been posted by Hugo Rabson, and I'll try 
clarifying my views in response to any comments or questions you have. 
I'm gonna download mondo and look through the installation facilities 
later, hopefully I can assist in creating a solution that would satisfy 
everyone, (including Debian AND RedHat ;) ) but right now I REALLY HAVE 
TO go to school.


Jon Svendsen

OK, those of you who argued that I should move Mondo to /usr/local, please read the a ttached e-mail and explain why this guy is wrong. He is basically saying (a) I don't understand the FHS (which means _you_ don't because it was your idea) and (b) no-one can install Mondo without violating the FHS. If he is wrong, please explain how.

Stan Benoit is currently working to make it possible to install Mondo almost anywhere, using a command-line switch sent to 'make' or something.

-Hugo

*** There is an attachment in this mail. ***

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

Has anyone on the list read "The Franklin's Tale" from the Canterbury Tales? 
The lady (the knight's wife) tells a bon viveur (or mal viveur, I guess, if 
he's trying to talk her into committing adultery) that she will sleep with 
him when the big rocks leave the harbor. So, in true Stankonia style, he 
abracadabras them away.

Anyway :) I shall support LS120 and ZIP drives when people demand them and 
when i can afford to buy myself one. When the manual/CD combo goes on sale in 
a month or there, that won't be a problem (I hope).

Comments? Suggestions?

-Hugo

On Thursday 31 January 2002 3:54 am, Bruce Curry wrote:
> It compared all 4 CDs this time but when it finished my keyboard
> was.....well.....off key so to speak.

It sounds as if you've been given the AZERTY keyboard layout instead of the 
QWERTY keyboard layout. You can disable all that by editing 
/usr/local/mindi/mindi, as is described in /usr/local/mindi/README.

> I re-booted and searched the entire drive for changes.txt and the file
> for mondo/mindi could not be found.

If /tmp/changed.files does not exist then there were no differences between 
the live filesystem and the archives. If you reboot, you'll lose it: it lives 
on the ramdisk.

> I feel that it is likely that my archives are good, but I haven't gotten
> brave enough to try a restore yet.  

I backup, wipe and restore at least once a week with the current beta (1.3x). 
I do that several times with the latest stable before releasing it, too. Bad 
archives have not been reported since May 2000. The backups are fine. So is 
the partitioning/formatting engine. I test it on my own system, on my own 
data, regularly.

> Anyway, if you have an explanation for the strange compare behavior, I'd
> appreciate it.

*cough* LOGFILE :-) .../var/log/mindi.log, to be exact. Please gzip it before 
you send it to me.

-Hugo

Hugo,

I've finally gotten through a compare.  The update to 1.24 and 0.55 got 
past the ramdrive problem during compare.

It compared all 4 CDs this time but when it finished my keyboard 
was.....well.....off key so to speak.  The '/' gave me '!' and the 'a' 
gave me a 'q'.  I didn't spend a great deal of time mapping the keyboard 
but it was pretty silly.  I was trying to "cat /tmp/changes.txt".

I re-booted and searched the entire drive for changes.txt and the file 
for mondo/mindi could not be found.

I feel that it is likely that my archives are good, but I haven't gotten 
brave enough to try a restore yet.  Actually I'm waiting until I NEED 
to.  It will be soon because I'll be trying to figure out how to get the 
newest kernel update to work in Mandrake 8.1.  It's munched my system 
into a kernel panic 4 times now and I'm apparently not yet experienced 
enough to know how to fix that.  I'm hard headed and I'll keep punching 
at it.

Anyway, if you have an explanation for the strange compare behavior, I'd 
appreciate it.

Thanks!

Bruce Curry
bcu...@ne...

If my kernel is too big, I compile a smaller one. That's just me being my ordinary, lazy, path-of-least-resistance self.

------obligatory signature------
http://www.microwerks.net/~hugo
-----end of obligatory sig.-----


--- stone zhao <st...@ut...> wrote:
>How can solve this problem? (kernel big then ramdisk?)
>
>Thanks again,
>
>
>
> Stone  
> 1-510-5809242
> U-tron Technologies,
>
>
>
>-----Original Message-----
>From: Hugo Rabson [mailto:hu...@fi...]
>Sent: Wednesday, January 30, 2002 3:53 PM
>To: stone zhao
>Subject: Re: problem for big kernel size
>
>
>MINDI_VER=0.53
>Fatal error. Kernel size = 1291 K
>Ramdisk free = 1191 K
>Sorry, kernel is too big
>
>1191 - 1291 = -100
>
>Your kernel is 100KB too big.
>
>
>
>
>------obligatory signature------
>http://www.microwerks.net/~hugo
>-----end of obligatory sig.-----
>
>
>--- stone zhao <st...@ut...> wrote:
>>Hi hugo,
>>
>>I met problem for running mondo-archive. Seems like kernel size is large
>>then ramdisk size. it stopped by self.
>>
>>Any suggestion?
>>
>>
>>Thanks a lot,
>>
>> Stone 
>> 1-510-5809242
>> U-tron Technologies,
>>
>>
>>
>>Follow is the log file:
>>
>>
>>[root@208 log]# more  mondo-archive.log
>>--------------- mondo-archive v1.23 --------------
>>15:17 nouns = '2 0,0,0 cdrw'
>>15:17 CDRW device is 0,0,0; its speed is 2; it's all good.
>>15:17 CALL_BURN_ISO reads ''
>>15:17 TMP has been set by Mondo to /home/tmp.mondo.21433
>>15:17 Skip 21433's temp dir - it's _our_ process.
>>15:17 ISO dir wiped of ISO files 1-19 and rescue.
>>15:17 Generating a filesystem catalog. Please wait.
>>15:17 call to find = find / -path /tmp -prune -o -path
>>/var/log/mondo-archive.lo
>>g -prune -o -path /home/mondo.scratch.21433 -prune -o -path
>>/home/tmp.mondo.2143
>>3 -prune -o -path /mnt/cdrom -prune -o -path /mnt/floppy -prune -o -path
>>/proc -
>>prune -o -print
>>15:17 Filesystem catalog has been generated.
>>15:17 Filelist created and copied to archives folder.
>>15:17 Calling Mindi Linux, to make boot disks
>>15:17 USE_LZO = 'no'
>>You are using Mindi-Linux v0.53 to make boot+data disks
>>Your kernel is /boot/vmlinuz-2.4.17 (v2.4.17)Mindi's temp dir =
>>/tmp/mindilinux/
>>21585
>>Mindi's output dir=/home/mondo.scratch.21433/images
>>
>>Mondo v1.2x defaults to LILO as the bootloader, BTW.Analyzing your
>>keyboard's co
>>nfiguration.Red Hat-style config detected.
>>Added kbd map /lib/kbd/keymaps/i386/qwerty/us-latin1.kmap.gz
>>Adding /lib/libc-2.2.2.so to filelist
>>Excluding /lib/i686/libc-2.2.2.so
>>Replacing it with /lib/libc-2.2.2.so
>>Adding /lib/libc.so.6 to filelist
>>Adding libc-2.2.2.so to filelist
>>Excluding /lib/i686/libc.so.6
>>Replacing it with /lib/libc.so.6
>>Stripped binary -/lib/ld-2.2.2.so-
>>Stripped binary -/lib/libc-2.2.2.so-
>>Stripped binary -/lib/libnsl-2.2.2.so-
>>Stripped binary -/usr/lib/libncurses.so.5.2-
>>disk=1 cut=100 cl=2 siz=1052
>>disk=1 cut=100 cl=2 siz=1140
>>disk=1 cut=100 cl=2 siz=1240
>>disk=1 cut=75 cl=3 siz=1320
>>disk=1 cut=32 cl=4 siz=1396
>>disk=1 cut=10 cl=5 siz=1468
>>disk=2 cut=100 cl=2 siz=648
>>disk=2 cut=100 cl=2 siz=700
>>disk=2 cut=100 cl=2 siz=740
>>disk=2 cut=100 cl=2 siz=780
>>disk=2 cut=100 cl=2 siz=808
>>disk=2 cut=100 cl=2 siz=820
>>disk=2 cut=100 cl=2 siz=828
>>Your raw fstab file looks like this:-
>>LABEL=/                 /                       ext2    defaults        1 1
>>LABEL=/boot             /boot                   ext2    defaults        1 2
>>/dev/fd0                /mnt/floppy             auto    noauto,owner    0 0
>>none                    /proc                   proc    defaults        0 0
>>none                    /dev/pts                devpts  gid=5,mode=620  0 0
>>/dev/hda5               swap                    swap    defaults        0 0
>>/dev/cdrom              /mnt/cdrom              iso9660
>>noauto,owner,kudzu,ro 0
>>0
>>/dev/cdrom1             /mnt/cdrom1             iso9660
>>noauto,owner,kudzu,ro 0
>>0
>>Examining /dev/hda6 (mount=/ fmt=ext2 psz=19374358)
>>Examining /dev/hda1 (mount=/boot fmt=ext2 psz=40131)
>>Examining /dev/hda5 (mount=swap fmt=swap psz=136512)
>>/dev/hda6 / ext2 19374358
>>/dev/hda1 /boot ext2 40131
>>/dev/hda5 swap swap 136512
>>1376    /home/mondo.scratch.21433/images/1.tar.gz
>>776     /home/mondo.scratch.21433/images/2.tar.gz
>>2608    /home/mondo.scratch.21433/images/all.tar.gz
>>Ramdisk will be 20792 KB
>>Files at mountpoint (/tmp/mindilinux/21585/mointpoint.21585) :-
>>/tmp/mindilinux/21585/mointpoint.21585
>>/tmp/mindilinux/21585/mointpoint.21585/zero
>>/tmp/mindilinux/21585/mointpoint.21585/lilo.conf
>>/tmp/mindilinux/21585/mointpoint.21585/dev
>>/tmp/mindilinux/21585/mointpoint.21585/dev/loop6
>>/tmp/mindilinux/21585/mointpoint.21585/dev/loop0
>>/tmp/mindilinux/21585/mointpoint.21585/dev/ram0
>>/tmp/mindilinux/21585/mointpoint.21585/dev/null
>>/tmp/mindilinux/21585/mointpoint.21585/dev/zero
>>/tmp/mindilinux/21585/mointpoint.21585/dev/ram1
>>/tmp/mindilinux/21585/mointpoint.21585/dev/ram2
>>/tmp/mindilinux/21585/mointpoint.21585/dev/loop1
>>/tmp/mindilinux/21585/mointpoint.21585/dev/loop2
>>/tmp/mindilinux/21585/mointpoint.21585/boot.b
>>/tmp/mindilinux/21585/mointpoint.21585/mindi.rdz
>>/tmp/mindilinux/21585/mointpoint.21585/message
>>/tmp/mindilinux/21585/mointpoint.21585/vmlinuz
>>--- end of list of files ---
>>MINDI_VER=0.53
>>Fatal error. Kernel size = 1291 K
>>Ramdisk free = 1191 K
>>Sorry, kernel is too big
>>
>>Please e-mail a copy of /tmp/mindi.err.21585.tgz, or AT LEAST
>>/var/log/mindi.log
>>, to hu...@fi...; you may want to consider sending me the screen
>>output
>>as well.15:19 Fatal error() has occurred. Turning off signal-trapping.
>>15:19
>>15:19 =======mondo-archive========FATAL ERROR=========mondo-archive========
>>15:19    log file: /var/log/mondo-archive.log
>>15:19    temp dir: /home/tmp.mondo.21433
>>15:19 fatal error: Mindi returned w/errors.
>>15:19 =======mondo-archive========FATAL ERROR=========mondo-archive========
>>15:19 Mondo-archive has stopped.
>
>_____________________________________________________________
>Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

Maybe you can help this guy... *sigh*

*** There is an attachment in this mail. ***

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

Didn't someone experience a problem like Martin's a few weeks ago? I forget 
what the fix was but it was most peculiar. Any ideas?

-Hugo


From:  Martin Lindquist <ml...@em...> 
To:  hu...@fi... 
Subject:  Re: Mondo restore of a directory 
Date:  30 Jan 2002 11:27:58 -0800 

On Wed, 2002-01-30 at 10:47, Hugo Rabson wrote:
> --- Martin Lindquist <ml...@em...> wrote:
> >  Ah, but when I boot into interactive mode, it prompts me to edit 
> 
>the mount points (which ones?  on the cd or on the hd?  
> 
> By editing 
the mountlist, you are editing the partition layour which Mondo will create 
and/or expect to find on the hard disk.
> 
> If you edit the mountlist then you should be changing it either::-
> - to reflect the layout of the hard disk (although why your mountlist 
doesn't already match the hard disk, I don't know), or

Answer: I had to change the swapfile size to 1GB (from 500MB approx.,
20GB drive) for Sorcery Linux. Would this change cause Mondo not to be
able to proceed in the interactive restore, but instead fail with mount
problems?  Do you have any suggestions as to what I should do/try to get
Mondo to restore a file/directory?

> - to reflect what you would like the layout to be (in which case, you 
need to repartition and reformat)
> 
> If Mondo cannot mount any of your partitions, it might be because you 
are changing the desired layout without changing the actual layout.
> 

I haven't been changing the mount tables and Mondo bails with the mount
troubles.  Do you expect it to be different if I change the table to
match the HD table?  I'm kinda cautious with things to do with partition
tables, etc...

Martin.

*** There is an attachment in this mail. ***

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

Hi Daniel,

On Wednesday 30 January 2002 2:34 pm, Daniel Grandjean wrote:
> On a system, I'm using mirror, (raid-level 1)
> Mondo does not support RAID

Mondo has supported RAID since v1.1x. Mondo has included a RAID device editor 
since v1.34 (IIRC).

When you are in the mountlist editor at restore-time, please go to /dev/md0 
(or whatever your RAID device is) and hit 'edit'. Then, hit 'RAID...' to see 
the RAID editor.

> On the road to the RAID support:
> To my understanding, the files layout is all summarized in mountlist.txt.
> When there is no RAID, disk partition can be recreated from the
> mountlist.txt information.
> When there is a RAID, we got the size of the raid device, the physical
> layout should be looked up in the raidtab table.

It is.

> If the raid device is a concatenation, the information of each slice
> is missing.

What does that mean? I am confused. :)

-Hugo

Hi Kevin,

Thank you for your detailed feedback and your compliments. They are very much 
appreciated.

On Wednesday 30 January 2002 5:46 am, kevin rennert wrote:
> 1 - For some reason, the RedHat 7.2 install put the 'linear' flag in my
> lilo.conf. That's fine, (though it works fine with LBA32 mode), but
> when mondo-restore calls lilo with the -L option, lilo complains and
> quits without doing anything and I had to tweak it myself until I
> removed the 'linear' option. Does it make sense to test the file for
> the 'linear' option before automatically telling it to use LBA32 mode?

Mondo runs 'lilo -L' to setup your MBR. If that fails, it runs 'lilo' 
(without the -L). It is a bit inelegant but it usually works. Are you saying 
Mondo fails to initialize your Master Boot Record? If so, I would certainly 
like to see your logfile, which you can probaby find at 
/tmp/mondo-restore.log; the newer versions of Mondo save the restore-time log 
there, so that you don't have to remember to backup the log before you reboot 
after restoring.

> 2 - After lilo would bomb out, I would get the endless repeated question
> -- 'edit mountlist again', to which the only proper answer appeared to
> be 'no'. If I selected yes, it would just flash and ask me
> again... and again... and again... This actually was happening with
> mindi-0.53, but I'll test it with mindi-0.55 tomorrow morning.

Interactive Mode should let you re-edit the mountlist. I've checked the loop 
and it looks okay. Were you restoring in Nuke Mode?

> 3- If my /etc/fstab contains that weird LABEL=/ notation that redhat
> seems to want to use, after restoring, the boot process fails when it
> goes to mount on / . This is easily fixed by just making  the LABEL
> line look more like a regular fstab line, but I have no idea why it
> doesn't work, and someone new might not know to do this.

Did you switch filesystems, or leave them as ext2/ext3? If the latter then 
I'm puzzled. I use RH7.2 with LABELs in my fstab and I don't get that 
problem. It sounds as if the partitions aren't belng labeled. May I see your 
LABEL'd fstab file, please? BTW, does it make a difference if you say "no" 
when asked if you have modified the mountlist?

> 4 - All biggiefiles seem to be restored owned by root. Most of my
> system files that end up being biggiefiles are indeed root's, but I
> just backed up my /home directory and a bunch of wav files (and my
> mbox)  in my home dir got restored as root's. Is there any way to
> change this, or is it just a product of the slicing?

OK, I'm on it.

> 6 - Also, just for kicks I tried using the text-mode. This worked great
> for the most part, except that when it asks you questions about your
> kernel, the messages don't actually make it to the screen. 

I'm guessing that you're talking about what happens when Mondo cannot find 
your default kernel. In that situation, please add '--my-kernel 
/boot/vmlinuz' to the call to Mondo-Archive. Replace 'vmlinuz' with the name 
of your kernel's file in /boot.

-Hugo

Does your LILO default to a graphical boot screen? Perhaps a picture is being 
incorporate in the boot-time menu instead of the text message.

Try reinstalling LILO or removing/renaming the graphic to force LILO to use 
the text message instead.

-Hugo


On Wednesday 30 January 2002 12:48 pm, David wrote:
> I have been following the modo list for a while and wanting to use modo to
> back up my PC but when I originally tried using mindi it just wouldn't
> work. I have since updated my kernel and also installed all the required
> rpm's but am still getting some errors.
>
> If I use the fail safe kernel I get the following from the log file
>
> Your PATH did not include /sbin or /usr/sbin. I have fixed that,
> temporarily. However, you may wish to ask your vendor to provide a
> permanent fix... Mindi Linux mini-distro generator v0.55 by HRabson
> <hu...@fi...>------------------------------------------------------
>-- ----------------------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
> yourdisks then it may still be a result of a problem with your kernel.
>
> the interesting thing is that /sbin and /usr/sbin are in my path as can be
> seen even though they are duplicated. I will have to fix that.
>
> [root@c38739 mindi]# echo $PATH
> /usr/local/sbin:/usr/sbin:/sbin:/usr/java/jdk/jre/bin:/usr/java/jdk/bin:/bi
>n:
> /sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/bin/X11:/usr/X
>11 R6/bin:/root/bin
>
> That is just a minor point basically after that everything just sits
> as can be seen from my processes
> root     23510  4956  0 22:45 pts/7    00:00:00 /bin/sh ./mindi
> root     23539 23510  0 22:45 pts/7    00:00:00 tar -x
> --use-compress-program bzip2 -f-
> root     23540 23539  0 22:45 pts/7    00:00:00 tar -x
> --use-compress-program bzip2 -f-
> root     23541 23540  1 22:45 pts/7    00:00:02 bzip2 -d
>
> The bzip2 just sits there and decreases CPU usage and goes nowhere.
>
> Now if I use my own kernel 2.4.16 with all of the stuff in there that
> should be I get the attached tgz file. I bomb out on the 2880K boot image.
> I have tried increasing EXTRA_SPACE to 8192 and even 25000 but then I get
> the same error in creating the 1722K boot disk.
>
> Any ideas what is going on.
>
> I have a Redhat 7.0 but with some additions from Rawhide including KDE2.2.
> I have installed all the rpm's listed on the modo website but that was a
> month or 2 ago and then have just installed the latest stable versions of
> mondo/mindi.
>
> I am going to go ahead an copy the img files to the floppies guessing I
> should use a dd command to do this.