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

F

free-and-bsd

The port sysutils/grub2 fails to build because in file util/grub-mkfont.c line 42 reads
Code: 
#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
Code: 
#include <freetype2/ftsynth.h>
solves the issue.
 
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.
 
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:
Code: 
#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 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.
Click to expand...
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.
 
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.
 
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.
Click to expand...
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.
 
Anyway, here are some diagnostics:

the command geom disk list ada0 says this:
Code: 
#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:
Code: 
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)
 
free-and-bsd said:
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.
Click to expand...
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.
Click to expand...

4K = 4 * 1024 = 4096. They are equivalent.
 
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:
Code: 
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:
Code: 
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 :)
 
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:
Code: 
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 said:
search --no-floppy --fs-uuid --set=root 46464c03259a8cb0
Click to expand...
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:
Code: 
dirname=`dirname $kfreebsd`
into
Code: 
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.
 
Did you enter a PR? Posting in the forums does not guarantee that the port maintainer will see it.
 
wblock@ said:
Did you enter a PR? Posting in the forums does not guarantee that the port maintainer will see it.
Click to expand...
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.
 
Last edited:
You must log in or register to reply here.
Back
Top