From owner-freebsd-current@freebsd.org Thu Oct 19 13:39:14 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 76F16E3BE02 for ; Thu, 19 Oct 2017 13:39:14 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D9426A523; Thu, 19 Oct 2017 13:39:14 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 58F591334A; Thu, 19 Oct 2017 13:39:13 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Thu, 19 Oct 2017 13:39:11 +0000 From: Glen Barber To: John Baldwin Cc: freebsd-current@freebsd.org, David Boyd , "mckusick@mckusick.com" Subject: Re: VM images for 12.0-CURRENT showing checksum failed messages Message-ID: <20171019133911.GX55623@FreeBSD.org> References: <1508255864.5659.3.camel@twc.com> <1740653.LGy8gQVNSR@ralph.baldwin.cx> <20171018164022.GT55623@FreeBSD.org> <3514274.MTfVLsneXj@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JNs4m2JFMNhdiK2v" Content-Disposition: inline In-Reply-To: <3514274.MTfVLsneXj@ralph.baldwin.cx> User-Agent: Mutt/1.8.2 (2017-04-18) 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: Thu, 19 Oct 2017 13:39:14 -0000 --JNs4m2JFMNhdiK2v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 18, 2017 at 09:49:16AM -0700, John Baldwin wrote: > On Wednesday, October 18, 2017 04:40:22 PM Glen Barber wrote: > > On Wed, Oct 18, 2017 at 09:28:40AM -0700, John Baldwin wrote: > > > On Wednesday, October 18, 2017 03:01:55 PM Glen Barber wrote: > > > > On Wed, Oct 18, 2017 at 07:49:00AM -0700, John Baldwin wrote: > > > > > On Tuesday, October 17, 2017 11:57:44 AM David Boyd wrote: > > > > > > The FreeBSD-12.0-CURRENT-amd64-20171012-r324542.vmdk image disp= lays > > > > > > many checksum failed messages when booted. (see attachment). > > > > > >=20 > > > > > > I think this started about 20170925. > > > > > >=20 > > > > > > I have VirtualBox VM's running 10.4-STABLE, 11.1-STABLE and 12.= 0- > > > > > > CURRENT. > > > > > >=20 > > > > > > Only the 12.0-CURRENT image exhibits this behavior. > > > > > >=20 > > > > > > This is easily fixed by "fsck -y /" in single-user mode during = the boot > > > > > > process. > > > > > >=20 > > > > > > I can test any updates at almost any time. > > > > >=20 > > > > > I wonder if the tool creating the snapshot images wasn't updated = to generate > > > > > cg checksums when creating the initial filesystem. Glen, do you = know which > > > > > tool (makefs or something else?) is used to generate the UFS file= system > > > > > in VM images for snapshots? (In this case it appears to be a .vm= dk image) > > > > >=20 > > > >=20 > > > > mkimg(1) is used. > > >=20 > > > Does makefs generate the UFS image fed into mkimg or does mkimg gener= ate the > > > UFS partition itself? > > >=20 > >=20 > > Sorry, I may have understated a bit. > >=20 > > First, mdconfig(8) is used to create a md(4)-backed disk, onto which > > newfs(8) is run, followed by the installworld/installkernel targets. > >=20 > > Next, mkimg(1) is used to feed the resultant md(4)-based .img > > filesystem (after umount(8)) to create the final output image. >=20 > Hmm, so I suspect you are using an older kernel, but I wonder if you are = also > using an older newfs or a newer newfs? If the newfs is the same as as the > running kernel, then this means that upgrading from a pre-cg-sum kernel t= o a > cg-sum kernel will have similar issues. >=20 I'm somewhat confused by the suggested timestamp this was composed/sent and our out-of-band conversation, but the images are created with the new newfs(8) creating the target filesystem. Glen --JNs4m2JFMNhdiK2v Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEVVuz/A7vpH93hEhKuWzd6q+LXtAFAlnoqv8ACgkQuWzd6q+L XtA5wA//QPrIhZ62t0IIImK1XAbkndSlCB55jWLWGP+BwQIop75PK+us8hJhaY2+ 21lryUBVDQy/bPlDeqC8+XeUXEAOG+AOIeqMTZgQR5VTV3vbjg4OX414l8WH8eZG 6P7X2cpz5gioNGZvEvEB5dtbGQ7MzH2gEJbv5JRJzNSWBCbgMA2OYUo6L+6smDKW bYm0ioWckoiki4N4ZC+BVxrtEGpXLLUWLx8e0N9ek16stLax1rS2NzFtz2ErfKL7 SjB0BKDvpHoHHJamgRsVBWR9iGZD4vgym9C5X5zr9t/315yDLRZLr6dOc6nlrk6P 9B4hTFdSFJw/BsMPSs3qMMPKAN62yxoCADMM9kBfvDqF8VcnbuC1anNPiVSfRQp0 SQc/6rnza2WezzJMzwvTNKifZOcIpMuWMUW7vZL/GQfaz3xxZpEDVTYrQaZVenWV ZRcEjKgm5CpGJ//49mdAFm9rxzk1N9RRmU4yt8Ee4K3eCfCOJZ4UEbNHsXpIm8i2 VEWRAoQ+3Pt4MLwgNKYam9uLSkBUa/bhoIrtBNzn9oicrOrVAQ0CYg3pf1qOI3zP qQuTh/W2PzyOJeRU/7l1xRgBbYmz9OY+bF18QQ9zAwvjsK3wRIlHYjm+JVZODdep HrP0ui7ezaSrsnamy7yDvljfRQWc4OJgRl0JEu1A/JrO72HtIkc= =tRRd -----END PGP SIGNATURE----- --JNs4m2JFMNhdiK2v--