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
Please send the folowup question to the group as well. I don't know how to
do it in Windows.
Glad to help,
Lee
-----Original Message-----
From: cmonster(a)icehouse.net [mailto:cmonster@icehouse.net]
Sent: Wednesday, July 28, 2004 10:47 PM
To: Lee Kransen
Subject: RE: [Udpcast] Image size bigger that actual space used
Thanks for the reply. I kind of thought it might something like that. These
are
widows systems I am imaging. How would I zero-ize the drive it windows?
Quoting Lee Kransen <lee(a)servision.net>:
> 1. Although 2.5/20 is currently in use it could be that much of the rest
of
> the 20GB was once written to and now does not contain strictly 0000000's.
In
> this case the compression will not be as great as it could be. You may
want
> to use the suggested procedure for Zero-izing your disk before turning it
> into a compressed image. This will have to be done for each partition on
the
> disk.
>
> -----------------------------------------------
> On the live system, just create a huge file:
>
> dd if=/dev/zero of=filler-file
>
> After a while, the dd will error out with a "disk full" error.
>
> Then, do a couple of syncs, and remove the file.
>
> sync
> sync
> rm filler-file
> -----------------------------------------------
>
> 2. lzop is designed for speed and not compression. Try setting the
> compression level to -7, -8, or -9 for better compression.
>
> Lee
>
>
> -----Original Message-----
> From: udpcast-bounces(a)udpcast.linux.lu
> [mailto:udpcast-bounces@udpcast.linux.lu] On Behalf Of
cmonster(a)icehouse.net
> Sent: Tuesday, July 27, 2004 4:36 PM
I am having a problem with the compressed size of the drive being far larger
than the size that is really used (I.E. 2.5 gigs used but image size of 9 gigs).
I found a program called sdelete and tried using it to cleanise the unused
space. But every time I run the udpcast to remake the image after using sdelete
it is even bigger than before! Any one have any ideas?
> To: udpcast(a)udpcast.linux.lu
> Subject: [Udpcast] Image size bigger that actual space used
>
>
>
> I have been trying to send an image to my server. The hard drive on the
> computer
> that I am sending from is 20 gig with 2.5 used. I turn on lzop compession
> and
> send the image to the server. But the image file endes up being 8.2 gigs.
> Any
> idea why it would be that big?
>
> Thanks again for your help
> Kevin
> _______________________________________________
> Udpcast mailing list
> Udpcast(a)udpcast.linux.lu
> http://udpcast.linux.lu/mailman/listinfo/udpcast
>
>
In my scenario I would like to run DHCP and TFTP on one machine and use a
second running machine as the sender. Is this possible to do with UDPCast?
This would mean copying a live (online) machine, is that a problem? How
would I set this up?
Thanks
I have been trying to send an image to my server. The hard drive on the computer
that I am sending from is 20 gig with 2.5 used. I turn on lzop compession and
send the image to the server. But the image file endes up being 8.2 gigs. Any
idea why it would be that big?
Thanks again for your help
Kevin
I've considered adding a feature to power off the client
machines after imaging, and I've seen that the busybox
halt and poweroff don't actually shut off the power,
at least on a Dell D600 notebook with the 2.4.26 kernel.
On the busybox mailing list, someone discussed using:
echo 5 > /proc/acpi/sleep
This seems to work OK in my testing from the busybox shell
within udpcast session, without actually running an imaging session.
In the case of nothing being mounted, is there any potential
for damage to the client system by powering off this way inside
udpreceiver.post?
I can't think of any problems, but I thought I should check
if anyone knows of anything that might not be flushed
from memory, etc., immediately after a udp-receiver operation.
--Donald Teed
This is a great product! I have already used it a bunch, I imaged 59 computers
on friday in an an hour an half. But I have some questions.
Question 1
Most of my machines have the same hardware, but some have had hard drives
replaced. so some are bigger... If I go from a big hard drive to a smaller one I
get and error but it seems to work just fine. But if I go from a smaller hard
drive to a bigger one it says transfre complete. But when I restart the the
computer (windows 98) I get invalid system disk. Is there any way or trick to be
able to copy from a smaller drive to a bigger one?
Question 2
I have been trying to use the command line tool so I can store images on a
server. I have a computer running Fedora core 2 and I can start the recieving
process by typing in udp-reciever -f pIII98. It says the following:
udp-reciever 2004-05-31
UDP reciever PII98 at 10.4.222.79 on eth0
On the sending machine I boot off the cdrom and start the sender, this is what
it says:
UDP sender 2004-05-31
using mcast address 234.4.222.2
compressed UDP sender for /dev/hda/ at 10.4.222.2 on eth0
Broadcasting control to 10.255.255.255
Both should be set to use the default port of 9000, but they won't connect. They
will both just sit there like this. If I boot them both off the cd they will
connect just fine. I am only not able to connect when using the command line
tool.
If anybody could help me out that would be great.
Thanks
Kevin Christensen
Kuna Joint school district
Kuna Idaho
As part of our production procedure we need to create a disk with a large,
mostly empty, /home partition (hda6). In addition to this, the size of the
disks that we copy to varies. It would be best for us to create the
partition and file system using mke2fs and then fsck in an udpreceiver.post
file. However BusyBox does not support mke2fs of fsck. Is there another way
to do this?
Best regards,
Lee
Hi,
I am new to multicasting and to UDPCast. I was wondering if it is possible to save a complete system to an image file, preferable lzoped or
gziped, and then multicast the image to a number of computers using UDPCast?
Best regards,
Lee Kransen
