QNX and bad file descriptor
kh
I thought I'd try QNX so downloaded and installed QNXRTP as a
file in my C: partition (it installs in the same manner as BeOS PE).
It would not boot.
but worse, it also hosed my Windows C: and BeOS Pro partitions.
Bootman still ran but reported something like "cannot mount
/dev/disk/ata/atapi/hda-9"
All attempts to get Windows running failed too, until I reformatted C:
and reinstalled.
I still cant get into BeOS. Using a boot floppy I still get the above
message.
I can run BeOS PE on the E: drive, but if try to mount the BeOS Pro
partition it reports: "bad file descriptor".
I suppose I can reformat and reinstall BeOS Pro but of course there is
data I don't want to lose and haven't backed up. (so not only have I
been unfaithful I didn't take precautions!)
I'm guessing QNXRTP has overwritten something at the start of
the BFS partition; possibly it doesn't recognise BFS as a valid
filesystem and called it something else?? I'm willing to try to use
Diskprobe to rewrite the "file descriptor", whatever that is, if someone
can tell me what to look for.
BTW, I've looked through the thread "No BeoS After reinst Win 98" and
I've already downloaded and had a look at Sven Olaf's Findpart, without
any real understanding of what it's doing. My machine is old with a BIOS
that can only see 2GB but a 10gig drive. BeOS is in the "unsupported"
end. Is that a problem?
Nigel Malthus.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Svend Olaf Mikkelsen
You will need Findpart version 4.18. If that is not the version you
have, it is in:
http://inet.uni2.dk/~svolaf/fpart418.zip
Then do in a Windows DOS box:
findpart all fp.txt
and insert (not attach) the output, no matter what it says.
Do you know if you have Ontrack Disk Manager or EZ-drive installed to
provide BIOS access to the entire disk? Which one?
--
Svend Olaf
Jøhnny Fävòrítê (it means "Pavlov's Dog's Nosehole")
> You will need Findpart version 4.18. If that is not the version you
> have, it is in:
>
> http://inet.uni2.dk/~svolaf/fpart418.zip
Hi Svend,
Axel Dorfler and I are in the early stages of writing a GUI disk
analysis and repair utility for BeOS. The ability to repair broken
partition tables would be great and neither of us know very much about
that. Would you be willing to supply expertise, source code, etc?
kh
Thanks. I'll have a go.
> Do you know if you have Ontrack Disk Manager or EZ-drive installed to
> provide BIOS access to the entire disk? Which one?
> --
> Svend Olaf
No. Neither. The BIOS thinks it has a 2111 MB drive and that's it. We've
fooled it by making one Primary partition of 2G, then dividing up an
extended partition into several others. I guess we've been living
dangerously. But it's an old MB with no BIOS update available.
kh
So what actually has gone wrong when "a bad file descriptor" is
reported?
I had hoped it might be a few bytes I could rewrite by hand in
Diskprobe...
:-(
kh
kh wrote:
>
> Svend Olaf Mikkelsen wrote:
> >
> >
> > You will need Findpart version 4.18. If that is not the version you
> > have, it is in:
> >
> > http://inet.uni2.dk/~svolaf/fpart418.zip
> >
> > Then do in a Windows DOS box:
> >
> > findpart all fp.txt
> >
> > and insert (not attach) the output, no matter what it says.
>
> Thanks. I'll have a go.
>
> > Do you know if you have Ontrack Disk Manager or EZ-drive installed to
> > provide BIOS access to the entire disk? Which one?
> > --
> > Svend Olaf
>
> No. Neither. The BIOS thinks it has a 2111 MB drive and that's it. We've
> fooled it by making one Primary partition of 2G, then dividing up an
> extended partition into several others. I guess we've been living
> dangerously. But it's an old MB with no BIOS update available.
OK:
this is the result:
Findpart, version 4.18.
Copyright Svend Olaf Mikkelsen, 2002.
Searches for partitions type 01, 04, 06, 07, 0B, 0C, 0E, 82, 83,
plus Fdisk F6 and Lilo sectors. Information based on bootsectors
is marked B. If the disk is larger than supported by BIOS, the
supported part of the disk is examined. Disks are numbered from 1.
OS: DOS 7.10 WINDOWS 4.10 All
Disk: 1 Cylinders: 1023 Heads: 64 Sectors: 63 MB: 2014
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
Fdisk F6 sector 0 1 1
Fdisk F6 sector 0 2 1
0 - 0B 4032 2108736 1029 1 0 1 523 63 63 B OK
524 1 0B 63 3596481 1756 524 1 1 1415* 63 63 R0 OK?
524 2 05 3596544 3596544 1756 1416# 0 1 2307* 63 63 524 OK?
0 - 0B 2112831 3596481 1756 524 1 1 1415 63 63 B OK?
-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 2062 4# 1712 17? 140 193 896
1 0 33 2058 4 2 2058 0 0 0 020209 334
524 1 33 3509 4 2 3509 0 0 0 010107 869
There were sectors, which could not be read.
Partitions according to partition tables on first harddisk:
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 4032 2108736 1029 1 0 1 523 63 63 OK OK
0 2 0F 2112768 14386176 7024 524 0 1 4091* 63 63 OK?
524 1 0B 63 3596481 1756 524 1 1 1415* 63 63 R0 OK?
524 2 05 3596544 3596544 1756 1416# 0 1 2307* 63 63 OK?
Error reading sector 5709312.
What do you think?
Nigel.
Svend Olaf Mikkelsen
>Findpart, version 4.18.
>Copyright Svend Olaf Mikkelsen, 2002.
>OS: DOS 7.10 WINDOWS 4.10 All
>
>Disk: 1 Cylinders: 1023 Heads: 64 Sectors: 63 MB: 2014
>
>-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
> Fdisk F6 sector 0 1 1
> Fdisk F6 sector 0 2 1
> 0 - 0B 4032 2108736 1029 1 0 1 523 63 63 B OK
> 524 1 0B 63 3596481 1756 524 1 1 1415* 63 63 R0 OK?
> 524 2 05 3596544 3596544 1756 1416# 0 1 2307* 63 63 524 OK?
> 0 - 0B 2112831 3596481 1756 524 1 1 1415 63 63 B OK?
>
>-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
> 0 1 33 2062 4# 1712 17? 140 193 896
> 1 0 33 2058 4 2 2058 0 0 0 020209 334
> 524 1 33 3509 4 2 3509 0 0 0 010107 869
>There were sectors, which could not be read.
>
>Partitions according to partition tables on first harddisk:
>
>-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
> 0 1*0B 4032 2108736 1029 1 0 1 523 63 63 OK OK
> 0 2 0F 2112768 14386176 7024 524 0 1 4091* 63 63 OK?
>
> 524 1 0B 63 3596481 1756 524 1 1 1415* 63 63 R0 OK?
> 524 2 05 3596544 3596544 1756 1416# 0 1 2307* 63 63 OK?
>Error reading sector 5709312.
Do not write to the D: partition.
If lost data were in the previous C: partition, do not write to C:
Then download nigel1.bat in
http://inet.uni2.dk/~svolaf/nigel1.zip
Put nigel1.bat and findpart.exe on a boot floppy, boot to the floppy,
and run nigel1.bat, which contains:
findpart pm fp1-1a.txt heads 64
findpart pm fp1-1b.txt
Post the content from fp1-1a.txt and fp1-1b.txt.
This reads the primary master directly, without BIOS use.
--
Svend Olaf
Kevin Craik
mean it's wise to put it there.
Kevin
kh wrote:
<snip>
> I can run BeOS PE on the E: drive, but if try to mount the BeOS Pro
> partition it reports: "bad file descriptor".
<snip>
> Nigel Malthus.
kh
Svend Olaf Mikkelsen wrote:
>
> Do not write to the D: partition.
>
> If lost data were in the previous C: partition, do not write to C:
>
> Then download nigel1.bat in
>
> http://inet.uni2.dk/~svolaf/nigel1.zip
>
> Put nigel1.bat and findpart.exe on a boot floppy, boot to the floppy,
> and run nigel1.bat, which contains:
>
> findpart pm fp1-1a.txt heads 64
> findpart pm fp1-1b.txt
>
> Post the content from fp1-1a.txt and fp1-1b.txt.
>
> This reads the primary master directly, without BIOS use.
> --
> Svend Olaf
fp1-1a.txt:
Findpart, version 4.18.
Copyright Svend Olaf Mikkelsen, 2002.
Searches for partitions type 01, 04, 06, 07, 0B, 0C, 0E, 82, 83,
plus Fdisk F6 and Lilo sectors. Information based on bootsectors
is marked B. If the disk is larger than supported by BIOS, the
supported part of the disk is examined. Disks are numbered from 1.
OS: DOS 7.10
Disk: PM Cylinders: 1023 Heads: 64 Sectors: 63 MB: 2014
IDE CHS: 4092/16/63 CTM: 16383/16/63 IDE MB: 2014
User sectors: 4124736 Native sectors: 20015856
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
Fdisk F6 sector 0 1 1
Fdisk F6 sector 0 2 1
0 - 0B 4032 2108736 1029 1 0 1 523 63 63 B OK
524 1 0B 63 3596481 1756 524 1 1 1415* 63 63 R0 OK?
524 2 05 3596544 3596544 1756 1416# 0 1 2307* 63 63 524 OK?
0 - 0B 2112831 3596481 1756 524 1 1 1415 63 63 B OK?
-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 2062 4# 1712 17? 140 193 896
1 0 33 2058 4 2 2058 0 0 0 020209 341
524 1 33 3509 4 2 3509 0 0 0 010107 869
There were sectors, which could not be read.
Partitions according to partition tables on primary master:
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 4032 2108736 1029 1 0 1 523 63 63 OK OK
0 2 0F 2112768 14386176 7024 524 0 1 4091* 63 63 OK?
524 1 0B 63 3596481 1756 524 1 1 1415* 63 63 R0 OK?
524 2 05 3596544 3596544 1756 1416# 0 1 2307* 63 63 OK?
Error reading sector 5709312.
fp1-1b.txt:
Findpart, version 4.18.
Copyright Svend Olaf Mikkelsen, 2002.
Searches for partitions type 01, 04, 06, 07, 0B, 0C, 0E, 82, 83,
plus Fdisk F6 and Lilo sectors. Information based on bootsectors
is marked B. If the disk is larger than supported by BIOS, the
supported part of the disk is examined. Disks are numbered from 1.
OS: DOS 7.10
Disk: PM Cylinders: 1023 Heads: 64 Sectors: 63 MB: 2014
IDE CHS: 4092/16/63 CTM: 16383/16/63 IDE MB: 2014
User sectors: 4124736 Native sectors: 20015856
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
Fdisk F6 sector 0 1 1
Fdisk F6 sector 0 2 1
0 - 0B 4032 2108736 1029 1 0 1 523 63 63 B OK
524 1 0B 63 3596481 1756 524 1 1 1415* 63 63 R0 OK?
524 2 05 3596544 3596544 1756 1416# 0 1 2307* 63 63 524 OK?
0 - 0B 2112831 3596481 1756 524 1 1 1415 63 63 B OK?
-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 2062 4# 1712 17? 140 193 896
1 0 33 2058 4 2 2058 0 0 0 020209 341
524 1 33 3509 4 2 3509 0 0 0 010107 869
There were sectors, which could not be read.
Partitions according to partition tables on primary master:
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 4032 2108736 1029 1 0 1 523 63 63 OK OK
0 2 0F 2112768 14386176 7024 524 0 1 4091* 63 63 OK?
524 1 0B 63 3596481 1756 524 1 1 1415* 63 63 R0 OK?
524 2 05 3596544 3596544 1756 1416# 0 1 2307* 63 63 OK?
Error reading sector 5709312.
Thanks for all the effort you are going to.
Like Kyvas, I am seriously grateful.
But i have a bad feeling about this...
Svend Olaf Mikkelsen
>Findpart, version 4.18.
>Copyright Svend Olaf Mikkelsen, 2002.
>OS: DOS 7.10
>
>Disk: PM Cylinders: 1023 Heads: 64 Sectors: 63 MB: 2014
>IDE CHS: 4092/16/63 CTM: 16383/16/63 IDE MB: 2014
>User sectors: 4124736 Native sectors: 20015856
>Thanks for all the effort you are going to.
>Like Kyvas, I am seriously grateful.
>But i have a bad feeling about this...
>
>Nigel.
The "Max Address" of the disk has been set using some tool, and
Findpart does not overrule that.
The disk reports itself as 2014 MB, but it contains 20015856 sectors,
which is 9773 MB.
Which brand of disk is it? For an IBM disk, the size can be changed
using the "IBM Feature tool".
Do you know of having changed the disk size setting?
Note that this is a setting directly on the disk, not in the BIOS.
--
Svend Olaf
kh
It's a Fujitsu MPF3102AT. Officially 16383 cylinders, 16 heads, 63
sectors/track = 8.45 GB. (or 10.24 GB in LBA)
We didn't knowingly change the disk size setting. The BIOS auto-detects
it as 2111MB with 4092 cylinders, 16 heads, and 63 sectors. That's how
we run it.
If we try to edit the cylinders setting manually to 16383 the BIOS seems
to accept that and records the disk size as 8.45GB, but it won't boot
like that.
That's the way it's always been since we put this disk in 18 months ago.
BIOS thinks it's about 2 GB; Fdisk allowed us to create another four
virtual partitions of 1.7GB each; and later I used the BeOS Drive Setup
tool to convert the last one of those into a 1.2 GB BFS, 500MB of Linux
and 64 MB of Linux Swap.
Confused yet? I know I am. But it worked, until the QNX experience...
Svend Olaf Mikkelsen
>It's a Fujitsu MPF3102AT. Officially 16383 cylinders, 16 heads, 63
>sectors/track = 8.45 GB. (or 10.24 GB in LBA)
>
>We didn't knowingly change the disk size setting. The BIOS auto-detects
>it as 2111MB with 4092 cylinders, 16 heads, and 63 sectors. That's how
>we run it.
>
>If we try to edit the cylinders setting manually to 16383 the BIOS seems
>to accept that and records the disk size as 8.45GB, but it won't boot
>like that.
>
>That's the way it's always been since we put this disk in 18 months ago.
>BIOS thinks it's about 2 GB; Fdisk allowed us to create another four
>virtual partitions of 1.7GB each; and later I used the BeOS Drive Setup
>tool to convert the last one of those into a 1.2 GB BFS, 500MB of Linux
>and 64 MB of Linux Swap.
>
>Confused yet? I know I am. But it worked, until the QNX experience...
I will think about it.
Is it possible for you to describe the exact current jumper setting
for the disk? It would be a drawing like this:
x x x x
|
x x x x x
or this:
x x x x
| |
x x x x x
(fixed font assumed).
If it is too difficult to get access to see the jumper setting, we can
wait with this.
You say that the disk is auto detected by BIOS to 4092 cylinders, 16
heads and 63 sectors. Is this an Award BIOS, and is the current
setting "NORMAL", "LARGE" or "LBA" (if any of these). According to
Windows, the BIOS reports 1023 sectors, 64 heads, 63 sectors, which
would be the Award LBA setting.
Note that based on the current information, it cannot be completely
ruled out that you had overlapping partitions.
--
Svend Olaf
kh
Svend Olaf Mikkelsen wrote:
> Is it possible for you to describe the exact current jumper setting
> for the disk? It would be a drawing like this:
>
> x x x x
> |
> x x x x x
>
> or this:
>
> x x x x
> | |
> x x x x x
>
> (fixed font assumed).
>
> If it is too difficult to get access to see the jumper setting, we can
> wait with this.
>
> You say that the disk is auto detected by BIOS to 4092 cylinders, 16
> heads and 63 sectors. Is this an Award BIOS, and is the current
> setting "NORMAL", "LARGE" or "LBA" (if any of these). According to
> Windows, the BIOS reports 1023 sectors, 64 heads, 63 sectors, which
> would be the Award LBA setting.
>
> Note that based on the current information, it cannot be completely
> ruled out that you had overlapping partitions.
> --
> Svend Olaf
In fact it's this:
x x x x
| | |
x x x x x
That is, set up as large drive on legacy BIOS and "with slave present" .
The slave being the CD drive.
BIOS is:
Phoenix BIOS 4.04, Agoura release 1.20.
The Agoura part relates to a Y2k update.
It's a proprietary Packard-Bell motherboard so it may be an oddball
BIOS.
There is an LBA Mode setting. It is set Enabled.
Thanks again for your patience and interest. I know you don't have to do
this.
Nigel.
Svend Olaf Mikkelsen
>In fact it's this:
>
> x x x x
> | | |
> x x x x x
>That is, set up as large drive on legacy BIOS and "with slave present" .
>The slave being the CD drive.
>
>BIOS is:
>Phoenix BIOS 4.04, Agoura release 1.20.
>
>The Agoura part relates to a Y2k update.
>It's a proprietary Packard-Bell motherboard so it may be an oddball
>BIOS.
>There is an LBA Mode setting. It is set Enabled.
>
>Thanks again for your patience and interest. I know you don't have to do
>this.
>Nigel.
This exact jumper setting is not listed in the manual, but I expect it
to be the jumper setting for limiting the disk size to 2 GB, master
with slave present.
I would have expected the disk not to report its number of native
sectors with this jumper setting, but behavior may be different from
disk to disk. When native sectors are reported, the disk size can be
changed during boot, which allows large disks to be used in systems
where BIOS will lock if a large disk is present during BIOS boot.
Recent Ontrack Disk Manager versions, and as far as I know, recent
Linux kernels, are able to enable the entire disk size. I do not know
about BeOS.
To boot a kernel above 2 GB would require a disk manager or boot
manager that can enable the full size.
It would be nice to know the entire nature of the problem, including
partition locations, before any solution is attempted. I will think
about it, and may provide a Findpart version that can enable the
entire disk size during search.
--
Svend Olaf
Svend Olaf Mikkelsen
Mikkelsen) wrote:
>It would be nice to know the entire nature of the problem, including
>partition locations, before any solution is attempted. I will think
>about it, and may provide a Findpart version that can enable the
>entire disk size during search.
This Findpart version is ready, but I withhold it a little for
testing.
--
Svend Olaf
Svend Olaf Mikkelsen
>In fact it's this:
>
> x x x x
> | | |
> x x x x x
>That is, set up as large drive on legacy BIOS and "with slave present" .
>The slave being the CD drive.
>
>BIOS is:
>Phoenix BIOS 4.04, Agoura release 1.20.
>
>The Agoura part relates to a Y2k update.
>It's a proprietary Packard-Bell motherboard so it may be an oddball
>BIOS.
>There is an LBA Mode setting. It is set Enabled.
>
>Thanks again for your patience and interest. I know you don't have to do
>this.
>Nigel.
Reply no. 2.
To attempt to search for partitions on the entire primary master,
using a 64 heads translation, you can do this:
Download Findpart version 4.19 in
http://inet.uni2.dk/~svolaf/fpart419.zip
Download nigel2.bat in
http://inet.uni2.dk/~svolaf/nigel2.zip
Put findpart.exe version 4.19 and nigel2.bat on a boot floppy, boot to
the floppy, and run nigel2.bat, which contains:
set findpart=edit
findpart native pm
set findpart=
findpart pm fp1-2.txt heads 64
The disk size setting will be effective until power down or reboot,
depending on disk and system. I recommend that you power down after
the examination.
Post the content from fp1-2.txt.
Since it is unexpected for me that the disk would inform about the
real number of sectors if the size is limited by a jumper, I am not
quite certain that the Findpart native command will work.
Is it possible to manually enter the disk size in the BIOS in stead of
using auto detect?
--
Svend Olaf
kh
Svend Olaf Mikkelsen wrote:
> Reply no. 2.
>
> To attempt to search for partitions on the entire primary master,
> using a 64 heads translation, you can do this:
>
> Download Findpart version 4.19 in
>
> http://inet.uni2.dk/~svolaf/fpart419.zip
>
> Download nigel2.bat in
>
> http://inet.uni2.dk/~svolaf/nigel2.zip
>
> Put findpart.exe version 4.19 and nigel2.bat on a boot floppy, boot to
> the floppy, and run nigel2.bat, which contains:
>
> set findpart=edit
> findpart native pm
> set findpart=
> findpart pm fp1-2.txt heads 64
>
> The disk size setting will be effective until power down or reboot,
> depending on disk and system. I recommend that you power down after
> the examination.
>
> Post the content from fp1-2.txt.
>
> Since it is unexpected for me that the disk would inform about the
> real number of sectors if the size is limited by a jumper, I am not
> quite certain that the Findpart native command will work.
>
> Is it possible to manually enter the disk size in the BIOS in stead of
> using auto detect?
No I dont think so. As I said, I can enter the cylinders setting
manually to 16383, which brings the reported disk size in BIOS correctly
up to 8.45GB. The BIOS doesn't complain that it's an invalid setting,
but then the machine won't boot.
Anyway, here's the next report:
Findpart, version 4.19.
Copyright Svend Olaf Mikkelsen, 2002.
Searches for partitions type 01, 04, 06, 07, 0B, 0C, 0E, 82, 83,
plus Fdisk F6 and Lilo sectors. Information based on bootsectors
is marked B. If the disk is larger than supported by BIOS, the
supported part of the disk is examined. Disks are numbered from 1.
OS: DOS 7.10
Disk: PM Cylinders: 1023 Heads: 64 Sectors: 63 MB: 2014
IDE CHS: 4092/16/63 CTM: 16383/16/63 IDE MB: 2014
User sectors: 4124736 Native sectors: 20015856
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
Fdisk F6 sector 0 1 1
Fdisk F6 sector 0 2 1
0 - 0B 4032 2108736 1029 1 0 1 523 63 63 B OK
524 1 0B 63 3596481 1756 524 1 1 1415* 63 63 R0 OK?
524 2 05 3596544 3596544 1756 1416# 0 1 2307* 63 63 524 OK?
0 - 0B 2112831 3596481 1756 524 1 1 1415 63 63 B OK?
-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 2062 4# 1712 17? 140 193 896
1 0 33 2058 4 2 2058 0 0 0 020209 348
524 1 33 3509 4 2 3509 0 0 0 010107 870
There were sectors, which could not be read.
Partitions according to partition tables on primary master:
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 4032 2108736 1029 1 0 1 523 63 63 OK OK
0 2 0F 2112768 14386176 7024 524 0 1 4091* 63 63 OK?
524 1 0B 63 3596481 1756 524 1 1 1415* 63 63 R0 OK?
524 2 05 3596544 3596544 1756 1416# 0 1 2307* 63 63 OK?
Error reading sector 5709312.
I'm glad you're a man who likes a challenge :-)
Svend Olaf Mikkelsen
>> Is it possible to manually enter the disk size in the BIOS in stead of
>> using auto detect?
>
>No I dont think so. As I said, I can enter the cylinders setting
>manually to 16383, which brings the reported disk size in BIOS correctly
>up to 8.45GB. The BIOS doesn't complain that it's an invalid setting,
>but then the machine won't boot.
>
>Anyway, here's the next report:
>I'm glad you're a man who likes a challenge :-)
>Nigel.
I suggest you power off, and change the jumper setting from:
x x x x
| | |
x x x x x
to
x x x x
| |
x x x x x
(fixed font assumed)
Do not touch the BIOS setting, unless it is AUTO, which it should not
be. If you shall enter numbers manually now, then enter
4092 cylinders, 16 heads, 63 sectors
The "LBA mode control" should be enabled. This should make the BIOS
report the disk as 1023 cylinders, 64 heads, 63 sectors, which is
required by the current Windows boot sector.
Can you boot?
Of cause change it back, if you cannot.
If you can boot to floppy, delete the current output files, and run
nigel1.bat or nigel2.bat again.
In the above message you said that you could not boot if the cylinders
manually are set to 16383. It is no surprise, that DOS/Windows cannot
boot if the BIOS geometry heads/sectors translation i changed, but the
question is if there is a BIOS lock up, or if it is just the boot
sectors of the disk that assumes another setting.
Still do not write to D:
--
Svend Olaf
kh
I think I have managed to follow your instructions. I had to put the
jumper back on to boot Windows again, but with it off I was able to run
findpart from the floppy. The result is much more detailed than before:
Findpart, version 4.19.
Copyright Svend Olaf Mikkelsen, 2002.
Searches for partitions type 01, 04, 06, 07, 0B, 0C, 0E, 82, 83,
plus Fdisk F6 and Lilo sectors. Information based on bootsectors
is marked B. If the disk is larger than supported by BIOS, the
supported part of the disk is examined. Disks are numbered from 1.
OS: DOS 7.10
Disk: PM Cylinders: 1245 Heads: 255 Sectors: 63 MB: 9766
*** Simulated translation:
Disk: PM Cylinders: 4964 Heads: 64 Sectors: 63 MB: 9773
IDE CHS: 16383/16/63 CTM: 16383/16/63 IDE MB: 9773
User sectors: 20015856
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
Fdisk F6 sector 0 1 1
Fdisk F6 sector 0 2 1
0 - 0B 4032 2108736 1029 1 0 1 523 63 63 B OK
524 1 0B 63 3596481 1756 524 1 1 1415* 63 63 R0 OK
524 2 05 3596544 3596544 1756 1416# 0 1 2307* 63 63 524 OK
0 - 0B 2112831 3596481 1756 524 1 1 1415 63 63 B OK
1416 1 0B 63 3596481 1756 1416# 1 1 2307* 63 63 R0 OK
1416 2 05 7193088 3596544 1756 2308# 0 1 3199* 63 63 524 OK
0 - 0B 5709375 3596481 1756 1416 1 1 2307 63 63 B OK
2308 1 0B 63 3596481 1756 2308# 1 1 3199* 63 63 R0 OK
2308 2 05 10789632 133056 64 3200# 0 1 3232* 63 63 524 OK
0 - 0B 9305919 3596481 1756 2308 1 1 3199 63 63 B OK
3120 1 06 63 3919041 1913 780 1 1 1022 255 63 R0 NB
0 - 06 12579903 3919041 1913 3120 1 1 4091 63 63 B OK
Fdisk F6 sector 3121 0 1
Fdisk F6 sector 3121 1 1
3200 1 82 63 132993 64 3200# 1 1 3232* 63 63 OK
3200 2 05 10922688 1024128 500 3233# 0 1 3486* 63 63 524 OK
3233 1 83 63 1024065 500 3233# 1 1 3486* 63 63 OK OK
3233 2 05 11946816 2439360 1191 3487# 0 1 4091* 63 63 524 OK
3233 - 83 63 1024065 500 3233 1 1 3486 63 63 B5 OK
Lilo sector 3233 1 1
3487 1 EB 63 2439297 1191 3487# 1 1 4091* 63 63 OK OK
3487 - EB 63 2439297 1191 3487 1 1 4091 63 63 B OK
Fdisk F6 sector 4092 1 1
-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 2062 4# 1712 17? 140 193 896
1 0 33 2058 4 2 2058 0 0 0 020209 345
524 1 33 3509 4 2 3509 0 0 0 010107 870
1416 1 33 3509 4 2 3509 0 0 0 010204 1084
2308 1 33 3509 4 2 3509 0 0 0 010206 1119
3120 1 2 240 32* 512 240 0 0 0 000813 8
There were sectors, which could not be read.
Partitions according to partition tables on primary master:
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 4032 2108736 1029 1 0 1 523 63 63 OK OK
0 2 0F 2112768 14386176 7024 524 0 1 4091* 63 63 OK
524 1 0B 63 3596481 1756 524 1 1 1415* 63 63 R0 OK
524 2 05 3596544 3596544 1756 1416# 0 1 2307* 63 63 OK
1416 1 0B 63 3596481 1756 1416# 1 1 2307* 63 63 R0 OK
1416 2 05 7193088 3596544 1756 2308# 0 1 3199* 63 63 OK
2308 1 0B 63 3596481 1756 2308# 1 1 3199* 63 63 R0 OK
2308 2 05 10789632 133056 64 3200# 0 1 3232* 63 63 OK
3200 1 82 63 132993 64 3200# 1 1 3232* 63 63 OK
3200 2 05 10922688 1024128 500 3233# 0 1 3486* 63 63 OK
3233 1 83 63 1024065 500 3233# 1 1 3486* 63 63 OK OK
3233 2 05 11946816 2439360 1191 3487# 0 1 4091* 63 63 OK
3487 1 EB 63 2439297 1191 3487# 1 1 4091* 63 63 OK OK
Svend Olaf Mikkelsen
>I think I have managed to follow your instructions. I had to put the
>jumper back on to boot Windows again, but with it off I was able to run
>findpart from the floppy. The result is much more detailed than before:
In the original message you said that you still could run BeOS PE on
the E: drive.
The E: drive begins cylinder 1416, after the end of the disk according
to the jumper setting.
Can you still see the E: and F: partitions from Windows? Do not write
to them, but you can do
dir E: /s
and
dir F: /s
in a DOS box, and see if the content scrolls over the screen.
--
Svend Olaf
kh
Svend Olaf Mikkelsen wrote:
> In the original message you said that you still could run BeOS PE on
> the E: drive.
>
> The E: drive begins cylinder 1416, after the end of the disk according
> to the jumper setting.
>
> Can you still see the E: and F: partitions from Windows? Do not write
> to them, but you can do
>
> dir E: /s
>
> and
>
> dir F: /s
>
> in a DOS box, and see if the content scrolls over the screen.
> --
> Svend Olaf
Yes. I could always read and write all the FAT partitions (D: E: and F:)
when booted from a DOS floppy. I could see C: too. But I got some read
errors from C:, scandisk would not work on C: and Windows would not
boot.
As I said earlier , I've already fixed that - I reformatted C: and
reinstalled Windows. Now, Windows is fine. All the DOS partitions are
usable. Win can't see the Linux or BeOS partitions, of course, but then
it never could.
I still cant boot BeOS Pro (which has always been my main concern!)
The boot error message was "cannot mount
/dev/disk/ide/ata/0/master/0/0_9"
When I launch BeOS PE, (which, as you know, is a virtual BFS partition
residing in a 500MB windows file on E:) PE can see all partitions and
can still mount most of them. But it cannot mount the BeOS Pro
partition, giving the "bad file descriptor" message.
I guess I have a very unusual partition table.
Perhaps it will help you interpret the Findpart result if I tell you
that BeOS's Drive Setup program reports the partitions as follows:
DOS 32-bit FAT 1GB
Extended (LBA) 0.5kB
Empty 0.0kB
Empty 0.0kB
DOS 32-bit FAT 1.7GB
DOS 32-bit FAT 1.7GB
DOS 32-bit FAT 1.7GB
Linux Swap 64.9MB
Linux Native 500MB
Be File System 1.2GB
So it's just the last one behaving badly.
Also, I have have pinpointed the start of the BeOS partition using
Diskprobe, which looks at the raw data. It's at "Block 14059647 of
20015856" (512 byte blocks) or "Device Offset 7198539264". Is that
useful?
Let me say again how much I appreciate your help.
Please don't feel obliged to continue if it's too much trouble.
Nigel.
Svend Olaf Mikkelsen
I assume all this happened with the jumper set to 2 GB. If the
behavior of the disk is that it allows read and write above the area
reported by the default command for getting disk information, this can
work, but it does not seem to be a standard. Also it may cause
problems with programs and operating systems, that will not read and
write above the area reported as currently useable by the disk.
You mention:
>/dev/disk/ide/ata/0/master/0/0_9"
and in the first message:
>Bootman still ran but reported something like "cannot mount
>/dev/disk/ata/atapi/hda-9"
I do not know the significance of that, but the BeOS partition
actually is partition number 10 (first logical is number 5).
DOS 32-bit FAT 1.7GB 5
DOS 32-bit FAT 1.7GB 6
DOS 32-bit FAT 1.7GB 7
Linux Swap 64.9MB 8
Linux Native 500MB 9
Be File System 1.2GB 10
--
Svend Olaf
kh
Svend Olaf Mikkelsen wrote:
>
>
> I assume all this happened with the jumper set to 2 GB. If the
> behavior of the disk is that it allows read and write above the area
> reported by the default command for getting disk information, this can
> work, but it does not seem to be a standard. Also it may cause
> problems with programs and operating systems, that will not read and
> write above the area reported as currently useable by the disk.
>
> You mention:
>
> >/dev/disk/ide/ata/0/master/0/0_9"
>
> and in the first message:
>
> >Bootman still ran but reported something like "cannot mount
> >/dev/disk/ata/atapi/hda-9"
>
> I do not know the significance of that, but the BeOS partition
> actually is partition number 10 (first logical is number 5).
I think there's no inconsistency there. BeOS is counting from 0. It sees
the first partition (C:) as /dev/disk/ide/ata/0/master/0/0_0
Or have I confused you with that reference to an atapi drive? Sorry
about that; I was going on memory. I should have written
/dev/disk/ide/ata/0/master/0/0_9 in the first place.
Svend Olaf Mikkelsen
>I think there's no inconsistency there. BeOS is counting from 0. It sees
>the first partition (C:) as /dev/disk/ide/ata/0/master/0/0_0
>Or have I confused you with that reference to an atapi drive? Sorry
>about that; I was going on memory. I should have written
>/dev/disk/ide/ata/0/master/0/0_9 in the first place.
OK. I thought I checked. The BeOS Installer numbers from 1.
--
Svend Olaf
kh
Ah. I see how that could confuse. It is like the way BeOS deals with its
workspaces; F1 to F9 calls up workspaces 1 to 9, but if you access them
from the command line they are 0 to 8.
Svend Olaf Mikkelsen
>Ah. I see how that could confuse. It is like the way BeOS deals with its
>workspaces; F1 to F9 calls up workspaces 1 to 9, but if you access them
>from the command line they are 0 to 8.
All this has been concentrating on the possibility of a confusion with
disk size and partition tables, but of cause it is also a possibility
that the partition actually is damaged. Then other methods must be
used.
Previously in this thread there is a question from Jøhnny Fävòrítê. I
did not get to that yet, but searching a "bad file descriptor" I found
this message of his:
Subject: BFS fixer update
The url to the Google message is so long, that you may want to search
yourself. A maybe similar problem was solved.
If the internals of the partition are to be examined, the best thing
may be to work on a copy. Since the partition is 1191 MB it would be
possible to copy it to a file in another partition. Maybe a file also
can be attempted mounted. One had to be certain that the tool used for
copying gets the correct disk geometry.
Also from the Findpart output it is known that at least parts of the
superblock of the partition is correct, since the information used for
recognizing the partition is in the superblock.
--
Svend Olaf
Svend Olaf Mikkelsen
"Pavlov's Dog's Nosehole") <thi...@totally.fake.com> wrote:
>Hi Svend,
>
>Axel Dorfler and I are in the early stages of writing a GUI disk
>analysis and repair utility for BeOS. The ability to repair broken
>partition tables would be great and neither of us know very much about
>that. Would you be willing to supply expertise, source code, etc?
Hi. Feel free to ask me questions about partition tables for this
purpose if you are in doubt about something, but I cannot do active
work, have so many projects already.
--
Svend Olaf
kh
Svend Olaf Mikkelsen wrote:
> All this has been concentrating on the possibility of a confusion with
> disk size and partition tables, but of cause it is also a possibility
> that the partition actually is damaged. Then other methods must be
> used.
>
> Previously in this thread there is a question from Jřhnny Fävňrítę. I
> did not get to that yet, but searching a "bad file descriptor" I found
> this message of his:
>
> Subject: BFS fixer update
>
> The url to the Google message is so long, that you may want to search
> yourself. A maybe similar problem was solved.
>
> If the internals of the partition are to be examined, the best thing
> may be to work on a copy. Since the partition is 1191 MB it would be
> possible to copy it to a file in another partition. Maybe a file also
> can be attempted mounted. One had to be certain that the tool used for
> copying gets the correct disk geometry.
>
> Also from the Findpart output it is known that at least parts of the
> superblock of the partition is correct, since the information used for
> recognizing the partition is in the superblock.
> --
> Svend Olaf
Found that post from Jřhnny Fävňrítę. Interesting.
Jřhnny Fävňrítę, are you following this? Is overwriting my indexes with
zeroes a sensible tactic? How can it be done? And if the partition then
becomes mountable, what next to restore the indexes? Do they need to be
restored?
Otherwise, I remain in your hands, Svend Olaf. I'm thinking the one
thing left for me to do is reinitialise and lose my data.
If you have a way to write it all to a file on another partition and
then dump it all back on the reinitialised partition, let's try it.
kh
Um. But not right now. Isn't it about 2.30 in the morning where you
are??
Just when you can.
Nigel :-)
Svend Olaf Mikkelsen
>Found that post from Jřhnny Fävňrítę. Interesting.
>Jřhnny Fävňrítę, are you following this? Is overwriting my indexes with
>zeroes a sensible tactic? How can it be done? And if the partition then
>becomes mountable, what next to restore the indexes? Do they need to be
>restored?
>
>Otherwise, I remain in your hands, Svend Olaf. I'm thinking the one
>thing left for me to do is reinitialise and lose my data.
>
>If you have a way to write it all to a file on another partition and
>then dump it all back on the reinitialised partition, let's try it.
Is there a time pressure?
One way to copy the partition to a file would be to use the Linux dd
command. Initially, the first, say 1000, sectors could be copied. I do
not know if a BeOS tool can do it.
Normally my tools also could be used, but they will not read above the
area specified by the BIOS, or the disk Identify device command.
If the examination is read only, it of cause also can be done on the
original.
First step would be to interpret the values in the superblock. It is
not especially difficult, but it will take its time. I am considering
it.
Also file system documentation should be located. One interesting
thing is if backup superblocks are present, as in a Linux ext2
partition. Still, it is however not known if a possible damage is
limited to the superblock.
--
Svend Olaf
kh
I have done a small experiment using mkbfs on a floppy. I can create a
filesystem, put files in it, then run mkbfs over the floppy again. The
files remain undamaged.
Might this be a reasonable thing to try on my broken partition?
It might make it mountable again without upsetting any of the data...
Pros? Cons? anyone?
The command would be mkbfs 1024 /dev/disk/ide/ata/0/master/0/0_9 <Volume
Name>
I imagine I'd have to be damn sure the existing block size is 1024, or
change that figure accordingly.
How can I find out?
kh
kh wrote:
>
> I have done a small experiment using mkbfs on a floppy. I can create a
> filesystem, put files in it, then run mkbfs over the floppy again. The
> files remain undamaged.
> Might this be a reasonable thing to try on my broken partition?
oops. No.
I tried that again, just to be sure, and the files disappeared.
I won't go down that dead end...
nigel.
Svend Olaf Mikkelsen
>> I have done a small experiment using mkbfs on a floppy. I can create a
>> filesystem, put files in it, then run mkbfs over the floppy again. The
>> files remain undamaged.
>> Might this be a reasonable thing to try on my broken partition?
>
>oops. No.
>I tried that again, just to be sure, and the files disappeared.
>
>I won't go down that dead end...
>
>nigel.
Just a quick question right now, to help understand what happens
regarding the disk size:
Which drive letters can you see if you boot to a DOS floppy?
Is there an error message from:
dir c:
dir d:
dir e:
dir f:
Also from a Windows DOS box (not pure DOS), you can do using Findpart
(nigel3.bat):
set svolaf-1=4964
findpart getsect 1 3487 1 1 2 fp1-3.bin
set svolaf-1=
Depending on the Windows behavior, this may retrieve the first two
sectors from the BeOS partition, containing the boot sector and the
superblock. The environment variable is implemented for test usage,
and informs Findpart about the real number of cylinders.
You can see the content of fp1-3.bin using the command:
edit /64 fp1-3.bin
If the content of fp1-3.bin looks interesting for the case, you can
mail me the file.
Nigel3.bat is in
http://inet.uni2.dk/~svolaf/nigel3.zip
--
Svend Olaf
Svend Olaf Mikkelsen
>oops. No.
>I tried that again, just to be sure, and the files disappeared.
>
>I won't go down that dead end...
>
>nigel.
Reply no. 2. From mail I know that Findpart was able to retrieve the
boot sector and superblock with the cylinders environment variable
set.
Also it is possible to access all FAT partitions from pure DOS.
I took a preliminary look at the super block, and did not find
anything suspicious (fixed font assumed):
magic1 1111905073
fs_byte_order 1112098629
block_size 4096
block_shift 12
num_blocks low 304912
num_blocks high 0
used_blocks low 284563
used_blocks high 0
inode_size 4096
magic2 -586018767
blocks_per_ag 1
ag_shift 15 num_ags 10
flags 1129071950
log_blocks group 0
log_blocks start 11 log_blocks len 2048
log_start low 1077 log_start high 0
log_end low 1077 log_end high 0
magic3 364282638
root_dir group 8
root_dir start 0 root_dir len 1
indices group 0
indices start 2059 indices len 1
Compared to a 203 MB partition of mine:
magic1 1111905073
fs_byte_order 1112098629
block_size 1024
block_shift 10
num_blocks low 208813
num_blocks high 0
used_blocks low 102375
used_blocks high 0
inode_size 1024
magic2 -586018767
blocks_per_ag 1
ag_shift 13 num_ags 26
flags 1129071950
log_blocks group 0
log_blocks start 27 log_blocks len 2048
log_start low 768 log_start high 0
log_end low 768 log_end high 0
magic3 364282638
root_dir group 8
root_dir start 0 root_dir len 1
indices group 0
indices start 2075 indices len 1
The boot sector is exactly as mine, except that the LBA address is
14059647, which matches CHS 3487/1/1 in this system.
د mentioned that it would be possible to copy the partition to a file
using the Linux dd command. Since Findpart can read the area, it also
would be possible to make a copy to a file in a FAT partition using
Findpart. That would require that the work is done on the copy. Or
Linux cat and zip could be used to make a backup:
cat /dev/hda10 | zip hda10.zip -
Of cause assuming that the target partition has room for the file.
--
Svend Olaf
kh
Svend Olaf Mikkelsen wrote:
>
> د mentioned that it would be possible to copy the partition to a file
> using the Linux dd command. Since Findpart can read the area, it also
> would be possible to make a copy to a file in a FAT partition using
> Findpart. That would require that the work is done on the copy. Or
> Linux cat and zip could be used to make a backup:
>
> cat /dev/hda10 | zip hda10.zip -
>
> Of cause assuming that the target partition has room for the file.
> --
> Svend Olaf
I tried using zip to do a backup but it stopped only partially
completed, reporting AddrMarkNotFound at LBAsect=14077677 sector=18030
and at LBAsect=14077679 sector=18032.
So I looked at that area of the disk in Diskprobe and found that it
cannot read the three blocks 14077677, 14077678, and 14077679.
Zip under BeOS PE behaves in the same way as zip under Linux, stopping
at the same point of the disk. In fact, even the hunting noise the disk
makes at that point is exactly the same as it makes when trying to mount
the partition.
Perhaps this is the root of my problem - three bad blocks?
If so, perhaps Findpart and dd would also fail to make a backup.
Is there some way to mark the blocks as bad so they will be skipped?
Svend Olaf Mikkelsen
>I tried using zip to do a backup but it stopped only partially
>completed, reporting AddrMarkNotFound at LBAsect=14077677 sector=18030
>and at LBAsect=14077679 sector=18032.
>So I looked at that area of the disk in Diskprobe and found that it
>cannot read the three blocks 14077677, 14077678, and 14077679.
>
>Zip under BeOS PE behaves in the same way as zip under Linux, stopping
>at the same point of the disk. In fact, even the hunting noise the disk
>makes at that point is exactly the same as it makes when trying to mount
>the partition.
>
>Perhaps this is the root of my problem - three bad blocks?
>
>If so, perhaps Findpart and dd would also fail to make a backup.
>
>Is there some way to mark the blocks as bad so they will be skipped?
Looking at the Findpart output again, I see that it also said: "There
were sectors, which could not be read."
Sector 14077677 is about 9 MB into the partition.
Findpart can retrieve sectors without stopping at bad sectors. The
options can be seen by typing "findpart getsect". To retrieve the
first 32 MB would be in a Windows DOS box:
set svolaf-1=4964
findpart getsect 1 3487 1 1 65536 beos1.bin noheader badf6
or:
set svolaf-1=4964
findpart getsect 1 3487 1 1 65536 beos1.bin noheader bad00
This will put ascii 246 or ascii 0 characters in the file for sectors
that cannot be read.
This way there is no option to compress the file until after it is
read. To save the entire partition the number of sectors in the
command line would be 2439297.
Actually the bad sectors can be repaired, but then the content of the
sectors will be lost. It cannot be ruled out that it would be possible
to read the sectors and get most of the content correct. Currently my
tools cannot do that, but it could be made. Alternatively recovery
work can be done without the content from these three sectors. Which
could be located in the root directory, I do not know.
--
Svend Olaf
kh
Svend Olaf Mikkelsen wrote:
>
OK. Successfully used Findpart to make a back-up .bin file; looks
correct.
What next?
nigel.
Svend Olaf Mikkelsen
>OK. Successfully used Findpart to make a back-up .bin file; looks
>correct.
>What next?
>
>nigel.
From the entire partition? Meaning that you have a 1,248,920,064 bytes
file?
I guess I will make a partition the same size, turn the three sectors
that are known to be bad into bad sectors, and see what happens when I
try to mount the partition.
More later.
--
Svend Olaf
kh
Yes, it is the entire partition. I had to move some stuff between my
vfat partitions to make room for it - which means I am ignoring your
earlier advice not to write anything to these other partitions.
Is this OK? I assume we are no longer blaming a corrupt partition table.
Svend Olaf Mikkelsen
>Yes, it is the entire partition. I had to move some stuff between my
>vfat partitions to make room for it - which means I am ignoring your
>earlier advice not to write anything to these other partitions.
>
>Is this OK? I assume we are no longer blaming a corrupt partition table.
Yes, I guess that is OK, since it seems as your system works
regardless of the atypical disk size information.
As preparation for the case that it is decided to repair the bad
sectors, and to verify the location of the bad sectors, you can
download nigel4.bat and Findbad version 1.3 in:
http://inet.uni2.dk/~svolaf/nigel4.zip
and
http://inet.uni2.dk/~svolaf/fbad13.zip
Then run nigel4.bat, which contains:
set fpcyl-1=4964
findbad 1 3487 3510 fp1-4.txt
Post the content from fp1-4.txt.
The next thing I intend to do is as mentioned to create a partition of
the same size, turn the same three sectors into bad sectors, see the
message I get when mounting, repair the bad sectors, and then see if
it will mount, or what happens. It however will not be my today.
Do you have some backup possibility?
--
Svend Olaf
kh
Svend Olaf Mikkelsen wrote:
> As preparation for the case that it is decided to repair the bad
> sectors, and to verify the location of the bad sectors, you can
> download nigel4.bat and Findbad version 1.3 in:
>
> http://inet.uni2.dk/~svolaf/nigel4.zip
>
> and
>
> http://inet.uni2.dk/~svolaf/fbad13.zip
>
> Then run nigel4.bat, which contains:
>
> set fpcyl-1=4964
> findbad 1 3487 3510 fp1-4.txt
>
> Post the content from fp1-4.txt.
>
> The next thing I intend to do is as mentioned to create a partition of
> the same size, turn the same three sectors into bad sectors, see the
> message I get when mounting, repair the bad sectors, and then see if
> it will mount, or what happens. It however will not be my today.
>
> Do you have some backup possibility?
> --
> Svend Olaf
Here's the result of Findbad:
FindBad, version 1.3.
Copyright Svend Olaf Mikkelsen, 2002.
Searches for bad sectors.
OS: DOS 7.10 WINDOWS 4.10
Disk: 1 Cylinders: 4964 Heads: 64 Sectors: 63 MB: 9773
Start cylinder: 3487 End cylinder: 3510
-------- CHS ----- LBA Code
3491 31 13 14077677 0A
3491 31 14 14077678 0A
3491 31 15 14077679 0A
3491 32 56 14077783 0A
3491 32 57 14077784 0A
3491 32 58 14077785 0A
3491 33 10 14077800 0A
3491 33 11 14077801 0A
3491 33 12 14077802 0A
3491 33 13 14077803 0A
3491 33 24 14077814 0A
3491 33 25 14077815 0A
3491 33 26 14077816 0A
3491 33 33 14077823 0A
3491 33 34 14077824 0A
3491 33 35 14077825 0A
3491 33 36 14077826 0A
3491 33 51 14077841 0A
3491 33 52 14077842 0A
3491 33 53 14077843 0A
3491 33 54 14077844 0A
3491 35 8 14077924 0A
3491 35 9 14077925 0A
3491 35 10 14077926 0A
3491 35 62 14077978 0A
3491 35 63 14077979 0A
3491 36 1 14077980 0A
3491 36 8 14077987 0A
3491 36 9 14077988 0A
3491 36 10 14077989 0A
3491 36 11 14077990 0A
3491 36 26 14078005 0A
3491 36 27 14078006 0A
3491 36 28 14078007 0A
3491 36 29 14078008 0A
3491 38 23 14078128 0A
3491 38 24 14078129 0A
3491 38 25 14078130 0A
3491 38 26 14078131 0A
3491 38 46 14078151 0A
3491 38 47 14078152 0A
3491 38 48 14078153 0A
3491 38 49 14078154 0A
Current cylinder: 3500
Which looks discouraging to me.
Nigel.
Svend Olaf Mikkelsen
>-------- CHS ----- LBA Code
> 3491 31 13 14077677 0A
> 3491 31 14 14077678 0A
> 3491 31 15 14077679 0A
> 3491 32 56 14077783 0A
> 3491 32 57 14077784 0A
> 3491 32 58 14077785 0A
> 3491 33 10 14077800 0A
cut
>Which looks discouraging to me.
>Nigel.
The first three are the same that you mentioned, so the situation may
be kind of stable. Assuming the number of bad sectors is constant, it
is not that many bad sectors. Only a limited area was searched, but in
this area the sectors are limited to cylinder 3491.
Nothing is known until the case is finished.
--
Svend Olaf
Svend Olaf Mikkelsen
Reply no. 2.
A few days ago I made a BeOS partition of the same size as yours on a
disk with a 64 heads translation, and turned the same sectors into bad
sectors. (It was at cylinder 487 in stead of 3487 since the disk was
smaller).
The partition would mount without error messages. This can be because
my file structure was different (it was just a new installation), or
because of some other difference. As example it is not examined if you
have more bad sectors later in the partition.
I also tried to mount a container file with another name than
\beos\image.be by first mounting the parent partition and then the
container, but it did not work. I am thinking of the copy of the
partition you have. If you have no other BeOS container in the same
partition, it may be possible to change the name to \beos\image.be
using the DOS "move command". It then would be possible that BeOS PE
would attempt to mount the file.
I am not certain about next step. One possibility of cause would be a
dedicated BeOS recovery tool that can copy files to another partition.
If I was to make such a thing, it would be a DOS program, that could
copy files to a FAT partition. It may not take that long time to
initially make a simple tool that can copy single files. At the moment
however I am busy making a similar thing for another file system.
Note that if more search for bad sectors should be done, it may be an
advantage to attempt to do it in pure DOS, since fewer retry attempts
then will me made. Currently I however do not suggest that search.
You did not say if you have backup possibility. If there is a problem
with the disk, it would be nice to get as example a backup from the
copy of partition. Bad sectors however can be the result of some
previous intermittent problem, it is not necessarily a problem with
the disk.
--
Svend Olaf
kh
Svend Olaf Mikkelsen wrote:
> Reply no. 2.
>
> A few days ago I made a BeOS partition of the same size as yours on a
> disk with a 64 heads translation, and turned the same sectors into bad
> sectors. (It was at cylinder 487 in stead of 3487 since the disk was
> smaller).
>
> The partition would mount without error messages. This can be because
> my file structure was different (it was just a new installation), or
> because of some other difference. As example it is not examined if you
> have more bad sectors later in the partition.
>
> I also tried to mount a container file with another name than
> \beos\image.be by first mounting the parent partition and then the
> container, but it did not work. I am thinking of the copy of the
> partition you have. If you have no other BeOS container in the same
> partition, it may be possible to change the name to \beos\image.be
> using the DOS "move command". It then would be possible that BeOS PE
> would attempt to mount the file.
No luck. I've tried several different ways to boot the copy of the BeOS
partition, or mount it from within BeOS PE. The best I get is that "bad
file descriptor" message.
>
> I am not certain about next step. One possibility of cause would be a
> dedicated BeOS recovery tool that can copy files to another partition.
> If I was to make such a thing, it would be a DOS program, that could
> copy files to a FAT partition. It may not take that long time to
> initially make a simple tool that can copy single files. At the moment
> however I am busy making a similar thing for another file system.
>
> Note that if more search for bad sectors should be done, it may be an
> advantage to attempt to do it in pure DOS, since fewer retry attempts
> then will me made. Currently I however do not suggest that search.
>
> You did not say if you have backup possibility. If there is a problem
> with the disk, it would be nice to get as example a backup from the
> copy of partition. Bad sectors however can be the result of some
> previous intermittent problem, it is not necessarily a problem with
> the disk.
>
> --
> Svend Olaf
Do you mean make a backup to CD or something?
No, I cant. I don't think I even have room on any FAT partition to make
another copy on the local hard drive.