On Tue, 14 Jul 2015, Dale R. Worley wrote: > Scott Moser <smoser@xxxxxxxxxx> writes: > > If sfdisk does not know the uuid provided, it silently falls back to > > 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem). > > > > It seems like if the user provided you with a GUID, sfdisk should trust > > them, or at very least exit failure if it refuses to use the provided > > GUID. > > Ugh, you're right! Silent disobedience is pernicious. My hack / "will this work" to fdisk_label_parse_parttype seemed to get a functional fdisk_new_unknown_parttype that would be used. diff --git a/libfdisk/src/parttype.c b/libfdisk/src/parttype.c index aedf4e8..bda850a 100644 --- a/libfdisk/src/parttype.c +++ b/libfdisk/src/parttype.c @@ -335,6 +335,7 @@ struct fdisk_parttype *fdisk_label_parse_parttype( if (ret) goto done; + typestr = str; /* maybe specified by order number */ errno = 0; i = strtol(str, &end, 0); @@ -347,7 +348,7 @@ struct fdisk_parttype *fdisk_label_parse_parttype( ret = fdisk_new_unknown_parttype(code, typestr); done: - DBG(PARTTYPE, ul_debugobj(ret, "returns parsed '%s' partition type", ret->name)); + DBG(PARTTYPE, ul_debugobj(ret, "returns parsed '%s' partition type (%s)", ret->name, ret->typestr)); return ret; } -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
