Greengrass v2: Operating in a Ubuntu Snap

I feel like I'm so close to this working, but I have one hurdle I can't quite overcome. I'm developing a Ubuntu Snap which contains all the runtime components we require for our greengrass deployments (node, python, java, etc.). After install, the entrypoint of my main snap daemon checks to see if a greengrass install exists at $SNAP_COMMON and if not, tries to initialize greengrass as follows:

java \
    -Droot="${GG_ROOT}" \
    -Dlog.store=FILE \
    -Djava.io.tmpdir=$GG_TMP \
    -Djava.class.path=$SNAP/usr/lib/jvm/java-11-amazon-corretto/lib:/usr/lib \
    -Duser.home=$HOME \
    -jar $GG_ROOT/Greengrass.jar \
    --component-default-user ggc_user:ggc_group \
    --root $GG_ROOT \
    --start false \
    --setup-system-service false \
    --provision true \
    --aws-region ${AWS_REGION:=us-east-1} \
    --thing-name $THING_NAME \
    --thing-group-name ${THING_GROUP:=Default} \
    --thing-policy-name $THING_POLICY_NAME \

• $GG_ROOT is set to $SNAP_COMMON/greengrass/v2 (comes out to something like /var/snap/my-snap/greengrass/v2).
• $GG_ROOT/Greengrass.jar is copied from my snap (which I include during the snap build process)
• $THING_NAME, $THING_GROUP, etc. are set by sourcing an identity file installed on each server.

This seems to almost work. Greengrass.jar extracts everything to $GG_ROOT except for alts/init/distro... For some reason that get's unpacked to $SNAP (so $SNAP/bin has greengrass.exe, loader, etc.). If I set start to true, it launches correctly and I even get logs at $GG_ROOT/logs, it's just the initial deployment goes off to lala land. I haven't tried issuing a new deployment in this configuration, but can't imagine it'd work (since there are no symlinks).

Would anyone happen to have a little insight into why the initial nucleus deployment is unpacking at $SNAP here instead of $GG_ROOT/packages/... and symlinked to $GG_ROOT/alts/init. I feel like if I can figure out this init deployment, it should work... :crossed_fingers:

Code tracing:

I think my issue can start tracing at KernelAlternatives:

    private Path getAltsDir() {
        return nucleusPaths.kernelAltsPath().toAbsolutePath();
    }

which I think ultimately ends up somewhere around KernelCommandLine:146

        kernel.getConfig().lookup("system", "rootpath").dflt(rootAbsolutePath)
                .subscribe((whatHappened, topic) -> initPaths(Coerce.toString(topic)));
    }

which leads to KernelCommandLine:166.

private void initPaths(String rootAbsolutePath) {
  ...
}

Unfortunately this doesn't really explain why the install gets split up... since kernelAltPaths is relative to rootPath, which should be getting set to $GG_ROOT :(