Bug#751704: libparted questions (was: Bug#751704: partman-base 173: partman overwrites parts of u-boot)
[CCing Otavio Salvador and Jim Meyering; the following is a short summary
of the situation; the full history can be read in bug #751704:
Debian-Installer uses partman for partitioning, which in turn is
based on libparted. On sunxi-based systems, upon writing the partition
table, partman/libparted overwrites parts of u-boot which are
located between the end of the partition table and the beginning of the
first partition which results in an unbootable system.
An attempt to solve this problem has been to conditionally set
PedDisk.needs_clobber to 0 in partman when it detects that it is
trying to write to a boot device on sunxi-based systems.]
Colin Watson <cjwatson@debian.org> wrote:
> PedDisk.needs_clobber is marked as "office use only" in parted; I
> interpret that as meaning that it really shouldn't be fiddled with
> outside parted, even though it's technically exposed. Could you please
> look at fixing parted to avoid clobbering the firmware area instead? I
> think that would be more correct.
I have no idea what is really meant with the comment
/* office use only ;-) */
int needs_clobber;
in /usr/include/parted/disk.h, so I would like to ask upstream
for clarification. Otavio, Jim: you are listed as parted
upstream maintainers on http://www.gnu.org/software/parted/ - could
you shed some light on this? Is it ok for an application to fiddle
with the needs_clobber element or is this to be considered
strictly libparted-internal?
@Colin: If the solution is to be completely encapsulated in
libparted, I see a large problem in how to solve the conflict between
space after the partition table being very differently used by
firmware for different SoCs on one side, and libparted trying to make
sure that there are no remains of other partition table formats in
the respective area on the other side - at least with the
prerequisite of keeping both the current defaults (clobbering) as
well as keeping the libparted API unchanged. With the current "there
is one erase size for all platforms" method in ped_disk_clobber() in
libparted/disk.c, we inevitably end up with conflicting requirements.
An example: the source for ped_disk_clobber() states:
/* How many sectors to zero out at each end.
This must be large enough to zero out the magic bytes
starting at offset 8KiB on a DASD partition table.
Doing the same from the end of the disk is probably
overkill, but at least on GPT, we do need to zero out
the final sector. */
So for at least one platform (according to Wikipedia DASD seems to be
some s/390 format), the area at offset 8KiB has to be wiped out while
for another (armhf/sunxi) it may not be wiped out as the u-boot SPL is
located there and cannot be relocated because its sector address is
hardcoded in the SoC.
According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#25,
similar problems (but at other offsets) come up for other SoCs.
According to the examples listed there, for TI SoCs libparted would
have to stop clobbering the GPT header after writing a DOS MBR, but
could wipe the DASD area. For a Freescale i.MX SoC libparted could
legally clobber the GPT header, but would have to refrain from
clobbering the areas behind it. If you extrapolate this to the large
number of different SoC families, to handle this completely inside
libparted, the library would have to know what exactly is the target
system for which it writes a partition table and special-case the
handling for each of them. While one might assume that the partition
table is for an s/390 system when a DASD partition table is
generated, this does not work as easily for the plethora of different
architectures and systems that use DOS MBR partition tables. This
gets even more complicated by the fact that libparted may run on one
platform but modify partition tables for another platform, such as
when operating on disk images for use with emulators or when
operating on hd-media images for different arm platforms (with
different firmware/bootloader requirements) on one autobuild host, so
trying to do runtime detection of the host system would still not cover
all use cases. In the case of creating images from scratch, the problem
can be circumvented by (re-)writing the bootloader at the end of the
process, but when the task is to modify existing images with unknown
content, this workaround is not available.
As a conclusion, I think that the decision whether to clobber the
area between the partition table and the beginning of the first
partition has to be taken by the calling application and not
internally by the library.
Kind Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: