clonezilla-live

[Clonezilla-live] Restored Disk Image: eth issue

[RSCL M. <rsc...@gm...>]

Hi,

My concern is not directly related to Clonezilla, but generic to theconcept
of cloning.

I have a server with CentOS 5.3 and Samba.
As a back up measure against HDD and other peripheral failure, I have
purchased an identical PC and I plan to clone the main server and then run
rsync on daily basis.
Everything seems fine in this schematic and I am fine with this backup
approach.

My concern is:
Both the server's have identical specs sans the ethernet.
When I will restore the image on the 2nd PC, and boot, it will alert for a *new
ethernet device found* and by default it will create a new interface ETH1

Is there any way to avoid creating the new ethernet device ETH1 and be able
to use the the original ETH0.

One thought which crossed my mind, but I have not tried is, after cloning, I
can boot the server using a live distro (may be knopix), mount the cloned
HDD and make changes to the ETH configuration, namely MAC address or
whatever else. Not sure what should I change, and then boot the closed HDD.

Does this make sense ? Will it help.
Can someone throw light on how to prevent the creation of ETH1.

Thx in advance.

Best regards,
Vai

Re: [Clonezilla-live] Restored Disk Image: eth issue

[Les M. <les...@gm...>]

On 4/9/2010 10:20 AM, RSCL Mumbai wrote:

> My concern is not directly related to Clonezilla, but generic to
> theconcept of cloning.
>
> I have a server with CentOS 5.3 and Samba.
> As a back up measure against HDD and other peripheral failure, I have
> purchased an identical PC and I plan to clone the main server and then
> run rsync on daily basis.
> Everything seems fine in this schematic and I am fine with this backup
> approach.
>
> My concern is:
> Both the server's have identical specs sans the ethernet.
> When I will restore the image on the 2nd PC, and boot, it will alert for
> a *new ethernet device found* and by default it will create a new
> interface ETH1
>
> Is there any way to avoid creating the new ethernet device ETH1 and be
> able to use the the original ETH0.
>
> One thought which crossed my mind, but I have not tried is, after
> cloning, I can boot the server using a live distro (may be knopix),
> mount the cloned HDD and make changes to the ETH configuration, namely
> MAC address or whatever else. Not sure what should I change, and then
> boot the closed HDD.
>
> Does this make sense ? Will it help.
> Can someone throw light on how to prevent the creation of ETH1.

This isn't really a clonezilla issue - it has to do with the way that 
Linux 2.6.x detects hardware in a more or less random order so even with 
what you think is identical hardware, the NICs and possibly even disk 
controllers may be given different names at boot/detection time.  Centos 
compensates for this by putting the ethernet hardware address in the 
/etc/sysconfig/ifcfg-eth? files and renaming the devices to match in 
some later step.  I have sometimes been successful with a script that 
pre-creates these files with the new mac addresses and sometimes they 
just get renamed and ignored.  My servers tend to have 4 to 6 NICs so 
there is the additional problem of knowing ahead of time which wire will 
be plugged into which NIC and I'd love to find a general solution.  For 
the moment the best approach might be to use a DHCP server that you can 
configure to give the old IP to the new NIC, or at least have a few 
spare IPs to give out so you can connect after the new server boots and 
repair the damage.

-- 
   Les Mikesell
    les...@gm...

Re: [Clonezilla-live] Restored Disk Image: eth issue

[RSCL M. <rsc...@gm...>]

On Fri, Apr 9, 2010 at 9:20 PM, Les Mikesell <les...@gm...> wrote:

