Before diving too far down this rathole... aren't the package scripts
run in the context of the zone?
James Carlson wrote:
> Ralf Weber writes:
>> or your zone path when the package gets created inside a zone. So I
>> would rewrite your scripts as:
> [...]
>> ${BASEDIR}/usr/sbin/chroot ${BASEDIR} /usr/sbin/groupadd -g 27 mysql
>> ${BASEDIR}/usr/sbin/chroot ${BASEDIR} /usr/sbin/useradd -u 27 -d /var/
>> lib/mysql -s /bin/false -G mysql mysql
>
> I wouldn't. There's no guarantee at all that $BASEDIR refers to an
> instance of the OS that can run at all with the current running
> kernel.
>
> In more detail: when you use chroot, the system reads *everything*
> from the given base directory, including the system libraries. That
> means you'll load up $BASEDIR/usr/sbin/groupadd and try to link in
> $BASEDIR/lib/libc.so.1 (among many other things). That library makes
> undocumented system calls that in turn depend on the exact rev of the
> kernel.
>
> What happens when you do that is arbitrary. It may work, as the
> system call interface usually changes slowly, but it may not. It all
> depends on the calls made by the application and the nature of the
> user/kernel flag days that have passed between these two images.
>
> (Note that Sun's ABI guarantee applies at the ABI level -- meaning the
> documented system library interfaces -- and not at the system call
> level.)
>
> What you're suggesting isn't supported and can't be supported.
> Instead of that, I'd suggest using nawk for now, and adding a call
> record to CR 6387333. useradd/groupadd should know how to deal with
> alternate roots.
>
