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>