Change UCI during init

Device is an Itus Shield Octeon III, non-supported platform.

During init, I do various checks on the mmc blk devices before handing rootfs off to them. If a check fails, it calls a "first boot" script that I keep in the images /etc/config/firstboot-sh file. After it runs, it hands off root to the block device (exec switch_root ${extroot_dir} /sbin/init).

The script runs successfully in running the tar xvzf call to extract the files I need, but I need to run several uci set commands depending on some previous variables.

/sbin/uci set snort.snort.interface='br-lan'
/sbin/uci set snort.snort.config_file='/etc/snort/snort.conf'

These are before the tar call, so I know it's completing the file (and finishing the boot), but the changes aren't made. Doing a uci show snort still shows snort.snort.interface='lo' rather than the br-lan

# This script serves as the jumping point for initial setup on a first boot.
# The script will setup aspects of the system from the "default" settings.

# Snort
# By default, Snort uses the 'lo' interface.  We want it watching the actual traffic.
/sbin/uci set snort.snort.interface='br-lan'
/sbin/uci set snort.snort.config_file='/etc/snort/snort.conf'

# Extract the Snort configuration and rule files
tar xvzf /etc/snort.tgz -C /extroot/etc

What am I doing wrong?

Are the things you’re trying to modify in existence and responsive at the time your script is running?

If you’re before mount_root, I believe you’re writing to tmpfs

Also, shebang of sh is more robust.


Would export survive the boot? If I can't call the script during init, then maybe I can set a export variable and a init.d script to check it later in boot.

As it’s a custom ROM, why not burn in your config?

The device has 3 select-able modes: router, bridge, gateway depending on a front-panel switch. I'm setting the mode during init by reading the GPIO switches. So, the file the first boot script calls depends on the mode, which then sets up the external root partition and configurations for the given mode. If I burn it into the image, I have to deal with 3 separate images.

Sounds like you’ve got the root-to-be mounted and writable before the bulk of procd is running. What about writing to /etc/config/ on the about-to-be-mounted file system?

Device has 3 mmc blocks (/dev/mmcblk1pX where X = 2-4), one for each mode. The script is for determining if the existing external root is a legacy closed image (OpenWrt based, but the company never published the source before they folded) and copying the current images root directory to the external before switching root to the outside.

So, basically, it goes:

uboot Stage 1 -> uboot Stage 2 -> Stage 3 is the image to be loaded for the mode
init then stalls until /dev/mmcblk1 is available, mounts the correct partition to /extroot

If the partition is correct for the image (I drop a .keyfile on /extroot for it and check that it exists), it hands off root to the external. If it isn't, it calls

cp -a -f bin etc init lib lib64 mnt overlay rom root sbin tmp usr var www ${extroot_dir}
and then hands off root.

Since the filesystem itself is identical for each of the 3 images, I need to select the correct tgz file that I'm including in the source_tree/files/ that contains the correct configuration files and settings for the given mode (network settings, snort settings, e2guardian settings, etc, etc).

I do extract the tgz file to the /extroot (because it is before the switch_root), but I don't know where the uci settings are stored. I'd be happy to just alter THOSE instead, I just figured calling uci set would be easier. Any idea where they are kept?

Ah ha.

I set an export FIRSTBOOT=0

Setting an export FIRSTBOOT=1 when I would have called the firstboot script and then having a /etc/rc.d/S13firstboot linked to /etc/init.d/firstboot that checks for that FIRSTBOOT=1 to see if it needs to run. It works. It isn't pretty, but at least I can migrate it out of init and put it all in one file that runs if it needs to.

Thanks for the help @jeff!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.