mondo-devel Mailing List for Mondo Rescue

Hi,
 
is there a possibiliyt to automatically restore a system that wa sbacked up
on a sda device to a hda device ?

Thnaks and best regards
 
Niels

Hello,

Niels Przybilla said on Sun, Feb 26, 2006 at 01:47:32PM +0100:

> on the new ftp structure i cannot find the failsafe kernel.
> Where can I download it now ?

At the same place as the other packages, except I did not generate it up
to now for all distros.

Currently you can find one at:

ftp://ftp.mondorescue.org/rhel/3/mindi-kernel-1.05-254.rhel3.i386.rpm
and of course under ftp://ftp.mondorescue.org/src/mindi-kernel-1.0.tgz

Bruno.
-- 
Linux Solution Consultant   /   Open Source Evangelist   \    HP C&I EMEA ISG
HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Hi,

I've just had a disk failure on my laptop. Fortunately, I took a full 
mondo backup on 14/02.

However, when I try to restore, I see the message "Waiting for 
petris............".

Here's what I've done:

Replace disk with identical model
Partition same as previously:
/dev/hda1	100MB (for boot)
/dev/hda2	~74GB (lvm volume)
Reboot
Setup lvm:
/dev/VolGroup00/LogVol00  ~72GB	/
/dev/VolGroup00/LogVol01  2GB   swap

Create file systems + swap

Run mondorestore
Choose Interactive
Choose to restore from DVD disks

The Mondo Rescue screen says "I'm thinking..."
I hit Alt-Left
The log screen says:
[Main] mondo-rstr-tools.c->get_cfg_file_from_archive#2432: tmp = '(sleep 
15; kill `ps ax | grep "mount /dev/fd0u1722 
/tmp/tmpfs/mondo.tmp.17767/mount.bootdisk" | cut -d' ' -f1` 2> /dev/null)&'
Hit ALt-Left again:
Waiting for petris.........................................................

And that's as far as it goes.

Any suggestions what might be going wrong?

R.

Thanks for the quick response Andree, this time I'll answer more quickly :)

<snip>

> > growisofs will not run regularly under sudo on my systems
> > as I think I mentioned
> >       in one of my previous mails, so I wrap it in a small script as
> > described on the man page:
> >
> >       #!/bin/ksh
> >       unset SUDO_COMMAND
> >       export MKISOFS=3D/usr/bin/mkisofs
> >       exec growisofs.bin "$@"
>
> Well, if you run mondoarchive regularly to archive to DVD in the first
> place, you are in fact running growisofs implicitly as sudo regularly as
> well, no?
Sorry, having a bit of a slow morning, I don't think I understand the
above point :)
Yes I am running growisofs regularly with sudo via the above script. I
think we can both agree that running growisofs/mondarchive/whatever is
possible with the proper scripting. Where we differ is whether it
should be required. But really I'm not arguing any more. I can see
both sides to this and I'm happy enough to trundle along with a little
script-based tweaking.

> >      growisofs refuses to run under sudo on both FC4 and CentOS4.2, out=
put is:
> >      ":-( growisofs is being executed under sudo, aborting!
> >     See NOTES paragraph in growisofs manual page for further details."
>
> Ha! Vindication!! So, it's not just Debian!!! (Sorry for the outburst,
> Bruno will understand. ;-) )

Glad to help ;-)

<snip>
> > As I understand that your main objection to reverting to the original
> > situation is one of security and not wanting to go against the
> > growisofs policy.
>
> Nope. This is not at all about security as far as I'm concerned - sorry
> for invoking that impression in the first place. (Having looked into
> this more, I even doubt that the standard behaviour of growisofs really
> does increase security.)
>
> Rather, this is exclusively about telling the user what's wrong in a
> timely and comprehensible manner: Before, mondoarchive would happily
> plod on when asked to produce DVDs and run as sudo until it would get
> stopped dead by growisofs failing because of the issue we have this
> jolly conversation about. A weird error was the result.
>
> To alleviate this, we are currently implementing exactly the same check
> as growisofs does, so that we can anticipate growisofs's failure and
> give a timely and (hopefully) more useful error. (Admittedly, this is
> targeted at ill-versed users than yourself.)
>
Ah my mistake so, apologies. It appears mondoarchive is caught between
a rock and a hard place due to growisof's variable behaviour.

> Our problem is how to reliably detect such a script. For starters, I have
> only one word for the use of ksh: surreal! Checking for a specific string
> in the growisofs binary is a dream of unambiguity in comparison.
>
Well it should be enough to check if growisofs is a script and if so
to check whether it contains the "unset SUDO_COMMAND". Ugly I admit
though :/

Anyway, thanks for taking the time to discuss this,

Cian

Cian

Hi Cian,

