Udpcast May 2004

udpcast@udpcast.linux.lu

9 participants
8 discussions

Buggy tg3 ethernet
by Donald Teed 04 Apr '06

04 Apr '06

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

2 1

RE: [Udpcast] udp-sender does not wait at all?
by Ramon Bastiaans 02 Jun '04

02 Jun '04

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 > ------------------------------------------------------

3 2

udp-sender does not wait at all?
by Ramon Bastiaans 27 May '04

27 May '04

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.

2 1

What happens when disks are not exactly the same?
by Donald Teed 26 May '04

26 May '04

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

2 2

No success with imaging XP
by Lee Baker 24 May '04

24 May '04

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

3 3

Udpcast Digest, Vol 11, Issue 4
by Sugg, Michael 17 May '04

17 May '04

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 **************************************

2 1

faster image
by Sugg, Michael 13 May '04

13 May '04

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

2 1

Getting info from ACPI - need to make kernel
by Donald Teed 02 May '04

02 May '04

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

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Udpcast May 2004