The u-boot from these nas devices is not that cracy it just loads the uImage from the partiton that is marked as the first in MBR nothing more
my request is to get sgdisk to support this (gdisk can do this already commands from gdisk r h 1 n 83 y n w y) the important part is the first n in this command sequence "Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N):" this way it becomes the first after the speciefd to adapt gpt parts. omly the first part of the mbr is the importatnt and ist also the only one that got to the mbr


2012/11/22 Antoine Leca <AntoineL@users.sourceforge.net>
Mario Fetka wrote:
> small correction
> fidsk sees it like that when i use the pipe version
>
> --------------------------------------------------------------------------
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sda1   *        2048      616447      307200   83  Linux
> /dev/sda4               1        2047        1023+  ee  GPT
>
> Partition table entries are not in disk order
>
> ------------------------------------------------------
>
> but sgdisk -h 1
>
> creates
>
> -------------------------------------------------------------
> Command (m for help): p
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sda1               1        2047        1023+  ee  GPT
> /dev/sda2            2048      616447      307200   83  Linux
>
>
>
> and with this the u-boot of the device finds the GPT as first part and this
> is not working
> my request was the posiblity to change this also for the sgdisk so that i
> can say the ee GPT disk is not part 1 in mbr
>
This can be awfully complex, and I wonder how can semi-complex cases
could be sorted (and of course, if things are not crystal clear at
design time, the probabilities for bugs + misuses are increasing
steadily...)

For an example, taking your case slightly edited, consider

GenLSPro ~ # sgdisk -p /dev/sda
Disk /dev/sda: 195371568 sectors, 93.2 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): xxxx-yyyyy...
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 195371534
Partitions will be aligned on 2048-sector boundaries
Total free space is 2541 sectors (1240.7 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          616447 300.0 MiB   8300  Linux filesystem
   2          616448       168388607   80.0 GiB    8300  Linux filesystem
   3       168388608       170485759   1024.0 MiB  8200  Linux swap
   4       170485760       195371007   11.9 GiB    8300  Linux filesystem

(I rounded down sd4's size.) There are nine distinct areas across the disk:
Number  Start (sector)    End (sector)  Size       Code  Name
 a                 0               1                     MBR
 b                 1              33                     GPTable
 c                34            2047                     free space
   1            2048          616447 300.0 MiB   8300  Linux filesystem
   2          616448       168388607   80.0 GiB    8300  Linux filesystem
   3       168388608       170485759   1024.0 MiB  8200  Linux swap
   4       170485760       195371007   11.9 GiB    8300  Linux filesystem
 d         195371008       195371534                     free space
 e         195371535       195371567                     alternate GPTable

Now, on what criteria could it be decided that using `sgdisk -H 1` makes area {a+b+c} to be covered under entry #4 typed EE, while the area {2+3+4+d+e} would not be covered? Why not {a+b} instead? Why to not have two EE entries (like some hybrid-making tools are already doing?)

Same questions with `sgdisk -H 2`: should the #4 EE entry covers {a+b+c}, or {a+b+c+1}? Why?

And what to do when the command is `sgdisk -H 4:2` ?
I guess the best answer is "Overtricky, giving up"...


Antoine