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
We have some less than reliable used laptops to image.
Sometimes on a few machines the PXE boot starts and fails
and it requires another boot up to get it going again.
I mention this because the problem I mention was not
observed before with more predictable machines.
If 15 machines are booted, and set to go into receive mode,
and udp-sender is run on the imaging server, and 4 clients
need to be rebooted to restart PXE, we have noticed that we
see a list of only the first 11 machines on the ready list from
udp-sender, even after the remaining 4 have come up and show
that UDP receiver is ready (but does not display "hit any key
to start" on the remaining 4).
It seems like there is a window of a few minutes before the
udp-sender will stop listening for more udp-receivers to say
they are ready.
I checked the options and I don't see any that are designed to increase
how long it will wait to see more machines responding as ready.
Are there any suggestions?
For now, I think we'll wait until all machines show udp-receiver
ready and then run udp-sender, but I'd hope this will not be
necessary.
--Donald Teed
Hi Alain, and everyone else, thanks Alain for making this wonderfull
tool. I really hope that you will have time for it in the future as
well, it has amazed everbody I have showed it to since ~2002.
Now I thought I was going to use the busybox dialog system you have
built, So I downloaded this patch:
http://udpcast.linux.lu/current/busybox.diff.gz
and well I'm abit confused because I ran "patch -p0 <busybox.diff"
and got the whole busybox distribution in a directory named
busybox. I tried running this:
# diff -Pur busybox-1.00-pre10 busybox |wc
38293 164676 1187667
# cat busybox.diff |wc
208529 900921 5876259
Have I missed something? I don't have alot of experience with diff, so maybe Iäm missing something here.
Saludos Erik
The udpcast part is working well enough. I made a nice
cast-o-matic image for PXE boot with all of the network
devices we may need to support. I think cast-o-matic is
the neatest think about udpcast and its tools.
I'm using an initial menu in PXE boot to select how to launch udpcast
(a solution suggested by Alain).
For that process, DHCP client fires up and gets an address OK.
The client is using a Broadcom BCM5702 based ethernet device.
I select the menu item (say sender for whole disk)
and then the linux kernel boots fine. DHCP gives
out address 192.168.1.207
Now we get into the blue screen section and it shows:
Sending bootp request...
Alert
info, udhcpc V0.9.9_pre) started
debug, sending discover... (3 times)
info, No lease, failing
(OK)
At the time the bootp request goes out the dhcp server shows
this in the log file:
in.tftpd[1902]: tftp: client does not accept options
On the client, I use the OK button and see a prompt
for Automatic Configuration. I select Yes for that,
and I get another status screen showing that:
info, udhcpc 0.9.9_pre started
debug, Sending discover
debug, sending select for 192.168.1.210
info, lease of 192.168.1.210 obtained lease time 2800
Again the daemon log for dhcpd and in.tftpd shows that
"client does not accept options"
However everything is fine on this second bootp pass.
I read on Novell about the -r switch for in.tftpd to
disable blksize for another Broadcom ethernet device
in the same family.
http://www.novell.com/coolsolutions/nnlsmag/features/a_install_via_pxe_boot…
So I've been using this to launch tftpd:
in.tftpd -l -s /tftproot -vv -r blksize
I'm avoiding inetd since it can stall when too many
simultaneous requests come in (security feature, but no
use to this situation).
The -r blksize didn't change the problem.
Once I manually click OK after the first bootp
request and say Yes to automatically configuring with DHCP,
it does work OK and udpcast works. However it would
be better if the process could run without
the user intervention at all of the clients.
I know this isn't exactly a problem in udpcast itself,
but in its surrounding environment, but I'm wondering
if anyone might know if this is a problem specific
to this client hardware and what might help the problem
(other TFTP options to suspend, other kernel with
newer driver that might avoid the issue)?
There are only 2 machines on the network of my test, so
there is no way another DHCP server might be answering the
call.
--Donald Teed
Since end of January, list distribution and archiving on
udpcast(a)udpcast.linux.lu was broken due to a mis-set alias.
The problems are fixed now, and archives are working again.
Archives can be browsed, as before, on
http://udpcast.linux.lu/pipermail/udpcast/
Articles posted during the outage have been manually added, so that
the archive is complete again.
Have fun,
Alain