> On 4/9/2010 10:20 AM, RSCL Mumbai wrote:
>
> > My concern is not directly related to Clonezilla, but generic to
> > theconcept of cloning.
> >
> > I have a server with CentOS 5.3 and Samba.
> > As a back up measure against HDD and other peripheral failure, I have
> > purchased an identical PC and I plan to clone the main server and then
> > run rsync on daily basis.
> > Everything seems fine in this schematic and I am fine with this backup
> > approach.
> >
> > My concern is:
> > Both the server's have identical specs sans the ethernet.
> > When I will restore the image on the 2nd PC, and boot, it will alert for
> > a *new ethernet device found* and by default it will create a new
> > interface ETH1
> >
> > Is there any way to avoid creating the new ethernet device ETH1 and be
> > able to use the the original ETH0.
> >
> > One thought which crossed my mind, but I have not tried is, after
> > cloning, I can boot the server using a live distro (may be knopix),
> > mount the cloned HDD and make changes to the ETH configuration, namely
> > MAC address or whatever else. Not sure what should I change, and then
> > boot the closed HDD.
> >
> > Does this make sense ? Will it help.
> > Can someone throw light on how to prevent the creation of ETH1.
>
> This isn't really a clonezilla issue - it has to do with the way that
> Linux 2.6.x detects hardware in a more or less random order so even with
> what you think is identical hardware, the NICs and possibly even disk
> controllers may be given different names at boot/detection time.  Centos
> compensates for this by putting the ethernet hardware address in the
> /etc/sysconfig/ifcfg-eth? files and renaming the devices to match in
> some later step.  I have sometimes been successful with a script that
> pre-creates these files with the new mac addresses and sometimes they
> just get renamed and ignored.  My servers tend to have 4 to 6 NICs so
> there is the additional problem of knowing ahead of time which wire will
> be plugged into which NIC and I'd love to find a general solution.  For
> the moment the best approach might be to use a DHCP server that you can
> configure to give the old IP to the new NIC, or at least have a few
> spare IPs to give out so you can connect after the new server boots and
> repair the damage.
>
> --
>   Les Mikesell
>    les...@gm...
>
>
Thx Les,

Then I think I should stop looking around and just go ahead and manually set
up the required IP address on eth1 and move on.
Just that I will have to change the firewall script, but its a one time job.
So I should not really bother.

Thx & Cheers

Re: [Clonezilla-live] Restored Disk Image: eth issue

[Dale S. <ml...@ri...>]

On Fri, Apr 09, 2010 at 08:50:36PM +0530, RSCL Mumbai wrote:
> Hi,
> 
> My concern is not directly related to Clonezilla, but generic to
> theconcept of cloning.
> 
> I have a server with CentOS 5.3 and Samba.
> As a back up measure against HDD and other peripheral failure, I have
> purchased an identical PC and I plan to clone the main server and then run
> rsync on daily basis.
> Everything seems fine in this schematic and I am fine with this backup
> approach.
> 
> My concern is:
> Both the server's have identical specs sans the ethernet.
> When I will restore the image on the 2nd PC, and boot, it will alert for a
> new ethernet device found and by default it will create a new interface
> ETH1
> 
> Is there any way to avoid creating the new ethernet device ETH1 and be
> able to use the the original ETH0.
> 
> One thought which crossed my mind, but I have not tried is, after cloning,
> I can boot the server using a live distro (may be knopix), mount the
> cloned HDD and make changes to the ETH configuration, namely MAC address
> or whatever else. Not sure what should I change, and then boot the closed
> HDD.
> 
> Does this make sense ? Will it help.
> Can someone throw light on how to prevent the creation of ETH1.
> 
> Thx in advance.
> 
> Best regards,
> Vai

I have encountered this issue myself.

Speaking of Fedora, which ought to apply to CENTOS, there are
two places where the MAC address might be stored that would
need to be cleansed.  These are:

/etc/udev/rules.d/70-persistent-net.rules    (more recent Fedora releases)

/etc/sysconfig/network-scripts/ifcfg-eth0

If you clean those out, you should be OK with eth0.
If your system does not have /etc/udev/rules.d/70-persistent-net.rules
then file ifcfg-eth0 should be the only place that matters.

sed -i /etc/udev/rules.d/70-persistent-net.rules -e '/rule written by/d' -e '/^ PCI device/d' -e '/SUBSYSTEM=="net", ACTION=="add",/d' -e '/^$/d'

