hyperkube-base: perform magic COPY incantation to make apt-get update work properly #67215
Conversation
k8s-ci-robot
added
release-note-none
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ixdy The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
|
/assign @tallclair @satyasm |
|
@ixdy: GitHub didn't allow me to assign the following users: satyasm. Note that only kubernetes members and repo collaborators can be assigned. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
cc @dims |
|
/close @BenTheElder figured out what was wrong (after I started at this for an hour+): I'm guessing when 0.3.1 was built, a restrictive |
|
awesome, thanks for investigating. Once that's fixed, can we remove the duplicate copy from debian-iptables too? |
|
yep, I folded that into my fix PR (#67222). |
Automatic merge from submit-queue (batch tested with PRs 67058, 67083, 67220, 67222, 67209). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Fix permissions of qemu-ARCH-static in debian-base and other images **What this PR does / why we need it**: proper fix for the issue I found in #67215. Some machines (like apparently workstations at Google) have a restrictive umask, so the `qemu-ARCH-static` binaries were getting installed in images without world read/execute permissions, causing utilities like `apt-get` to fail. There was also a duplicate download/install of these binaries for `debian-iptables`, which further confused the issue. I've since removed that duplicate installation. Many thanks to @BenTheElder for asking the right question to get me to look at the permissions again. I haven't pushed any images yet. After merge, I'll build/promote `debian-base:0.3.2`, then update everything to use it, then push some more images, write some more PRs, ... **Release note**: ```release-note NONE ``` /assign @tallclair
This PR seriously bothers me.
I've attempted to build a new release of the
debian-hyperkube-baseimages (after #67026), but I'm unable to cross-build any of the non-amd64 images, while thedebian-iptablesimages build without issue.The errors were around signatures on the apt repositories:
Through trial and error, I discovered that the only difference between the
debian-iptablesimage builds anddebian-hyperkube-basebuilds were that the iptables builds download theqemu-ARCH-staticbinaries andCOPYthem into the container.The
qemu-ARCH-staticbinaries already exist in the base image (debian-base), and the version, permissions, sha256sum, and other metadata are unchanged. Somehow copying it again (via theCOPYdirective) matters.If I
COPYto some other path, it doesn't work.For even more spookiness, building the hyperkube-base image from
debian-base:0.3works without issue.If I remove the
COPYlines from thedebian-iptablesDockerfile, I can't build that image anymore.Release note: