You are not logged in.
Hi all,
I discovered that there's some garbage data at the beginning of my disk that contains at least a section of a GRUB bootloader. I used to have an MBR-style partition table with GRUB installed in said MBR, but I've since nuked the disk in favor of GPT and UEFI. If I enable MBR-style booatloaders in the BIOS, I found that the old GRUB attempts to boot with all kinds of errors.
I know that on an MBR-style partitioning schema, I could run:
dd if=/dev/null of=/dev/sdX bs=446 count=1
But this isn't MBR, it's GPT. Will the same command still work without overwriting GPT partition data?
Offline
The recommended command is:
# sgdisk --zap-all /dev/sd<x>
https://wiki.archlinux.org/index.php/Be … tion_table
However, if you wish to boot a GPT disk via BIOS, you will need a "BIOS Boot Partition" (type "EF02" in gdisk)...
https://wiki.archlinux.org/index.php/GR … structions
And then install GRUB to this partition using:
# grub-install --target=i386-pc --recheck /dev/sda
And then generate the grub.cfg
https://wiki.archlinux.org/index.php/Be … guide#GRUB
Last edited by Head_on_a_Stick (2014-11-24 21:50:16)
Freedom for Öcalan!
Offline
I think you misunderstood: everything works fine now, but if I enable "Legacy" boot mode (a.k.a. MBR) in the BIOS, it tries to boot GRUB from leftover garbage when it was installed in the MBR. I don't want to erase my partition tables, and am currently using UEFI/GPT/GRUB via a ef00 partition at the beginning of my disk. It all works now, I just want to clean up the garbage.
Offline
You cannot boot up in Legacy mode with a GPT disk unless you have a BIOS boot partition for GRUB to install to -- please read the links I posted.
EDIT: You don't have to erase your partition table -- just use gdisk to add a new partition of type ef02 at sectors 34-2047 (these will be "free") and run the GRUB install command I posted.
Last edited by Head_on_a_Stick (2014-11-24 22:16:14)
Freedom for Öcalan!
Offline
More answer are found here.
IMHO, GPT doesn't reside in the MBR, so clearing the first 446 bytes is harmless for both partitioning system. Even the MBR partition table start after 446th byte.
do it good first, it will be faster than do it twice the saint
Offline
I'm not trying to use MBR for a bootloader or a partitioning scheme and am not trying to use MBR boot on GPT. I understand that GRUB will not boot from the MBR with a GPT partitioning scheme unless I have a BIOS partition, but this is also not what I'm trying to do. I have UEFI and GPT on my system and it runs fine, and plan to keep it that way.
If switch my BIOS to boot from the MBR (with UEFI and GPT), it happens to unsuccessfully attempt to boot GRUB from what was in the MBR. I don't want to boot GRUB from the MBR; I want to do the opposite: erase whatever is in where the MBR used to be so that it won't attempt to boot a mangled system. It's nit-picky, I know.
I backed-up and nuked the first 446 bytes of my disk, but GRUB seems to still be present somehow. I'll double-check my work and ensure that I really did nuke it.
Offline
@OP: with GPT disks, the MBR 512 byte header is kept in place to avoid the partition being wiped by non-GPT aware programs.
It's not "garbage" in need of cleaning up -- it does serve a function, it just won't boot from it.
Freedom for Öcalan!
Offline
If usually is used in UEFI mode, I don't see much need to modify the MBR.
In the very rare case, one may write a LM code return into the first bytes. That will tell to return to BIOS routine call.
For your curiosity see wikipedia MBR
do it good first, it will be faster than do it twice the saint
Offline