sed -i /etc/sysconfig/network-scripts/ifcfg-eth0 -e '/^HWADDR/d'

or update the HWADDR assignment to have the new MAC address.

Because my system had multiple NICs and because I wanted reproducible
NIC naming, I wrote a script that used lspci to determine the NIC
locations in the PCI bus topology and set HWADDR appropriately in
the ifcfg-eth* files and rename the NICs.

Now the question is:  Is there a way to have clonezilla automatically
execute such a script after an image restore?

Re: [Clonezilla-live] Restored Disk Image: eth issue

[RSCL M. <rsc...@gm...>]

On Fri, Apr 9, 2010 at 11:20 PM, Dale Stimson
<ml...@ri...<ml%2B...@ri...>
> wrote:

> On Fri, Apr 09, 2010 at 08:50:36PM +0530, RSCL Mumbai wrote:
> > Hi,
> >
> > My concern is not directly related to Clonezilla, but generic to
> > theconcept of cloning.
> >
> > I have a server with CentOS 5.3 and Samba.
> > As a back up measure against HDD and other peripheral failure, I have
> > purchased an identical PC and I plan to clone the main server and then
> run
> > rsync on daily basis.
> > Everything seems fine in this schematic and I am fine with this backup
> > approach.
> >
> > My concern is:
> > Both the server's have identical specs sans the ethernet.
> > When I will restore the image on the 2nd PC, and boot, it will alert for
> a
> > new ethernet device found and by default it will create a new interface
> > ETH1
> >
> > Is there any way to avoid creating the new ethernet device ETH1 and be
> > able to use the the original ETH0.
> >
> > One thought which crossed my mind, but I have not tried is, after
> cloning,
> > I can boot the server using a live distro (may be knopix), mount the
> > cloned HDD and make changes to the ETH configuration, namely MAC address
> > or whatever else. Not sure what should I change, and then boot the closed
> > HDD.
> >
> > Does this make sense ? Will it help.
> > Can someone throw light on how to prevent the creation of ETH1.
> >
> > Thx in advance.
> >
> > Best regards,
> > Vai
>
> I have encountered this issue myself.
>
> Speaking of Fedora, which ought to apply to CENTOS, there are
> two places where the MAC address might be stored that would
> need to be cleansed.  These are:
>
> /etc/udev/rules.d/70-persistent-net.rules    (more recent Fedora releases)
>
> /etc/sysconfig/network-scripts/ifcfg-eth0
>
> If you clean those out, you should be OK with eth0.
> If your system does not have /etc/udev/rules.d/70-persistent-net.rules
> then file ifcfg-eth0 should be the only place that matters.
>
> sed -i /etc/udev/rules.d/70-persistent-net.rules -e '/rule written by/d' -e
> '/^ PCI device/d' -e '/SUBSYSTEM=="net", ACTION=="add",/d' -e '/^$/d'
>
> sed -i /etc/sysconfig/network-scripts/ifcfg-eth0 -e '/^HWADDR/d'
>
> or update the HWADDR assignment to have the new MAC address.
>
> Because my system had multiple NICs and because I wanted reproducible
> NIC naming, I wrote a script that used lspci to determine the NIC
> locations in the PCI bus topology and set HWADDR appropriately in
> the ifcfg-eth* files and rename the NICs.
>
> Now the question is:  Is there a way to have clonezilla automatically
> execute such a script after an image restore?
>

Thx Dale. This is exactly what I was looking for.
I have many times tried changing ifcfg-eth0 file, but always found the OS to
still create a new interface.
Thx. I will try this first thing Monday morning and post my results.

I have 2 servers, surprisingly one of the server has the file
70-persistent-net.rules, and one does not.

*[root@v4 ~]# cat /etc/redhat-release
Fedora release 9 (Sulphur)
[root@v4 ~]# cat /etc/udev/rules.d/70-persistent-net.rules

# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet
controller (rule written by anaconda)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:19:d1:a6:fa:d3", ATTR{type}=="1", KERNEL=="eth*",
NAME="eth0"

