On Tuesday 28 September 2004 10:41, Bernard Chatin wrote:
First let me thanks you for this not enough known but great application (it
allows me to save a laptop hard drive where commercial product like Acronis
just fails and open source g4u didn't recognize the network card).
I'm considering using this product to save special configurations with PXE.
I successfully tested it with the linux24 precompiled kernel (the linux26
fails to detect my USB keyboard). To avoid the menu options witch will be
the same accross my network I tried to use the documented keywords like
those described in http://www.udpcast.linux.lu/current/bootloader.html
the default file after the append keyword( append initrd=initrd
disk=/dev/hda umode=snd auto=yes). I read a previous post that says that
only the first 6 parameter are taken into account. Here it just doesnt't
work. Do you know if it's a kernel configuration problem ?
I haven't yet found the reason why this it only takes the 6 first
Is there a
workaround (for example putting those parameters in a another configuration
file) to avoid the menus ?
Yes, you can include a /udpcfg.txt file into the initrd image using
the --savefile option of the makeImage script.
The savefile is a text file that may contain the following settings,
one per line. Unlike for the kernel command line, there is no limit in
the number of parameters for the save file
lang= menu language
kbmap= keyboard map
netmodule network card module (driver) to load
netmodparm parameters for network card module
dhcp whether to use dhcp (yes/no)
ip ip address (if dhcp not set)
netmask netmask (if dhcp not set)
port UDP port (default: 9000)
disk partition or disk to copy (for example /dev/hda)
umode snd for sender, rcv for receiver
compr compression mode (gz, lzop or none)
udpcparam additional parameter to pass to udpsender/udpreceiver
You may also use the online cast-o-matic tool to build an image:
A few words about an added feature I would like to
I would like to have several process waiting on my linux server ready to
backup several hosts in their owns "file.img". That implies at least two
The possibility to generate a unique file name for each different client
... or, alternatively, you may use a different UDP port for each
client type, and have udp-receivers listening for each client type,
each bound to their own file.
(One approach would be to send the mac address from
the client and to use
it with a time stamp on the server).
IP addresses might be easyer to implement (... and a one-to-one
mapping between Mac and IP may easily be set up by using a static DHCP
The possibility for the receiver to be split in a
daemon part that never
quits and a child process to be spawned for each client.
Could be encapsulated into a while loop in a shell script.
while : ; do
./udp-receiver -p 9002 -f client-9002.img --nokbd
mv client-9002.img client-9002-`date +%Y%m%d-%H%M%S`.img
The date command helps to make the file names unique, in order not to
overwrite earlyer transmissions.
For that part
maybe it could be easier to use in the middle an http server and a cgi
Yes, you could make a CGI script which would start an udp-receiver (or
even a sender) in the background, and then return. The --nokbd option
may be helpful here, in order to prevent udp-receiver (or sender) to
become confused by the absence of a keyboard.