On Mon, 2006-02-27 at 10:57 +0000, Cian Cullinan wrote:
> On 2/26/06, Andree Leidenfrost <ale...@bi...> wrote:
> > There has been no feedback on my original response, so I assume this is
> > rather low priority.
> 
> Right apologies for not replying sooner.

No worries whatsoever. Just thought I point this out. ;-)

> > 1) In my original response below, I was wrong in two ways:
> >    1.1) My mondo Debian package does NOT use sudo but rather su (via a
> >         standard Debian script called su-to-root). So, the sudo problem
> >         you describe does not apply to this. I have run mondoarchive in
> >         DVD mode from the menu and it works fine.
> 
>      I'm running CentOS4.2 and FC4.

Sure. This was just to correct my prior statement regarding Debian.
Nothing to do with you.

> >    1.2) Setting the growisofs binary setuid root does NOT make it work
> >         with sudo. I've tried it and it doesn't work. I've also looked
> >         at the code and there is nothing that would indicate that it
> >         should work. (I've looked at version 6.1.) I rather think now
> >         that I misinterpreted the manpage. Really it suggests to run
> >         growisofs setuid root as an alternative to using sudo. So the
> >         manpage effectively discourages the use of sudo. (Whether that
> >         makes sense is a different matter - see below.)
> >
>      Yes, the manpage discusses running growisofs suid root, and via sudo as
>       two separate things.

Ok, so that's sorted. Sorry for the confusion caused from my end.

> > 2) The growisofs SUDO handling seems to be an issue for others, too.
> >    See eg. here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=268308
> 
>       This bug report basically expresses the objection I have with 1)
> growisofs restricting
>       sudo usage, and 2) mondarchive reinforcing that behaviour.
> Namely, I'm a grown up,
>       and I should be trusted not to shoot myself in the foot unless
> of course I want to ;)

Well, to stick to the picture of mentioned bug report, you additionally
ought to be entitled to free choice of weapons to harms yourself - no
point in excluding sudo if there are others. ;-)

