FreeBSD-10.3-RELEASE-i386-memstick.img installer changes contents of USB flash drive

[Warren Block]

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 <dpchrist at holgerdanske.com> 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.