gptfdisk-general Mailing List for GPT fdisk (Page 4)
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: Rod S. <rod...@ro...> - 2017-07-20 17:52:31
|
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 |
From: Priebe, S. <Seb...@ca...> - 2017-07-20 14:24:04
|
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. ------------------------------------------------- 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: 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. |
From: Johan M. <joh...@gm...> - 2017-07-19 16:56:52
|
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...> 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. > > > ------------------------------------------------- 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: Dienstag, 18. > > Juli 2017 20:24 An: gpt...@li...; Priebe, > > Sebastian <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... http://www.rodsbooks.com > > > > > -- > 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: Rod S. <rod...@ro...> - 2017-07-19 13:27:46
|
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. > ------------------------------------------------- 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: Dienstag, 18. > Juli 2017 20:24 An: gpt...@li...; Priebe, > Sebastian <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... http://www.rodsbooks.com > -- Rod Smith rod...@ro... http://www.rodsbooks.com |
From: Priebe, S. <Seb...@ca...> - 2017-07-19 06:16:24
|
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. 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. 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: Dienstag, 18. Juli 2017 20:24 An: gpt...@li...; Priebe, Sebastian <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... http://www.rodsbooks.com |
From: Rod S. <rod...@ro...> - 2017-07-18 18:42:56
|
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... http://www.rodsbooks.com |
From: Priebe, S. <Seb...@ca...> - 2017-07-17 10:54:22
|
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? 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? 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 |
From: Christopher C. <chr...@gm...> - 2017-04-13 07:36:38
|
Just an observation while converting to GPT an so I could resize some partitions from macOS’ Disk Utility on an old hard drive pulled from a Dell laptop but now used for portable storage. gdisk does not recognize the old partition type code of the Dell utility partition, DE00. I haven’t researched whether if Dell continues to use this kind of partition on UEFI systems, nor if there is a new type code to assign; otherwise, since the underlying partition is FAT, maybe it can be converted to always use the Windows GUID rather than the current OS. I don’t imagine this being an issue since the partition is no longer be bootable/accessible from the original system—I’ll probably ignore or delete the partition anyways. However if this does turn out to be an issue, it might be something I can come up with a patch for. Hope this helps, Christopher A. Chavez |
From: Hanno B. <ha...@hb...> - 2017-01-16 16:11:01
|
Hi, The attached file causes a stack buffer overflow in gdisk. This can be seen by compiling gdisk with the memory safety feature address sanitizer (make CFLAGS="-fsanitize=address -g" CXXFLAGS="-fsanitize=address -g" LDFLAGS="-fsanitize=address"). There's a buffer overflow of 8 bytes in the function BasicMBRData::ReadLogicalParts This was found with the fuzzing tool american fuzzy lop. Here's the full stack trace from address sanitizer: ==7508==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc8e455cd8 at pc 0x00000040fab8 bp 0x7ffc8e455a60 sp 0x7ffc8e455a58 WRITE of size 8 at 0x7ffc8e455cd8 thread T0 #0 0x40fab7 in BasicMBRData::ReadLogicalParts(unsigned long, int) /f/gdisk/gptfdisk-code/basicmbr.cc:264 #1 0x40f3cf in BasicMBRData::ReadMBRData(DiskIO*, int) /f/gdisk/gptfdisk-code/basicmbr.cc:200 #2 0x424538 in GPTData::PartitionScan() /f/gdisk/gptfdisk-code/gpt.cc:701 #3 0x424e20 in GPTData::LoadPartitions(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /f/gdisk/gptfdisk-code/gpt.cc:766 #4 0x43d7b0 in main /f/gdisk/gptfdisk-code/gdisk.cc:57 #5 0x7f386c18878f in __libc_start_main (/lib64/libc.so.6+0x2078f) #6 0x403178 in _start (/f/gdisk/gptfdisk-code/gdisk+0x403178) Address 0x7ffc8e455cd8 is located in stack of thread T0 at offset 552 in frame #0 0x40f901 in BasicMBRData::ReadLogicalParts(unsigned long, int) /f/gdisk/gptfdisk-code/basicmbr.cc:247 This frame has 2 object(s): [32, 544) 'ebr' <== Memory access at offset 552 overflows this variable [576, 1600) 'EbrLocations' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /f/gdisk/gptfdisk-code/basicmbr.cc:264 in BasicMBRData::ReadLogicalParts(unsigned long, int) -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hb... GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 |
From: <kol...@sy...> - 2016-10-07 15:01:36
|
Hello before I start with my request I want to thank all of you for your engagement in developing f/oss. I am new to this project and I have a special request to all of you, who have contributed to this project. I am a researcher in the field of social science. My research interest is the developer community of free / open source projects in order to improve community building. I would like to learn something about your experiences in developing software within f/oss-projects. Therefore I am looking for interview partners. If you are willing to participate, please contact me for more informations. Thanks Klasu |
From: Johan M. <je...@to...> - 2016-08-08 18:13:23
|
Thanks for the great programs! One minor point on UUIDs: all the programs (gdisk, sgdisk and cgdisk) print UUIDs in upper case. This is not practical, at least not on Linux, since you can't cut and paste the UUID anywhere. Most other programs represent UUIDs in lower case, and are case sensitive on input. /dev/disk/by-uuid/ presents the UUIDs in lower case, mount(8), blkid(8), swapon(8) and swapoff(8) all use lower case and are case sensitive on input. Wikipedia says: "In its canonical form, a UUID is represented by 32 lowercase hexadecimal digits". Thus lower case would seem to be a natural choice instead of upper case. Would something break if the output format was changed to lower case? Johan Myréen joh...@ik... |
From: Aurimas L. <au...@go...> - 2016-06-29 21:42:59
|
commit 3c1e0296b565f9fbdf5ebc929d6c4c840e060b5a Author: Aurimas Liutikas <au...@go...> Date: Tue May 10 19:16:10 2016 -0700 Fix a couple of clang warnings. - __STDC_CONSTANT_MACROS and __STDC_LIMIT_MACROS might be defined by a project that includes gptfdisk. This patch add #ifndef checks. - register keyword does not do anything in newer compilers. This patch removes it from crc32.cc - all structs need to be fully initialized. This patch adds missing NULL values in gptcl.cc Signed-off-by: Aurimas Liutikas <au...@go...> diff --git a/attributes.cc b/attributes.cc index f3cd585..7c1b990 100644 --- a/attributes.cc +++ b/attributes.cc @@ -6,8 +6,12 @@ /* This program is copyright (c) 2009-2013 by Roderick W. Smith. It is distributed under the terms of the GNU GPL version 2, as detailed in the COPYING file. */ +#ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS +#endif +#ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS +#endif #include <stdint.h> #include <stdio.h> diff --git a/basicmbr.cc b/basicmbr.cc index 5661487..742e95e 100644 --- a/basicmbr.cc +++ b/basicmbr.cc @@ -6,8 +6,12 @@ /* This program is copyright (c) 2009-2013 by Roderick W. Smith. It is distributed under the terms of the GNU GPL version 2, as detailed in the COPYING file. */ +#ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS +#endif +#ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS +#endif #include <stdio.h> #include <stdlib.h> diff --git a/bsd.cc b/bsd.cc index f487f18..d3cf10d 100644 --- a/bsd.cc +++ b/bsd.cc @@ -6,8 +6,12 @@ /* This program is copyright (c) 2009 by Roderick W. Smith. It is distributed under the terms of the GNU GPL version 2, as detailed in the COPYING file. */ +#ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS +#endif +#ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS +#endif #include <stdio.h> //#include <unistd.h> diff --git a/crc32.cc b/crc32.cc index d253dd9..5eca100 100644 --- a/crc32.cc +++ b/crc32.cc @@ -31,7 +31,7 @@ uint32_t crc_tab[256]; */ uint32_t chksum_crc32 (unsigned char *block, unsigned int length) { - register unsigned long crc; + unsigned long crc; unsigned long i; crc = 0xFFFFFFFF; diff --git a/diskio-unix.cc b/diskio-unix.cc index af71cdb..6b3ff14 100644 --- a/diskio-unix.cc +++ b/diskio-unix.cc @@ -12,8 +12,12 @@ // This program is copyright (c) 2009 by Roderick W. Smith. It is distributed // under the terms of the GNU GPL version 2, as detailed in the COPYING file. +#ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS +#endif +#ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS +#endif #include <sys/ioctl.h> #include <string.h> diff --git a/diskio-windows.cc b/diskio-windows.cc index 5535f49..7d3190b 100644 --- a/diskio-windows.cc +++ b/diskio-windows.cc @@ -12,8 +12,12 @@ // This program is copyright (c) 2009, 2010 by Roderick W. Smith. It is distributed // under the terms of the GNU GPL version 2, as detailed in the COPYING file. +#ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS +#endif +#ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS +#endif #include <windows.h> #include <winioctl.h> diff --git a/diskio.cc b/diskio.cc index baf235b..43209cc 100644 --- a/diskio.cc +++ b/diskio.cc @@ -12,8 +12,12 @@ // This program is copyright (c) 2009 by Roderick W. Smith. It is distributed // under the terms of the GNU GPL version 2, as detailed in the COPYING file. +#ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS +#endif +#ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS +#endif #ifdef _WIN32 #include <windows.h> diff --git a/gpt.cc b/gpt.cc index d0a46c6..7e0a535 100644 --- a/gpt.cc +++ b/gpt.cc @@ -6,8 +6,12 @@ /* This program is copyright (c) 2009-2013 by Roderick W. Smith. It is distributed under the terms of the GNU GPL version 2, as detailed in the COPYING file. */ +#ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS +#endif +#ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS +#endif #include <stdio.h> #include <stdlib.h> diff --git a/gptcl.cc b/gptcl.cc index 920dd44..3616996 100644 --- a/gptcl.cc +++ b/gptcl.cc @@ -109,7 +109,7 @@ int GPTDataCL::DoOptions(int argc, char* argv[]) { {"version", 'V', POPT_ARG_NONE, NULL, 'V', "display version information", ""}, {"zap", 'z', POPT_ARG_NONE, NULL, 'z', "zap (destroy) GPT (but not MBR) data structures", ""}, {"zap-all", 'Z', POPT_ARG_NONE, NULL, 'Z', "zap (destroy) GPT and MBR data structures", ""}, - POPT_AUTOHELP { NULL, 0, 0, NULL, 0 } + POPT_AUTOHELP { NULL, 0, 0, NULL, 0, NULL, NULL } }; // Create popt context... diff --git a/gptpart.cc b/gptpart.cc index 17d6f15..0877ae0 100644 --- a/gptpart.cc +++ b/gptpart.cc @@ -12,8 +12,12 @@ // This program is copyright (c) 2009 by Roderick W. Smith. It is distributed // under the terms of the GNU GPL version 2, as detailed in the COPYING file. +#ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS +#endif +#ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS +#endif #ifdef USE_UTF16 #include <unicode/ustdio.h> diff --git a/guid.cc b/guid.cc index 1e73ab7..7c66ad7 100644 --- a/guid.cc +++ b/guid.cc @@ -11,8 +11,12 @@ // // +#ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS +#endif +#ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS +#endif #include <stdio.h> #include <time.h> diff --git a/mbr.cc b/mbr.cc index 08c61be..c063de7 100644 --- a/mbr.cc +++ b/mbr.cc @@ -6,8 +6,12 @@ /* This program is copyright (c) 2009-2013 by Roderick W. Smith. It is distributed under the terms of the GNU GPL version 2, as detailed in the COPYING file. */ +#ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS +#endif +#ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS +#endif #include <stdio.h> #include <stdlib.h> diff --git a/mbrpart.cc b/mbrpart.cc index 0ca5814..ad1d39e 100644 --- a/mbrpart.cc +++ b/mbrpart.cc @@ -17,8 +17,12 @@ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. */ +#ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS +#endif +#ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS +#endif #include <stddef.h> #include <stdint.h> diff --git a/parttypes.cc b/parttypes.cc index 175aca5..4dee3a9 100644 --- a/parttypes.cc +++ b/parttypes.cc @@ -5,8 +5,12 @@ /* This program is copyright (c) 2009-2015 by Roderick W. Smith. It is distributed under the terms of the GNU GPL version 2, as detailed in the COPYING file. */ +#ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS +#endif +#ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS +#endif #include <string.h> #include <stdint.h> diff --git a/support.cc b/support.cc index 0ff3485..b1a5266 100644 --- a/support.cc +++ b/support.cc @@ -6,8 +6,12 @@ /* This program is copyright (c) 2009-2013 by Roderick W. Smith. It is distributed under the terms of the GNU GPL version 2, as detailed in the COPYING file. */ +#ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS +#endif +#ifndef __STDC_CONSTANT_MACROS #define __STDC_CONSTANT_MACROS +#endif #include <stdio.h> #include <stdint.h> |
From: Christoph A. M. <cal...@sc...> - 2016-06-01 22:05:43
|
Hey. A bit late,... From: Rod Smith <rodsmith@ro...> - 2015-05-31 22:57:38 >The trouble is that the response from Linux developers was >overwhelmingly negative. No Linux developer found the case for the >existence of such a code to be compelling, I'm kinda surprised... where exactly did you read that "overwhelmingly negative" response? My understanding was rather that no one really cared a lot, neither negatively nor positively, which is simply based on the fact that partition codes themselves (including the ones for crypto and all others) are basically useless. >and the redundant >information poses a risk of getting out of sync with actual partition >contents. Which is the case for literally any other partition type as well. Yet, you added them. > No Linux partitioning tool or encryption utility actually > uses those codes. Sure, but again, no big surprise... and probably the case for most if not all other partition codes as well,... at least for anything used in the Linux world. The only exception I'd know of is the weird thing systemd offers, i.e. fstab less booting and deciding the mountpoint of some few locations based on a special code for them. But that's really some badly unclean design since a different mountpoint doesn't make a different "type" of partition content (I wonder you supported *that* if you don't support what's actually a proper distinguished type). Other than that, people except the systemd guys hopefully learned enough from the MBR types that caused MD RAID to auto-assemble, that actually using partition types for something without verifying the real type is kinda stupid. >Furthermore, although the number of GUIDs is huge More than there'd be atoms in space... >supporting >every possible code somebody might dream up is impractical for GPT >fdisk, because it increases the size of the list shown when a user >types "L" >to get that code list. An increased list size makes it harder to find >the codes that are actually being used, so supporting these codes >would degrade GPT fdisk's user interface experience. Again, we're talking about two proper and different container types, dm-crypt and LUKS (well one could argue that plain dm-crypt isn't a container, but it's simply nice to have something for that as well). Also I didn't ask you to add combinations for all possible types like. LUKS+ext* LUKS+btrfs LUKS+xfs and so on (which would be bad design again, as the type should only describe the next level). So again I'm kinda surprised that you've added stuff like: bf01 Solaris /usr & Mac Z bf04 Solaris /var bf05 Solaris /home 8301 Linux reserved 8302 Linux /home which are not real types, but just some fs with a connected mountpoint, or: 8300 Linux filesystem which isn't a real type either, but instead there should be types for xfs, jfs, ext*, btrfs, etc. Sure, you had to do this, due to the pressure that people did bad design an misused the partition types for their needs... but then it's really strange that you don't add something which is actually a type proper. >Thus, unless and until I learn that these codes are actually being >used, I will not add them to GPT fdisk's code list. An individual who >wants to use them may still do so by entering the GUID value directly, >but there's really very little benefit to this. Well it would have the same "benefit" than setting e.g. 8300 Linux filesystem, it fills an in the real world unused field within the GPT with a more proper value than e.g. "8300 Linux filesystem" (neither luks nor dm-crypt is a filesystem). Cheers, Chris. |
From: Tzu-Jung L. <roy...@cu...> - 2016-03-22 05:41:17
|
These patch add support to using alternative starting LBA for the Partition Table Entries (default: LBA2). SoC tends to have their constraints on where to load its bootcode. In some cases, those fixed location might conflict with the default layout of GPT (LBA 0/1/2...). I'm not sure if we support "optional" argument. So in order to maintain UI compatibility, we pick currently unused option letters. So current user of option 'o' won't break for the required argument. Signed-off-by: Tzu-Jung Lee <roy...@cu...> diff --git a/gpt.cc b/gpt.cc index d0a46c6..9cb8e7a 100644 --- a/gpt.cc +++ b/gpt.cc @@ -552,7 +552,9 @@ void GPTData::RebuildMainHeader(void) { mainHeader.firstUsableLBA = secondHeader.firstUsableLBA; mainHeader.lastUsableLBA = secondHeader.lastUsableLBA; mainHeader.diskGUID = secondHeader.diskGUID; - mainHeader.partitionEntriesLBA = UINT64_C(2); + mainHeader.partitionEntriesLBA = secondHeader.firstUsableLBA - + ((secondHeader.numParts * GPT_SIZE) / blockSize) - + (((secondHeader.numParts * GPT_SIZE) % blockSize) != 0); mainHeader.numParts = secondHeader.numParts; mainHeader.sizeOfPartitionEntries = secondHeader.sizeOfPartitionEntries; mainHeader.partitionEntriesCRC = secondHeader.partitionEntriesCRC; @@ -773,7 +775,7 @@ int GPTData::LoadPartitions(const string & deviceFilename) { case use_bsd: bsdDisklabel.ReadBSDData(&myDisk, 0, diskSize - 1); // bsdDisklabel.DisplayBSDData(); - ClearGPTData(); + ClearGPTData(GPT_PTE_LBA); protectiveMBR.MakeProtectiveMBR(1); // clear boot area (option 1) XFormDisklabel(&bsdDisklabel); break; @@ -783,7 +785,7 @@ int GPTData::LoadPartitions(const string & deviceFilename) { protectiveMBR.MakeProtectiveMBR(); break; case use_new: - ClearGPTData(); + ClearGPTData(GPT_PTE_LBA); protectiveMBR.MakeProtectiveMBR(); break; case use_abort: @@ -1312,7 +1314,7 @@ int GPTData::LoadGPTBackup(const string & filename) { // Something went badly wrong, so blank out partitions if (allOK == 0) { cerr << "Improper backup file! Clearing all partition data!\n"; - ClearGPTData(); + ClearGPTData(GPT_PTE_LBA); protectiveMBR.MakeProtectiveMBR(); } // if } else { @@ -1336,7 +1338,7 @@ int GPTData::DestroyGPT(void) { uint8_t* emptyTable; memset(blankSector, 0, sizeof(blankSector)); - ClearGPTData(); + ClearGPTData(GPT_PTE_LBA); if (myDisk.OpenForWrite()) { if (!myDisk.Seek(mainHeader.currentLBA)) @@ -1549,7 +1551,7 @@ void GPTData::XFormPartitions(void) { uint8_t origType; // Clear out old data & prepare basics.... - ClearGPTData(); + ClearGPTData(GPT_PTE_LBA); // Convert the smaller of the # of GPT or MBR partitions if (numParts > MAX_MBR_PARTS) @@ -1732,7 +1734,9 @@ int GPTData::SetGPTSize(uint32_t numEntries, int fillGPTSectors) { partitions = newParts; } // if/else existing partitions numParts = numEntries; - mainHeader.firstUsableLBA = ((numEntries * GPT_SIZE) / blockSize) + (((numEntries * GPT_SIZE) % blockSize) != 0) + 2 ; + mainHeader.firstUsableLBA = ((numEntries * GPT_SIZE) / blockSize) + + (((numEntries * GPT_SIZE) % blockSize) != 0) + + mainHeader.partitionEntriesLBA; secondHeader.firstUsableLBA = mainHeader.firstUsableLBA; MoveSecondHeaderToEnd(); if (diskSize > 0) @@ -1836,12 +1840,13 @@ int GPTData::SwapPartitions(uint32_t partNum1, uint32_t partNum2) { // structure, since it may hold the original MBR partitions if the // program was launched on an MBR disk, and those may need to be // converted to GPT format. -int GPTData::ClearGPTData(void) { +int GPTData::ClearGPTData(uint64_t pteSector) { int goOn = 1, i; // Set up the partition table.... delete[] partitions; partitions = NULL; + mainHeader.partitionEntriesLBA = pteSector; SetGPTSize(NUM_GPT_ENTRIES); // Now initialize a bunch of stuff that's static.... @@ -1850,7 +1855,6 @@ int GPTData::ClearGPTData(void) { mainHeader.headerSize = HEADER_SIZE; mainHeader.reserved = 0; mainHeader.currentLBA = UINT64_C(1); - mainHeader.partitionEntriesLBA = (uint64_t) 2; mainHeader.sizeOfPartitionEntries = GPT_SIZE; for (i = 0; i < GPT_RESERVED; i++) { mainHeader.reserved2[i] = '\0'; diff --git a/gpt.h b/gpt.h index e9afd06..8b61536 100644 --- a/gpt.h +++ b/gpt.h @@ -145,7 +145,7 @@ public: uint32_t CreatePartition(uint32_t partNum, uint64_t startSector, uint64_t endSector); void SortGPT(void); int SwapPartitions(uint32_t partNum1, uint32_t partNum2); - int ClearGPTData(void); + int ClearGPTData(uint64_t pteSector); void MoveSecondHeaderToEnd(); int SetName(uint32_t partNum, const UnicodeString & theName); void SetDiskGUID(GUIDData newGUID); diff --git a/gptcl.cc b/gptcl.cc index 7c1d5cf..f5e6340 100644 --- a/gptcl.cc +++ b/gptcl.cc @@ -29,6 +29,7 @@ GPTDataCL::GPTDataCL(void) { attributeOperation = backupFile = partName = hybrids = newPartInfo = NULL; mbrParts = twoParts = outDevice = typeCode = partGUID = diskGUID = NULL; + newHeaderInfo = NULL; alignment = DEFAULT_ALIGNMENT; deletePartNum = infoPartNum = largestPartNum = bsdPartNum = 0; tableSize = GPT_SIZE; @@ -64,7 +65,7 @@ int GPTDataCL::DoOptions(int argc, char* argv[]) { GPTData secondDevice; int opt, numOptions = 0, saveData = 0, neverSaveData = 0; int partNum = 0, newPartNum = -1, saveNonGPT = 1, retval = 0, pretend = 0; - uint64_t low, high, startSector, endSector, sSize; + uint64_t low, high, pteSector, startSector, endSector, sSize; uint64_t temp; // temporary variable; free to use in any case char *device; string cmd, typeGUID, name; @@ -88,6 +89,7 @@ int GPTDataCL::DoOptions(int argc, char* argv[]) { {"randomize-guids", 'G', POPT_ARG_NONE, NULL, 'G', "randomize disk and partition GUIDs", ""}, {"hybrid", 'h', POPT_ARG_STRING, &hybrids, 'h', "create hybrid MBR", "partnum[:partnum...]"}, {"info", 'i', POPT_ARG_INT, &infoPartNum, 'i', "show detailed information on partition", "partnum"}, + {"init", 'I', POPT_ARG_STRING, &newHeaderInfo, 'I', "init partition table", "[pte_lba]"}, {"load-backup", 'l', POPT_ARG_STRING, &backupFile, 'l', "load GPT backup from file", "file"}, {"list-types", 'L', POPT_ARG_NONE, NULL, 'L', "list known partition types", ""}, {"gpttombr", 'm', POPT_ARG_STRING, &mbrParts, 'm', "convert GPT to MBR", "partnum[:partnum...]"}, @@ -263,6 +265,12 @@ int GPTDataCL::DoOptions(int argc, char* argv[]) { case 'i': ShowPartDetails(infoPartNum - 1); break; + case 'I': + JustLooking(0); + pteSector = IeeeToInt(GetString(newHeaderInfo, 1), GetBlockSize(), GPT_PTE_LBA, diskSize, GPT_PTE_LBA); + ClearGPTData(pteSector); + saveData = 1; + break; case 'l': LoadBackupFile(backupFile, saveData, neverSaveData); free(backupFile); @@ -319,7 +327,7 @@ int GPTDataCL::DoOptions(int argc, char* argv[]) { break; case 'o': JustLooking(0); - ClearGPTData(); + ClearGPTData(GPT_PTE_LBA); saveData = 1; break; case 'O': @@ -426,6 +434,14 @@ int GPTDataCL::DoOptions(int argc, char* argv[]) { // Do a few types of operations even if there are problems.... while ((opt = poptGetNextOpt(poptCon)) > 0) { switch (opt) { + case 'I': + JustLooking(0); + pteSector = IeeeToInt(GetString(newHeaderInfo, 1), GetBlockSize(), GPT_PTE_LBA, diskSize, GPT_PTE_LBA); + ClearGPTData(pteSector); + saveData = 1; + cout << "Information: Creating fresh partition table; will override earlier problems!\n"; + retval = 0; + break; case 'l': LoadBackupFile(backupFile, saveData, neverSaveData); cout << "Information: Loading backup partition table; will override earlier problems!\n"; @@ -434,7 +450,7 @@ int GPTDataCL::DoOptions(int argc, char* argv[]) { break; case 'o': JustLooking(0); - ClearGPTData(); + ClearGPTData(GPT_PTE_LBA); saveData = 1; cout << "Information: Creating fresh partition table; will override earlier problems!\n"; retval = 0; diff --git a/gptcl.h b/gptcl.h index 610ca5f..f519936 100644 --- a/gptcl.h +++ b/gptcl.h @@ -32,7 +32,7 @@ class GPTDataCL : public GPTData { // Following are variables associated with popt parameters.... char *attributeOperation, *backupFile, *partName, *hybrids; char *newPartInfo, *mbrParts, *twoParts, *outDevice, *typeCode; - char *partGUID, *diskGUID; + char *partGUID, *diskGUID, *newHeaderInfo; int alignment, deletePartNum, infoPartNum, largestPartNum, bsdPartNum; uint32_t tableSize; poptContext poptCon; diff --git a/gpttext.cc b/gpttext.cc index 718b99b..1da4307 100644 --- a/gpttext.cc +++ b/gpttext.cc @@ -579,7 +579,10 @@ void GPTDataTextUI::MainMenu(string filename) { cout << "This option deletes all partitions and creates a new protective MBR.\n" << "Proceed? "; if (GetYN() == 'Y') { - ClearGPTData(); + ostringstream prompt; + prompt << "First sector (" << GPT_PTE_LBA << "-" << diskSize << ", default = " + << GPT_PTE_LBA << ") or {+-}size{KMGTP}: "; + ClearGPTData(GetSectorNum(GPT_PTE_LBA, diskSize, GPT_PTE_LBA, GetBlockSize(), prompt.str())); MakeProtectiveMBR(); } // if break; @@ -811,6 +814,17 @@ void GPTDataTextUI::ExpertsMenu(string filename) { case 'i': case 'I': ShowDetails(); break; + case 'j': case 'J': + cout << "This option deletes all partitions and creates a new protective MBR.\n" + << "Proceed? "; + if (GetYN() == 'Y') { + ostringstream prompt; + prompt << "First sector (" << GPT_PTE_LBA << "-" << diskSize << ", default = " + << GPT_PTE_LBA << ") or {+-}size{KMGTP}: "; + ClearGPTData(GetSectorNum(GPT_PTE_LBA, diskSize, GPT_PTE_LBA, GetBlockSize(), prompt.str())); + MakeProtectiveMBR(); + } // if + break; case 'l': case 'L': prompt.seekp(0); prompt << "Enter the sector alignment value (1-" << MAX_ALIGNMENT << ", default = " @@ -881,6 +895,7 @@ void GPTDataTextUI::ShowExpertCommands(void) { cout << "g\tchange disk GUID\n"; cout << "h\trecompute CHS values in protective/hybrid MBR\n"; cout << "i\tshow detailed information on a partition\n"; + cout << "j\tcreate a new empty GUID partition table (GPT)\n"; cout << "l\tset the sector alignment value\n"; cout << "m\treturn to main menu\n"; cout << "n\tcreate a new protective MBR\n"; diff --git a/support.h b/support.h index b888d92..9714c44 100644 --- a/support.h +++ b/support.h @@ -65,6 +65,7 @@ // Number and size of GPT entries... #define NUM_GPT_ENTRIES 128 #define GPT_SIZE 128 +#define GPT_PTE_LBA 2 #define HEADER_SIZE UINT32_C(92) #define GPT_RESERVED 420 #define NAME_SIZE 36 // GPT allows 36 UTF-16LE code units for a name in a 128 byte partition entry -- 2.7.3 |
From: Joel R. <joe...@gm...> - 2015-10-21 19:44:10
|
Okay, here's the patch as an attachment. It's the output of git-diff at the current HEAD. I've removed the #warning line I used to make sure uuid/uuid.h was included, and added OpenBSD to the instructions in README. Not much to patch, really, just adding tests for __OpenBSD__ being defined instead of __FreeBSD__. And the ioctl(fd, DIOCGFLUSH) in diskio-unix.cc, I couldn't find DIOCGFLUSH or an equivalent, so I'm swagging an fsync. That probably needs to be checked by someone who knows more than I do. I'm trying to get some eyeballs on it over at misc@openbsd, but I may need to go to the dev list with a complete package before they'll look at it. Sorry I couldn't respond. I've been asleep. On Wed, Oct 21, 2015 at 10:59 PM, Rod Smith <rod...@ro...> wrote: > On 10/21/2015 09:11 AM, Joel Rees wrote: >> Well, actually, I have it compiling cleanly and appearing to function. >> >> Need to think about what kinds of tests I can run. >> >> Using make -f Makefile.freebsd brings /usr/local/include in so that >> uuid/uuid.h is found (and gets around the kludge, etc.). >> >> Here's the real diff: > > Your patch is failing to apply because of e-mail transformations. Please > send it to me as an attachment, not inline. > [...] -- Joel Rees Be careful when you look at conspiracy. Arm yourself with knowledge of yourself, as well: http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html |
From: Rod S. <rod...@ro...> - 2015-10-21 14:00:05
|
On 10/21/2015 09:11 AM, Joel Rees wrote: > Well, actually, I have it compiling cleanly and appearing to function. > > Need to think about what kinds of tests I can run. > > Using make -f Makefile.freebsd brings /usr/local/include in so that > uuid/uuid.h is found (and gets around the kludge, etc.). > > Here's the real diff: Your patch is failing to apply because of e-mail transformations. Please send it to me as an attachment, not inline. > ----------------------- > diff --git a/diskio-unix.cc b/diskio-unix.cc > index af71cdb..83b60f9 100644 > --- a/diskio-unix.cc > +++ b/diskio-unix.cc > @@ -248,6 +248,13 @@ int DiskIO::DiskSync(void) { > << "You should reboot or remove the drive.\n"; > platformFound++; > #endif > +#if defined (__OpenBSD__) // Shamelessly parroting the FreeBSD code. > + sleep(2); > + i = fsync(fd); // Is this how to force a flush on a disk device? > + cout << "Warning: The kernel may continue to use old or deleted > partitions.\n" > + << "You should reboot or remove the drive.\n"; > + platformFound++; > +#endif > #ifdef __linux__ > sleep(1); // Theoretically unnecessary, but ioctl() fails > sometimes if omitted.... > fsync(fd); > diff --git a/diskio.h b/diskio.h > index 631a43a..c198f29 100644 > > --- a/diskio.h > +++ b/diskio.h > @@ -29,7 +29,7 @@ > #include <sys/dkio.h> > #endif > > -#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined > (__APPLE__) > +#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined > (__OpenBSD__) || defined (__APPLE__) > #define fstat64 fstat > #define stat64 stat > #endif > diff --git a/guid.cc b/guid.cc > index 1e73ab7..0fd8bfe 100644 > --- a/guid.cc > +++ b/guid.cc > @@ -147,6 +147,8 @@ void GUIDData::Randomize(void) { > ReverseBytes(&uuidData[4], 2); > ReverseBytes(&uuidData[6], 2); > uuidGenerated = 1; > +#else > > +# warning "not compiling in the uuid_generate()" > #endif > #if defined (_RPC_H) || defined (__RPC_H__) > UUID MsUuid; > diff --git a/support.h b/support.h > index b888d92..dd3ea03 100644 > --- a/support.h > +++ b/support.h > @@ -10,7 +10,7 @@ > > #define GPTFDISK_VERSION "1.0.1" > > -#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined > (__APPLE__) > +#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || > (__OpenBSD__) || defined (__APPLE__) > // Darwin (Mac OS) & FreeBSD: disk IOCTLs are different, and there is > no lseek64 > #include <sys/disk.h> > #define lseek64 lseek > ~ > ~ > ----------------------- > > Whaddaya think? > > -- > Joel Rees > > ------------------------------------------------------------------------------ > _______________________________________________ > Gptfdisk-general mailing list > Gpt...@li... > https://lists.sourceforge.net/lists/listinfo/gptfdisk-general > -- Rod Smith rod...@ro... http://www.rodsbooks.com |
From: Joel R. <joe...@gm...> - 2015-10-21 13:11:21
|
Well, actually, I have it compiling cleanly and appearing to function. Need to think about what kinds of tests I can run. Using make -f Makefile.freebsd brings /usr/local/include in so that uuid/uuid.h is found (and gets around the kludge, etc.). Here's the real diff: ----------------------- diff --git a/diskio-unix.cc b/diskio-unix.cc index af71cdb..83b60f9 100644 --- a/diskio-unix.cc +++ b/diskio-unix.cc @@ -248,6 +248,13 @@ int DiskIO::DiskSync(void) { << "You should reboot or remove the drive.\n"; platformFound++; #endif +#if defined (__OpenBSD__) // Shamelessly parroting the FreeBSD code. + sleep(2); + i = fsync(fd); // Is this how to force a flush on a disk device? + cout << "Warning: The kernel may continue to use old or deleted partitions.\n" + << "You should reboot or remove the drive.\n"; + platformFound++; +#endif #ifdef __linux__ sleep(1); // Theoretically unnecessary, but ioctl() fails sometimes if omitted.... fsync(fd); diff --git a/diskio.h b/diskio.h index 631a43a..c198f29 100644 --- a/diskio.h +++ b/diskio.h @@ -29,7 +29,7 @@ #include <sys/dkio.h> #endif -#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined (__APPLE__) +#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined (__OpenBSD__) || defined (__APPLE__) #define fstat64 fstat #define stat64 stat #endif diff --git a/guid.cc b/guid.cc index 1e73ab7..0fd8bfe 100644 --- a/guid.cc +++ b/guid.cc @@ -147,6 +147,8 @@ void GUIDData::Randomize(void) { ReverseBytes(&uuidData[4], 2); ReverseBytes(&uuidData[6], 2); uuidGenerated = 1; +#else +# warning "not compiling in the uuid_generate()" #endif #if defined (_RPC_H) || defined (__RPC_H__) UUID MsUuid; diff --git a/support.h b/support.h index b888d92..dd3ea03 100644 --- a/support.h +++ b/support.h @@ -10,7 +10,7 @@ #define GPTFDISK_VERSION "1.0.1" -#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined (__APPLE__) +#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || (__OpenBSD__) || defined (__APPLE__) // Darwin (Mac OS) & FreeBSD: disk IOCTLs are different, and there is no lseek64 #include <sys/disk.h> #define lseek64 lseek ~ ~ ----------------------- Whaddaya think? -- Joel Rees |
From: Rod S. <rod...@ro...> - 2015-10-21 12:41:47
|
On 10/20/2015 11:25 PM, Joel Rees wrote: > Trying to compile gpt-fdisk on openbsd. I don't think I've ever tried compiling GPT fdisk on OpenBSD, and I don't recall hearing of anybody else doing it. That said.... > in guid.h, we have > --------------- > // Have to play games with uuid_t since it's defined in incompatible ways > // for Unix (libuuid) vs. Windows (in rpc.h) ... > However, in openbsd, in sys/uuid.h, we have ... > Extending the MSWindows hack to openbsd does allow compiling to > proceed a bit farther, > > ---------------- > $ make ... > g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c diskio-unix.cc > diskio-unix.cc: In member function 'int DiskIO::DiskSync()': > diskio-unix.cc:222: warning: unused variable 'i' > diskio-unix.cc: In member function 'int DiskIO::Seek(uint64_t)': > diskio-unix.cc:285: error: 'lseek64' was not declared in this scope > *** Error 1 in /home/family/work/sf/gptfdisk-code (<sys.mk>:97 'diskio-unix.o') > ---------------- > > but it really wants some kind of compile-time check, or at least a > run-time check. It sounds like you've gotten past the initial uuid_t definition issue (although whether it will work in the compiled program is another matter). The lseek64 issue is entirely different. If you check support.h, you'll see that "lseek64" is redefined to "lseek" for some platforms that don't provide this call. You may work around this second issue by expanding the list to include OpenBSD. -- Rod Smith rod...@ro... http://www.rodsbooks.com |
From: Joel R. <joe...@gm...> - 2015-10-21 03:26:03
|
Trying to compile gpt-fdisk on openbsd. in guid.h, we have --------------- // Have to play games with uuid_t since it's defined in incompatible ways // for Unix (libuuid) vs. Windows (in rpc.h) #ifdef _WIN32 #include <rpc.h> #ifdef _MSC_VER #pragma comment(lib, "Rpcrt4.lib") #endif typedef unsigned char my_uuid_t[16]; #else // Not Windows #if defined (__OpenBSD__) #include <sys/uuid.h> // maybe it should be uuid.h? (JMRees) typedef uuid_t my_uuid_t[1]; #else #include <uuid/uuid.h> typedef uuid_t my_uuid_t; #endif #endif --------------- However, in openbsd, in sys/uuid.h, we have struct uuid { uint32_t time_low; uint16_t time_mid; uint16_t time_hi_and_version; uint8_t clock_seq_hi_and_reserved; uint8_t clock_seq_low; uint8_t node[_UUID_NODE_LEN]; }; and (since this isn't kernel) typedef struct uuid uuid_t; For a lark, I tried this in guid.h: --------------- #else // Not Windows #if defined (__OpenBSD__) #include <sys/uuid.h> // maybe it should be uuid.h? (JMRees) typedef uuid_t my_uuid_t[1]; #else #include <uuid/uuid.h> typedef uuid_t my_uuid_t; #endif #endif --------------- but that contradicts usage in guid.cc in a number of places which seem to expect an array of bytes. Extending the MSWindows hack to openbsd does allow compiling to proceed a bit farther, ---------------- $ make g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c crc32.cc g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c support.cc g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c guid.cc g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c gptpart.cc g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c mbrpart.cc g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c basicmbr.cc g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c mbr.cc g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c gpt.cc g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c bsd.cc g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c parttypes.cc g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c attributes.cc g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c diskio.cc g++ -O2 -pipe -Wall -D_FILE_OFFSET_BITS=64 -c diskio-unix.cc diskio-unix.cc: In member function 'int DiskIO::DiskSync()': diskio-unix.cc:222: warning: unused variable 'i' diskio-unix.cc: In member function 'int DiskIO::Seek(uint64_t)': diskio-unix.cc:285: error: 'lseek64' was not declared in this scope *** Error 1 in /home/family/work/sf/gptfdisk-code (<sys.mk>:97 'diskio-unix.o') ---------------- but it really wants some kind of compile-time check, or at least a run-time check. Any thoughts? -- Joel Rees Be careful when you look at conspiracy. Arm yourself with knowledge of yourself, as well: http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html ============ $ git diff diff --git a/diskio.h b/diskio.h index 631a43a..c198f29 100644 --- a/diskio.h +++ b/diskio.h @@ -29,7 +29,7 @@ #include <sys/dkio.h> #endif -#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined (__APPLE__) +#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined (__OpenBSD__) || defined (__APPLE__) #define fstat64 fstat #define stat64 stat #endif diff --git a/guid.h b/guid.h index 229d5bd..9210af5 100644 --- a/guid.h +++ b/guid.h @@ -26,8 +26,14 @@ #endif typedef unsigned char my_uuid_t[16]; #else // Not Windows + #if defined (__OpenBSD__) +#include <sys/uuid.h> // maybe it should be uuid.h? (JMRees) +//typedef uuid_t my_uuid_t[1]; +typedef unsigned char my_uuid_t[16]; + #else #include <uuid/uuid.h> typedef uuid_t my_uuid_t; + #endif #endif using namespace std; |
From: Alexander v. G. I. <kal...@un...> - 2015-10-07 22:00:16
|
October 7 2015 4:25 PM, "Rod Smith" <rod...@ro...> wrote: > On 10/05/2015 02:09 PM, Jörg Jenderek wrote: > >> Hello, >> i used backup software Acronis True Image (see >> https://en.wikipedia.org/wiki/Acronis_True_Image) >> >> This software creates and use an own partition >> called "Acronis Secure Zone" ( see >> https://en.wikipedia.org/wiki/Acronis_Secure_Zone ) >> for storing backup files. >> >> But when i start gdisk and print the partition table, >> i get lines like: >> Number Start (sector) End (sector) Size Code Name >> 7 27293696 163612671 65.0 GiB 0700 Windows 8.x 52 GB >> 8 174116864 176338943 1.1 GiB FFFF >> 9 176339787 250067786 35.2 GiB 8300 SUSE 13.1 35 GB >> >> The detailed information about partition 8 by 'i'-key are: >> Partition GUID code: 0311FC50-01CA-4725-AD77-9ADBB20ACE98 (Unknown) >> Partition unique GUID: BB93ADA1-75CD-437E-96D0-8BBA1B75653C >> First sector: 174116864 (at 83.0 GiB) >> Last sector: 176338943 (at 84.1 GiB) >> Partition size: 2222080 sectors (1.1 GiB) >> Attribute flags: 0000000000000000 >> Partition name: '' >> >> So it would be nice, if future versions of gdisk could recognize partitions >> with GUID 0311FC50-01CA-4725-AD77-9ADBB20ACE98 as "Acronis Secure Zone". > > Thanks for reporting this. I take it that Acronis set this up > automatically? I ask because I tried Googling > "0311FC50-01CA-4725-AD77-9ADBB20ACE98" and found no hits, so this > doesn't seem to be documented on any Web-accessible site -- or at least, > if it is, Google hasn't found it yet. I've tentatively added this type > code for the next release; I just want to verify that it's actually in > use "in the wild" before I do the release. Thanks! Given the nature of these GPT id's, not sure gptfdisk should define it if Acronis hasn't documented it anywhere.. it could be randomly picked for all we know. Jörg, could you reach out to Acronis to confirm? -- Alex |
From: Rod S. <rod...@ro...> - 2015-10-07 21:25:27
|
On 10/05/2015 02:09 PM, Jörg Jenderek wrote: > Hello, > i used backup software Acronis True Image (see > https://en.wikipedia.org/wiki/Acronis_True_Image) > > This software creates and use an own partition > called "Acronis Secure Zone" ( see > https://en.wikipedia.org/wiki/Acronis_Secure_Zone ) > for storing backup files. > > But when i start gdisk and print the partition table, > i get lines like: > Number Start (sector) End (sector) Size Code Name > 7 27293696 163612671 65.0 GiB 0700 Windows 8.x 52 GB > 8 174116864 176338943 1.1 GiB FFFF > 9 176339787 250067786 35.2 GiB 8300 SUSE 13.1 35 GB > > The detailed information about partition 8 by 'i'-key are: > Partition GUID code: 0311FC50-01CA-4725-AD77-9ADBB20ACE98 (Unknown) > Partition unique GUID: BB93ADA1-75CD-437E-96D0-8BBA1B75653C > First sector: 174116864 (at 83.0 GiB) > Last sector: 176338943 (at 84.1 GiB) > Partition size: 2222080 sectors (1.1 GiB) > Attribute flags: 0000000000000000 > Partition name: '' > > So it would be nice, if future versions of gdisk could recognize partitions > with GUID 0311FC50-01CA-4725-AD77-9ADBB20ACE98 as "Acronis Secure Zone". Thanks for reporting this. I take it that Acronis set this up automatically? I ask because I tried Googling "0311FC50-01CA-4725-AD77-9ADBB20ACE98" and found no hits, so this doesn't seem to be documented on any Web-accessible site -- or at least, if it is, Google hasn't found it yet. I've tentatively added this type code for the next release; I just want to verify that it's actually in use "in the wild" before I do the release. Thanks! -- Rod Smith rod...@ro... http://www.rodsbooks.com |
From: Jörg J. <joe...@gm...> - 2015-10-05 18:09:02
|
Hello, i used backup software Acronis True Image (see https://en.wikipedia.org/wiki/Acronis_True_Image) This software creates and use an own partition called "Acronis Secure Zone" ( see https://en.wikipedia.org/wiki/Acronis_Secure_Zone ) for storing backup files. But when i start gdisk and print the partition table, i get lines like: Number Start (sector) End (sector) Size Code Name 7 27293696 163612671 65.0 GiB 0700 Windows 8.x 52 GB 8 174116864 176338943 1.1 GiB FFFF 9 176339787 250067786 35.2 GiB 8300 SUSE 13.1 35 GB The detailed information about partition 8 by 'i'-key are: Partition GUID code: 0311FC50-01CA-4725-AD77-9ADBB20ACE98 (Unknown) Partition unique GUID: BB93ADA1-75CD-437E-96D0-8BBA1B75653C First sector: 174116864 (at 83.0 GiB) Last sector: 176338943 (at 84.1 GiB) Partition size: 2222080 sectors (1.1 GiB) Attribute flags: 0000000000000000 Partition name: '' So it would be nice, if future versions of gdisk could recognize partitions with GUID 0311FC50-01CA-4725-AD77-9ADBB20ACE98 as "Acronis Secure Zone". With best regards Jörg Jenderek -- Jörg Jenderek email: joerg.jen.der.ek (at) gmx.net Germany PGP: B9FE A356 283E 0048 6389 18BF AFF2 B1C9 421A D4D6 |
From: Jörg J. <joe...@gm...> - 2015-09-21 20:13:01
|
Hello, I used the efi 64 bit port of gdisk version 1.0.0. I tried to change the name of partition number 5. When i entered the 14 characters "FAT16 DOS 2GB" and pressed the enter key, finally display is a partition summary like Number Start (sector) End (sector) Size Code Name 1 2048 616447 300.0 MiB EF00 FAT32 EFI 300 MB 2 616448 878591 128.0 MiB 0C01 MiroSoft Reserved 1... 3 878592 8046591 3.4 GiB 8200 SWAP Linux 3.5 GB 4 8046592 8763391 350.0 MiB 2700 NTFS Windows RE 350 MB 5 8763392 12955647 2.0 GiB 0700 FAT16 DOS 2GB 6 12955648 27291647 6.8 GiB 0700 FAT32 7 GB Furthermore i looked in the hexdump of the corresponding sector: 00000000: a2a0 d0eb e5b9 3344 87c0 68b6 b726 99c7 ......3D..h..&.. 00000010: 76f8 0a89 393e 8b44 9664 8505 bfb5 0349 v...9>.D.d.....I 00000020: 00b8 8500 0000 0000 ffaf c500 0000 0000 ................ 00000030: 0000 0000 0000 0000 4600 4100 5400 3100 ........F.A.T.1. 00000040: 3600 2000 4400 4f00 5300 2000 2000 3200 6. .D.O.S. . .2. 00000050: 4700 4200 0a00 0000 0000 0000 0000 0000 G.B............. There i saw an additional 0x0a00 (Linefeed, NewLine or CTRL-J character) after the 14 characters entered string. I think this a bug in the efi port of gdisk program, because when i run the same procedure with the windows 64 bit port of gdisk with same version, the "c" key changed the partition name correctly without the additional enter character. I am using an Intel DH87RL main board with BIOS (latest Version RLH8710H.86A.0326.2014.0528.1542, 28.05.2014) and 2 standard USB keyboards (Tevion MD42488 and General keys PX-3070675). With best regards Jörg Jenderek -- Jörg Jenderek email: joerg.jen.der.ek (at) gmx.net Germany PGP: B9FE A356 283E 0048 6389 18BF AFF2 B1C9 421A D4D6 |
From: Cody P S. <de...@co...> - 2015-06-17 21:37:20
|
"IeeeToInt: initialize suffix" fixes an issue where sgdisk would occasionally try to create partitions that started very far into the disk. "Always use off64_t to avoid overflow issues" fixes an issue on 32bit when CFLAGS are overridden and as a result _FILE_OFFSET_BITS is not passed. Note that with this change, I don't think we actually need to pass _FILE_OFFSET_BITS any more. "if there is any error, report it via return value" ensures that if there is an error writing data, the command does not return success, hiding it's failure until later in the calling script. "seek: detect and complain about seek overflows" fixes a theoretical issue related to the off64_t issue fixed above. I haven't actually triggered the bug this fixes, though. Cody P Schafer (4): IeeeToInt: initialize suffix if there is any error, report it via return value Always use off64_t to avoid overflow issues seek: detect and complain about seek overflows diskio-unix.cc | 11 ++++++++--- gptcl.cc | 5 ++++- support.cc | 2 +- 3 files changed, 13 insertions(+), 5 deletions(-) -- 2.4.3 |
From: Cody P S. <de...@co...> - 2015-06-17 21:37:05
|
--- diskio-unix.cc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/diskio-unix.cc b/diskio-unix.cc index 7be0bbe..71b4387 100644 --- a/diskio-unix.cc +++ b/diskio-unix.cc @@ -272,7 +272,7 @@ int DiskIO::DiskSync(void) { // Note that seeking beyond the end of the file is NOT detected as a failure! int DiskIO::Seek(uint64_t sector) { int retval = 1; - off_t seekTo, sought; + off64_t seekTo, sought; // If disk isn't open, try to open it.... if (!isOpen) { @@ -389,7 +389,7 @@ int DiskIO::Write(void* buffer, int numBytes) { // return correct values for disk image files. uint64_t DiskIO::DiskSize(int *err) { uint64_t sectors = 0; // size in sectors - off_t bytes = 0; // size in bytes + off64_t bytes = 0; // size in bytes struct stat64 st; int platformFound = 0; #ifdef __sun__ -- 2.4.3 |