# There is some strange issue with bsdinstall (and with gpart, maybe).



## Oleg_NYC (Nov 18, 2011)

I successfully installed freebsd FreeBSD 9 when I entered the shell mode in bsdinstall and followed this approach: http://www.wonkity.com/~wblock/docs/html/disksetup.html (the "Old Standard Way" approach). However, since I like testing things and have one spare hard drive that I use for testing purposes, I decided to install freebsd FreeBSD 9-RC2 on it. This time, I didn't enter the shell mode, but let bsdinstall partition the hard drive. My BIOS can't boot it no matter what partition table bsdinstall puts on it (GPT or MBR). My guess is that bsdinstall uses gpart to create either one of those partition tables. Just for testing purposes, I installed linux on that hard drive and BIOS successfully booted it. According to gpart's info output, linux installed bios-boot and efi partitions on it.

So, to conclude, the shell mode approach works for me when I install freebsd FreeBSD 9, and all of the other approaches don't.


----------



## wblock@ (Nov 18, 2011)

It would probably be helpful to show the output of *gpart show* from the working Linux disk.  Is this a relatively new computer or motherboard?


----------



## Oleg_NYC (Nov 18, 2011)

The model of my computer is Gateway GT5620. I think I bought it in 2008. Gpart displays this output for the linux disk:

```
=>        34  3907029101  ada2  GPT  (1.8T)
          34        2014        - free -  (1M)
        2048        2048     1  bios-boot  (1.0M)
        4096     1024000     2  efi  (500M)
     1028096     8257536     3  linux-swap  (4G)
     9285632   104857600     4  linux-data  (50G)
   114143232  3792885760     5  linux-data  (1.8T)
  3907028992         143        - free -  (71k)
```


----------



## tingo (Nov 18, 2011)

if you don't mind testing, you could retry the FreeBSD install on that drive again (same way as you did it when it didn't work). But this time, go to shell (liveCD or what it is called) before you reboot, and do a `# gpart show` on the drive. Perhaps we can figure out what the problem is.


----------



## Oleg_NYC (Nov 18, 2011)

Okay, I'll do that.


----------



## Oleg_NYC (Nov 18, 2011)

Here it is:
`# gpart show /dev/ada2`

```
=>        34  3907029101  ada2  GPT  (1.8T)
          34           6        - free -  (3.0k)
          40         128     1  freebsd-boot  (64k)
         168  3898605432     2  freebsd-ufs  (1.8T)
  3898605600     8388608     3  freebsd-swap  (4.0G)
  3906994208       34927        - free -  (17M)
```


----------



## wblock@ (Nov 19, 2011)

oleglelchuk said:
			
		

> The model of my computer is Gateway GT5620. I think I bought it in 2008. Gpart displays this output for the linux disk:
> 
> ```
> =>        34  3907029101  ada2  GPT  (1.8T)
> ...



It might need that efi partition, or at least expect to find it on a GPT disk.  Put a 512K freebsd-boot partition starting at 34, delete the bios-boot partition, leave the efi partition, and replace the partitions following it with freebsd-ufs and freebsd-swap.


----------



## Oleg_NYC (Nov 19, 2011)

To be honest, I don't know how to do it correctly on command line or in bsdinstall. When I tried to do it in bsdinstall, it didn't create the freebsd-boot partition at number 34, but below it. On the command line, I typed: [cmd=]gpart add -t freebsd-boot -s 512K -b 34 /dev/ada2[/cmd], and got the message: 
	
	



```
ada2p1 added, but partition is not aligned on 4096 bytes
```


----------



## wblock@ (Nov 19, 2011)

It doesn't have to start at 34, it should just be the first partition.  Use -b 40 to start at 5*4k.  Add -a 4k to the command and gpart(8) will align to the nearest 4K.  I'm not sure whether gpart will let you create a new partition before existing ones, haven't tried that.


----------



## Oleg_NYC (Nov 19, 2011)

Well, if I use bsdinstall to create a 512K freebsd-boot partition, 500MB efi partition, freebsd-swap partition, and freebsd-ufs partition, and then install the base system and the kernel on it, the BIOS can't boot it.


----------



## tingo (Nov 19, 2011)

It probably expects there to be something in that efi partition as well.
Herer is another thing you can try:

install Linux (like you did before), verify that it boots.
boot the FreeBSD liveCD, and verify that the partitions looks like the output in post #3.
delete all partitions, except for 'bios-boot' and 'efi'
install FreeBSD.


----------



## Oleg_NYC (Nov 20, 2011)

Okay, this is what I found out. The efi partition that linux installed contained a root filesystem with the linux kernel. I deleted every single partition from the drive without destroying the GPT table on it and ran the command [cmd=]gpart add -t freebsd-boot -s 512K -a 4k ada2[/cmd] Then I typed [cmd=]gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada2[/cmd] Then I rebooted with the FreeBSD LiveCD, and in bsdinstall, I entered the manual mode for partitioning, added freebsd-swap and freebsd-ufs partitions to the drive, answered "no" to the question "This partition scheme requires a boot partition for the disk to be bootable. Would you like to make one now?" I installed the base system/kernel to the disk, and when I rebooted, the BIOS successfully booted that drive. This is what the output from [cmd=]gpart show[/cmd] displays:

```
gpart show /dev/ada2
=>        34  3907029101  ada2  GPT  (1.8T)
          34           6        - free -  (3.0k)
          40        1024     1  freebsd-boot  (512k)
        1064     8388608     2  freebsd-swap  (4.0G)
     8389672  3898605568     3  freebsd-ufs  (1.8T)
  3906995240       33895        - free -  (16M)
