Discussion:
Corrupted partition preventing boot?
(too old to reply)
Dariusz Piatkowski
2010-02-24 19:40:11 UTC
Permalink
Folks,

Looks like my main boot partition on my WD VelociRaptor SATA drive took a
dump...but the real strange thing is that for some reason even as I attempt to
boot off of a maintenance partition (same drive) the boot process gets stuck
during the HPFS386 FS load.

Specifically, the HPFS386 message comes up on the screen (normal '...HPFS386
file system...' stuff), but as the scan of the 'bad' partition begins the drive
goes silent and the boot process stops right there...it will NOT go past this
step. I can listen to the drive execute various seek commands and see the HD
light flashing as the maintenance partition is scanned, but I believe the boot
stops when the bad partition is encountered.

I attempted to boot off of my emergency floppies...boot gets stuck in the same
spot.

I am going to try booting with plain HPFS (not using ACLs in my HPFS386
implementation) next...but this one has me stumped. I would have expected that
if the partition was bad it would be marked as such and skipped...so I'm quite
puzzled how a presumably bad partition is hanging the whole boot process.

Any ideas?
b***@gmail.com
2010-02-25 05:55:24 UTC
Permalink
the hard drive may be toast

later,
lin Baden
Post by Dariusz Piatkowski
Folks,
Looks like my main boot partition on my WD VelociRaptor SATA drive took a
dump...but the real strange thing is that for some reason even as I attempt to
boot off of a maintenance partition (same drive) the boot process gets stuck
during the HPFS386 FS load.
Specifically, the HPFS386 message comes up on the screen (normal '...HPFS386
file system...' stuff), but as the scan of the 'bad' partition begins the drive
goes silent and the boot process stops right there...it will NOT go past this
step. I can listen to the drive execute various seek commands and see the HD
light flashing as the maintenance partition is scanned, but I believe the boot
stops when the bad partition is encountered.
I attempted to boot off of my emergency floppies...boot gets stuck in the same
spot.
I am going to try booting with plain HPFS (not using ACLs in my HPFS386
implementation) next...but this one has me stumped. I would have expected that
if the partition was bad it would be marked as such and skipped...so I'm quite
puzzled how a presumably bad partition is hanging the whole boot process.
Any ideas?
Dariusz Piatkowski
2010-02-26 04:40:17 UTC
Permalink
Post by b***@gmail.com
the hard drive may be toast
later,
lin Baden
Post by Dariusz Piatkowski
Folks,
Looks like my main boot partition on my WD VelociRaptor SATA drive took a
dump...but the real strange thing is that for some reason even as I attempt to
boot off of a maintenance partition (same drive) the boot process gets stuck
during the HPFS386 FS load.
Specifically, the HPFS386 message comes up on the screen (normal '...HPFS386
file system...' stuff), but as the scan of the 'bad' partition begins the drive
goes silent and the boot process stops right there...it will NOT go past this
step. I can listen to the drive execute various seek commands and see the HD
light flashing as the maintenance partition is scanned, but I believe the boot
stops when the bad partition is encountered.
I attempted to boot off of my emergency floppies...boot gets stuck in the same
spot.
I am going to try booting with plain HPFS (not using ACLs in my HPFS386
implementation) next...but this one has me stumped. I would have expected that
if the partition was bad it would be marked as such and skipped...so I'm quite
puzzled how a presumably bad partition is hanging the whole boot process.
Any ideas?
Yes, I am starting to think the same as well...
Jonathan de Boyne Pollard
2010-02-25 13:37:25 UTC
Permalink
I would have expected that if the partition was bad it would be marked
as such and skipped.
What on Earth led you to that expectation? You must have had CHKDSK run
on boot before, so you must know that what actually happens is that
partitions marked as bad are detected and repair attempts are
automatically attempted for them.

It's time to remind yourself of the /AUTOCHECK command-line option to
the HPFS filesystem driver.
Dariusz Piatkowski
2010-02-26 04:39:51 UTC
Permalink
On Thu, 25 Feb 2010 13:37:25 UTC, Jonathan de Boyne Pollard
Post by Jonathan de Boyne Pollard
I would have expected that if the partition was bad it would be marked
as such and skipped.
What on Earth led you to that expectation? You must have had CHKDSK run
on boot before, so you must know that what actually happens is that
partitions marked as bad are detected and repair attempts are
automatically attempted for them.
It's time to remind yourself of the /AUTOCHECK command-line option to
the HPFS filesystem driver.
Well, maybe I didn't quite put this the right way.

Yes, of course I'm aware of the /AUTOCHECK option, and it is in fact turned on.
During the boot however no attempts to run CHKDSK are actually executed...none
that I can visibly see anyways. Like I said - granted this is based on rather
crude empirical evidence - when the HD light goes off so to appears to be all
disk activity on that HD, no more head seek noises are emitted, etc...the boot
process stops DEAD in that spot.

I suspect a bad HD at this point in time....however, given the multitude error
handling capabilities built into the drives I had hoped that if a given area of
a drive went bad it could be automatically either re-mapped (after all isn't
that what spare sectors are for?) or marked as unusable and discarded. Yes, I
also realize that this might leave the very partition in a state of complete
mess/error...however I would have thought that maybe the error was related to
the logical partition as opposed to the physical harddrive layout. Apparently I
may be wrong on this last count...

As-is, I am no longer worried about the boot partition...my system was set up to
sync up the backup disk with the main disk on nightly bassis, rather I have a
single data partition on that drive which I am still hoping to get to in order
to retrieve some data off of it. I recently created this partition and never
managed to get my back-up drive to mirror this partition and to sync up...
PJ
2010-02-26 11:55:01 UTC
Permalink
Suggest you use DFSee to try to rescue the data you need. If you have a
registered copy you can also get very good help from the author.
Peter
Post by Dariusz Piatkowski
As-is, I am no longer worried about the boot partition...my system was set up to
sync up the backup disk with the main disk on nightly bassis, rather I have a
single data partition on that drive which I am still hoping to get to in order
to retrieve some data off of it. I recently created this partition and never
managed to get my back-up drive to mirror this partition and to sync up...
ivan
2010-02-26 12:35:35 UTC
Permalink
On Fri, 26 Feb 2010 04:39:51 UTC, "Dariusz Piatkowski"
Post by Dariusz Piatkowski
On Thu, 25 Feb 2010 13:37:25 UTC, Jonathan de Boyne Pollard
Post by Jonathan de Boyne Pollard
I would have expected that if the partition was bad it would be marked
as such and skipped.
What on Earth led you to that expectation? You must have had CHKDSK run
on boot before, so you must know that what actually happens is that
partitions marked as bad are detected and repair attempts are
automatically attempted for them.
It's time to remind yourself of the /AUTOCHECK command-line option to
the HPFS filesystem driver.
Well, maybe I didn't quite put this the right way.
Yes, of course I'm aware of the /AUTOCHECK option, and it is in fact turned on.
During the boot however no attempts to run CHKDSK are actually executed...none
that I can visibly see anyways. Like I said - granted this is based on rather
crude empirical evidence - when the HD light goes off so to appears to be all
disk activity on that HD, no more head seek noises are emitted, etc...the boot
process stops DEAD in that spot.
With AUTOCHEK on chkdsk runs without any output to the screen at boot
time.

What you have happening is chkdsk trying to check the disk and failing
which stops the boot process.

There is a possibility you may be able to recover from this if you
have a USB to hard drive converter (something like the Ultra USB 2.0
to IDESATA Cable for 2.5-Inch 3.5-Inch 5.25-Inch Drive with Power
Adapter, ULT40112).
Post by Dariusz Piatkowski
I suspect a bad HD at this point in time....however, given the multitude error
handling capabilities built into the drives I had hoped that if a given area of
a drive went bad it could be automatically either re-mapped (after all isn't
that what spare sectors are for?) or marked as unusable and discarded. Yes, I
also realize that this might leave the very partition in a state of complete
mess/error...however I would have thought that maybe the error was related to
the logical partition as opposed to the physical harddrive layout. Apparently I
may be wrong on this last count...
As-is, I am no longer worried about the boot partition...my system was set up to
sync up the backup disk with the main disk on nightly bassis, rather I have a
single data partition on that drive which I am still hoping to get to in order
to retrieve some data off of it. I recently created this partition and never
managed to get my back-up drive to mirror this partition and to sync up...
If you remove the drive and are then able to boot the machine there is
hope for recovery using a USB to disk converter and DFSee. Being able
to boot without the disk also shows most of your hardware is OK.


ivan
--
Steve Wendt
2010-02-27 05:39:11 UTC
Permalink
Post by ivan
With AUTOCHEK on chkdsk runs without any output to the screen at boot
time.
??? That's not what I've ever seen.
Peter Brown
2010-02-25 17:17:03 UTC
Permalink
Hi Dariusz
Post by Dariusz Piatkowski
Folks,
Looks like my main boot partition on my WD VelociRaptor SATA drive took a
dump...but the real strange thing is that for some reason even as I attempt to
boot off of a maintenance partition (same drive) the boot process gets stuck
during the HPFS386 FS load.
Specifically, the HPFS386 message comes up on the screen (normal '...HPFS386
file system...' stuff), but as the scan of the 'bad' partition begins the drive
goes silent and the boot process stops right there...it will NOT go past this
step. I can listen to the drive execute various seek commands and see the HD
light flashing as the maintenance partition is scanned, but I believe the boot
stops when the bad partition is encountered.
I attempted to boot off of my emergency floppies...boot gets stuck in the same
spot.
I am going to try booting with plain HPFS (not using ACLs in my HPFS386
implementation) next...but this one has me stumped. I would have expected that
if the partition was bad it would be marked as such and skipped...so I'm quite
puzzled how a presumably bad partition is hanging the whole boot process.
Any ideas?
I'm not sure how closely related this is...

A couple of days ago I was running WindowsXP Pro in a VPC/2 when XP
locked solid.

I could not switch to my eCS2.0RC6a Desktop to kill VPC/2 and trying
seemed to cause eCS to lockup as well - clock stopped, no movement in
eComCenter Activity Monitor, no response to keyboard, mouse had stopped
moving, No Ctrl-Alt-Del...

I pressed the system box Reset switch and the system failed to display
the Boot Manager after the POST.

I have 2 SATA2 drives. Disk1 is 160Gb and has volumes C: through I:
Disk2 is 80Gb and has volumes J: through L:

I was booted from L: at the time of the crash; VPC/2 is on J: with it's
disks (*.vhd files) on I:

As I could not boot from hard drive I thought Boot Manager may have
somehow got mangled so attempted to boot from eCS2.0RC7 CD. That failed
to boot.

I left the system powered off while I went for a coffee and spliff - and
a cogitation.

Having refreshed myself I had another look at the problem and, as I was
booted from Disk2 at the time of the crash I thought that maybe I could
get somewhere if I disconnected Disk2 and retried booting from eCS2.0RC7 CD.

That worked so I booted to the "Maintenance Console" and performed
chkdsks on volumes G: through I: (all JFS); volumes E: and F: are FAT16
so they had been automatically checked/corrected. Volumes C: (NTFS) and
D: (FAT32) I hoped to be able to check at a later time.

I then had a look at the disk using LVM.

As the drive had failed to display Boot Manager I deleted the existing
installation, reinstalled it and added eCS2.0RC7 (H:) to the boot menu.

I then rebooted and allowed boot from hard drive when asked by the
eCS2.0 CD. Boot Manager appeared.

Looks like the problem is with Drive2...

Fearing the worst (dead disk) I powered off the system and added Disk2
back into the mix.

I decided to boot from eCS2.0RC7 CD again - it has a "disk integrity
check" which Disk2 failed. I elected to not let eCS fix the problem
which results in the system stopping there as eCS will not continue when
it detects a disk fault that the user will not let it fix.

I rebooted from the CD but this time declined the disk integrity check
in order to see if Disk2 was accessible at all. I got to the Maintenance
Console and ran chkdsk against volumes J: through L: which worked fine;
I could now access those drives without problems.

I then ran LVM.

Disk2 showed 7Mb Free Space where I expected it to have a 7Mb Boot
Manager partition. I reinstalled Boot Manager and added L: eCS2.0Rc6a to
the boot menu.

I then rebooted the system, with the ecS CD removed, and was rewarded by
Boot Manager appearing and displaying the 2 boot options "Disk 1
eCS2.0RC7" and "Disk 2 eCS2.0RC6a".

I tested that both boot options work fine and am currently using the
RC6a installation and have been since resolving the problem so doubt it
was a hardware failure related event.

MY XP in VPC/2 installation seems to have survived intact as well.

I am not sure what caused the original problem which seemed to involve
deleting Boot Manager from Disk2 but there was a "pop under" Internet
Explorer window - ie a popup window that hides under other open windows
- that appeared in the XP VPC/2 session immediately prior to the XP
VPC/2 and then eCS lockups.

I do wonder if that had interfered with the Boot Manager on Disk2; maybe
downloading some code to wipe the 1st primary (Boot Manager) partition
on Disk2?


As I said earlier: I'm not sure how closely related this is...

Regards

Pete
Marcel Müller
2010-02-26 13:02:20 UTC
Permalink
Hi,
Post by Dariusz Piatkowski
Specifically, the HPFS386 message comes up on the screen (normal '...HPFS386
file system...' stuff), but as the scan of the 'bad' partition begins the drive
goes silent and the boot process stops right there...it will NOT go past this
step. I can listen to the drive execute various seek commands and see the HD
light flashing as the maintenance partition is scanned, but I believe the boot
stops when the bad partition is encountered.
this is a bug in HPFS386. The driver cannot correctly deal with dirty
partitions. So if you have any partition that is not clean when the
driver loads, the system might stop. This also includes removable media.
Post by Dariusz Piatkowski
I attempted to boot off of my emergency floppies...boot gets stuck in the same
spot.
I am going to try booting with plain HPFS
Do your emergency disks really utilize HPFS386?
Post by Dariusz Piatkowski
(not using ACLs in my HPFS386
implementation)
ACLs are no problem. The local security feature will cause the plain
HPFS driver to reject.
Post by Dariusz Piatkowski
I would have expected that
if the partition was bad it would be marked as such and skipped...so I'm quite
puzzled how a presumably bad partition is hanging the whole boot process.
That's the bug. HPFS.IFS does not share this bug and will load without
any problem when dirty volumes are attached.

You have two choices:
- Either you ensure that all attached HPFS volumes are clean during
boot. The easiest way is to use JFS for all other volumes.
- Or you downgrade to plain HPFS.


Marcel
Steve Wendt
2010-02-27 05:42:01 UTC
Permalink
Post by Marcel Müller
this is a bug in HPFS386. The driver cannot correctly deal with dirty
partitions. So if you have any partition that is not clean when the
driver loads, the system might stop. This also includes removable media.
I don't know about removable media, but I've never had a problem with
HPFS386 failing to run chkdsk on my dirty partitions.
Marcel Müller
2010-02-27 09:28:48 UTC
Permalink
Hi,
Post by Steve Wendt
Post by Marcel Müller
this is a bug in HPFS386. The driver cannot correctly deal with dirty
partitions. So if you have any partition that is not clean when the
driver loads, the system might stop. This also includes removable media.
I don't know about removable media, but I've never had a problem with
HPFS386 failing to run chkdsk on my dirty partitions.
HPFS386 has no problem with CHKDSK. HPFS386 has a problem with
inaccessible volumes when the driver loads. Then it may lock up. This
does not always happen but quite often.
So, if CHKDSK is not successful for some reason or if one drive letter
is missing in the autocheck list, it is likely to hang. This is
especially annoying because checking volumes later at boot time is about
ten times faster and might be parallelized for different physical drives.


Marcel
Dariusz Piatkowski
2010-02-27 19:24:22 UTC
Permalink
Dariusz Piatkowski
2010-02-27 19:36:57 UTC
Permalink
On Wed, 24 Feb 2010 19:40:11 UTC, "Dariusz Piatkowski"
Post by Dariusz Piatkowski
Folks,
Looks like my main boot partition on my WD VelociRaptor SATA drive took a
dump...but the real strange thing is that for some reason even as I attempt to
boot off of a maintenance partition (same drive) the boot process gets stuck
during the HPFS386 FS load.
Specifically, the HPFS386 message comes up on the screen (normal '...HPFS386
file system...' stuff), but as the scan of the 'bad' partition begins the drive
goes silent and the boot process stops right there...it will NOT go past this
step. I can listen to the drive execute various seek commands and see the HD
light flashing as the maintenance partition is scanned, but I believe the boot
stops when the bad partition is encountered.
I attempted to boot off of my emergency floppies...boot gets stuck in the same
spot.
I am going to try booting with plain HPFS (not using ACLs in my HPFS386
implementation) next...but this one has me stumped. I would have expected that
if the partition was bad it would be marked as such and skipped...so I'm quite
puzzled how a presumably bad partition is hanging the whole boot process.
Any ideas?
Just a follow-up to this post...found the problem...see my detailed response to
Marcel Muller. Big THANK YOU to all who responded with suggestions. Booting with
plain HPFS and running a CHKDSK on the corrupted partition resolved my issue.
Chuck McKinnis
2010-02-27 22:36:53 UTC
Permalink
On Wed, 24 Feb 2010 19:40:11 UTC, "Dariusz Piatkowski"
Post by Dariusz Piatkowski
Folks,
Looks like my main boot partition on my WD VelociRaptor SATA drive took a
dump...but the real strange thing is that for some reason even as I attempt to
boot off of a maintenance partition (same drive) the boot process gets stuck
during the HPFS386 FS load.
Specifically, the HPFS386 message comes up on the screen (normal '...HPFS386
file system...' stuff), but as the scan of the 'bad' partition begins the drive
goes silent and the boot process stops right there...it will NOT go past this
step. I can listen to the drive execute various seek commands and see the HD
light flashing as the maintenance partition is scanned, but I believe the boot
stops when the bad partition is encountered.
I attempted to boot off of my emergency floppies...boot gets stuck in the same
spot.
I am going to try booting with plain HPFS (not using ACLs in my HPFS386
implementation) next...but this one has me stumped. I would have expected that
if the partition was bad it would be marked as such and skipped...so I'm quite
puzzled how a presumably bad partition is hanging the whole boot process.
Any ideas?
Anything else on the drive?
--
Chuck McKinnis
Loading...