[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: about harddisk installing!
"Qiwen Wei[EXCH:DATA:NCE]" <QiwenW@nortelnce.com> writes:
> Thanks Marcus Watts!!!
>
> I do like you say above this time, but still cannot install from harddisk.
>
> like before ,patitions as below:
> > 0 0C Win95 FAT32L
> > 1 0F Extended LBA
> > 2 A6 OpenBSD
> > 3 00 unused
> then q, i make some parts and mount like this:
> a --> /
> b --> /swap
> d --> /var
> e --> /home
> f --> /usr
> then done, config network,ok
> then done, type ! to shell
> mkdir windows
> mount -r /dev/wd0i /windows ----------> mount_ffs : /dev/wd0i on
> /windows,device not configured.
> mount -r -t msdos /dev/wd0i /windows ------------->
> mount_ffs : /dev/wd0i on /windows,device not configured.
>
> what happened?
>
> then ^ D, select install from local harddisk,select wd0,there are only
> a,b,c,d,e,f
>
> i think open should mount other OS automaticly,otherwise ,what's means
> installing from harddisk.
>
> any help,thanks.
Ok, I hadn't looked at the install script closely enough. There
are actually two parts where it talks about reading the local
filesystem; a part in "install.sh" where it says "You appear to
be running diskless", and goes on to ask directly for a pathname,
and another part in "install.sub" where it asks for
"Install from (f)tp, (h)ttp," ..." or local (d)isk?".
Somehow I assumed the former was possible (apparently this
is only true if root was an NFS filesystem; not likely using
a boot floppy), in fact I think you must be talking about the
latter. It would be helpful if you could reproduce prompts and
error messages more exactly, the phraes "local harddisk" does
not in fact appear anywhere in the install scripts.
In any event, I had thought before that you could mount the
device and simply give it a pathname at the appropriate place.
Now I agree you need to see more partitions.
The error you saw was probably "Device not Configured.". This
is error 6 = ENXIO. In this case this was most likely produced
by bounds checking in dev/ata/wd.c wdopen(). Evidently you really
and truely do not have a "wd0i". You should not have needed to say
"mount -t msdos" - if you don't specify a type, mount is normally
able to infer this from the partition information -- in this case,
the "0C = Win95 FAT32L" that you saw when running fdisk. All this
will only work when you have your disk label stuff right, which
is clearly not yet the case.
Basically, you need to get your OpenBSD label to include the
extra foreign OSes that you have defined in your MBR. The
install script is helpfully running 2 commands to help you
do this,
fdisk --sets up MBR partitions
disklabel --sets up the OpenBSD label.
apparently your MBR is already setup. But you should run
it again, and write down all the numbers for the block offsets
for your MBR partitions.
Er, but as long as I'm on the MBR, there are two other things
you *should* know:
(1) your OpenBSD partition needs to be less than 8 G into
the disk. In fact, the entire root partition must be
less than 8G in -- so that's really 8G - sizeof(root).
There's a non-obvious note in the README that says this;
hopefully you already knew this. The install stuff
doesn't check for this, and will cheerfully install
openbsd where it can't boot.
(2) You have a non-OpenBSD OS as the first MBR entry. That's ok,
but if it's not the active partition, and you want to boot
it, you better have somebody else's boot manager installed
too. If you install OpenBSD as the first and active MBR
entry, and other entries after that, you can boot OpenBSD normally,
or use the OpenBSD boot as your boot manager. That is,
from the boot> prompt, you can boot the other OS with
"machine boot hd0b" "machine boot hd0c", "machine boot hd0d".
"machine boot hd0a" is treated the same as "machine boot hd0"
and means boot the active partition, not the first partition.
[
if I remember right, this little gem is in
/usr/src/sys/arch/i386/stand/libsa/cmd_i386.c
Xboot() -- 2 if stmts that read ..."part > 0"...
I think should read "part >= 0". I can make diffs;
my efforts to communicate this to the /boot
author foundered on communications difficulties...
If you fix this, don't forget "installboot" to test.
]
There are also potential APM issues with using OpenBSD boot
as your boot manager; it didn't affect Windows XP for me
(but that may have used ACPI); it does affect DOS (which is
not APM aware.) And most likely OpenBSD boot can't boot
anything past 8G.
For disk label, *in addition* to the a=root, b=swap, you also
need to make a partition "i" that points to your Windows 95 setup.
I have a laptop with Windows XP installed -- here's what I had/have:
initial fdisk setup:
Disk: wd0 geometry: 7752/240/63 [117210240 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
----
*0: 07 0 1 1 - 7571 239 63 [ 63: 114488577 ] HPFS/QNX/AUX
1: 1C 7572 0 1 - 7751 239 63 [ 114488640: 2721600 ] Thinkpad Rec
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
[ Apparently fdisk thinks that "ntfs" is "HPFS". Weird, huh? ]
Final fdisk setup:
Disk: wd0 geometry: 7752/240/63 [117210240 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
----
0: 07 0 1 1 - 948 239 63 [ 63: 14348817 ] HPFS/QNX/AUX
1: 1C 7572 0 1 - 7751 239 63 [ 114488640: 2721600 ] Thinkpad Rec
*2: 00 949 0 1 - 7571 239 63 [ 14348880: 100139760 ] OpenBSD
3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
[ Note that my NTFS filesystem is now a lot smaller. This means I
(later on) had to reinstall XP. It was sort of fascinating
to watch the Thinkpad Recovery partition do this. ]
initial disklabel output:
...
16 partitions:
# size offset fstab [fsize bsize cpg]
c: 117210240 0 unused 0 0 # ( Cyl. 0 - 116279)
i: 14348817 63 unknown # (Cyl. 0*-113579)
j: 2721600 114488640 unknown # (Cyl. 113580 - 116279)
Note that this initial disk label already has "i" == ntfs,
and "j" == "Thinkpad recovery". This is actually done by magic inside
the kernel, when it constructed a default label inside the kernel.
You should probably see "msdos" instead of "unknown" for your FAT32L filesystem.
Final disk label:
16 partitions:
# size offset fstab [fsize bsize cpg]
a: 204624 14348880 4.2BSD 1024 8192 16 # /
b: 2097648 14553504 swap
c: 117210240 0 unused 0 0 # ( Cyl. 0 - 116279)
d: 204624 16651152 4.2BSD 1024 8192 16 # /var
e: 1024128 16855776 4.2BSD 1024 8192 16 # /usr
f: 96199488 17879904 4.2BSD 1024 8192 16 # /home
g: 409248 114079392 4.2BSD 1024 8192 16 # /usr/X11R6
i: 14348817 63 unknown # (Cyl. 0*-113579)
j: 2721600 114488640 unknown # (Cyl. 113580 - 116279)
[ These are, by the way, not the best sizes; /usr was too small for
/usr/local, which is where ports like KDE go... ]
I have not had good luck creating those foreign OS partitions inside of
disklabel. The problem is that disklabel insists that offset,size on
any partitions you create are contained entirely within the OpenBSD MBR
partition. Actually, it may be possible to use 'b' (set bounds) to get
around this, but I can't vouch that this will in fact work. It is
probably best to make sure that disklabel gets these automatically from
the system, and that you not delete these once created. If you already
have a valid openBSD label, you'll likely have to wipe it to make this
happen, and you may have to do some experimenting too, to find the
right combination such that everything works right. Hm; maybe 'b'
bounds is your best bet. Anyways, you might try one or more of the
following:
disklabel wd0
z - in disklabel - zero out the partition boot record.
# (try writing out 0's, exit disklabel, rerun disklabel.)
w
q
disklabel -c wd0
# clear system's in-core disk label, use what's on disk.
Or, in disklabel, try:
D get default partition table
Or I suppose this *ought* to work:
dd </dev/zero >/dev/wd0a bs=1k count=1
disklabel -c wd0
In any event, until you can get your OpenBSD label to have an 'i'
partition that matches your existing Windows MBR partition in size &
offset, I don't believe you'll have much luck mounting it. Once you get this
right, you *should* see wd0i as as a choice under "local (d)isk", and
it should just invisibly mount and work.
For what it's worth, I don't think "open" should mount any filesystems
(this is why there's a separate "mount" syscall) and I don't think the
install scripts should be mounting existing filesystems unless and
until you ask it to use them.
-Marcus Watts