--On 09 June 2005 00:42 -0300, Luciano ES wrote:
First off, the boot error message:
Loading...
probing: pc0 com0 com1 apm mem [508K 254M a20=on]
disk: fd0 hd0+* hd1+* hd2*
OpenBSD/i386 BOOT 2.06
open(hd0a:/etc/boot.conf): Invalid argument
boot>
booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
failed(22). will try /obsd
<http://www.openbsd.org/faq/faq14.html#Boot386>
ok, * means that no BSD disklabel was found, which isn't a surprise if
the fdisk partition was somehow lost as there wouldn't be anywhere to
look for a disklabel. This is also reported in the dmesg;
http://tinyurl.com/7wwdg
wd0: no disk label
wd1: no disk label
wd2: no disk label
If the label isn't present, you'd expect to have a default label
generated from the fdisk partitions (but of course this has just the
one 'container' BSD partition, not each individual partitions with the
filesystems for / /usr /var etc), which fits with the disklabels you
gave.
How does 'fdisk wd0' look? Have you used any disk tools on the drive
from another OS which might have changed the MBR? Are you loading the
OpenBSD boot directly from MBR, or is there some other bootmanager in
the way? Any chance some program might have decided that the OpenBSD
partition is bogus because it doesn't know the type, and decides to
change it?
# /dev/rwd0c:
type: ESDI
disk: ESDI/IDE disk
label: ST3120022A
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 16383
total sectors: 234441648
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0# microseconds
track-to-track seek: 0# microseconds
drivedata: 0
# size offset fstype [fsize bsize cpg]
a: 1024065 63 4.2BSD 2048 16384 328 # Cyl
0*- 1015
b: 1024128 1024128 swap # Cyl
1016 - 2031
c: 234441648 0 unused 0 0 # Cyl
0 -232580
d: 1024128 2048256 4.2BSD 2048 16384 328 # Cyl
2032 - 3047
e: 9625392 3072384 4.2BSD 2048 16384 328 # Cyl
3048 - 12596
f: 204624 12697776 4.2BSD 2048 16384 204 # Cyl
12597 - 12799
g: 2054115 12902400 4.2BSD 2048 16384 328 # Cyl
12800 - 14837*
i: 1847475 14956515 MSDOS # Cyl
14837*- 16670*
j: 32004 16804116 ext2fs # Cyl
16670*- 16702*
k: 2618532 16836183 unknown # Cyl
16702*- 19300*
l: 10361862 19454778 ext2fs # Cyl
19300*- 29579
m: 10361862 29816703 ext2fs # Cyl
29580*- 39859*
n: 10329732 40178628 ext2fs # Cyl
39859*- 50107*
o: 31535532 50508423 MSDOS # Cyl
50107*- 81392*
p: 25189857 82044018 MSDOS # Cyl
81392*-106382*
-and-
16 partitions:
# size offset fstype [fsize bsize cpg]
c: 234441648 0 unused 0 0 # Cyl
0 -232580
i: 1847475 14956515 MSDOS # Cyl
14837*- 16670*
j: 14956452 63 unknown # Cyl
0*- 14837*
k: 32004 16804116 ext2fs # Cyl
16670*- 16702*
l: 2618532 16836183 unknown # Cyl
16702*- 19300*
m: 10361862 19454778 ext2fs # Cyl
19300*- 29579
n: 10361862 29816703 ext2fs # Cyl
29580*- 39859*
o: 10329732 40178628 ext2fs # Cyl
39859*- 50107*
p: 31535532 50508423 MSDOS # Cyl
50107*- 81392*
The listed partitions cover <50% of the HD, so I guess there are
probably other partitions. disklabel only supports partitions a-p
(which is why the MSDOS partition disappears when the others are moved
to the next letter when the unknown OpenBSD partition becomes 'j'). I
don't know if any problems are exposed by using so many partitions
(other than not being able to mount some of them from OpenBSD), but
when you deal with corner cases, there's more chance of finding
problems.
This tutorial makes several complaints about OpenBSD's fdisk.
And, in my own experience, it was clearly difficult not to lose
the slice's ID every now and then with no apparent cause.
I haven't really found that myself, but the most I've done is dual-boot
OpenBSD and Windows on one box with two fdisk partitions using ntldr
(as described in the faq), so it's a far less complex setup. Never seen
a partition-type change with OpenBSD tools except when deliberately
doing so with fdisk...
