Use parted for partitioning #285
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for that. It may be a while before it gets merged, but at a glance, it looks much batter. |
|
Thanks! Take your time, I'm not blocked by this merge (I'm using a fork of pi-gen customized for my own image anyway). |
Previously, fdisk was used by sending commands into its stdin, which is not very robust (since it heavily relies on the interactive prompts offered by fdisk as well as the default values it offers, which seem prone to changing in future version). It seems likely that in the past, fdisk was easier than parted since it provides default values that make it easier to create adjacent partitions, without precalculating all positions in the script. However now that partitions are manually being aligned, all data must be calculated anyway. This commit changes the partition generation to use parted rather than fdisk. For this, it rewrites various calculations and renames variables to be easier to read as well. All values are now in number of bytes, rather than mixing bytes and sectors. This commit also makes makes sure that the boot partition and root partition are always adjacent (previously the root partition was aligned without also rounding the boot partition size, leaving some empty space in between). As a side effect of using parted, this also causes the "bootcode" part of the MBR to be filled with some default x86 bootcode. This is totally irrelevant for booting the Raspberry Pi, but it does prevent triggering a bug in parted. When using parted to change the partition table (e.g. when resizing the root partition on first boot by raspi-config's init_resize.sh), the disk identifier would be changed due to this bug, which would change the PARTUUID of all partitions. The init_resize.sh script would work around this by updating the PARTUUID in e.g. fstab, but that's fragile at best. This commit prevents the bug from triggering and keeps the disk identifier the same. See https://debbugs.gnu.org/35714 for details about this parted bug. This commit fixes RPi-Distro#284.
matthijskooijman
force-pushed
the
use-parted
branch
from
47d924e to
9e20ae8
Compare
|
I just rebased this PR on top of master, now it applies without conflicts again. |
|
Sorry, this dropped off the radar for a bit. Thank you. |
|
No problem, thanks for merging! |
PeterJohnson
pushed a commit
to PeterJohnson/WPILibPi
that referenced
this pull request
Dec 7, 2019
Previously, fdisk was used by sending commands into its stdin, which is not very robust (since it heavily relies on the interactive prompts offered by fdisk as well as the default values it offers, which seem prone to changing in future version). It seems likely that in the past, fdisk was easier than parted since it provides default values that make it easier to create adjacent partitions, without precalculating all positions in the script. However now that partitions are manually being aligned, all data must be calculated anyway. This commit changes the partition generation to use parted rather than fdisk. For this, it rewrites various calculations and renames variables to be easier to read as well. All values are now in number of bytes, rather than mixing bytes and sectors. This commit also makes makes sure that the boot partition and root partition are always adjacent (previously the root partition was aligned without also rounding the boot partition size, leaving some empty space in between). As a side effect of using parted, this also causes the "bootcode" part of the MBR to be filled with some default x86 bootcode. This is totally irrelevant for booting the Raspberry Pi, but it does prevent triggering a bug in parted. When using parted to change the partition table (e.g. when resizing the root partition on first boot by raspi-config's init_resize.sh), the disk identifier would be changed due to this bug, which would change the PARTUUID of all partitions. The init_resize.sh script would work around this by updating the PARTUUID in e.g. fstab, but that's fragile at best. This commit prevents the bug from triggering and keeps the disk identifier the same. See https://debbugs.gnu.org/35714 for details about this parted bug. This commit fixes RPi-Distro#284.
general-wedge
pushed a commit
to HQapp/hq-os
that referenced
this pull request
Jan 5, 2020
Previously, fdisk was used by sending commands into its stdin, which is not very robust (since it heavily relies on the interactive prompts offered by fdisk as well as the default values it offers, which seem prone to changing in future version). It seems likely that in the past, fdisk was easier than parted since it provides default values that make it easier to create adjacent partitions, without precalculating all positions in the script. However now that partitions are manually being aligned, all data must be calculated anyway. This commit changes the partition generation to use parted rather than fdisk. For this, it rewrites various calculations and renames variables to be easier to read as well. All values are now in number of bytes, rather than mixing bytes and sectors. This commit also makes makes sure that the boot partition and root partition are always adjacent (previously the root partition was aligned without also rounding the boot partition size, leaving some empty space in between). As a side effect of using parted, this also causes the "bootcode" part of the MBR to be filled with some default x86 bootcode. This is totally irrelevant for booting the Raspberry Pi, but it does prevent triggering a bug in parted. When using parted to change the partition table (e.g. when resizing the root partition on first boot by raspi-config's init_resize.sh), the disk identifier would be changed due to this bug, which would change the PARTUUID of all partitions. The init_resize.sh script would work around this by updating the PARTUUID in e.g. fstab, but that's fragile at best. This commit prevents the bug from triggering and keeps the disk identifier the same. See https://debbugs.gnu.org/35714 for details about this parted bug. This commit fixes RPi-Distro#284.
alexgg
pushed a commit
to balena-os/pi-gen
that referenced
this pull request
Jul 12, 2021
Previously, fdisk was used by sending commands into its stdin, which is not very robust (since it heavily relies on the interactive prompts offered by fdisk as well as the default values it offers, which seem prone to changing in future version). It seems likely that in the past, fdisk was easier than parted since it provides default values that make it easier to create adjacent partitions, without precalculating all positions in the script. However now that partitions are manually being aligned, all data must be calculated anyway. This commit changes the partition generation to use parted rather than fdisk. For this, it rewrites various calculations and renames variables to be easier to read as well. All values are now in number of bytes, rather than mixing bytes and sectors. This commit also makes makes sure that the boot partition and root partition are always adjacent (previously the root partition was aligned without also rounding the boot partition size, leaving some empty space in between). As a side effect of using parted, this also causes the "bootcode" part of the MBR to be filled with some default x86 bootcode. This is totally irrelevant for booting the Raspberry Pi, but it does prevent triggering a bug in parted. When using parted to change the partition table (e.g. when resizing the root partition on first boot by raspi-config's init_resize.sh), the disk identifier would be changed due to this bug, which would change the PARTUUID of all partitions. The init_resize.sh script would work around this by updating the PARTUUID in e.g. fstab, but that's fragile at best. This commit prevents the bug from triggering and keeps the disk identifier the same. See https://debbugs.gnu.org/35714 for details about this parted bug. This commit fixes RPi-Distro#284.
UmeshMohan-Dozee
pushed a commit
to DozeeRnD/pi-gen
that referenced
this pull request
Sep 18, 2024
Previously, fdisk was used by sending commands into its stdin, which is not very robust (since it heavily relies on the interactive prompts offered by fdisk as well as the default values it offers, which seem prone to changing in future version). It seems likely that in the past, fdisk was easier than parted since it provides default values that make it easier to create adjacent partitions, without precalculating all positions in the script. However now that partitions are manually being aligned, all data must be calculated anyway. This commit changes the partition generation to use parted rather than fdisk. For this, it rewrites various calculations and renames variables to be easier to read as well. All values are now in number of bytes, rather than mixing bytes and sectors. This commit also makes makes sure that the boot partition and root partition are always adjacent (previously the root partition was aligned without also rounding the boot partition size, leaving some empty space in between). As a side effect of using parted, this also causes the "bootcode" part of the MBR to be filled with some default x86 bootcode. This is totally irrelevant for booting the Raspberry Pi, but it does prevent triggering a bug in parted. When using parted to change the partition table (e.g. when resizing the root partition on first boot by raspi-config's init_resize.sh), the disk identifier would be changed due to this bug, which would change the PARTUUID of all partitions. The init_resize.sh script would work around this by updating the PARTUUID in e.g. fstab, but that's fragile at best. This commit prevents the bug from triggering and keeps the disk identifier the same. See https://debbugs.gnu.org/35714 for details about this parted bug. This commit fixes RPi-Distro#284.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, fdisk was used by sending commands into its stdin, which is
not very robust (since it heavily relies on the interactive prompts
offered by fdisk as well as the default values it offers, which seem
prone to changing in future version).
It seems likely that in the past, fdisk was easier than parted since it
provides default values that make it easier to create adjacent
partitions, without precalculating all positions in the script. However
now that partitions are manually being aligned, all data must be
calculated anyway.
This commit changes the partition generation to use parted rather than
fdisk. For this, it rewrites various calculations and renames variables
to be easier to read as well. All values are now in number of bytes,
rather than mixing bytes and sectors.
This commit also makes makes sure that the boot partition and root
partition are always adjacent (previously the root partition was aligned
without also rounding the boot partition size, leaving some empty space
in between).
As a side effect of using parted, this also causes the "bootcode" part
of the MBR to be filled with some default x86 bootcode. This is totally
irrelevant for booting the Raspberry Pi, but it does prevent triggering
a bug in parted. When using parted to change the partition table (e.g.
when resizing the root partition on first boot by raspi-config's
init_resize.sh), the disk identifier would be changed due to this bug,
which would change the PARTUUID of all partitions. The init_resize.sh
script would work around this by updating the PARTUUID in e.g. fstab,
but that's fragile at best. This commit prevents the bug from
triggering and keeps the disk identifier the same.
See https://debbugs.gnu.org/35714 for details about this parted bug.
This commit fixes #284.