14 Jul
2004
14 Jul
'04
4:16 p.m.
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
15 Jul
15 Jul
5:06 a.m.
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
3:14 p.m.
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
20 Jul
20 Jul
9:51 a.m.
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
10:27 a.m.
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
6886
days inactive
6892
days old
4 comments
3 participants
participants (3)
-
Alain Knaff -
Donald Teed -
Felix Rauch