From owner-freebsd-hackers@freebsd.org Fri Jan 15 14:42:07 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C20D5A84765 for ; Fri, 15 Jan 2016 14:42:07 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79AE11B13; Fri, 15 Jan 2016 14:42:07 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id l65so22942380wmf.1; Fri, 15 Jan 2016 06:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a504fexz1WRk4q+DbXhICyvptFY0eFRNv06Wyjij/DY=; b=Um7RafdKolblrk5EhOSB7ofY0vc9YPYXGpLn9IuScYuLtlRkawEocW6ETfe0moEQgu r1JVf8cHWQNGWUy+JBSZhb3+3o43XNHulfqdpWwFoVc6+fPMh5aMFHwEmYWdAGBmmjTl 1V/TPEEgVZuUVBmjBW/w8c9e8uzUPzIbYMB7+0a8+/raEJJcAd69OacxcXqgYXzi6nBf EEK5RW6vz/3qWXc0Ab7t5i2AXUwwz4Q7hioAENRhlMghDdRe/kjPbO6SCQNd8UMc8xrK wAHRNuFQPAlrJGNlh5WtiHaMU02ReqCAsJX7Kl+5WTzIu86iCrHw/s6oeyqvbqUNNHHe 9WkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a504fexz1WRk4q+DbXhICyvptFY0eFRNv06Wyjij/DY=; b=PMBdLKh0YownzuZiLOUmsu49WPlljZwBAuM/pYBIv4OqEKfCaQEPly3TcB6UwLD1e/ QvYGPy+9MSMozUWKkBg2IARdM64gkdY46n1PaZveODB4f1JuAtnjZZ5soAKFGyxktRfT SFRubocIPZGEMUNBvMm02quaOrxNfkCf3e3nJ8urt4szuHcBuRMQBFDqY+aAemd5adMM pu5ONfSs40hf2DoburNhAfP+fAA7IAkOOsDpqMGPvXNYgmlj7qoIGRHttGvgZ/e2DNKs lTZdmdFx0UhY0/DPPNvaiz3Fd/9Etixu61YIlAuuUQNRmyTKuzTXAoCWFgoHLUynbgUq zP2A== X-Gm-Message-State: ALoCoQl1IxyAKwwLcOXsGYNO1hqbprOnup1TEa4dhIoZH7RwrFPoOE7nr4AJ+KkGnwZAkO8ULRq+skWGzcQyBpgg9aN30Hmj6w== MIME-Version: 1.0 X-Received: by 10.194.117.5 with SMTP id ka5mr10578274wjb.20.1452868925816; Fri, 15 Jan 2016 06:42:05 -0800 (PST) Received: by 10.28.55.132 with HTTP; Fri, 15 Jan 2016 06:42:05 -0800 (PST) In-Reply-To: <569900CD.2040003@metricspace.net> References: <9418E44F-114E-4ABA-A32D-416297BCDA9F@metricspace.net> <56985C6A.6040209@multiplay.co.uk> <569900CD.2040003@metricspace.net> Date: Fri, 15 Jan 2016 14:42:05 +0000 Message-ID: Subject: Re: EFI/ZFS Update: successful tests, need more complex vdevs From: krad To: Eric McCorkle Cc: Renato Botelho , Steven Hartland , freebsd-hackers@freebsd.org, Gabor Radnai X-Mailman-Approved-At: Fri, 15 Jan 2016 15:14:31 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:42:07 -0000 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 wrote: > On 01/15/16 06:51, Renato Botelho wrote: > >> On Jan 15, 2016, at 00:41, Steven Hartland >>> 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" >