Hi ML,
happy to found this tool, I've got my first big problem with it.
Using the multicast to clone a HDD to several Clients, the clients take the MAC of the onboard NIC (NVidia nForce). After that, the original MAC is gone and I'm not able to restore this.
This fact has been a little difficult to find. Cause I thought, the MAC ist Part of the NIC, not of the HDD, which has been cloned. So how does it come? And even how can I overcome this?
Any Idea would be appreciated,
TIA
Pitt Leidner wrote:
Hi ML,
happy to found this tool, I've got my first big problem with it.
Using the multicast to clone a HDD to several Clients, the clients take the MAC of the onboard NIC (NVidia nForce). After that, the original MAC is gone and I'm not able to restore this.
This fact has been a little difficult to find. Cause I thought, the MAC ist Part of the NIC, not of the HDD, which has been cloned. So how does it come? And even how can I overcome this?
Any Idea would be appreciated,
TIA
Not sure I understood what you meant here, but...:
Some distributions try to associate a "permanent" card identifier (eth0, eth1, ...) to each ethernet card by remembering its Mac address. This is too avoid that on machines with multiple cards, the naming depends on the module load order, or whatever. Before doing such tying, this used to be a problem: occasionally the card known as eth0 would come up as eth1, and vice versa.
However, the problem with this approach is that now on the clones, the card will be seen as a "new" card, and named eth1, whereas on the original machine it was named eth0.
A workaround for this is to remove the feature, which is not needed on machines which have only one network card anyways.
Usually the feature is managed by udev. There is one file which contains the known associations, and another one which appens associations of newly seen cards. Both must be removed/disabled in order to disable the feature.
In Kubuntu, for instance, card associations are remembered in /etc/udev/rules.d/70-persistent-net.rules
And the script appending new associations is 75-persistent-net-generator.rules .
If you remove these two files on the sender before cloning, the ethernet card on each slave should be named eth0
On other distributions, the principle is similar, although the exact file names may vary.
Regards,
Alain
Hi,
Am Samstag, 16. Februar 2008 schrieb Alain Knaff:
[...]
Not sure I understood what you meant here, but...:
Some distributions try to associate a "permanent" card identifier (eth0, eth1, ...)
This happens only, if any OS has been completely started.
My Problem occurs early at "passing bios", which tries to establish a PXE-boot connection to a DHCP/TFTP/PXE-Bootserver. All cloned clients telling the DHCP-Server that they have the same MAC. SO it cann't be anything in the OS.
[... doesn't match the problem ...]
Cloning by other systems then UDP-Cast didn't produse the Problem.
After Clonig with i.e. "Acronis True Image" or "G4L" without multicast, in openSuse 10.3 it just needed to initialize the eth-x once and the wrong Mac was repaired, in Windows nothing to do, the Mac has been recognized correctly. So it must be an error with UDP-Cast. (It doesn't help to run any other cloning Software fpr repairing after I used udpCast once, cause the original MAC is completly gone).
Pitt Leidner wrote:
Hi,
Am Samstag, 16. Februar 2008 schrieb Alain Knaff:
[...]
Not sure I understood what you meant here, but...:
Some distributions try to associate a "permanent" card identifier (eth0, eth1, ...)
This happens only, if any OS has been completely started.
My Problem occurs early at "passing bios", which tries to establish a PXE-boot connection to a DHCP/TFTP/PXE-Bootserver. All cloned clients telling the DHCP-Server that they have the same MAC. SO it cann't be anything in the OS.
[... doesn't match the problem ...]
Ooops my bad. Couldn't quite figure out your description, so I assumed that you might have run into this common problem... sorry for the confusion.
So, if I understood you right, already at the PXE level, at the very beginning, when the system starts booting, each receiver assumes the sender's MAC address?
This seems rather weird, because at that point in time, it is not yet "decided" which one of the machines will be sender and which one will be receiver...
Or do you mean that they assume some other (common) Mac address?
Or, if this is not what you mean, can you try to enumerate step by step what is needed to reproduce the problem. Is it really as simple as trying to boot the machines via PXE, or did anything happen before?
Most cards allow to update the Mac address in volatile memory, but as soon as you reboot, the real "hardware" Mac address should come back. And it still leaves the question on what changed the Mac address. It is certainly _not_ udpcast.
Some cards may have writable EEPROMs where the Mac address may be permanently updated. I don't know these NVidia chips well enough to know whether yes or no this is possible with them. Again, we need to find out here _which_ application might have updated the Mac address.
Regards,
Alain
Hi,
Am Samstag, 16. Februar 2008 schrieb Alain Knaff:
Pitt Leidner wrote:
[... doesn't match the problem ...]
Ooops my bad. Couldn't quite figure out your description, so I assumed that you might have run into this common problem... sorry for the confusion.
Your'e welcome ;-)
So, if I understood you right, already at the PXE level, at the very beginning, when the system starts booting, each receiver assumes the sender's MAC address?
Somehow, yes, but not this way.
This seems rather weird, because at that point in time, it is not yet "decided" which one of the machines will be sender and which one will be receiver...
Or do you mean that they assume some other (common) Mac address?
No! The Clients will take the Senders Mac, after cloning. I did not get it, if the receivers are running with their own mac...
Or, if this is not what you mean,
I think so. Difficult to descripe and my english is not that good.
can you try to enumerate step by step what is needed to reproduce the problem. Is it really as simple as trying to boot the machines via PXE, or did anything happen before?
Before (or History): I've got several allmost identical PC-Systems (AMD Athlon64-3000, 80 GB HDD, ...). All running with dualboot for w2k and oss 10.1- everything runs well with a protected windows partition (like read only) at this point. But this HDD-Protection becomes to old. It wasn't manageable, cause for any Update, system had to be switched, rebooted, updating, switched an rebooted again on every individual machine. Lizenzes runnig out, and so on ...
At this point I used Norton Ghost, witch couldn't recognize the onboard NICs. So HDD imaging was done one by one HDD :-( not funny, as you can imagin. Then I heard of Acronis, saw it, bought it. Same Problem: No Nic has been recognized. But HDD imaging one by one has been fine at this point.
Actual (The Moment the problem occurs): Then I found about UDPCast (and G4L) giving it a try. I made a Master-PC (setting up everything) and booted UDPCast from CD using it as a server, which has ww:xx:yy:zz:60:0a as its original MAC on its Onboard NIC. This mac is also printed on the motherboard. Cause the Motherboards are from allmost one series, the MAC-Addresses are allmost identical except for the last 4 positions (ww:xx:yy:zz: is equal to all NICs)
Then i booted several PCs from CD setting them up as UDP-Cast-clients. UDPCast runs fine at this point. After _several_ minutes (=hours), the imaging was done. Then I rebootet, trying to finish the Clients to hang them into a M$-Domain and so on. Strange Errors occured then. I couldn't change their names, Ping to the IP did not work properly, ... I saw the mac, and when I looked to the DHCP-Server Logs, it looked strange, all had one and the same MAC, which is the MAC of the UDPCast server!
NOW (how to see this error): I have an DHCP-, TFTP-Server for PXE-Boot. On each Machine is the boot-order 1. PXE-lanboot; 2. HDDrive; 3. CD-Drive. When I boot any of this machines, it trys to concect to the DHCP giving me a Message with its (not the one of the DHCP) own MAC, which is equal to the MAC from this UDPCast-Server. BTW, at this point, there ist no UDPCAST-Server online.
As a quick workaround, I manualy changed the MAC on OS-Level (in Windows: Systemcontroll->Network->Properties->...) to have a running Network but at boot-time the wrong MAC is still displayed. If I reboot any Machine from an original installation-CD like openSUSE (oss) 10.3 this Installation runs with the new wrong MAC Address.
Most cards allow to update the Mac address in volatile memory, but as soon as you reboot, the real "hardware" Mac address should come back.
Yes, this is the only method, to have an working Network. Otherwise, the Users would have done 'something' to me:-(
And it still leaves the question on what changed the Mac address. It is certainly _not_ udpcast.
This is allmost, what I thougt also _until_ the fact, that I can reproduce this error: If I just do a new UDPCast cloning with any "new" PC (that is a PC, wich has its original MAC, identical to the one printed on the NIC) and after cloning that at the next boot time, the cloned PC has the MAC of the UDP-Cast Server. (UDPCAST-Server switched off). Until this point, there was no other software runing on this machine. Just the BIOS and its PXE-Boot feature.
Other settings and environment: I found out, that the UDP-CAST-Server as its own DHCP-Server. So each cloning was done, runnig _two_ DHCP-Servers in the same network. The udp-cast-clients started its service by PXE-Boot, to spare me the disk-jockey and the udp-cast-server has been found easily, so no reason for me, to disable the *big* dhcp-server, which serves for the PXE-Boot.
Some cards may have writable EEPROMs where the Mac address may be permanently updated.
I still full of hope, that the wrong mac is _not_ burnet permanently into the nic :-}
I don't know these NVidia chips well enough to know whether yes or no this is possible with them.
I could live with that, if there would exists a Tool, to change the wrong MAC back to its original value! But nothing found yet...
The other problem is, I usualy have to "wake on LAN" to administer the workstations. And this works only, if the MAC on each NIC ist indivitually.
Again, we need to find out here _which_ application might have updated the Mac address.
That's the point! It is an completely unusual Problem- I've never had something like this in the last 30 Years. Also it wasn't easy to find, cause usually you think in a way that the mac is something static. For me it looks, that only the udpcast imaging hast done this. Cause there was no other application involved.
Regards,
Alain
Do you think, it is posible to find the reason an a solution?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Wondering if it could be a problem with the dhcp requests. If all machines have the same image, the client can request a specific IP address in the request, and the dhcp server can then try to honor it. Since this is all done with broadcast before the get ip addresses, it might be that the broadcast from the dhcp server is being received by all machines. With the info I see that might be possible.
My dhcp server is set to use the Mac address of the machine to assign the IP address, so the machines always get the same IP address. My lab has 98, XP and Fedora, and all get the same IP address based on the MAC. When using the campus dhcp server it would get different IPs with each OS.
I created a little basic program that on the first boot after a reimage, will make changes to the registry based on the MAC of the nic. The Fedora gets the name from the IP address that the dhcpd server gave the machine.
Does the problem happen with the linux.
Also, have you tried ntfsclone on the g4l to backup the ntfs partition. It is generally faster than the image copy with dd, but only backs up the ntfs used data. Depending on the size of the data. At the moment, we are getting hit with the kavo virus, and the norton antivirus doesn't stop infections. I've got a process to remove it, but not prevent from transfering from a flash. I put a 6GB ntfsclone image file on the Linux parttition, and can then reimage the XP in about 10 minutes.
I'm the current maintainer of G4L, and use Udpcast to then transfer the image to all the other machines at one time.
ftp://amd64gcc.dyndns.org/g4l-24alpha6.iso
Is the latest alpha of the soon to be released version 0.24, and it has kernels up to 2.6.24.2.
On 17 Feb 2008 at 11:37, Pitt Leidner wrote:
From: Pitt Leidner pitt.leidner@gmx.net Organization: Freelance To: UDPCast udpcast@udpcast.linux.lu Date sent: Sun, 17 Feb 2008 11:37:16 +0100 Subject: Re: [Udpcast] Big Problem with cloned MACs
Hi,
Am Samstag, 16. Februar 2008 schrieb Alain Knaff:
Pitt Leidner wrote:
[... doesn't match the problem ...]
Ooops my bad. Couldn't quite figure out your description, so I assumed that you might have run into this common problem... sorry for the confusion.
Your'e welcome ;-)
So, if I understood you right, already at the PXE level, at the very beginning, when the system starts booting, each receiver assumes the sender's MAC address?
Somehow, yes, but not this way.
This seems rather weird, because at that point in time, it is not yet "decided" which one of the machines will be sender and which one will be receiver...
Or do you mean that they assume some other (common) Mac address?
No! The Clients will take the Senders Mac, after cloning. I did not get it, if the receivers are running with their own mac...
Or, if this is not what you mean,
I think so. Difficult to descripe and my english is not that good.
can you try to enumerate step by step what is needed to reproduce the problem. Is it really as simple as trying to boot the machines via PXE, or did anything happen before?
Before (or History): I've got several allmost identical PC-Systems (AMD Athlon64-3000, 80 GB HDD, ...). All running with dualboot for w2k and oss 10.1- everything runs well with a protected windows partition (like read only) at this point. But this HDD-Protection becomes to old. It wasn't manageable, cause for any Update, system had to be switched, rebooted, updating, switched an rebooted again on every individual machine. Lizenzes runnig out, and so on ...
At this point I used Norton Ghost, witch couldn't recognize the onboard NICs. So HDD imaging was done one by one HDD :-( not funny, as you can imagin. Then I heard of Acronis, saw it, bought it. Same Problem: No Nic has been recognized. But HDD imaging one by one has been fine at this point.
Actual (The Moment the problem occurs): Then I found about UDPCast (and G4L) giving it a try. I made a Master-PC (setting up everything) and booted UDPCast from CD using it as a server, which has ww:xx:yy:zz:60:0a as its original MAC on its Onboard NIC. This mac is also printed on the motherboard. Cause the Motherboards are from allmost one series, the MAC-Addresses are allmost identical except for the last 4 positions (ww:xx:yy:zz: is equal to all NICs)
Then i booted several PCs from CD setting them up as UDP-Cast-clients. UDPCast runs fine at this point. After _several_ minutes (=hours), the imaging was done. Then I rebootet, trying to finish the Clients to hang them into a M$-Domain and so on. Strange Errors occured then. I couldn't change their names, Ping to the IP did not work properly, ... I saw the mac, and when I looked to the DHCP-Server Logs, it looked strange, all had one and the same MAC, which is the MAC of the UDPCast server!
NOW (how to see this error): I have an DHCP-, TFTP-Server for PXE-Boot. On each Machine is the boot-order 1. PXE-lanboot; 2. HDDrive; 3. CD-Drive. When I boot any of this machines, it trys to concect to the DHCP giving me a Message with its (not the one of the DHCP) own MAC, which is equal to the MAC from this UDPCast-Server. BTW, at this point, there ist no UDPCAST-Server online.
As a quick workaround, I manualy changed the MAC on OS-Level (in Windows: Systemcontroll->Network->Properties->...) to have a running Network but at boot-time the wrong MAC is still displayed. If I reboot any Machine from an original installation-CD like openSUSE (oss) 10.3 this Installation runs with the new wrong MAC Address.
Most cards allow to update the Mac address in volatile memory, but as soon as you reboot, the real "hardware" Mac address should come back.
Yes, this is the only method, to have an working Network. Otherwise, the Users would have done 'something' to me:-(
And it still leaves the question on what changed the Mac address. It is certainly _not_ udpcast.
This is allmost, what I thougt also _until_ the fact, that I can reproduce this error: If I just do a new UDPCast cloning with any "new" PC (that is a PC, wich has its original MAC, identical to the one printed on the NIC) and after cloning that at the next boot time, the cloned PC has the MAC of the UDP-Cast Server. (UDPCAST-Server switched off). Until this point, there was no other software runing on this machine. Just the BIOS and its PXE-Boot feature.
Other settings and environment: I found out, that the UDP-CAST-Server as its own DHCP-Server. So each cloning was done, runnig _two_ DHCP-Servers in the same network. The udp-cast-clients started its service by PXE-Boot, to spare me the disk-jockey and the udp-cast-server has been found easily, so no reason for me, to disable the *big* dhcp-server, which serves for the PXE-Boot.
Some cards may have writable EEPROMs where the Mac address may be permanently updated.
I still full of hope, that the wrong mac is _not_ burnet permanently into the nic :-}
I don't know these NVidia chips well enough to know whether yes or no this is possible with them.
I could live with that, if there would exists a Tool, to change the wrong MAC back to its original value! But nothing found yet...
The other problem is, I usualy have to "wake on LAN" to administer the workstations. And this works only, if the MAC on each NIC ist indivitually.
Again, we need to find out here _which_ application might have updated the Mac address.
That's the point! It is an completely unusual Problem- I've never had something like this in the last 30 Years. Also it wasn't easy to find, cause usually you think in a way that the mac is something static. For me it looks, that only the udpcast imaging hast done this. Cause there was no other application involved.
Regards,
Alain
Do you think, it is posible to find the reason an a solution?
-- yours sincerely
Pitt _______________________________________________ Udpcast mailing list Udpcast@udpcast.linux.lu https://lll.lgl.lu/mailman/listinfo/udpcast
+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@kuentos.guam.net mailto:msetzerii@gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins +----------------------------------------------------------+
http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489)
BOINC@HOME CREDITS SETI 4,701,429.396436 | EINSTEIN 1,407,215.657118 | ROSETTA 393,311.538748
Hi ML
Am Sonntag, 17. Februar 2008 schrieb Michael D. Setzer II:
Wondering if it could be a problem with the dhcp requests. If all machines have the same image, the client can request a specific IP address in the request, and the dhcp server can then try to honor it. Since this is all done with broadcast before the get ip addresses, it might be that the broadcast from the dhcp server is being received by all machines. With the info I see that might be possible.
My dhcp server is set to use the Mac address of the machine to assign the IP address, so the machines always get the same IP address.
That's the same way I'm usually doing it.
My lab has 98, XP and Fedora, and all get the same IP address based on the MAC.
I'm using w2k, WxpPro and oss10.3-clients. The Domain Controller is a Windows 2003 (SP2) Server running AD, DNS, WINS, DHCP (only at the moment) and a FTP-Server. An Opensuse 10.3 runs to be used as an Apache2 and TFTP-Server (served by the W2K3 DHCP).
When using the campus dhcp server it would get different IPs with each OS.
This isn't needed for our LAN.
I created a little basic program that on the first boot after a reimage, will make changes to the registry based on the MAC of the nic. The Fedora gets the name from the IP address that the dhcpd server gave the machine.
Does the problem happen with the linux.
yes, This was my first Intention too,
Also, have you tried ntfsclone on the g4l to backup the ntfs partition.
If I'm using g4L, to create an Image on a LAN-Drive, this runs fine, without any Problems - I didn't find out, how to run g4l using mulitcast with that LAN-Drive Image. So I didn't follow this way until today.
It is generally faster than the image copy with dd, but only backs up the ntfs used data.
This isn't a posibility to me, cause we need read only Windows-Partitions, which are done by a tool called HDD-Sheriff. This tool installs an own Bootmanager in to the MBR. So I have to use HDD-Imaging instead of Partition-Imaging.
Depending on the size of the data. At the moment, we are getting hit with the kavo virus, and the norton antivirus doesn't stop infections. I've got a process to remove it, but not prevent from transfering from a flash. I put a 6GB ntfsclone image file on the Linux parttition, and can then reimage the XP in about 10 minutes.
I'm the current maintainer of G4L, and use Udpcast to then transfer the image to all the other machines at one time.
will this be part of G4L?
ftp://amd64gcc.dyndns.org/g4l-24alpha6.iso
Is the latest alpha of the soon to be released version 0.24, and it has kernels up to 2.6.24.2.
fine!
On 17 Feb 2008 at 11:37, Pitt Leidner wrote:
From: Pitt Leidner pitt.leidner@gmx.net Organization: Freelance To: UDPCast udpcast@udpcast.linux.lu Date sent: Sun, 17 Feb 2008 11:37:16 +0100 Subject: Re: [Udpcast] Big Problem with cloned MACs
Hi,
Am Samstag, 16. Februar 2008 schrieb Alain Knaff:
Pitt Leidner wrote:
[... doesn't match the problem ...]
Ooops my bad. Couldn't quite figure out your description, so I assumed that you might have run into this common problem... sorry for the confusion.
Your'e welcome ;-)
So, if I understood you right, already at the PXE level, at the very beginning, when the system starts booting, each receiver assumes the sender's MAC address?
Somehow, yes, but not this way.
This seems rather weird, because at that point in time, it is not yet "decided" which one of the machines will be sender and which one will be receiver...
Or do you mean that they assume some other (common) Mac address?
No! The Clients will take the Senders Mac, after cloning. I did not get it, if the receivers are running with their own mac...
Or, if this is not what you mean,
I think so. Difficult to descripe and my english is not that good.
can you try to enumerate step by step what is needed to reproduce the problem. Is it really as simple as trying to boot the machines via PXE, or did anything happen before?
Before (or History): I've got several allmost identical PC-Systems (AMD Athlon64-3000, 80 GB HDD, ...). All running with dualboot for w2k and oss 10.1- everything runs well with a protected windows partition (like read only) at this point. But this HDD-Protection becomes to old. It wasn't manageable, cause for any Update, system had to be switched, rebooted, updating, switched an rebooted again on every individual machine. Lizenzes runnig out, and so on ...
At this point I used Norton Ghost, witch couldn't recognize the onboard NICs. So HDD imaging was done one by one HDD :-( not funny, as you can imagin. Then I heard of Acronis, saw it, bought it. Same Problem: No Nic has been recognized. But HDD imaging one by one has been fine at this point.
Actual (The Moment the problem occurs): Then I found about UDPCast (and G4L) giving it a try. I made a Master-PC (setting up everything) and booted UDPCast from CD using it as a server, which has ww:xx:yy:zz:60:0a as its original MAC on its Onboard NIC. This mac is also printed on the motherboard. Cause the Motherboards are from allmost one series, the MAC-Addresses are allmost identical except for the last 4 positions (ww:xx:yy:zz: is equal to all NICs)
Then i booted several PCs from CD setting them up as UDP-Cast-clients. UDPCast runs fine at this point. After _several_ minutes (=hours), the imaging was done. Then I rebootet, trying to finish the Clients to hang them into a M$-Domain and so on. Strange Errors occured then. I couldn't change their names, Ping to the IP did not work properly, ... I saw the mac, and when I looked to the DHCP-Server Logs, it looked strange, all had one and the same MAC, which is the MAC of the UDPCast server!
NOW (how to see this error): I have an DHCP-, TFTP-Server for PXE-Boot. On each Machine is the boot-order 1. PXE-lanboot; 2. HDDrive; 3. CD-Drive. When I boot any of this machines, it trys to concect to the DHCP giving me a Message with its (not the one of the DHCP) own MAC, which is equal to the MAC from this UDPCast-Server. BTW, at this point, there ist no UDPCAST-Server online.
As a quick workaround, I manualy changed the MAC on OS-Level (in Windows: Systemcontroll->Network->Properties->...) to have a running Network but at boot-time the wrong MAC is still displayed. If I reboot any Machine from an original installation-CD like openSUSE (oss) 10.3 this Installation runs with the new wrong MAC Address.
Most cards allow to update the Mac address in volatile memory, but as soon as you reboot, the real "hardware" Mac address should come back.
Yes, this is the only method, to have an working Network. Otherwise, the Users would have done 'something' to me:-(
And it still leaves the question on what changed the Mac address. It is certainly _not_ udpcast.
This is allmost, what I thougt also _until_ the fact, that I can reproduce this error: If I just do a new UDPCast cloning with any "new" PC (that is a PC, wich has its original MAC, identical to the one printed on the NIC) and after cloning that at the next boot time, the cloned PC has the MAC of the UDP-Cast Server. (UDPCAST-Server switched off). Until this point, there was no other software runing on this machine. Just the BIOS and its PXE-Boot feature.
Other settings and environment: I found out, that the UDP-CAST-Server as its own DHCP-Server. So each cloning was done, runnig _two_ DHCP-Servers in the same network. The udp-cast-clients started its service by PXE-Boot, to spare me the disk-jockey and the udp-cast-server has been found easily, so no reason for me, to disable the *big* dhcp-server, which serves for the PXE-Boot.
Some cards may have writable EEPROMs where the Mac address may be permanently updated.
I still full of hope, that the wrong mac is _not_ burnet permanently into the nic :-}
I don't know these NVidia chips well enough to know whether yes or no this is possible with them.
I could live with that, if there would exists a Tool, to change the wrong MAC back to its original value! But nothing found yet...
The other problem is, I usualy have to "wake on LAN" to administer the workstations. And this works only, if the MAC on each NIC ist indivitually.
Again, we need to find out here _which_ application might have updated the Mac address.
That's the point! It is an completely unusual Problem- I've never had something like this in the last 30 Years. Also it wasn't easy to find, cause usually you think in a way that the mac is something static. For me it looks, that only the udpcast imaging hast done this. Cause there was no other application involved.
Regards,
Alain
Do you think, it is posible to find the reason an a solution?
-- yours sincerely
Pitt _______________________________________________ Udpcast mailing list Udpcast@udpcast.linux.lu https://lll.lgl.lu/mailman/listinfo/udpcast
+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@kuentos.guam.net mailto:msetzerii@gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins +----------------------------------------------------------+
http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489)
BOINC@HOME CREDITS SETI 4,701,429.396436 | EINSTEIN 1,407,215.657118 | ROSETTA 393,311.538748
Udpcast mailing list Udpcast@udpcast.linux.lu https://lll.lgl.lu/mailman/listinfo/udpcast
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 17 Feb 2008 at 14:46, Pitt Leidner wrote:
Cut ====
I'm the current maintainer of G4L, and use Udpcast to then transfer the image to all the other machines at one time.
will this be part of G4L?
The images that are created by g4l are compatible with udpcast. If you have an image saved on a server with compression, you can then use udp-sender to send the compressed file. The g4l CD has and option to receive udp-cast files.
ftp://amd64gcc.dyndns.org/g4l-24alpha6.iso
Is the latest alpha of the soon to be released version 0.24, and it has kernels up to 2.6.24.2.
fine!
Cut =====
+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@kuentos.guam.net mailto:msetzerii@gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins +----------------------------------------------------------+
http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489)
BOINC@HOME CREDITS SETI 4,736,900.884797 | EINSTEIN 1,412,908.299132 | ROSETTA 394,320.092198
Am Montag, 18. Februar 2008 schrieb Michael D. Setzer II:
On 17 Feb 2008 at 14:46, Pitt Leidner wrote:
Cut ====
I'm the current maintainer of G4L, and use Udpcast to then transfer the image to all the other machines at one time.
will this be part of G4L?
The images that are created by g4l are compatible with udpcast. If you have an image saved on a server with compression, you can then use udp-sender to send the compressed file. The g4l CD has and option to receive udp-cast files.
But still, it is not posible to use G4L with multicast by its own? (Just as a receiver of udp-sender, as you descriped)
ftp://amd64gcc.dyndns.org/g4l-24alpha6.iso
Is the latest alpha of the soon to be released version 0.24, and it has kernels up to 2.6.24.2.
fine!
Cut =====
+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@kuentos.guam.net mailto:msetzerii@gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins +----------------------------------------------------------+
http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489)
BOINC@HOME CREDITS SETI 4,736,900.884797 | EINSTEIN 1,412,908.299132 | ROSETTA 394,320.092198
Udpcast mailing list Udpcast@udpcast.linux.lu https://lll.lgl.lu/mailman/listinfo/udpcast
[...]
Actual (The Moment the problem occurs): Then I found about UDPCast (and G4L) giving it a try. I made a Master-PC (setting up everything) and booted UDPCast from CD using it as a server, which has ww:xx:yy:zz:60:0a as its original MAC on its Onboard NIC. This mac is also printed on the motherboard. Cause the Motherboards are from allmost one series, the MAC-Addresses are allmost identical except for the last 4 positions (ww:xx:yy:zz: is equal to all NICs)
Then i booted several PCs from CD setting them up as UDP-Cast-clients. UDPCast runs fine at this point. After _several_ minutes (=hours), the imaging was done. Then I rebootet, trying to finish the Clients to hang them into a M$-Domain and so on. Strange Errors occured then. I couldn't
So, I suppose you booted into windows at that point....
change their names, Ping to the IP did not work properly, ... I saw the mac, and when I looked to the DHCP-Server Logs, it looked strange, all had one and the same MAC, which is the MAC of the UDPCast server!
I suppose what happened here is some Windows bogosity, or rather some Nvidia-driver-on-windows bogosity:
- Probably, for some weird reason, the Nvidia driver (or one autostart program associated with the Nvidia driver?) changes the value of the Mac address in the Eprom towards an address stored somewhere in the registry (or somewhere else).
What to do: 1. Try talking to Nvidia tech support about it 2. Try searching the registry for the "bad" Mac address, and replace each occurrence with the "correct" address. ... or, if you want to trace the error, replace each occurrence with a different address, and then check later which one of these "sticks"...
[...]
of the UDP-Cast Server. (UDPCAST-Server switched off). Until this point, there was no other software runing on this machine.
Sorry, you did mention Windows. This *is* other software, which might very well do strange things to the Nic. If not Windows itself, then at least Nvidia's drivers or associated software might do it...
Try once doing an Udpcast, and *immediately* boot into Knoppix after that, and check the Mac address. I'm pretty sure that the Mac address stays the same until Windows is booted once.
[...]
I could live with that, if there would exists a Tool, to change the wrong MAC back to its original value! But nothing found yet...
Probably the same tool that changed it to wrong in the first place. Try having a closer look at the Nvidia drivers, and at the registry...
Regards,
Alain
Am Sonntag, 17. Februar 2008 schrieb Alain Knaff:
[...]
Actual (The Moment the problem occurs): Then I found about UDPCast (and G4L) giving it a try. I made a Master-PC (setting up everything) and booted UDPCast from CD using it as a server, which has ww:xx:yy:zz:60:0a as its original MAC on its Onboard NIC. This mac is also printed on the motherboard. Cause the Motherboards are from allmost one series, the MAC-Addresses are allmost identical except for the last 4 positions (ww:xx:yy:zz: is equal to all NICs)
Then i booted several PCs from CD setting them up as UDP-Cast-clients. UDPCast runs fine at this point. After _several_ minutes (=hours), the imaging was done. Then I rebootet, trying to finish the Clients to hang them into a M$-Domain and so on. Strange Errors occured then. I couldn't
So, I suppose you booted into windows at that point....
change their names, Ping to the IP did not work properly, ... I saw the mac, and when I looked to the DHCP-Server Logs, it looked strange, all had one and the same MAC, which is the MAC of the UDPCast server!
I suppose what happened here is some Windows bogosity, or rather some Nvidia-driver-on-windows bogosity:
- Probably, for some weird reason, the Nvidia driver (or one autostart
program associated with the Nvidia driver?) changes the value of the Mac address in the Eprom towards an address stored somewhere in the registry (or somewhere else).
No. I use the same PCs (same Hardware, same Software) without any Problems (Here Clonig has been done by other software: Acronis, G4L, ...). Just as i descriped before: The Error (wich is the (wrong) MAC of the UDPCAST-Server) occurs at boottime right after a UDPCastCloning. This Error is reproduced.
What to do:
- Try talking to Nvidia tech support about it
- Try searching the registry for the "bad" Mac address, and replace
each occurrence with the "correct" address. ... or, if you want to trace the error, replace each occurrence with a different address, and then check later which one of these "sticks"...
[...]
of the UDP-Cast Server. (UDPCAST-Server switched off). Until this point, there was no other software runing on this machine.
Sorry, you did mention Windows. This *is* other software, which might very well do strange things to the Nic. If not Windows itself, then at least Nvidia's drivers or associated software might do it...
Try once doing an Udpcast, and *immediately* boot into Knoppix after that, and check the Mac address.
Yes, this has been done (as I wrote in this thread before). The Fact, that i found this error first was from within windows, yes. But then I did the same Procedures on different PCs. Here the error occured directly after rebooting from the UDPcast.
This could be funny, allways to search for the responsibility somewhere else. In the end I have to belive, there can not be an error at all, cause the MAC is uniqe worldwide. It is imposible and so on. :-(
I'm pretty sure that the Mac address stays the same until Windows is booted once.
Belive it or not. This (an I'm not a big frient of proprietary solutions) is not a problem within Windows.
[...]
I could live with that, if there would exists a Tool, to change the wrong MAC back to its original value! But nothing found yet...
Probably the same tool that changed it to wrong in the first place. Try having a closer look at the Nvidia drivers, and at the registry...
Sorry, but this doesn't solve it.
Regards,
Alain
Pitt Leidner wrote:
Hi,
Am Samstag, 16. Februar 2008 schrieb Alain Knaff:
Pitt Leidner wrote:
[... doesn't match the problem ...]
[ cut ]
Other settings and environment: I found out, that the UDP-CAST-Server as its own DHCP-Server. So each cloning was done, runnig _two_ DHCP-Servers in the same network. The udp-cast-clients started its service by PXE-Boot, to spare me the disk-jockey and the udp-cast-server has been found easily, so no reason for me, to disable the *big* dhcp-server, which serves for the PXE-Boot.
A few questions:
1. is there some way you're blocking the updcast receivers from seeing the *big* dhcp-server, i.e. is the dhcp server running on the udpcast sender guaranteed to be authoritative for the udpcast receivers
2. how does your udpcast sender get its ip address, from the *big* dhcp- server or do you set it manually; do you provide an ethernet-to-ip mapping file for the dhcp server running on your udpcast sender
3. when the systems you are going to clone are booted as udpcast receivers, is the ethernet address displayed by running ifconfig on the udpcast receivers the ethernet address of the onboard adapter or is it the ethernet address of the udpcast sender
Some cards may have writable EEPROMs where the Mac address may be permanently updated.
I still full of hope, that the wrong mac is _not_ burnet permanently into the nic :-}
I don't know these NVidia chips well enough to know whether yes or no this is possible with them.
I could live with that, if there would exists a Tool, to change the wrong MAC back to its original value! But nothing found yet...
The other problem is, I usualy have to "wake on LAN" to administer the workstations. And this works only, if the MAC on each NIC ist indivitually.
Again, we need to find out here _which_ application might have updated the Mac address.
That's the point! It is an completely unusual Problem- I've never had something like this in the last 30 Years. Also it wasn't easy to find, cause usually you think in a way that the mac is something static. For me it looks, that only the udpcast imaging hast done this. Cause there was no other application involved.
I read through all the messages in this thread but I don't recall if you mentioned which specific NVidia chipset is used on the systems you're cloning. I've been using udpcast to manage a computer lab, the motherboards used are Asus A8N-E which use NVidia's nForce 4 Ultra chipset.
The NVidia drivers for Windows, as provided by Asus, for this chipset include NVidia's ForceWare which allows one to manipulate a number of settings for the onboard ethernet adapter, including the ethernet address. I haven't tried using this to know if setting the ethernet address with this utility makes a change in firmware/BIOS. This is a link to the manual (PDF) for ForceWare for the 6.86 version of the nForce 4 Ultra drivers
http://www.nvidia.com/object/LO_28249.html
Take a look at "Current Ethernet Address" on page 123.
On a somewhat related note, I used the ForceWare utility in Windows to configure the system for wake-on-lan. WOL works if I shutdown from Windows. If I boot the system from a Linux-based live cd (INSERT rescue CD for example) and just shut down, WOL doesn't work. If I do the following to shutdown, WOL works
ethtool -s eth0 wol g echo s > /proc/acpi/sleep
I put that together from these links
http://www.beowulf.org/archive/2006-May/015558.html
http://www.beowulf.org/archive/2001-September/004782.html
http://ftp.pld-linux.org/people/siefca/patches/nvidia/README.en.txt
Regards,
Alain
Do you think, it is posible to find the reason an a solution?
Hi,
I'll going for some tests in a few couple of days, cause ASRock gave me a MAC-tool to change the mac to its original values. But for now, I've to do a few impotant other things ...
Am Mittwoch, 27. Februar 2008 schrieb Tom Carpenter:
Pitt Leidner wrote:
Hi,
Am Samstag, 16. Februar 2008 schrieb Alain Knaff:
Pitt Leidner wrote:
[... doesn't match the problem ...]
[ cut ]
Other settings and environment: I found out, that the UDP-CAST-Server as its own DHCP-Server. So each cloning was done, runnig _two_ DHCP-Servers in the same network. The udp-cast-clients started its service by PXE-Boot, to spare me the disk-jockey and the udp-cast-server has been found easily, so no reason for me, to disable the *big* dhcp-server, which serves for the PXE-Boot.
A few questions:
- is there some way you're blocking the updcast receivers from seeing the *big* dhcp-server, i.e. is the dhcp server running on the
udpcast sender guaranteed to be authoritative for the udpcast receivers
It looks like this, yes and no, there is nothing blocked (maybee without my knowledge) - all I can see, sender and receiver looking normal to me ...
- how does your udpcast sender get its ip address, from the *big*
dhcp- server
Yes
or do you set it manually;
No
do you provide an ethernet-to-ip mapping file for the dhcp server running on your udpcast sender
No, not on the sender - The ethernet-to-ip mapping is usually done on the *big* dhcp server.
- when the systems you are going to clone are booted as udpcast
receivers, is the ethernet address displayed by running ifconfig on the udpcast receivers the ethernet address of the onboard adapter or is it the ethernet address of the udpcast sender
I didn't get in to a commandline_state. The sender and the receivers starting allmost automatically until a state with a few questions.
Some cards may have writable EEPROMs where the Mac address may be permanently updated.
I still full of hope, that the wrong mac is _not_ burnet permanently into the nic :-}
I don't know these NVidia chips well enough to know whether yes or no this is possible with them.
I could live with that, if there would exists a Tool, to change the wrong MAC back to its original value! But nothing found yet...
The other problem is, I usualy have to "wake on LAN" to administer the workstations. And this works only, if the MAC on each NIC ist indivitually.
Again, we need to find out here _which_ application might have updated the Mac address.
That's the point! It is an completely unusual Problem- I've never had something like this in the last 30 Years. Also it wasn't easy to find, cause usually you think in a way that the mac is something static. For me it looks, that only the udpcast imaging hast done this. Cause there was no other application involved.
I read through all the messages in this thread but I don't recall if you mentioned which specific NVidia chipset is used on the systems you're cloning. I've been using udpcast to manage a computer lab, the motherboards used are Asus A8N-E which use NVidia's nForce 4 Ultra chipset.
The Chipset is called: NVIDIA nForce 410 MCP
The mb can be found here: http://www.asrock.com/mb/overview.asp?Model=939NF4G-SATA2
The NVidia drivers for Windows, as provided by Asus, for this chipset include NVidia's ForceWare which allows one to manipulate a number of settings for the onboard ethernet adapter, including the ethernet address. I haven't tried using this to know if setting the ethernet address with this utility makes a change in firmware/BIOS. This is a link to the manual (PDF) for ForceWare for the 6.86 version of the nForce 4 Ultra drivers
I had no tools like this, bu now I've got a tool to rewrite the mac to its original value
http://www.nvidia.com/object/LO_28249.html
Take a look at "Current Ethernet Address" on page 123.
On a somewhat related note, I used the ForceWare utility in Windows to configure the system for wake-on-lan. WOL works if I shutdown from Windows. If I boot the system from a Linux-based live cd (INSERT rescue CD for example) and just shut down, WOL doesn't work. If I do the following to shutdown, WOL works
ethtool -s eth0 wol g echo s > /proc/acpi/sleep
I put that together from these links
http://www.beowulf.org/archive/2006-May/015558.html
http://www.beowulf.org/archive/2001-September/004782.html
http://ftp.pld-linux.org/people/siefca/patches/nvidia/README.en.txt
Tom, thanks for your reply. I've to do some other important (familiary) things first, then I'll reset the macs to its original values, so the LAN can work stable - after that I'll sure do some tests regarding this problem to see which step does the changing.
As I tested on monday, resetting the mac is done quickly - so it is still comfortable to use udpcast, even if I loose the mac ;-)
This story is so strange that I think we need to take a look at whether it might be a false positive.
Why do you say the MAC addresses are the same? What actual commands or steps did you take which revealed the MAC addresses? Is it ifconfig, arp, looking at DHCP logs, etc? Whenever I see something which meets my disbelief I seek confirmation from another angle, in case the first tool is lying (picking up something from a file rather than live).
--Donald
Pitt Leidner wrote:
Hi ML,
happy to found this tool, I've got my first big problem with it.
Using the multicast to clone a HDD to several Clients, the clients take the MAC of the onboard NIC (NVidia nForce). After that, the original MAC is gone and I'm not able to restore this.
This fact has been a little difficult to find. Cause I thought, the MAC ist Part of the NIC, not of the HDD, which has been cloned. So how does it come? And even how can I overcome this?
Any Idea would be appreciated,
TIA
Hi,
Am Sonntag, 17. Februar 2008 schrieb D G Teed:
This story is so strange
yes ;-) and BTW, thanks for your guidance
that I think we need to take a look at whether it might be a false positive.
Why do you say the MAC addresses are the same?
First: Cause something looked so strange, I looked at the DHCP-Server (OpenSuse 10.3, running DHCP, TFTP, Apache2) to see at the log-files created by this DHCP Server. Usually, I give IPs depending on the MAC.
Second: Windows told it, using the "ipconfig -all" command. Same then with knoppix (ifconfig).
Last and this is now my only reference to it, cause if checked that so often: The PXE-Boot of the BIOS tells it at boottime during the first screen, after PXE-Boot is up and before the PXE-Boot-menu comes up.
What actual commands or steps did you take which revealed the MAC addresses?
Is it ifconfig,
Yes, using any life CD like systools, knoppix, ...
arp,
didn't ry this one.
looking at DHCP logs,
Yes, this was my first sight to get an Idea, what was so strange (really, I never thought to have Problems with a MAC)
etc?
I'm ready to use any additionally tool...
Whenever I see something which meets my disbelief I seek confirmation from another angle, in case the first tool is lying (picking up something from a file rather than live).
Good way! This is what I allmost going to try. But now, my different angles are gone :-( So any input is welcome!
--Donald
Pitt Leidner wrote:
Hi ML,
happy to found this tool, I've got my first big problem with it.
Using the multicast to clone a HDD to several Clients, the clients take the MAC of the onboard NIC (NVidia nForce). After that, the original MAC is gone and I'm not able to restore this.
This fact has been a little difficult to find. Cause I thought, the MAC ist Part of the NIC, not of the HDD, which has been cloned. So how does it come? And even how can I overcome this?
Any Idea would be appreciated,
TIA
Hi,
Am Mittwoch, 13. Februar 2008 schrieb Pitt Leidner:
Using the multicast to clone a HDD to several Clients, the clients take the MAC of the onboard NIC (NVidia nForce). After that, the original MAC is gone and I'm not able to restore this.
This fact has been a little difficult to find. Cause I thought, the MAC ist Part of the NIC, not of the HDD, which has been cloned. So how does it come?
The answer in short: UDP-Cast wasn't resonsible for that!
It has been an behavior of the the harddiskprotection "HDD Sheriff" witch protects the bios also. So a cloned target system will have a cloned Bios.Backup of the source also. This rewrites then the "changed" mac of the nic of the target after rebooting.
I've received an MAC-writing tool from the Nic-producer- with that the strange error could be located quickly.
I'm sorry for that. But still thankfull, becaus of your guidance, which gave me some ideas to the problem... ;-)
-
Alain Knaff -
D G Teed -
Michael D. Setzer II -
Pitt Leidner -
Tom Carpenter