From owner-freebsd-stable@FreeBSD.ORG Tue Nov 4 09:35:14 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C72E3DDE; Tue, 4 Nov 2014 09:35:13 +0000 (UTC) Date: Tue, 4 Nov 2014 09:35:11 +0000 From: Glen Barber To: Kevin Oberman Subject: Re: FreeBSD 10.1-RC4 Now Available Message-ID: <20141104093510.GA1226@hub.FreeBSD.org> References: <20141102194344.GA21862@hub.FreeBSD.org> <20141103083214.GG4390@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Release Engineering Team , FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 09:35:14 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 03, 2014 at 11:21:04PM -0800, Kevin Oberman wrote: > On Mon, Nov 3, 2014 at 12:32 AM, Glen Barber wrote: >=20 > > On Sun, Nov 02, 2014 at 04:37:26PM -0800, Kevin Oberman wrote: > > > On Sun, Nov 2, 2014 at 11:43 AM, Glen Barber wrote: > > > I hit a problem right out at the start: > > > # freebsd-update upgrade -r 10.1-RC4 > > > Looking up update.FreeBSD.org mirrors... 5 mirrors found. > > > Fetching metadata signature for 10.0-RC3 from update2.freebsd.org.= =2E. > > > done. > > > Fetching metadata index... done. > > > Fetching 1 metadata patches. done. > > > Applying metadata patches... done. > > > Fetching 1 metadata files... done. > > > Inspecting system... done. > > > > > > The following components of FreeBSD seem to be installed: > > > kernel/generic src/src world/base world/doc world/games > > > > > > The following components of FreeBSD do not seem to be installed: > > > world/lib32 > > > > > > Does this look reasonable (y/n)? n > > > > > > But I do have lib32 installed and have had since the initial > > > installation.No prior upgrade failed. I have no time to look at how > > > freebsd-update tests for components, but something went haywire. > > > > I am unable to reproduce this, and prior to sending the 10.1-RC4 > > announcement email, did test the upgrade path from 10.1-RC2 and > > 10.1-RC3. I've just double-checked on a clean install of 10.1-RC3, and > > only see (as expected on this install) src/src component not installed > > locally. > > >=20 > Ahh. I found a rather nasty oops. It is NOT a problem with RC4. It was a > typo when I intended to go to RC3. Seems I went to 10.0-RC3-p1. I may take > me a while to clean up the mess! Any explanation of how this could have > caused me to lose /usr/lib32 contents would be appreciated >=20 > Sorry for the noise. My suspicion is that 'freebsd-update install' was run twice without a reboot between. freebsd-update(8) uses uname(1) to determine the running userland and kernel to determine the upgrade path, specifically the current running version to the version intended to be run. It uses 'uname -r' for this, so if you do this, you can end up with a very interesting running userland after the reboot. # # fetch update bits for next RC # freebsd-update -r 10.1-RC4 upgrade # # install kernel for next RC(*) # freebsd-update install # # install userland for next RC # freebsd-update install (*) This is important. While you have technically installed the new kernel, it is not the *active* kernel, and freebsd-update(8) (nor any other utility using 'uname -r') cannot tell the difference without a reboot. For example, on my laptop: # uname -ri 11.0-CURRENT NUCLEUS # env UNAME_r=3D12.0-EVILBSD UNAME_i=3DNOTGENERIC uname -ri 12.0-EVILBSD NOTGENERIC While it is purely conjecture this is the situation in your case, "disappearing" /usr/lib32 is certainly an effect of this I have never personally seen before. Was /usr/lib32 in fact gone, or are you basing that on the output of freebsd-update(8)? Glen --5vNYLRcllDrimb99 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUWJ3OAAoJEAMUWKVHj+KTJTkP/3vWsLxuEZb9kFWWQJ7mwYYw S5In1mbH/HOFGPz39K/JlQThgJYTb6ht3sdzfQ/dO5KQ8hDj/aX9vdh/3ZIoSzXn U1EdT0BWOuCC7g0ysH5D/qzRPBUCBngZ2jtVNHQmjh7l78Uk4n4+84YEBni3EIqy +QhLxaKBKHwzpe6tIYsF/isakX90TibJWuNpAe5GLLPuMwVSIM4GfMTSPyb2Pn1g J/tyIrpgAsYMNSmgPpC8upPVnlBwXGARCRF8PNlS9tr67PCtLRR/SMl1qei54rYV 75pDTVNyWa4eE1u9iXOEX26S/ZQyo+jyebEmFWmhI2hWJgm69xQC97intz+T6fuX jo0/xw4rgeKfGpuChJJ09hkqrxRNFa87pP9VL4kZC2b4JZ2QvgWblfzztkgyQleq SZdcHBiYnJE5n3ZAwWE86EmYR4zokDs4/QhmVuBxyVo3lcrQacc3WBL5rUcV2KRh lUzh1tMcnw+8NBlBqmjYDPQswT4EVb15MMemdGYsqHxOi39dVpDGnW7Yg0ZaAQnW YUrLcC3wpixrycqjGvULRYqcZ2j+ODoMNB8VZ+hAjX/3DExzWQzgDH2OTJTk4UE0 EHYVjj2NAl+omHRcu2VpMcW7AnGr5Mid4ATeIBAh+GrJbNWkKnobl6xrf8LlMYH7 pU0/bT6Ss3M40f7a2dau =ZSlj -----END PGP SIGNATURE----- --5vNYLRcllDrimb99--