| View previous topic :: View next topic |
| Author |
Message |
acy
n00b
Joined: 25 Mar 2024
Posts: 11
|
 Posted: Mon Mar 25, 2024 12:23 pm Post subject: net.net0 not recognised after Clonezilla restore |
 |
|
Hi,
I'm working with a system here that I need to clone and make sure I have it backed up in its original state. I have created an image using Clonezilla successfully, the image restores all the parititions and the entire system as it is. However, for some reason after I use the restore, net.net0 doesn't exist anymore. The hardware works, as I have several disks that do work (the source that was cloned). Everything works fine when I use the original disk, but when I restore the image on another identical disk, I get this problem. Does anyone have any idea what could be wrong or what may be causing this issue?
Here is the only information I am getting when starting up the system. When using iconfig, I only see inet, and no net.net0. Service can obviously not be started.
https://ibb.co/MGV33JZ
Thank you in advance
Disclaimer: I am very new to gentoo so treat me like I am 5. |
|
| Back to top |
|
 |
acy
n00b
Joined: 25 Mar 2024
Posts: 11
|
| Posted: Mon Mar 25, 2024 12:38 pm Post subject: |
|
|
I found this:
https://forums.gentoo.org/viewtopic-t-1114338-start-0.html
And I seem to have the same problem that CONFIG_BROADCOM_PHY is not set. But I don't know how to change the setting, and how to rebuild the kernel to test this.
Furthermore, this is something that needs to be working from the beginning when restoring from a clone. Any ideas? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54253
Location: 56N 3W
|
| Posted: Mon Mar 25, 2024 12:52 pm Post subject: |
|
|
acy,
Welcome to Gentoo.
Log in and run the command then post the names of the interfaces you do see.
If this worked on *identical* hardware before the clone, it should work now too.
You will only need a kernel change if the hardware differs and the new hardware is not supported.
net.net0 is a non-standard Gentoo interface name. Is this a Gentoo install you are working with?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
acy
n00b
Joined: 25 Mar 2024
Posts: 11
|
| Posted: Mon Mar 25, 2024 1:00 pm Post subject: |
|
|
| NeddySeagoon wrote: | acy,
net.net0 is a non-standard Gentoo interface name. Is this a Gentoo install you are working with? |
Thank you!
Yes, you are correct. I was told that we needed to use a certain name on the interface to avoid confusion, however, I don't understand why a dead on copy of the system didn't include that change.
The original version of the system has it as net.net0. So I am guessing we are just going to end up changing the name of the interface.
Here is the result of the command:
https://ibb.co/Vm0ZdHh
Sorry about the blackout, there needs to be some discretion from my part. |
|
| Back to top |
|
|
Ralphred
Guru
Joined: 31 Dec 2013
Posts: 501
|
| Posted: Mon Mar 25, 2024 1:24 pm Post subject: |
|
|
| acy wrote: | | I don't understand why a dead on copy of the system didn't include that change. |
Permanent interface names are assigned to NIC mac addresses, ironically one of the only things to change when comparing "identical" hardware.
The common solution for permanent interface naming is a udev .rules file that assigns a name based on mac.
Running | Code: | | grep net0 /etc/udev/rules.d/* |
should identify the file for you and allow you to update the mac address to match the hardware.
EDIT: I should have included this; if it doesn't work, add the file | /etc/udev/rules.d/70-persistant-net.rules: | | SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="c4:00:ad:29:2f:43", NAME="net0" |
and it should work. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54253
Location: 56N 3W
|
| Posted: Mon Mar 25, 2024 1:59 pm Post subject: |
|
|
Ralphred,
udev used to assign names based on MAC addresses by default.
It would even exchange kernel allocated device names.
That changed when it got sucked into systemd. The enp3s0 is named after the PCI bus and slot.
Its just changed one set of corner cases for another.
acy,
Your kernel is fine, it's just that your network interface did not get renamed as you were expecting. Its called enp3s0 now.
| Code: | | ATTR{address}=="c4:00:ad:29:2f:43" |
is unique to your enp3s0, so using that udev rule will only fix the naming this once.
If you expect to restore the clone to other systems, we need to look at other solutions to this, unless restore and and edit the rule is OK.
Thinking about cloning, if you use sshd, you need to remove the /etc/ssh/ssh_host_* from any and all clones.
Its a very bad thing to clone the ssh identity of a system.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Ralphred
Guru
Joined: 31 Dec 2013
Posts: 501
|
| Posted: Mon Mar 25, 2024 2:27 pm Post subject: |
|
|
| NeddySeagoon wrote: | Thinking about cloning, if you use sshd, you need to remove the /etc/ssh/ssh_host_* from any and all clones.
Its a very bad thing to clone the ssh identity of a system. |
Some sort of post clone set-up script seems to be the order of the day. The fact you could try to match your udev rule to a hardware ID gives a good "have I been run yet" test, but if it is identical hardware then enp3s0 will be essentially static between machines. I know there are other "run once" solutions but I'm loath to trust them in the case of cloning. |
|
| Back to top |
|
|
acy
n00b
Joined: 25 Mar 2024
Posts: 11
|
| Posted: Mon Mar 25, 2024 3:55 pm Post subject: |
|
|
| Ralphred wrote: | | NeddySeagoon wrote: | Thinking about cloning, if you use sshd, you need to remove the /etc/ssh/ssh_host_* from any and all clones.
Its a very bad thing to clone the ssh identity of a system. |
Some sort of post clone set-up script seems to be the order of the day. The fact you could try to match your udev rule to a hardware ID gives a good "have I been run yet" test, but if it is identical hardware then enp3s0 will be essentially static between machines. I know there are other "run once" solutions but I'm loath to trust them in the case of cloning. |
Ralphred,
Adding the file /etc/udev/rules.d/70-persistant-net.rules along with the line:
| Code: | | SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="c4:00:ad:29:2f:43", NAME="net0" |
did in fact work. My first thought then was to create a script that would poll the mac-address and create this file with this line adjusted accordingly. Is that possible to pull off?[/code] |
|
| Back to top |
|
|
acy
n00b
Joined: 25 Mar 2024
Posts: 11
|
| Posted: Mon Mar 25, 2024 3:59 pm Post subject: |
|
|
| NeddySeagoon wrote: |
If you expect to restore the clone to other systems, we need to look at other solutions to this, unless restore and and edit the rule is OK.
Thinking about cloning, if you use sshd, you need to remove the /etc/ssh/ssh_host_* from any and all clones.
Its a very bad thing to clone the ssh identity of a system. |
For now the edit rule is fine for development purposes, but the big picture is that I would want this clone to work universally for identical systems.
This means I need to create some sort of script that automatically runs at startup, or maybe there is a different solution to this.
Regarding the SSHD, I am not entirely sure about the details behind this, but I appreciate you raising the concern and it is something I will forward
to my superior. At this moment I am looking to be able to create a restoration USB-drive that should be plug-n-play with Clonezilla.
This naming problem is what stands in the way at the moment. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54253
Location: 56N 3W
|
| Posted: Mon Mar 25, 2024 7:26 pm Post subject: |
|
|
acy,
Its possible as Ralphred pointed out but my bash foo is weak.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
acy
n00b
Joined: 25 Mar 2024
Posts: 11
|
| Posted: Mon Mar 25, 2024 8:20 pm Post subject: |
|
|
| Ralphred wrote: | | NeddySeagoon wrote: | Thinking about cloning, if you use sshd, you need to remove the /etc/ssh/ssh_host_* from any and all clones.
Its a very bad thing to clone the ssh identity of a system. |
Some sort of post clone set-up script seems to be the order of the day. The fact you could try to match your udev rule to a hardware ID gives a good "have I been run yet" test, but if it is identical hardware then enp3s0 will be essentially static between machines. I know there are other "run once" solutions but I'm loath to trust them in the case of cloning. |
Is there a way to change the name to net0 without referring to the mac-address? In my case I would have to pill the mac-address, but if I can say:
Change enp3s0 -> net0
Would probably make my life a lot easier, if all the systems will revert to enp3s0, which is something I could test before I do an implementation. But I want to know ahead of time if it is even an option.
Thank you in advance. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21637
|
| Posted: Mon Mar 25, 2024 8:35 pm Post subject: |
|
|
| How many network cards will each system have? This seems like you might be better off disabling the systemd-udevd Predictable Network Interface Names feature and getting the nice simple actually predictable name of eth0 for the first discovered network card of the system. Then instead of hunting down special identifiers and renaming what you find to net0, you just use eth0 and tell systemd-udevd not to rename anything. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54253
Location: 56N 3W
|
| Posted: Mon Mar 25, 2024 8:48 pm Post subject: |
|
|
acy,
To do that, set net.ifnames=0 on the kernel command line.
The first Ethernet interface to be discovered will be eth0.
The "to be discovered" is key. With only one interface its always eth0,
With two or more, the discovery order is not deterministic, so using kernel names it not safe.
That's what naming using MAC address was designed to fix.
That was change naming by PCI bus and slot, so the name did not change if the interface card (and MAC address) were changed due to interface card failure.
If you know that there will be exactly one Ethernet net interface, then net.ifnames=0 is safe.
That's not slot dependent.
enp3s0 is the slot dependent udev renaming of an Ethernet interface.
Use that if the interface at that slot is connected to the outside world.
So far, with just a single interface, it can all just work.
It gets more complex with two or more interfaces in the same system. Then you need to know how the system is connected to the outside world to do the naming correctly
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Ralphred
Guru
Joined: 31 Dec 2013
Posts: 501
|
| Posted: Mon Mar 25, 2024 9:23 pm Post subject: |
|
|
Because of Neddies catch with the ssh identity, the "simple springboard" of a missing unique nic name, and the simplicity of the script itself, I went ahead and wrote it (well the nic bit). | Code: | #!/bin/bash
ifconfig -a| grep -q "^net0: " && exit 0
mac=$(ifconfig -a|awk '/^enp/{printme=1};/^$/{printme=0};printme'|awk '/ether [0-9a-f]*:/{print $2}')
test ${mac} || echo "Error finding mac address" && exit 1
echo "SUBSYSTEM==\"net\", ACTION==\"add\", ATTR{address}==\"${mac}\", NAME=\"net0\"" > /etc/udev/rules.d/99-autogenerated-net0.rules
#if you have a modular kernel you can test (and run) the below to sidestep a reboot
#udevadm control --reload-rules
#rmmod [nic module]
#modprobe [nic module]
## Insert stuff to fix duplicate ssh identities here ##
## Insert yet to be identified post-clone fixes here ##
|
Because I do a lot of custom stuff with openrc's service files, I'd be happy wrapping it in /etc/init.d/post-clone.prep that removes itself from all runlevels as part of it's stop command, but creating a 'firstrun' runlevel if i started trying to fix more than ~3 things just for documenting/debugging ease. |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 2963
Location: Edge of marsh USA
|
| Posted: Tue Mar 26, 2024 3:34 am Post subject: |
|
|
I have the following set in /etc/udev/rules.d, though I don't remember if they are still used they way originally intended. They do no harm if you want to prevent udev automatically renaming your interfaces.
| Code: | cd /etc/udev/rules.d
ln -s /dev/null 80-net-name-slot.rules
ln -s /dev/null 80-net-setup-link.rules |
In /etc/default/grub make the section about renaming network interfaces look like:
| Code: | # Boot with network interface renaming disabled
GRUB_CMDLINE_LINUX="net.ifnames=0" |
That way updating grub.cfg with "grub-mkconfig -o /boot/grub/grub.cfg" net.ifnames=0 will be included in the right line.
As noted above by others, this will normally give you the default kernel named interface, eth0, if you only have one network card.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
acy
n00b
Joined: 25 Mar 2024
Posts: 11
|
| Posted: Tue Mar 26, 2024 10:17 am Post subject: |
|
|
| Hu wrote: | | How many network cards will each system have? This seems like you might be better off disabling the systemd-udevd Predictable Network Interface Names feature and getting the nice simple actually predictable name of eth0 for the first discovered network card of the system. Then instead of hunting down special identifiers and renaming what you find to net0, you just use eth0 and tell systemd-udevd not to rename anything. |
Hu, thank you for your answer.
I can't answer your question as to how many network cards there are in the system in total, as I do not know. What I do know is that there is no budging on the name for this particular subsystem. Your solution would have been great, and maybe it is possible but my current instructions are that it must retain the name net0. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54253
Location: 56N 3W
|
| Posted: Tue Mar 26, 2024 12:41 pm Post subject: |
|
|
acy,
You have insufficient information to provide a robust solution to your problem.
Any of the solutions suggested will work for exactly one network in the system.
They will all be unreliable for two or more interfaces.
Grabbing at straws, with two or more interfaces fitted, ethtool will tell you which interfaces are connected.
If only one is connected, that's probably the one to rename to net0 ... again its not a robust solution.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
acy
n00b
Joined: 25 Mar 2024
Posts: 11
|
| Posted: Tue Mar 26, 2024 1:06 pm Post subject: |
|
|
| NeddySeagoon wrote: | acy,
To do that, set net.ifnames=0 on the kernel command line.
The first Ethernet interface to be discovered will be eth0.
The "to be discovered" is key. With only one interface its always eth0,
With two or more, the discovery order is not deterministic, so using kernel names it not safe.
That's what naming using MAC address was designed to fix.
That was change naming by PCI bus and slot, so the name did not change if the interface card (and MAC address) were changed due to interface card failure.
If you know that there will be exactly one Ethernet net interface, then net.ifnames=0 is safe.
That's not slot dependent.
enp3s0 is the slot dependent udev renaming of an Ethernet interface.
Use that if the interface at that slot is connected to the outside world.
So far, with just a single interface, it can all just work.
It gets more complex with two or more interfaces in the same system. Then you need to know how the system is connected to the outside world to do the naming correctly |
NeddySeagoon,
This is really good information. I am pretty sure I could work something out from knowing this. I just need to understand how Gentoo works more in-depth. You guys have definitely lead me on the right path to put the pieces together. I really apprecaite the effort from your side! Thank you. |
|
| Back to top |
|
|
acy
n00b
Joined: 25 Mar 2024
Posts: 11
|
| Posted: Tue Mar 26, 2024 1:08 pm Post subject: |
|
|
| Ralphred wrote: | Because of Neddies catch with the ssh identity, the "simple springboard" of a missing unique nic name, and the simplicity of the script itself, I went ahead and wrote it (well the nic bit). | Code: | #!/bin/bash
ifconfig -a| grep -q "^net0: " && exit 0
mac=$(ifconfig -a|awk '/^enp/{printme=1};/^$/{printme=0};printme'|awk '/ether [0-9a-f]*:/{print $2}')
test ${mac} || echo "Error finding mac address" && exit 1
echo "SUBSYSTEM==\"net\", ACTION==\"add\", ATTR{address}==\"${mac}\", NAME=\"net0\"" > /etc/udev/rules.d/99-autogenerated-net0.rules
#if you have a modular kernel you can test (and run) the below to sidestep a reboot
#udevadm control --reload-rules
#rmmod [nic module]
#modprobe [nic module]
## Insert stuff to fix duplicate ssh identities here ##
## Insert yet to be identified post-clone fixes here ##
|
Because I do a lot of custom stuff with openrc's service files, I'd be happy wrapping it in /etc/init.d/post-clone.prep that removes itself from all runlevels as part of it's stop command, but creating a 'firstrun' runlevel if i started trying to fix more than ~3 things just for documenting/debugging ease. |
Ralphred,
This is beyond what I expected to see here. This is huge! Big thank you for the bash script, will work on it and see if I can get this sorted into the system. |
|
| Back to top |
|
|
acy
n00b
Joined: 25 Mar 2024
Posts: 11
|
| Posted: Tue Mar 26, 2024 1:10 pm Post subject: |
|
|
| figueroa wrote: | I have the following set in /etc/udev/rules.d, though I don't remember if they are still used they way originally intended. They do no harm if you want to prevent udev automatically renaming your interfaces.
| Code: | cd /etc/udev/rules.d
ln -s /dev/null 80-net-name-slot.rules
ln -s /dev/null 80-net-setup-link.rules |
In /etc/default/grub make the section about renaming network interfaces look like:
| Code: | # Boot with network interface renaming disabled
GRUB_CMDLINE_LINUX="net.ifnames=0" |
That way updating grub.cfg with "grub-mkconfig -o /boot/grub/grub.cfg" net.ifnames=0 will be included in the right line.
As noted above by others, this will normally give you the default kernel named interface, eth0, if you only have one network card. |
figueroa,
This looks like a really good option as well. Now I have plenty to work with, big thank you for supplying me with more information regarding this problem. I will need to discuss with my peers before choosing an implementation, and come back to update if and how things were solved. Thank you! |
|
| Back to top |
|
|
acy
n00b
Joined: 25 Mar 2024
Posts: 11
|
| Posted: Tue Mar 26, 2024 1:12 pm Post subject: |
|
|
| NeddySeagoon wrote: | acy,
You have insufficient information to provide a robust solution to your problem.
Any of the solutions suggested will work for exactly one network in the system.
They will all be unreliable for two or more interfaces.
Grabbing at straws, with two or more interfaces fitted, ethtool will tell you which interfaces are connected.
If only one is connected, that's probably the one to rename to net0 ... again its not a robust solution. |
NeddySeagoon,
For the foreseeable future, this subsystem running Gentoo32 will only have one network interface fitted. Any changes to the hardware will far more likely end in a discontinued product with newer hardware and operating systems. I don't expect this particular system to change at all unless it gets completely discontinued. A solution for one network interface will probably work fine in this case. Thank you! |
|
| Back to top |
|
|
Ralphred
Guru
Joined: 31 Dec 2013
Posts: 501
|
| Posted: Tue Mar 26, 2024 3:46 pm Post subject: |
|
|
| acy wrote: | | For the foreseeable future, this subsystem running Gentoo32 will only have one network interface fitted. |
If this is a "standard system" you are deploying with a built in network interface, you can further target (what should have been) the default nic by using: | Code: | | mac=$(ifconfig -a|awk '/^enp3s0/{printme=1};/^$/{printme=0};printme'|awk '/ether c4:00:ad:/{print $2}') |
Where enp3s0 specifically targets where you/the supplier are putting the card and/or ether c4:00:ad: targets the manufacturer of the card.
But reading this, that manufacturer uses two other "manufacturer mac prefixes", and if it's a discrete nic then it's my belief you are possibly creating more issues for yourself going forward.
Obviously, as figueroa says, allowing network names to default to "ethX" by using net.ifnames=0 is the easiest solution if/when you are in a position to "push back" against the net.net0 naming convention. |
|
| Back to top |
|
|
|
Kernel & Hardware
