Date: Fri, 15 Jan 2016 14:42:05 +0000 From: krad <kraduk@gmail.com> To: Eric McCorkle <eric@metricspace.net> Cc: Renato Botelho <garga@freebsd.org>, Steven Hartland <killing@multiplay.co.uk>, freebsd-hackers@freebsd.org, Gabor Radnai <gabor.radnai@gmail.com> Subject: Re: EFI/ZFS Update: successful tests, need more complex vdevs Message-ID: <CALfReye5nEMVvtoFKgL%2BweN4m5o%2BcERPmJibuJayNEtmLGaG3Q@mail.gmail.com> In-Reply-To: <569900CD.2040003@metricspace.net> References: <CABnVG=dbUQF_9-0FGj6hjNKPoRP-YekZfCEYfEb5DgcWK30BCA@mail.gmail.com> <9418E44F-114E-4ABA-A32D-416297BCDA9F@metricspace.net> <56985C6A.6040209@multiplay.co.uk> <EB1FB298-78BA-43C5-B5CF-C615D3D93570@FreeBSD.org> <569900CD.2040003@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks this is useful information. I did have a look at the way pc bsd was
using grub to boot rootonzfs systems, and they used the Kfreebsd options.
This looked kind of handy as you might have been able to specify the zfs
file system to boot off. This would be a real boost the boot environments
as you could easily choose which one to boot into, making upgrade recovery
far easier.
Presumably the freebsd@ part in your setup refers to the zfs file system?
In which case you could have multiple menu entries with different file
systems specified, this is assuming the grub config is on the efi disk
though?
I'm also curious how this would his work when the are multiple pools on the
same disk for some reason.
On 15 January 2016 at 14:23, Eric McCorkle <eric@metricspace.net> wrote:
> On 01/15/16 06:51, Renato Botelho wrote:
>
>> On Jan 15, 2016, at 00:41, Steven Hartland <killing@multiplay.co.uk>
>>> wrote:
>>>
>>> Just wanted to let everyone know that I just finished committing these
>>> changes to the tree.
>>>
>>> Huge thanks to Eric's for his work on this, as well as everyone else who
>>> contributed.
>>>
>>> I've set the target for MFC of 2 weeks, so I hope to be able to get this
>>> into stable/10 before the 10.3 slush, so if you're interested in this
>>> change please test a head build > r294068 ASAP.
>>>
>>
>> Great work, thanks!
>>
>> Is there a way to move a installed ZFS system to EFI?
>>
>>
> (Refer to Steven's guide for the simple case where you can create an EFI
> partition)
>
>
> == Using GRUB ==
>
> GRUB can be used with loader.efi on a ZFS system (I use this myself, as I
> have a Gentoo install in the same ZFS volume)
>
> Make sure you install GRUB with EFI support (the ports collection will
> handle this). The grub port comes with a script that auto-detects
> filesystems and sets up a grub.cfg in /boot/grub/. However, that script
> won't properly detect ZFS partitions, so you'll need to add it manually.
> The entry is simple.
>
> I have a zfs volume called "data", which has the freebsd system root on
> the filesystem data/freebsd. The GRUB entry then is:
>
> menuentry "FreeBSD" {
> search.fs_label data ZFS_PART
> chainloader ($ZFS_PART)/freebsd@/boot/loader.efi
> }
>
> The first line searches for the volume "data" and binds its device to the
> variable ZFS_PART. The second specifies that the chained bootloader is
> under the filesystem "freebsd" (the @ at the end of the name denotes a
> filesystem, not a path), with the path /boot/loader.efi
>
>
> == Disks without enough space to make the GPT or EFI partition ==
>
> If you have a ZFS filesystem on an MBR disk, or on a GPT disk without
> enough space to create a workable EFI partition, you can use one of ZFS's
> lesser-known features: zfs send/recv.
>
> ZFS send and recv allow an entire filesystem to be serialized out to a
> stream, and then read back in. You can use this to dump the entire
> filesystem out to a removable storage or an NFS mount. Then, use an
> install disk or memstick and repartition your drive, using zfs recv to
> recreate the filesystem.
>
>
> == On a Mac ==
>
> (Note: this is based on research that is several years old at this point.
> Also, I never actually field tested this myself.)
>
> Macs are wierd, due to their non-standard EFI. The Mac EFI implementation
> looks for an HFS+ partition, and loads the "blessed" file as the EFI
> bootloader (this is a special filesystem-level metadata unique to HFS+
> filesystems).
>
> In order to do an EFI boot on a mac, you'd need some way of manufacturing
> an HFS+ partition containing only your bootloader, with that file being
> "blessed". The easiest way to do this would be to use a Mac OS install to
> create an empty HFS+ filesystem, add your boot loader, then use a shell
> command to "bless" it (this command exists, but I don't remember what it is
> offhand). It also wouldn't be too hard to write a tool to create an HFS+
> image from a file (I have a half-written implementation of that lying
> around somewhere).
>
> Also note that Macs expect a 200MB EFI partition (which isn't actually
> used for anything), and I've heard reports of the firmware flaking out if
> it's not there.
>
> I believe there are also GRUB and rEFIt options for Mac, if you don't want
> to go to these lengths.
>
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALfReye5nEMVvtoFKgL%2BweN4m5o%2BcERPmJibuJayNEtmLGaG3Q>