Re: [Gptfdisk-general] sgdisk and Hybrid without prepend of EFI partition support
Brought to you by:
srs5694
From: Mario F. <mar...@gm...> - 2012-11-24 08:11:12
|
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 <Ant...@us...> > 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 > |