Hi Dag,
Please see my responses below.
Thanks,
Yasha
On 01/30/2012 03:35 PM, Dag Wieers wrote:
On Mon, 30 Jan 2012, Yasha Karant wrote:
We had a massive power failure, beyond what the UPS could handle.
Despite attempts to find a way for the system to shut down gracefully,
it simply powered down without unmounting the disk partitions.
Nominally, the backup local UPS I am using (APC Back-UPS 650) has an
interface Port DB-9 RS-232 but I have not found any Linux application
that reliably would communicate with this model of UPS (that is,
emulate the same behavior as the application available from APC for MS
Win that senses the RS-232 information from APC, waits the appropriate
time, and then shutdown -- anyone found one?).
Upon boot, automatic fsck failed, and a request was posted for root
password. However, no more than one character of the password would be
accepted, causing an endless loop to this condition and not allowing
me control of the system (run fsck manually).
Hi Yasha,
I wonder:
- whether you were in fact using a journalling filesystem (because it
should even recover from power failure like that when it is journalled)
For the most part, for a number of reasons, we are sticking with ext2,
with -- in the case of my workstation -- fuse ntfs for MS Windows which
is required for particular unpleasantries. We have not made a
production change to ext4, but are considering the transition. We are
attempting to get detailed data on the reliability of the ext4
filesystem, how much overhead (loss of data capacity) ext4 requires, and
the performance change (loss?) between ext2 and ext4. Any detailed,
preferably quantitative, comparisons on production systems will be
appreciated.
- what was mounted on /mnt/sysimage (as normally this is your
root-filesystem during installation, not during runtime)
I did a manual umount from the rescue running image, and verified with
mount that /mnt/sysimage was not mounted . Nonetheless, when the
production system attempted to reboot, it reported that the /dev/sda5
was not cleanly unmounted, and started automatic fsck. This fsck
failed, with the request that I manually run fsck -- an operation I
could not do as the root password was not accepted, being truncated by
the root password input procedure.
- why you couldn't disable the filesystem in /etc/fstab, reboot and fix
it after the system would have booted normally
Indeed, from the rescue running image, a manual invocation of fsck
solved the issue -- including fsck -y /dev/sda* , etc., to get all of
the partitions. When the swap partition was found, fsck complained but
still finished.
- why a filesystem like /mnt/sysimage is configured to stop the
boot-process when it has issues (man fstab, check sixth field)
The filesystem /mnt/sysimage never appears during the regular boot of
the system, only from the rescue image. In this particular situation, I
did a manual umount of /mnt/sysimage but the regular boot sequence
reported that /dev/sda5 (the partition the rescue system mounted on
/mnt/sysimage) had not been cleanly unmounted (repeating what I wrote
above).
Do the above comments clear the fog?
Thanks in advance for clearing the fog,