# PCI device 0x1106:0x3106 (via-rhine)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:22:b0:61:22:52", ATTR{type}=="1", KERNEL=="eth*",
NAME="eth1"

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:19:d1:a6:f2:75", ATTR{type}=="1", KERNEL=="eth*",
NAME="eth2"
[root@v4 ~]#*


*[root@v44 rules.d]# cat /etc/redhat-release
CentOS release 5.3 (Final)
[root@v44 rules.d]#  cat /etc/udev/rules.d/
05-udev-early.rules   50-udev.rules         60-net.rules
60-raw.rules          90-alsa.rules         90-hal.rules
98-kexec.rules
40-multipath.rules    51-hotplug.rules      60-pcmcia.rules
85-pcscd_ccid.rules   90-dm.rules           95-pam-console.rules
bluetooth.rules
[root@v44 rules.d]# ll /etc/udev/rules.d/
total 124
-rw-r--r-- 1 root root   515 Jan 21  2009 05-udev-early.rules
-rw-r--r-- 1 root root   920 Jan 21  2009 40-multipath.rules
-rw-r--r-- 1 root root 15647 Jan 21  2009 50-udev.rules
-rw-r--r-- 1 root root   471 Jan 21  2009 51-hotplug.rules
-rw-r--r-- 1 root root   143 Nov 13  2008 60-net.rules
-rw-r--r-- 1 root root  1088 Jan  6  2007 60-pcmcia.rules
-rw-r--r-- 1 root root   452 Jan 21  2009 60-raw.rules
-rw-r--r-- 1 root root  1823 Jan 21  2009 85-pcscd_ccid.rules
-rw-r--r-- 1 root root   114 Jan 21  2009 90-alsa.rules
-rw-r--r-- 1 root root    61 Jan 21  2009 90-dm.rules
-rw-r--r-- 1 root root    82 Jan 20  2009 90-hal.rules
-rw-r--r-- 1 root root   107 Jan 21  2009 95-pam-console.rules
-rw-r--r-- 1 root root   292 Jan 21  2009 98-kexec.rules
-rw-r--r-- 1 root root  2319 Jul 14  2008 bluetooth.rules*


Any ideas if CentOS has an alternate location or file name.



And yes, if CloneZilla builds this feature, it will be of great help in HDD
replication for blind restoration -- I guess this is called bear-metal
restoration....

But well, I am more than happy with your post.
It helps be do what I have been searching since a long time.

Cheer

Re: [Clonezilla-live] Restored Disk Image: eth issue

[Dale S. <ml...@ri...>]

[Most previous thread content excised because of its length.]

