Date: Fri, 15 Jan 2016 14:48:01 +0000 From: Steven Hartland <killing@multiplay.co.uk> To: krad <kraduk@gmail.com>, Eric McCorkle <eric@metricspace.net> Cc: Renato Botelho <garga@freebsd.org>, freebsd-hackers@freebsd.org, Gabor Radnai <gabor.radnai@gmail.com> Subject: Re: EFI/ZFS Update: successful tests, need more complex vdevs Message-ID: <569906A1.8040700@multiplay.co.uk> In-Reply-To: <CALfReye5nEMVvtoFKgL%2BweN4m5o%2BcERPmJibuJayNEtmLGaG3Q@mail.gmail.com> 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> <CALfReye5nEMVvtoFKgL%2BweN4m5o%2BcERPmJibuJayNEtmLGaG3Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
ZFS Boot Environments (BE) support was also wired up to Beastie last night by Allan for those interested in that :) On 15/01/2016 14:42, krad wrote: > 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 > <mailto: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 <mailto: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 <mailto: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 > <mailto:freebsd-hackers-unsubscribe@freebsd.org>" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?569906A1.8040700>