GEOM has amnesia

Sat Apr 1 00:09:09 UTC 2017

On Sat, 1 Apr 2017 01:36:54 +0300 "Andrey V. Elsukov" <bu7cher at yandex.ru> wrote

> On 01.04.2017 00:58, Chris H wrote:
> > So. I spin up an old 11 server I have sitting in the closet, with
> > this external drive attached to it. I do *NOT* get the corrupt GPT
> > message. So I blank/partition/newfs the external drive &&
> > mount the partitions individually to /mnt && restore again. When I
> > reboot to the external drive still connected to the old 11 server,
> > I do *NOT* receive the corrupt GPT message. WooHoo! I think.
> > So I re-attach the drive to the new 12 server. Reboot, and can't
> > boot to it && get the corrupt GPT message.
> > 
> > GEOM seems to be broken in 12, maybe even (recent) 11. As the 11
> > server I used for testing is ~9 mos out.
> > 
> > What can I do to (help?) fix this mess?
> 
> Just a guess, BIOS on the system, where FreeBSD 12 is installed
> overwrites the last sector of your disks.
> I have seen such reports, and always this was the cause.
> 
> You can do the following steps to make sure:
> * on the old 11 system with the sane GPT save the last sector to some file.
> * reboot, save the sector again to another file and compare both files.
> * attach the disk to your 12 system, GPT should become corrupted. Save
> the last sector and compare with previous file.
> 
> You can look at the hexdump of this file, and probably it should be
> obviously what is extraneous in the data.
> 
> To save the last sector you need to know its number, it can be found by
> this command:
> 
>  # diskinfo da0 | awk '{print $4-1}'
> 
> Then use dd to save it:
> 
>  # dd if=/dev/da0 of=./sector skip='diskinfo da0 | awk '{print $4-1}''
>  # hexdump -C ./sector
> 
> You should see something like this:
> 00000000  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI
> PART....\...|
    ...
> *
> 00000200
> 
> The dump of correct GPT header should not have more lines.
> 
Andrey, Thank you!

OK I'm having trouble with the concept. But *indeed* the
output indicates *always* good on the 11 server (confirmed
following your steps above).
Moving it to the new 12 server, returns corrupt secondary GPT
table message && hexdump output is:

