'blkid', '-o', 'udev', '-p', '-c', '/dev/null', '/dev/sdb2' returned a non-zero value: 2

On Sat, 05 Mar 2011 02:36:08 -0000, Matt Waddel <email address hidden> wrote:
> linaro_media_create.cmd_runner.SubcommandNonZeroReturnValue: Sub process "['sudo', 'blkid', '-o', 'udev', '-p', '-c', '/dev/null', '/dev/sdb2']" returned a non-zero value: 2

Hi Matt,

What do you get if you run the command by hand?

  sudo blkid -o udev -p -c /dev/null /dev/sdb2

(with the sd card plugged in)

Could you also attach the full transcript of the failing run?

Thanks,

James

I see you used the "--no-rootfs" switch, so maybe this failed because
the sdcard didn't have a root partition?

Also, I wonder if it makes sense to call l-m-c with --no-rootfs but
without --no-part; if you plan to reuse an existing partition l-m-c
should probably not touch your partition table.

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.

It does only happen with the --no-rootfs switch. Adding the
--no-part switch doesn't help.

The --no-bootfs option works correctly.

Hey Matt,

Could you try adding an os.sleep(30) before rootfs_uuid = get_uuid(root_partition) in linaro-media-create and see whether that helps?

Thanks!

(Try running the blkid command from another terminal while it's sleeping if you like)

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
 - # 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)

Thanks,

James

I can reproduce this issue, but for me this does NOT return successfully:
sudo -E blkid -o udev -p -c /dev/null /dev/sdb2

it returns error code 2, which I guess means that the UUID can't be found.

I'm wondering: Matt, if you used a MMC which had a rootfs at offset +100 (for instance), and kept rewriting the part table + bootfs with the above command, things would just work, but as soon as you upgrade to a l-m-c with new part offset, it will create the part table pointing at a rootfs at +4000 (for instance), and will overwrite your rootfs. So I think what might help is doing a full run without --no-rootfs, then doing the next runs with --no-rootfs if you like.

I'm testing the above to see if it works.

I tested by doing a full run, and then doing a run with --no-rootfs, and both passed, so this seems like a sensible explanation.

I guess the issue is that --no-rootfs doesn't guard against partitioning; we could either go the route of adding a --no-partitioning flag, or the other way around kill --no-rootfs support.

There already is a "--no-part" option in linaro-media-create.

This does work when I do a full run with the new l-m-c, then
run again with --no-part + --no-rootfs. So I'll mark this bug
as invalid.

On Thu, 10 Mar 2011 01:23:32 -0000, Matt Waddel <email address hidden> wrote:
> There already is a "--no-part" option in linaro-media-create.
>
> This does work when I do a full run with the new l-m-c, then
> run again with --no-part + --no-rootfs. So I'll mark this bug
> as invalid.

Thanks for reporting and testing Matt.

This situation isn't ideal, but adding the smarts to detect the
situation would be a lot of work, and I don't think it is worth it at
this time.

Thanks,

James