On Nov 30, 2008, at 1:46 AM, Andree Leidenfrost wrote:
Hi David,
It obviously took me way too long to look into this and respond. I am
sorry about this.
Andree
Thanks for looking into this, and thanks for all of your help with
Mondo on Debian.
If you are still around, it would be great if you could read on and
give
me your feedback.
Firstly, version 2.2.0-881 was not an actual Debian package, i.e.
something that you installed from a Debian repository, or was it?
Secondly, did you by any chance try to do this with a standard Debian
kernel?
I'm using a custom compiled kernel on Debian.
I've used both Debian packages and Mondo compiled from source code,
mainly because I have trouble getting it to work with Debian.
So I don't recall the answer to your first question, but I'm currently
having problems restoring from Mondo.
The restore starts, but hangs up about half way thru.
From your message, I am not 100% sure whether networking fails during
restore. From your mondoarchive parameters I understand that you
back up
to optical media and the presumably restore from it, so you would not
need the nwetwork working during the restore run. I therefore beleive
that the issue is with networking not working in the restored Debian
installation because of the change in z25_persistent-net.rules. Is
this
correct?
Yes, after a restore, the machine comes up with eth1 instead of the
eth0 is should have.
I just manually edit the z25 (now z70) file back to eth0, and reboot.
Not a big problem now that I know how to fix it.
Now the not able to restore is a big problem :-)
I have asked Bruno (Hi Bruno!) and here is what he pointed out
regarding
the matter:
$ pbg z25_persistent-net
./mindi/mindi: rm
-f ./etc/udev/rules.d/z25_persistent-net.rules
IIRC this is a patch you provided ;-)
svn diff -r 1789:1790
Index: mindi/mindi
===================================================================
--- mindi/mindi (révision 1789)
+++ mindi/mindi (révision 1790)
@@ -2821,6 +2821,8 @@
echo "udev device manager found" > tmp/USE-UDEV
LogIt "udev device manager found"
cp --parents -Rdf /etc/udev . 2> /dev/null
+ # This avoids NIC remapping if on another machine at
restore time on Debian at least
+ rm -f ./etc/udev/rules.d/z25_persistent-net.rules
cp --parents -Rdf /lib/udev /lib64/udev . 2> /dev/null
if [ -x /sbin/udevd ]; then
lis2=`grep -Ev '^#' $MINDI_CONF/udev.files`
I am not actually sure that I provided this patch, although it rings a
very faint bell - anyway.
z25_persistent-net.rules stores the result of udev running
persistent-net-generator.rules so that it is preserved during reboots.
The idea behind deleting this would be that when restoring, especially
on totally different or at least somewhat changed hardware (e.g. new
mainboard and/or different network hardware when restoring, udev
should
newly determine what the network interfaces are. This is generally a
good and correct approach I believe. So, we should really keep
deleting
z25_persistent-net.rules as per the above patch I think.
However, we delete in the restore environment only and do not change
the
udev config of the restored system. At least I think this is what we
do
- Bruno, do you think this is right or am I overlooking something
here?
With all the above said, would you be able to try and reproduce the
issue with the latest version in Debian unstable using a standard
kernel? This might give me enough information to successfully
reproduce
the problem which I have not been able to (things work fine for me in
this department)
The problem still exists for me, but I'm using a custom kernel.
I will give it a try with the standard kernel and let you know.
Thanks for following up !
mark
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
