[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Yann E. MORIN]

Hello All!

Some systems require a specific partition layout to be able to boot.
For example:
  - the RaspberryPi:
    - the first, primary partition, and vfat-formatted, with the bootloader
      files and the kernel
    - the rest of the filesystem hierarchy can be dispatched at will
  - on i.MX:
    - the first, (primary?) partition must be non-FAT (special type?), with
      the bootloader raw-binary inside
    - the rest of the filesystem hierarchy can be whatever
  - on OMAP paltforms:
    - similar to the PI, but the kernel can be on ext2/3/4 (as wel as VFAT?)

For now, buildroot can build a single filesystem image. This is not useable
for these systems. The only possibility as of today is to configure BR to
generate a tarball, and have a custom script that does the required split up
of the different components.

It would be nice to have buildroot smoothly handle these cases.

After a quick talk on IRC with Thomas, here are a few proposals.

0) Keep as-is

Buildroot can not handle all possibilities, we can't even *think* about
all such possibilities. This is the easiest for buildroot, and pushes the
complexity down to the users.

1) Known, simple cases

Provision for a few select, known-simple cases (such as /boot on VFAT with
bootloader and kernel). This can be done rather easily, but is not worth
the effort only if it does not address most cases.

2) Use a descriptive, versatile framework

We could add an option in the menuconfig where the user could specify a
description (in a file) of the required layout, a bit like fs/ubi/ubinize
we have today. This would be in addition to the existing options, not a
replacement.

For example (syntax is just a first draft):
    [defaults]
    part.type=ext
    part.align=1MiB
    fs.size=auto
    fstab=yes
    fstab.mount=boot
    raw.content=file
    
    [bootloader]
    part.type=pri
    part.nb=1
    part.align=4MiB # Mandatory by design
    fs.type=raw
    raw.file=/boot/boot.raw
    fstab=no
    
    [boot]
    fs.dir=/boot
    fs.type=fat
    fstab.mount=no
    fs.label=boot
    part.type=pri
    fat.bits=32
    
    [root]
    fs.type=squashfs
    fs.label=root
    fs.size=64MiB
    fs.dir=/
    squashfs.comp=xz
    
    [home]
    fs.dir=/home
    fs.type=ext4
    fs.size=+1GiB
    fs.label=home
    
    [swap]
    fs.type=raw
    part.size=128MiB
    raw.content=gen
    raw.gen=exec:scripts/generate-swap 128MiB
    fstab.mount=no

Of course, this is far from being exhaustive, but the basics are visible:
  - syntax is .ini-like
  - order is not significant
  - missing fields are guessed or computed (eg. partition type/number),
    or use default values (to be documented)
  - sizes can be automatic ('auto'), enforced ('64MiB'), or free space
    ('+1GiB')
  - filesystem-agnostic options (eg. 'fs.label'), and filesystem-specific
    options (eg. 'fat.bits')
  - content can be generated
  - # starts a comment

So, what are your comments on this?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Steve Calfee]

On Sun, Dec 23, 2012 at 4:00 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Hello All!
>
> Some systems require a specific partition layout to be able to boot.
> For example:
>   - the RaspberryPi:
>     - the first, primary partition, and vfat-formatted, with the bootloader
>       files and the kernel
>     - the rest of the filesystem hierarchy can be dispatched at will
>   - on i.MX:
>     - the first, (primary?) partition must be non-FAT (special type?), with
>       the bootloader raw-binary inside
>     - the rest of the filesystem hierarchy can be whatever
>   - on OMAP paltforms:
>     - similar to the PI, but the kernel can be on ext2/3/4 (as wel as VFAT?)
>
> For now, buildroot can build a single filesystem image. This is not useable
> for these systems. The only possibility as of today is to configure BR to
> generate a tarball, and have a custom script that does the required split up
> of the different components.
>
> It would be nice to have buildroot smoothly handle these cases.
>
> After a quick talk on IRC with Thomas, here are a few proposals.
>
> 0) Keep as-is
>
> Buildroot can not handle all possibilities, we can't even *think* about
> all such possibilities. This is the easiest for buildroot, and pushes the
> complexity down to the users.
>
This is my favorite. There are no known situations that cannot be
handled by buildroot. Quit adding to the makefile. It adds
complexities, and only fixes the one, current users complaint. Keep
mechanism separate from policy. Buildroot should be a simple
consistent way to build a root file system. People who have weird
build/target desires can do that in an external script.

