The option of ipappend 1 in the default file and retransmission
of HELLOs in udp-sender (--rexmit-hello-interval) has been
valuable to getting udpcast working with the Dell notebooks
we have with Broadcom 5700 series ethernet.
Today, with a slightly newer broadcom chipset appearing in
the most recent shipment, we noticed that udp-receiver was
intermittantly not showing the "hit any button to start transfer"
message. With some trial and error I found that if I
watched the tail of /var/log/message on the receiver (server)
and waited for the messages on TX and RX flow control to
complete before running udp-receiver, it would always initiate
a good connection. If I had started the udp-receiver
prior to the TX/RX flow control appearing in the message log
(in which case there was no "hit any key" message),
I could ^C the receiver, run it again and it would signify
the ready state with 100% success.
In conclusion, we have a workaround of starting udp-receiver
after a few seconds past the client PXE machine booting and
showing the udp-sender status ready (but not yet "hit any key...").
Another solution would be if udp-receiver also supported
--rexmit-hello-interval. It isn't a flaw in the udpcast system
but a kludge for a network device that is proving itself to be
sluggish in initialization in general.
--Donald Teed
At first I was, but when I couldn't get the multicast senders to wait
for the clients I tried manually running udp-sender and receiver.
This to take flamethrower out of the equation and to pinpoint what was
causing it.
However, I already found the bug, and made a patch for it this morning.
The problem is the time struct udp-sender uses to store the time at
which the first receiver connects is never initialized to 0, while a if
statement later on assumes that the value is 0 if no receiver has
connected yet.
This causes the udp-sender doesn't know the time of the first connected
client and that it doesn't wait
The fix is initializing the variable correctly and setting it to 0.
I have attached a diff patch which corrects it, it works great now :)
Regards,
Ramon.
> -----Original Message-----
> From: Brian Elliott Finley [mailto:finley@mcs.anl.gov]
> Sent: donderdag 27 mei 2004 17:46
> To: Ramon Bastiaans
> Cc: udpcast(a)udpcast.linux.lu
> Subject: Re: [Udpcast] udp-sender does not wait at all?
>
> Are you using flamethrower to do this?
>
>
> Thus spake Ramon Bastiaans (bastiaans(a)sara.nl):
> >Hi,
> >
> >I have been working on getting multicast systemimager image
broadcasts
> >to work, but I am having a hard time.
> >
> >Is it just me (am I doing something wrong?) or does udp-sender
> >completely ignore the wait and client parameters?
> >
> >Udp-sender doesn't wait at all for a minimum number of clients, after
> >the first connection, it immediately starts the multicast to the
first
> >client.
> >
> >On the server:
> >
> ># udp-sender --pipe 'tar -B -S -cpf - -C
/home/test/sara/ramon/testdir .
> >' --portbase 12345 --min-clients 20 --max-wait 1800 --min-wait 600
--fec
> >8x8/128 --interface eth0 --max-bitrate 20M --full-duplex
--nopointopoint
> >--nokbd
> >stripes=8 redund=8 stripesize=128
> >Udp-sender 2004-02-22
> >Using mcast address 234.168.44.1
> >Compressed UDP sender for (stdin) at 10.168.44.1 on eth0
> >Broadcasting control to 10.168.44.255
> >New connection from 10.168.44.5 (#0) 00000019
> >Starting transfer: 00000019
> >bytes= 11 929 600 re-xmits=000000 ( 0.0%) slice=1024 73 709 551
> >615 - 0
> >Transfer complete.
> >Disconnecting #0 (10.168.44.5)
> >
> >On the client:
> >
> ># udp-receiver --interface eth0 --portbase 12345 --nokbd --nosync
--file
> >./bla.tar
> >Udp-receiver 2004-02-22
> >UDP receiver for ./bla.tar at 10.168.44.5 on eth0
> >received message, cap=00000019
> >Connected as #0 to 10.168.44.1
> >Listening to multicast on 234.168.44.1
> >bytes= 11 929 600 ( 15.91 Mbps) 11 929 600
> >Transfer complete.
> >ramon@u5:~/1.udptest$
> >
> >
> >Now there is no timestamps, but the udp-sender starts the multicast
in
> >about 2 seconds after the connect from the client. But the sender
does
> >not have 20 clients connected, and it didn't wait 10 minutes at all
(I
> >kind of overdid the values here, but with lower values it doesn't
work
> >either).
> >
> >Am I missing something?
> >
> >Kind regards,
> >
> >Ramon Bastiaans.
> >
> >_______________________________________________
> >Udpcast mailing list
> >Udpcast(a)udpcast.linux.lu
> >http://udpcast.linux.lu/mailman/listinfo/udpcast
> >
>
> --
> ------------------------------------------------------
> Brian Elliott Finley Argonne, MCS Division
> Mobile: 630.631.6621 Office: 630.252.4742
> gpg --keyserver wwwkeys.pgp.net --recv-keys 10F8EE52
> ------------------------------------------------------
Hi,
I have been working on getting multicast systemimager image broadcasts
to work, but I am having a hard time.
Is it just me (am I doing something wrong?) or does udp-sender
completely ignore the wait and client parameters?
Udp-sender doesn't wait at all for a minimum number of clients, after
the first connection, it immediately starts the multicast to the first
client.
On the server:
# udp-sender --pipe 'tar -B -S -cpf - -C /home/test/sara/ramon/testdir .
' --portbase 12345 --min-clients 20 --max-wait 1800 --min-wait 600 --fec
8x8/128 --interface eth0 --max-bitrate 20M --full-duplex --nopointopoint
--nokbd
stripes=8 redund=8 stripesize=128
Udp-sender 2004-02-22
Using mcast address 234.168.44.1
Compressed UDP sender for (stdin) at 10.168.44.1 on eth0
Broadcasting control to 10.168.44.255
New connection from 10.168.44.5 (#0) 00000019
Starting transfer: 00000019
bytes= 11 929 600 re-xmits=000000 ( 0.0%) slice=1024 73 709 551
615 - 0
Transfer complete.
Disconnecting #0 (10.168.44.5)
On the client:
# udp-receiver --interface eth0 --portbase 12345 --nokbd --nosync --file
./bla.tar
Udp-receiver 2004-02-22
UDP receiver for ./bla.tar at 10.168.44.5 on eth0
received message, cap=00000019
Connected as #0 to 10.168.44.1
Listening to multicast on 234.168.44.1
bytes= 11 929 600 ( 15.91 Mbps) 11 929 600
Transfer complete.
ramon@u5:~/1.udptest$
Now there is no timestamps, but the udp-sender starts the multicast in
about 2 seconds after the connect from the client. But the sender does
not have 20 clients connected, and it didn't wait 10 minutes at all (I
kind of overdid the values here, but with lower values it doesn't work
either).
Am I missing something?
Kind regards,
Ramon Bastiaans.
Our notebook supplier says they cannot provide the exact
same model of disk in all units of a fairly large order.
Assuming that most data will be packed in the beginning of
the drive (we use Ghost on the template development machine,
which should be doing a defrag as it makes its image),
how can there be any data loss if there is a small difference
in size between two models of drive?
The alternate paranoid approach is to make an image file
for every model of drive involved. If there is no real
need to do that, we'd like to avoid the extra efforts
involved in making a new image file each time a new
model of drive is encountered.
--Donald Teed
I'm trying to image a 20G drive containing XP Pro (NTFS) to a single
file on a Linux receiver and then transimt this image back to the same
XP box to test things are working ok.
I can create the image with no problems (no compression used) and then
udpcast the image back to the same machine it was taken from. When I
reboot this machine I get "A disk read error occurred - Press
Ctrl+Al+Del to restart"
I've tried several times with no success - anyone got any ideas or
managed to get this to work?
Even the XP disk will not boot to allow repair - PC just hangs after it
has started inspecting setup.
Thanks
Lee Baker
This is a reply from a co-worker. Does this make a little bit more
since? We are using WindowsXP Fat32. We always copy the whole partition.
Michael Sugg
AV/Computer Tech
Randolph County Schools
2234D Enterprise St.
Asheboro NC 27205
(w)336-318-6170
(c)336-736-7538
-----Original Message-----
From: Uhl, Mark
Sent: Monday, May 17, 2004 9:39 AM
To: Sugg, Michael
Subject: RE: Udpcast Digest, Vol 11, Issue 4
We are mostly using udpcast in a machine to machine situation. We would
like a way to add a command switch (/?) to the udpcast floppy that
would only copy from the sender to the receiver only the portion on the
hard drive that actually has data not the entire hard drive.
-----Original Message-----
From: Sugg, Michael
Sent: Monday, May 17, 2004 8:36 AM
To: Moffitt, Jimmy; Uhl, Mark
Subject: Udpcast Digest, Vol 11, Issue 4
udpcast is reading the drive as raw data (similar to dd).
It doesn't care what file system is there or whatever.
You can select a partition, or the whole drive.
To get the best compression of the unused portion of your
drive, write zeros to it. If it is something like FAT32 or
ext2, then this is possible with the dd command. If you
are stuck with NTFS, then the perl script mentioned
on the g4u web page will zero the unused portion of a drive
partition.
In a recent laptop I'm working with having a 40 GB drive,
imaging takes about 30 minutes. When you are writing the
empty part of the drive, the only bottleneck is the drive's
write speed. Writing zeros is as fast as your drive
can go and this doesn't drag down the performance as much
as one might expect.
Any tool that can write just the files, needs to be able to
read and write the file system type. You didn't mention
what that was in your email. It also needs to be able
to set up the boot record information on the MBR, which
is fairly simple for something like LILO with Linux, but
not as straightforward with Windows.
I tried doing a image and restore of a Windows XP FAT32 system
using tar from KNOPPIX booted cdrom and using dd to grab 512 bytes from
the MBR of /dev/hda (and stick it into the tar). When the
data was restored, I had a file system, but the way Windows
uses the MBR must involve a hard pointer to the offset
where the boot loader resides. I don't know how to do
the equivalent of "rerunning LILO" for Windows except
that funky fixmbr command that exists only in the Windows XP
recovery console.
Linux (or the busybox boot environment) cannot write to
an NTFS system, so this is not a possibility either.
The methods to do this are known to the makers of Ghost
and all of the companies Symantec has been buying up that
make competitors to Ghost (except for the inreliable
Imagecast by Phoenix).
--Donald Teed
On Thu, 13 May 2004, Sugg, Michael wrote:
> Is there a switch command that will enable udpcast to only image the
HD
> that has information on it? For ex. If a HD only has 6 of the 40 Gig
> taken on it, Ghost will only copy 6G. I love the udpcast software, but
> it takes longer because it copies the whole 40G HD. Is there a switch
> that will fix this? And where do I need to put the command? Thanks.
>
>
>
> Michael Sugg
>
> AV/Computer Tech
>
> Randolph County Schools
>
> 2234D Enterprise St.
>
> Asheboro NC 27205
>
> (w)336-318-6170
>
> (c)336-736-7538
>
>
>
>
------------------------------
_______________________________________________
Udpcast mailing list
Udpcast(a)udpcast.linux.lu
http://udpcast.linux.lu/mailman/listinfo/udpcast
End of Udpcast Digest, Vol 11, Issue 4
**************************************
Is there a switch command that will enable udpcast to only image the HD
that has information on it? For ex. If a HD only has 6 of the 40 Gig
taken on it, Ghost will only copy 6G. I love the udpcast software, but
it takes longer because it copies the whole 40G HD. Is there a switch
that will fix this? And where do I need to put the command? Thanks.
Michael Sugg
AV/Computer Tech
Randolph County Schools
2234D Enterprise St.
Asheboro NC 27205
(w)336-318-6170
(c)336-736-7538
During imaging, I am going to be grabbing information for our
database such as BIOS service tag from Dell, MAC address, etc.
I may be asked if I can also supply the battery pack serial number.
I've noticed that I can get part of the battery info from under
/proc/acpi/battery/BAT0/info . The 2.4.26 kernel linked on the
udpcast website doesn't include ACPI support, so I'm trying to
compile my own kernel. I've had limited success. I've done
this sort of thing before, just not for a PXE boot environment.
I need to be able to support the ipappend 1 option in default,
and this requires the config option "IP: kernel level autoconfiguration"
and DHCP/BOOTP under it. I'm not sure what network file
system options must be provided. I don't really need
to mount anything on NCP/NFS, etc, but just a normal
PXE boot using initrd. I saw the sample config file for
floppy based boot, but it was not close enough for what
one needs in a PXE boot.
--Donald Teed