```

So, please tell me what it is that bsdinstall does wrong unless I ignore its default options.


----------



## kpa (Nov 20, 2011)

Can you compare what fdisk(8) says about the working and non working partitionings? This could be a problem with the protective MBR (/boot/pmbr) where the MBR partition that covers (protects) the GPT area is not marked as active and some BIOSes refuse to boot when there is no active MBR partition on the disk.


----------



## Oleg_NYC (Nov 20, 2011)

Okay, this is the output from [cmd=]fdisk /dev/ada2[/cmd] about the working partitioning scheme:


```
The data for partition 1 is:
sysid 238 (0xee),(EFI GPT)
    start 1, size 3907029167 (1907729 Meg), flag 80 (active)
        beg: cyl 0/ head 0/ sector 1;
        end: cyl 1023/ head 254/ sector 63
```

After you told me to check its output for the partitioning scheme that the BIOS is unable to boot, I ran [cmd=]gpart destroy -F /dev/ada2[/cmd] rebooted with the LiveCD in the CD drive, used all the default options that bsdinstall offered me for installing FreeBSD, and now this is what [cmd=]fdisk /dev/ada2[/cmd] says about this unbootable scheme:


```
The data for partition 1 is:
sysid 238 (0xee),(EFI GPT)
    start 1, size 3907029167 (1907729 Meg), flag 80 (active)
        beg: cyl 0/ head 0/ sector 2;
        end: cyl 1023/ head 255/ sector 63
