[Buildroot] post-buil script in chrooted

[Buildroot] post-buil script in chrooted

[David Bonnin]

Hello,

Few ask in finalise target:
1- to do root task, i can only use permission: target in each 
packages..........
CAN i use a "root script" in chrooted mode?
ROOTFS_POST_BUILD_SCRIPT is not executed chrooted in the target.

2-
why rootfs targets are generated 2 times?   (in my case: rootfs.tar and 
rootfs.ubifs)
Generate 1 time and then generate tar and UBIFS is quicker.....so why?



"Thanks for this nice buildroot tool."
David.

[Buildroot] post-buil script in chrooted

[Thomas Petazzoni]

Dear David Bonnin,

On Fri, 12 Oct 2012 07:18:24 +0200, David Bonnin wrote:

> Few ask in finalise target:
> 1- to do root task, i can only use permission: target in each 
> packages..........

Not sure I understand this part.

> CAN i use a "root script" in chrooted mode?
> ROOTFS_POST_BUILD_SCRIPT is not executed chrooted in the target.

No because it doesn't make sense. Buildroot is used in many cases for
cross-compilation, so the development machine is x86 or x86_64 and the
target filesystem contain ARM, PowerPC or MIPS binaries. So chrooting
into it is not possible (unless we use Qemu or something like that, but
it's not the idea of Buildroot, we want to do cross-compilation).

> 2-
> why rootfs targets are generated 2 times?   (in my case: rootfs.tar
> and rootfs.ubifs)
> Generate 1 time and then generate tar and UBIFS is quicker.....so why?

Well, this is exactly what Buildroot is doing:

 1) It generates your root filesystem in output/target

 2) At the end of the build it uses the contents of output/target to
    create the different root filesystem images you requested. So if
    you requested a tarball image and an UBIFS image, it is going to
    call tar inside fakeroot to create the tarball image using the
    contents of output/target, and then mkfs.ubifs inside fakeroot to
    create the UBIFS image using the contents of output/target.

Hope this helps,

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

[Buildroot] post-buil script in chrooted

[Thomas De Schampheleire]

Hi David,

On Fri, Oct 12, 2012 at 9:30 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear David Bonnin,
>
> On Fri, 12 Oct 2012 07:18:24 +0200, David Bonnin wrote:
>
>> Few ask in finalise target:
>> 1- to do root task, i can only use permission: target in each
>> packages..........
>
> Not sure I understand this part.
>
>> CAN i use a "root script" in chrooted mode?
>> ROOTFS_POST_BUILD_SCRIPT is not executed chrooted in the target.
>
> No because it doesn't make sense. Buildroot is used in many cases for
> cross-compilation, so the development machine is x86 or x86_64 and the
> target filesystem contain ARM, PowerPC or MIPS binaries. So chrooting
> into it is not possible (unless we use Qemu or something like that, but
> it's not the idea of Buildroot, we want to do cross-compilation).

Maybe you can explain why you think chroot would be necessary. What
are you trying to accomplish?
If you need to add device nodes for example, there are other ways to
do it without needing to be root.

>
>> 2-
>> why rootfs targets are generated 2 times?   (in my case: rootfs.tar
>> and rootfs.ubifs)
>> Generate 1 time and then generate tar and UBIFS is quicker.....so why?
>
> Well, this is exactly what Buildroot is doing:
>
>  1) It generates your root filesystem in output/target
>
>  2) At the end of the build it uses the contents of output/target to
>     create the different root filesystem images you requested. So if
>     you requested a tarball image and an UBIFS image, it is going to
>     call tar inside fakeroot to create the tarball image using the
>     contents of output/target, and then mkfs.ubifs inside fakeroot to
>     create the UBIFS image using the contents of output/target.
>
> Hope this helps,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] post-buil script in chrooted

[Arnout Vandecappelle]

