Creating ticket based on irc report :
│(07:29:24) trent-teleport: Having issues running `yum update` - comes back with an error on `tzdata-2022g` │ │(07:29:32) trent-teleport: ```tzdata-2022g-1.el7.noarch.rpm FAILED │ │(07:29:33) trent-teleport: https://download.cf.centos.org/centos/7/updates/x86_64/Packages/tzdata-2022g-1.el7.noarch.rpm: │ │[Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=updates clean metadata │ │(07:29:33) trent-teleport: ``` │ │(07:30:19) trent-teleport: Works from non-AWS infra, and after a bit of digging I found out about the AWS-specific caching │ │mirror
Metadata Update from @arrfab: - Issue assigned to arrfab
Metadata Update from @arrfab: - Issue tagged with: centos-build-pipeline, centos-common-infra, high-gain, medium-trouble
It seems we had an issue the way some pkgs were uploaded to S3 and so causing mismatch : The way AWS cloudfront is setup is to cache objects for a long time (they shouldn't change) and so everybody was still downloading the unsigned variant, while the correct one was pushed to origin node used by Cloudfront.
I created an invalidation rule at cloudfront level, and so it was "forced" to get it from origin again, and this time it's ok :
wget http://mirror.centos.org/centos/7/updates/x86_64/Packages/tzdata-2022g-1.el7.noarch.rpm ; rpm -Kv tzdata-2022g-1.el7.noarch.rpm ; sha256sum tzdata-2022g-1.el7.noarch.rpm --2023-04-04 09:02:57-- http://mirror.centos.org/centos/7/updates/x86_64/Packages/tzdata-2022g-1.el7.noarch.rpm Resolving mirror.centos.org (mirror.centos.org)... 2605:9000:401:103::2, 204.15.73.245 Connecting to mirror.centos.org (mirror.centos.org)|2605:9000:401:103::2|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 501628 (490K) [application/x-rpm] Saving to: ‘tzdata-2022g-1.el7.noarch.rpm’ tzdata-2022g-1.el7.noarch.rpm 100%[================================================>] 489.87K 1.01MB/s in 0.5s 2023-04-04 09:02:58 (1.01 MB/s) - ‘tzdata-2022g-1.el7.noarch.rpm’ saved [501628/501628] tzdata-2022g-1.el7.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY Header SHA1 digest: OK V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY MD5 digest: OK 4af524ef4c3174e29991b9c0e236ba3d89b8d2c935d9359910aca965ba5001ca tzdata-2022g-1.el7.noarch.rpm wget https://download.cf.centos.org/centos/7/updates/x86_64/Packages/tzdata-2022g-1.el7.noarch.rpm ; rpm -Kv tzdata-2022g-1.el7.noarch.rpm ; sha256sum tzdata-2022g-1.el7.noarch.rpm --2023-04-04 09:04:10-- https://download.cf.centos.org/centos/7/updates/x86_64/Packages/tzdata-2022g-1.el7.noarch.rpm Resolving download.cf.centos.org (download.cf.centos.org)... 2600:9000:24f5:ea00:d:fdf0:9340:93a1, 2600:9000:24f5:9400:d:fdf0:9340:93a1, 2600:9000:24f5:400:d:fdf0:9340:93a1, ... Connecting to download.cf.centos.org (download.cf.centos.org)|2600:9000:24f5:ea00:d:fdf0:9340:93a1|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 501628 (490K) [application/x-rpm] Saving to: ‘tzdata-2022g-1.el7.noarch.rpm’ tzdata-2022g-1.el7.noarch.rpm 100%[================================================>] 489.87K 1.21MB/s in 0.4s 2023-04-04 09:04:12 (1.21 MB/s) - ‘tzdata-2022g-1.el7.noarch.rpm’ saved [501628/501628] tzdata-2022g-1.el7.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY Header SHA1 digest: OK V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY MD5 digest: OK 4af524ef4c3174e29991b9c0e236ba3d89b8d2c935d9359910aca965ba5001ca tzdata-2022g-1.el7.noarch.rpm
it seems that there was already a pkg with same ENVR but for unknown reason, it was rebuilt and pushed. @hughesjr : can you give us some explanations ? See also https://lists.centos.org/pipermail/centos/2023-April/896789.html
it seems that the already built and pushed package was rebuilt and pushed again, but so with different checksum. As it's now solved at the aws cloudfront setup, closing
Metadata Update from @arrfab: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.