```

 So, I see two differences: in the first case, it was 
	
	



```
sector 1
```
 and 
	
	



```
head 254
```
 and in the second case, it was 
	
	



```
sector 2
```
 and 
	
	



```
head 255
```


----------



## Oleg_NYC (Nov 20, 2011)

So, guys, have you figured out the source of the problem?


----------



## wblock@ (Nov 20, 2011)

I would take a working Linux install and modify the partitions with gpart.


----------



## Oleg_NYC (Nov 20, 2011)

But that's what I did. I made sure that the drive on which linux was installed was bootable and deleted every single partition from it without destroying the GPT table itself. I explained it in post #12. In that post, I also mentioned what I did after that and I mentioned that I was able to boot that drive with a working FreeBSD system on it. But then kpa asked me to use fdisk to compare the info about the bootable system with the info about the unbootable one, and that's what I did. What should I do now?


----------



## wblock@ (Nov 20, 2011)

No, I mean after the Linux install creates the partitions, create a freebsd-boot partition at the beginning and replace the linux partitions after it with freebsd-ufs and freebsd-swap.  See post #7.


----------



## tingo (Nov 20, 2011)

oleglelchuk said:
			
		

> answered "no" to the question "This partition scheme requires a boot partition for the disk to be bootable..."



When you first installed FreeBSD (and it didn't work), did you also answer "no" to this question? That would explain things.


----------



## Oleg_NYC (Nov 20, 2011)

tingo, no, if I use the standard approach for installing FreeBSD, that question never gets asked.
wblock, if I delete the linux-swap and linux-data partitions, delete the bios-boot partition and replace it with the freebsd-boot partition, leave the efi partition untouched, and add the freebsd-swap and freebsd-ufs partitions, that drive will still load the grub boot-manager and boot the linux kernel. If I delete the efi partition and boot that drive, the grub rescue prompt will appear. If I execute the command 
	
	



```
gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada2
```
 the grub boot manager will be destroyed and replaced with the FreeBSD boot manager. I will get the message "Not ufs" if I boot that drive with the empty freebsd-ufs partition that I created before, or the FreeBSD OS will be successfully loaded if I use bsdinstall to put the base system/kernel on that freebsd-ufs partition.

By the way, I want to explain more what happens when the BIOS can't boot the drive. If I use the standard approach for installing FreeBSD, the computer will just keep displaying the messages 
	
	



```
<F2> Enter BIOS menu
```
 and 
	
	



```
<F10>Choose the drive from which to boot
```
 and nothing will happen if I press on those keys. So, at this point, I will be forced to disconnect the data cable from the drive, reboot, and reconnect the cable before the kernel on my other drive starts booting.


----------



## wblock@ (Nov 20, 2011)

oleglelchuk said:
			
		

> wblock, if I delete the linux-swap and linux-data partitions, delete the bios-boot partition and replace it with the freebsd-boot partition, leave the efi partition untouched, and add the freebsd-swap and freebsd-ufs partitions, that drive will still load the grub boot-manager and boot the linux kernel. If I delete the efi partition and boot that drive, the grub rescue prompt will appear. If I execute the command
> 
> 
> 
> ...



Yes, but if a freebsd-boot partition is larger than 512K, it will not boot.  The blank space at the start of that drive and the bios-boot partition are both 1M.  I think it will work to add the freebsd-boot partition in the blank space:
`# gpart add -t freebsd-boot -a 4k -b 40 -s 512K ada2`

Then put the bootcode on it as above.  AFAIK gptboot will try to boot the first UFS partition it finds.



> I will get the message "Not ufs" if I boot that drive with the empty freebsd-ufs partition that I created before,



Sure, there has to be a filesystem there.  Creating the partition doesn't automatically create the filesystem or populate it.



> or the FreeBSD OS will be successfully loaded if I use bsdinstall to put the base system/kernel on that freebsd-ufs partition.



Um... that sounds like it works.


----------



## Oleg_NYC (Nov 20, 2011)

wblock@ said:
			
		

> Yes, but if a freebsd-boot partition is larger than 512K, it will not boot



Yes, I created a 512K freebsd-boot partition, though I never tried putting it in the blank space above the bios-boot partition.

But what I would like to know is why I have the problems that I described if I simply follow the default and standard approach for installing FreeBSD 9. If my BIOS is buggy, then why was I able to install linux without having those problems? If bsdinstall and gpart are buggy, then why am I the only person on this board who had the problems I described?


----------



## wblock@ (Nov 20, 2011)

It's really hard to say.  Linux might have a special workaround for that computer.  Or maybe there's a BIOS bug that only affects FreeBSD.  But it sounds like that EFI partition is needed when a GPT partition scheme is used.  Please post the model of computer, something may be known about it.  That might also help future searchers with the same model.


----------



## Oleg_NYC (Nov 21, 2011)

As I mentioned before, the computer model is Gateway GT5620.


----------



## wblock@ (Nov 21, 2011)

So you did, sorry.  Does it have the latest BIOS?


----------



## Oleg_NYC (Nov 21, 2011)

Yes.


----------



## Oleg_NYC (Nov 22, 2011)

But I don't understand why you think the EFI partition is needed. I think the problem has more to do with how gpart creates the GPT table, as opposed to how gnu parted does it. For example, if I type [cmd=]parted /dev/sdc[/cmd] and then type [cmd=]mklabel gpt[/cmd] my BIOS doesn't crash when I reboot and I can add any freebsd FreeBSD partition to it. But if I type [cmd=]gpart create -s gpt /dev/ada2[/cmd] the BIOS crashes when I reboot.


----------



## wblock@ (Nov 22, 2011)

Now that's interesting.  The EFI partition is guesswork, mainly because when it was present, the machine worked.

