On Sat, 2011-05-07 at 09:54 -0400, Daniel Dickinson wrote:
> Which reminds me, which target is the offending one with a per-target
> fstab (which I believe is wrong, unless the target can only ever
> possibly have a single known USB device (i.e. internal USB device
> only, rather than USB host port))?

In my case it is a target that is not (yet) in the OpenWRT repository,
but looking at current trunk, I see 3 fstab's in target/linux:

target/linux/xburst/base-files/etc/config/fstab
target/linux/omap24xx/base-files/etc/config/fstab
target/linux/s3c24xx/openmoko-gta02/base-files/etc/config/fstab

> Also, I want to take a look at the fstab and see how it differs from
> the default to see if it truly a platform-specific config or just that
> the platform dev happens to prefer a different config.

The list above there are at least 2 different fstabs, as openmoko and
xburst onces seem to be the same.

> If it's a true target-specific one then the thing to do is modify the
> block-mount makefile to use a different config depending on the
> target.  If not then I need to discuss the issue with the platform
> maintainer.

I have a couple of use cases on different targets where fstab is used
for mount points which aren't internal. They are not only target
specific, but *product* specific.

In the end, I think this is not just a block-mount problem but a generic
problem with device "profiles" having custom configuration. I know in
most cases this gets "solved" by using uci-defaults to reconfigure, but
in my case it is a target running from ramdisk, so every boot is a
"first" boot ;-)

The alternative of the files/ directory in the WRT buildroot is IMHO a
very bad solution for this, as it will be used regardless of which
target or profile you build for, and at least I tend to have one build
tree for multiple targets/profiles.

I would like a hook in the profiles to do post-package-install
configuration on the rootfs, if it isn't there already. I have to admit
I haven't found time yet to look more closely at this.

Regards,

Ithamar.


_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to