has anyone actually tested sdcard_image.bbclass?

has anyone actually tested sdcard_image.bbclass?

[Robert P. J. Day]

  testing SD card image creation under meta-ti for the first time and
the first issue seems to be that this is necessary:

diff --git a/classes/sdcard_image.bbclass b/classes/sdcard_image.bbclass
index f9b8d46..45374e2 100644
--- a/classes/sdcard_image.bbclass
+++ b/classes/sdcard_image.bbclass
@@ -1,4 +1,4 @@
-inherit image
+inherit image_types

 # Add the fstypes we need
 IMAGE_FSTYPES_append = " tar.bz2 sdimg"

  also, even after i make that change, i get:

===== start =====
... big snip ...
| /etc/fstab entries need to be created with the user flag for the
loop devices like:
| /dev/loop2
/home/rpjday/oe/builds/ti/bone/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/tmp-mnt-boot
vfat user 0 0
| ERROR: Function failed: do_rootfs (see
/home/rpjday/oe/builds/ti/bone/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.1938
for further information)
ERROR: Task 7
(/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/images/core-image-minimal.bb,
do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1922 tasks of which 1901 didn't need to
be rerun and 1 failed.
No currently running tasks (1922 of 1923)

Summary: 1 task failed:

/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/images/core-image-minimal.bb,
do_rootfs
===== end =====

but i'm willing to believe that's something i did stupidly so i'll
look at it further.

  thoughts?  all i did for a test was add this to local.conf:

IMAGE_CLASSES += "sdcard_image"

and run:

$ bitbake core-image-minimal

the previous build worked fine without trying to create the SD card
image.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: has anyone actually tested sdcard_image.bbclass?

[Gary Thomas]

On 2013-01-10 07:48, Robert P. J. Day wrote:
>
>    testing SD card image creation under meta-ti for the first time and
> the first issue seems to be that this is necessary:
>
> diff --git a/classes/sdcard_image.bbclass b/classes/sdcard_image.bbclass
> index f9b8d46..45374e2 100644
> --- a/classes/sdcard_image.bbclass
> +++ b/classes/sdcard_image.bbclass
> @@ -1,4 +1,4 @@
> -inherit image
> +inherit image_types
>
>   # Add the fstypes we need
>   IMAGE_FSTYPES_append = " tar.bz2 sdimg"
>
>    also, even after i make that change, i get:
>
> ===== start =====
> ... big snip ...
> | /etc/fstab entries need to be created with the user flag for the
> loop devices like:
> | /dev/loop2
> /home/rpjday/oe/builds/ti/bone/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/tmp-mnt-boot
> vfat user 0 0
> | ERROR: Function failed: do_rootfs (see
> /home/rpjday/oe/builds/ti/bone/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.1938
> for further information)
> ERROR: Task 7
> (/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/images/core-image-minimal.bb,
> do_rootfs) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 1922 tasks of which 1901 didn't need to
> be rerun and 1 failed.
> No currently running tasks (1922 of 1923)
>
> Summary: 1 task failed:
>
> /home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/images/core-image-minimal.bb,
> do_rootfs
> ===== end =====
>
> but i'm willing to believe that's something i did stupidly so i'll
> look at it further.
>
>    thoughts?  all i did for a test was add this to local.conf:
>
> IMAGE_CLASSES += "sdcard_image"
>
> and run:
>
> $ bitbake core-image-minimal
>
> the previous build worked fine without trying to create the SD card
> image.

Did you look at the log to see why it failed?  Last time I tried this,
it required horrible set up to make it work (something I never wanted
to take the time to accomplish).

Interestingly enough, the meta-fsl-arm layer also has an SD card image
layout (class) which works perfectly and needs no magic to make it work.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: has anyone actually tested sdcard_image.bbclass?

[Robert P. J. Day]

On Thu, 10 Jan 2013, Gary Thomas wrote:

> On 2013-01-10 07:48, Robert P. J. Day wrote:
> >
> >    testing SD card image creation under meta-ti for the first time and
> > the first issue seems to be that this is necessary:
> >
> > diff --git a/classes/sdcard_image.bbclass b/classes/sdcard_image.bbclass
> > index f9b8d46..45374e2 100644
> > --- a/classes/sdcard_image.bbclass
> > +++ b/classes/sdcard_image.bbclass
> > @@ -1,4 +1,4 @@
> > -inherit image
> > +inherit image_types
> >
> >   # Add the fstypes we need
> >   IMAGE_FSTYPES_append = " tar.bz2 sdimg"
> >
> >    also, even after i make that change, i get:
> >
> > ===== start =====
> > ... big snip ...
> > | /etc/fstab entries need to be created with the user flag for the
> > loop devices like:
> > | /dev/loop2
> > /home/rpjday/oe/builds/ti/bone/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/tmp-mnt-boot
> > vfat user 0 0
> > | ERROR: Function failed: do_rootfs (see
> > /home/rpjday/oe/builds/ti/bone/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.1938
> > for further information)
> > ERROR: Task 7
> > (/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/images/core-image-minimal.bb,
> > do_rootfs) failed with exit code '1'
> > NOTE: Tasks Summary: Attempted 1922 tasks of which 1901 didn't need to
> > be rerun and 1 failed.
> > No currently running tasks (1922 of 1923)
> >
> > Summary: 1 task failed:
> >
> > /home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/images/core-image-minimal.bb,
> > do_rootfs
> > ===== end =====
> >
> > but i'm willing to believe that's something i did stupidly so i'll
> > look at it further.
> >
> >    thoughts?  all i did for a test was add this to local.conf:
> >
> > IMAGE_CLASSES += "sdcard_image"
> >
> > and run:
> >
> > $ bitbake core-image-minimal
> >
> > the previous build worked fine without trying to create the SD card
> > image.
>
> Did you look at the log to see why it failed?  Last time I tried this,
> it required horrible set up to make it work (something I never wanted
> to take the time to accomplish).
>
> Interestingly enough, the meta-fsl-arm layer also has an SD card image
> layout (class) which works perfectly and needs no magic to make it work.

  i'm going to be testing all of the above again shortly from scratch
to make sure it wasn't something silly i did.  but if someone wants to
see if they can reproduce it, all i did was a standard configure using
meta-ti layer for a beaglebone and i built a core-image-minimal.

  after that worked, i added the following line to local.conf:

IMAGE_CLASSES += "sdcard_image"

and that caused the very same build to fail.  can anyone else confirm
that?  i'll be digging into this as soon as i get back from coffee.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: has anyone actually tested sdcard_image.bbclass?

[Trevor Woerner]

[-- Attachment #1: Type: text/plain, Size: 2752 bytes --]

On Thu, Jan 10, 2013 at 10:11 AM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:
>> > ===== start =====
>> > ... big snip ...
>> > | /etc/fstab entries need to be created with the user flag for the
>> > loop devices like:
>> > | /dev/loop2
>> >
/home/rpjday/oe/builds/ti/bone/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/tmp-mnt-boot
>> > vfat user 0 0

>   i'm going to be testing all of the above again shortly from scratch
> to make sure it wasn't something silly i did.  but if someone wants to
> see if they can reproduce it, all i did was a standard configure using
> meta-ti layer for a beaglebone and i built a core-image-minimal.


I followed the same procedure and met the same end.

I was able to get the build to complete without error (NOTE: i don't own
this
device, so i can't be sure it all worked, but the build completed) with the
help of the following:

1) edit /etc/fstab

The build is telling you to update your /etc/fstab (which you have to do as
root, and which is very *this*-build-specific. In your case it wants you to
add the following line:

    /dev/loop2
/home/rpjday/oe/builds/ti/bone/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/tmp-mnt-boot
vfat user 0 0

2) path fixup

I'm building using openSuSE 12.2 so all the various hard-coded paths in the
script are wrong. Instead of "/sbin/fsdisk" mine is found at
"/usr/sbin/fsdisk".
I had to go through the entire script and perform that fixup for all such
paths.

3) genext2fs code hack

Within 5 yards of finish line the 'genext2fs' step fails with the following
error msg:

  genext2fs: set_file_size: ftruncate: Invalid argument

I googled and googled and couldn't find an answer. I found other people
with the
same problem, but others only said "works for me". In the end I actually
went
into the code of genext2fs and commented out the body of the
"set_file_size()"
function! I then replaced the one being called by the script with my new
one and
the build could then complete without error.

4) use the "root"

