-----BEGIN PGP SIGNED MESSAGE-----
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.
Is the latest alpha of the soon to be released version 0.24, and it has kernels
up to 220.127.116.11.
On 17 Feb 2008 at 11:37, Pitt Leidner wrote:
From: Pitt Leidner <pitt.leidner(a)gmx.net>
To: UDPCast <udpcast(a)udpcast.linux.lu>
Date sent: Sun, 17 Feb 2008 11:37:16 +0100
Subject: Re: [Udpcast] Big Problem with cloned MACs
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
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
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,
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
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
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
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
I still full of hope, that the wrong mac is _not_ burnet
the nic :-}
I don't know these NVidia chips well enough
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
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.
Do you think, it is posible to find the reason an a solution?
Udpcast mailing list
Michael D. Setzer II - Computer Science Instructor
Guam Community College Computer Center
Guam - Where America's Day Begins
Number of Seti Units Returned: 19,471
Processing time: 32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)
SETI 4,701,429.396436 | EINSTEIN 1,407,215.657118 | ROSETTA