On 12/10/12 10:41, Thomas De Schampheleire wrote:
> On Fri, Oct 12, 2012 at 9:30 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com>  wrote:
>> >  Dear David Bonnin,
>> >
>> >  On Fri, 12 Oct 2012 07:18:24 +0200, David Bonnin wrote:
>> >
>>> >>  Few ask in finalise target:
>>> >>  1- to do root task, i can only use permission: target in each
>>> >>  packages..........
>> >
>> >  Not sure I understand this part.
>> >
>>> >>  CAN i use a "root script" in chrooted mode?
>>> >>  ROOTFS_POST_BUILD_SCRIPT is not executed chrooted in the target.
>> >
>> >  No because it doesn't make sense. Buildroot is used in many cases for
>> >  cross-compilation, so the development machine is x86 or x86_64 and the
>> >  target filesystem contain ARM, PowerPC or MIPS binaries. So chrooting
>> >  into it is not possible (unless we use Qemu or something like that, but
>> >  it's not the idea of Buildroot, we want to do cross-compilation).
> Maybe you can explain why you think chroot would be necessary. What
> are you trying to accomplish?
> If you need to add device nodes for example, there are other ways to
> do it without needing to be root.

  I think he means fakeroot, not chroot...

  I can think of some things for which you may want to execute a fakeroot
script:

- to set xattrs or acls (though I'm not sure if libfakeroot supports them);
- to run some other 'filesystem generation' program, e.g. rsync or nfsd
(we would create a new rootfs type for that, but Joe R. User may have a
hard time doing that).


  But most likely, what David needs is covered by BR2_ROOTFS_DEVICE_TABLE.


  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] post-buil script in chrooted

[David Bonnin]

Hello,

yes, sorry , i mean ,  i was looking for a post-build script for my 
board in a fakeroot environnement.
customize package is deprecated.

in board/me/Myproject/rootfs-adds/root/

i want to cp files of root user.

So i need to use custom skeletonfs or use customize package.

Is there a better way to do it?

thanks.

customize package
Le 12/10/2012 20:52, Arnout Vandecappelle a ?crit :
> On 12/10/12 10:41, Thomas De Schampheleire wrote:
>> On Fri, Oct 12, 2012 at 9:30 AM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com>  wrote:
>>> >  Dear David Bonnin,
>>> >
>>> >  On Fri, 12 Oct 2012 07:18:24 +0200, David Bonnin wrote:
>>> >
>>>> >>  Few ask in finalise target:
>>>> >>  1- to do root task, i can only use permission: target in each
>>>> >>  packages..........
>>> >
>>> >  Not sure I understand this part.
>>> >
>>>> >>  CAN i use a "root script" in chrooted mode?
>>>> >>  ROOTFS_POST_BUILD_SCRIPT is not executed chrooted in the target.
>>> >
>>> >  No because it doesn't make sense. Buildroot is used in many cases 
>>> for
>>> >  cross-compilation, so the development machine is x86 or x86_64 
>>> and the
>>> >  target filesystem contain ARM, PowerPC or MIPS binaries. So 
>>> chrooting
>>> >  into it is not possible (unless we use Qemu or something like 
>>> that, but
>>> >  it's not the idea of Buildroot, we want to do cross-compilation).
>> Maybe you can explain why you think chroot would be necessary. What
>> are you trying to accomplish?
>> If you need to add device nodes for example, there are other ways to
>> do it without needing to be root.
>
>  I think he means fakeroot, not chroot...
>
>  I can think of some things for which you may want to execute a fakeroot
> script:
>
> - to set xattrs or acls (though I'm not sure if libfakeroot supports 
> them);
> - to run some other 'filesystem generation' program, e.g. rsync or nfsd
> (we would create a new rootfs type for that, but Joe R. User may have a
> hard time doing that).
>
>
>  But most likely, what David needs is covered by BR2_ROOTFS_DEVICE_TABLE.
>
>
>  Regards,
>  Arnout

[Buildroot] post-buil script in chrooted

[Arnout Vandecappelle]

On 16/10/12 00:03, David Bonnin wrote:
> Hello,
>
> yes, sorry , i mean , i was looking for a post-build script for my board in a fakeroot environnement.
> customize package is deprecated.
>
> in board/me/Myproject/rootfs-adds/root/
>
> i want to cp files of root user.

  Do you mean, files that are owned by root and are not readable by you?
That won't be possible.

  Or do you mean, files that should be owned by root in the target?  In that
case, you can just copy them in the post-build script - buildroot will make
everything owned by root.


> So i need to use custom skeletonfs or use customize package.

  Neither of these will do anything that the post-build script cannot do.

  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] post-buil script in chrooted

[David Bonnin]

Hello,

Exactly, i want to create few users on the target, and copy files for 
each user, like ftpUser , httpdUser, userMyApp, userMyBackupApp.
I doesn't want to copy files only for root.

My apps(2) on the target doesn't run under root privileveges, and have 
theirs own default files/directory.

Now, i understand BR, i did it statically, with copy files by post-build 
script and permissions target in customize package ( deprecated).
My next step, will be put the default directory/files in root folder, 
and at target board starting create/copy files for my users, in goal to 
remove customize package and my own Skeleton.

Thinking of starting, It seemed implicit that we can execute a personnal 
script in a fakeroot script for modify the target dir before make images.

My project works  now, and looking back BR is a good choice(better than 
TI-SDK, and easy to understand).

Le 17/10/2012 22:32, Arnout Vandecappelle a ?crit :
> On 16/10/12 00:03, David Bonnin wrote:
>> Hello,
>>
>> yes, sorry , i mean , i was looking for a post-build script for my 
>> board in a fakeroot environnement.
>> customize package is deprecated.
>>
>> in board/me/Myproject/rootfs-adds/root/
>>
>> i want to cp files of root user.
>
>  Do you mean, files that are owned by root and are not readable by you?
> That won't be possible.
>
>  Or do you mean, files that should be owned by root in the target?  In 
> that
> case, you can just copy them in the post-build script - buildroot will 
> make
> everything owned by root.
>
>
>> So i need to use custom skeletonfs or use customize package.
>
>  Neither of these will do anything that the post-build script cannot do.
>
>  Regards,
>  Arnout

[Buildroot] post-buil script in chrooted

[Arnout Vandecappelle]

On 26/10/12 22:56, David Bonnin wrote:
> Exactly, i want to create few users on the target, and copy files for each user, like ftpUser , httpdUser, userMyApp,
> userMyBackupApp.
> I doesn't want to copy files only for root.
>
> My apps(2) on the target doesn't run under root privileveges, and have theirs own default files/directory.

  If you want to set file owners and permissions on the target, you should use
the device table (BR2_ROOTFS_DEVICE_TABLE).  Look at
target/generic/device_table.txt for an example.

  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