As I mentioned before, this script's use of losetup definitely requires root
permissions on my system. At first I made losetup "+s". Then sfdisk needed
more permissions, then dd, then... In the end I just simply ran bitbake as
root.
Of course, by default, bitbake complains and won't run as root, so I had to
"touch conf/sanity.conf" to force it.

After all these hacks (and maybe more?) I was able to get the build to
complete without
error. Whether or not the results are useful I'm not sure. In the end I
ended up with the
following artifact:


tmp/deploy/images/core-image-minimal-beagleboard-20130110215340-2013.01.10.img.gz

[-- Attachment #2: Type: text/html, Size: 3357 bytes --]

Re: has anyone actually tested sdcard_image.bbclass?

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3259 bytes --]

On Thu, 10 Jan 2013, Trevor Woerner wrote:

> On Thu, Jan 10, 2013 at 10:11 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >> > ===== start =====
> >> > ... big snip ...
> >> > | /etc/fstab entries need to be created with the user flag for the
> >> > loop devices like:
> >> > | /dev/loop2
> >> >/home/rpjday/oe/builds/ti/bone/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.
> 0-r0/tmp-mnt-boot
> >> > vfat user 0 0
>
> >   i'm going to be testing all of the above again shortly from scratch
> > to make sure it wasn't something silly i did.  but if someone wants to
> > see if they can reproduce it, all i did was a standard configure using
> > meta-ti layer for a beaglebone and i built a core-image-minimal.
>
>
> I followed the same procedure and met the same end.

