From owner-freebsd-questions@freebsd.org Thu Sep 29 13:04:15 2016 Return-Path: Delivered-To: freebsd-questions@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 F3A9CBEC953 for ; Thu, 29 Sep 2016 13:04:15 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C3D81F82 for ; Thu, 29 Sep 2016 13:04:15 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u8TD4Eb6034116 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Sep 2016 07:04:14 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u8TD4DY5034111; Thu, 29 Sep 2016 07:04:14 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 29 Sep 2016 07:04:13 -0600 (MDT) From: Warren Block To: Ian Smith cc: David Christensen , freebsd-questions@freebsd.org Subject: Re: FreeBSD-10.3-RELEASE-i386-memstick.img installer changes contents of USB flash drive In-Reply-To: <20160929014801.W6806@sola.nimnet.asn.au> Message-ID: References: <20160929014801.W6806@sola.nimnet.asn.au> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 29 Sep 2016 07:04:14 -0600 (MDT) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 13:04:16 -0000 On Thu, 29 Sep 2016, Ian Smith wrote: > In freebsd-questions Digest, Vol 643, Issue 3, Message: 17 > On Tue, 27 Sep 2016 14:19:39 -0700 David Christensen wrote: > > On 09/27/2016 08:12 AM, Ian Smith wrote: > > > Just checking .. did you only access the stick by reading with dd? > > > > Correct. > > OK. > > > > Where? > > > > The last block: > > > > # ll > > /mnt/i3000d/data/dpchrist/iso/freebsd/10.3/FreeBSD-10.3-RELEASE-i386-memstick.img > > > > -rw-r--r-- 1 dpchrist dpchrist 691669504 2016/09/25 11:25:37 > > /mnt/i3000d/data/dpchrist/iso/freebsd/10.3/FreeBSD-10.3-RELEASE-i386-memstick.img > > > > # cmp -l > > /mnt/i3000d/data/dpchrist/iso/freebsd/10.3/FreeBSD-10.3-RELEASE-i386-memstick.img > > /dev/sdc > > 691669010 351 235 << ~18 bytes into the last 512-byte block > > 691669011 117 252 > > 691669012 2 351 > > > 691669081 121 0 > > 691669082 235 0 > > 691669083 252 0 > > 691669084 351 0 > > 691669085 0 301 > > 691669086 0 203 > > 691669087 0 127 > > 691669088 0 137 > > 691669089 0 337 > > 691669090 0 24 > [..] > > 691669495 0 227 > > 691669497 0 22 > > 691669498 0 163 > > 691669499 0 362 > > 691669500 0 372 > > 691669501 0 221 > > 691669502 0 230 > > 691669503 0 122 > > 691669504 0 256 > > cmp: EOF on > > /mnt/i3000d/data/dpchrist/iso/freebsd/10.3/FreeBSD-10.3-RELEASE-i386-memstick.img > > Right, so most of the last sector was updated. I'm no good at octal .. > > We discerned recently that for 10.3, i386 memstick is GPT/EFI and amd64 > is still MBR/BSD. Since only the last sector differs, perhaps something > has updated the secondary GPT during the installation, assuming that a > GPT image should already include one - or at least, the space for one? A secondary copy of the partition table is saved at the end of a GPT-partitioned drive. This is a problem for GPT when a binary image is written to a device that is not exactly the same size as the image. That is pretty much always the case with installer images. gpart can repair ("recover") the backup partition table because it is a copy of the primary partition table. This might be required during an install to make sure the disk works with particularly strict BIOS or UEFI implementations. Although it seems like a reboot would be required afterwards.