Hi,
I have a few identical Dell Optiplex 7010 machines that I want to use for our school's computer room. I tried to clone these installations (like I did before on CentOS 5 and various versions of Slackware), but this time I ran into a problem.
Here's what I did.
1. Install one computer and zero unused hard disk sectors with dd.
2. Send the image to a local FTP server using G4L (Ghost4Linux).
3. Fetch the image on another computer.
4. Boot the new computer in rescue mode and change the hardcoded /etc/hostname to a new value.
Let me add that I removed all hardcoded MAC addresses from /etc/sysconfig/ifcfg-em1, which has only very limited information in it.
What else could cause the network to choke on a cloned installation?
Cheers,
Niki
At Fri, 3 May 2019 18:48:30 +0200 CentOS mailing list centos@centos.org wrote:
Hi,
I have a few identical Dell Optiplex 7010 machines that I want to use for our school's computer room. I tried to clone these installations (like I did before on CentOS 5 and various versions of Slackware), but this time I ran into a problem.
Here's what I did.
Install one computer and zero unused hard disk sectors with dd.
Send the image to a local FTP server using G4L (Ghost4Linux).
Fetch the image on another computer.
Boot the new computer in rescue mode and change the hardcoded
/etc/hostname to a new value.
Let me add that I removed all hardcoded MAC addresses from /etc/sysconfig/ifcfg-em1, which has only very limited information in it.
I think you need to re-code each machine's MAC address into ifcfg-em1.
What else could cause the network to choke on a cloned installation?
Cheers,
Niki
On Fri, May 3, 2019 at 11:48 AM Nicolas Kovacs info@microlinux.fr wrote:
Here's what I did.
Install one computer and zero unused hard disk sectors with dd.
Send the image to a local FTP server using G4L (Ghost4Linux).
Fetch the image on another computer.
Boot the new computer in rescue mode and change the hardcoded
/etc/hostname to a new value.
Let me add that I removed all hardcoded MAC addresses from /etc/sysconfig/ifcfg-em1, which has only very limited information in it.
What else could cause the network to choke on a cloned installation?
systemctl daemon-reload
That will cause SystemD to refresh it's internal state about the settings in config files.
On Fri May 03 06:48:30 PM, Nicolas Kovacs wrote:
Hi,
I have a few identical Dell Optiplex 7010 machines that I want to use for our school's computer room. I tried to clone these installations (like I did before on CentOS 5 and various versions of Slackware), but this time I ran into a problem.
Here's what I did.
Install one computer and zero unused hard disk sectors with dd.
Send the image to a local FTP server using G4L (Ghost4Linux).
Fetch the image on another computer.
Boot the new computer in rescue mode and change the hardcoded
/etc/hostname to a new value.
Let me add that I removed all hardcoded MAC addresses from /etc/sysconfig/ifcfg-em1, which has only very limited information in it.
What else could cause the network to choke on a cloned installation?
Whenever I clone one machine to another (under CentOS 6 anyway) the cloned machine comes up with a different network port, so I have to move /etc/sysconfig/network-scripts/ifcfg-eth0 to ifcfg-eth1 and update all the relevant entries in that file (as well as removing the MAC address).
Cheers, Zube
Am 03.05.2019 um 18:48 schrieb Nicolas Kovacs info@microlinux.fr:
Hi,
I have a few identical Dell Optiplex 7010 machines that I want to use for our school's computer room. I tried to clone these installations (like I did before on CentOS 5 and various versions of Slackware), but this time I ran into a problem.
Here's what I did.
Install one computer and zero unused hard disk sectors with dd.
Send the image to a local FTP server using G4L (Ghost4Linux).
Fetch the image on another computer.
Boot the new computer in rescue mode and change the hardcoded
/etc/hostname to a new value.
Let me add that I removed all hardcoded MAC addresses from /etc/sysconfig/ifcfg-em1, which has only very limited information in it.
What else could cause the network to choke on a cloned installation?
Any MACs in /etc/udev/rules.d/70-persistent-net.rules ?
-- LF
Le 03/05/2019 à 20:10, Leon Fauster via CentOS a écrit :
Any MACs in /etc/udev/rules.d/70-persistent-net.rules ?
After some more experimenting, I found out the showstopper was completely unrelated to cloning. Someone had the unfortunate idea of doing a hard reset on a local wireless access point, which resulted in two active DHCP servers for two different subnets. As soon as this problem was solved, all cloned PCs booted perfectly.
The only thing I had to do was edit the hardcoded hostnames in /etc/hostname.
Cheers,
Niki
Nicolas Kovacs wrote:
Le 03/05/2019 à 20:10, Leon Fauster via CentOS a écrit :
Any MACs in /etc/udev/rules.d/70-persistent-net.rules ?
After some more experimenting, I found out the showstopper was completely unrelated to cloning. Someone had the unfortunate idea of doing a hard reset on a local wireless access point, which resulted in two active DHCP servers for two different subnets. As soon as this problem was solved, all cloned PCs booted perfectly.
The only thing I had to do was edit the hardcoded hostnames in /etc/hostname.
Right, and of course you weren't on the need-to-know list....
Glad to hear it worked out.
mark