> >    A define has been available to build growisofs without the SUDO
> >    check since version 5.20: compiling with '-DI_KNOW_ALL_ABOUT_SUDO'
> >    should be all that is required. It just appears that distributions
> >    are not using it. This makes me wonder: What happens, when you call
> >    'sudo growisofs' on your system (assuming appropriate sudoers
> >    config)? Does it work? If yes, what does running:
> >        strings `which growisofs | grep SUDO_COMMAND
> >    give on your system (and what distribution are you running anyway)?
> >    If no, you are no worse off than before, really, you just use
> >    another script - please see the attached script and details below.
> >
>       I was not aware of this build option, thanks. However I do my
> very best to stick to
>       official distribution packages and avoid compiling from source
> these days. Life is too
>       short.

Cool. This was more to discuss which direction we could take with
mondoarchive to check for this...

> growisofs will not run regularly under sudo on my systems
> as I think I mentioned
>       in one of my previous mails, so I wrap it in a small script as
> described on the man page:
> 
>       #!/bin/ksh
>       unset SUDO_COMMAND
>       export MKISOFS=/usr/bin/mkisofs
>       exec growisofs.bin "$@"

Well, if you run mondoarchive regularly to archive to DVD in the first
place, you are in fact running growisofs implicitly as sudo regularly as
well, no?

> > 3) If distributions do compile growisofs with '-DI_KNOW_ALL_ABOUT_SUDO',
> >    we could probe for string 'SUDO_COMMAND' as described under 2).
> >    Debian for example does not currently do this. I don't know about
> >    others. Hence your input in regards to 2) would be valuable.
> >
>      growisofs refuses to run under sudo on both FC4 and CentOS4.2, output is:
>      ":-( growisofs is being executed under sudo, aborting!
>     See NOTES paragraph in growisofs manual page for further details."

Ha! Vindication!! So, it's not just Debian!!! (Sorry for the outburst,
Bruno will understand. ;-) )

> > 4) Alternatively, attached script provides a wrapper for mondoarchive
> >    identical to the one mentioned in the growisofs manpage for
> >    growisofs. With this wrapper in place, things work as before.
> 
>       Yes, I am already doing something similar (see my mail from Feb 20).

Okidoki.

> > 3) and 4) could both be implemented, where 3) would be a patch whereas
> > 4) would mean to include the attached script in mondo and provide some
> > documentation on how to use it.
> >
> > I would be happy to do both. I would not be happy to revert to the old
> > behaviour for the reasons I gave in my original response.
> >
> As I understand that your main objection to reverting to the original
> situation is one of security and not wanting to go against the
> growisofs policy.

Nope. This is not at all about security as far as I'm concerned - sorry
for invoking that impression in the first place. (Having looked into
this more, I even doubt that the standard behaviour of growisofs really
does increase security.)

Rather, this is exclusively about telling the user what's wrong in a
timely and comprehensible manner: Before, mondoarchive would happily
plod on when asked to produce DVDs and run as sudo until it would get
stopped dead by growisofs failing because of the issue we have this
jolly conversation about. A weird error was the result.

To alleviate this, we are currently implementing exactly the same check
as growisofs does, so that we can anticipate growisofs's failure and
give a timely and (hopefully) more useful error. (Admittedly, this is
targeted at ill-versed users than yourself.)

> Well I think my opinion on that is fairly clear,
> growisofs is attempting to cover a "perceived" security issue of sudo
> - something which is the responsibility of the computer administrator
> IMHO - and mondoarchive is reinforcing this.

I feel your pain. The problem really is that you are using bespoke script
to work around the growisofs issue and now mondorescue rains on your
parade. Sorry about that.

Our problem is how to reliably detect such a script. For starters, I have
only one word for the use of ksh: surreal! Checking for a specific string
in the growisofs binary is a dream of unambiguity in comparison. 

> Anyway, this has all become rather philisophical, apologies for that.

I actually like philosophical from time to time... ;-)

> I think we've covered the issue and how to work around it in enough
> detail that other mondoarchive users and people googling can use sudo
> if they wish.

... but agree with you.

Notwithstanding this and depending on Bruno's feedback, we may still do
what I for lack of fantasy decided to call 3) and/or 4).

> Regards,
> Cian

Regards,
Andree

> P.S.: you're script didn't make it through in your last mail.

Oops, sorry, attached now.
-- 
Andree Leidenfrost
Sydney - Australia

On 2/26/06, Andree Leidenfrost <ale...@bi...> wrote:
> There has been no feedback on my original response, so I assume this is
> rather low priority.

Right apologies for not replying sooner.

> 1) In my original response below, I was wrong in two ways:
>    1.1) My mondo Debian package does NOT use sudo but rather su (via a
>         standard Debian script called su-to-root). So, the sudo problem
>         you describe does not apply to this. I have run mondoarchive in
>         DVD mode from the menu and it works fine.

     I'm running CentOS4.2 and FC4.

>    1.2) Setting the growisofs binary setuid root does NOT make it work
>         with sudo. I've tried it and it doesn't work. I've also looked
>         at the code and there is nothing that would indicate that it
>         should work. (I've looked at version 6.1.) I rather think now
>         that I misinterpreted the manpage. Really it suggests to run
>         growisofs setuid root as an alternative to using sudo. So the
>         manpage effectively discourages the use of sudo. (Whether that
>         makes sense is a different matter - see below.)
>
     Yes, the manpage discusses running growisofs suid root, and via sudo a=
s
      two separate things.

> 2) The growisofs SUDO handling seems to be an issue for others, too.
>    See eg. here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D26830=
8

      This bug report basically expresses the objection I have with 1)
growisofs restricting
      sudo usage, and 2) mondarchive reinforcing that behaviour.
Namely, I'm a grown up,
      and I should be trusted not to shoot myself in the foot unless
of course I want to ;)

>    A define has been available to build growisofs without the SUDO
>    check since version 5.20: compiling with '-DI_KNOW_ALL_ABOUT_SUDO'
>    should be all that is required. It just appears that distributions
>    are not using it. This makes me wonder: What happens, when you call
>    'sudo growisofs' on your system (assuming appropriate sudoers
>    config)? Does it work? If yes, what does running:
>        strings `which growisofs | grep SUDO_COMMAND
>    give on your system (and what distribution are you running anyway)?
>    If no, you are no worse off than before, really, you just use
>    another script - please see the attached script and details below.
>
      I was not aware of this build option, thanks. However I do my
very best to stick to
      official distribution packages and avoid compiling from source
these days. Life is too
      short. growisofs will not run regularly under sudo on my systems
as I think I mentioned
      in one of my previous mails, so I wrap it in a small script as
described on the man page:

      #!/bin/ksh
      unset SUDO_COMMAND
      export MKISOFS=3D/usr/bin/mkisofs
      exec growisofs.bin "$@"

> 3) If distributions do compile growisofs with '-DI_KNOW_ALL_ABOUT_SUDO',
>    we could probe for string 'SUDO_COMMAND' as described under 2).
>    Debian for example does not currently do this. I don't know about
>    others. Hence your input in regards to 2) would be valuable.
>
     growisofs refuses to run under sudo on both FC4 and CentOS4.2, output =
is:
     ":-( growisofs is being executed under sudo, aborting!
    See NOTES paragraph in growisofs manual page for further details."

> 4) Alternatively, attached script provides a wrapper for mondoarchive
>    identical to the one mentioned in the growisofs manpage for
>    growisofs. With this wrapper in place, things work as before.

      Yes, I am already doing something similar (see my mail from Feb 20).

