Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Nov 2012 07:31:29 +0100
From:      Andre Albsmeier <>
To:        jb <>
Cc:        "" <>
Subject:   Re: Booting 2nd(!) FreeBSD installation sitting on same disk
Message-ID:  <20121105063129.GA86734@bali>
In-Reply-To: <>
References:  <20121103165421.GA76199@bali> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sat, 03-Nov-2012 at 23:34:48 +0100, jb wrote:
> Andre Albsmeier <Andre.Albsmeier <at>> writes:
> > ... 
> > However, when pressing F3, the system of slice 2(!) is      
> > loaded. This is due to the fact that boot1 always loads
> > the first active FreeBSD slice ;-(.
> > ... 
> > Is there no chance to actually honour the fact that F3 was
> > pressed and boot from slice 3 without updating the MBR before?
> I do not know the story of active slice in FreeBSD, but I know that neither
> Windows nor Linux require active partitions (in their jargon) to boot from any
> more.

If course FreeBSD doesn't rely on being started from an active
slice. Otherwise playing with currdev in loader wouldn't work.
It is just boot1 which causes the problem since it always searches
the MBR partition (slice) table for the first active FreeBSD slice
and if it doesn't find one it starts over again and searches for
any FreeBSD slice.

The problem is that boot1 doesn't get the information which F-key
was pressed in boot0 directly. It does only in case you allow a
write-back of the MBR using -o update with boot0cfg.

I made an ugly hack for this by patching boot1 code of slice 3
in a way that it actually searches for IN(!)active partitions in
its first pass:

--- sys/boot/i386/boot2/boot1.S.ORI	2012-09-23 22:07:16.000000000 +0200
+++ sys/boot/i386/boot2/boot1.S	2012-11-05 07:16:29.000000000 +0100
@@ -151,7 +151,11 @@
 		jne main.3			# No
 		jcxz main.5			# If second pass
 		testb $0x80,(%si)		# Active?
+		jz main.5			# No
 		jnz main.5			# Yes
 main.3: 	add $0x10,%si	 		# Next entry
 		incb %dh			# Partition
 		cmpb $0x1+PRT_NUM,%dh		# In table?

Since this code only sits in boot1 of slice 3 it just applies to
slice 3.

The proper fix would be to pass the information about the key pressed
in boot0 to boot1 directly via registers of by whatever means...


Want to link to this message? Use this URL: <>