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
On Wed, 14 Jul 2004, Donald Teed wrote: [...]
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?
If you are cloning directly to a hard-disk partition, there might (as far as I know) still be some blocks in the buffer cache that have not been written to disk (I assume that your apm command will halt the machine immediately, but I could be wrong).
Alternatively, you could either first issue a "sync" command before halting the machine, or then shutdown the machine by executing the "shutdown" command with the proper arguments (like "-h" or "-P").
- Felix
There is no shutdown command in busybox. I don't know if a statically compiled one from some other Linux would do the same job. I doubt it would match the needs of the busybox/isolinux environment.
Our notebooks have 512 MB of RAM on board, and one curious feature of udpcast imaging is that the udpcast sender is disconnected when there is still about 5 GB of disk to be written on the client/receiver. It continues writing from highly compressed zeros in RAM.
I joked with the production manager that if I got shutdown to work, they could pack up the notebooks as soon as the server disconnected and have them finish writing from memory to disk while packed up on the shelf. That could save about 5 minutes from the 30 minute job of writing a 40 GB drive.
I guess my concern is for any few seconds of timing that might be required for the disk cache to finish writing. I recall there was a Windows there was a patch to deal with allowing for the larger disk cache to do this on Windows shutdown. I don't know if "sleep 5" would do the same or it needs 10, 15 or whatever.
--Donald Teed
On Thu, 15 Jul 2004, Felix Rauch wrote:
On Wed, 14 Jul 2004, Donald Teed wrote: [...]
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?
If you are cloning directly to a hard-disk partition, there might (as far as I know) still be some blocks in the buffer cache that have not been written to disk (I assume that your apm command will halt the machine immediately, but I could be wrong).
Alternatively, you could either first issue a "sync" command before halting the machine, or then shutdown the machine by executing the "shutdown" command with the proper arguments (like "-h" or "-P").
- Felix
On Thursday 15 July 2004 17:14, Donald Teed wrote:
There is no shutdown command in busybox. I don't know if a statically compiled one from some other Linux would do the same job. I doubt it would match the needs of the busybox/isolinux environment.
Our notebooks have 512 MB of RAM on board, and one curious feature of udpcast imaging is that the udpcast sender is disconnected when there is still about 5 GB of disk to be written on the client/receiver. It continues writing from highly compressed zeros in RAM.
I joked with the production manager that if I got shutdown to work, they could pack up the notebooks as soon as the server disconnected and have them finish writing from memory to disk while packed up on the shelf. That could save about 5 minutes from the 30 minute job of writing a 40 GB drive.
The postinstall script udpreceiver.post is only executed once udpreceiver has completed, so this can indeed be done.
So, if you just put the following inside, it should work:
#!/bin/sh sync sync echo 5 >/proc/acpi/sleep
The syncs should not even be necessary, as udpreceiver already writes the file in synchronous mode (O_SYNC flag).
[This is, as long as the echo 5 >/proc/acpi/sleep works. I tried that on my desktop, but unfortunately it didn't do anything at all. Maybe on a laptop, it does indeed shut down the machine, or put it to sleep]
I guess my concern is for any few seconds of timing that might be required for the disk cache to finish writing.
O_SYNC mode and the sync commands should take care of that.
I recall there was a Windows there was a patch to deal with allowing for the larger disk cache to do this on Windows shutdown. I don't know if "sleep 5" would do the same or it needs 10, 15 or whatever.
--Donald Teed
Or do a sync, followed by the sleep, and another sync to be really sure.
Alain
On Tue, 20 Jul 2004, Alain Knaff wrote:
[This is, as long as the echo 5 >/proc/acpi/sleep works. I tried that on my desktop, but unfortunately it didn't do anything at all. Maybe on a laptop, it does indeed shut down the machine, or put it to sleep]
Yes, I have confirmed that the echo 5 does do a shutdown. It goes down in about 4 seconds. poweroff or halt just stop init processes and the power stays on the laptop.
I have worked with a Linux template for this laptop and I'm familiar with what it looks like when in other power saving states - it would still show a green light on an led somewhere. echo 5 makes all of the lights go out.
In my case I've compiled my own 2.4.26 kernel with APCI support. I needed it to grab the disk model number.
The pre script sends the disk model info back to a web server, which collects the model IDs into a file. The script that fires off udp-sender on the web server first checks that uniq | wc -l on the disk models file produces '1'. If it isn't, it is time to shrink the master disk partition and make a new image, or produce an image specific to the new model of disk.
We have 4500 laptops coming in over the next few months, and Dell says they cannot ensure the 40 GB drive will always be the same model.
People are generally amazed at how flexible this solution is.
--Donald Teed
-
Alain Knaff -
Donald Teed -
Felix Rauch