From owner-freebsd-questions@FreeBSD.ORG Fri Jun 27 20:36:54 2014 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64405736 for ; Fri, 27 Jun 2014 20:36:54 +0000 (UTC) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F306C29F8 for ; Fri, 27 Jun 2014 20:36:53 +0000 (UTC) Received: from r56.edvax.de (port-92-195-69-249.dynamic.qsc.de [92.195.69.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx02.qsc.de (Postfix) with ESMTPS id 132EA27673; Fri, 27 Jun 2014 22:36:50 +0200 (CEST) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id s5RKao3Y002351; Fri, 27 Jun 2014 22:36:50 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Fri, 27 Jun 2014 22:36:50 +0200 From: Polytropon To: paul beard Subject: Re: what should uname -v be telling me here? Message-Id: <20140627223650.25210a53.freebsd@edvax.de> In-Reply-To: References: <44lhsi5ugm.fsf@be-well.ilk.org> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: questions@freebsd.org, Lowell Gilbert X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 20:36:54 -0000 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, ...