On Fri, Apr 09, 2010 at 11:47:59PM +0530, RSCL Mumbai wrote:
> Thx Dale. This is exactly what I was looking for.
> I have many times tried changing ifcfg-eth0 file, but always found the OS
> to still create a new interface.
> Thx. I will try this first thing Monday morning and post my results.
> 
> I have 2 servers, surprisingly one of the server has the file
> 70-persistent-net.rules, and one does not.
> 
> [root@v4 ~]# cat /etc/redhat-release
> Fedora release 9 (Sulphur)
> [root@v4 ~]# cat /etc/udev/rules.d/70-persistent-net.rules
> 
> # This file was automatically generated by the /lib/udev/write_net_rules
> # program run by the persistent-net-generator.rules rules file.
> #
> # You can modify it, as long as you keep each rule on a single line.
> 
> # Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit
> Ethernet controller (rule written by anaconda)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:19:d1:a6:fa:d3", ATTR{type}=="1", KERNEL=="eth*",
> NAME="eth0"
> 
> # PCI device 0x1106:0x3106 (via-rhine)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:22:b0:61:22:52", ATTR{type}=="1", KERNEL=="eth*",
> NAME="eth1"
> 
> # PCI device 0x10ec:0x8168 (r8169)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:19:d1:a6:f2:75", ATTR{type}=="1", KERNEL=="eth*",
> NAME="eth2"
> [root@v4 ~]#
> 
> [root@v44 rules.d]# cat /etc/redhat-release
> CentOS release 5.3 (Final)
> [root@v44 rules.d]#  cat /etc/udev/rules.d/
> 05-udev-early.rules   50-udev.rules         60-net.rules         
> 60-raw.rules          90-alsa.rules         90-hal.rules         
> 98-kexec.rules
> 40-multipath.rules    51-hotplug.rules      60-pcmcia.rules      
> 85-pcscd_ccid.rules   90-dm.rules           95-pam-console.rules 
> bluetooth.rules
> [root@v44 rules.d]# ll /etc/udev/rules.d/
> total 124
> -rw-r--r-- 1 root root   515 Jan 21  2009 05-udev-early.rules
> -rw-r--r-- 1 root root   920 Jan 21  2009 40-multipath.rules
> -rw-r--r-- 1 root root 15647 Jan 21  2009 50-udev.rules
> -rw-r--r-- 1 root root   471 Jan 21  2009 51-hotplug.rules
> -rw-r--r-- 1 root root   143 Nov 13  2008 60-net.rules
> -rw-r--r-- 1 root root  1088 Jan  6  2007 60-pcmcia.rules
> -rw-r--r-- 1 root root   452 Jan 21  2009 60-raw.rules
> -rw-r--r-- 1 root root  1823 Jan 21  2009 85-pcscd_ccid.rules
> -rw-r--r-- 1 root root   114 Jan 21  2009 90-alsa.rules
> -rw-r--r-- 1 root root    61 Jan 21  2009 90-dm.rules
> -rw-r--r-- 1 root root    82 Jan 20  2009 90-hal.rules
> -rw-r--r-- 1 root root   107 Jan 21  2009 95-pam-console.rules
> -rw-r--r-- 1 root root   292 Jan 21  2009 98-kexec.rules
> -rw-r--r-- 1 root root  2319 Jul 14  2008 bluetooth.rules
> 
> Any ideas if CentOS has an alternate location or file name.
> 
> And yes, if CloneZilla builds this feature, it will be of great help in
> HDD replication for blind restoration -- I guess this is called bear-metal
> restoration....
> 
> But well, I am more than happy with your post.
> It helps be do what I have been searching since a long time.
> 
> Cheer

The bottom line, in my opinion:

For Centos 5.3, only ifcfg-eth* need to be changed.

For recent Fedora releases (including F9), ifcfg-eth* *and*
/etc/udev/rules.d/70-persistent-net.rules will need to be changed.

Details:

You are running two systems, one with Centos 5.3 and one with Fedora 9.

Centos 5.3's ultimate upstream was Fedora Core 6.  My recent
experience on this subject is with Fedora Core 5 and modern
Fedora (F11/F12).

Sometime between FC5 and F11, the udev scripts were significantly
changed.  Presumably Centos 5.3's implementation is similar
to FC5 and Fedora 9 is similar to F11/F12.

At the time of FC5, the udev scripts did not
use /etc/udev/rules.d/70-persistent-net.rules.  Rule
/etc/udev/rules.d/60-net.rules would invoke /lib/udev/rename_device
to maintain stable NIC naming, which if I recall correctly (from
when I looked at its source) uses only HWADDR in ifcfg-* files.

Therefore, your Centos 5.3 system might be OK if all you do is
change the ifcfg-eth* files.

For more recent Fedora, Anaconda or one of the rules:
    /lib/udev/rules.d/60-net.rules
    /lib/udev/rules.d/75-persistent-net-generator.rules
will handle NIC naming.

Rule /lib/udev/rules.d/60-net.rules may invoke
/lib/udev/rename_device, which would use HWADDR and ifcfg-*",
probably more or less as in Fedora 5.

As I recall, if no HWADDR is present in ifcfg-*, then
    /lib/udev/rules.d/75-persistent-net-generator.rules
(via /lib/udev/write_net_rules) will update
    /etc/udev/rules.d/70-persistent-net.rules