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,