Console Conf and

Would someone be so kind as to tell me how to change this? I’m about to poke around some more myself but I seem to recalling checking all of the source for console conf and did not obviously see it.

It’s a core 18 build and I am pulling all parts of the image (snaps) from an alternate location. I can unsquash them and manipulate as necessary so that’s not a problem.

p.s. - snapd doesn’t feel quite right for category but… :man_shrugging:?


OK, to answer my own question (and I think I figured this out once before but this is hard :))…

I believe it’s done here:

self.ui.frame.body.progress.set_text("Contacting store...")
            result = run_command(["snap", "create-user", "--sudoer", "--json", email])
            if result['status'] != 0:
                self.ui.frame.body.error.set_text("Creating user failed:\n" + result['err'])

So it’s the snap binary that’s shipped with the core snap (in this case) that likely needs to be adjusted.

Duh! Of course it requires a fixed snapd in core as well. That’s actually probably more important than the fixed snap binary I’m guessing. Live and learn.

that should not be … UC18 builds actually use the snapd snap and do only ship a symlink inside the core18 base pointing to the snap command inside the snapd snap (and usually do not ship core unless there is an app snap requiring it) … console-conf waits until snapd notifies about “seeding done” there …

I think I may have been mistaken. I used an 18 gadget and kernel but didn’t specify my base as core18. So that probably accounts for the difference in behavior vs. expectation, right?

if you included an app snap that had no base, yes, that would then use core at runtime … but would have no influence on the OS itself or on console-conf. if you built with a UC18 model assertion, used a gadget and kernel for UC18, you boot into a UC18 system, no matter what bases the apps on top of that use …

That’s not what I meant. I meant the base in the model assertion.

I will double check my work but whatever image I ended up with after I replaced the snap/snapd binaries in core I was able to login and get a user created with my SSH key as expected.

right, all i’m saying is that unless you used UC16, there is no snap binary in the base snap, just a symlink to the one shipped in the snapd snap …

(this is there since core18)

Right but wouldn’t the model assertion need base: core18? Anyway here’s the model assertion I used:

    "type": "model",
    "series": "16",
    "authority-id": "itl",
    "brand-id": "itl",
    "model": "itl-ubuntu-core-18-amd64",
    "architecture": "amd64",
    "timestamp": "2021-04-10T20:41:00+00:00",
    "gadget": "itl-pc=18",
    "kernel": "itl-pc-kernel=18"

That gadget and kernel should just be the “stock” 18 gadget and kernel. The core snap it will pull when building is similarly the “stock” core. The only changes have been to either names or in the case of core replacing binaries.

The seed manifest is:

itl-pc-kernel 58
core 60
itl-pc 57

So what makes a Ubuntu Core 18 image an Ubuntu Core 18 image? is the gadget and kernel enough? Does the base need to be specified to core18?

well, the answer lies in /etc/os-release … :slight_smile:

but what you have there will indeed use the core snap as base and thus be effectively a UC16 image …

There you have it. :slight_smile:

itl@localhost:~$ cat /etc/os-release 
NAME="Ubuntu Core"
PRETTY_NAME="Ubuntu Core 16"

But it IS using a newer 18 kernel:

itl@localhost:~$ uname -ra
Linux localhost.localdomain 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

what is “an 18 kernel” ?

it is using a kernel, UC does not care what kernel, as long as it is new enough (>= 4.4) the proper config defaults are there and the set of apparmor patches is complete, you should be able to combine any kernel with any base snap.

Just being lazy… Meaning the kernel 18.04 shipped with as opposed to the kernel 16.04 shipped with. I’ll hold you to any kernel with any base snap. :stuck_out_tongue:

Edit: and really I just meant the pc-kernel=18 that I specified.

well, since this seems to be your own kernel installed from a local snap file, the track (18) is really not relevant…

but anyway, your statement about the snap binary in the base snap was the confusing bit here, since you claimed to have a core18 image in the initial post … that mystery has been solved for good now i think :slight_smile:

Yeah just to be clear, the /usr/bin/snap command comes either from the core snap on a UC16 system, or from the snapd snap on all other systems, with the /usr/bin/snap command in the core18 or core20 snaps just being a symlink to the real command from the snapd snap.

Also I don’t think our documentation makes this distinction, but there are “3” types of model assertions for ubuntu core:

  • No base specified -> UC16, your base snap is the core snap and your snapd comes from the core snap (unless you manually transition the device to use the snapd snap which won’t be done automatically)
  • Base specified as core18 or anything other than core20 if you have your own forked base snap: Ubuntu Core 18, here you always have the snapd snap, so snapd always comes from the snapd snap, even if you also have the core snap installed
  • snaps header and grade header in the model assertion -> Ubuntu Core 20+. There are other tidbits here which create the system known as Ubuntu Core 20, such as the new initramfs in a kernel intended for Ubuntu Core 20, as well as a different partition layout, etc. If you have base: core20 then this is a stock UC20 system, if you have base: core22 (no idea if this exists yet), then this would be a Ubuntu Core 22 system, as we don’t plan on revamping the model assertion again for Ubuntu Core 22.

Hopefully that makes it slightly more clear how the model relates to the version of Ubuntu Core.

1 Like