Fwd: regression: “guix_ pack” Docker images no longer work on AWS

OpenSubmitted by Ricardo Wurmus.
Details
3 participants
  • Efraim Flashner
  • Ludovic Courtès
  • Ricardo Wurmus
Owner
unassigned
Severity
important
R
R
Ricardo Wurmus wrote on 26 Apr 2021 17:16
Fwd: regression: “guix pack” Docker images no longer work on AWS
(address . bug-guix@gnu.org)
877dkpoz40.fsf@elephly.net
Hi Guix,

I’m using “guix pack”-generated Docker images on AWS ECS. On June
17,
2020 I generated and uploaded an image that works fine. According
to
AWS this image has this manifest type:

application/vnd.docker.distribution.manifest.v2+json

Today I generated a new image that does not work. It cannot be
opened
by ECS; it cannot find /bin/sh, which exists. The manifest type
is now
recognized as

application/vnd.oci.image.manifest.v1+json

It also now detects an “Artifact media type” and prints it as

application/vnd.oci.image.config.v1+json

I’d very much like to push a newly generated image. Is there a
way to
generate the image as it was done in the summer of 2020?

Note that both these images appear to work “fine” with a local
Docker
installation (i.e. when run with “docker run”). (When running
/bin/sh
in the container interactively it appears to freeze whenever I try
to
actually run a command, but perhaps I’m just holding it wrong…)

--
Ricardo
E
E
Efraim Flashner wrote on 27 Apr 2021 08:55
Re: bug#48035: Fwd: regression : “guix pack” Docker images no longer work on AWS
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 48035@debbugs.gnu.org)
YIe1bN7aPJFkr54J@3900XT
On Mon, Apr 26, 2021 at 05:16:15PM +0200, Ricardo Wurmus wrote:
Toggle quote (28 lines)
>
> Hi Guix,
>
> I’m using “guix pack”-generated Docker images on AWS ECS. On June 17,
> 2020 I generated and uploaded an image that works fine. According to
> AWS this image has this manifest type:
>
> application/vnd.docker.distribution.manifest.v2+json
>
> Today I generated a new image that does not work. It cannot be opened
> by ECS; it cannot find /bin/sh, which exists. The manifest type is now
> recognized as
>
> application/vnd.oci.image.manifest.v1+json
>
> It also now detects an “Artifact media type” and prints it as
>
> application/vnd.oci.image.config.v1+json
>
> I’d very much like to push a newly generated image. Is there a way to
> generate the image as it was done in the summer of 2020?
>
> Note that both these images appear to work “fine” with a local Docker
> installation (i.e. when run with “docker run”). (When running /bin/sh
> in the container interactively it appears to freeze whenever I try to
> actually run a command, but perhaps I’m just holding it wrong…)
>

On March 10th, a couple of days before your original message, docker was
updated to 19.03.15 for some security fixes. Perhaps try locally
reverting that and see if it fixes your problem.

--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmCHtWoACgkQQarn3Mo9
g1ECmA//c3TeA3Cv8jMSfBScLLlE7CaOWbnaoGsfIc1TvkVe9hAHSCemyO2Ewy2d
2saDF6XAAfusKtWsbzjcF0vXfONj7QHf7oAw4FaRplzLh9maJ/NhWwe8BEpxd1Jh
nXT6jwbzDOFO2/HYTW1txptvJtswENN2mHwcRYBRphRS3PX7bLok5B2Losl9LNB6
8gg49j0YOnuW90Y5EY1IIEdcWHUnI4Gzvb0PUFSNYOEv7juL+98I3shveX1jSuXU
lNsRYoXSYneIC4oDI74+vGYb2ISrcMtrAHTtvM37q9u6EV32//5lwpt9aH5KYn7G
laf2gzoaDxNdRhh3M1tn/2CsnpDI1/LhmcpIRVxyh+ITJVQLwOeB940wYm/xYdg7
W6bL7nNf+VUWm9xIEF1Cy7U3ZrybqofQsKdmIJ2fxRTK3f1oPwP/1DNTdlBPz5XP
vMSZEAifDZPKGpt2dlv3E3kXWK+ym2H65CYYc22ivNA1lRP9izgnbkZKth4sI0cJ
9kx6o8szkQF4YUpTVPkRBmoZpx2EtFI8Cyi4l61HYqmF4hHv35YljmVw5HhzLEwC
iZbbwzQUsEw5WhTWZr4FmR/0DKRoswW8XaOQyYkrjD/RpJLs8KEB0bIT6VKnpD4B
c7zVKkVrh2YS7Wp+WMh2FTHztXAVm9ir8RLU+Bu7PWufxEMBOmE=
=P6gZ
-----END PGP SIGNATURE-----


