From owner-freebsd-hackers Sun Jul 2 00:19:00 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA19267 for hackers-outgoing; Sun, 2 Jul 1995 00:19:00 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA19252 ; Sun, 2 Jul 1995 00:18:48 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA03775; Sun, 2 Jul 1995 17:09:37 +1000 Date: Sun, 2 Jul 1995 17:09:37 +1000 From: Bruce Evans Message-Id: <199507020709.RAA03775@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, paul@freebsd.org Subject: Re: Announcing 2.0.5-950622-SNAP Sender: hackers-owner@freebsd.org Precedence: bulk >> > > I'm curious why dual boot is a "no and possibly never"? >> >> > Just the amount of work involved is all. You can't have 2 FreeBSD >> > slices on a disk and boot from the second one as the boot code is too >> > stupid to understand that you might want to boot from something other >> > than the first one it finds. >> >> Except for the space constraints, it should be possible to extent the >> boot syntax from: >> >> driver(unit,part)/filename >> >> to >> >> driver(unit,[slice,]part)/filename There is also some work to do in sysinstall: setting up different fstabs for different root partitions and perhaps managing N root partitions at once. >I don't understand the problem? You just boot the partition that has the >active flag set. Our boot process doesn't do this properly but it's That would always boot my DOS partition. Some OS's will only boot from partitions with the active flag set, so some boot selectors rewrite the MBR to change the active flag, but I don't/won't use such an OS or boot selector. Anyway, the boot selector belongs in the FreeBSD bootstrap. We already have this for the first FreeBSD slice on all drives. All that is missing is selection of the slice (including non-FreeBSD ones) and changing of the default selection. >not conceptually difficult. Last time I looked it wasn't the bootblocks >that were the problem but the disk drivers, since they built fake >disklabels by searching for the first FreeBSD partition. I haven't looked >at that area of the code since diskslices came online so I'm not >sure what happens now. - Old drivers search for the first FreeBSD slice but don't build fake disk labels (the label is irrelevant). - Old bootblocks search for the first FreeBSD slice but don't tell the kernel which slice was booted from. - Current drivers search for all FreeBSD slices. - Current bootblocks search for the first FreeBSD slice and pass it to the kernel where it is ignored. It is known to be the first FreeBSD slice and using the compatibility slice instead is better for compatibility with old fstabs. Bruce