Bug#751704: sunxi MMC boot SPL vs. GPT partition (Re: Bug#751704: partman-base 173: partman overwrites parts of u-boot)

2014-06-18 Thread Ian Campbell
(seems like I didn't actually CC linux-sunxi when I said I would, oh well, I may post a summary to that list later) On Tue, 2014-06-17 at 19:44 +0200, Karsten Merker wrote: Unfortunately the problematic part in this case is the SPL which is the only part of u-boot that cannot be relocated

Bug#751704: sunxi MMC boot SPL vs. GPT partition (Re: Bug#751704: partman-base 173: partman overwrites parts of u-boot)

2014-06-18 Thread Ian Campbell
On Wed, 2014-06-18 at 08:43 +0100, Ian Campbell wrote: I suppose it is possible that something somewhere is wanting to zero the GPT even in msdos mode (as you say below, perhaps to wipe any remains of a GPT). I think it is parted doing this in ped_disk_clobber which is called from various bits

Bug#751704: sunxi MMC boot SPL vs. GPT partition (Re: Bug#751704: partman-base 173: partman overwrites parts of u-boot)

2014-06-17 Thread Ian Campbell
CCing the linux-sunxi group. On Mon, 2014-06-16 at 17:58 -0400, Lennart Sorensen wrote: On Sun, Jun 15, 2014 at 08:02:03PM +0200, Karsten Merker wrote: Source: partman-base Version: 173 Severity: important Upon testing a locally built debian-installer based on linux 3.15-1 (from

Bug#751704: sunxi MMC boot SPL vs. GPT partition (Re: Bug#751704: partman-base 173: partman overwrites parts of u-boot)

2014-06-17 Thread Lennart Sorensen
On Tue, Jun 17, 2014 at 10:20:38AM +0100, Ian Campbell wrote: CCing the linux-sunxi group. It sure would be nice if CPU makers would stop putting their boot code where the GPT goes. Do none of them EVER think their device will want to use a disk bigger than 2TB? Hrm, that is rather

Bug#751704: sunxi MMC boot SPL vs. GPT partition (Re: Bug#751704: partman-base 173: partman overwrites parts of u-boot)

2014-06-17 Thread Lennart Sorensen
On Tue, Jun 17, 2014 at 07:44:36PM +0200, Karsten Merker wrote: Unfortunately the problematic part in this case is the SPL which is the only part of u-boot that cannot be relocated because its sector address is hardcoded in the SOC's BROM. I see two possible approaches to solve the conflict