... snip ...

  just to recap what seems to be an obvious bug in meta-ti, all i want
to do is add the image class of "sdcard_image" to create an SD card
image of core-image-minimal for a beaglebone.

  from a fresh configuration and adjusting to select a machine of
beaglebone, i can do all the fetching to start things off:

$ bitbake -c fetchall core-image-minimal

and i can use bitbake-env to examine the relevant variables:

$ bitbake-env -r core-image-minimal IMAGE_CLASSES IMAGE_FSTYPES
Parsing recipes..WARNING: No recipes available for:

/home/rpjday/oe/dist/layers/meta-ti/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
done.
IMAGE_CLASSES="image_types"
IMAGE_FSTYPES=" tar.bz2 "
$

  so far, so good.  now, AIUI, to add the SD card image type to the
generated artifacts, i need only add this line to my local.conf:

IMAGE_CLASSES += "sdcard_image"

but after i do that:

$ bitbake-env -r core-image-minimal IMAGE_CLASSES IMAGE_FSTYPES
Parsing recipes..ERROR: Error executing a python function in <code>:
NameError: global name 'imagetypes_getdepends' is not defined
... huge snip here ...

  using the raspberry pi layer as a model, i made the following change
in meta-ti's sdcard_image.bbclass file:

diff --git a/classes/sdcard_image.bbclass
b/classes/sdcard_image.bbclass
index f9b8d46..45374e2 100644
--- a/classes/sdcard_image.bbclass
+++ b/classes/sdcard_image.bbclass
@@ -1,4 +1,4 @@
-inherit image
+inherit image_types

 # Add the fstypes we need
 IMAGE_FSTYPES_append = " tar.bz2 sdimg"

  and now, at least bitbake-env works:

$ bitbake-env -r core-image-minimal IMAGE_CLASSES IMAGE_FSTYPES
Parsing recipes..WARNING: No recipes available for:

/home/rpjday/oe/dist/layers/meta-ti/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
done.
IMAGE_CLASSES=" sdcard_image"
IMAGE_FSTYPES=" tar.bz2  tar.bz2 sdimg"
$

  so, is it fair to say that that's a bug in sdcard_image.bbclass?
or is there something else that needs to be adjusted?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: has anyone actually tested sdcard_image.bbclass?

[Trevor Woerner]

On Fri, Jan 11, 2013 at 7:02 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>   so, is it fair to say that that's a bug in sdcard_image.bbclass?
> or is there something else that needs to be adjusted?


Yes, I would say there most certainly is a bug since, as you point
out, bitbake can't even parse the recipes correctly without throwing
an error (which is exactly the error I saw too).

Re: has anyone actually tested sdcard_image.bbclass?

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

On Fri, Jan 11, 2013 at 5:02 AM, Robert P. J. Day <rpjday@crashcourse.ca>wrote:

> IMAGE_CLASSES += "sdcard_image"
>
> but after i do that:
>
> $ bitbake-env -r core-image-minimal IMAGE_CLASSES IMAGE_FSTYPES
> Parsing recipes..ERROR: Error executing a python function in <code>:
> NameError: global name 'imagetypes_getdepends' is not defined
> ... huge snip here ...
>

