Moving boot drive to another machine , net not working

SUSE Product Topics SLES Networking
1

I have some blade servers that do not have any display adapters, and therefore I cannot see what’s happening when it boots. So generally when I am imaging these machines for RHEL, I can image it on another machine, then just copy the ifcfg-ens1 to ifcfg-p1p1, then edit the p1p1 file to change relevant details, then I run ‘nmcli connection reload’, then the network works fine on the new machine.

However, with SLES they just use eth0 or eth1 as the name. I have set the udev 70-persistent-net.rules to use the new MAC address and I have made sure to disable the firewall via ‘systemctl disable firewalld’ and ‘system stop firewalld’, yes I still can’t connect to the machine when it’s in the different server. Is there some special trick to doing this on SLES?

2

Hi sqlperf,

welcome to the forums.

As your description seems like the proper way to go, do you have any chance to see what happened? Does the blade chassis enclosure provide some networked console switch to access the servers, especially after the start?

Another option to try could be to simply remove the entry from persistent-net and let the OS detect and enter the new address.

Regards,
J

3

OK, I was able to resolve this by deleting the udev rule. After that, the machine booted up fine and I was able to connect via SSH.

[QUOTE=jmozdzen;54925]Hi sqlperf,

welcome to the forums.

As your description seems like the proper way to go, do you have any chance to see what happened? Does the blade chassis enclosure provide some networked console switch to access the servers, especially after the start?

Another option to try could be to simply remove the entry from persistent-net and let the OS detect and enter the new address.

Regards,
J[/QUOTE]

4

Hi sqlperf,

  			OK, I was able to resolve this by deleting the udev rule. After  that, the machine booted up fine and I was able to connect via SSH.

That’s good news. Just for curiosity’s sake: have you check what is different in the newly generated rule from when you pre-edited the file instead?

Regards,
J

5

Here’s the first one (not working). Eth1 had the correct MAC address.

This file was automatically generated by the /usr/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, and change only the value of the NAME= key.

mlx4_core (0000:04:00.0)

SUBSYSTEM==“net”, ACTION==“add”, DRIVERS==“?", ATTR{address}==“7c:fe:90:xx:xx:xx”, ATTR{dev_id}==“0x0”, ATTR{type}==“1”, KERNEL=="eth”, NAME=“eth0”

mlx4_core (0000:03:00.0)

SUBSYSTEM==“net”, ACTION==“add”, DRIVERS==“?", ATTR{address}==“7c:fe:90:xx:xx:xx”, ATTR{dev_id}==“0x0”, ATTR{type}==“1”, KERNEL=="eth”, NAME=“eth1”

Here’s the working version:

This file was automatically generated by the /usr/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, and change only the value of the NAME= key.

mlx4_core (0000:03:00.0)

SUBSYSTEM==“net”, ACTION==“add”, DRIVERS==“?", ATTR{address}==“7c:fe:90:xx:xx:xx”, ATTR{dev_id}==“0x0”, ATTR{type}==“1”, KERNEL=="eth”, NAME=“eth0”

[QUOTE=jmozdzen;54957]Hi sqlperf,

  			OK, I was able to resolve this by deleting the udev rule. After  that, the machine booted up fine and I was able to connect via SSH.

That’s good news. Just for curiosity’s sake: have you check what is different in the newly generated rule from when you pre-edited the file instead?

Regards,
J[/QUOTE]

6

Hi sqlperf,

that result makes me curious.

If the mac addresses differ in your manually edited file, you were (per your comment) using eth1 for the device. The generated version uses eth0, though, and that works. Did you put the network parameters in the file /etc/sysconfig/network/ifcfg-eth0 or …/ifcfg-eth1?

Regards,
J