Dual boot: TrueOS (and Trident) both corrupt the GPT header at boot time (versions 17.12, 18.03, 18.12+)

[allentiak]

Hi,
Possible duplicate of #15...

Below there is a copy of my comment on that bug.
#15 (comment)

---

I am having similar symptoms on a Dell Precision M3800 when trying to reboot with Debian testing...
The partition table (GPT+UEFI) "disappears", somehow.

This happens either:

1. after (successfully) finishing the installation (see https://www.trueos.org/handbook/install.html#installation-finished).
2. (if I restore the partitions afterwards), after each time I boot into TrueOS.

Affected TrueOS versions: 17.12 (stable), 2017.12.30 (unstable).
The computer already has Debian testing installed.

BTW: Once I restore the partitions, rEFInd works fine.

This problem only happens after booting into TrueOS. As long as I don't access it, I can use Debian normally.

@kmoore134 (or someone else) Could you please elaborate on how could I open a terminal during install, or on how to log the install process, so I could provide with proper logs, please? I haven't found the relevant info in the TrueOS handbook, and [Alt+{F1-F4}] does not work...

[digitalist]

I once managed to ctrl+c out of installer, but it seems it was pure luck or very fast fingers - it didn't reboot

Maybe we should add a patch to allow quit to console without autoreboot?

[allentiak]

I found a workaround to the problem: to restore the GPT partition table backup.

I have just discovered what was wrong: the installer somehow corrupts the GPT table.
After the installer reboots the machine for the first time, it renders the disk unbootable.

After restoring the GPT partition table backup, I can boot normally into Debian (not into TrueOS, though; each time I do it triggers the bug again).

As this bug happens on every reboot, it renders TrueOS unusable.
Present in both TrueOS 17.12 and 18.03.

Below is the log of what I did.

Partition List:
p1: EFI
p2: ext4 (root)
p3: Linux-swap
p4: ext4 (home)
p5: ZFS
p6: ZFS-swap

root@sysresccd /root % gdisk 
GPT fdisk (gdisk) version 1.0.1

Type device filename, or press <Enter> to exit: 
root@sysresccd /root % gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.1

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Caution! After loading partitions, the CRC doesn't check out!
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: damaged

Found invalid MBR and corrupt GPT. What do you want to do? (Using the
GPT MAY permit recovery of GPT data.)
 1 - Use current GPT
 2 - Create blank GPT

Your answer: 1

Command (? for help): p
Disk /dev/sda: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): BAF22793-BCD9-8349-A200-0C0773CF380B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 238189 sectors (116.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1026047   500.0 MiB   EF00  
   2         1026048        98682879   46.6 GiB    8301  
   3        98682880       161183743   29.8 GiB    8200  
   4       161183744       897814527   351.3 GiB   8301  
   5       897814528       966187007   32.6 GiB    A504  
   6       966187008       999979007   16.1 GiB    A502  

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sda.
The operation has completed successfully.
root@sysresccd /root % gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): BAF22793-BCD9-8349-A200-0C0773CF380B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 238189 sectors (116.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1026047   500.0 MiB   EF00  
   2         1026048        98682879   46.6 GiB    8301  
   3        98682880       161183743   29.8 GiB    8200  
   4       161183744       897814527   351.3 GiB   8301  
   5       897814528       966187007   32.6 GiB    A504  
   6       966187008       999979007   16.1 GiB    A502  

Command (? for help): q

[allentiak]

@pkgdemon Could you take a look at this, please?

[pkgdemon]

@allentiak I am not sure I can help here. I don't really have the cycles to test dual boot scenarios, and do not have much expertise in this area. This seems like something we should really look into however, and I will pass this along at the next TrueOS meeting. Have you by chance tried stock FreeBSD to see if the behavior is the same?

[allentiak]

On Mon, 18 Jun 2018 at 23:12, Joe Maloney ***@***.***> wrote: @allentiak <https://github.com/allentiak> I am not sure I can help here. I don't really have the cycles to test dual boot scenarios, and do not have much expertise in this area. This seems like something we should really look into however, and I will pass this along at the next TrueOS meeting.

Thank you very much for your reply, Joe! Have you by chance tried stock FreeBSD to see if the behavior is the same?

Not really. But I could try to find the time to give it a try. When is the next TrueOS meeting?

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1541 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB1U-QC_vkb3-iEqYNjQI4A-Xy8Uzcg2ks5t-F4SgaJpZM4S0pLc> .

[allentiak]

I've just realized I opened this bug in "trueos-core", and not in "trueos"...
Should I move it there?

[pkgdemon]

@allentiak Keeping the bug here for now is probably best.

[allentiak]

On Mon, 18 Jun 2018 at 23:12, Joe Maloney [email protected] wrote:

Have you by chance tried stock FreeBSD to see if the behavior is the same?

Not really. But I could try to find the time to give it a try before that meeting, in order to provide the necessary feedback...

@pkgdemon: When is the next TrueOS meeting?

[pkgdemon]

@allentiak We did not meet this week due to others out of office. I believe we will meet next this Friday on 06-29-18.

[allentiak]

I don't think I will be able to test this before that date. However, I will definitely have the time to do it whithin the following two weeks (around the 15th/July/2018). Would that be OK?

[pkgdemon]

@allentiak no problem I will keep an eye on this ticket.

[allentiak]

@pkgdemon Could you please check #1554? I would like to test this with release 18.06...

[allentiak]

@pkgdemon As #1554 is still open, I only tried this again with Project Trident's Beta 2 (2018.09.06). I can confirm that this bug is still present there.

[ericbsd]

This ghostbsd/pc-sysinstall@ecd8fec was faulty and when I am confident it will not break TrueOS and other projects I will add the code to the TrueOS code.

[allentiak]

Hi, Eric! (@ericbsd)

Thanks for your quick reply. Please remember to mention me when you add the code. I would really like to install GhostBSD on a dual boot with Debian.

Best,
Leandro

[allentiak]

This also happens with Trident 19.05