Comment 3 for bug 1836867

I did a bit more investigation, and here is what I have so far, maybe someone more familiar with the matter can make an educated guess based on this:

I initially figured that the order of the curtin configs matters, and to some extend that is certainly true (see the merge proposal linked above).

However, the order has not changed from 2.4 to 2.6, so I wanted to know what exactly changed that made this work in 2.4. I wrote out all the curtin config files in a similar way curtin does when it `pack()`s the image here: https://git.launchpad.net/curtin/tree/curtin/pack.py#n231

The `main_config`, which includes the snippets I added in `/etc/maas/preseeds/curtin_userdata_custom` (including setting preserve_sources_list to true) is always one of the first files. The next file is generated from the `archive_config`, which _always_ contains `preserve_sources_list: false`, so given nothing else, assuming a fairly standard config merge algorithm, it is no surprise that the latter would overwrite the former.

That begs the question: why does it work in 2.4 then? The only difference in the curtin configs that I could find that are possibly related to this is the debconf section that is also part of the `main_config`.

This is the debconf section in 2.4:

debconf_selections: {grub2: grub2 grub2/update_nvram boolean false, maas: 'cloud-init cloud-init/datasources multiselect
    MAAS

    cloud-init cloud-init/maas-metadata-url string http://10.33.152.28:5240/MAAS/metadata/

    cloud-init cloud-init/maas-metadata-credentials string oauth_consumer_key=...&oauth_token_key=...&oauth_token_secret=...

    cloud-init cloud-init/local-cloud-config string apt:\n preserve_sources_list:
    false\n primary:\n - arches: [default]\n uri: http://archive.ubuntu.com/ubuntu\n proxy:
    http://10.33.152.28:8000/\n security:\n - arches: [default]\n uri: http://archive.ubuntu.com/ubuntu\napt_preserve_sources_list:
    true\napt_proxy: http://10.33.152.28:8000/\nmanage_etc_hosts: false\nmanual_cache_clean:
    true\nreporting:\n maas: {consumer_key: ..., endpoint: ''http://10.33.152.28:5240/MAAS/metadata/status/mg84hc'',\n token_key:
    ..., token_secret: ...,\n type:
    webhook}\nsystem_info:\n package_mirrors:\n - arches: [i386, amd64]\n failsafe:
    {primary: ''http://archive.ubuntu.com/ubuntu'', security: ''http://security.ubuntu.com/ubuntu''}\n search:\n primary:
    [''http://archive.ubuntu.com/ubuntu'']\n security: [''http://archive.ubuntu.com/ubuntu'']\n -
    arches: [default]\n failsafe: {primary: ''http://ports.ubuntu.com/ubuntu-ports'',
    security: ''http://ports.ubuntu.com/ubuntu-ports''}\n search:\n primary:
    [''http://ports.ubuntu.com/ubuntu-ports'']\n security: [''http://ports.ubuntu.com/ubuntu-ports'']\n

    '

Note that this contains the setting to NOT preserve the sources first, and then again to DO preserve the sources, potentially overriding the first one.

The debconf section in 2.6 does not contain anything related to apt at all.

So just from looking at it I would guess that this it _might_ be related, though it does not quite make sense to me. From what I understand, this is debconf selection done by curtin for cloud-init inside the target, but I don't think curtin executes cloud-init inside the target does it?

Another thought I was having that this config got somehow mangled during some read/write/transfer that ended up actually making the apt key inside the debconf part a top-level key (e.g. by interpreting the linebreaks in there where it shouldn't have.

I was writing these files out myself on the MAAS host, I have not figured out how to get the actual files as curtin found them, so it remains a bit of speculation.

Now, this is just me trying to really understand what is happening. But given that the debconf part in 2.6 now looks completely different anyways, maybe it is not worth investing any more time in this. I still think reordering is _probably_ the right thing to do, will follow up on the merge request soon...

Thanks a lot,
Conrad