Regards, Steve

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Arnout Vandecappelle]

On 12/25/12 04:52, Steve Calfee wrote:
> On Sun, Dec 23, 2012 at 4:00 PM, Yann E. MORIN<yann.morin.1998@free.fr>  wrote:
>> Hello All!
>>
>> Some systems require a specific partition layout to be able to boot.
>> For example:
>>    - the RaspberryPi:
>>      - the first, primary partition, and vfat-formatted, with the bootloader
>>        files and the kernel
>>      - the rest of the filesystem hierarchy can be dispatched at will
>>    - on i.MX:
>>      - the first, (primary?) partition must be non-FAT (special type?), with
>>        the bootloader raw-binary inside
>>      - the rest of the filesystem hierarchy can be whatever
>>    - on OMAP paltforms:
>>      - similar to the PI, but the kernel can be on ext2/3/4 (as wel as VFAT?)
>>
>> For now, buildroot can build a single filesystem image. This is not useable
>> for these systems. The only possibility as of today is to configure BR to
>> generate a tarball, and have a custom script that does the required split up
>> of the different components.

  That's not really true, is it? Buildroot generates the ext2fs and the 
boot loader and kernel images, you only have to create the partitions and 
the fatfs and pull everything together into a single image.

>>
>> It would be nice to have buildroot smoothly handle these cases.
>>
>> After a quick talk on IRC with Thomas, here are a few proposals.
>>
>> 0) Keep as-is
>>
>> Buildroot can not handle all possibilities, we can't even *think* about
>> all such possibilities. This is the easiest for buildroot, and pushes the
>> complexity down to the users.
>>
> This is my favorite. There are no known situations that cannot be
> handled by buildroot. Quit adding to the makefile. It adds
> complexities, and only fixes the one, current users complaint. Keep
> mechanism separate from policy. Buildroot should be a simple
> consistent way to build a root file system. People who have weird
> build/target desires can do that in an external script.


  +1

  On the other hand, if an external package would exist that implements 
the fully monty (your option 2), then I would have no problem with 
integrating that package and running it automatically post-build.

  Regards,
  Arnout


-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Yann E. MORIN]

Arnout, Steve, All,

On Wednesday 02 January 2013 Arnout Vandecappelle wrote:
> On 12/25/12 04:52, Steve Calfee wrote:
> > On Sun, Dec 23, 2012 at 4:00 PM, Yann E. MORIN<yann.morin.1998@free.fr>  wrote:
[--SNIP--]
> >> For now, buildroot can build a single filesystem image. This is not useable
> >> for these systems. The only possibility as of today is to configure BR to
> >> generate a tarball, and have a custom script that does the required split up
> >> of the different components.
> 
>   That's not really true, is it? Buildroot generates the ext2fs and the 
> boot loader and kernel images, you only have to create the partitions and 
> the fatfs and pull everything together into a single image.

So, you said the same as me: Buildroot (without external tools) can
not generate more than one *filesystem* image (ext2, tar, whatever).

Then, _after_ Buildroot finishes, you can do whatever you want to build
additional images. But that's not Buildroot doing it.

> >> 0) Keep as-is
> >>
> >> Buildroot can not handle all possibilities, we can't even *think* about
> >> all such possibilities. This is the easiest for buildroot, and pushes the
> >> complexity down to the users.
> >>
> > This is my favorite. There are no known situations that cannot be
> > handled by buildroot. Quit adding to the makefile. It adds
> > complexities, and only fixes the one, current users complaint. Keep
> > mechanism separate from policy. Buildroot should be a simple
> > consistent way to build a root file system. People who have weird
> > build/target desires can do that in an external script.
> 
> 
>   +1
> 
>   On the other hand, if an external package would exist that implements 
> the fully monty (your option 2), then I would have no problem with 
> integrating that package and running it automatically post-build.

The problem doing it after Buildroot finishes, is that you loose all the
_PERMISSIONS and _DEVICES variables (unless you also fakeroot the
whole process).

Well, I'm a bit out of time now, so don't hold your breath...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Steve Calfee]

On Wed, Jan 2, 2013 at 3:56 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Arnout, Steve, All,
>
> On Wednesday 02 January 2013 Arnout Vandecappelle wrote:
>> On 12/25/12 04:52, Steve Calfee wrote:
>> > On Sun, Dec 23, 2012 at 4:00 PM, Yann E. MORIN<yann.morin.1998@free.fr>  wrote:
> [--SNIP--]
>> >> For now, buildroot can build a single filesystem image. This is not useable
>> >> for these systems. The only possibility as of today is to configure BR to
>> >> generate a tarball, and have a custom script that does the required split up
>> >> of the different components.
>>
>>   That's not really true, is it? Buildroot generates the ext2fs and the
>> boot loader and kernel images, you only have to create the partitions and
>> the fatfs and pull everything together into a single image.
>
> So, you said the same as me: Buildroot (without external tools) can
> not generate more than one *filesystem* image (ext2, tar, whatever).
>

Hi Yann,

Maybe we are talking about different things. I think there is a config
option in buildroot that allows you to build multiple output
filesystems, I believe I have created ext4 and a tar.gz as outputs. I
think there are also various flash file systems you can create.

They do all contain the identical built rootfs, so for raspberry pi
where for now you want the first boot partition to be fat and the rest
ext4,  buildroot does not build both of them. However the images are
correctly made and can easily be installed by the user manually or via
a script. Building for instance the boot fat file system does not make
much sense, you still need to somehow install the built stuff onto
flash. Doing an install is highly developer specific (and frequently
requires manual insertion of flash etc), and I don't think should be
part of the the BR make system.

Regards, Steve

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Willy Lambert]

2013/1/3 Steve Calfee <stevecalfee@gmail.com>:
> On Wed, Jan 2, 2013 at 3:56 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>> Arnout, Steve, All,
>>
>> On Wednesday 02 January 2013 Arnout Vandecappelle wrote:
>>> On 12/25/12 04:52, Steve Calfee wrote:
>>> > On Sun, Dec 23, 2012 at 4:00 PM, Yann E. MORIN<yann.morin.1998@free.fr>  wrote:
>> [--SNIP--]
>>> >> For now, buildroot can build a single filesystem image. This is not useable
>>> >> for these systems. The only possibility as of today is to configure BR to
>>> >> generate a tarball, and have a custom script that does the required split up
>>> >> of the different components.
>>>
>>>   That's not really true, is it? Buildroot generates the ext2fs and the
>>> boot loader and kernel images, you only have to create the partitions and
>>> the fatfs and pull everything together into a single image.
>>
>> So, you said the same as me: Buildroot (without external tools) can
>> not generate more than one *filesystem* image (ext2, tar, whatever).
>>
>
> Hi Yann,
>
> Maybe we are talking about different things. I think there is a config
> option in buildroot that allows you to build multiple output
> filesystems, I believe I have created ext4 and a tar.gz as outputs. I
> think there are also various flash file systems you can create.
>

I'm curious to know how you do ext4 from BR. I did not found that, and
ASAIK, there is no documentation about outputs (and it's a real pain
for new comers like me)

> They do all contain the identical built rootfs, so for raspberry pi
> where for now you want the first boot partition to be fat and the rest
> ext4,  buildroot does not build both of them. However the images are
> correctly made and can easily be installed by the user manually or via
> a script. Building for instance the boot fat file system does not make
> much sense, you still need to somehow install the built stuff onto
> flash. Doing an install is highly developer specific (and frequently
> requires manual insertion of flash etc), and I don't think should be
> part of the the BR make system.

Maybe a documented exemple with qemu would be helpfull. I am trying
for a month now to create a "partionned" img file. The idea is to use
one of the partition as the rootfs. So I tried different ways to
extract the rootfs.tgz into it but I never succeed in this. I admit
that I'm really not good at playing with "virtual disks", but there is
no entry to find your way. I also believe that it's no more BR stuff,
but hints would be welcome.


>
> Regards, Steve
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Yann E. MORIN]

Steve, All,

On Thursday 03 January 2013 01:32:52 Steve Calfee wrote:
> On Wed, Jan 2, 2013 at 3:56 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > Arnout, Steve, All,
> >
> > On Wednesday 02 January 2013 Arnout Vandecappelle wrote:
> >> On 12/25/12 04:52, Steve Calfee wrote:
> >> > On Sun, Dec 23, 2012 at 4:00 PM, Yann E. MORIN<yann.morin.1998@free.fr>  wrote:
> > [--SNIP--]
> >> >> For now, buildroot can build a single filesystem image. This is not useable
> >> >> for these systems. The only possibility as of today is to configure BR to
> >> >> generate a tarball, and have a custom script that does the required split up
> >> >> of the different components.
> >>
> >>   That's not really true, is it? Buildroot generates the ext2fs and the
> >> boot loader and kernel images, you only have to create the partitions and
> >> the fatfs and pull everything together into a single image.
> >
> > So, you said the same as me: Buildroot (without external tools) can
> > not generate more than one *filesystem* image (ext2, tar, whatever).
> >
> 
> Hi Yann,
> 
> Maybe we are talking about different things. I think there is a config
> option in buildroot that allows you to build multiple output
> filesystems, I believe I have created ext4 and a tar.gz as outputs. I
> think there are also various flash file systems you can create.

Indeed, we're not speaking the same. Yes, Buildroot can generate different
filesystem images with the *same* content.

I am trying to address the case where different parts of the filesystem
hierarchy have to be stored in different filesystems, because they have
to be in different partitions.

For example, on the Raspberry Pi, we have to have:
  - the first partition must be vfat and must contain the few binary
    blobs (bootloader and config for the GPU, the Linux kernel and its
    command line)
  - the rest of the filesystem hierarchy can be whatever (eg. an extN
    filesystem for / on the second partition, and another one for /home
    on yet a third partition)

Buildroot can not handle this case, which is the one I want to address
if it makes sense.

> They do all contain the identical built rootfs, so for raspberry pi
> where for now you want the first boot partition to be fat and the rest
> ext4,  buildroot does not build both of them. However the images are
> correctly made and can easily be installed by the user manually or via
> a script. Building for instance the boot fat file system does not make
> much sense, you still need to somehow install the built stuff onto
> flash. Doing an install is highly developer specific (and frequently
> requires manual insertion of flash etc), and I don't think should be
> part of the the BR make system.

The reason for wanting to include such a feature in Buildroot is to
keep Buildroot ximple to use for the *end-user*, not necessarily for
the Buildroot developpers. A little bit of complexity in the Buildroot
Makefiles and script is OK if it makes for an smoother user experience.

And if you have those files in images/ :
  - images/boot-vfat.img
  - images/root-squahfs.img
  - images/home-ext2.img

Then it is a matter of running (/dev/sdX is the sd-card):
  - dd if=images/boot-vfat.img of=/dev/sdX1
  - dd if=images/root-squashfs.img of=/dev/sdX2
  - dd if=images/home-ext2.img of=/dev/sdX3

This is much simpler from an end-user perspective, than having to write
a script that extracts images/root.tar, splits the extracted stuff, calls
the corresponding genXXXfs. And not forgetting to run that script via
fakeroot to not lose the special files and the permissions...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Jeremy Rosen]

hello all

I have been thinking a bit about that recently for various reasons... AFAIK there are two approches

1) after buildroot has done its work use fakeroot or sudo to untar the tared root filesystem and then recreate
 the various images you need for the different parts of your root fs

2) add a hook to buildroot to call a shell script to build custom filesystems during the filesystem creation phase
 of buildroot... i.e within the fakeroot environement that buildroot uses to create its rootfs

I think that second approch is simpler for the user and is simple to implement in BR (it plugs well in the 
current FS building mechanism) but I don't know if that's the direction BR is going...

the first approch is basically you making a script to run after buildroot, it's a bit complicated since you 
need to be a bit familiar with how fakeroot and/or sudo works but it doesn't depends on any change in buildroot

    Regards

    J?r?my Rosen

fight key loggers : write some perl using vim

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Arnout Vandecappelle]

On 01/03/13 09:40, Yann E. MORIN wrote:
> Steve, All,
>
> On Thursday 03 January 2013 01:32:52 Steve Calfee wrote:
>> >  On Wed, Jan 2, 2013 at 3:56 PM, Yann E. MORIN<yann.morin.1998@free.fr>  wrote:
>>> >  >  Arnout, Steve, All,
>>> >  >
>>> >  >  On Wednesday 02 January 2013 Arnout Vandecappelle wrote:
>>>> >  >>  On 12/25/12 04:52, Steve Calfee wrote:
>>>>> >  >>  >  On Sun, Dec 23, 2012 at 4:00 PM, Yann E. MORIN<yann.morin.1998@free.fr>   wrote:
>>> >  >  [--SNIP--]
>>>>>> >  >>  >>  For now, buildroot can build a single filesystem image. This is not useable
>>>>>> >  >>  >>  for these systems. The only possibility as of today is to configure BR to
>>>>>> >  >>  >>  generate a tarball, and have a custom script that does the required split up
>>>>>> >  >>  >>  of the different components.
>>>> >  >>
>>>> >  >>     That's not really true, is it? Buildroot generates the ext2fs and the
>>>> >  >>  boot loader and kernel images, you only have to create the partitions and
>>>> >  >>  the fatfs and pull everything together into a single image.
>>> >  >
>>> >  >  So, you said the same as me: Buildroot (without external tools) can
>>> >  >  not generate more than one*filesystem*  image (ext2, tar, whatever).
>>> >  >
>> >
>> >  Hi Yann,
>> >
>> >  Maybe we are talking about different things. I think there is a config
>> >  option in buildroot that allows you to build multiple output
>> >  filesystems, I believe I have created ext4 and a tar.gz as outputs. I
>> >  think there are also various flash file systems you can create.
> Indeed, we're not speaking the same. Yes, Buildroot can generate different
> filesystem images with the*same*  content.
>
> I am trying to address the case where different parts of the filesystem
> hierarchy have to be stored in different filesystems, because they have
> to be in different partitions.
>
> For example, on the Raspberry Pi, we have to have:
>    - the first partition must be vfat and must contain the few binary
>      blobs (bootloader and config for the GPU, the Linux kernel and its
>      command line)
>    - the rest of the filesystem hierarchy can be whatever (eg. an extN
>      filesystem for / on the second partition, and another one for /home
>      on yet a third partition)
>
> Buildroot can not handle this case, which is the one I want to address
> if it makes sense.

  I think the usual case is that you have one rootfs image (e.g. ext2) 
and a number of other component images (e.g. bootloader, boot script, 
config for the GPU). Buildroot puts each of these in the images 
directory. In _some_ cases (e.g. RPi), the non-rootfs components should 
be put together into a fat filesystem. It is true that buildroot doesn't 
have support for that, but it is relatively simple to do that in a 
post-build script:

