Consider supporting a safety check to avoid overwriting data partitions #190
Labels
Comments
bgilbert
added a commit
to glennswest/coreos-installer
that referenced
this issue
Jul 31, 2020
Add --save-partlabel <glob> and --save-partindex <range> options, which save partition table metadata for existing data partitions and then restore those partitions after writing the image. --save-partlabel takes a glob pattern matching the partition label, and --save-partindex takes a partition number or range of partition numbers (possibly single-ended). For example, to save all partitions with indexes greater than 4, specify "--save-partindex 5-". The specified partitions need not exist. If no --save-* options are specified, no partitions are saved. Multiples of each option can be specified, and/or multiple filters can be specified within a single option argument by separating them with commas. There are corresponding kargs coreos.inst.save_partlabel and coreos.inst.save_partindex, which cannot be repeated but which accept comma-separated patterns. Upon restore, try to reuse the original partition number. If it's not available, renumber the partition to one more than the highest number used so far. For simplicity, never backfill entries earlier in the partition table, even if the corresponding slot is unused. If a saved partition overlaps with the image contents, fail. This can't be detected in advance, so detect the overrun during fetch and stop before the saved partition is clobbered. Also fail if the install image has a partition extending past the end of the image that overlaps with a saved partition. On any failure, after clearing the partition table, restore any saved partitions. In addition, augment partition-table clearing to clear the backup GPT, since some tools may otherwise hallucinate partitions that were overwritten during the install. All of this assumes GPT partitioning both in the image and on disk, so if --save-* options are specified for a DASD target, fail. Fixes coreos#190. Co-authored-by: Glenn West <gwest@redhat.com>
nikita-dubrovskii
pushed a commit
to nikita-dubrovskii/coreos-installer
that referenced
this issue
Aug 19, 2020
Add --save-partlabel <glob> and --save-partindex <range> options, which save partition table metadata for existing data partitions and then restore those partitions after writing the image. --save-partlabel takes a glob pattern matching the partition label, and --save-partindex takes a partition number or range of partition numbers (possibly single-ended). For example, to save all partitions with indexes greater than 4, specify "--save-partindex 5-". The specified partitions need not exist. If no --save-* options are specified, no partitions are saved. Multiples of each option can be specified, and/or multiple filters can be specified within a single option argument by separating them with commas. There are corresponding kargs coreos.inst.save_partlabel and coreos.inst.save_partindex, which cannot be repeated but which accept comma-separated patterns. Upon restore, try to reuse the original partition number. If it's not available, renumber the partition to one more than the highest number used so far. For simplicity, never backfill entries earlier in the partition table, even if the corresponding slot is unused. If a saved partition overlaps with the image contents, fail. This can't be detected in advance, so detect the overrun during fetch and stop before the saved partition is clobbered. Also fail if the install image has a partition extending past the end of the image that overlaps with a saved partition. On any failure, after clearing the partition table, restore any saved partitions. In addition, augment partition-table clearing to clear the backup GPT, since some tools may otherwise hallucinate partitions that were overwritten during the install. All of this assumes GPT partitioning both in the image and on disk, so if --save-* options are specified for a DASD target, fail. Fixes coreos#190. Co-authored-by: Glenn West <gwest@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature Request
Desired Feature
Users might want to use coreos-installer to reprovision existing systems that have a data partition on the boot disk. coreos-installer overwrites the partition table, but that's okay, since the Ignition config can recreate the data partition in the same place and its data will be intact.
However, there's no explicit guarantee that future install images won't be larger than current ones, which could cause coreos-installer to silently clobber the data partition.
Consider adding some mechanism to ensure important data isn't clobbered. I don't think we can do this automatically; we'd have to understand the intentions of the existing partition table. The simplest (and least user-friendly) approach is to add an argument specifying a byte offset limit, and error out if we try to cross it.
We can't generally perform this safety check without actually trying to install; the supported decompressors don't provide a way to obtain the uncompressed length of the payload.
The text was updated successfully, but these errors were encountered: