From owner-freebsd-bugs@freebsd.org Fri Aug 12 08:25:04 2016 Return-Path: Delivered-To: freebsd-bugs@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 2CF6EBB7F09 for ; Fri, 12 Aug 2016 08:25:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0857A1F4C for ; Fri, 12 Aug 2016 08:25:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7C8P3po036302 for ; Fri, 12 Aug 2016 08:25:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 211767] boot1.efi probing doesn't find ZFS pool unless delaying execution of boot1 a few seconds after power on Date: Fri, 12 Aug 2016 08:25:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-BETA4 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: joel@lopes-da-silva.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 08:25:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211767 Bug ID: 211767 Summary: boot1.efi probing doesn't find ZFS pool unless delaying execution of boot1 a few seconds after power on Product: Base System Version: 11.0-BETA4 Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: joel@lopes-da-silva.com CC: freebsd-amd64@FreeBSD.org CC: freebsd-amd64@FreeBSD.org I just installed FreeBSD 11.0-Beta4 on a Mac Mini (Late 2014) with an exter= nal Thunderbolt enclosure that contains two WD Red drives. This is a root-on-ZFS setup, where the 2 drives used in a mirror vdev. For more information on my setup, you can find the exact steps I followed in here: https://github.com/JoeKun/freebsd-configuration/blob/master/documentation/f= reebsd/freebsd.md After switching to the FreeBSD partition for the Mac Boot Manager, when I reboot the Mac Mini, boot1.efi fails with the following output: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 7 block devices.......... done ZFS found no pools UFS found no pools Failed to load '/boot/loader.efi' panic: No bootable partitions found! However, things behave differently if, right when the Mac Mini starts up, I hold the Option key down so the Mac Boot Manager will not immediately start executing boot1.efi, and instead allow the user to change the partition from which to boot. When I do that, and then I just press Enter to proceed booti= ng from the FreeBSD partition, I get straight into the Beastie screen, and Fre= eBSD boots flawlessly. This is 100% reproducible with my hardware setup. It's as if there's some kind of race condition between /boot/boot1.efi prob= ing the block devices and the devices being fully powered on, or started up, or something like that. The mere introduction of this artificial delay allows boot1.efi to successfully find the ZFS pool. Is there a way that we can have boot1.efi sleep for a certain amount of time before probing the block devices? Or maybe try again a couple of times if probing didn't yield anything interesting? --=20 You are receiving this mail because: You are the assignee for the bug.=