[Buildroot] Modifying boot scripts in buildroot's output

[Buildroot] Modifying boot scripts in buildroot's output

[JNY]

Hi,
I've noticed a slight problem with the boot scripts when I install my target
with buildroot's output.  I know how to modify the scripts by hand after
installing, but would prefer buildroot's output contain the modified
scripts, so on installation, the scripts are correct.  I didn't (knowingly)
configure these scripts, so I assume it's done in the background somewhere. 
Can anyone advise on how to go about this (assuming can be done!).
Regards,
JNY
-- 
View this message in context: http://old.nabble.com/Modifying-boot-scripts-in-buildroot%27s-output-tp29415478p29415478.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.

[Buildroot] Modifying boot scripts in buildroot's output

[Ossy]

Am 12.08.2010 09:16, schrieb JNY:
>
> I've noticed a slight problem with the boot scripts when I install my target
> with buildroot's output.  I know how to modify the scripts by hand after
> installing, but would prefer buildroot's output contain the modified
> scripts, so on installation, the scripts are correct.  I didn't (knowingly)
> configure these scripts, so I assume it's done in the background somewhere.
>
If this is a general problem for ALL target builds and prevent future 
rootfs from beeing bootable, you should describe your problem for the 
mailinglist. Maybe it should be fixed in the main target_skeleton.

But I assume, you like to override the default scripts of the "built-in" 
target_skeleton. My configuration looks like this:
ossy at debian-virtual:~/buildroot/buildroot-dev$ ll 
target/device/sheevaplug/SeagateDockStar/target_skeleton/
insgesamt 0
drwxr-xr-x  2 ossy ossy  19 18. Mai 22:19 bin
drwxr-xr-x  2 ossy ossy  19 18. Mai 22:19 boot
drwxr-xr-x  2 ossy ossy  19 18. Mai 22:19 config
drwxr-xr-x  2 ossy ossy  19 18. Mai 22:19 dev
drwxr-xr-x  7 ossy ossy 141  8. Aug 22:34 etc
drwxr-xr-x  2 ossy ossy  19 18. Mai 22:19 home
drwxr-xr-x  2 ossy ossy  19 18. Mai 22:19 lib
drwxr-xr-x  2 ossy ossy  19 18. Mai 22:19 mnt
drwxr-xr-x  2 ossy ossy  19 18. Mai 22:19 opt
drwxr-xr-x  2 ossy ossy  92 18. Mai 22:19 root
drwxr-xr-x  2 ossy ossy  19 18. Mai 22:19 sbin
drwxr-xr-x  2 ossy ossy  19 18. Mai 22:19 sys
drwxr-xr-x  2 ossy ossy  24 18. Mai 22:19 tmp
drwxr-xr-x  2 ossy ossy  19  6. Aug 22:14 usr
drwxr-xr-x 10 ossy ossy  94 18. Mai 22:19 var

ossy at debian-virtual:~/buildroot/buildroot-dev$ ls -la 
target/device/sheevaplug/SeagateDockStar/target_skeleton/bin/
insgesamt 4
drwxr-xr-x  2 ossy ossy   19 18. Mai 22:19 .
drwxr-xr-x 17 ossy ossy 4096 18. Mai 22:19 ..
-rw-r--r--  1 ossy ossy    0 18. Mai 22:19 .empty


All directories which to not differ from the default have such an 
".empty" stamp in it.
I wanted to modify the inittab in order to modify the default boot 
behaviour a bit. So I put MY modified inittab in:
ossy at debian-virtual:~/buildroot/buildroot-dev$ ls -la 
target/device/sheevaplug/SeagateDockStar/target_skeleton/etc/inittab
-rw-r--r-- 1 ossy ossy 1480  8. Aug 16:32 
target/device/sheevaplug/SeagateDockStar/target_skeleton/etc/inittab

I advised the buildroot mechanism to use a customised target skeleton:
ossy at debian-virtual:~/buildroot/buildroot-dev$ grep target_skeleton .config
BR2_ROOTFS_SKELETON_CUSTOM_PATH="$(BOARD_PATH)/target_skeleton"
(where board-path is target/device/sheevaplug/SeagateDockStar/ )

The resulting rootfs includes the default content where a .empty stamp 
is present, but it includes my modified inittab from 
target/device/sheevaplug/SeagateDockStar/target_skeleton/etc/.

Regards,
Marcus