what should uname -v be telling me here?

[Polytropon]

On Fri, 27 Jun 2014 12:54:58 -0700, paul beard wrote:
> Well, after some headscratching and physical inspection, it looks like
> this machine is booting and running from the same physical disk. It
> appears I never understood that you could boot from a different device
> than the one that was mounted and holding all your data *without
> realizing it* or being able to find out (ideally sysctl would reveal
> the device that the running kernel was pulled from: if it does, I
> can't make it out). It seems there should be some way to specify a
> boot device without futzing around in the BIOS or learn what device
> has been defined. dmesg doesn't even reveal that, as far as I can
> tell. It looks like boot.config might do some or all of what I expect.

It's typical for PCs to boot the first device that has
the "boot flag" set. The _order_ of which devices are
recognized depends on the computer, and it can even be
altered with BIOS settings which one is "the first disk".

The kernel loader reports like this:

Loading /boot/defaults/loader.conf
/boot/kernel/kernel
[...]
Booting [/boot/kernel/kernel]...

And the kernel's message is then this:

Trying to mount root from ufs:/dev/ad4s1a

In my case, ad4s1a is the first disk where are a bootable
file system is present.

By adding boot code to a partition, the chain is started
after the BIOS commits control. See "man boot" for details.
This boot code can specify any disk, also a different one
than it's sitting on itself. The above message corresponds
to "0:ad(4,1,a)/boot/loader", as it's the 0th BIOS drive, but
the unit 4 to the ad (ata disk) driver; 1st slice, 1st ('a')
partition.

The loader, configured in /boot/loader.conf, can also set
certain things, for example those:

#root_disk_unit="0"             # Force the root disk unit number
#rootdev="disk1s1a"             # Set the root filesystem

As you can see, this refers to BIOS unit numbering, not to
the device driver's identification. The root file system is
usually the one that contains /boot and therefore the kernel.

Later on, this details are "lost", for example if you query

	% sysctl kern.bootfile
	kern.bootfile: /boot/kernel/kernel

the answer will already be "translated" to file system tree
level: You need to find out where /boot resides (in my case,
it's on ad4s1a, which is mounted at /) to identify the boot
device (or to be precise, the device the kernel has been read
from).



> I also don't see how I can remove or rewrite just the MBR/bootsector
> on disk other than the active disk.

You can do this with gpart, but also with the old-fasioned
tools fdisk. Note that you might have to modify further parts
of the boot chain, see "man boot0cfg" for details.



> If I could do that I could be
> reasonably sure I was booting and running from the disk I think I am.

Can you capture console output prior to the kernel? It should
provide that information.



> It may be time to stop pretending I know how any of this stuff
> actually works.

In this case, read "man boot", it explains the procedure and
the parts involved (and how to configure them). :-)



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...