Joined: 08 Mar 2004
Location: Woonsocket, RI
|Posted: Sun Oct 27, 2013 11:12 pm Post subject: Re: uefi and gpt design flaws?
|_______0 wrote: |
|I was wondering about the fact that GPT partition keeps some info at the end of the hard drive without being visible by any partition program is kinda messed up. |
The information isn't really invisible. The data at the end of the disk is a backup of the data at the start of the disk. A properly-designed partitioning program will compare the two when it starts and warn you if there's a mismatch. Certainly my own GPT fdisk (gdisk, cgdisk, and sgdisk) does this, and I think that parted does, too. The idea, as with any backup, is that if the original is damaged (say, by an accident with the dd utility), the backup can be used to restore the partition table. This is a significant improvement over the old MBR scheme, in which overwriting a single sector will trash your partition table.
|An accidental resizing can destroy an hdd? |
Most hard disks can't be resized. For RAID arrays or the like that can be resized, any decent GPT partitioning program will detect the change, warn you about it, and enable you to move the backup partition table. Both GPT fdisk and parted do this.
|And also uefi having to have it's own 500MB partition is kinda wrong. mbr at least is kept separate and has a predictable location and size leaving the whole drive free to use as one would like. |
I assume you're referring to the EFI System Partition (ESP). It needn't be 500MB in size, although it can be. Use of an ESP for storing boot loaders is a huge advance over the primitive MBR system. Under EFI, you can store as many boot loaders as you like and they don't conflict with one another. With MBR, they all battle for supremacy in the boot code section of the MBR, and getting them to coexist can be a challenge, especially if you don't know what you're doing. What's more, large BIOS boot loaders, such as GRUB, typically install parts of themselves in officially-unallocated sectors of the disk. The problem with this is that other utilities (such as disk encryption software) often tries to take over the same space, so you can end up with a non-booting system if you try to install another program that wants to use that space.
The weakness of EFI on this score is in the use of NVRAM to store boot loader preferences. If the NVRAM is wiped or if the disk is moved to a new computer, it will become unbootable unless there's a boot loader that uses the fallback filename (EFI/BOOT/bootx64.efi, at least on x86-64 systems). Fortunately, the better EFIs offer a way to launch boot loaders by filename, which is a useful workaround.
|All of a sudden is impossible to dd/clone uefi partitioned drives in sane way. |
A "dd" clone will still work if the new disk is as big as or bigger than the original; however, using a disk partitioning tool to adjust the location of the backup partition data is advisable. So is adjusting the GUID values so that the disks have truly unique GUIDs. Both tasks can be accomplished with a single command:
|sgdisk -e -G /dev/sdb |
Change /dev/sdb as necessary, of course.
Of course, filesystem-specific tools are likely to do disk cloning more efficiently than dd, and if the target disk is significantly bigger than the source you'd probably want to do something that will copy the filesystem(s) onto larger partition(s) from the start, so I'm not sure dd is the best tool for this job even on an MBR disk.