which templates are used?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I want to design my own templates for directories and files (fstab etc). Where do I set this? I thought it's in ./fs/skeleton. But obviously not for every file..
Why this?
- --
- --
cheers
- -micha-
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNo2BGAAoJEEMkp/gkis19YJQIAMzTFOuekd83F+4HFtaGGQSU ufTyysVRTlOlptkMqC/u4K40N2bWKmz9Z4Fx3GnQ36g6FzVu1OUoFyWdxQ3pEUm5 Jzn/Hy+iRuYaILiqS+iUbawb0mRrwwFUD7u7oa5KFyLQiRzeDwl8Yx63DJRuaKkI vlHFsSX1w283ZBtW0WPZ6X2zhwPV+CaSww5Qqem1JzmftjN9gMY8KF0lCrCK3Mft ASp1zHdvAzYlPtuon2w36yWAWVaFd+wscIvmdbEqZba5TJbPJpgEFHlvZ/CT32ee 6yNXjOoeMnypz1AIdZgnh27Zo0hgqLD66JdvFzqa22mtU1voEzoPbwRZGGOLUpc= =pZ7R
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi once again,
Am 11.04.2011 22:10, schrieb Michael Burghart:
Quoted 7 lines
Hi,
I want to design my own templates for directories and files (fstab etc). Where do I set this? I thought it's in ./fs/skeleton. But obviously not for every file..
Why this?
I set this in .config:
BR2_ROOTFS_SKELETON_CUSTOM=y BR2_ROOTFS_SKELETON_CUSTOM_PATH="/Save/buildroot-2011.02/fs/skeleton"
but it's not used! I made special directories and files in the fs/skeleton but they are nowhere to be seen. What do I have to do to make them visible??
- --
- --
cheers
- -micha-
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNo2n6AAoJEEMkp/gkis19o90IAKcfTK+P4CAQKMiCPobd2UmU 3T3qYQA+EylLG7ZP1rSkj/2BwopdiAfy+yp6Jftl9qjpJDt5n4xlGqi9F6BZV6wP Xda00VwVR0yChT8E1lVF63YZPAF6L5gtpav3vP0EoYdLTfwRqBFoXvF7VPjZ0VCE 72MGenaH19GDLCLU5ukWFiwh0bDnBgywX6HVoIFkTC3vLVQvMlij61FZ+FEHsUEs S3bPXdZwV5Z+WHSmOTgVgHGCmkf5KvfmtrzdwT7kCAyNEqxA4KwDV/v/PRVQ+PfR 9r/Bphr4G1g4pdI/imViCuX6TGbRVtoSRG7hfHL+tMaQIiq+MzvzcDLSVd1R1Qo= =cCdh
-----END PGP SIGNATURE-----
Quoted 10 lines · Michael Burghart
Am 11.04.2011 22:10, schrieb Michael Burghart:
I set this in .config:BR2_ROOTFS_SKELETON_CUSTOM=y BR2_ROOTFS_SKELETON_CUSTOM_PATH="/Save/buildroot-2011.02/fs/skeleton"
but it's not used! I made special directories and files in the fs/skeleton but they are nowhere to be seen. What do I have to do to make them visible??
Buildroot has a quirk: the rootfs skeleton is copied to the target dir only once(!). If you change any files in ./fs/skeleton (or your custom path) you have to do "make clean" and start over (or hack the Makefile, around line 420...).
Best regards,
Bj?rn Forsman
Quoted 4 lines · Bj?rn Forsman
Buildroot has a quirk: the rootfs skeleton is copied to the target dir only once(!). If you change any files in ./fs/skeleton (or your custom path) you have to do "make clean" and start over (or hack the
Makefile, around line 420...).
I've been copying the skeleton to the "customize" package (re:
package/customize/source), removing output/build/.root and rerunning the make. I think this will recopy the skeleton I updated before generating the fs image, but without having to recompile everything. You just have to have the customize package enabled.
I say this with only modest confidence - I don't remember checking if it *actually* ran the custom package build again but I was pretty sure it did. That was how I was picking up skeleton changes from my build system.
Signature · 1 line
Michael J. Hammel <[email protected]>
[cut]
Quoted 4 lines
Buildroot has a quirk: the rootfs skeleton is copied to the target dir only once(!). If you change any files in ./fs/skeleton (or your custom path) you have to do "make clean" and start over (or hack the
Makefile, around line 420...).
It's not a quirk. I always thought its designed like that. You should work and modify files in directory buildroot/output/target, shouldn't you?
Signature · 4 lines
Patryk "LeadMan" Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Quoted 6 lines · Patryk Benderz
[cut]
Quoted 4 lines
Buildroot has a quirk: the rootfs skeleton is copied to the target dir only once(!). If you change any files in ./fs/skeleton (or your custom path) you have to do "make clean" and start over (or hack the
Makefile, around line 420...).It's not a quirk. I always thought its designed like that.
Yes, it's most likely intended.
But why not always copy skeleton to target dir? I think it would be more user friendly. If you remove stuff from skeleton you will get out of sync with target dir, but without a package manager that out-of-sync problem is inevitable (unless doing full "make clean && make".. painfully slow for small skeleton changes). And there *is* currently an out-of-sync problem in that changes to ./fs/skeleton is not copied to target dir. And that is confusing.
I think it is more common to *change* skeleton files than to remove, so I would definitely like to see always-copy-skeleton functionality in Buildroot.
Quoted 3 lines
You should
work and modify files in directory buildroot/output/target, shouldn't you?
If you meant "you should not modify files in buildroot/output/target" then yes. That directory is the output of builds and "make clean" will destroy it.
Best regards,
Bj?rn Forsman
Il 11/04/2011 22:52, Michael Burghart ha scritto:
Quoted 9 lines
I set this in .config:
BR2_ROOTFS_SKELETON_CUSTOM=y BR2_ROOTFS_SKELETON_CUSTOM_PATH="/Save/buildroot-2011.02/fs/skeleton"
but it's not used! I made special directories and files in the fs/skeleton but they are nowhere to be seen. What do I have to do to make them visible??
You need to do a full rebuild or just copy changed/updated files to the target directory (target) and rebuild/regenerate filesystems
Signature · 20 lines
____________________________________________________________
|
Daniele Salvatore Albano | web site:
IT Consultant | http://www.itechcon.it
Website Design and Development |
Software Engineer and Developer | e-mail:
Linux Servers SetUp And Administration | info at itechcon.it
Embedded Network Solutions | d.albano at itechcon.it
Ai sensi del D.Lgs. 196/2003 si precisa che le informazioni contenute in
questo messaggio sono riservate ed a uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La
invitiamo ad eliminarlo senza copiarlo e a non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Pursuant to Legislative Decree No. 196/2003, you are hereby informed
that this message contains confidential information intended only for
the use of the addressee. If you are not the addressee, and have
received this message by mistake, please delete it and immediately
notify us. You may not copy or disseminate this message to anyone. Thank
you.Quoted 7 lines · Daniele Salvatore Albano
Il 11/04/2011 22:52, Michael Burghart ha scritto:
Quoted 6 lines
I set this in .config:
BR2_ROOTFS_SKELETON_CUSTOM=y BR2_ROOTFS_SKELETON_CUSTOM_PATH="/Save/buildroot-2011.02/fs/skeleton"
Quoted 7 lines
Quoted 3 lines
but it's not used! I made special directories and files in the fs/skeleton but they are nowhere to be seen. What do I have to do to make them visible??
You need to do a full rebuild or just copy changed/updated files to the target directory (target) and rebuild/regenerate filesystems
Or you can use the
BR2_ROOTFS_POST_BUILD_SCRIPT:
? Specify a script to be run after the build has finished and before
?
? the BR2 starts packing the files into selected packages.
?
? This gives users the oportunity to do board-specific cleanups,
?
? add-ons and the like, so the generated files can be used directly
?
? without further processing.
?
? The script is called with the target directory name as first and
?
? only argument. Make sure the exit code of that script is 0,
?
? otherwise make will stop after calling it.
? ? Symbol: BR2_ROOTFS_POST_BUILD_SCRIPT
[=$(TOPDIR)/target/device/beaglebo ?
? Type : string
?
? Prompt: Custom script to run before packing files
?
? Defined at fs/Config.in:3
?
? Location:
?
? -> Target filesystem options
?Sorry about the mess in the cut and paste from buildroot's menuconfig.
Mine patchrootfs is:
#!/bin/bash
#
# skript which runs before creating rootfs
#
#
MAINDIR=${1}/../../
SRCDIR=${MAINDIR}"target/device/beagleboard/skeleton/*"
DESTDIR=${1}
echo "***************patching some stuff in " ${DESTDIR} from ${SRCDIR}
#echo "DESTDIR " ${DESTDIR}
#echo "SRCDIR " ${SRCDIR}
#ls -l ${SRCDIR} ${SRCDIR}"/etc"
cp -rvp ${SRCDIR} ${DESTDIR}
echo "end of userdefined script before packing rootfs"So this copies the fs skeleton, recursively from the local directory after every build. The trick is it just overlays the fs in the target, so you only have to add files that are specific or changed in your build. So if you tweak an existing file say in /etc, it will replace that file. If you add a new file (maybe a script) say in /usr/bin it will add that from your local tree into the build. The local skeleton should stay very sparse.
There is no way to remove files that are not needed etc, just remove them locally in your skeleton and when buildroot is remade with a clean it will get all sorted out.
Regards, Steve
Quoted 74 lines · Steve Calfee
Quoted 7 lines · Daniele Salvatore Albano
Il 11/04/2011 22:52, Michael Burghart ha scritto:
Quoted 6 lines
I set this in .config:
BR2_ROOTFS_SKELETON_CUSTOM=y BR2_ROOTFS_SKELETON_CUSTOM_PATH="/Save/buildroot-2011.02/fs/skeleton"
Quoted 7 lines
Quoted 3 lines
but it's not used! I made special directories and files in the fs/skeleton but they are nowhere to be seen. What do I have to do to make them visible??
You need to do a full rebuild or just copy changed/updated files to the target directory (target) and rebuild/regenerate filesystems
Or you can use the
BR2_ROOTFS_POST_BUILD_SCRIPT:
? Specify a script to be run after the build has finished and before? ? the BR2 starts packing the files into selected packages. ? ? This gives users the oportunity to do board-specific cleanups, ? ? add-ons and the like, so the generated files can be used directly ? ? without further processing. ? ? The script is called with the target directory name as first and ? ? only argument. Make sure the exit code of that script is 0, ? ? otherwise make will stop after calling it. ?? Symbol:
BR2_ROOTFS_POST_BUILD_SCRIPT
[=$(TOPDIR)/target/device/beaglebo ?
? Type : string? ? Prompt: Custom script to run before packing files ? ? Defined at fs/Config.in:3 ? ? Location: ? ? -> Target filesystem options ?Sorry about the mess in the cut and paste from buildroot's menuconfig.
Mine patchrootfs is:
#!/bin/bash
## skript which runs before creating rootfs # # MAINDIR=${1}/../../ SRCDIR=${MAINDIR}"target/device/beagleboard/skeleton/*" DESTDIR=${1} echo "***************patching some stuff in " ${DESTDIR} from ${SRCDIR} #echo "DESTDIR " ${DESTDIR} #echo "SRCDIR " ${SRCDIR} #ls -l ${SRCDIR} ${SRCDIR}"/etc" cp -rvp ${SRCDIR} ${DESTDIR} echo "end of userdefined script before packing rootfs"So this copies the fs skeleton, recursively from the local directory after every build. The trick is it just overlays the fs in the target, so you only have to add files that are specific or changed in your build. So if you tweak an existing file say in /etc, it will replace that file. If you add a new file (maybe a script) say in
/usr/binit will add that from your local tree into the build. The local skeleton should stay very sparse.
Quoted 4 lines
There is no way to remove files that are not needed etc, just remove them locally in your skeleton and when buildroot is remade with a clean it will get all sorted out.
Would using rsync with appropriate options instead of cp do that trick?
Mike
Quoted 5 lines
Regards, Steve
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Quoted 24 lines · Michael S. Zick
Quoted 24 lines
Mine patchrootfs is:
#!/bin/bash
## skript which runs before creating rootfs # # MAINDIR=${1}/../../ SRCDIR=${MAINDIR}"target/device/beagleboard/skeleton/*" DESTDIR=${1} echo "***************patching some stuff in " ${DESTDIR} from ${SRCDIR} #echo "DESTDIR " ${DESTDIR} #echo "SRCDIR " ${SRCDIR} #ls -l ${SRCDIR} ${SRCDIR}"/etc" cp -rvp ${SRCDIR} ${DESTDIR} echo "end of userdefined script before packing rootfs"So this copies the fs skeleton, recursively from the local directory after every build. The trick is it just overlays the fs in the target, so you only have to add files that are specific or changed in your build. So if you tweak an existing file say in /etc, it will replace that file. If you add a new file (maybe a script) say in
/usr/binit will add that from your local tree into the build. The local skeleton should stay very sparse.
Quoted 8 lines
Quoted 4 lines
There is no way to remove files that are not needed etc, just remove them locally in your skeleton and when buildroot is remade with a clean it will get all sorted out.
Would using rsync with appropriate options instead of cp do that trick?
Mike
Hi Mike,
Maybe, but I think you would have to have an entire tree in your local directory, my goal was to have as few board specific files as necessary. I haven't actually found it much of a problem growing litter in the file system. And if it is I can always do the buildroot "make clean".
Regards, Steve
Quoted 1 line · On Mon, 11 Apr 2011 17:06:03 -0700 Steve Calfee <[email protected]> wrote:
BR2_ROOTFS_POST_BUILD_SCRIPT
That's also what I use. Instead of making modifications to fs/skeleton/, or completely duplicating that skeleton, my post build script :
*) Copies some additional files (which I typically store and version
control in board/<mycompany>/<myproduct>)
*) Adjust some files from the skeleton. It does this in a way that
allows to re-run make several times without screwing things. For example, if I need to add a new line at the end of a file (like /etc/fstab), I first test that this line hasn't already been added, in order to avoid duplicates.
This technique has several advantages :
*) You don't change the default skeleton, which would mess things up
next time you upgrade Buildroot ;
*) You don't duplicate the entire default skeleton, which prevents you
from taking advantages of new things in the skeleton if you upgrade Buildroot ;
*) As the post build script is executed at every 'make' invocation,
you don't have to 'make clean ; make' to see the effect of your post build script changes.
Regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 8 lines · Thomas Petazzoni
Quoted 1 line · On Mon, 11 Apr 2011 17:06:03 -0700 Steve Calfee <[email protected]> wrote:
?BR2_ROOTFS_POST_BUILD_SCRIPT
That's also what I use. Instead of making modifications to
fs/skeleton/, or completely duplicating that skeleton, my post build script :
I currently use git branches and edit fs/skeleton in each branch. I have one branch per project. I think this setup has some nice properties:
Quoted 5 lines
?*) Adjust some files from the skeleton. It does this in a way that ? ?allows to re-run make several times without screwing things. For ? ?example, if I need to add a new line at the end of a file ? ?(like
/etc/fstab), I first test that this line hasn't already been ? ?added, in order to avoid duplicates.
Automatically handled (or non-existent problem) if using fs/skeleton with git branches.
Quoted 4 lines
This technique has several advantages :
?*) You don't change the default skeleton, which would mess things up ? ?next time you upgrade Buildroot ;
Why is it messy?
Using git branches you will be notified of conflicts. Upgrades are safe. If, on the other hand, the post build script is used to edits skeleton files you may end up with undetected conflicts after a skeleton upgrade (unsafe).
Quoted 3 lines
?*) As the post build script is executed at every 'make' invocation, ? ?you don't have to 'make clean ; make' to see the effect of your post ? ?build script changes.
I've modified the top Makefile so that fs/skeleton is copied to target dir on every 'make' (patches sent to list[1]).
It may be seen as a downside that this approach is only one-project-per-branch. But I find that there are already differences between projects, not only in the skeleton files, so I use one branch per project anyway.
Are there any (other) downsides to this approach I may have missed?
[1]: http://lists.busybox.net/pipermail/buildroot/2011-March/041685.html
Best regards,
Bj?rn Forsman