Closed cdrage closed 3 weeks ago
Okay further investigation could be pointing towards an issue with podman machine itself rather than bib.
sudo podman run \
--name httpd-bootc-image-builder \
--tty \
--privileged \
--security-opt label=type:unconfined_t \
-v /home/wikus/bootc/test123:/output/ \
-v /var/lib/containers/storage:/var/lib/containers/storage \
--label bootc.image.builder=true \
quay.io/centos-bootc/bootc-image-builder:latest-1720185748 \
quay.io/bootc-extension/httpd:latest \
--output \
/output/ \
--local \
--type \
raw \
--target-arch \
amd64
MAYBE due to https://github.com/containers/podman/pull/22920 @cgwalters but I'm not entire 100% sure yet to diagnose why. It could be due to the switch of the underlying fs system?
MAYBE due to https://github.com/containers/podman/pull/22920 @cgwalters but I'm not entire 100% sure yet to diagnose why. It could be due to the switch of the underlying fs system?
Do you actually have that commit? I think it's more that commit should fix that problem. As for why it started occurring...well, I think what happened is probably a Linux kernel upgrade in Fedora made 9p buggier. I didn't bother investigating deeply (though see e.g. https://github.com/containers/bootc/issues/485#issuecomment-2076127555 where I found a likely commit that caused a different bug on 9p).
IOW: run podman machine ssh findmnt|grep virtiofs
- if that's empty then you don't have the commit, and try upgrading to current git main podman to see if my fix works for you too.
MAYBE due to containers/podman#22920 @cgwalters but I'm not entire 100% sure yet to diagnose why. It could be due to the switch of the underlying fs system?
Do you actually have that commit? I think it's more that commit should fix that problem. As for why it started occurring...well, I think what happened is probably a Linux kernel upgrade in Fedora made 9p buggier. I didn't bother investigating deeply (though see e.g. containers/bootc#485 (comment) where I found a likely commit that caused a different bug on 9p).
IOW: run
podman machine ssh findmnt|grep virtiofs
- if that's empty then you don't have the commit, and try upgrading to current git main podman to see if my fix works for you too.
Doh, you are right. I am using podman 5.0.3
and it's using an older version but with an updated kernel upgrade in the fedora image. Checking findmnt
and it shows 9p.
So your PR is doing the opposite and actually fixing the issue, sorry!
I'm unable to update podman though (not on fedora channels yet) to the latest version which is unfortunate, so I'll just have to wait.
Due to numerous issues, I've opened up https://github.com/containers/podman-desktop-extension-bootc/issues/623 to perhaps move away from podman machine requirement for the bootc extension.
I mentioned this issue here: https://github.com/containers/podman-bootc/pull/58
It was not failing if we connect stdin, but now (in my machine) the error show up again. Btw, I think, bib IS working it's just failing when osbuild calls export, but if you check the output dir the disk image is there.
I mentioned this issue here: https://github.com/containers/podman-bootc/pull/58
It was not failing if we connect stdin, but now (in my machine) the error show up again. Btw, I think, bib IS working it's just failing when osbuild calls export, but if you check the output dir the disk image is there.
Yeah :( the image outputs are okay and myself and another person confirmed it. Just the prevailing output is failing. If anymore users raise the issue I'll make sure to just say that the image is fine and ignore the error (for now).
Closing this here as there's nothing really easily this project can do directly to workaround it and the best fix is just to get the newer podman in the hands of users.
Building any image does not work on Linux at the moment and always ends with an error.
Running Fedora 40. This is used with Podman Machine.
I can confirm this works fine on macOS.
Command to run:
Output: