# sysutils/grub2 fails to build: util/grub-mkfont.c typo



## free-and-bsd (Apr 22, 2014)

The port sysutils/grub2 fails to build because in file util/grub-mkfont.c line 42 reads

```
#include <freetype/ftsynth.h>
```
while on my system the actual file is found under freetype2 subfolder, and rightfully so since I only have print/freetype2 installed. So changing it to 
	
	



```
#include <freetype2/ftsynth.h>
```
 solves the issue.


----------



## jrm@ (Apr 22, 2014)

I submitted the patch for this a few weeks ago and it was just accepted the other day. Update your ports tree and try again.


----------



## free-and-bsd (Apr 22, 2014)

Oh, you did! Thanks a lot.

BTW, want to express my greatest thanks to you for your nice job with grub2 )
I'm utterly satisfied that now it can do EVERYTHING: 
1) it can boot FreeBSD kernel directly rather than via /boot/zfsloader.
2) it can boot it from a ZFS filesystem.
3) it can do all the above with grub2 config files themselves residing on that same ZFS filesystem.
I"m saying all this because the Linux grub2 I used last wasn't able to boot the kernel directly, but would choke and reboot. Which compels to use /boot/zfsloader, which is not nearly as good an option...

For all the above to be possible there's one requirement, though: the bios-boot partition MUST be big enough to embed all the needed grub2 data. At least, when I converted the existing freebsd-boot size 64K partition to be used by grub2, it proved not big enough and the resulting bootloader escaped to rescue prompt, from which it is impossible to boot a ZFS-based system. So I made my bios-boot partition 20M large and now it works perfectly well. I remember this recommendation since my Linux experiences with grub2.

If somebody wants to know how to create the needed bios-boot partition:

```
#gpart add -t \!21686148-6449-6E6F-744E-656564454649 -s <size> -i <index> <geom>
```
 AFAIK it need not be exactly at the beginning of your GPT disk -- which is the beauty of GPT. It doesn't need MBR/PMBR if you're using grub2 as your boot-loader. 

Spent quite some time testing these things, so it'll be good for other people to know. Because grub2 is the best bootloader I know of to be used for multiboot systems (except if one's using Oracle Solaris, in which case Solaris' own grub2 version will have to be used).

So, thank you again for your great job!!!!


----------



## free-and-bsd (Apr 24, 2014)

free-and-bsd said:
			
		

> 1) it can boot FreeBSD kernel directly rather than via /boot/zfsloader.
> 2) it can boot it from a ZFS filesystem.
> 3) it can do all the above with grub2 config files themselves residing on that same ZFS filesystem.


There seems to be one exception for  (3): I have a 4k-aligned HDD with ZFS filesystem that's 4k-aligned as well. For that configuration rule (3) doesn't work and grub2 fails to find partition. The only working solution is to create, not only a boot-bios partition to embed grub2 images, but also a dedicated partition for grub2 boot-directory to reside there. That's the only way it seems to work for my 4k-aligned HDD.
The drive, I must add, is for sure 4k-aligned (checked and double checked it with the vendor), and the ZFS also reports ashift=12, so there must be no mistake about that.


----------



## wblock@ (Apr 24, 2014)

Careful with the terminology.  "Aligned" means the filesystem blocks are aligned with the disk blocks.  If you did not use -a4k when adding those partitions with gpart(8), a drive with 4K blocks and ZFS with ashift=12 can still not be aligned, resulting in poor performance.


----------



## free-and-bsd (Apr 24, 2014)

wblock@ said:
			
		

> Careful with the terminology.  "Aligned" means the filesystem blocks are aligned with the disk blocks.  If you did not use -a4k when adding those partitions with gpart(8), a drive with 4K blocks and ZFS with ashift=12 can still not be aligned, resulting in poor performance.


How about if I used -a 4096 instead? At first I didn't and gpart complained that the resulting partition "was created but wasn't 4k-aligned". So I used -a 4096 and then it didn't complain.


----------



## free-and-bsd (Apr 24, 2014)

Anyway, here are some diagnostics:

the command `geom disk list ada0` says this:

```
#geom disk list ada0
Geom name: ada0
Providers:
1. Name: ada0
   Mediasize: 1000204886016 (932G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e3
   descr: WDC WD10EZEX-08M2NA0
   lunid: 50014ee25f20d41e
   ident: WD-WCC3F2012824
   fwsectors: 63
   fwheads: 16
```

And then `camcontrol identify ada0`:

```
pass0: <WDC WD10EZEX-08M2NA0 01.01A01> ATA-9 SATA 3.x device
pass0: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes)

protocol              ATA/ATAPI-9 SATA 3.x
device model          WDC WD10EZEX-08M2NA0
firmware revision     01.01A01
serial number         WD-WCC3F2012824
WWN                   50014ee25f20d41e
cylinders             16383
heads                 16
sectors/track         63
sector size           logical 512, physical 4096, offset 0
LBA supported         268435455 sectors
LBA48 supported       1953525168 sectors
PIO supported         PIO4
DMA supported         WDMA2 UDMA5 
media RPM             7200

Feature                      Support  Enabled   Value           Vendor
read ahead                     yes	yes
write cache                    yes	yes
flush cache                    yes	yes
overlap                        no
Tagged Command Queuing (TCQ)   no	no
Native Command Queuing (NCQ)   yes		32 tags
SMART                          yes	yes
microcode download             yes	yes
security                       yes	no
power management               yes	yes
advanced power management      no	no
automatic acoustic management  no	no
media status notification      no	no
power-up in Standby            no	no
write-read-verify              no	no
unload                         yes	yes
free-fall                      no	no
Data Set Management (DSM/TRIM) no
Host Protected Area (HPA)      yes      no      1953525168/1953525168
HPA - Security                 no
```
Which means, I believe, that the drive _does_ have 4k sectors (physical 4096 output of `camcontrol`) and that the partition _is_ 4k-aligned (Stripeoffset: 0 output of `geom disk list`)


----------



## wblock@ (Apr 24, 2014)

free-and-bsd said:
			
		

> wblock@ said:
> 
> 
> 
> ...



4K = 4 * 1024 = 4096.  They are equivalent.


----------



## free-and-bsd (Apr 24, 2014)

Thanks, so I thought when in the live CD's shell with no option to google it up .


----------



## free-and-bsd (Apr 24, 2014)

Finally, there is a solution to the problem of _standard_ grub2 installation not being able to find 4k-aligned ZFS partition.

While I have no idea about the roots of the problem itself, the solution is to include the zfs and part_gpt modules into the core.img that gets embedded into the bios-boot partition:

```
grub-install --modules="part_gpt zfs" /dev/ada0
```
The only thing to keep in mind, then, is that the resulting core.img is about 54k large (the default one is about 34k), so the bios-boot partition must be big enough to hold it. Looks like the usual 64k or 94k freebsd-boot partition, after being converted to the bios-boot type, will be able to hold it.
The above mentioned implies, that the _standard_ install procedure doesn't include the --modules argument to grub-install command, hoping that it will figure out the fitting defaults. And so it does, as it all works fine on my other HDD with no 4k alignment.

Finally, the possibility of creating separate core.img files including the needed modules is a good thing if one needs some rescue media, useful for various cases including even EFI/UEFI systems, along with the more common PCs. They can reside in the grub2 boot directory of such media and every such core.img file can be booted as a multiboot kernel using the grub shell multiboot command:

```
multiboot /path/to/core.img
```
HERE is a good thorough guide to grub2 usage, it also explains how to create core.img without embedding it onto your HDD partition. Thanks to the Archlinux guys for their useful documentation


----------



## free-and-bsd (Apr 27, 2014)

OK, there is finally this small problem with grub-mkconfig: for some reasons it tries to look for zpool.cache in /boot/kernel/zfs instead of /boot/zfs , then complains it is not found there.

Besides, the generated grub.cfg file is every now and then polluted by the following lines:

```
insmod zfs
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  46464c03259a8cb0
else
  search --no-floppy --fs-uuid --set=root 46464c03259a8cb0
fi
```
which MAY BE , if ever, needed at the beginning of a menuentry, but now every few lines. 

Otherwise the scirpt detects zfs pool and root fs  all right and the entries for kernel and modules are written correctly -- except for these 2 errors above.


----------



## free-and-bsd (Dec 7, 2014)

free-and-bsd said:


> search --no-floppy --fs-uuid --set=root 46464c03259a8cb0


UPDATES: the string above now works perfectly fine and UUID is recognized by the bootloader at the boot stage. So there's no need now to be using `set root=(hdN,[gpt]N)`
directive to replace it. Thanks to the maintainers and developers .

There still remains the problem that the script looks for zpool.cache in /boot/kernel/zfs instead of /boot/zfs. This can be fixed by changing this line in the file /usr/local/etc/grub.d/10_kfreebsd:

```
dirname=`dirname $kfreebsd`
```
into 
	
	



```
dirname=`dirname $(dirname $kfreebsd)`
```
This, of course, implies that zpool.cache is looked for and found in /boot/zfs. And sure thing, it is a rather _bad_ idea to have it in /boot/kernel directory.


----------



## free-and-bsd (Dec 8, 2014)

OK, I've submitted a patch to make grub-mkconfig work for FreeBSD in sysutils/grub2.


----------



## wblock@ (Dec 9, 2014)

Did you enter a PR?  Posting in the forums does not guarantee that the port maintainer will see it.


----------



## free-and-bsd (Dec 9, 2014)

wblock@ said:


> Did you enter a PR?  Posting in the forums does not guarantee that the port maintainer will see it.


No I haven't, don't know who to address with this particular problem. `pkg info sysutils/grub2` shows maintainer address at ports@FreeBSD.org, yet `grub-mkconfig --help` shows the address to report bugs at bug-grub@gnu.org. And the problem with this script is hardly the fault of port maintainers, it is from the upstream. Even being Linux user I used to have edit the resulting grub.cfg files created by grub-mkconfig. So I'm not sure who I should address with this.

Or am I wrong? From the comments found in the file in question it appears that GRUB2 developers were thinking, perhaps, of Debian distribution running a kFreeBSD kernel, and not of the FreeBSD OS itself. In which case their consideration as to what should be found where must be well justified, so then this matter concerns more the port maintainers.


----------



## wblock@ (Dec 9, 2014)

If it is an upstream bug, that is where to report it.  If it takes the upstream a long time to integrate bug fixes, it still can be worth adding a patch to the port so it works in the meantime.  For that, enter a port bug.  We even have an article on submitting bugs: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/.


----------



## free-and-bsd (Dec 9, 2014)

wblock@ said:


> If it is an upstream bug, that is where to report it.  If it takes the upstream a long time to integrate bug fixes, it still can be worth adding a patch to the port so it works in the meantime.  For that, enter a port bug.  We even have an article on submitting bugs: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/.


Done


----------

