From owner-freebsd-stable@freebsd.org Sun May 19 12:59:19 2019 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 86A4215AD550 for ; Sun, 19 May 2019 12:59:19 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from mx.sdf.org (mx.sdf.org [205.166.94.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.sdf.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E5308B972 for ; Sun, 19 May 2019 12:59:17 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from sdf.org (IDENT:bennett@otaku.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id x4JCxFkx001628 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO) for ; Sun, 19 May 2019 12:59:16 GMT Received: (from bennett@localhost) by sdf.org (8.15.2/8.12.8/Submit) id x4JCxFOc012073 for freebsd-stable@freebsd.org; Sun, 19 May 2019 07:59:15 -0500 (CDT) From: Scott Bennett Message-Id: <201905191259.x4JCxFOc012073@sdf.org> Date: Sun, 19 May 2019 07:59:15 -0500 To: freebsd-stable@freebsd.org Subject: Re: 11-STABLE system unbootable after update User-Agent: Heirloom mailx 12.5 6/20/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0E5308B972 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-1.02 / 15.00]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.985,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.994,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[cached: mx.sdf.org]; NEURAL_HAM_SHORT(-0.37)[-0.374,0]; RCVD_IN_DNSWL_NONE(0.00)[20.94.166.205.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; DMARC_NA(0.00)[sdf.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14361, ipnet:205.166.94.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.55)[ip: (-1.77), ipnet: 205.166.94.0/24(-0.88), asn: 14361(-0.05), country: US(-0.06)] 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, 19 May 2019 12:59:19 -0000 On Sat, 18 May 2019 08:02:20 -0500 Scott Bennett wrote: > I have been running 11.2-STABLE for a while at r345498. Last weekend it crashed, >so I took the opportunity to install the most recent build I had lying around, r347182. >I created a new boot environment and installed the r347182 kernel into it, shut the >system down, and rebooted. The new kernel came up and appeared to be working okay, so >I continued with the mergemaster -p -F, make installworld, and mergemaster -F, then >shut it down again, and rebooted. It asked for the GELI key for the boot pool, which >I then entered. The spinning slash cursor appeared and may have changed for one frame >or so, and then I got a message beginning with "BTX" and followed by several lines of >hexadecimal, and then it stopped. I tried it again just to be sure, and the result was >exactly the same. > Does anyone know whether the PMBR boot block or the loader in the freebsd-boot >partition changed between r345498 and r347182? I found no warning in /usr/src/UPDATING ^ I wrote the revision down wrong in my notes. It was really r347183. >about installworld potentially leaving a wasted system, so I don't have a clear idea >of what went wrong, much less whether I missed some instruction somewhere about source >updates. If anyone can lend me a clue here, I would greatlyappreciate it. I only had >one working machine, and now it is only working in a "rescue" mode by booting from a >DVD. (Probably needless to say, but I will burn new DVDs with up-to-date stuff as soon >as my system is working the way it is supposed to again.) > This motherboard is nearly 11 years old and does not boot from USB (in spite of >the BIOS menus say), so at the moment I am logged into SDF by running a long out-of-date >TrueOS installer DVD, which happens to be a pain to get to boot all the way, but I've >figured how to make it do it rather than get stuck with a logo on the screen that never >goes away. Unfortunately, it includes no software to burn a CD or DVD, so I cannot >make a new bootable disk for the time being. I will check email much later today or >this evening. So far I've received one reply, which was not copied to this list, yet the person responding suggested something to try and also adked that I post the result to the list. I would have done both anyway, but the respondent may have desired anonymity on the list, so I am not quoting the message I received. The suggestion was to wait about a second after entering the GELI passphrase and then hit the space bar on my keyboard. At the resulting prompt, I should enter the path given in the prompt, but with ".old" appended. I did that, and YES!!! It worked and proceeded until I had a boot menu. I opted for single-user mode and then responded to further requests for GELI passphrases until eventually I had a root shell. Being unable to reach the boot menu was a problem hadn't previously even crossed my mind. I certainly hope that doing updates from source in the future will not cause this same booby trap again. At that point I renamed /boot/zfsloader to /boot/zfsloader.bad.r347183 and /boot/zfsloader.old to /boot/zfsloader. I also added a hard link to the latter as /boot/zfsloader.good.r345498. All is still not well, however. In multi-user mode, startx turns the screen black and switches its power setting to standby. After that it remains unresponsive until I log in via a different vt and send SIGHUP to xorg. After a rather lengthy delay (30-60 seconds, at a guess) it returns to the login session on the console vt. I have now commented out the "kld_list="/boot/modules/radeonkms.ko" line in /etc/rc.conf.local in hopes that the next boot will get the scfb driver to take it instead of the radeonkms driver from graphics/drm-next-kmod. If someone knows, is this a case where rebuilding and reinstalling graphics/drm-next-kmod? If so, then I will do that, but I see that the Makefile still appears to use the same distribution file. Many, many thanks to the person who responded with the solution to get past the loader crash!! My system is now getting work done again, and the rest of the new problems can be dealt with on a running system. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************