During the installation from CD as described in the hanbook ad0s2 was choosen as install target and partitioned by pressing 'a'. Afterwards, the boot manager question (chapter 2.5.4) was answered with "None". My plan was to use a boot utility on a floppy disk to boot FreeBSD later on (which works on another computer) in order to leave microsoft boot handler untouched. After finishing the installation process, the computer could not boot at all: The mbr of the primary master hard drive was deleted or destroyed! By booting from a MS-DOS boot disk and running fdisk /mbr the boot problem was fixed. The bug remains: If I choose 'None' in sysinstall I expect the mbr to be untouched! How-To-Repeat: Install a non FreeBSD operating system on the first partition of your prim. master harddisk which uses the mbr to boot. Install FreeBSD afterwards on the second partition of the same disk, answering the question of chapter 2.5.4 with 'none'. After the installation the mbr is gone.
Responsible Changed From-To: freebsd-bugs->qa Over to maintainer group.
Responsible Changed From-To: qa->freebsd-qa Canonicalize responsible.
State Changed From-To: open->feedback does this bug still exist in recent -RELEASEs ?
I have now tested the installation of FreeBSD 6.1 on a machine with some other OS already existing. I've choosen 'none' as described in the bug description. The goal was to use the existing boot manager and point it afterwards to the FreeBSD installation as well. Result: the system was not bootable after the FreeBSD installation. An analysis shows, that the mbr was not deleted or destroyed; just the active flag was removed and the FreeBSD slice was set active. Setting the previous slice active resolved the problem! So the bug text should be replaced by: sysinstall changes the active slice flag although the corresponding sysinstall question was answered with "None - Leave Master Boot Record untouched" Heiner
On Monday 19 June 2006 21:18, John Baldwin wrote: > Please fix your mail server to actually honor what SPF says if you want > people to reply to your questions. The SPF record for FreeBSD.org is not > exclusive. Sorry, my mail provider seems to be black listed sometimes. Can't do anything against it ... > Hmm, this is because the menu is not about leaving the MBR completely > untouched (we couldn't add new slices if we did that!) but instead about > leaving the boot code in the MBR untouched. Note that the Active flag > isn't stored in the boot code, but in the partition table. When you > create the FreeBSD slice in the MBR during installation, it will have > the Active flag set. You can manually reset the Active flag on the That is right. But what are the options? Either I do not have a bootloader installed. Then "standard" is the correct choice. Or I have other OS installed and I would like to let the BSD boot manager handle it. Then "BootMgr" is a good choice. Or I would like let my favorite boot manager do the job. Then "None" is my choice. Unfortunately my favorite boot manager will not boot, as the active flag has been changed! I can not think on any situation, where this behaviour might be usefull! > Windows partition before exiting that stage of the disk editor and > things should work as expected. Would you be able to try that out and > verify that? I did. During the fdisk "Allocating Disk Space" of the installation I selected the windows partition and pressed 'S'. After the installation the windows partition was still active. So this is a good workaround. Heiner
On Sunday 25 June 2006 05:26, Heiner wrote: > On Monday 19 June 2006 21:18, John Baldwin wrote: > > Hmm, this is because the menu is not about leaving the MBR completely > > untouched (we couldn't add new slices if we did that!) but instead about > > leaving the boot code in the MBR untouched. Note that the Active flag > > isn't stored in the boot code, but in the partition table. When you > > create the FreeBSD slice in the MBR during installation, it will have > > the Active flag set. You can manually reset the Active flag on the > > That is right. But what are the options? Either I do not have a bootloader > installed. Then "standard" is the correct choice. Or I have other OS > installed and I would like to let the BSD boot manager handle it. > Then "BootMgr" is a good choice. Or I would like let my favorite boot manager > do the job. Then "None" is my choice. Unfortunately my favorite boot manager > will not boot, as the active flag has been changed! I can not think on any > situation, where this behaviour might be usefull! The problem is the active flag isn't part of the boot code, just part of the partition table. I might want to leave the default DOS MBR boot loader present (use "None") but boot FreeBSD, in that case choosing "None" just works. It's not really feasible for the installer to know how custom boot loaders treat the Active flag or intuit which slice the user wants to boot by default. If you want to boot a slice other than FreeBSD it is up to the user to manually mark the other slice as active after adding the FreeBSD slice. This could probably be made clearer in the documentation though. > > Windows partition before exiting that stage of the disk editor and > > things should work as expected. Would you be able to try that out and > > verify that? > > I did. During the fdisk "Allocating Disk Space" of the installation I selected > the windows partition and pressed 'S'. After the installation the windows > partition was still active. So this is a good workaround. > > > Heiner > -- John Baldwin
Hi! > by default. If you want to boot a slice other than FreeBSD it is up to the > user to manually mark the other slice as active after adding the FreeBSD > slice. This could probably be made clearer in the documentation though. While I disagree in the first part, I agree in: - the docmentation should clearly state, what "none" means (changing the active slice) and how to prevent it, if unwanted (selecting the slice and pressing 'S') - afterwards bug 48341 can be closed Thanks Heiner
State Changed From-To: feedback->open Feedback was received
Responsible Changed From-To: freebsd-bugs->brucec Take.
State Changed From-To: open->suspended sysinstall obtains the list of slices from kern.geom.conftxt. Unfortunately that doesn't contain the flags so sysinstall has no way of knowing which slice is active. Suspend this PR pending a rewrite of the slice editor.
Responsible Changed From-To: brucec->freebsd-sysinstall Back to the pool.
State Changed From-To: suspended->closed Sysinstall is no longer in base.
State Changed From-To: closed->suspended However, stable/8 is not EOL and still contains sysinstall.
sysinstall has been replaced by bsdinstall in FreeBSD 9.x. Closing.