00000000  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000010  65 12 5c 16 00 00 00 00  2f 60 38 3a 00 00 00 00  |e.\...../`8:....|
00000020  01 00 00 00 00 00 00 00  28 00 00 00 00 00 00 00  |........(.......|
00000030  07 60 38 3a 00 00 00 00  91 e5 f5 c1 0d 16 e7 11  |.`8:............|
00000040  8d 49 00 24 81 ce ba 87  08 60 38 3a 00 00 00 00  |.I.$.....`8:....|
00000050  80 00 00 00 80 00 00 00  00 00 00 00 86 da fa 98  |................|
00000060  61 66 13 80 09 fe d0 54  35 59 db 8e 43 b8 7e 37  |af.....T5Y..C.~7|
00000070  c9 77 0e 9d 35 fd 45 04  de 9a d3 ff 30 83 8f b4  |.w..5.E.....0...|
00000080  b9 84 1d 41 59 44 ef fd  fd 89 3e 1e 9e c6 23 e1  |...AYD....>...#.|
00000090  83 17 a7 53 e1 e7 51 c8  5f 87 2b 76 f8 60 c4 ca  |...S..Q._.+v.`..|
000000a0  e2 3e 1e eb 12 69 12 32  33 c3 29 42 d6 aa 1a bc  |.>...i.23.)B....|
000000b0  90 af fc 4f d0 e1 58 c3  52 f5 5c 54 ca bd 05 8c  |...O..X.R.\T....|
000000c0  89 04 8d 7b 11 a3 b2 1e  07 6e fe 1b 79 00 c0 15  |...{.....n..y...|
000000d0  1a 39 79 28 91 a3 e8 24  93 1a 35 ef e9 f8 e5 17  |.9y(...$..5.....|
000000e0  e6 93 f1 a2 5d aa 3e 2f  40 dc b3 17 19 4c f6 05  |....].>/@....L..|
000000f0  cf 75 3e 88 ad a4 2a 68  8c 04 c4 99 a1 bb a2 1c  |.u>...*h........|
00000100  9c 8d fe c7 3e e4 cb 56  ce 3d 33 5b 28 a5 c9 45  |....>..V.=3[(..E|
00000110  c7 3f aa e2 1e 98 bc e2  6d 9d 91 12 84 24 d6 13  |.?......m....$..|
00000120  3d b5 14 bd 9a 44 e9 ee  3f b5 91 31 73 86 79 7e  |=....D..?..1s.y~|
00000130  09 bd 4e 01 cb 06 81 b4  41 11 cd cf 97 dd 97 a1  |..N.....A.......|
00000140  a7 73 e5 f7 c5 a4 75 c9  1f 6b 5e 88 fe 1a 92 d2  |.s....u..k^.....|
00000150  3a cc 70 21 1f b8 30 34  b9 0e 5c b2 d0 14 5e 82  |:.p!..04..\...^.|
00000160  56 60 04 35 77 c9 25 04  7a af ce e1 8d 24 37 53  |V`.5w.%.z....$7S|
00000170  a3 0c dd 63 3c 15 fe 9f  a4 46 00 97 c1 b0 27 be  |...c<....F....'.|
00000180  f5 c7 f9 b5 71 9e 1b 90  f7 9c ee 8a 8e 7b 77 61  |....q........{wa|
00000190  23 13 4a 93 0b e0 f0 9e  3f dc 8e 12 f9 19 d3 75  |#.J.....?......u|
000001a0  f2 52 6d bd 12 30 cd bf  0c 91 79 10 1a bd 5b d4  |.Rm..0....y...[.|
000001b0  0f 9c 1b ff 7b 60 74 79  d7 fa bb 02 6f 19 be e4  |....{`ty....o...|
000001c0  06 fd f4 7c cb 05 23 eb  89 2f 7f cc 9b 01 fa f7  |...|..#../......|
000001d0  4c 07 c4 72 55 9f 3d 39  f3 71 64 94 bf 7e 74 b0  |L..rU.=9.qd..~t.|
000001e0  49 80 c1 37 4f 49 91 e0  54 a7 e5 4d 83 8f b8 32  |I..7OI..T..M...2|
000001f0  62 f2 61 50 6f f2 16 05  a4 60 2f 06 be 45 a6 72  |b.aPo....`/..E.r|
00000200

gpart recover da0 && hexdump output from newly captured last
sector:

00000000  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000010  aa 9c 5f 36 00 00 00 00  2f 60 38 3a 00 00 00 00  |.._6..../`8:....|
00000020  01 00 00 00 00 00 00 00  28 00 00 00 00 00 00 00  |........(.......|
00000030  07 60 38 3a 00 00 00 00  91 e5 f5 c1 0d 16 e7 11  |.`8:............|
00000040  8d 49 00 24 81 ce ba 87  09 60 38 3a 00 00 00 00  |.I.$.....`8:....|
00000050  80 00 00 00 80 00 00 00  65 12 5c 16 00 00 00 00  |........e.\.....|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

My problem with your theory; 3 reasons I question it
1) The internal SATA3 disk never experiences this
2) When I first plugged in the external drive, it had ghostbsd
on it, and the server attempted to boot it w/o error. It wasn't
until I blanked/partitioned/newfs'd it, that the trouble(s) manifest
3) This server is brand new hardware and the *only* media that has
ever touched this prior to the anomaly was the FreeBSD install DVD
(I'm trying to eliminate the possibility of VIRII here).

Can you please elaborate on how/why the BIOS should/would modify
boot media && only USB boot media?

Thank you again, Andrey, for all your input on this!

--Chris