The default behavior of our SLES11sp3 boxes has changed sometime iin the last 6 months, don’t know when exactly.
I have multiple LVM volume groups and volumes in them, I have it configured to do an auto check after 180 days during server boot.
In the past there was a progress bar for all volumes, but now there only is a bar for the volumes in the first volume group.
For the others it just says it is doing the fsck.
Some of our volumes are quite big and it takes a while to complete (which is fine), but now it is sort of impossible to check if something is still happening as our VM’s are in a cloud and I have no visibility for disk IO or CPU utilization.
I assume one of the SLES patches changed this behavior.
Any idea what I should configure to get my bar back?
The default behavior of our SLES11sp3 boxes has changed sometime iin the last 6 months, don’t know when exactly.
I have multiple LVM volume groups and volumes in them, I have it configured to do an auto check after 180 days during server boot.
In the past there was a progress bar for all volumes, but now there only is a bar for the volumes in the first volume group.
For the others it just says it is doing the fsck.
Some of our volumes are quite big and it takes a while to complete (which is fine), but now it is sort of impossible to check if something is still happening as our VM’s are in a cloud and I have no visibility for disk IO or CPU utilization.
I assume one of the SLES patches changed this behavior.
Any idea what I should configure to get my bar back?
Thanks,
Hein[/QUOTE]
I don’t know if this piece of code changed, but it’s /etc/init.d/boot.localfs that’s deciding on whether to show the bar or not:
# If we use a serial console, don't use the fsck progress bar
if test "${REDIRECT##*/}" = "tty1" ; then
FSCK_OPTS="$FSCK_OPTS -C"
else
FSCK_OPTS="$FSCK_OPTS -V"
fi
So probably your VMs don’t report /dev/tty1 as the terminal, when fsck is run?
Thanks for pointing me into this direction.
The progress bar is shown for the volumes in the first LVM group, but not for the ones in the other ones, so I don’t think the /dev/tty1 is the problem.
I did a compare between a plain vanilla SLES11sp3 server and one that has all the recent patches.
File /etc/init.d/boot.localfs is part of package aaa_base-11-6.94.1 that was updated on the server on Sep 13.
File /sbin/fsck is part of package util-linux-2.19.1-6.54.1 that was updated on the server on Jul 12.
I found some changes in the /etc/init.d/boot.localfs file:
Old
# common options for file system check
FSCK_OPTS="-R -A -M -a"
# force file system check if forced
if test -f /forcefsck -o “$DO_FORCEFSCK” = “yes” ; then
FSCK_OPTS="$FSCK_OPTS -f"
fi
# If we use a serial console, don’t use the fsck progress bar
if test “${REDIRECT##*/}” = “tty1” ; then
FSCK_OPTS="$FSCK_OPTS -C"
else
FSCK_OPTS="$FSCK_OPTS -V"
fi
echo “Checking file systems…”
fsck $FSCK_OPTS
# A return code of 1 indicates that file system errors
# were corrected, but that the boot may proceed.
# A return code of 2 or larger indicates failure.
FSCK_RETURN=$?
test -n “$FSTAB_FILE” && rm -f $FSTAB_FILE
test $FSCK_RETURN -lt 4
rc_status -v1 -r
New
# common options for file system check
FSCK_OPTS="-R -A -M -a -t noopts=_netdev"
# force file system check if forced
if test -f /forcefsck -o “$DO_FORCEFSCK” = “yes” ; then
FSCK_OPTS="$FSCK_OPTS -f"
fi
# If we use a serial console, don’t use the fsck progress bar
if test “${REDIRECT##*/}” = “tty1” ; then
FSCK_OPTS="$FSCK_OPTS -C"
else
FSCK_OPTS="$FSCK_OPTS -V"
fi
# test if we know -r
fsck -r /dev/null >/dev/null 2>/dev/null
if test $? -ne 16 ; then
FSCK_OPTS="$FSCK_OPTS -r"
fi
echo “Checking file systems…”
fsck $FSCK_OPTS > /fsck_corrected_errors
# A return code of 1 indicates that file system errors
# were corrected, but that the boot may proceed.
# A return code of 2 or larger indicates failure.
FSCK_RETURN=$?
test $FSCK_RETURN -eq 0 && rm -f /fsck_corrected_errors
test -n “$FSTAB_FILE” && rm -f $FSTAB_FILE
test $FSCK_RETURN -lt 4
rc_status -v1 -r
I am guessing the issue is “> /fsck_corrected_errors”.
The last line I see during boot is “Checking file systems…”
So, what seems to be happening is that the progress bar is written to file /fsck_corrected_errors.
Then when no errors are found in the fsck the /fsck_corrected_errors is deleted again, so leaving no trace.
I guess they should have used “tee” to display both to console and file.
looks like you’ve nailed it… if you’d like to change that piece of code to include tee, please watch out to have the proper rc checked (you’re running a command pipe).