VM images for 12.0-CURRENT showing checksum failed messages

[Kirk McKusick]

> Date: Wed, 18 Oct 2017 16:40:22 +0000
> From: Glen Barber <gjb at FreeBSD.org>
> To: John Baldwin <jhb at freebsd.org>
> Cc: freebsd-current at freebsd.org, David Boyd <David.Boyd49 at twc.com>,
>         "mckusick at mckusick.com" <mckusick at mckusick.com>
> Subject: Re: VM images for 12.0-CURRENT showing checksum failed messages
> 
> 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 displays
>>>>> many checksum failed messages when booted. (see attachment).
>>>>>
>>>>> I think this started about 20170925.
>>>>>
>>>>> I have VirtualBox VM's running 10.4-STABLE, 11.1-STABLE and 12.0-
>>>>> CURRENT.
>>>>>
>>>>> Only the 12.0-CURRENT image exhibits this behavior.
>>>>>
>>>>> This is easily fixed by "fsck -y /" in single-user mode during the boot
>>>>> process.
>>>>>
>>>>> I can test any updates at almost any time.
>>>>
>>>> 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 filesystem in VM images for snapshots?
>>>> (In this case it appears to be a .vmdk image)
>>>>
>>>
>>> mkimg(1) is used.
>>
>> Does makefs generate the UFS image fed into mkimg or does mkimg generate the
>> UFS partition itself?
> 
> Sorry, I may have understated a bit.
> 
> First, mdconfig(8) is used to create a md(4)-backed disk, onto which
> newfs(8) is run, followed by the installworld/installkernel targets.
> 
> Next, mkimg(1) is used to feed the resultant md(4)-based <format>.img
> filesystem (after umount(8)) to create the final output image.
> 
> Glen

Glen,

Can you try running fsck on the md(4) disk after you do the unmount to
see if it finds any problems (`fsck /dev/md0')? If that comes up clean
(as it should), then I can investigate what it is about mkimg that causes
problems. If fsck finds problems, then there is an issue in the base UFS
infrastructure.

	Kirk McKusick