[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#751704: partman-base 173: partman overwrites parts of u-boot



Source: partman-base
Version: 173
Severity: important

Upon testing a locally built debian-installer based on linux
3.15-1 (from experimental) on an Allwinner sunXi-based armhf
system, I have found that the system does not boot anymore after
partman has written a new partition table to the SD card from
which the system loads u-boot.

Kernel 3.15-1 is the first kernel in Debian that contains an
MMC/SD driver for this platform, i.e. with older versions
partitions could only be created on an attached SATA disk but not
on the SD card, so this problem has not shown up earlier.

In my first attempt, the partition table has been created by the
"guided partitioning" option in d-i, which has created the
following layout:

Disk /dev/sdd: 15 GB, 15718510080 bytes
255 heads, 63 sectors/track, 1911 cylinders, total 30700215 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System 
/dev/sdd1   *        2048      499711      257008   83  Linux
Warning: Partition 1 does not end on cylinder boundary.                   
/dev/sdd2          499712    29306879    14402272   83  Linux
Warning: Partition 2 does not end on cylinder boundary.                   
/dev/sdd3        29308926    30701567      698827    5  Extended
Warning: Partition 3 does not end on cylinder boundary.                   
/dev/sdd5        29308928    30701567      698827   82  Linux swap
Warning: Partition 5 does not end on cylinder boundary.                   

The layout itself appears ok as the first partition starts at
sector 2048, i.e. at 1MB offset, but comparing the state of the
first MB of data on the device before and after partman has
written the partition table shows that not only the partition
table has been written, but also the area from offset 0x2000 up
to 0x25ff has been zeroed out.  On all Allwinner sunXi-based
systems this area contains the u-boot SPL, without which the
system cannot boot anymore.

A second attempt with manual partitioning showed the same
behaviour, i.e. it appears to be a general partman problem and
not specific to partman-auto.

Partman should only write the partition table but should not
touch the area between the partition table and the beginning
of the first partition as this area is used by bootloaders.

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: