Closed lfarkas closed 4 years ago
Adding --log-level=debug
to the command line might help.
@TomSweeneyRedHat PTAL
do we have https://github.com/containers/buildah/pull/2072 in the vendored copy?
ok it's build, but the build takes about a halfen hour while it was about a minutes in the previous version. from the --log-level=debug the build is full of (for all file):
DEBU[0030] error closing backward: invalid argument
The Buildah copy fix will be in 1.7.1, but we should get this out ASAP. @mheon can we cut a new release?
Uh. Let's give it a few days and do it while we have everyone in the Brno office.
@rhatdan do you suspect this was cured by the Overlayv2 fix in c/storage that went into Buildah this weekend? @lfarkas, if so, any chance you could try upstream Buildah?
i can try anything if you give me an rpm/binary and or command to test
@lfarkas could you share your Dockerfile as a reproducer? This would simplify checking if your issue has been solved.
the dockerfile itself is very simple or actually large but everything run fast but the relevant part is only one line:
COPY . .
which try to copy the generated laravel/php code into the image and during the copy it's full of errors like this:
DEBU[0002] copyFileWithTar(/home/lfarkas/work/develnet/hostop/hostop/webadmin/public/vendor/backpack/bootstrap-iconpicker/icon-fonts/font-awesome-4.3.0/css/font-awesome.css, /home/lfarkas/.local/share/containers/storage/overlay/23455afa8df20434492a450d7fdc42d447735c4ce6c92cfdcbc5fb6b63687712/merged/public/vendor/backpack/bootstrap-iconpicker/icon-fonts/font-awesome-4.3.0/css/font-awesome.css)
DEBU[0002] error closing font-awesome.css: invalid argument
DEBU[0002] copyFileWithTar(/home/lfarkas/work/develnet/hostop/hostop/webadmin/public/vendor/backpack/bootstrap-iconpicker/icon-fonts/font-awesome-4.3.0/css/font-awesome.min.css, /home/lfarkas/.local/share/containers/storage/overlay/23455afa8df20434492a450d7fdc42d447735c4ce6c92cfdcbc5fb6b63687712/merged/public/vendor/backpack/bootstrap-iconpicker/icon-fonts/font-awesome-4.3.0/css/font-awesome.min.css)
DEBU[0002] error closing font-awesome.min.css: invalid argument
DEBU[0002] copyFileWithTar(/home/lfarkas/work/develnet/hostop/hostop/webadmin/public/vendor/backpack/bootstrap-iconpicker/icon-fonts/font-awesome-4.3.0/fonts, /home/lfarkas/.local/share/containers/storage/overlay/23455afa8df20434492a450d7fdc42d447735c4ce6c92cfdcbc5fb6b63687712/merged/public/vendor/backpack/bootstrap-iconpicker/icon-fonts/font-awesome-4.3.0/fonts)
DEBU[0002] copyFileWithTar(/home/lfarkas/work/develnet/hostop/hostop/webadmin/public/vendor/backpack/bootstrap-iconpicker/icon-fonts/font-awesome-4.3.0/fonts/FontAwesome.otf, /home/lfarkas/.local/share/containers/storage/overlay/23455afa8df20434492a450d7fdc42d447735c4ce6c92cfdcbc5fb6b63687712/merged/public/vendor/backpack/bootstrap-iconpicker/icon-fonts/font-awesome-4.3.0/fonts/FontAwesome.otf)
DEBU[0002] error closing FontAwesome.otf: invalid argument
DEBU[0002] copyFileWithTar(/home/lfarkas/work/develnet/hostop/hostop/webadmin/public/vendor/backpack/bootstrap-iconpicker/icon-fonts/font-awesome-4.3.0/fonts/fontawesome-webfont.eot, /home/lfarkas/.local/share/containers/storage/overlay/23455afa8df20434492a450d7fdc42d447735c4ce6c92cfdcbc5fb6b63687712/merged/public/vendor/backpack/bootstrap-iconpicker/icon-fonts/font-awesome-4.3.0/fonts/fontawesome-webfont.eot)
DEBU[0002] error closing fontawesome-webfont.eot: invalid argument
and it takes very long time. since there are 26180 files in the directory. if i leave it there it can finish...once:-) real 28m9.044s user 18m19.830s sys 16m43.759s and almost all time spend in the copy command.
if you need a real example just use this demo: https://github.com/Laravel-Backpack/Demo
@TomSweeneyRedHat @rhatdan, do we need to do the vendor dance before or are we good to test with the latest master?
I don't think we have an updated Buildah landed.
If the c/storage fix fixed the issue, we won't have that until Buildah 1.13.2+ lands. That's a WIP atm. So we are still doing the vendor dance here.
We have issues with buildah vendoring into Podman, due to the containers.conf merger into Buildah. I am working on reverting/fixing some issues on this now, Hopefully this will get merged fairly quickly. But I would rather not rush containers.conf buildah out right now.
I was able to work around this issue in Fedora 31 by installing the buildah
package, which as I understand it is then used by an installed podman
package.
It is not really used, it is more embedded. Basically Podman uses the buildah code like a shared library inside of itself, it does NOT execute the Buildah command or need Buildah installed.
it's still not working (ie very slow) with 1.8.0
@nalind FYI
Since this is a well known buildah issue, I am going to close this and hope that this gets fixed in Buildah soon and then Podman gets the update.
it's nice that you close it but after 2 month it's still not fixed and not working on fedora:-(
@lfarkas If this is not working in Buildah please open a bug over there.
There is an ongoing rewrite of copy in buildah going on. We have lots of issues/complaints about copy being too slow. We have fixed a few, but @nalind Thinks that a full rewrite is necessary and he has been working on it. Hopefully we will have something soon.
@lfarkas If this is not working in Buildah please open a bug over there.
it's not working in podman build (since most people use it). what's a it's a regression since it was working in 1.4.4 el7!
what's more even if the v1.8.2 release notes said: Updated Buildah to v1.14.3 it's still not working.
Do we have an issue about this on the Buildah side? @rhatdan @TomSweeneyRedHat
If not we should get one written
I'm not sure if we have a particular issue in the Buildah issues, but it's a problem that's also been reported via Bugzilla and @nalind has been diligently working on it.
Basically, I want a tracker issue that we can point people to, that will be closed when this is actually done and released. If we have a public BZ about that, that ought to be fine.
The BZ is at: https://bugzilla.redhat.com/show_bug.cgi?id=1756986 which is based off of https://github.com/containers/buildah/issues/1714
The BZ is at: https://bugzilla.redhat.com/show_bug.cgi?id=1756986 which is based off of containers/buildah#1714
which is totally false! since it's was closed as "Fixed in buildah-1.11.2-2" but still not working with buildah-1.14.3-1.fc31.x86_64
@nalind PTAL
it's still not fixed and still not working in podman-2.0.2-1.fc32.x86_64. why did you close it???
If it's not working, please open a fresh issue against Buildah, given this is a bug in Buildah code.
ok i know that all go code is statically linked. and podman is bad because of buildah, BUT still it's a podman bug! if I try to build with podman it's not working. and I do NOT really case about when will be it fixed in buildah. since even if it's fixed in buildah and do not fixed in podman then it's still a bug in podman. so please reopen this bug against podman until podman use such a version of buildah which fix this bug. what's more it's a regression since it was working in a earlier version and it's no longer works!
imho it's a same bug if I a program link against a wrong version of openssl and it's not working properly it's still bug in the given program.
@lfarkas At this point I am confused about what this issue is? If it is Podman build is slow when you use COPY command have a huge amount of files and are using a .dockerignore then that is fine, and is being worked on. That has existed since the beginning of Buildah and Podman, so I don't see this as a regression. If you are talking about something else, then perhaps we need a new issue. Bottom line is that having an open issue here on podman build is not going to be effective. Opening the issue in buildah bud would lead to a fix and then the fix will get vendored into Podman.
@lfarkas We use Buildah code for Podman build, but most Podman developers are not Buildah developers; if you file the bug here, all we'll do is ask the Buildah developers to look at it, and then they will probably transfer the bug over to their repo. Creating it there skips a great many steps and will make the process faster and easier for everyone.
The exception would be if you confirm that it is fixed with the latest buildah
but is still broken on Podman. In that case, it's definitely our problem, maybe a too-old version? At this point, I don't think we've confirmed that the bug is actually present/not present in Buildah.
with the latest fedora podman-1.7.0-2.fc31.x86_64 update podman build no longer works ie, it's hang in a copy command:
forever. it's start to get really annoying that none of the latest fedora podman build working (the previous totally ignore .dockerignore which result a catastrophic images).
is there any way to debug what's happening or in what it's hang?