image.bbclass defines the default IMAGE_CLASSES using ?=. Which means if
your distro doesn't define its own default value, you'll end up with
IMAGE_CLASSES only containing sdcard_image, not both image_types and
sdcard_image, and clearly both are required.
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 1055 bytes --]

Re: has anyone actually tested sdcard_image.bbclass?

[Robert P. J. Day]

On Fri, 11 Jan 2013, Chris Larson wrote:

>
> On Fri, Jan 11, 2013 at 5:02 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>       IMAGE_CLASSES += "sdcard_image"
>
>       but after i do that:
>
>       $ bitbake-env -r core-image-minimal IMAGE_CLASSES IMAGE_FSTYPES
>       Parsing recipes..ERROR: Error executing a python function in <code>:
>       NameError: global name 'imagetypes_getdepends' is not defined
>       ... huge snip here ...
>
> image.bbclass defines the default IMAGE_CLASSES using ?=. Which
> means if your distro doesn't define its own default value, you'll
> end up with IMAGE_CLASSES only containing sdcard_image, not both
> image_types and sdcard_image, and clearly both are required.

  i don't see that happening with the raspberry pi layer.  if i
configure for that layer sitting on top of oe-core, and just

  $ bitbake rpi-basic-image

this setting from the rpi layer:

conf/machine/include/rpi-default-settings.inc:IMAGE_CLASSES += "sdcard_image-rpi"

produces this with bitbake-env:

$ bitbake-env -r rpi-basic-image IMAGE_CLASSES
Parsing recipes..done.
IMAGE_CLASSES=" sdcard_image-rpi"
$

  the value of IMAGE_CLASSES clearly *doesn't* include "image_types",
but the build works fine and i get the resulting SD card image in
tmp/deploy/images:

rpi-basic-image-raspberrypi-20130112091402.rootfs.rpi-sdimg

  i'm sure i'm misreading what you wrote, but you can see from the
output of bitbake-env that there is no "image_types" in IMAGE_CLASSES
and the build works just fine.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: has anyone actually tested sdcard_image.bbclass?

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

On Sat, Jan 12, 2013 at 3:20 AM, Robert P. J. Day <rpjday@crashcourse.ca>wrote:

> On Fri, 11 Jan 2013, Chris Larson wrote:
>
> >
> > On Fri, Jan 11, 2013 at 5:02 AM, Robert P. J. Day <rpjday@crashcourse.ca>
> wrote:
> >       IMAGE_CLASSES += "sdcard_image"
> >
> >       but after i do that:
> >
> >       $ bitbake-env -r core-image-minimal IMAGE_CLASSES IMAGE_FSTYPES
> >       Parsing recipes..ERROR: Error executing a python function in
> <code>:
> >       NameError: global name 'imagetypes_getdepends' is not defined
> >       ... huge snip here ...
> >
> > image.bbclass defines the default IMAGE_CLASSES using ?=. Which
> > means if your distro doesn't define its own default value, you'll
> > end up with IMAGE_CLASSES only containing sdcard_image, not both
> > image_types and sdcard_image, and clearly both are required.
>
>   i don't see that happening with the raspberry pi layer.  if i
> configure for that layer sitting on top of oe-core, and just
>
>   $ bitbake rpi-basic-image
>
> this setting from the rpi layer:
>
> conf/machine/include/rpi-default-settings.inc:IMAGE_CLASSES +=
> "sdcard_image-rpi"
>
> produces this with bitbake-env:
>
> $ bitbake-env -r rpi-basic-image IMAGE_CLASSES
> Parsing recipes..done.
> IMAGE_CLASSES=" sdcard_image-rpi"
> $
>
>   the value of IMAGE_CLASSES clearly *doesn't* include "image_types",
> but the build works fine and i get the resulting SD card image in
> tmp/deploy/images:
>
> rpi-basic-image-raspberrypi-20130112091402.rootfs.rpi-sdimg
>
>   i'm sure i'm misreading what you wrote, but you can see from the
> output of bitbake-env that there is no "image_types" in IMAGE_CLASSES
> and the build works just fine.


Then that class likely does an 'inherit image_types' itself, thereby making
the implicit dependency explicit.
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 2510 bytes --]

Re: has anyone actually tested sdcard_image.bbclass?

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2718 bytes --]

On Sat, 12 Jan 2013, Chris Larson wrote:

