SUSE seems to have changed the /etc/os-release file so that VERSION is now the corresponding SLES version, i.e. 16.0 for SL Micro 6.2, and the actual Micro version is now under SUSE_SUPPORT_PRODUCT_VERSION. Since the awk in the rpm resolution script matches both of these, you get an array now and the product activation attempt fails because of a malformed product string.
To reproduce, run any build with operatingSystem.packages.enableExtras=true and it will error out in the rpm stage.
I'm not sure of the best way to handle this. You could just look for the second key, but given this just broke in a minor version update, it would appear /etc/os-release is not meant to be a stable API. suseconnect itself handles this somehow since it knows the version to activate when you register the system, so you can copy whatever it does. Alternatively, suseconnect -s if called after initial registration will give machine-readable output of the product status, which includes the version.
SUSE seems to have changed the
/etc/os-releasefile so thatVERSIONis now the corresponding SLES version, i.e. 16.0 for SL Micro 6.2, and the actual Micro version is now underSUSE_SUPPORT_PRODUCT_VERSION. Since the awk in the rpm resolution script matches both of these, you get an array now and the product activation attempt fails because of a malformed product string.To reproduce, run any build with
operatingSystem.packages.enableExtras=trueand it will error out in the rpm stage.I'm not sure of the best way to handle this. You could just look for the second key, but given this just broke in a minor version update, it would appear
/etc/os-releaseis not meant to be a stable API.suseconnectitself handles this somehow since it knows the version to activate when you register the system, so you can copy whatever it does. Alternatively,suseconnect -sif called after initial registration will give machine-readable output of the product status, which includes the version.