On Wed, 09 Mar 2011 17:47:13 -0000, Matt Waddel <email address hidden> wrote:
> Running this command stand alone does not fail:
> sudo blkid -o udev -p -c /dev/null /dev/sdb2
>
> I've uploaded a failing run from revision 288. Revision 287 does
> not fail. It seems that something in the boot partition alignment
> changes caused this problem.
There's nothing immediately obviously wrong there, but sfdisk command
changes are certainly suspicious.
Assuming this is vexpress-specific then this hunk looks suspicious
- # This will create a partition of the given type, containing 9
- # cylinders (74027520 bytes, ~70 MiB), followed by a Linux-type
- # partition containing the rest of the free space.
- return ',9,%s,*\n,,,-' % partition_type
+ # align on sector 63 for compatibility with broken versions of x-loader
+ # unless align_boot_part is set
+ boot_align = 63
+ if should_align_boot_part:
+ boot_align = PART_ALIGN_S
+
+ # can only start on sector 1 (sector 0 is MBR / partition table)
+ boot_start, boot_end, boot_len = align_partition(
+ 1, BOOT_MIN_SIZE_S, boot_align, PART_ALIGN_S)
+ # apparently OMAP3 ROMs require the vfat length to be an even number
+ # of sectors (multiple of 1 KiB); decrease the length if it's odd,
+ # there should still be enough room
+ boot_len = boot_len - boot_len % 2
+ boot_end = boot_start + boot_len - 1
+ # we ignore _root_end / _root_len and return a sfdisk command to
+ # instruct the use of all remaining space; XXX if we had some root size
+ # config, we could do something more sensible
+ root_start, _root_end, _root_len = align_partition(
+ boot_end + 1, ROOT_MIN_SIZE_S, PART_ALIGN_S, PART_ALIGN_S)
+
+ return '%s,%s,%s,*\n%s,,,-' % (
+ boot_start, boot_len, partition_type, root_start)
On Wed, 09 Mar 2011 17:47:13 -0000, Matt Waddel <email address hidden> wrote:
> Running this command stand alone does not fail:
> sudo blkid -o udev -p -c /dev/null /dev/sdb2
>
> I've uploaded a failing run from revision 288. Revision 287 does
> not fail. It seems that something in the boot partition alignment
> changes caused this problem.
Thanks for bisecting.
http:// bazaar. launchpad. net/~linaro- maintainers/ linaro- image-tools/ trunk/revision/ 288
There's nothing immediately obviously wrong there, but sfdisk command
changes are certainly suspicious.
Assuming this is vexpress-specific then this hunk looks suspicious
- # This will create a partition of the given type, containing 9 align_boot_ part: %s,*\n% s,,,-' % (
- # cylinders (74027520 bytes, ~70 MiB), followed by a Linux-type
- # partition containing the rest of the free space.
- return ',9,%s,*\n,,,-' % partition_type
+ # align on sector 63 for compatibility with broken versions of x-loader
+ # unless align_boot_part is set
+ boot_align = 63
+ if should_
+ boot_align = PART_ALIGN_S
+
+ # can only start on sector 1 (sector 0 is MBR / partition table)
+ boot_start, boot_end, boot_len = align_partition(
+ 1, BOOT_MIN_SIZE_S, boot_align, PART_ALIGN_S)
+ # apparently OMAP3 ROMs require the vfat length to be an even number
+ # of sectors (multiple of 1 KiB); decrease the length if it's odd,
+ # there should still be enough room
+ boot_len = boot_len - boot_len % 2
+ boot_end = boot_start + boot_len - 1
+ # we ignore _root_end / _root_len and return a sfdisk command to
+ # instruct the use of all remaining space; XXX if we had some root size
+ # config, we could do something more sensible
+ root_start, _root_end, _root_len = align_partition(
+ boot_end + 1, ROOT_MIN_SIZE_S, PART_ALIGN_S, PART_ALIGN_S)
+
+ return '%s,%s,
+ boot_start, boot_len, partition_type, root_start)
Thanks,
James