From: dumas patrice ([email protected])
Date: Sat Aug 19 2000 - 19:48:45 CEST
Hi,
This is a very long message.
I dunno if it is because I am quite dumb, but I think the info message of
the tmp ressource setting is quite misleading, as explainations are in k
(fore example "I suggest to choice size < 1Mb (e.g 300k)."), but the
parameter TMP_KB_SIZE is in blocks, as it is the mkfs option. So I put
300k on the prompt and it didn't work :-(.
To avoid bad answer of stupid users, I think that either there could be a
prepare section like
prepare(){
echo "enter the tmp size in blocks of one kilobyte"
prompt TMP_KB_SIZE "${TMP_KB_SIZE}"
save -n $1 configure
}
Or the info part should be changed, but I don't know how, as if there is
info on the parameter type, it wouldn't be coherent with the other info
messages.
Another think is that everything goes bad if tmp is not set (if in
ramdisk), so I propose some things to go around user unwant or errors :
for the user unwant, just have an unwanted function like this one in
tmp.fun :
unwanted()
{
in_ram=`mount | rgrep " / " | rgrep ram`
if [ "$in_ram" ] ; then
echo "The system is in ram."
prompt ans "n" "Are you really really sure you don't want to set up /tmp
?(y/n)"
if [ "z$ans" = "zn" ]; then exec setup -f tmp
fi
fi
return 0
}
and to go around a failure in the configure part:
configure()
{
in_ram=`mount | rgrep " / " | rgrep ram`
if [ "$in_ram" ] ; then
check mkfs.${TMP_FS} mount mkdir
umount /tmp 2>/dev/null
TMP_DEVICE="/dev/ram`find_ramdisk`"
mkfs.${TMP_FS} -q ${TMP_DEVICE} ${TMP_KB_SIZE}
#here I add
if [ "$?" -ne 0 ]; then
echo "mkfs.${TMP_FS} couldn't create a {TMP_FS} fs on
${TMP_DEVICE} with ${TMP_KB_SIZE} blocks"
echo "press enter to retry configuration"
read dummy
exec setup -f tmp
else
mkdir -p /tmp
rm -rf /tmp/* 2>/dev/null
mount ${TMP_DEVICE} /tmp
rm -r /tmp/lost*
chmod ugo+rwx /tmp
fi
fi
}
Perhaps it should be interresting to have an error function defined for
all the *.fun, in the setup script, which would take two
args, the ressource name, and an integer, that would have been 0 if there
was no error. Note that that function would have to be carefully used, as
if there is a reconfiguration, the function will return at the same point
where the error occured. So the return status should be tested, 1
indicating there was a retry, so the end of configuration can be
skipped. Does someone have a better idea about that problem ?
error()
{
if [ "$1" -ne "0" ]; then
while [ 1 ]; do
echo "An error occured while configuration of the $2 ressource"
prompt ans "r" "do you want to r)etry, c)ontinue or be dumped to a
s)hell?"
[ "$ans" = r ] && exec setup -f $2 && return 1
[ "$ans" = s ] && break
[ "$ans" = s ] && echo "type exit when finish." && /bin/-ash && break
done
fi
return 0
}
Alternatively, the error should be tested in the process function in
setup, so that after the line,
eval ${ACTION} ${resource}
there should be :
if [ "$?" -ne 0 ] && [ -z "$noconfig" ]; then
echo "An error occured while configuration of the ${resource} ressource"
prompt ans "r" "do you want to r)etry by hand, c)ontinue, be d)umped to a
shell or mark this ressource to be s)kipped next time ?"
[ "$ans" = r ] && eval ask_the_user ${resource}
[ "$ans" = d ] && echo "type exit when finish." && /bin/-ash
[ "$ans" = s ] && save -n ${resource} skipped
done
fi
I think this one is the better one, as it also provides a general
mechanism to handle errors in setup, not prone to the problems existing in
the error function case. But the error function could have been overriden.
Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:15 CET