From owner-freebsd-stable@freebsd.org Sun Dec 2 17:59:16 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA2D9132936F for ; Sun, 2 Dec 2018 17:59:16 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mr85p00im-zteg06021601.me.com (mr85p00im-zteg06021601.me.com [17.58.23.187]) (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 CE3FB76E1C for ; Sun, 2 Dec 2018 17:59:15 +0000 (UTC) (envelope-from tsoome@me.com) Received: from nazgul.lan (148-52-235-80.sta.estpak.ee [80.235.52.148]) by mr85p00im-zteg06021601.me.com (Postfix) with ESMTPSA id B372A4000E5; Sun, 2 Dec 2018 17:59:13 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Subject: Re: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2 From: Toomas Soome In-Reply-To: Date: Sun, 2 Dec 2018 19:59:11 +0200 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0F5FCC70-EADB-4F9E-A391-F1A73BE5608F@me.com> References: <22f5b92a09ea4d62ac3feb74457067f7@ijs.si> <5EEBAFC0-4FA3-4219-A918-7376F4223656@me.com> To: Mark Martinec X-Mailer: Apple Mail (2.3445.101.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-02_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1812020172 X-Rspamd-Queue-Id: CE3FB76E1C X-Spamd-Result: default: False [-5.27 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[me.com]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[187.23.58.17.list.dnswl.org : 127.0.5.2]; DKIM_TRACE(0.00)[me.com:+]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; MX_GOOD(-0.01)[cached: mx1.mail.icloud.com]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; RECEIVED_SPAMHAUS_PBL(0.00)[148.52.235.80.zen.spamhaus.org : 127.0.0.10]; IP_SCORE(-1.07)[ip: (-3.46), ipnet: 17.58.16.0/20(-0.96), asn: 714(-0.85), country: US(-0.09)]; FREEMAIL_ENVFROM(0.00)[me.com]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[me.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2018 17:59:17 -0000 > On 2 Dec 2018, at 01:11, Mark Martinec = wrote: >=20 > 2018-11-29 18:43, Toomas Soome wrote: >> I just did push biosdisk updates to stable/12, I wonder if you could >> test those bits=E2=80=A6 >=20 > Thank you! I haven't tried it yet, but I wonder whether this fix was > already incorporated into 12.0-RC3, which would make my rescue easier. >=20 > Otherwise I can build a stable/12 on another host and transplant > the problematic file(s) to the affected host - if I knew which files > to copy. >=20 > I wonder also, if the today's posting by cksalexander@q.com on the > freebsd-stable ML titled "FreeBSD-12.0-RC3-i386-disc1.iso does not = boot" > could be describing the same problem? >=20 > Mark >=20 The files are /boot/loader* binaries - to be exact, check which one is = linked to /boot/loader. I can provide binaries if needed. Can not tell about post in freebsd-stable - it simply does not provide = enough information. rgds, toomas >=20 >>> On 29 Nov 2018, at 17:01, Mark Martinec = wrote: >>> After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 = (amd64, >>> zfs, bios), I tried my luck with one of our production hosts, and = ended up >>> with a stuck loader after rebooting with a new kernel (after the = first >>> stage of upgrade). >>> These were the steps, and all went smoothly and normally until a = reboot: >>> freebsd-update upgrade -r 12.0-RC2 >>> freebsd-update install >>> shutdown -r now >>> While booting, the 'BTX loader' comes up, lists the BIOS drives, >>> then the spinner below the list comes up and begins turning, >>> stuttering, and after a couple of seconds it grinds to a standstill >>> and nothing happens afterwards. >>> At this point the ZFS and the bootstrap loader is supposed to >>> come up, but it doesn't. >>> This host has too zfs pools, the system pool consists of two SSDs >>> in a zfs mirror (also holding a freebsd-boot partition each), the >>> other pool is a raidz2 with six JBOD disks on an LSI controller. >>> The gptzfsboot in both freebsd-boot partitions is fresh from 11.2, >>> both zpool versions are up-to-date with 11.2. The 'zpool status -v' >>> is happy with both pools. >>> After rebooting from an USB drive and reverting the /boot directory >>> to a previous version, the machine comes up normally again >>> with the 11.2-RELEASE-p4. >>> I found a file init.core in the / directory, slightly predating the >>> last reboot with a salvaged system - although it was probably not >>> a cause of the problem, but a consequence of the rescue operation. >>> It is unfortunate that this is a production host, so I can't play >>> much with it. One or two more quick experiments I can probably >>> afford, but not much more. Should I just first wait for the >>> official 12.0 release? Should I try booting with a 12.0 on USB >>> and try to import pools? Suggestions welcome. >>> Now that the /boot has been manually restored to the 11.2 state, >>> A SECOND QUESTION is about freebsd-update, which still thinks we are >>> in the middle of an upgrade procedure. Trying now to just update >>> the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains: >>> # uname -a >>> FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 >>> # >>> # freebsd-version >>> 11.2-RELEASE-p4 >>> # >>> # freebsd-update fetch >>> src component not installed, skipped >>> You have a partially completed upgrade pending >>> Run '/usr/sbin/freebsd-update install' first. >>> Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway. >>> So what is the right way to get rid of all traces of the >>> unsuccessful upgrade, and let freebsd-update believe we are cleanly >>> at 11.2-p4 ? Removing /var/db/freebsd-update did not help. >>> Mark > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"