Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Apr 2017 17:29:50 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 218026] GEOM / gpart: secondary table(s) are consistently corrupted
Message-ID:  <bug-218026-8-KbMG4RKeH6@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-218026-8@https.bugs.freebsd.org/bugzilla/>
References:  <bug-218026-8@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218026

--- Comment #2 from Chris Hutchinson <portmaster@bsdforge.com> ---
OK I'm now on:
FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r316389: amd64
and the problem still exists. I also solicited help on the mailing list.
I received a reply indicating that my BIOS may be the culprit. WTF?!
Well. It indeed appears to be true...
gpart destroy -F da0
gpart create -s GPT da0
gpart add -t freebsd-ufs -l external da0
newfs -U -o time /dev/gpt/external

All of which returned the anticipated results. So I perform the
following, to confirm the suspected culprit (BIOS) on the newly
created drive:

dd if=3D/dev/da0 of=3D./sector skip=3D'diskinfo da0 | awk '{print $4-1}''
(backtics may not show correctly)
Which resulted in the following:

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

Looks as one would anticipate. Let's reboot, and see what happens
(drive plugged in, but NOT mounted)

Results AFTER reboot;
gpart informs me:
kernel: GEOM: da0: the secondary GPT table is corrupt or invalid.
kernel: GEOM: da0: using the primary only -- recovery suggested.
kernel: GEOM: new disk ada0

As suspected, somethings still wrong. Let's look closer;
dd if=3D/dev/da0 of=3D./sector skip=3D'diskinfo da0 | awk '{print $4-1}''
returns:

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.=3D3[=
(..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  |=3D....D..?..1=
s.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.=3D9.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

Whoa! That doesn't look AT ALL the way it should! So, is this the NSA
planting a backdoor, or is it FreeBSD, or???
Can I use a HEX editor to save the extra bits to a separate file, and
attempt to execute it, to see if it's something evil?

Thoughts, suggestions, ... GREATLY appreciated!

--Chris

P.S. A BIG thanks to Andrey V. Elsukov for the insight!

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-218026-8-KbMG4RKeH6>