QA (public) » openQA Project (public) » openQA Tests (public)

I have booted a job using the following:
UEFI_PFLASH_CODE=/usr/share/qemu/ovmf-x86_64-code.bin
UEFI_PFLASH_VARS=/usr/share/qemu/ovmf-x86_64-vars.bin

Booting now works, but zypper ref complains:

$ zypper -n refresh
Retrieving repository 'SL-Micro-6.1-Pool' metadata [.........Repository 'SL-Micro-6.1-Pool' is invalid.
[SUSE_Linux_Micro_6.1_x86_64:SL-Micro-6.1-Pool|http://openqa.suse.de/assets/repo/SL-Micro-Packages-6.1-x86_64-BuildV.6.1/] Valid metadata not found at specified URL
History:
 - Signature verification failed for repomd.xml

Please check if the URIs defined for this repository are pointing to a valid repository.
Skipping repository 'SL-Micro-6.1-Pool' because of the above error.
Could not refresh the repositories because of errors.


New repository or package signing key received:

  Repository:       SL-Micro-6.1-Pool
  Key Fingerprint:  F5FE 65C3 163C D347 266C 583D 9C75 3149 CE3B 672E
  Key Name:         Unsupported <unsupported-rsa@suse.de>
  Key Algorithm:    RSA 2048
  Key Created:      Tue Feb 14 15:47:25 2023
  Key Expires:      Sat Feb 13 15:47:25 2027
  Rpm Name:         gpg-pubkey-ce3b672e-63ebad0d



    Note: Signing data enables the recipient to verify that no modifications occurred after the data
    were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system
    and in extreme cases even to a system compromise.

    Note: A GPG pubkey is clearly identified by its fingerprint. Do not rely on the key's name. If
    you are not sure whether the presented key is authentic, ask the repository provider or check
    their web site. Many providers maintain a web page showing the fingerprints of the GPG keys they
    are using.

Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): r
error]

And if you try to use auto import keys:

$ zypper --gpg-auto-import-keys ref

Retrieving repository 'SL-Micro-6.1-Pool' metadata [.........

Automatically importing the following key:

  Repository:       SL-Micro-6.1-Pool
  Key Fingerprint:  F5FE 65C3 163C D347 266C 583D 9C75 3149 CE3B 672E
  Key Name:         Unsupported <unsupported-rsa@suse.de>
  Key Algorithm:    RSA 2048
  Key Created:      Tue Feb 14 15:47:25 2023
  Key Expires:      Sat Feb 13 15:47:25 2027
  Rpm Name:         gpg-pubkey-ce3b672e-63ebad0d



    Note: A GPG pubkey is clearly identified by its fingerprint. Do not rely on the key's name. If
    you are not sure whether the presented key is authentic, ask the repository provider or check
    their web site. Many providers maintain a web page showing the fingerprints of the GPG keys they
    are using.
Subprocess failed. Error: Failed to import public key [9C753149CE3B672E-63ebad0d] [Unsupported <unsupported-rsa@suse.de>] [expires: 2027-02-13]
History:
 - Command exited with status 1.
 - error: /var/tmp/zypp.8l5Sq2/pubkey-9C753149CE3B672E-MSopej: key 1 import failed.
 - error: can't create transaction lock on /usr/lib/sysimage/rpm/.rpm.lock (Read-only file system)

..............done]
Building repository 'SL-Micro-6.1-Pool' cache [....done]
All repositories have been refreshed.

I was thinking of one approach:

• in stagings only, build suse-build-key and include the current repokey.
• build installation-images to include this as trusted key
• build media
• build kiwi images also with suse-build-key

However, this does not work if only RPM-MD repos are built, like we have on SLE Micro 6.0 maintenance use-case.

There I think the best way is to auto import the staging key, either hardcoding of as Jose proposed a zypper ref --auto-import-keys

For secure boot, you either can disable secure boot in stagings (but run in main repo), or implement handling the MOK import dialog.