From owner-freebsd-current@freebsd.org Tue Feb 7 16:33:38 2017 Return-Path: Delivered-To: freebsd-current@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 C2BA7CD55C0 for ; Tue, 7 Feb 2017 16:33:38 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CC788A4 for ; Tue, 7 Feb 2017 16:33:38 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OL000900J04VS00@st13p35im-asmtp002.me.com> for FreeBSD-current@FreeBSD.org; Tue, 07 Feb 2017 16:33:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1486485203; bh=9eA6gQzsRK5rwxaXNCkrTAN1sZ6d0bRcOEYSzqNChys=; h=From:Content-type:MIME-version:Subject:Date:To:Message-id; b=q8pD1HMY5RH4jLP+FUf1ObPfWDjufAyioBNx1dGCohhMUvNAKmvQZCFnItwgBQ+G+ TC9qcivWf0XCD60YCV8FYteikkLXp/K4rFzgMVkDYr9PL0NcSwQR8F0PiIa+g12JHp 6iMCXylrErbPqNkIlxPFiFEwv86Z7nSta1WPJoBzDzOW52TLEhW+U0XyVWmQSw9NqO Mcva9j1MSAKwam2d0C/LvoyH7pkbQOcTgMUwoOjZA/gSrU1+iVANYAmuhGT3COevQz n4zDagF8hmvcTsC9gcQ+kIdAsfZoFWXbzLIhUnn3WZo6l0TaIbPFI1rk2x+7pUn481 qRjQ3TdugpH2w== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OL0003C4JBLS520@st13p35im-asmtp002.me.com> for FreeBSD-current@FreeBSD.org; Tue, 07 Feb 2017 16:33:23 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-07_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=4 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1702070158 From: Toomas Soome Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: gptzfsboot trouble Date: Tue, 07 Feb 2017 18:33:21 +0200 References: <000d01d2815c$74f1be60$5ed53b20$@btinternet.com> To: FreeBSD-current@FreeBSD.org In-reply-to: <000d01d2815c$74f1be60$5ed53b20$@btinternet.com> Message-id: <26D78147-119E-4BB7-B567-2B2C09C321BE@me.com> X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 16:33:38 -0000 > On 7. veebr 2017, at 18:08, Thomas Sparrevohn = wrote: >=20 > Hi all >=20 >=20 >=20 > Last week I decided to upgrade my FreeBSD installation - it's been a = while > (September 16 was last time). Unfortunately CURRENT does not boot and = cash > in a weird way. Both 11-RELEASE and 12 CURRENT boot loader seems to = attempt > to read blocks that exceeds the physical disk. Initially I through it = was a > hard disk error - but after a "oh" experience I realised that the > "gptzfsboot: error 4 lba 921592" is actually beyond the physical = boundaries > of the disk (300GB disk). In order to rule out different options - I > installed a vanilla 11-RELEASE on the 300G with a simple stripe - it = also > gives the error but does boot - the LBA of the error is slightly = different > on 11 CURRENT and comes up with LBA 921600 >=20 >=20 >=20 > I have scanned all the disks for physical faults and there seems to be = none > and I have tried doing a single disk installation on each disk - they = give > the same error - Does anybody have any idea? Included Photos as = sometimes it > get through to the actual boot menu but then crash in another place >=20 The gptzfsboot does read the backup label from the disk and the GPT = backup label is stored at the end of the disk. The location of the = backup label is in the primary GPT table, alternate sector field. I = wonder if that location is somehow set to bad value=E2=80=A6 rgds, toomas=