gptfdisk-general Mailing List for GPT fdisk (Page 3)
Brought to you by:
srs5694
You can subscribe to this list here.
2011 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(5) |
Sep
(1) |
Oct
(1) |
Nov
(2) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(1) |
May
(2) |
Jun
(5) |
Jul
(6) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(6) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2014 |
Jan
(17) |
Feb
(3) |
Mar
(3) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(5) |
Jul
|
Aug
|
Sep
(1) |
Oct
(8) |
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(13) |
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(20) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
(22) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Christian E. <chr...@ca...> - 2021-06-08 07:36:15
|
On Tue, Jun 8, 2021 at 9:24 AM Erik Larsson <cat...@gm...> wrote: > > Hi, > > I submitted this patch and tested it on Ubuntu 16.04 PowerPC (big > endian, 32-bit) which had the same string-mangling problem when this fix > is *not* applied... so there's something weird going on. Agreed and thanks for the quick reply. > In general I prefer to keep data read from disk into memory in the > on-disk endianness and transform endianess when retrieving it or setting it. > gptfdisk does not do this but instead byteswaps the fields back and > forth in the structures that were read from disk. This is error-prone > and can lead to on-disk corruption when it's written back. This might be > contributing to the problems. > > I'll check if I can reproduce with e.g. Debian sid ppc64 (big endian) I was not seeing the very same on ppc64el which is the ppc64 architecture of Debian/Ubutnu. But then the "el" means little endian so that would make sense. The https://wiki.debian.org/PPC64 for big endian exists but is unofficial and thereby might have some issues. I'd think the fastest way for you could be getting a free s390x VM to work on via https://developer.ibm.com/components/ibm-linuxone/gettingstarted/# > and find out what's going on. I have no access to an s390x machine but > maybe qemu can help with that... It can, but you'd want to use a rather new qemu and an older Debian/Ubuntu system as too recent instructions always are a problem. As I said the community cloud likely is your quickest way out of this. > Best regards, > > - Erik > > On 8.6.2021 10.12, Christian Ehrhardt wrote: > > Hi, > > I wanted to let you know that the recent try to fix big endian byte > > swapping is actually breaking big endian in 1.0.7. > > > > This is broken on s390x (=big endian) in Debian [1] and Ubuntu [2]. > > > > When you look at just these logs it seems it is just failing for no > > apparent reason, > > but with -x enabled in gdisk_test.sh one quickly sees there is some > > string-mangling happening: > > > > Number Start (sector) End (sector) Size Code Name > > 1 2048 131038 63.0 MiB 8300 䰀椀渀甀砀 昀椀氀攀猀礀猀琀攀洀 > > > > Reading the very same file with the old gdisk is good - so likely the > > on-dis content is good as well: > > Number Start (sector) End (sector) Size Code Name > > 1 2048 131038 63.0 MiB 8300 Linux filesystem > > > > This is caused by GPTPart::GetDescription due to this change [3] in 1.0.7 > > > > Reverting this fixes change fixes the problem. > > > > [1]: https://buildd.debian.org/status/fetch.php?pkg=gdisk&arch=s390x&ver=1.0.7-1&stamp=1617791278&raw=0 > > [2]: https://launchpadlibrarian.net/540613637/buildlog_ubuntu-impish-s390x.gdisk_1.0.7-1_BUILDING.txt.gz > > [3]: https://sourceforge.net/p/gptfdisk/code/ci/86dd5fea351a5a55bea26b7622eb85ebd6075a60/ > > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd |
From: Christian E. <chr...@ca...> - 2021-06-08 07:28:49
|
Hi, I wanted to let you know that the recent try to fix big endian byte swapping is actually breaking big endian in 1.0.7. This is broken on s390x (=big endian) in Debian [1] and Ubuntu [2]. When you look at just these logs it seems it is just failing for no apparent reason, but with -x enabled in gdisk_test.sh one quickly sees there is some string-mangling happening: Number Start (sector) End (sector) Size Code Name 1 2048 131038 63.0 MiB 8300 䰀椀渀甀砀 昀椀氀攀猀礀猀琀攀洀 Reading the very same file with the old gdisk is good - so likely the on-dis content is good as well: Number Start (sector) End (sector) Size Code Name 1 2048 131038 63.0 MiB 8300 Linux filesystem This is caused by GPTPart::GetDescription due to this change [3] in 1.0.7 Reverting this fixes change fixes the problem. [1]: https://buildd.debian.org/status/fetch.php?pkg=gdisk&arch=s390x&ver=1.0.7-1&stamp=1617791278&raw=0 [2]: https://launchpadlibrarian.net/540613637/buildlog_ubuntu-impish-s390x.gdisk_1.0.7-1_BUILDING.txt.gz [3]: https://sourceforge.net/p/gptfdisk/code/ci/86dd5fea351a5a55bea26b7622eb85ebd6075a60/ -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd |
From: Erik L. <cat...@gm...> - 2021-06-08 07:24:32
|
Hi, I submitted this patch and tested it on Ubuntu 16.04 PowerPC (big endian, 32-bit) which had the same string-mangling problem when this fix is *not* applied... so there's something weird going on. In general I prefer to keep data read from disk into memory in the on-disk endianness and transform endianess when retrieving it or setting it. gptfdisk does not do this but instead byteswaps the fields back and forth in the structures that were read from disk. This is error-prone and can lead to on-disk corruption when it's written back. This might be contributing to the problems. I'll check if I can reproduce with e.g. Debian sid ppc64 (big endian) and find out what's going on. I have no access to an s390x machine but maybe qemu can help with that... Best regards, - Erik On 8.6.2021 10.12, Christian Ehrhardt wrote: > Hi, > I wanted to let you know that the recent try to fix big endian byte > swapping is actually breaking big endian in 1.0.7. > > This is broken on s390x (=big endian) in Debian [1] and Ubuntu [2]. > > When you look at just these logs it seems it is just failing for no > apparent reason, > but with -x enabled in gdisk_test.sh one quickly sees there is some > string-mangling happening: > > Number Start (sector) End (sector) Size Code Name > 1 2048 131038 63.0 MiB 8300 䰀椀渀甀砀 昀椀氀攀猀礀猀琀攀洀 > > Reading the very same file with the old gdisk is good - so likely the > on-dis content is good as well: > Number Start (sector) End (sector) Size Code Name > 1 2048 131038 63.0 MiB 8300 Linux filesystem > > This is caused by GPTPart::GetDescription due to this change [3] in 1.0.7 > > Reverting this fixes change fixes the problem. > > [1]: https://buildd.debian.org/status/fetch.php?pkg=gdisk&arch=s390x&ver=1.0.7-1&stamp=1617791278&raw=0 > [2]: https://launchpadlibrarian.net/540613637/buildlog_ubuntu-impish-s390x.gdisk_1.0.7-1_BUILDING.txt.gz > [3]: https://sourceforge.net/p/gptfdisk/code/ci/86dd5fea351a5a55bea26b7622eb85ebd6075a60/ > |
From: <u3...@ne...> - 2021-06-07 03:30:50
|
Thank you for your work. 1) With some entries, such as for -N, --largest-new=num, the manual page takes the burden of claryfing -a (--set-alignment). I suggest to take the same approach for the references to the -A, -c, -t, and -u options within the entry for -n, --new=partnum:start:end. 2) For the special partnum of 0, --info=0 will show detailed information about what -n, --new=partnum:start:end will do with 0 partnum, and a 0 start value. -- u34 |
From: Rod S. <rod...@ro...> - 2021-01-14 00:48:32
|
On 1/13/21 11:27 AM, Jonas Witschel wrote: > On 2021-01-13 10:34, Rod Smith wrote: >> I really wish somebody from Google had contacted me about that, but they >> didn't, so thanks for alerting me to it. I've just made that change to >> the git repo. (It shows up now in your [4] link.) I'm also preparing a >> 1.0.6 release; I'll probably push that later today. > > Awesome, thank you very much! The 1.0.6 release is out, so you should be able to get it from git (https://sourceforge.net/p/gptfdisk/code/ci/master/tree/); or various binaries or the source tarball from the Sourceforge downloads directory (https://sourceforge.net/projects/gptfdisk/files/gptfdisk/1.0.6/); or links to those on my own page (https://www.rodsbooks.com/gdisk/download.html). -- Rod Smith rod...@ro... http://www.rodsbooks.com |
From: Rod S. <rod...@ro...> - 2021-01-13 16:20:55
|
On 1/12/21 3:03 AM, Jonas Witschel wrote: > Hi, > > according to [1], a possible out of bounds write was found in GPT fdisk. This > has been patched downstream in Android [2] and the patch is available at [3]. > However, I couldn't find this commit or an equivalent workaround in the > upstream repository on SourceForge [4]. Should the patch be applied upstream as > well? I really wish somebody from Google had contacted me about that, but they didn't, so thanks for alerting me to it. I've just made that change to the git repo. (It shows up now in your [4] link.) I'm also preparing a 1.0.6 release; I'll probably push that later today. > [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-0308 > [2] https://source.android.com/security/bulletin/2021-01-01 > [3] https://android.googlesource.com/platform/external/gptfdisk/+/6d369451868ce71618144c4f4bd645ae48f0d1c5%5E! > [4] https://sourceforge.net/p/gptfdisk/code/ci/master/tree/basicmbr.cc#l293 > > > > _______________________________________________ > Gptfdisk-general mailing list > Gpt...@li... > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > -- Rod Smith rod...@ro... http://www.rodsbooks.com |
From: Jonas W. <dia...@ar...> - 2021-01-12 08:19:22
|
Hi, according to [1], a possible out of bounds write was found in GPT fdisk. This has been patched downstream in Android [2] and the patch is available at [3]. However, I couldn't find this commit or an equivalent workaround in the upstream repository on SourceForge [4]. Should the patch be applied upstream as well? Best, Jonas [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-0308 [2] https://source.android.com/security/bulletin/2021-01-01 [3] https://android.googlesource.com/platform/external/gptfdisk/+/6d369451868ce71618144c4f4bd645ae48f0d1c5%5E! [4] https://sourceforge.net/p/gptfdisk/code/ci/master/tree/basicmbr.cc#l293 |
From: Rod S. <rod...@ro...> - 2020-08-08 00:20:46
|
On 8/7/20 4:51 PM, u3...@ne... wrote: > All the existing partitions have their first sector immediately following > the last sector of their prior partition. > Why gdisk suggest to start the 8th partition at sector #59424768? The last sector > of the 7th partition is at sector #59422999. > gdisk is 1.0.5. > A non destrcutive read only badblocks -sv doesn't find any badblock. By default, GPT fdisk begins partitions on 2048-sector (1 MiB) boundaries, if the disk uses 512-byte logical sectors (as most do). If the final sector of partition #7 is 59422999, then the next free sector would be 59423000, which is not divisible by 2048, so GPT fdisk won't start a partition there. Instead, it will round up to the next free divisible-by-2048 value, which is 59424768, just as you report. This is done because it optimizes performance on many disk devices. Most modern hard disks use what's called Advanced Format, which uses 4096-byte physical sectors that are broken up into eight 512-byte logical sectors. These require alignment on 8-sector boundaries for optimal performance. Many RAID arrays have requirements to align on 256 KiB, 512 KiB, or similar power-of-two boundaries. SSDs vary a lot in their requirements, but some of them have a power-of-2 optimal alignment, too. A 1 MiB alignment meets all of these technologies' needs for optimal alignment. (There are some oddball SSDs and other configurations that might work better with other types of alignment.) For this reason, most modern partitioning tools align partitions' starts to 1 MiB boundaries. (Partition end points are not important, AFAIK.) If you understand your disk's alignment needs and want to adjust the setting in GPT fdisk, you can do so from the experts' menu with the "l" (lowercase L) option. You can see the current alignment with the "d" option on the experts' menu. For instance, you could set this to 8 if you're using an Advanced Format disk without RAID; or to 1 if you're using a non-Advanced-Format hard disk without RAID. Changing this value will enable you to reclaim a little otherwise lost disk space; but the amount is puny on modern hard disks. Even modern USB flash drives have capacities measured in the tens of GB, so saving under 1 MiB at the start of the disk, or between partitions if they aren't sized to precise multiples of 1 MiB, represents less that 0.1% of the disk's capacity. On a hard disk with a capacity measured in the TB range, the savings would be two or three orders of magnitude less, on a percentage basis. I don't know how you created your existing partitions. You can check for proper alignment (that is, alignment matching GPT fdisk's current setting) via the "v" option in gdisk. It's possible that partition #7 is not properly aligned; or it could simply have a size that's not an exact multiple of 2048 sectors. Changing the alignment would require a tool like GParted, which understands filesystems as well as partitions, and it might or might not be worth the bother depending on the disk type and partition contents. -- Rod Smith rod...@ro... http://www.rodsbooks.com |
From: <u3...@ne...> - 2020-08-07 21:34:14
|
All the existing partitions have their first sector immediately following the last sector of their prior partition. Why gdisk suggest to start the 8th partition at sector #59424768? The last sector of the 7th partition is at sector #59422999. gdisk is 1.0.5. A non destrcutive read only badblocks -sv doesn't find any badblock. |
From: Christoph B. <sou...@ma...> - 2019-08-06 21:48:43
|
Hello, as reported in Debian bug report <https://bugs.debian.org/873452>: There is a minimum block device size to hold a valid GP table. If I understand the documents correctly it's 68 (512 byte) sectors and, violating the specification, as low as four - but that's not something gptfdisk should support anyway. However, the report above tells gdisk shows weird results when operating on a very small disk. Please consider implementing a sanity limit to avoid such a weirdness. Thanks in advance, Christoph |
From: Christoph B. <sou...@ma...> - 2019-08-06 21:40:37
|
Hello, please check Debian bug report <https://bugs.debian.org/876393>: It seems to be possible to trigger a code path where a variable is not initialized. Could you please check and possibly pick the included patch? Thanks in advance, Christoph |
From: andrew b. <abe...@ar...> - 2019-07-24 00:14:07
|
Oh, nevermind... after a few more minutes of thought I realized that `sgdisk --move-second-header` was required after the `lvextend`.Sorry for the noise.Sent via the Samsung Galaxy S8, an AT&T 5G Evolution capable smartphone -------- Original message --------From: andrew bezella <abe...@ar...> Date: 7/23/19 16:37 (GMT-08:00) To: gpt...@li... Subject: [Gptfdisk-general] unexpected results from `sgdisk --largest-new` hello -i'm seeing some unexpected (to me) results when running `sgdisk --largest-new` and wondering if it's a bug or a misunderstanding on mypart. testing with GPT fdisk (sgdisk) version 1.0.4.the documentation states: -N, --largest-new=num Create a new partition that fills the largest available block of space on the disk. You can use the -a (--set-alignment) option to adjust the alignment, if desired. A num value of 0 causes the program to use the first available partition number.i've attached output with details, but the behavior can be summarizedas: 1. create a 500g logical volume 2. run `sgdisk --largest-new=0`; this creates a 500.0 GiB partition starting at 2048 (as expected) 3. extend the lv to 600g 4. run `sgdisk --largest-new=0` again; this ignores the add'l 100g and instead creates a 1007.0 KiB partition starting at sector 34 5. an additional `sgdisk --largest-new=0` creates the expected 100.0 GiB partition in the added spaceon a whim, i also tried `partprobe` between `lvextend` and the 2nd`sgdisk` invocation. same results. also tested `--largest-new=2` withno change.from my understanding of the option documentation, the `--largest-new`invocation after growing the lv should have consumed that space insteadof making the tiny partition at the beginning of the device. does thatmatch others' views/experience? as a guess, it might have something todo with the "last usable sector" calculation, which appears unchangedat 1048575966 the first time it prints the info for what it does see asa 600.0 GiB lv...thanks in advance for any feedback. if i don't hear anything i'llprobably file a bug on ubuntu's launchpad. andy-- andrew bezella <abe...@ar...>internet archive_______________________________________________Gptfdisk-general mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/gptfdisk-general |
From: andrew b. <abe...@ar...> - 2019-07-23 23:54:01
|
hello - i'm seeing some unexpected (to me) results when running `sgdisk -- largest-new` and wondering if it's a bug or a misunderstanding on my part. testing with GPT fdisk (sgdisk) version 1.0.4. the documentation states: -N, --largest-new=num Create a new partition that fills the largest available block of space on the disk. You can use the -a (--set-alignment) option to adjust the alignment, if desired. A num value of 0 causes the program to use the first available partition number. i've attached output with details, but the behavior can be summarized as: 1. create a 500g logical volume 2. run `sgdisk --largest-new=0`; this creates a 500.0 GiB partition starting at 2048 (as expected) 3. extend the lv to 600g 4. run `sgdisk --largest-new=0` again; this ignores the add'l 100g and instead creates a 1007.0 KiB partition starting at sector 34 5. an additional `sgdisk --largest-new=0` creates the expected 100.0 GiB partition in the added space on a whim, i also tried `partprobe` between `lvextend` and the 2nd `sgdisk` invocation. same results. also tested `--largest-new=2` with no change. from my understanding of the option documentation, the `--largest-new` invocation after growing the lv should have consumed that space instead of making the tiny partition at the beginning of the device. does that match others' views/experience? as a guess, it might have something to do with the "last usable sector" calculation, which appears unchanged at 1048575966 the first time it prints the info for what it does see as a 600.0 GiB lv... thanks in advance for any feedback. if i don't hear anything i'll probably file a bug on ubuntu's launchpad. andy -- andrew bezella <abe...@ar...> internet archive |
From: Edward E. <dev...@gm...> - 2019-02-20 22:29:39
|
On Windows, using UINT32_MAX (which is of course 1<<32 - 1) as a scaling factor to get a uint64_t is causing the sector total to be counted wrong, affecting disks/images >= 4GiB. Among other things, gdisk wants to "fix" the secondary GPT by moving it back one sector (plus one sector for each additional 2TiB). This patch (on current master) uses GetFileSizeEx(), which returns file size as an int64_t. This API was available possibly as far back as Windows 98, so switching to it shouldn't be a problem. Re-compiled on Windows and tested with a known good disk. I believe this bug caused Chris Murphy's issue in https://sourceforge.net/p/gptfdisk/discussion/939590/thread/cc21c83b/ ; it may be involved in https://sourceforge.net/p/gptfdisk/discussion/939590/thread/6b992837/ as well. It may be worthwhile to check if UINT{32,64}_MAX are being used correctly in all other cases. They look OK to me, but I'm not familiar enough with the GPT format to be confident of that assessment. |
From: 林博仁 <buo...@gm...> - 2017-10-02 14:02:32
|
Hello and first of all I would like to express my gratitude for your articles, it has always been the most helpful reference of booting mechanism to me. > * You can replace a hybrid MBR with a legal protective MBR by using the "n" option on the experts' menu. This is what I want, replacing the hybrid MBR to the proper protective MBR. I tried to achieve this by filling null argument to the "h" option without noticing there's a "n" option in another menu. I figured a another way to do the job and documented here earlier, just FYI: https://hackmd.io/KYMwbAnAHArADDAtMAJhALI98DMiNgDsiATGAMYSEQzDkxgxA=== Thanks, 林博仁 <Buo...@gm...> |
From: Rod S. <rod...@ro...> - 2017-10-02 14:00:45
|
On 10/02/2017 12:44 AM, 林博仁 wrote: > (NOTE: I'm not subscribed to this list, please CC me.) > > Hello. I would like to request a feature to revert a previously > configured Hybrid MBR configuration as I like to avoid any *surprises* > during installing Windows. It's not clear to me precisely what you mean; however, gdisk might already do what you want: * You can replace a hybrid MBR with a legal protective MBR by using the "n" option on the experts' menu. * You can create a new hybrid MBR by using the "h" option on the recovery & transformation menu. * You can abort from most operations without writing changes to disk by selecting "q" in any menu. * You can back up all partition table data by using the "b" option on the main menu, and restore a backup by using the "l" option on the recovery & transformation menu. It's impossible to return to a previous state once the partition table has been written unless a backup has been saved. Making such recovery possible would require automatically writing backups to some directory, and of course the recovery would only work if gdisk were the only program used to partition the disk. It's impossible to guarantee no "surprises" when installing Windows (or any other OS). I strongly recommend you read up on the differences between BIOS-mode and EFI-mode installations and learn how to control the boot mode your computer uses to boot an OS installation medium. My page on the CSM may be helpful: http://www.rodsbooks.com/efi-bootloaders/csm-good-bad-ugly.html Note that this page is written mainly for UEFI-based PCs. Macs differ in some important details, although the basic principles are the same. -- Rod Smith rod...@ro... http://www.rodsbooks.com |
From: 林博仁 <buo...@gm...> - 2017-10-02 04:44:23
|
(NOTE: I'm not subscribed to this list, please CC me.) Hello. I would like to request a feature to revert a previously configured Hybrid MBR configuration as I like to avoid any *surprises* during installing Windows. Thanks! 林博仁 <Buo...@gm...> |
From: Andrew J. <and...@co...> - 2017-09-15 00:27:21
|
Are there any plans to support machine readable output from sgdisk? Currently, sgdisk does not support any output formatting options. Allowing output in the form of key/value pairs (like the ones generated by `blkid -o export`) or json would be helpful to other programs which need to consume and parse sgdisk's output. sgdisk also does not support creating partitions with colons in the labels since they are used as delimiters in the command line arguments. Looking at getString() in gptcl.cc, it does not look like escaping colons is supported. Is this intentional? -Andrew Jeddeloh -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. |
From: Ivan M. <i.m...@sa...> - 2017-08-09 17:56:26
|
Hello, Looking into basicmbr.cc, there’s the following code (added in commit 23d8d54c): while (another && (partNum < MAX_MBR_PARTS) && (partNum >= 0) && (allOK > 0)) { for (i = 0; i < MAX_MBR_PARTS; i++) { if (EbrLocations[i] == offset) { // already read this one; infinite logical partition loop! cerr << "Logical partition infinite loop detected! This is being corrected.\n"; allOK = -1; partNum -= 1; } // if } // for EbrLocations[partNum] = offset; … if ((partNum >= 0) && (partNum < MAX_MBR_PARTS) && (allOK > 0)) { 1. Is it guaranteed by the algorithm that after the decrement partNum still be non-negative when accessing the array? 2. The second checking of partNum (after array access) is redundant. References: [1] https://sourceforge.net/p/gptfdisk/code/ci/23d8d54c/#diff-3 [2] https://android-review.googlesource.com/#/c/platform/external/gptfdisk/+/224286/1/basicmbr.cc ------------ Best regards, Ivan Maidanski |
From: Rod S. <rod...@ro...> - 2017-07-27 01:31:23
|
Hi all, It's been a while, but a new version of GPT fdisk has arrived! I've just released version 1.0.2. Details of what's changed are at: http://www.rodsbooks.com/gdisk/revisions.html The changes are fairly modest (hence the long gap since 1.0.1) -- mainly new partition type codes and a bit more information about the disk being edited (its model number and physical sector size) in Linux. The recently-discussed ability to set the starting sector for the main partition table is also included, which is unimportant for most but critical for a few. -- Rod Smith rod...@ro... http://www.rodsbooks.com |
From: Johan M. <joh...@gm...> - 2017-07-23 12:09:09
|
Thank you for the new version. I did a quick test and ran the new gdisk on a USB stick and put the main table at sector 64. I added a partition and created a UDF file system on it. Both Linux and Windows 7 sees it without problems. Now I can create a standard conforming full-size 128-entry partition table and still have the Allwinner SoC's ROM read what it needs starting at LBA 16. This is still, as you say, "in limbo", i.e. not on a partition, but at least not in the area reserved for partition data and not between the table and the partition data. Regarding the "braindead" SoCs: they don't have enough ROM to be able to parse partition tables, and if they did, then they would probably only support MBR partitions. So they have to make some hard-coded choice. Allwinner generously reserves 8 kB at the start of the storage device for whatever needs to be stored there, but that's not enough for GPT. On 22 July 2017 at 05:20, Rod Smith <rod...@ro...> wrote: > Hi, > > So I've done some hacking this evening, and I've submitted an initial > version of the code to enable moving the main partition table to git: > > https://sourceforge.net/p/gptfdisk/code/ci/master/tree/ > > This is git commit 503e9a. You'll need to pull down the source code and > compile it locally. The NEWS file summarizes the changes. In gdisk, the > feature is implemented via "j" on the experts' menu; in sgdisk, it's > -j/--move-main-table={sector}, where {sector} is the sector number to > which you want to move the partition table; and the ability to change > this value is not implemented in cgdisk. This seems to be working for > me, but I need to hammer away at it to find any bugs or complications > that might be lurking. I'd appreciate it if you can do so, too. Note > that the code may interact with other features. I've added some checks > to the verify code, and functions like partition table resizing, > backups, restores, etc., could all be affected, and I haven't yet > checked them to be sure they're all doing sensible things. > > One quirk I discovered is that fdisk's (util-linux fdisk's) GPT support > creates a gap between the partition table and the first usable sector. > Either before or after this patch to GPT fdisk, my program seems to > handle these disks OK, but there is one important peculiarity, which > makes me a bit wary: The gdisk "use backup GPT" feature ("b" on the > backup/recovery menu), if applied to an fdisk-created disk, moves the > partition table from sector 2 to sector 2016 (from the start to the end > of the space between the main metadata to the first usable sector). This > preserves the first-usable-sector value but shifts the location of the > gap in the GPT data structures. I don't see any way around this; each > GPT metadata structure contains a pointer only to its own partition > table, so the backup data does not provide any clue about whether the > main partition table comes at the beginning or end of a too-big > allocated area (or somewhere in the middle). The current (development) > state of the GPT fdisk code assumes the partition table will go at the > end of the allocation area since that's how the "j" function on the > experts' menu does it. > > Both fdisk and parted seemed to be able to cope with disks created with > a shifted main partition table; however, my testing with them has been > limited. I did a VERY basic test with OS X, but I have yet to test with > Windows, FreeBSD, or anything else. > > On 07/21/2017 03:08 AM, Johan Myréen wrote: > > In summary: we all seem to agree that creating a partition for the data > > read by the SoC ROM is a good idea. What we need in this case is a > > layout that looks like this: Protective MBR+GPT Header - 1st partition - > > Partition Entry Table - Rest of the partitions. > > > > On 21 July 2017 at 08:58, Priebe, Sebastian <Seb...@ca... > > <mailto:Seb...@ca...>> wrote: > > > > Hello Rod, > > > > I agree with you that this can cause confusion. But there are hard > > restrictions by the SOCs and the GPT concept provides all mechanisms > > to do what it needed. So, why not let the user of gptfdisk configure > > it? You can put all this stuff in the experts section and leave the > > "normal" user with the defaults. > > > > I was thinking of you objections: is it possible to put a partitions > > at LBA 2? That's what I need to do. With the possibility to move the > > PTEs itself (e.g. to LBA 512), it should be possible to put a > > partition infront of the PTEs, right? > > > > Nevertheless, the option to put the PTEs to a configurable LBA (not > > 2) is very needed. > > > > Greetings, > > Sebastian > > > > > > > > ------------------------------------------------- > > Wir ziehen um! > > Ab dem 01.07.2017 > > NEUER CADCON HAUPTSITZ > > Am Mittleren Moos 53, 86167 Augsburg > > ------------------------------------------------- > > > > CADCON > > Ingenieurgesellschaft mbH & Co. KG > > Geschaeftsfuehrer: Robert Bauer > > Sitz der Gesellschaft: 86368 Gersthofen > > Registergericht: Amtsgericht Augsburg HRA 14521 > > -----Ursprüngliche Nachricht----- > > Von: Rod Smith [mailto:rod...@ro... > > <mailto:rod...@ro...>] > > Gesendet: Donnerstag, 20. Juli 2017 19:52 > > An: Priebe, Sebastian <Seb...@ca... > > <mailto:Seb...@ca...>>; > > gpt...@li... > > <mailto:gpt...@li...> > > Betreff: Re: AW: [Gptfdisk-general] [PATCH] Support padding between > > Partition Header(LBA1) and Entries(LBA2) > > > > On 07/20/2017 10:20 AM, Priebe, Sebastian wrote: > > > That is another good point. > > > > > > I would love the possibility to configure the start sector of the > > > first partition located at offset 40 in the GPT header > independently > > > of the number of partitions. > > > > > > Currently it is calculated from the number of partitions. > > > > Why? This gets back to my first objection, when I misunderstood the > > point of the patch. If you're just blocking off space between the > > first partition table and the first partition, then a partition is > > the appropriate way to reserve that space. Using a partition makes > > it plain that the space is in use and can provide some clue (through > > the partition type code and/or description) of what its purpose is. > > Rendering a set of blocks unusable by normal partitions and useless > > to GPT itself just invites confusion and conflicts in how it might > > be used. > > > > > *Von:*Johan Myréen [mailto:joh...@gm... > > <mailto:joh...@gm...>] > > > *Gesendet:* Mittwoch, 19. Juli 2017 18:57 > > > *An:* gpt...@li... > > <mailto:gpt...@li...> > > > *Betreff:* Re: [Gptfdisk-general] [PATCH] Support padding between > > > Partition Header(LBA1) and Entries(LBA2) > > > > > > > > > > > > For the record: when booting from an SD card, the ROM in Allwinner > > > SoCs loads 32 kB of code starting at 8 kB. This makes it possible > to > > > use a shorter, non-standard partition table, but of course it > would be > > > nicer to be able to avoid hacks like this. > > > > > > > > > > > > On 19 July 2017 at 16:27, Rod Smith <rod...@ro... > > <mailto:rod...@ro...> > > > <mailto:rod...@ro... <mailto:rod...@ro...>>> > > wrote: > > > > > > On 07/19/2017 02:16 AM, Priebe, Sebastian wrote: > > > > Hello Rod, > > > > > > > > thx for your quick reply. > > > > > > > > To your first problem point: Many SOCs don't care about any > > > > partitioning during their boot process. E.g. the Freescale > > (NXP) SOCs > > > > I work with load the LBA block 2 into RAM and expect some > > special > > > > proprietary data there. > > > > > > OK, thanks. I was mis-reading the code; I thought it was > > simply moving > > > the first usable sector for partitions, not moving the > > partition table > > > itself. If an SoC is stupid enough to require boot code at > > sector 2, > > > then that conflicts with the standard GPT positioning, so > > moving it may > > > be the only solution. > > > > > > > Currently the gptfdisk tools always put the > > > > PTEs there. There is no way around that. I also don't like > > having > > > > some "hidden" data on the disk, but that’s just the way it > > is. I also > > > > don't see a way of putting bootcode in a partition for the > > Freescale > > > > case as there are no free blocks available. > > > > > > > > I can't say anything to your other points, as I haven't > > looked into > > > > the details yet. > > > > > > I'll give it some more thought. I'm now inclined to do > > something about > > > this, whether it's accepting some variant of the patch or doing > > > something else, liking a new option (analogous to the existing > "e" > > > option on the experts' menu) to relocate the main partition > table > > > entries. > > > > > > > > > > > > > > > > CADCON > > > Ingenieurgesellschaft mbH & Co. KG > > > Geschaeftsfuehrer: Robert Bauer > > > Sitz der Gesellschaft: 86368 Gersthofen > > > Registergericht: Amtsgericht Augsburg HRA 14521 > > > > > > ------------------------------------------------- Wir ziehen > > um! Ab > > > > dem 01.07.2017 NEUER CADCON HAUPTSITZ Am Mittleren Moos 53, > > 86167 > > > > Augsburg ------------------------------------------------- > > > > > > > > CADCON Ingenieurgesellschaft mbH & Co. KG Geschaeftsfuehrer: > > Robert > > > > Bauer Sitz der Gesellschaft: 86368 Gersthofen > Registergericht: > > > > Amtsgericht Augsburg HRA 14521 -----Ursprüngliche > > Nachricht----- Von: > > > > Rod Smith [mailto:rod...@ro... > > <mailto:rod...@ro...> > > > <mailto:rod...@ro... > > <mailto:rod...@ro...>>] Gesendet: Dienstag, 18. > > > > Juli 2017 20:24 An: gpt...@li... > > <mailto:gpt...@li...> > > > <mailto:gpt...@li... > > <mailto:gpt...@li...>>; Priebe, > > > > Sebastian <Seb...@ca... > > <mailto:Seb...@ca...> > > > <mailto:Seb...@ca... > > <mailto:Seb...@ca...>>> Betreff: Re: > > > > [Gptfdisk-general] [PATCH] Support padding between Partition > > > > Header(LBA1) and Entries(LBA2) > > > > > > > > On 07/17/2017 06:38 AM, Priebe, Sebastian wrote: > > > >> Hello, > > > >> > > > >> there was a mail to this list in March 2016 with a patch > > adding the > > > >> option to change the starting LBA of the PTE (byte 72 in > > the GPT > > > >> header): > > > >> > > https://sourceforge.net/p/gptfdisk/mailman/message/34955352/ > > <https://sourceforge.net/p/gptfdisk/mailman/message/34955352/> > > > >> > > > >> Has somebody reviewed or tested that patch? > > > > > > > > I think I missed that the first time around. > > > > > > > >> As written in the original message this option is needed > > for many > > > >> embedded devices as many SoC vendors tends to have their > > > >> constraints on where to load its bootcode which may > > conflict with > > > >> the default starting LBA (2) of GPT fdisk. > > > >> > > > >> Why has this patch not been included? > > > > > > > > After reviewing the code, I have a number of problems with > > it. Most > > > > of these are minor, but the first is major: > > > > > > > > * I don't understand why this is needed. Why not create a > > partition > > > > (a BIOS Boot Partition or something analogous) to hold the > > SoC boot > > > > code? By disabling the 2048-sector alignment policy, such a > > partition > > > > could easily be located starting at sector 34, which is the > > first > > > > sector that would be safe to use anyway. This strikes me as a > > > > superior solution compared to creating a significant chunk > > of the > > > > disk that's "in limbo" -- neither allocated to partitions or > > official > > > > GPT data structures nor available for allocation. It was the > > reckless > > > > use of such space under MBR that led to numerous conflicts > > between > > > > boot loaders and other low-level disk utilities with MBR and > > > > BIOS-mode booting. Encouraging something similar with GPT > > strikes me > > > > as a Bad Idea. * Creating a new "j" option on the experts' > > menu that > > > > replicates what "o" does on the main menu would create > > confusion. * > > > > The change to "o" on the main menu makes it harder to use. > > If this > > > > functionality is really needed, that may be unavoidable -- > > or perhaps > > > > a new function could be added to adjust this setting, > > leaving "o" > > > > unaffected. * Perhaps adding "j" was done so that sgdisk's > > -o could > > > > be left to work as it always has. If so, that might be > > better done > > > > by adding an OPTIONAL parameter to -o. I'm not 100% sure > that's > > > > possible, though; I'd need to dig into the POPT > > documentation. * The > > > > patch included no documentation changes. I could write that > > myself, > > > > of course, but at a minimum, a description of when a > > non-standard > > > > (that is, non-0) padding size is appropriate would be > > helpful, since > > > > I'm unfamiliar with the SoC boot loaders that you say would > > benefit > > > > from such a change. > > > > > > > > If you can make a case for why putting SoC boot loader code > in a > > > > partition, even if that means adjust the alignment policy, > won't > > > > work, then I'll consider this patch. If not, though, I think > > it's > > > > best to reject this patch, since I don't want to contribute > > to old > > > > BIOS/MBR problems infecting the EFI/GPT world. > > > > > > > > If a partition will do the job, but if you don't think the > > BIOS Boot > > > > Partition is the right type code, then you can create such a > > GUID and > > > > submit a patch that adds it. (It would help if you have some > > > > authority in the field and can get buy-in for using that > > type code.) > > > > There might even be ways to tweak the alignment code to > minimize > > > > problems from having a single unaligned partition on a disk, > if > > > > that's likely to be an issue. > > > > > > > > -- Rod Smith rod...@ro... > > <mailto:rod...@ro...> > > > <mailto:rod...@ro... > > <mailto:rod...@ro...>> http://www.rodsbooks.com > > > > > > > > > > > > > -- > > > Rod Smith > > > rod...@ro... <mailto:rod...@ro...> > > <mailto:rod...@ro... <mailto:rod...@ro...>> > > > http://www.rodsbooks.com > > > > > > > > ------------------------------------------------------------ > ------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > > Gptfdisk-general mailing list > > > Gpt...@li... > > <mailto:Gpt...@li...> > > > <mailto:Gpt...@li... > > <mailto:Gpt...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > > <https://lists.sourceforge.net/lists/listinfo/gptfdisk-general> > > > > > > > > > > > > > > > -- > > Rod Smith > > rod...@ro... <mailto:rod...@ro...> > > http://www.rodsbooks.com > > > > ------------------------------------------------------------ > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Gptfdisk-general mailing list > > Gpt...@li... > > <mailto:Gpt...@li...> > > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > > <https://lists.sourceforge.net/lists/listinfo/gptfdisk-general> > > > > > > > > > > ------------------------------------------------------------ > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > > _______________________________________________ > > Gptfdisk-general mailing list > > Gpt...@li... > > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > > > > > -- > Rod Smith > rod...@ro... > http://www.rodsbooks.com > |
From: Rod S. <rod...@ro...> - 2017-07-22 02:21:10
|
Hi, So I've done some hacking this evening, and I've submitted an initial version of the code to enable moving the main partition table to git: https://sourceforge.net/p/gptfdisk/code/ci/master/tree/ This is git commit 503e9a. You'll need to pull down the source code and compile it locally. The NEWS file summarizes the changes. In gdisk, the feature is implemented via "j" on the experts' menu; in sgdisk, it's -j/--move-main-table={sector}, where {sector} is the sector number to which you want to move the partition table; and the ability to change this value is not implemented in cgdisk. This seems to be working for me, but I need to hammer away at it to find any bugs or complications that might be lurking. I'd appreciate it if you can do so, too. Note that the code may interact with other features. I've added some checks to the verify code, and functions like partition table resizing, backups, restores, etc., could all be affected, and I haven't yet checked them to be sure they're all doing sensible things. One quirk I discovered is that fdisk's (util-linux fdisk's) GPT support creates a gap between the partition table and the first usable sector. Either before or after this patch to GPT fdisk, my program seems to handle these disks OK, but there is one important peculiarity, which makes me a bit wary: The gdisk "use backup GPT" feature ("b" on the backup/recovery menu), if applied to an fdisk-created disk, moves the partition table from sector 2 to sector 2016 (from the start to the end of the space between the main metadata to the first usable sector). This preserves the first-usable-sector value but shifts the location of the gap in the GPT data structures. I don't see any way around this; each GPT metadata structure contains a pointer only to its own partition table, so the backup data does not provide any clue about whether the main partition table comes at the beginning or end of a too-big allocated area (or somewhere in the middle). The current (development) state of the GPT fdisk code assumes the partition table will go at the end of the allocation area since that's how the "j" function on the experts' menu does it. Both fdisk and parted seemed to be able to cope with disks created with a shifted main partition table; however, my testing with them has been limited. I did a VERY basic test with OS X, but I have yet to test with Windows, FreeBSD, or anything else. On 07/21/2017 03:08 AM, Johan Myréen wrote: > In summary: we all seem to agree that creating a partition for the data > read by the SoC ROM is a good idea. What we need in this case is a > layout that looks like this: Protective MBR+GPT Header - 1st partition - > Partition Entry Table - Rest of the partitions. > > On 21 July 2017 at 08:58, Priebe, Sebastian <Seb...@ca... > <mailto:Seb...@ca...>> wrote: > > Hello Rod, > > I agree with you that this can cause confusion. But there are hard > restrictions by the SOCs and the GPT concept provides all mechanisms > to do what it needed. So, why not let the user of gptfdisk configure > it? You can put all this stuff in the experts section and leave the > "normal" user with the defaults. > > I was thinking of you objections: is it possible to put a partitions > at LBA 2? That's what I need to do. With the possibility to move the > PTEs itself (e.g. to LBA 512), it should be possible to put a > partition infront of the PTEs, right? > > Nevertheless, the option to put the PTEs to a configurable LBA (not > 2) is very needed. > > Greetings, > Sebastian > > > > ------------------------------------------------- > Wir ziehen um! > Ab dem 01.07.2017 > NEUER CADCON HAUPTSITZ > Am Mittleren Moos 53, 86167 Augsburg > ------------------------------------------------- > > CADCON > Ingenieurgesellschaft mbH & Co. KG > Geschaeftsfuehrer: Robert Bauer > Sitz der Gesellschaft: 86368 Gersthofen > Registergericht: Amtsgericht Augsburg HRA 14521 > -----Ursprüngliche Nachricht----- > Von: Rod Smith [mailto:rod...@ro... > <mailto:rod...@ro...>] > Gesendet: Donnerstag, 20. Juli 2017 19:52 > An: Priebe, Sebastian <Seb...@ca... > <mailto:Seb...@ca...>>; > gpt...@li... > <mailto:gpt...@li...> > Betreff: Re: AW: [Gptfdisk-general] [PATCH] Support padding between > Partition Header(LBA1) and Entries(LBA2) > > On 07/20/2017 10:20 AM, Priebe, Sebastian wrote: > > That is another good point. > > > > I would love the possibility to configure the start sector of the > > first partition located at offset 40 in the GPT header independently > > of the number of partitions. > > > > Currently it is calculated from the number of partitions. > > Why? This gets back to my first objection, when I misunderstood the > point of the patch. If you're just blocking off space between the > first partition table and the first partition, then a partition is > the appropriate way to reserve that space. Using a partition makes > it plain that the space is in use and can provide some clue (through > the partition type code and/or description) of what its purpose is. > Rendering a set of blocks unusable by normal partitions and useless > to GPT itself just invites confusion and conflicts in how it might > be used. > > > *Von:*Johan Myréen [mailto:joh...@gm... > <mailto:joh...@gm...>] > > *Gesendet:* Mittwoch, 19. Juli 2017 18:57 > > *An:* gpt...@li... > <mailto:gpt...@li...> > > *Betreff:* Re: [Gptfdisk-general] [PATCH] Support padding between > > Partition Header(LBA1) and Entries(LBA2) > > > > > > > > For the record: when booting from an SD card, the ROM in Allwinner > > SoCs loads 32 kB of code starting at 8 kB. This makes it possible to > > use a shorter, non-standard partition table, but of course it would be > > nicer to be able to avoid hacks like this. > > > > > > > > On 19 July 2017 at 16:27, Rod Smith <rod...@ro... > <mailto:rod...@ro...> > > <mailto:rod...@ro... <mailto:rod...@ro...>>> > wrote: > > > > On 07/19/2017 02:16 AM, Priebe, Sebastian wrote: > > > Hello Rod, > > > > > > thx for your quick reply. > > > > > > To your first problem point: Many SOCs don't care about any > > > partitioning during their boot process. E.g. the Freescale > (NXP) SOCs > > > I work with load the LBA block 2 into RAM and expect some > special > > > proprietary data there. > > > > OK, thanks. I was mis-reading the code; I thought it was > simply moving > > the first usable sector for partitions, not moving the > partition table > > itself. If an SoC is stupid enough to require boot code at > sector 2, > > then that conflicts with the standard GPT positioning, so > moving it may > > be the only solution. > > > > > Currently the gptfdisk tools always put the > > > PTEs there. There is no way around that. I also don't like > having > > > some "hidden" data on the disk, but that’s just the way it > is. I also > > > don't see a way of putting bootcode in a partition for the > Freescale > > > case as there are no free blocks available. > > > > > > I can't say anything to your other points, as I haven't > looked into > > > the details yet. > > > > I'll give it some more thought. I'm now inclined to do > something about > > this, whether it's accepting some variant of the patch or doing > > something else, liking a new option (analogous to the existing "e" > > option on the experts' menu) to relocate the main partition table > > entries. > > > > > > > > > > > CADCON > > Ingenieurgesellschaft mbH & Co. KG > > Geschaeftsfuehrer: Robert Bauer > > Sitz der Gesellschaft: 86368 Gersthofen > > Registergericht: Amtsgericht Augsburg HRA 14521 > > > > ------------------------------------------------- Wir ziehen > um! Ab > > > dem 01.07.2017 NEUER CADCON HAUPTSITZ Am Mittleren Moos 53, > 86167 > > > Augsburg ------------------------------------------------- > > > > > > CADCON Ingenieurgesellschaft mbH & Co. KG Geschaeftsfuehrer: > Robert > > > Bauer Sitz der Gesellschaft: 86368 Gersthofen Registergericht: > > > Amtsgericht Augsburg HRA 14521 -----Ursprüngliche > Nachricht----- Von: > > > Rod Smith [mailto:rod...@ro... > <mailto:rod...@ro...> > > <mailto:rod...@ro... > <mailto:rod...@ro...>>] Gesendet: Dienstag, 18. > > > Juli 2017 20:24 An: gpt...@li... > <mailto:gpt...@li...> > > <mailto:gpt...@li... > <mailto:gpt...@li...>>; Priebe, > > > Sebastian <Seb...@ca... > <mailto:Seb...@ca...> > > <mailto:Seb...@ca... > <mailto:Seb...@ca...>>> Betreff: Re: > > > [Gptfdisk-general] [PATCH] Support padding between Partition > > > Header(LBA1) and Entries(LBA2) > > > > > > On 07/17/2017 06:38 AM, Priebe, Sebastian wrote: > > >> Hello, > > >> > > >> there was a mail to this list in March 2016 with a patch > adding the > > >> option to change the starting LBA of the PTE (byte 72 in > the GPT > > >> header): > > >> > https://sourceforge.net/p/gptfdisk/mailman/message/34955352/ > <https://sourceforge.net/p/gptfdisk/mailman/message/34955352/> > > >> > > >> Has somebody reviewed or tested that patch? > > > > > > I think I missed that the first time around. > > > > > >> As written in the original message this option is needed > for many > > >> embedded devices as many SoC vendors tends to have their > > >> constraints on where to load its bootcode which may > conflict with > > >> the default starting LBA (2) of GPT fdisk. > > >> > > >> Why has this patch not been included? > > > > > > After reviewing the code, I have a number of problems with > it. Most > > > of these are minor, but the first is major: > > > > > > * I don't understand why this is needed. Why not create a > partition > > > (a BIOS Boot Partition or something analogous) to hold the > SoC boot > > > code? By disabling the 2048-sector alignment policy, such a > partition > > > could easily be located starting at sector 34, which is the > first > > > sector that would be safe to use anyway. This strikes me as a > > > superior solution compared to creating a significant chunk > of the > > > disk that's "in limbo" -- neither allocated to partitions or > official > > > GPT data structures nor available for allocation. It was the > reckless > > > use of such space under MBR that led to numerous conflicts > between > > > boot loaders and other low-level disk utilities with MBR and > > > BIOS-mode booting. Encouraging something similar with GPT > strikes me > > > as a Bad Idea. * Creating a new "j" option on the experts' > menu that > > > replicates what "o" does on the main menu would create > confusion. * > > > The change to "o" on the main menu makes it harder to use. > If this > > > functionality is really needed, that may be unavoidable -- > or perhaps > > > a new function could be added to adjust this setting, > leaving "o" > > > unaffected. * Perhaps adding "j" was done so that sgdisk's > -o could > > > be left to work as it always has. If so, that might be > better done > > > by adding an OPTIONAL parameter to -o. I'm not 100% sure that's > > > possible, though; I'd need to dig into the POPT > documentation. * The > > > patch included no documentation changes. I could write that > myself, > > > of course, but at a minimum, a description of when a > non-standard > > > (that is, non-0) padding size is appropriate would be > helpful, since > > > I'm unfamiliar with the SoC boot loaders that you say would > benefit > > > from such a change. > > > > > > If you can make a case for why putting SoC boot loader code in a > > > partition, even if that means adjust the alignment policy, won't > > > work, then I'll consider this patch. If not, though, I think > it's > > > best to reject this patch, since I don't want to contribute > to old > > > BIOS/MBR problems infecting the EFI/GPT world. > > > > > > If a partition will do the job, but if you don't think the > BIOS Boot > > > Partition is the right type code, then you can create such a > GUID and > > > submit a patch that adds it. (It would help if you have some > > > authority in the field and can get buy-in for using that > type code.) > > > There might even be ways to tweak the alignment code to minimize > > > problems from having a single unaligned partition on a disk, if > > > that's likely to be an issue. > > > > > > -- Rod Smith rod...@ro... > <mailto:rod...@ro...> > > <mailto:rod...@ro... > <mailto:rod...@ro...>> http://www.rodsbooks.com > > > > > > > > > -- > > Rod Smith > > rod...@ro... <mailto:rod...@ro...> > <mailto:rod...@ro... <mailto:rod...@ro...>> > > http://www.rodsbooks.com > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Gptfdisk-general mailing list > > Gpt...@li... > <mailto:Gpt...@li...> > > <mailto:Gpt...@li... > <mailto:Gpt...@li...>> > > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > <https://lists.sourceforge.net/lists/listinfo/gptfdisk-general> > > > > > > > > > -- > Rod Smith > rod...@ro... <mailto:rod...@ro...> > http://www.rodsbooks.com > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Gptfdisk-general mailing list > Gpt...@li... > <mailto:Gpt...@li...> > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > <https://lists.sourceforge.net/lists/listinfo/gptfdisk-general> > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Gptfdisk-general mailing list > Gpt...@li... > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > -- Rod Smith rod...@ro... http://www.rodsbooks.com |
From: Rod S. <rod...@ro...> - 2017-07-21 13:20:12
|
On 07/21/2017 03:08 AM, Johan Myréen wrote: > In summary: we all seem to agree that creating a partition for the data > read by the SoC ROM is a good idea. What we need in this case is a > layout that looks like this: Protective MBR+GPT Header - 1st partition - > Partition Entry Table - Rest of the partitions. No, I don't think that's even legal, since the GPT spec ASSUMES a single uninterrupted range of sectors in which partitions reside. Having one partition before the partition table and a bunch more after it would violate this assumption. I suppose you could hack something together that would look like that, but I shudder to think of what random partitioning tools would do with it. For SoCs that require boot code at sector 2, what's needed is: 1. Protective MBR (1 sector; position cannot change) 2. GPT header (1 sector; position cannot change) 3. Area reserved for boot loader (normally used by partition table) 4. Partition table 5. Area reserved for partitions 6. Backup GPT data structures (end of disk; not an issue here) My previous message was to the effect that reserving extra space between the partition table (4 in the above) and the reserved area for partitions (5 in the above) is pointless and could lead to abuses, since the space would be reserved by the partition table structures but not officially allocated for anything. That could easily lead to contention by different developers who think "ooh, neat, I can use this space for X," and who then overwrite something stored there by another tool created by a developer who thought "ooh, neat, I can use this space for Y." Furthermore, even if gdisk preserves these settings, there's no guarantee that another tool will do so; some other partitioning tool might change the start location of the first partition back to just after the partition table, thus enabling partitions to be created there. In sum, padding THAT area (4-5) just creates the potential for problems. If you need to put something there for some reason, I don't see why creating a regular partition shouldn't be sufficient. If you just want to push out the official point where partitions can begin, you could do it by increasing 3 in the above list, once that feature is implemented; the effect would be the same. If an SoC is hard-coded to read boot loader code from sector 2, then that's another matter; that's what 3 in the preceding list is for. gdisk does not currently support this, but that's what the proposed patch does. I have other problems with the patch, outlined earlier, so my inclination is to implement this in another way (namely, create the partition table as it's done now, but have an experts' menu item that moves the partition table). That's not to say this is a good idea in an abstract sense; IMHO, anything that's hard-coded to boot by reading a fixed sector number these days is pretty brain-dead. The need to support this in tools like gdisk means that some people who don't need this feature will dig a great big hole and fall into it; but if you're stuck with a brain-dead SoC that's hard-coded to read its boot code from sector 2, then you really do need this feature. This is analogous to hybrid MBRs, which are similarly non-standard but that provide needed functionality for some cases. People create hybrid MBRs when they don't need to, thus causing problems for themselves; but Macs need hybrid MBRs to dual-boot with BIOS-mode OSes. I'll look into implementing this soon -- conceivably this weekend, but I can make no promises about that. > On 21 July 2017 at 08:58, Priebe, Sebastian <Seb...@ca... > <mailto:Seb...@ca...>> wrote: > > Hello Rod, > > I agree with you that this can cause confusion. But there are hard > restrictions by the SOCs and the GPT concept provides all mechanisms > to do what it needed. So, why not let the user of gptfdisk configure > it? You can put all this stuff in the experts section and leave the > "normal" user with the defaults. > > I was thinking of you objections: is it possible to put a partitions > at LBA 2? That's what I need to do. With the possibility to move the > PTEs itself (e.g. to LBA 512), it should be possible to put a > partition infront of the PTEs, right? > > Nevertheless, the option to put the PTEs to a configurable LBA (not > 2) is very needed. > > Greetings, > Sebastian > > > > ------------------------------------------------- > Wir ziehen um! > Ab dem 01.07.2017 > NEUER CADCON HAUPTSITZ > Am Mittleren Moos 53, 86167 Augsburg > ------------------------------------------------- > > CADCON > Ingenieurgesellschaft mbH & Co. KG > Geschaeftsfuehrer: Robert Bauer > Sitz der Gesellschaft: 86368 Gersthofen > Registergericht: Amtsgericht Augsburg HRA 14521 > -----Ursprüngliche Nachricht----- > Von: Rod Smith [mailto:rod...@ro... > <mailto:rod...@ro...>] > Gesendet: Donnerstag, 20. Juli 2017 19:52 > An: Priebe, Sebastian <Seb...@ca... > <mailto:Seb...@ca...>>; > gpt...@li... > <mailto:gpt...@li...> > Betreff: Re: AW: [Gptfdisk-general] [PATCH] Support padding between > Partition Header(LBA1) and Entries(LBA2) > > On 07/20/2017 10:20 AM, Priebe, Sebastian wrote: > > That is another good point. > > > > I would love the possibility to configure the start sector of the > > first partition located at offset 40 in the GPT header independently > > of the number of partitions. > > > > Currently it is calculated from the number of partitions. > > Why? This gets back to my first objection, when I misunderstood the > point of the patch. If you're just blocking off space between the > first partition table and the first partition, then a partition is > the appropriate way to reserve that space. Using a partition makes > it plain that the space is in use and can provide some clue (through > the partition type code and/or description) of what its purpose is. > Rendering a set of blocks unusable by normal partitions and useless > to GPT itself just invites confusion and conflicts in how it might > be used. > > > *Von:*Johan Myréen [mailto:joh...@gm... > <mailto:joh...@gm...>] > > *Gesendet:* Mittwoch, 19. Juli 2017 18:57 > > *An:* gpt...@li... > <mailto:gpt...@li...> > > *Betreff:* Re: [Gptfdisk-general] [PATCH] Support padding between > > Partition Header(LBA1) and Entries(LBA2) > > > > > > > > For the record: when booting from an SD card, the ROM in Allwinner > > SoCs loads 32 kB of code starting at 8 kB. This makes it possible to > > use a shorter, non-standard partition table, but of course it would be > > nicer to be able to avoid hacks like this. > > > > > > > > On 19 July 2017 at 16:27, Rod Smith <rod...@ro... > <mailto:rod...@ro...> > > <mailto:rod...@ro... <mailto:rod...@ro...>>> > wrote: > > > > On 07/19/2017 02:16 AM, Priebe, Sebastian wrote: > > > Hello Rod, > > > > > > thx for your quick reply. > > > > > > To your first problem point: Many SOCs don't care about any > > > partitioning during their boot process. E.g. the Freescale > (NXP) SOCs > > > I work with load the LBA block 2 into RAM and expect some > special > > > proprietary data there. > > > > OK, thanks. I was mis-reading the code; I thought it was > simply moving > > the first usable sector for partitions, not moving the > partition table > > itself. If an SoC is stupid enough to require boot code at > sector 2, > > then that conflicts with the standard GPT positioning, so > moving it may > > be the only solution. > > > > > Currently the gptfdisk tools always put the > > > PTEs there. There is no way around that. I also don't like > having > > > some "hidden" data on the disk, but that’s just the way it > is. I also > > > don't see a way of putting bootcode in a partition for the > Freescale > > > case as there are no free blocks available. > > > > > > I can't say anything to your other points, as I haven't > looked into > > > the details yet. > > > > I'll give it some more thought. I'm now inclined to do > something about > > this, whether it's accepting some variant of the patch or doing > > something else, liking a new option (analogous to the existing "e" > > option on the experts' menu) to relocate the main partition table > > entries. > > > > > > > > > > > CADCON > > Ingenieurgesellschaft mbH & Co. KG > > Geschaeftsfuehrer: Robert Bauer > > Sitz der Gesellschaft: 86368 Gersthofen > > Registergericht: Amtsgericht Augsburg HRA 14521 > > > > ------------------------------------------------- Wir ziehen > um! Ab > > > dem 01.07.2017 NEUER CADCON HAUPTSITZ Am Mittleren Moos 53, > 86167 > > > Augsburg ------------------------------------------------- > > > > > > CADCON Ingenieurgesellschaft mbH & Co. KG Geschaeftsfuehrer: > Robert > > > Bauer Sitz der Gesellschaft: 86368 Gersthofen Registergericht: > > > Amtsgericht Augsburg HRA 14521 -----Ursprüngliche > Nachricht----- Von: > > > Rod Smith [mailto:rod...@ro... > <mailto:rod...@ro...> > > <mailto:rod...@ro... > <mailto:rod...@ro...>>] Gesendet: Dienstag, 18. > > > Juli 2017 20:24 An: gpt...@li... > <mailto:gpt...@li...> > > <mailto:gpt...@li... > <mailto:gpt...@li...>>; Priebe, > > > Sebastian <Seb...@ca... > <mailto:Seb...@ca...> > > <mailto:Seb...@ca... > <mailto:Seb...@ca...>>> Betreff: Re: > > > [Gptfdisk-general] [PATCH] Support padding between Partition > > > Header(LBA1) and Entries(LBA2) > > > > > > On 07/17/2017 06:38 AM, Priebe, Sebastian wrote: > > >> Hello, > > >> > > >> there was a mail to this list in March 2016 with a patch > adding the > > >> option to change the starting LBA of the PTE (byte 72 in > the GPT > > >> header): > > >> > https://sourceforge.net/p/gptfdisk/mailman/message/34955352/ > <https://sourceforge.net/p/gptfdisk/mailman/message/34955352/> > > >> > > >> Has somebody reviewed or tested that patch? > > > > > > I think I missed that the first time around. > > > > > >> As written in the original message this option is needed > for many > > >> embedded devices as many SoC vendors tends to have their > > >> constraints on where to load its bootcode which may > conflict with > > >> the default starting LBA (2) of GPT fdisk. > > >> > > >> Why has this patch not been included? > > > > > > After reviewing the code, I have a number of problems with > it. Most > > > of these are minor, but the first is major: > > > > > > * I don't understand why this is needed. Why not create a > partition > > > (a BIOS Boot Partition or something analogous) to hold the > SoC boot > > > code? By disabling the 2048-sector alignment policy, such a > partition > > > could easily be located starting at sector 34, which is the > first > > > sector that would be safe to use anyway. This strikes me as a > > > superior solution compared to creating a significant chunk > of the > > > disk that's "in limbo" -- neither allocated to partitions or > official > > > GPT data structures nor available for allocation. It was the > reckless > > > use of such space under MBR that led to numerous conflicts > between > > > boot loaders and other low-level disk utilities with MBR and > > > BIOS-mode booting. Encouraging something similar with GPT > strikes me > > > as a Bad Idea. * Creating a new "j" option on the experts' > menu that > > > replicates what "o" does on the main menu would create > confusion. * > > > The change to "o" on the main menu makes it harder to use. > If this > > > functionality is really needed, that may be unavoidable -- > or perhaps > > > a new function could be added to adjust this setting, > leaving "o" > > > unaffected. * Perhaps adding "j" was done so that sgdisk's > -o could > > > be left to work as it always has. If so, that might be > better done > > > by adding an OPTIONAL parameter to -o. I'm not 100% sure that's > > > possible, though; I'd need to dig into the POPT > documentation. * The > > > patch included no documentation changes. I could write that > myself, > > > of course, but at a minimum, a description of when a > non-standard > > > (that is, non-0) padding size is appropriate would be > helpful, since > > > I'm unfamiliar with the SoC boot loaders that you say would > benefit > > > from such a change. > > > > > > If you can make a case for why putting SoC boot loader code in a > > > partition, even if that means adjust the alignment policy, won't > > > work, then I'll consider this patch. If not, though, I think > it's > > > best to reject this patch, since I don't want to contribute > to old > > > BIOS/MBR problems infecting the EFI/GPT world. > > > > > > If a partition will do the job, but if you don't think the > BIOS Boot > > > Partition is the right type code, then you can create such a > GUID and > > > submit a patch that adds it. (It would help if you have some > > > authority in the field and can get buy-in for using that > type code.) > > > There might even be ways to tweak the alignment code to minimize > > > problems from having a single unaligned partition on a disk, if > > > that's likely to be an issue. > > > > > > -- Rod Smith rod...@ro... > <mailto:rod...@ro...> > > <mailto:rod...@ro... > <mailto:rod...@ro...>> http://www.rodsbooks.com > > > > > > > > > -- > > Rod Smith > > rod...@ro... <mailto:rod...@ro...> > <mailto:rod...@ro... <mailto:rod...@ro...>> > > http://www.rodsbooks.com > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Gptfdisk-general mailing list > > Gpt...@li... > <mailto:Gpt...@li...> > > <mailto:Gpt...@li... > <mailto:Gpt...@li...>> > > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > <https://lists.sourceforge.net/lists/listinfo/gptfdisk-general> > > > > > > > > > -- > Rod Smith > rod...@ro... <mailto:rod...@ro...> > http://www.rodsbooks.com > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Gptfdisk-general mailing list > Gpt...@li... > <mailto:Gpt...@li...> > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > <https://lists.sourceforge.net/lists/listinfo/gptfdisk-general> > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Gptfdisk-general mailing list > Gpt...@li... > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > -- Rod Smith rod...@ro... http://www.rodsbooks.com |
From: Johan M. <joh...@gm...> - 2017-07-21 07:08:18
|
In summary: we all seem to agree that creating a partition for the data read by the SoC ROM is a good idea. What we need in this case is a layout that looks like this: Protective MBR+GPT Header - 1st partition - Partition Entry Table - Rest of the partitions. On 21 July 2017 at 08:58, Priebe, Sebastian <Seb...@ca...> wrote: > Hello Rod, > > I agree with you that this can cause confusion. But there are hard > restrictions by the SOCs and the GPT concept provides all mechanisms to do > what it needed. So, why not let the user of gptfdisk configure it? You can > put all this stuff in the experts section and leave the "normal" user with > the defaults. > > I was thinking of you objections: is it possible to put a partitions at > LBA 2? That's what I need to do. With the possibility to move the PTEs > itself (e.g. to LBA 512), it should be possible to put a partition infront > of the PTEs, right? > > Nevertheless, the option to put the PTEs to a configurable LBA (not 2) is > very needed. > > Greetings, > Sebastian > > > > ------------------------------------------------- > Wir ziehen um! > Ab dem 01.07.2017 > NEUER CADCON HAUPTSITZ > Am Mittleren Moos 53, 86167 Augsburg > ------------------------------------------------- > > CADCON > Ingenieurgesellschaft mbH & Co. KG > Geschaeftsfuehrer: Robert Bauer > Sitz der Gesellschaft: 86368 Gersthofen > Registergericht: Amtsgericht Augsburg HRA 14521 > -----Ursprüngliche Nachricht----- > Von: Rod Smith [mailto:rod...@ro...] > Gesendet: Donnerstag, 20. Juli 2017 19:52 > An: Priebe, Sebastian <Seb...@ca...>; > gpt...@li... > Betreff: Re: AW: [Gptfdisk-general] [PATCH] Support padding between > Partition Header(LBA1) and Entries(LBA2) > > On 07/20/2017 10:20 AM, Priebe, Sebastian wrote: > > That is another good point. > > > > I would love the possibility to configure the start sector of the > > first partition located at offset 40 in the GPT header independently > > of the number of partitions. > > > > Currently it is calculated from the number of partitions. > > Why? This gets back to my first objection, when I misunderstood the point > of the patch. If you're just blocking off space between the first partition > table and the first partition, then a partition is the appropriate way to > reserve that space. Using a partition makes it plain that the space is in > use and can provide some clue (through the partition type code and/or > description) of what its purpose is. > Rendering a set of blocks unusable by normal partitions and useless to GPT > itself just invites confusion and conflicts in how it might be used. > > > *Von:*Johan Myréen [mailto:joh...@gm...] > > *Gesendet:* Mittwoch, 19. Juli 2017 18:57 > > *An:* gpt...@li... > > *Betreff:* Re: [Gptfdisk-general] [PATCH] Support padding between > > Partition Header(LBA1) and Entries(LBA2) > > > > > > > > For the record: when booting from an SD card, the ROM in Allwinner > > SoCs loads 32 kB of code starting at 8 kB. This makes it possible to > > use a shorter, non-standard partition table, but of course it would be > > nicer to be able to avoid hacks like this. > > > > > > > > On 19 July 2017 at 16:27, Rod Smith <rod...@ro... > > <mailto:rod...@ro...>> wrote: > > > > On 07/19/2017 02:16 AM, Priebe, Sebastian wrote: > > > Hello Rod, > > > > > > thx for your quick reply. > > > > > > To your first problem point: Many SOCs don't care about any > > > partitioning during their boot process. E.g. the Freescale (NXP) > SOCs > > > I work with load the LBA block 2 into RAM and expect some special > > > proprietary data there. > > > > OK, thanks. I was mis-reading the code; I thought it was simply > moving > > the first usable sector for partitions, not moving the partition > table > > itself. If an SoC is stupid enough to require boot code at sector 2, > > then that conflicts with the standard GPT positioning, so moving it > may > > be the only solution. > > > > > Currently the gptfdisk tools always put the > > > PTEs there. There is no way around that. I also don't like having > > > some "hidden" data on the disk, but that’s just the way it is. I > also > > > don't see a way of putting bootcode in a partition for the > Freescale > > > case as there are no free blocks available. > > > > > > I can't say anything to your other points, as I haven't looked into > > > the details yet. > > > > I'll give it some more thought. I'm now inclined to do something > about > > this, whether it's accepting some variant of the patch or doing > > something else, liking a new option (analogous to the existing "e" > > option on the experts' menu) to relocate the main partition table > > entries. > > > > > > > > > > > CADCON > > Ingenieurgesellschaft mbH & Co. KG > > Geschaeftsfuehrer: Robert Bauer > > Sitz der Gesellschaft: 86368 Gersthofen > > Registergericht: Amtsgericht Augsburg HRA 14521 > > > > ------------------------------------------------- Wir ziehen um! Ab > > > dem 01.07.2017 NEUER CADCON HAUPTSITZ Am Mittleren Moos 53, 86167 > > > Augsburg ------------------------------------------------- > > > > > > CADCON Ingenieurgesellschaft mbH & Co. KG Geschaeftsfuehrer: Robert > > > Bauer Sitz der Gesellschaft: 86368 Gersthofen Registergericht: > > > Amtsgericht Augsburg HRA 14521 -----Ursprüngliche Nachricht----- > Von: > > > Rod Smith [mailto:rod...@ro... > > <mailto:rod...@ro...>] Gesendet: Dienstag, 18. > > > Juli 2017 20:24 An: gpt...@li... > > <mailto:gpt...@li...>; Priebe, > > > Sebastian <Seb...@ca... > > <mailto:Seb...@ca...>> Betreff: Re: > > > [Gptfdisk-general] [PATCH] Support padding between Partition > > > Header(LBA1) and Entries(LBA2) > > > > > > On 07/17/2017 06:38 AM, Priebe, Sebastian wrote: > > >> Hello, > > >> > > >> there was a mail to this list in March 2016 with a patch adding > the > > >> option to change the starting LBA of the PTE (byte 72 in the GPT > > >> header): > > >> https://sourceforge.net/p/gptfdisk/mailman/message/34955352/ > > >> > > >> Has somebody reviewed or tested that patch? > > > > > > I think I missed that the first time around. > > > > > >> As written in the original message this option is needed for many > > >> embedded devices as many SoC vendors tends to have their > > >> constraints on where to load its bootcode which may conflict with > > >> the default starting LBA (2) of GPT fdisk. > > >> > > >> Why has this patch not been included? > > > > > > After reviewing the code, I have a number of problems with it. Most > > > of these are minor, but the first is major: > > > > > > * I don't understand why this is needed. Why not create a partition > > > (a BIOS Boot Partition or something analogous) to hold the SoC boot > > > code? By disabling the 2048-sector alignment policy, such a > partition > > > could easily be located starting at sector 34, which is the first > > > sector that would be safe to use anyway. This strikes me as a > > > superior solution compared to creating a significant chunk of the > > > disk that's "in limbo" -- neither allocated to partitions or > official > > > GPT data structures nor available for allocation. It was the > reckless > > > use of such space under MBR that led to numerous conflicts between > > > boot loaders and other low-level disk utilities with MBR and > > > BIOS-mode booting. Encouraging something similar with GPT strikes > me > > > as a Bad Idea. * Creating a new "j" option on the experts' menu > that > > > replicates what "o" does on the main menu would create confusion. * > > > The change to "o" on the main menu makes it harder to use. If this > > > functionality is really needed, that may be unavoidable -- or > perhaps > > > a new function could be added to adjust this setting, leaving "o" > > > unaffected. * Perhaps adding "j" was done so that sgdisk's -o could > > > be left to work as it always has. If so, that might be better done > > > by adding an OPTIONAL parameter to -o. I'm not 100% sure that's > > > possible, though; I'd need to dig into the POPT documentation. * > The > > > patch included no documentation changes. I could write that myself, > > > of course, but at a minimum, a description of when a non-standard > > > (that is, non-0) padding size is appropriate would be helpful, > since > > > I'm unfamiliar with the SoC boot loaders that you say would benefit > > > from such a change. > > > > > > If you can make a case for why putting SoC boot loader code in a > > > partition, even if that means adjust the alignment policy, won't > > > work, then I'll consider this patch. If not, though, I think it's > > > best to reject this patch, since I don't want to contribute to old > > > BIOS/MBR problems infecting the EFI/GPT world. > > > > > > If a partition will do the job, but if you don't think the BIOS > Boot > > > Partition is the right type code, then you can create such a GUID > and > > > submit a patch that adds it. (It would help if you have some > > > authority in the field and can get buy-in for using that type > code.) > > > There might even be ways to tweak the alignment code to minimize > > > problems from having a single unaligned partition on a disk, if > > > that's likely to be an issue. > > > > > > -- Rod Smith rod...@ro... > > <mailto:rod...@ro...> http://www.rodsbooks.com > > > > > > > > > -- > > Rod Smith > > rod...@ro... <mailto:rod...@ro...> > > http://www.rodsbooks.com > > > > ------------------------------------------------------------ > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Gptfdisk-general mailing list > > Gpt...@li... > > <mailto:Gpt...@li...> > > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > > > > > > > > > -- > Rod Smith > rod...@ro... > http://www.rodsbooks.com > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Gptfdisk-general mailing list > Gpt...@li... > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > |
From: Priebe, S. <Seb...@ca...> - 2017-07-21 05:58:40
|
Hello Rod, I agree with you that this can cause confusion. But there are hard restrictions by the SOCs and the GPT concept provides all mechanisms to do what it needed. So, why not let the user of gptfdisk configure it? You can put all this stuff in the experts section and leave the "normal" user with the defaults. I was thinking of you objections: is it possible to put a partitions at LBA 2? That's what I need to do. With the possibility to move the PTEs itself (e.g. to LBA 512), it should be possible to put a partition infront of the PTEs, right? Nevertheless, the option to put the PTEs to a configurable LBA (not 2) is very needed. Greetings, Sebastian ------------------------------------------------- Wir ziehen um! Ab dem 01.07.2017 NEUER CADCON HAUPTSITZ Am Mittleren Moos 53, 86167 Augsburg ------------------------------------------------- CADCON Ingenieurgesellschaft mbH & Co. KG Geschaeftsfuehrer: Robert Bauer Sitz der Gesellschaft: 86368 Gersthofen Registergericht: Amtsgericht Augsburg HRA 14521 -----Ursprüngliche Nachricht----- Von: Rod Smith [mailto:rod...@ro...] Gesendet: Donnerstag, 20. Juli 2017 19:52 An: Priebe, Sebastian <Seb...@ca...>; gpt...@li... Betreff: Re: AW: [Gptfdisk-general] [PATCH] Support padding between Partition Header(LBA1) and Entries(LBA2) On 07/20/2017 10:20 AM, Priebe, Sebastian wrote: > That is another good point. > > I would love the possibility to configure the start sector of the > first partition located at offset 40 in the GPT header independently > of the number of partitions. > > Currently it is calculated from the number of partitions. Why? This gets back to my first objection, when I misunderstood the point of the patch. If you're just blocking off space between the first partition table and the first partition, then a partition is the appropriate way to reserve that space. Using a partition makes it plain that the space is in use and can provide some clue (through the partition type code and/or description) of what its purpose is. Rendering a set of blocks unusable by normal partitions and useless to GPT itself just invites confusion and conflicts in how it might be used. > *Von:*Johan Myréen [mailto:joh...@gm...] > *Gesendet:* Mittwoch, 19. Juli 2017 18:57 > *An:* gpt...@li... > *Betreff:* Re: [Gptfdisk-general] [PATCH] Support padding between > Partition Header(LBA1) and Entries(LBA2) > > > > For the record: when booting from an SD card, the ROM in Allwinner > SoCs loads 32 kB of code starting at 8 kB. This makes it possible to > use a shorter, non-standard partition table, but of course it would be > nicer to be able to avoid hacks like this. > > > > On 19 July 2017 at 16:27, Rod Smith <rod...@ro... > <mailto:rod...@ro...>> wrote: > > On 07/19/2017 02:16 AM, Priebe, Sebastian wrote: > > Hello Rod, > > > > thx for your quick reply. > > > > To your first problem point: Many SOCs don't care about any > > partitioning during their boot process. E.g. the Freescale (NXP) SOCs > > I work with load the LBA block 2 into RAM and expect some special > > proprietary data there. > > OK, thanks. I was mis-reading the code; I thought it was simply moving > the first usable sector for partitions, not moving the partition table > itself. If an SoC is stupid enough to require boot code at sector 2, > then that conflicts with the standard GPT positioning, so moving it may > be the only solution. > > > Currently the gptfdisk tools always put the > > PTEs there. There is no way around that. I also don't like having > > some "hidden" data on the disk, but that’s just the way it is. I also > > don't see a way of putting bootcode in a partition for the Freescale > > case as there are no free blocks available. > > > > I can't say anything to your other points, as I haven't looked into > > the details yet. > > I'll give it some more thought. I'm now inclined to do something about > this, whether it's accepting some variant of the patch or doing > something else, liking a new option (analogous to the existing "e" > option on the experts' menu) to relocate the main partition table > entries. > > > > > > CADCON > Ingenieurgesellschaft mbH & Co. KG > Geschaeftsfuehrer: Robert Bauer > Sitz der Gesellschaft: 86368 Gersthofen > Registergericht: Amtsgericht Augsburg HRA 14521 > > ------------------------------------------------- Wir ziehen um! Ab > > dem 01.07.2017 NEUER CADCON HAUPTSITZ Am Mittleren Moos 53, 86167 > > Augsburg ------------------------------------------------- > > > > CADCON Ingenieurgesellschaft mbH & Co. KG Geschaeftsfuehrer: Robert > > Bauer Sitz der Gesellschaft: 86368 Gersthofen Registergericht: > > Amtsgericht Augsburg HRA 14521 -----Ursprüngliche Nachricht----- Von: > > Rod Smith [mailto:rod...@ro... > <mailto:rod...@ro...>] Gesendet: Dienstag, 18. > > Juli 2017 20:24 An: gpt...@li... > <mailto:gpt...@li...>; Priebe, > > Sebastian <Seb...@ca... > <mailto:Seb...@ca...>> Betreff: Re: > > [Gptfdisk-general] [PATCH] Support padding between Partition > > Header(LBA1) and Entries(LBA2) > > > > On 07/17/2017 06:38 AM, Priebe, Sebastian wrote: > >> Hello, > >> > >> there was a mail to this list in March 2016 with a patch adding the > >> option to change the starting LBA of the PTE (byte 72 in the GPT > >> header): > >> https://sourceforge.net/p/gptfdisk/mailman/message/34955352/ > >> > >> Has somebody reviewed or tested that patch? > > > > I think I missed that the first time around. > > > >> As written in the original message this option is needed for many > >> embedded devices as many SoC vendors tends to have their > >> constraints on where to load its bootcode which may conflict with > >> the default starting LBA (2) of GPT fdisk. > >> > >> Why has this patch not been included? > > > > After reviewing the code, I have a number of problems with it. Most > > of these are minor, but the first is major: > > > > * I don't understand why this is needed. Why not create a partition > > (a BIOS Boot Partition or something analogous) to hold the SoC boot > > code? By disabling the 2048-sector alignment policy, such a partition > > could easily be located starting at sector 34, which is the first > > sector that would be safe to use anyway. This strikes me as a > > superior solution compared to creating a significant chunk of the > > disk that's "in limbo" -- neither allocated to partitions or official > > GPT data structures nor available for allocation. It was the reckless > > use of such space under MBR that led to numerous conflicts between > > boot loaders and other low-level disk utilities with MBR and > > BIOS-mode booting. Encouraging something similar with GPT strikes me > > as a Bad Idea. * Creating a new "j" option on the experts' menu that > > replicates what "o" does on the main menu would create confusion. * > > The change to "o" on the main menu makes it harder to use. If this > > functionality is really needed, that may be unavoidable -- or perhaps > > a new function could be added to adjust this setting, leaving "o" > > unaffected. * Perhaps adding "j" was done so that sgdisk's -o could > > be left to work as it always has. If so, that might be better done > > by adding an OPTIONAL parameter to -o. I'm not 100% sure that's > > possible, though; I'd need to dig into the POPT documentation. * The > > patch included no documentation changes. I could write that myself, > > of course, but at a minimum, a description of when a non-standard > > (that is, non-0) padding size is appropriate would be helpful, since > > I'm unfamiliar with the SoC boot loaders that you say would benefit > > from such a change. > > > > If you can make a case for why putting SoC boot loader code in a > > partition, even if that means adjust the alignment policy, won't > > work, then I'll consider this patch. If not, though, I think it's > > best to reject this patch, since I don't want to contribute to old > > BIOS/MBR problems infecting the EFI/GPT world. > > > > If a partition will do the job, but if you don't think the BIOS Boot > > Partition is the right type code, then you can create such a GUID and > > submit a patch that adds it. (It would help if you have some > > authority in the field and can get buy-in for using that type code.) > > There might even be ways to tweak the alignment code to minimize > > problems from having a single unaligned partition on a disk, if > > that's likely to be an issue. > > > > -- Rod Smith rod...@ro... > <mailto:rod...@ro...> http://www.rodsbooks.com > > > > > -- > Rod Smith > rod...@ro... <mailto:rod...@ro...> > http://www.rodsbooks.com > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Gptfdisk-general mailing list > Gpt...@li... > <mailto:Gpt...@li...> > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > > > -- Rod Smith rod...@ro... http://www.rodsbooks.com |