About /boot being a symlink to /efi/boot and ZFS
Anton Shterenlikht
mexas at bristol.ac.uk
Wed Jan 27 22:41:45 UTC 2010
On Tue, Jan 26, 2010 at 10:24:57AM -0800, Marcel Moolenaar wrote:
> All,
>
> Due to limitations of the EFI loader, files under /boot had to
> be on the EFI system partition for the boot process to work.
> And in order to boot the new kernel after building an installing
> a new kernel, the only viable option for that was to make /boot
> a symlink to /efi/boot and mount the EFI system partition under
> /efi by default.
>
> While initially this was mostly preventing us from having more
> than 1 FreeBSD installation on a single machine, over time this
> showed to cause bigger problems.
>
> The first and foremost problem is that it causes the kernel to
> panic when you use ZFS. The reason for the panic is that ZFS
> maintains a cache file that lives under /boot/zfs on FreeBSD.
> This is because /boot/zfs really is /efi/boot/zfs on ia64 and
> /efi is a FAT file system that needs the Giant lock, which ZFS
> simply does not deal with well or at all.
>
> To solve this issue, I had 3 choices:
> ZFS-1 Teach ZFS about Giant for the time that Giant is still
> around
> ZFS-2 Fix the FAT file system implement by not needing Giant
> ZFS-3 Eliminate /boot as a symlink to /efi/boot
>
> A second problem recently popped up when mergemaster started to
> compare file and directory types and started to complain about
> /boot not being a directory like it should be. While this isn't
> a big issue, mergemaster has no way of ignoring directories so
> it'll will always come up.
>
> To solve the mergemaster issue, I had 2 choices:
> MM-1 Extend mergemaster to allow it to ignore directories
> without ignoring the files in them
> MM-2 Eliminate /boot as a symlink to /efi/boot
>
> It has always been nice to be able to install multiple versions
> of FreeBSD, especially for development and maintenance, and for
> that to happen, I had to eliminate /boot as a symlink to /efi/boot.
>
> You get the drift...
>
> So, I changed to not use the EFI file system protocol, but rather
> the EFI block I/O protocol. This make the loader aware of the
> partitions on the disk. Using FreeBSD's file system support on
> top of that, we were able to read from the EFI system partition,
> a FreeBSD UFS file system and even ISO9660s.
>
> Secondly, I added a command line argument to the loader (a boot
> option in EFIs boot manager terminology) so that one can select
> the default partition to boot from.
>
> With these 2 changes, the loader can boot FreeBSD directly from
> the UFS root file system and consequently /boot does not have to
> be a symlink onto /efi and both ZFS and mergemaster are happy
> campers.
>
> To migrate your existing installation to the new scheme, follow
> the following instructions:
>
> 1. Upgrade to the latest 8-STABLE or 9-CURRENT sources.
> 2. Perform a full 'make buildworld' and 'make buildkernel'
> 3. Perform a 'make installworld' only
>
> [after step 3 you have the latest loader on /efi]
>
> 4. Remove the /boot symlink (and only the symlink)
> 5. Perform a 'make installworld' again -- a bit excessive,
> but easier for the instructions.
>
> [after step 5 you have a minimally populated /boot on the
> root file system]
>
> 6. Perform a 'make installkernel' -- this installs the
> latest kernel in /boot on the root file system.
>
> [after step 6 the EFI file system holds the preview kernel
> and the UFS root file system holds the latest kernel]
>
> 7. Copy /efi/boot/loader.conf and /efi/boot/device.hints to
> /boot/loader.conf and /boot/device.hinst (resp).
> 8. From /boot/loader.conf, remove the vfs.root.mountfrom
> line.
> 9. Copy the FreeBSD loader to a more proper directory. Type:
> # mkdir /efi/FreeBSD
> # cp /efi/boot/loader.efi /efi/FreeBSD
> 10. Reboot.
> 11. In the EFI boot manager, add a new entry for FreeBSD by
> using "FreeBSD/loader.efi" as the loader and "-dev part2:"
> as the boot option string (can be either Unicode or ASCII).
> 12. Boot FreeBSD. Check that the loader version is 2.1. If not,
> you're not using the right loader. If the loader version
> is right but the loader cannot find a kernel, run 'lsdev'
> in the loader to list all partitions and try them until
> you find the right one. Note that part0: can be expected
> to be the EFI system partition, so you that only if you
> can't find a kernel on any other partitons. Remember to
> update the EFI boot manager accordingly.
Marcel, I got stuck in step 12:
Loading.: FreeBSD
Starting: FreeBSD
Consoles: EFI console
FreeBSD/ia64 EFI boot, Revision 2.1
(mexas at mech-as221.men.bris.ac.uk, Tue Jan 26 23:36:05 GMT 2010)
\
can't load 'kernel'
Type '?' for a list of commands, 'help' for more detailed help.
OK
What does "-dev part2:" do?
OK lsdev
part devices:
part0: 33554432 blocks
part1: 109820239 blocks
part2: 33554432 blocks
part3: 109820239 blocks
part4: 819200 blocks
part5: 2097152 blocks
part6: 2097152 blocks
part7: 2097152 blocks
part8: 2097152 blocks
part9: 26358603 blocks
net devices:
net0:
net1:
OK
Where do I go from here?
Shell> ls fs0:\freebsd
Directory of: fs0:\freebsd
01/27/10 10:12p <DIR> 16,384 .
01/27/10 10:12p <DIR> 0 ..
01/27/10 10:12p r 611,689 loader.efi
1 File(s) 611,689 bytes
2 Dir(s)
I wonder if there should be an excutable flag?
thank you
anton
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
More information about the freebsd-ia64
mailing list