Date: Fri, 15 Jan 2016 08:52:34 -0600 From: Karl Denninger <karl@denninger.net> To: freebsd-hackers@freebsd.org Subject: Re: EFI/ZFS Update: successful tests, need more complex vdevs Message-ID: <569907B2.4070700@denninger.net> In-Reply-To: <569906A1.8040700@multiplay.co.uk> 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> <569906A1.8040700@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
THAT's useful around here :-)
On 1/15/2016 08:48, Steven Hartland wrote:
> 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>"
>>
>>
>
> _______________________________________________
> 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"
--
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
[-- Attachment #2 --]
0 *H
010
`He 0 *H
_0[0C)0
*H
01 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA0
150421022159Z
200419022159Z0Z1 0 UUS10UFlorida10U
Cuda Systems LLC1 0 UKarl Denninger (OCSP)0"0
*H
0
X@vkY
Tq/vE]5#֯MX \8LJ/V?5Da+
sJc*/r{ȼnS+ w")ąZ^DtdCOZ ~7Q '@a#ijc۴oZdB&!Ӝ-< ? HN5y
5}F|e f"V لio74zn">a1qWuɖbFeGE&3(KhixG3!#e_XƬ Ϝ/,$+;4y 'Bz<qT9_?rRUpn5
Jn&Rx/p Jyel*pN8/#9u/YP EC)TY>~/˘N[vyiDKˉ ,^" ?$T8 v& K%z8C @?K{9f`+@,| Mbia 007++0)0'+0http://cudasystems.net:88880 U 0 0 `HB0 U 0, `HB
OpenSSL Generated Certificate0 U -h\Ff Y0 U #0$q}ݽʒm50 U 0karl@denninger.net0
*H
Owbabɺx&Uk[ (Oj!%p MQ0I!#QH}.>~2&D}<wm_>V6 v ]f>=Nn+8;q wfΰ/RLyUG#b}n!Dր _up|_ǰc/%ۥ
nN8:d;-UJd/m1~VނיnN I˾$tF1&}|?q?\đXԑ&\4V<lKۮ3%Am_(q -(cAeGX)f}-˥6cv~Kg8m~v ;|9:-iAPқ6ېn-.)<[$KJtt/L4ᖣ^Cmu4vb{+BG$M0c\[MR|0FԸP&78"4p# }D Z9;V9#>Sw"[UP710001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0
`He M0 *H
1 *H
0 *H
1
160115145234Z0O *H
1B@£SxDUǁG-߿ ;d=6gc 這 Qt{@y+UMR'0l *H
1_0]0 `He*0 `He0
*H
0*H
0
*H
@0+0
*H
(0 +71001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0 *H
101 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0
*H
.X>=MHg:W|#{-w4%Fh&c28#?֏>Ł!y< ?'66+\\>I0/DM6xʾeƼkݨ|t)8k.biS>.D2{i^(WYe!qu! 80gjEg9AH{dKF
,\1o
sT&CMh;~(\[r)I!z-%ΦE;^KDӗ$ЊI>;T.v/6/I|7@EQMֲwH`|%AU뵀УUoNoxևR_}p ŭ*zT:
b-i73
eҿ6CPc&֯BC6qL Y9RIUbhbE"HX9^$P#bLZ ;e'Kk
p,:"q R
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?569907B2.4070700>