> 3) and 4) could both be implemented, where 3) would be a patch whereas
> 4) would mean to include the attached script in mondo and provide some
> documentation on how to use it.
>
> I would be happy to do both. I would not be happy to revert to the old
> behaviour for the reasons I gave in my original response.
>
As I understand that your main objection to reverting to the original
situation is one of security and not wanting to go against the
growisofs policy. Well I think my opinion on that is fairly clear,
growisofs is attempting to cover a "perceived" security issue of sudo
- something which is the responsibility of the computer administrator
IMHO - and mondoarchive is reinforcing this.

Anyway, this has all become rather philisophical, apologies for that.
I think we've covered the issue and how to work around it in enough
detail that other mondoarchive users and people googling can use sudo
if they wish.

Regards,
Cian

P.S.: you're script didn't make it through in your last mail.

I have installed mondorescue on a 64 Bit (HP-DL385) system running latest FC 4
Linux.

I do the following archive call:

mondoarchive -Oi -d /home/mondo -N -p `hostname -s` -E /home/mondo -L

Note that without -L (e.g. bzip2) it is pretty much the same.

It creates the first two iso-images in a reasonable time, but then it comes to:

[Main] libmondo-archive.c->slice_up_file_etc#3531: Sliced bigfile #4...OK!
        [Main] libmondo-archive.c->make_slices_and_images#2226: bigfile_fname = /var/log/lastlog

which takes some hours with really high cpu-load on a AMD 275 dual core cpu,
which makes it really unusable.

The reason is, that the sparse file /var/log/lastlog has a size of 1.2TB

[root@odo ~]# ll /var/log/lastlog
-rw-r--r--  1 root root 1254130450140 Feb 26 12:00 /var/log/lastlog

The following job takes all of the time from the cpu:

root     29866 18192 99 13:23 pts/0    01:35:48 md5sum /var/log/lastlog

I tried to exclue the last log with -E "/home/mondo /var/log/lastlog"
but this did not help. It looks like the -E option works only for directories
and not for single files (a feature request??)

It seems to me, that the compressed lastlog takes 1-2 iso-images.

There was a discussion at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154882
about a similar problem with tar and sparse file handling.