R
R
Ricardo Wurmus wrote on 27 Apr 2021 09:48
Re: bug#48035: Fwd: regression: “guix pack” Docker images no longer work on AWS
(name . Efraim Flashner)(address . efraim@flashner.co.il)(address . 48035@debbugs.gnu.org)
87sg3cnp5n.fsf@elephly.net
Hi Efraim,

Toggle quote (5 lines)
> On March 10th, a couple of days before your original message,
> docker was
> updated to 19.03.15 for some security fixes. Perhaps try locally
> reverting that and see if it fixes your problem.

We are not using Docker to generate the Docker images.

I only have problems with the generated Docker images on AWS,
which does not use Docker from Guix.

--
Ricardo
L
L
Ludovic Courtès wrote on 28 Apr 2021 23:29
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 48035@debbugs.gnu.org)
87wnsmp072.fsf@gnu.org
Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (25 lines)
> I’m using “guix pack”-generated Docker images on AWS ECS. On June 17,
> 2020 I generated and uploaded an image that works fine. According to
> AWS this image has this manifest type:
>
> application/vnd.docker.distribution.manifest.v2+json
>
> Today I generated a new image that does not work. It cannot be opened
> by ECS; it cannot find /bin/sh, which exists. The manifest type is
> now
> recognized as
>
> application/vnd.oci.image.manifest.v1+json
>
> It also now detects an “Artifact media type” and prints it as
>
> application/vnd.oci.image.config.v1+json
>
> I’d very much like to push a newly generated image. Is there a way to
> generate the image as it was done in the summer of 2020?
>
> Note that both these images appear to work “fine” with a local Docker
> installation (i.e. when run with “docker run”). (When running /bin/sh
> in the container interactively it appears to freeze whenever I try to
> actually run a command, but perhaps I’m just holding it wrong…)

The Git log of (guix docker) and (guix scripts pack) doesn’t show
anything suspicious.

Could you try generating an image with ‘guix pack’ and feeding it to
Docker using Guix’ Docker service in a VM? Attached is an OS that I
used previously to test Docker things. (You need to run with ‘-m 8192’
or similar so that when you run ‘docker load -i
/gnu/store/…-docker-pack.tar.gz’ the whole VM disk fits into RAM.)

If you used ‘-S /bin=bin’, /bin/sh in the image is a symlink to
/gnu/store/…-bash/bin/sh, an absolute file name that’s only valid within
the image. Perhaps Docker is confused by that like Singularity is/was.
In that case, try changing ‘guix pack’ so it produces relative symlinks
as it already does for the ‘singularity’ backend.

HTH!

Ludo’.
(use-modules (gnu) (srfi srfi-1)) (use-package-modules docker linux) (use-service-modules dbus desktop networking docker) (operating-system (host-name "dockeros") (timezone "Europe/Paris") (locale "fr_FR.utf8") (bootloader (bootloader-configuration (bootloader grub-bootloader) (target "/dev/sdX"))) (file-systems (cons (file-system (device (file-system-label "my-root")) (mount-point "/") (type "ext4")) %base-file-systems)) (users (cons (user-account (name "ludo") (group "users") (supplementary-groups '("wheel")) (password (crypt "foo" "$6$")) (home-directory "/home/ludo")) %base-user-accounts)) (packages (cons* docker-cli singularity %base-packages)) (services (append (list (service docker-service-type) (service dbus-root-service-type) (service elogind-service-type) (service dhcp-client-service-type)) ;; Choose a better console font. (modify-services %base-services (console-font-service-type config => (map (lambda (tty) (cons tty "lat9u-16")) '("tty1" "tty2" "tty3" "tty4" "tty5" "tty6")))))))
L
L
Ludovic Courtès wrote on 30 Apr 2021 17:38
control message for bug #48035
(address . control@debbugs.gnu.org)
87zgxfbx5s.fsf@gnu.org
severity 48035 important
quit
?