Compare the two partition tables.  Create a blank GPT with with parted/mklabel, then display the partition table information.  (I'd use mfsBSD and *gpart show* but *parted print* might also be good.)  Then erase it and create a GPT setup with gpart.  Now use the same program as before to display the partition table information again and look for differences.


----------



## MasterCATZ (Nov 23, 2011)

I am having similar issues

```
gptboot: invalid GPT backup header
Auto failed
Manual MBF /BSD with Auto GPT Partition failed
```

Just about to try my luck doing it manually in the shell again but last time it froze on asking for root password. Any other method so far booting it just showed - then | then stopped dead in its tracks. 8.2-Release and 9-Current installed fine but 9.0 RC2 memstick, that's another question also tried installing via sysinstall. With no luck in the installer knowing where the files were.

*edit*

Drive was wiped Completely via both DD and LLF and used Auto option with 9.0 RC2 installer 
3 times now the built in partition tool has caused some kind of boot failour on a completly zero'd HDD 

I performed low level Format on HDD and retied 9.0 RC2 it did it again I then went to 8.2-Release and it refused to write changes to HDD , Re Low level Formatted HDD and 8.2-Release installed onto it 

I am just about to try and install 9.0 RC2 into the created partitions 8.2 did 

9-Current installed and booted ( with the backup header nag as 64k boot )last weekend 

*edit*

8.2-release did them as MBR and BSD Slices

when I tried this manually even in 9.0 RC2 it still would not boot it would just show a - then 2 sec later halt on a | 
( worked out this only happens if I do not zero out the drive after a GPT has been created





also noticed 9-current has MPS enabled but RC2 does not

I can not use any other partitioning tools after 9 has partitioned as GPT
 ( 8.2-releases complains about not being able to find nodes and fdisk has issues as well ) 

the only way to change anything is to dd zero out the start of the drive , the disk is an 500 gig usb GoFlex




I found that if I leave the MBR that 8.2 made and make a BSD partition in 9 RC2 it works 

but if I use 9 RC2 to  make a MBR and then a BSD partition it will not work 
( only if a GPT had been created with out dd zeroing the drive if it is zero'd out 9 RC2 will boot fine after manually creating them )

I am going to do Trial and error on a thumb drive later on when I have time as I have plenty spare I can kill

maybe not being marked as bootable ?




I think its because the 9.0 RC2 is using 64k boot size I recreated it as 256k and it booted 
how ever the gptboot: invalid GPT backup header is still their but at least it kept booting


I have now forgotten what I did but I am pretty sure I used Auto full disk then manually re edited the GPT partition to have 128k boot in GPT style and it booted 
( but can not rermber if it was MBR or not now )
 because  
	
	



```
gptboot: invalid GPT backup header
```
 still displayed and was annoying me I manually made it an MBR with BSD slice's and the install went fine ( how ever I still had to zero out the drive before that would work after the GPT was made what ever it is doing in AUTO mode is preventing something from working 

the other thing would be if using GPT partitions and mount paths in the installer menu  has the option to make labels why does it not use them I had to manually change the fstab file after I enabled MPS so the rootfs could be found after drive positions changed

I was going to pastebin the HDD boot sectors for comparison as HEX code but it only saved as garbled data
if someone knows of a program that will let me copy and paste / export the offset hex and code I am all ears ( I was using WinHEX )


----------



## wblock@ (Nov 23, 2011)

That's a different issue, which I responded to in this thread.


----------



## tingo (Nov 24, 2011)

oleglelchuk said:
			
		

> tingo, no, if I use the standard approach for installing FreeBSD, that question never gets asked.



That's odd. It sure gets asked here when I install from a FreeBSD 9.0-RC2 image.
When you say "standard approach" do you mean using the installer (as in selecting "Install" from the menu)?


----------



## Oleg_NYC (Nov 24, 2011)

tingo, yes. If I select "Install", then select "Guided" method for partitioning, and hit "Finish", that question never gets asked.

wblock, *parted print* displays the same information in both cases, except that, of course, I need to disconnect and then reconnect the data cable to the hard drive after the BIOS loads and before the kernel boots if the GPT table was created with gpart. As I mentioned in post #1, I get the same problems if I use gpart to create the MBR/slicing scheme on the hard drive. For example, the BIOS doesn't crash if I create the MBR table with the command *gpart create -s mbr /dev/ada2*, but it crashes if I add slice 1 to the disk by typing *gpart add -t freebsd /dev/ada2*. Fdisk and bsdlabel don't give me the same problems if I use them for the same purpose.


----------



## wblock@ (Nov 24, 2011)

If the partition sizes and locations are identical, then it's either the contents of those partitions, or maybe the "magic values" used to identify the partition types.


----------