The reason that the last-log is so large, is user nfsnobody with user-id -1,
which gives:
nfsnobody:x:4294967294:4294967294:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
(see https://lists.dulug.duke.edu/pipermail/dulug/2005-July/016374.html)


--

J.Demel

Hi,
 
on the new ftp structure i cannot find the failsafe kernel.
Where can I download it now ?

Thanks and best regards
 
Niels

There has been no feedback on my original response, so I assume this is
rather low priority. Nevertheless, as I like to get to the bottom of
things, I've spent some quality time on this and here is the outcome:

1) In my original response below, I was wrong in two ways:
   1.1) My mondo Debian package does NOT use sudo but rather su (via a=20
        standard Debian script called su-to-root). So, the sudo problem=20
        you describe does not apply to this. I have run mondoarchive in=20
        DVD mode from the menu and it works fine.
   1.2) Setting the growisofs binary setuid root does NOT make it work=20
        with sudo. I've tried it and it doesn't work. I've also looked=20
        at the code and there is nothing that would indicate that it=20
        should work. (I've looked at version 6.1.) I rather think now=20
        that I misinterpreted the manpage. Really it suggests to run=20
        growisofs setuid root as an alternative to using sudo. So the=20
        manpage effectively discourages the use of sudo. (Whether that=20
        makes sense is a different matter - see below.)

2) The growisofs SUDO handling seems to be an issue for others, too.   =20
   See eg. here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D268308
   A define has been available to build growisofs without the SUDO=20
   check since version 5.20: compiling with '-DI_KNOW_ALL_ABOUT_SUDO'=20
   should be all that is required. It just appears that distributions=20
   are not using it. This makes me wonder: What happens, when you call=20
   'sudo growisofs' on your system (assuming appropriate sudoers=20
   config)? Does it work? If yes, what does running:
       strings `which growisofs | grep SUDO_COMMAND
   give on your system (and what distribution are you running anyway)?
   If no, you are no worse off than before, really, you just use=20
   another script - please see the attached script and details below.

3) If distributions do compile growisofs with '-DI_KNOW_ALL_ABOUT_SUDO',
   we could probe for string 'SUDO_COMMAND' as described under 2).=20
   Debian for example does not currently do this. I don't know about=20
   others. Hence your input in regards to 2) would be valuable.

4) Alternatively, attached script provides a wrapper for mondoarchive
   identical to the one mentioned in the growisofs manpage for=20
   growisofs. With this wrapper in place, things work as before.

3) and 4) could both be implemented, where 3) would be a patch whereas
4) would mean to include the attached script in mondo and provide some
documentation on how to use it.

I would be happy to do both. I would not be happy to revert to the old
behaviour for the reasons I gave in my original response.

In the meantime, the attached script should get you going without having
to recompile or patch mondoarchive.

Andree

On Sat, 2006-02-18 at 23:43 +1100, Andree Leidenfrost wrote:=20
> Hi Cian,
>=20
> I understand where you are coming from. So, let's have another look at
> this:
>=20
> The growisofs manpage does say:
>=20
> "If executed under sudo(8) growisofs refuses to start."
>=20
> Plain and simple. It later explains the workaround that you mention
> (unset SUDO_COMMAND) under the premise that you 'are  willing to take
> the consequences'.
>=20
> mondoarchive's behaviour was changed in the first place because of e.g.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D293147.
>=20
> I understand the desire to run mondoarchive via sudo, in fact
> distributions like Ubuntu would do this per default (also I have
> recently added a menu entry to the Debian package I maintain that in
> fact does use sudo as well). I am just not sure that we can simply
> ignore the rather severe security warning given in the growisofs manpage
> by using some sort of automatism. And an automatism it would have to be,
> I'm pretty sure, as I'd really like to avoid bug reports like the above.
>=20
> I appreciate you sharing your opinion that mondoarchive's behaviour in
> this context is not appropriate. I agree that it is definitely not a
> technical issue (but rather an issue of policy).
>=20
> I suppose mondoarchive could check whether:
> a) growisofs is really a script as described in the manpage
> b) growisofs is installed set-root-uid as mentioned in the manpage
> In either case, growisofs is supposed to work fine when called via sudo,
> and we could just proceed. If neither is the case, we could throw the
> same error as we do now.
>=20
> However, I'm strongly opposing the circumvention of security mechanisms
> put in place by the growisofs folks, i.e. using 'unset SUDO_COMMAND'
> directly inside mondoarchive. Apart from the immediate security
> implications it may have additional other unwanted and potentially
> dangerous side effects.
>=20
> What do you and everybody else think?
>=20
> Cheers,
> Andree
>=20
>=20
> On Fri, 2006-02-17 at 12:25 +0000, Cian Cullinan wrote:
> > Not really a bug report or a feature request, but something in between =
:)
> > I just updated my version of mondo to 2.06 from the FC4 rpms and
> > noticed that it now prevents you from calling growisofs through
> > mondoarchive if you ran mondoarchive with the 'sudo' command.
> > (this change was made in the post_param_configuration function in
> > libmondo-tools.c).
> > The error thrown is "Can't write DVDs as sudo because growisofs
> > doesn't support this - please see the growisofs manpage for details."
> > In my opinion it's not appropriate for mondoarchive to be doing this.
> > The man page for growisofs explains why the author thinks using sudo
> > is a bad idea (and I don't necessarily agree with him, but that's
> > another debate) but then goes on to explain how to proceed if that's
> > really what you want to do. Unfortunately this is no good now because
> > mondoarchive does its own checking and throws an exception if you use
> > sudo.
> > Looking at the code it would be very simple to circumvent this by
> > calling 'unset SUDO_COMMAND' before calling mondoarchive, but the
> > point is more that it's not really mondoarchive's place to enforce
> > restrictions on growisofs.
> > Thoughts?
> >=20
> > Cian
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=12164=
2
> > _______________________________________________
> > Mondo-devel mailing list
> > Mon...@li...
> > https://lists.sourceforge.net/lists/listinfo/mondo-devel
--=20
Andree Leidenfrost
Sydney - Australia

Dear all,

If you are using Mondo Rescue on Debian, you may be interested in my
newly created blog: http://andreeleidenfrost.blogspot.com/.

It basically supersedes the News section at:
http://www.desknow.com/desknow/directfiles/aleidenfrost/mr-debs-unofficial.=
 (And it will hopefully get updated more frequently! ;-) )

Cheers,
Andree
--=20
Andree Leidenfrost
Sydney - Australia

On suse which might be in the util-linux rpm. So check for which,
'whereis which' and if which is the only thing missing adding -nodeps is
probably ok.

JeffS


On Fri, 2006-02-24 at 09:19 -0800, Mark Nienberg wrote:
> Olaf Matthaei wrote:
> >
> >
> > error: Failed dependencies:
> > which is needed by mindi-1.06-266.sles9
> >
> You need to install the rpm package for "which".
> "yum install which" or whatever the SLES equivalent is.
> 

Olaf Matthaei wrote:
>
>
> error: Failed dependencies:
> which is needed by mindi-1.06-266.sles9
>
You need to install the rpm package for "which".
"yum install which" or whatever the SLES equivalent is.

-- 
Mark Nienberg, SE
Tipping Mar + associates
1906 Shattuck Ave
Berkeley, CA 94704
(510) 549-1906 ext 236
http://www.tippingmar.com

Olaf Matthaei said on Thu, Feb 23, 2006 at 01:53:02PM +0100:

> error: Failed dependencies:
> which is needed by mindi-1.06-266.sles9

Yes, this was an error in the 2.06 version which will not be in the next
2.0.7 due soon.

It's relatively easy to regenrate this rpm BTW by downloading the
src.rpm and removing the wrong dependency.

Bruno.
-- 
Linux Solution Consultant   /   Open Source Evangelist   \    HP C&I EMEA ISG
HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Randall R Schulz said on Wed, Feb 22, 2006 at 06:13:42AM -0800:

> > 1) The target has different look and feel than www.mondorescue.org.
> 
> Making it clear the different authorship and affiliation of the Wiki 
> relative to the primary Web site.

 I would add that the new page provides no way to get back to the
previous page (with menu). So we chose to open a new window in that
precise case, allowing the user to go on using the main menu bar, as
well as reading separately the new content. Clearly it's a choice more
in favor of less experimented users. For the Wiki, I have no way to
indicate it. For docs, I can precise it on the original page.

I hope to host a Wiki myself having a similar look&feel, so not forcing
a new page.

I think both positions are valid. We just made a choice.

> As I said, it's a usurpation of user control. There's no indication that 
> it will happen (in most browsers). And the one mode of control in 
> Mozilla.org browsers (which I do use, though currently it's still 
> mostly Mozilla 1.7) does not include keeping such links in the same tab 
> as the originating link.

Ok, clearly in Firefox, when I click on the Wiki menu with my middle
mouse button, it opens a new tab, not a new window. I'll add a "Firefox
friendly icon" to the site maybe ;-) Of course with mozilla clicking
with the middle button for me already opens a new window. But I tested
with konqueror and Mozilla, if you explicitely asks for opening rather
the wiki in a new tab, it just does it.

> I use these 
> features. I resent that decision having been made silently and 
> unilaterally for me in advance.

Well, of course Web site designer chose to present to you their
information the way they like the most, not necessarily the way you like
the most. Maybe you prefer green rather than blue as I do.

I'm sorry you do not find it convenient, but we were 2 to find it more
convcenient. Maybe we should add a pool function ;-)

Best regards,
Bruno.
-- 
Linux Solution Consultant   /   Open Source Evangelist   \    HP C&I EMEA ISG
HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Looks great!!!!!!!!!!


----- Original Message ----- 
From: "Bruno Cornec" <Bru...@hp...>
To: <mon...@li...>
Sent: Thursday, February 23, 2006 5:55 AM
Subject: Re: [Mondo-devel] [ANNOUNCE] Mondo Rescue has a new Web site


> Bruno Cornec said on Wed, Feb 22, 2006 at 07:09:31PM +0100:
>
>> Ok, I think I found why I had an issue yesterday. I will update the
>> system BIOS and Raid BIOS of the machine to avoid similar issues in the
>> future in a couple of minutes. Expect 20 minutes downtime again, and I
>> hope it won't happen soon again. At least this one is planned :-)
>
> Up again !
> -- 
> Linux Solution Consultant   /   Open Source Evangelist   \    HP C&I EMEA 
> ISG
> HP/Intel Solution Center http://hpintelco.net Hewlett-Packard 
> Grenoble/France
> Des infos sur Linux?  http://www.HyPer-Linux.org 
> http://www.hp.com/linux
> La musique ancienne?  http://www.musique-ancienne.org 
> http://www.medieval.org
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Mondo-devel mailing list
> Mon...@li...
> https://lists.sourceforge.net/lists/listinfo/mondo-devel
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> MailScanner thanks transtec Computers for their support.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.

Bruno Cornec said on Wed, Feb 22, 2006 at 07:09:31PM +0100:

> Ok, I think I found why I had an issue yesterday. I will update the
> system BIOS and Raid BIOS of the machine to avoid similar issues in the
> future in a couple of minutes. Expect 20 minutes downtime again, and I
> hope it won't happen soon again. At least this one is planned :-)

Up again !
-- 
Linux Solution Consultant   /   Open Source Evangelist   \    HP C&I EMEA ISG
HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Bruno Cornec said on Wed, Feb 22, 2006 at 02:40:21PM +0100:

> Ok, a hope this time it will stay longer up ;-)
> So it's back again at http://www.mondorescue.org

Ok, I think I found why I had an issue yesterday. I will update the
system BIOS and Raid BIOS of the machine to avoid similar issues in the
future in a couple of minutes. Expect 20 minutes downtime again, and I
hope it won't happen soon again. At least this one is planned :-)

Bruno.
-- 
Linux Solution Consultant   /   Open Source Evangelist   \    HP C&I EMEA ISG
HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Robert W. Holder said on Wed, Feb 22, 2006 at 04:49:42PM +1100:

> Anyone had success migrating from SATA drives to PATA drives?

IMO that should not cause any problem at all. Just adapt your mountlist
during restore. mondorestore will do that interactively for you, while
not finding the original device.

> Ultimately I also want to set up RAID where there was none, but walking 
> before running is the key to success, I think.

Well, it depends, as these are 2 completely different and parallel
operations. You may want to look at
http://www.mondorescue.org/docs/HOWTO-_Deploy_Linux_from_SCSI_to_SATA.pdf 
for more details.

HTH,
Bruno.
-- 
Linux Solution Consultant   /   Open Source Evangelist   \    HP C&I EMEA ISG
HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Andree,

On Wednesday 22 February 2006 05:13, Andree Leidenfrost wrote:
> Randall,
>
> Thank you for you comments on the new Mondo Rescue website.
>
> The reason that 'target=_blank' is used for the Wiki link (and a
> number of other links for that matter) is that:
>
> 1) The target has different look and feel than www.mondorescue.org.

Making it clear the different authorship and affiliation of the Wiki 
relative to the primary Web site.


> 2) One completely leaves the confines of www.mondorescue.org
>    which may be unwanted and surprising to users.

A hyper link going to a different site might be "unwanted" and 
"surprising?" That's pretty hard to believe. It's what the Web is 
about.


> Modern browsers like Firefox provide good control about new windows.
> As an example, they can be configured to create a new tab instead. I
> assume you are aware of this. Taking this into account, what exactly
> don't you like about a new tab being created when the scope of your
> browser contents changes considerably?

As I said, it's a usurpation of user control. There's no indication that 
it will happen (in most browsers). And the one mode of control in 
Mozilla.org browsers (which I do use, though currently it's still 
mostly Mozilla 1.7) does not include keeping such links in the same tab 
as the originating link.

I dislike this all very much. When I want a link opened in a new tab or 
window, which is fairly often and for my own reasons, I use these 
features. I resent that decision having been made silently and 
unilaterally for me in advance.


> Best regards,
> Andree


Randall Schulz

Hello,

JeffS said on Wed, Feb 22, 2006 at 08:54:27AM -0500:
> At the top of the page appears this note:
> 
> stable-r422 - 2006-02-21 

I thought it wouldn't be looked at, but it seems the new site is 
analyzed with fine-grained eyes ;-)


> What does it mean? 

This is the SVN revision used for the delivery.
THe Web site content is managed under SVN as well as the code, so I used
the r422 for the delivery of the Web site. Useful for people who want
to know the differences between what is live, and what is in the tree
(Andree and I mainly).

> That version number does not appear in the ../src
> area. Unless I missed it :-(

No. Now that the web site is in a better shape (at least I hope, and the
first feedbacks seem to indicate it), I'll go back with Andree to the code
work, and we'll deliver soon a 2.0.7/1.0.7 version of mondo/mindi.

Not all the modifications you are expecting will be in, be before we
change more deeply the tree, we want to deliver that step. 

Roadmap is already available at :
http://openfacts.berlios.de/index-en.phtml?title=Mondorescue_Roadmap

Of course, nothing prevents you to get the latest SVN state to have
access to those r4xx versions.

Bruno.
-- 
Linux Solution Consultant   /   Open Source Evangelist   \    HP C&I EMEA ISG
HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

On Wed, Feb 22, 2006 at 02:40:21PM +0100, Bruno Cornec wrote:
> Ok, a hope this time it will stay longer up ;-)
> So it's back again at http://www.mondorescue.org

Yup. It's back.

> > > Btw.: The link to the original website points to a Fedora Core Test
> > > Page, but you already know that, right? ;-)
> 
> I copied the old content in a new Web zone which should be accessible as
> http://oldwww.mondorescue.org as soon as DNS propagation is finished.

Works for me. We run our own DNS Servers here of course. ;-)

Btw.: If you ever take down the original site, please put the nice
image with the palm trees somewhere.

-- 
Andreas Micklei
IVISTAR Kommunikationssysteme AG
Ehrenbergstr. 19 / 10245 Berlin
http://www.ivistar.de

At the top of the page appears this note:

stable-r422 - 2006-02-21 


What does it mean? That version number does not appear in the ../src
area. Unless I missed it :-(

Thanks,
Jeff

Bruno Cornec said on Tue, Feb 21, 2006 at 03:57:44PM +0100:

> Alas, I made a mistake, and it's now not accessible anymore. As I'm
> working remotely, I won't be able to put it up again before tomorrow :-(
> Strange annouce indeed !

Ok, a hope this time it will stay longer up ;-)
So it's back again at http://www.mondorescue.org

> > Btw.: The link to the original website points to a Fedora Core Test
> > Page, but you already know that, right? ;-)

I copied the old content in a new Web zone which should be accessible as
http://oldwww.mondorescue.org as soon as DNS propagation is finished.

Bruno.
-- 
Linux Solution Consultant   /   Open Source Evangelist   \    HP C&I EMEA ISG
HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Hi Curtis,

For starters, could you run

'mindi --makemountlist /tmp/mountlist.txt.test'

as root and post the result.


Further to that, amd64 was only officially supported on Debian from
mondo 2.06-2 and mondo 1.06-2. Current and recommended versions are
2.06-3 and 1.06-3, respectively.

Maybe you could upgrade the packages installed on your kanotix using the
latest stock Debian packages from Debian Sid?

Cheers,
Andree

On Tue, 2006-02-21 at 15:59 -0800, gar...@ma... wrote:
>   Hi, all,
>=20
>    I just installed Mondo and Mindi on an x86_64 Debian system
> (specifically, it's running the 2.6.14-kanotix64-9 kernel, which may
> not really be supported by your application). It seemed to install
> fine, with no missing or forced dependencies, etc.
>    However, upon running "mondoarchive" as root, I got the following
> message(s):
>=20
>  Initializing...
> See /var/log/mondo-archive.log for details of backup run.
> Checking sanity of your Linux distribution
> Mindi --makemountlist /tmp/mountlist.txt.test failed for some reason.
> Please run that command by hand and examine /var/log/mindi.log
> for more information. Perhaps your /etc/fstab file is insane.
> Perhaps Mindi's MakeMountlist() subroutine has a bug. We'll see.
> Failed.
> Fatal error... Pre-param initialization phase failed. Please review the
> error messages above, make the specified changes, then try again.
> Exiting...
> ---FATALERROR--- Pre-param initialization phase failed. Please review the
> error messages above, make the specified changes, then try again.
> Exiting...
> If you require technical support, please contact the mailing list.
> See http://www.mondorescue.org for details.
> The list's members can help you, if you attach that file to your e-mail.
> 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=3D254
> Type 'less /var/log/mondo-archive.log' to see the output log
>=20
>     As per requests, I will attach the gzipped mondo-archive log, and the
> mindi.err file. I'm not sure what else to do at this point (although I
> did try running the "Mindi --makemountlist /tmp/mountlist.txt.test"
> command by hand, but it requires a lowercase "mindi" -- this might be
> changed in the scripts' documentation -- in any case, this still
> returns a "Fatal error. DebFindFailsafe failed." message).
>=20
>         Regards, Curtis O.
>=20
> Oh, and my fstab file is as below. Doesn't seem insane to me, but then I
> don't know much about it:
>=20
> # /etc/fstab: static file system information.
> #
> # <file system> <mount point>   <type>  <options>       <dump>  <pass>
> proc            /proc           proc    defaults        0       0
> usbfs  /proc/bus/usb  usbfs  devmode=3D0666  0  0
> /dev/hda5       /               reiserfs defaults        0       1
> /dev/hda1       /media/hda1     ntfs    ro,umask=3D000    0       0
> /dev/hda6       none            swap    sw              0       0
> /dev/hda7       /media/hda7     ext3    defaults        0       0
> /dev/hda8       /media/hda8     ext3    defaults        0       0
> /dev/cdrom      /media/cdrom0   udf,iso9660 user,noauto     0       0
> none /sys sysfs defaults 0 0
>=20
--=20
Andree Leidenfrost
Sydney - Australia

Randall,

Thank you for you comments on the new Mondo Rescue website.

The reason that 'target=3D_blank' is used for the Wiki link (and a number
of other links for that matter) is that:

1) The target has different look and feel than www.mondorescue.org.
2) One completely leaves the confines of www.mondorescue.org
   which may be unwanted and surprising to users.

Modern browsers like Firefox provide good control about new windows. As
an example, they can be configured to create a new tab instead. I assume
you are aware of this. Taking this into account, what exactly don't you
like about a new tab being created when the scope of your browser
contents changes considerably?

Best regards,
Andree

On Tue, 2006-02-21 at 06:31 -0800, Randall R Schulz wrote:
> Bruno and Andree,
>=20
> On Tuesday 21 February 2006 03:47, Bruno Cornec wrote:
> > Hello,
> >
> > Thanks to Ayo's authorization, and after 2 weeks of hard work, we are
> > proud to announce that we now have a new and updated Web site. We
> > hope it will be useful and wait for your feedback.
> >
> > You may find it at http://www.mondorescue.org (IP: 213.30.161.23)
>=20
> Very nice.
>=20
> May I ask that a new window not be created when one clicks the "Wiki"=20
> link at the top? I consider this kind of use of the target=3D'_blank'=20
> attribute to be a usurpation of the user's ability to choose where a=20
> link is opened. All modern browsers have an "Open in new window" or=20
> "Open in new tab" command, after all. It's not so easy to suppress the=20
> behavior produced by the target=3D attribute and there's no way of=20
> knowing in advance when you'll be presented with a new window.
>=20
>=20
> > Bruno and Andree
>=20
>=20
> Randall Schulz
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Mondo-devel mailing list
> Mon...@li...
> https://lists.sourceforge.net/lists/listinfo/mondo-devel
--=20
Andree Leidenfrost
Sydney - Australia