search

ghostbsd / issues

Issue tracker for GhostBSD
BSD 2-Clause "Simplified" License
2 stars 1 forks source link

Dual Boot: GhostBSD corrupts the protective MBR #79

Open allentiak opened 4 years ago

allentiak commented 4 years ago

Summary

I am trying to dual boot GhostBSD with Debian. After a successful GhostBSD 20.04.1 install (on a ZFS partition), every time I boot into GhostBSD, it corrupts the protective MBR of my hard drive.

I have verified this bug in GhostBSD graphical installation on a partition (both with rEFInd boot manager and FreeBSD UEFI loader). I haven't been able to reproduce this bug on FreeBSD.

When I say "successful GhostBSD install", I mean that, after installing GhostBSD, both rEFInd and FreeBSD UEFI loader work perfectly... as long as I don't choose GhostBSD.

I have been dealing with this bug (in a way or another) since the times TrueOS was desktop-oriented... First, the OS corrupted the GPT partition table (see https://github.com/trueos/trueos-core/issues/1541); now it corrupts the protective MBR...

I found a workaround that restores my protective MBR, but if I boot into GhostBSD, the bug triggers again.

Here are the pc-sysinstall installation logs:

Due to https://github.com/ghostbsd/gbi/issues/26, I cannot confirm whether this bug belongs to gbi or pc-sysinstall.

My system

Partition layout

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): q

root@sysresccd /root % fsarchiver probe detailed 
[======DISK======] [=============NAME==============] [====SIZE====] [MAJ] [MIN]
[sda             ] [SAMSUNG SSD SM84               ] [   476.94 GB] [  8] [  0]
[sdb             ] [Flash Disk                     ] [   956.00 MB] [  8] [ 16]

[=====DEVICE=====] [==FILESYS==] [======LABEL======] [====SIZE====] [MAJ] [MIN] [==============LONGNAME==============] [=================UUID=================] 
[loop0           ] [squashfs   ] [<unknown>        ] [   587.99 MB] [  7] [  0] [/dev/loop0                          ] [<unknown>                             ] 
[sda1            ] [vfat       ] [<unknown>        ] [   512.00 MB] [  8] [  1] [/dev/sda1                           ] [C50C-E0C8                             ] 
[sda2            ] [ext4       ] [<unknown>        ] [   244.00 MB] [  8] [  2] [/dev/sda2                           ] [7d7fca75-1d45-49b4-9258-99dedfb49fc6  ] 
[sda3            ] [LVM2_member] [<unknown>        ] [    68.92 GB] [  8] [  3] [/dev/sda3                           ] [MahmDQ-frLo-hE3P-eiQC-xQZo-3eDP-rSexy2] 
[sda4            ] [ext4       ] [<unknown>        ] [   338.35 GB] [  8] [  4] [/dev/sda4                           ] [5b94c943-c68d-4a06-b735-da85645692a4  ] 
[sda5            ] [<unknown>  ] [<unknown>        ] [    52.33 GB] [  8] [  5] [/dev/sda5                           ] [<unknown>                             ] 
[sda6            ] [<unknown>  ] [<unknown>        ] [    16.60 GB] [  8] [  6] [/dev/sda6                           ] [<unknown>                             ] 
[sdb1            ] [iso9660    ] [sysresccd_zfs    ] [   719.00 MB] [  8] [ 17] [/dev/sdb1                           ] [2018-05-12-04-07-38-00                ] 
[dm-0            ] [ext4       ] [<unknown>        ] [    15.24 GB] [253] [  0] [/dev/mapper/debian-var              ] [e7b117d0-b915-47dc-a9ff-d7bad647ea96  ] 
[dm-1            ] [ext4       ] [<unknown>        ] [     2.05 GB] [253] [  1] [/dev/mapper/debian-tmp              ] [92f21c45-9dcd-4377-acd5-8c6a40dabd30  ] 
[dm-2            ] [swap       ] [<unknown>        ] [    15.98 GB] [253] [  2] [/dev/mapper/debian-swap             ] [765a9a13-5844-443b-992d-90f6787cb8b4  ] 
[dm-3            ] [ext4       ] [<unknown>        ] [    35.64 GB] [253] [  3] [/dev/mapper/debian-root             ] [0bf5ca7c-3b95-4e98-9da0-b3c1582c1398  ]

EFI partition content (as seen from Debian)

# tree /boot/efi/EFI/
/boot/efi/EFI/
└── debian
    ├── BOOTX64.CSV
    ├── fbx64.efi
    ├── grub.cfg
    ├── grubx64.efi
    ├── mmx64.efi
    └── shimx64.efi

For reproducibility reasons, I always delete the folders GhostBSD adds to my EFI partition before reinstalling it. This is, # rm -rf /boot/efi/EFI/{ghostbsd,BOOT}.

Partition layout (once the bug is triggered)

root@sysresccd /root % fsarchiver probe detailed 
[======DISK======] [=============NAME==============] [====SIZE====] [MAJ] [MIN]
[sda             ] [SAMSUNG SSD SM84               ] [   476.94 GB] [  8] [  0]
[sdb             ] [Flash Disk                     ] [   956.00 MB] [  8] [ 16]

[=====DEVICE=====] [==FILESYS==] [======LABEL======] [====SIZE====] [MAJ] [MIN] [==============LONGNAME==============] [=================UUID=================] 
[loop0           ] [squashfs   ] [<unknown>        ] [   587.99 MB] [  7] [  0] [/dev/loop0                          ] [<unknown>                             ] 
[sdb1            ] [iso9660    ] [sysresccd_zfs    ] [   719.00 MB] [  8] [ 17] [/dev/sdb1                           ] [2018-05-12-04-07-38-00                ]

Workaround

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

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

Found valid GPT with corrupt MBR; using GPT and will write new
protective MBR on save.

Command (? for help): p
Disk /dev/sda: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 157F8209-23C9-4663-98D9-40AED3C143A7
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 4717 sectors (2.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  efi
   2         1050624         1550335   244.0 MiB   8300  debian-boot
   3         1550336       146081791   68.9 GiB    8E00  debian-physical-volume
   4       146081792       855652351   338.3 GiB   8300  home
   5       855652352       965398527   52.3 GiB    A504  
   6       965398528      1000212479   16.6 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.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
allentiak commented 4 years ago

@ericbsd Is there anything I could help you with so this bug get triaged faster?

ericbsd commented 4 years ago

To be honest with that problem I am not even sure were to start.

allentiak commented 4 years ago

@ericbsd Whereas I have no clue about BSD internals, I have an idea that might work...

The first thing to discover is whether this alteration is performed at boot time or at poweroff time. I can help you with this (see below). Once we know that for sure, I could help you analyzing GhostBSD's scripts to discover where the bug is.

As I have said earlier on, I already have a dual boot scenario with Debian working. I could simply try updating it to GhostBSD's latest version (20.08.04, AFAIK).

In order to know whether this is a boot or poweroff time bug, I could try forcefully shutting my system down, and rebooting it later on. If the problem persists, the bug is in GhostBSD's init scripts. Otherwise, it's in the poweroff scripts. In any case, you should lead the analysis. (I am happy to help you with this, but remember I have zero knowledge about FreeBSD/GhostBSD's internals - so I will need guidance on this.)

@ericbsd What do you think about this?

ericbsd commented 3 years ago

I know this Is for MBR, but is GPT still corrupted?

ericbsd commented 10 months ago

issue moved from ghostbsd/ghostbsd-src to ghostbsd/issues