Install snapd and a package using snapd during kickstart

1

On an RHEL 7.8 installed system, I am able to install snapd and also install a program using snapd.

However, I’m trying to do both of those within a RHEL7 kickstart post script so I can install all my packages in an automated process.

I’m able to install snapd via RPMs within the kickstart script, but the problem I have later is that when I try to snap ack the new program, I get the following error:

error: cannot assert: cannot communicate with server: Post http://localhost/v2/assertions: dial unix /run/snapd.socket: connection refused.

I believe this is because the systemctl enable --now snapd.socket command I’m running is failing since (apparently) you cannot run systemctl commands within the kickstart post chroot environment.

Is there a non-systemctl command I can run to set up the sockets in this environment?

Thanks,
John

2

Right, that’s because the commands are actually executed in a chroot as far as I remember.

I think you could prepare the seed for snapd. On the first run, snapd will load up all the snap files and their metadata and install them in the system. This is how for instance the LXD snapd is set up in Ubuntu Cloud images.

Unfortunately, there’s not much documentation about building the seed from scratch. Apparently this was investigated before right there Seed.yaml documentation and even someone wrote a blog post on setting up the seed Seed.yaml documentation though it seems to be a bit outdated.

As quick reference I did this:

$ snap known --direct model \
    series=16 model=generic-classic brand-id=generic > generic-classic.model
$ snap prepare-image --classic --arch amd64 \
    --snap core --snap jq \
    ./generic-classic.model $PWD/dir

It should be possible to invoke all of the commands without active snapd.

The seed built a seed under $PWD/dir looks like this:

dir
└── var
    └── lib
        └── snapd
            └── seed
                ├── assertions
                │   ├── 16,8X4ytHZ2xX4kNkr8V2NU3AQuoMlglwED.snap-declaration
                │   ├── 16,99T7MUlRhtI3U0QFgl5mXXESAiSwt776.snap-declaration
                │   ├── BWDEoaqyr25nF5SNCvEv2v7QnM9QsfCc0PBMYD_i2NGSQ32EF2d4D0hqUel3m8ul.account-key
                │   ├── dFSiCVGoSMIXseHHK5W_y0WRonHv5_isSepiRYCJvdOF5l50SwTP8IdZaL4jS_Rz.snap-revision
                │   ├── d-JcZF9nD9eBw7bwMnH61x-bklnQOhQud1Is6o_cn2wTj8EYDi9musrIT9z2MdAa.account-key
                │   ├── generic.account
                │   ├── model
                │   └── U4kFeqGBTfrv8dPkHoGN9C6lW9OT_nBIcHHqUJv4EjTWTNoZoD27yOsxL9o63HIv.snap-revision
                ├── seed.yaml
                └── snaps
                    ├── core_9066.snap
                    └── jq_6.snap

The contents of seed.yaml:

$ cat dir/var/lib/snapd/seed/seed.yaml 
snaps:
- name: core
  snap-id: 99T7MUlRhtI3U0QFgl5mXXESAiSwt776
  channel: stable
  contact: mailto:snaps@canonical.com
  file: core_9066.snap
- name: jq
  snap-id: 8X4ytHZ2xX4kNkr8V2NU3AQuoMlglwED
  channel: stable
  contact: mailto:snaps@canonical.com
  file: jq_6.snap

It may even work if you specify / as target. If not, then transferring the contents from target directory into the chroot should be sufficient.

I’m not sure anyone has tried this on non Ubuntu, so please keep this topic updated so that we can fix any bugs.