>
> On Sat, Jan 12, 2013 at 3:20 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>       On Fri, 11 Jan 2013, Chris Larson wrote:
>
>       >
>       > On Fri, Jan 11, 2013 at 5:02 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>       >       IMAGE_CLASSES += "sdcard_image"
>       >
>       >       but after i do that:
>       >
>       >       $ bitbake-env -r core-image-minimal IMAGE_CLASSES IMAGE_FSTYPES
>       >       Parsing recipes..ERROR: Error executing a python function in <code>:
>       >       NameError: global name 'imagetypes_getdepends' is not defined
>       >       ... huge snip here ...
>       >
>       > image.bbclass defines the default IMAGE_CLASSES using ?=. Which
>       > means if your distro doesn't define its own default value, you'll
>       > end up with IMAGE_CLASSES only containing sdcard_image, not both
>       > image_types and sdcard_image, and clearly both are required.
>
>   i don't see that happening with the raspberry pi layer.  if i
> configure for that layer sitting on top of oe-core, and just
>
>   $ bitbake rpi-basic-image
>
> this setting from the rpi layer:
>
> conf/machine/include/rpi-default-settings.inc:IMAGE_CLASSES += "sdcard_image-rpi"
>
> produces this with bitbake-env:
>
> $ bitbake-env -r rpi-basic-image IMAGE_CLASSES
> Parsing recipes..done.
> IMAGE_CLASSES=" sdcard_image-rpi"
> $
>
>   the value of IMAGE_CLASSES clearly *doesn't* include "image_types",
> but the build works fine and i get the resulting SD card image in
> tmp/deploy/images:
>
> rpi-basic-image-raspberrypi-20130112091402.rootfs.rpi-sdimg
>
>   i'm sure i'm misreading what you wrote, but you can see from the
> output of bitbake-env that there is no "image_types" in IMAGE_CLASSES
> and the build works just fine.
>
> Then that class likely does an 'inherit image_types' itself, thereby
> making the implicit dependency explicit.

  so which is the *preferred* way to advise developers how to write a
new class like that?  i realize both ways work, but if one is going to
document this, what's the *recommended* way that would go into the OE
style guide?  and, yes, there should be a recommended way. :-)

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: has anyone actually tested sdcard_image.bbclass?

[Trevor Woerner]

On Thu, Jan 10, 2013 at 10:07 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> Interestingly enough, the meta-fsl-arm layer also has an SD card image
> layout (class) which works perfectly and needs no magic to make it work.


Very interesting! Thanks so much for posting this information.

The meta-ti method uses a combination of losetup, sfdisk, dd, and
others to create its images (which is what I have traditionally used
to create my own images). losetup (for sure and probably sfdisk too)
requires privilege in order to work (which probably accounts for all
the messy setup).

The meta-fsl-arm method, on the other hand, uses GNU parted which
doesn't appear to require privilege and does away with losetup and
sfdisk.

I'm glad you posted this information as I'll now be converting my
scripts to use parted as well.

Re: has anyone actually tested sdcard_image.bbclass?

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]

On Thu, Jan 10, 2013 at 3:50 PM, Trevor Woerner <twoerner@gmail.com> wrote:

> On Thu, Jan 10, 2013 at 10:07 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> > Interestingly enough, the meta-fsl-arm layer also has an SD card image
> > layout (class) which works perfectly and needs no magic to make it work.
>
>
> Very interesting! Thanks so much for posting this information.
>
> The meta-ti method uses a combination of losetup, sfdisk, dd, and
> others to create its images (which is what I have traditionally used
> to create my own images). losetup (for sure and probably sfdisk too)
> requires privilege in order to work (which probably accounts for all
> the messy setup).
>
> The meta-fsl-arm method, on the other hand, uses GNU parted which
> doesn't appear to require privilege and does away with losetup and
> sfdisk.
>
> I'm glad you posted this information as I'll now be converting my
> scripts to use parted as well.


We started looking at a parted based pandaboard sdcard image creation setup
for Mentor, but haven't completed it, so we'd be interested in seeing what
people do in this regard. Obviously it'll all probably go away in favor of
the image creation/deployment rework in the long term, but we need
something in the short term.

One issue we ran into is, my panda seems to require a particular alignment
(e.g. first partition at 63*255) based on geometry, but parted's alignment
options are rather limited. Either one can use pyparted (but that's GPL,
and the metadata is MIT), or use sfdisk (which has its own issues, but lets
you specify geometry), or manually calculate the alignment (theoretical).
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 2284 bytes --]