mkfs.vfat /dev/sdb1
sudo mount /dev/sdb1 /mnt
cp output/images/* /mnt
sudo umount /mnt

  There is certainly no need to split up the rootfs itself. (Unless the 
RPi-specific things install stuff in the rootfs while it really should go 
into the images directory, but that's a different issue).

  AFAIK there is no equivalent of genext2fs for FAT, so it would be 
rather difficult to make a boot-vfat.img in buildroot (use sudo? fuse? 
pmount?).


  Regards,
  Arnout
-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Thu, 03 Jan 2013 09:53:40 +0100, Arnout Vandecappelle wrote:

>   AFAIK there is no equivalent of genext2fs for FAT, so it would be 
> rather difficult to make a boot-vfat.img in buildroot (use sudo?
> fuse? pmount?).

You have the mtools, see http://www.gnu.org/software/mtools/.

Also, see the genimage tool from Pengutronix people:
http://www.pengutronix.de/software/genimage/download/.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Yann E. MORIN]

Thomas, All,

On Thursday 03 January 2013 09:57:02 Thomas Petazzoni wrote:
> On Thu, 03 Jan 2013 09:53:40 +0100, Arnout Vandecappelle wrote:
> 
> >   AFAIK there is no equivalent of genext2fs for FAT, so it would be 
> > rather difficult to make a boot-vfat.img in buildroot (use sudo?
> > fuse? pmount?).
> 
> You have the mtools, see http://www.gnu.org/software/mtools/.
> 
> Also, see the genimage tool from Pengutronix people:
> http://www.pengutronix.de/software/genimage/download/.

And genpart, too:
    http://www.pengutronix.de/software/genpart/index_en.html

Whoohoo! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

 Yann> The reason for wanting to include such a feature in Buildroot is to
 Yann> keep Buildroot ximple to use for the *end-user*, not necessarily for
 Yann> the Buildroot developpers. A little bit of complexity in the Buildroot
 Yann> Makefiles and script is OK if it makes for an smoother user experience.

 Yann> And if you have those files in images/ :
 Yann>   - images/boot-vfat.img
 Yann>   - images/root-squahfs.img
 Yann>   - images/home-ext2.img

 Yann> Then it is a matter of running (/dev/sdX is the sd-card):
 Yann>   - dd if=images/boot-vfat.img of=/dev/sdX1
 Yann>   - dd if=images/root-squashfs.img of=/dev/sdX2
 Yann>   - dd if=images/home-ext2.img of=/dev/sdX3

Except this doesn't take care of resizing the filesystems to span the
entire partition.

The linaro people afaik have a linaro-media-create tool to automate
something like this, perhaps we could use it?
-- 
Bye, Peter Korsgaard

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Yann E. MORIN]

Willy, All,

On Thursday 03 January 2013 Willy Lambert wrote:
> 2013/1/3 Steve Calfee <stevecalfee@gmail.com>:
[--SNIP--]
> > Maybe we are talking about different things. I think there is a config
> > option in buildroot that allows you to build multiple output
> > filesystems, I believe I have created ext4 and a tar.gz as outputs. I
> > think there are also various flash file systems you can create.
> 
> I'm curious to know how you do ext4 from BR. I did not found that, and
> ASAIK, there is no documentation about outputs (and it's a real pain
> for new comers like me)

Indeed, not sure about ext4. But it's doable for ext3:
  - first create an ext2 filesystem with genext2fs
  - then add the ext3 feature with something like tune2fs -j

As for ext4, it is probably not possible, as it is really different from
an ext2/3 filesystem.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Bjørn Forsman]

On 3 January 2013 18:33, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Willy, All,
>
> On Thursday 03 January 2013 Willy Lambert wrote:
>> 2013/1/3 Steve Calfee <stevecalfee@gmail.com>:
> [--SNIP--]
>> > Maybe we are talking about different things. I think there is a config
>> > option in buildroot that allows you to build multiple output
>> > filesystems, I believe I have created ext4 and a tar.gz as outputs. I
>> > think there are also various flash file systems you can create.
>>
>> I'm curious to know how you do ext4 from BR. I did not found that, and
>> ASAIK, there is no documentation about outputs (and it's a real pain
>> for new comers like me)
>
> Indeed, not sure about ext4. But it's doable for ext3:
>   - first create an ext2 filesystem with genext2fs
>   - then add the ext3 feature with something like tune2fs -j
>
> As for ext4, it is probably not possible, as it is really different from
> an ext2/3 filesystem.

You can also convert ext3 to ext4:

https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4

Best regards,
Bj?rn Forsman

[Buildroot] [RFC] How to handle targets that need more than one file system to boot?

[Yann E. MORIN]

Bj?rn, All,

On Thursday 03 January 2013 Bj?rn Forsman wrote:
> On 3 January 2013 18:33, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
[--SNIP--]
> > As for ext4, it is probably not possible, as it is really different from
> > an ext2/3 filesystem.
> 
> You can also convert ext3 to ext4:
> 
> https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4

Ah, good to know! Thank you! :-)
So, we now know how to generate filesystems for all the ext familly. Yeah!

Regarfds,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'