Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 Jan 1999 19:49:06 +0200 (SAT)
From:      Robert Nordier <rnordier@nordier.com>
To:        owensc@enc.edu (Charles Owens)
Cc:        root@jules.res.cmu.edu, stable@FreeBSD.ORG, kingsled@enc.edu, rnordier@nordier.com
Subject:   Re: disk problem at bootup... (me too!)
Message-ID:  <199901311749.TAA04694@ceia.nordier.com>
In-Reply-To: <36B45C54.82BF98BE@enc.edu> from Charles Owens at "Jan 31, 99 08:36:21 am"

next in thread | previous in thread | raw e-mail | index | archive | help
Charles Owens wrote:

> Greg,
> 
> I believe I'm having the same problem that you are.  I had my system
> running 2.2.7 just fine.  I did a clean reinstall of 3.0-RELEASE:
> during the "fdisk" phase I said to my buddy, "I'm pretty sure that it
> will _not_ work to make a bootable drive dangerously dedicated."  Rather
> than just go with what I has worked for years I decided to test my
> assertion by attempting to dangerously dedicate the disk (duh :-).  As
> I'd expected I got an error during the commit phase.  So I went back to
> the fdisk screen, redid things normally, and completed the install.

You can boot from an unsliced ("dangerously dedicated") disk; but
it's probably best to slice your disks unless you've got really good
reasons not to.

In particular, unless you're starting with a completely blank disk
(where sysinstall detects no slices and no partitions whatever), you
don't want to go changing between sliced and unsliced.  (However, a
blank disk may be what you meant by a "clean reinstall".)

> 
> When attempting the first boot I get a "missing operating system"
> error.  I can get into the system by booting from the install floppy and
> typing "0:da(0,a)/boot/loader" at the first boot prompt.

A "Missing operating system" error generally means that the OS-
specific bootstrap can't be found by the mbr code.

Anyway, the error at least indicates you have working mbr code
installed (see below).

> 
> So I'm thinking that my messing around with dangerously dedicated mode
> must have screwed something up.  Thus far I've done this to attempt to
> fix it:
> 
> -- Booted the install disk.  When to fdisk screen and did the normal
> thing I'd do during and install:  Use all disk (_not_ dangerously
> dedicated), Set FBSD partition bootable.  Then I hit 'W' to write it
> out.  Didn't help.
> 
> -- From the booted system (getting in via the on-floppy boot sector) I
> typed both:
>             disklabel -B da0s1
>      and  disklabel -B da0
> I'm not quite sure if this was right, but it helped me as much as it
> helped you.

Both of those were reasonable things to try.
 
> In digging through the mail archives I've found some folks that seem to
> have had this problem in the past.  Several people suggested that the
> installing DOS MBR via the DOS "fdisk /mbr" command would fix things.
> Isn't this what the above disklabel commands are supposed to do?  What
> _is_ the correct way to do this from FreeBSD?  Not that I'm _entirely_
> opposed to doing it with the DOS utility.  ;-)  (I'm going to give this
> a try Monday.)

An "fdisk /mbr" will rewrite the mbr code (rather than data).  The
easiest way to do the same thing from FreeBSD is to use the recent
fdisk -b option, but this is available only in -current.  You can
do the same thing using sysinstall, by instructing it to use a
"Standard MBR", but the process is more involved and error-prone.

I think the fdisk -b option should probably be back-ported to -stable.

However, an "fdisk /mbr" or equivalent is unlikely to help you at
this stage (see above).

> 
> Someone else pointed out that some motherboards have a BIOS setting by
> which the motherboard will prevent the writing of the boot sector...
> which can mess up FreeBSD install.  Good point... I don't think that's
> my problem here though.

Yes, apparently some BIOSes do this.  Unless one's using Microsoft
OSes exclusively, though, this is probably more trouble than it's
worth.

> 
> I must admit I'm a bit unclear on how this is all arranged.  Are there
> multiple "boot sectors" that get processed during boot up?  One "MBR"
> for the whole disk and then another boot record that lives on each
> bootable slice?

The mbr will load sector 0 of the slice.  If this has the correct
signature (the last two bytes are 0x55, 0xaa), control will be
passed to it.  What happens after that is OS-specific (and maybe
bootstrap-specific).  The usual FreeBSD behavior is to load another
14 or 15 consecutive sectors following sector 0 of the slice.
Together, these 15 or 16 sectors comprise boot1, the disk label,
and boot2.  Control is passed (blindly) from boot1 to boot2.  And
boot2 looks in the root directory for /boot/loader, and loads and
passes control to that, if found.

As far as your problem is concerned, I don't think there's a
substitute for actually looking at the disk to find out what has
ended up there.

If you want to send me the output of

    dd if=/dev/rda0 size=512 count=80 | hexdump -C

together with fdisk and disklabel output, I can probably tell you
where things are going wrong.

--
Robert Nordier

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901311749.TAA04694>