Closed M1cha closed 2 years ago
I can reproduce it with 4.3.0 but it is fixed upstream with 6fe64591d630f6f532f6233c4ea8c97f79809797
@giuseppe When will the next release be? Technically this is a bug and should be fixed in 4.3 but given that we don't know what fixed it and that commit updated a lot of dependencies it'll probably only arrive in the next minor or major release which can be months apart.
Target is late January, with RCs beginning in early January.
In that case I'll want to invest time into figuring out how to build podman for fedora coreOS (rpm-ostree).
a 30minute google search lets me believe that this is non-trivial - let alone cross-compiling for aarch64. There was a tutorial but it seems very outdated: https://podman.io/blogs/2018/11/19/build_libpod-container-images.html
I know this is off-topic but since I've already mentioned it, here are the steps to cross-compile from x64 to aarch64 on fedora
This takes a long time to build since qemu-user isn't exactly known to be fast :shrug: Create a fedora 37 x86_64 VM, I tried toolbox but it only seems to work without cross-compiling.
$ sudo dnf install git qemu-user-static fedora-packager rpmdevtools gcc
$ rpmdev-setuptree
$ git clone https://src.fedoraproject.org/rpms/podman.git
$ # apply the patch I've attached
$ cd podman
$ spectool -agR podman.spec
$ rpmbuild -bs podman.spec
$ sudo mock -r /etc/mock/fedora-37-aarch64.cfg --rebuild ~/rpmbuild/SRPMS/podman-4.4.0-1.fc37.src.rpm
based on 86969acc658495a3b6f7de27c57dc4b6e60c82dd
diff --git a/podman.spec b/podman.spec
index 97d7fa4..adab288 100644
--- a/podman.spec
+++ b/podman.spec
@@ -29,7 +29,7 @@
%global git_gvproxy https://%{import_path_gvproxy}
%global commit_gvproxy fdc231ae7b8fe1aec4cf0b8777274fa21b70d789
-%global built_tag v4.3.1
+%global built_tag v4.4.0
%global built_tag_strip %(b=%{built_tag}; echo ${b:1})
%global gen_version %(b=%{built_tag_strip}; echo ${b/-/"~"})
@@ -42,7 +42,7 @@ ExclusiveArch: %{golang_arches}
Summary: Manage Pods, Containers and Container Images
URL: https://%{name}.io/
# All SourceN files fetched from upstream
-Source0: %{git0}/archive/%{built_tag}.tar.gz
+Source0: %{git0}/archive/480c7fbf5361f3bd8c1ed81fe4b9910c5c73b186.tar.gz
Source1: %{git_plugins}/archive/%{commit_plugins}/%{repo_plugins}-%{commit_plugins}.tar.gz
Source2: %{git_gvproxy}/archive/%{commit_gvproxy}/%{repo_gvproxy}-%{commit_gvproxy}.tar.gz
Provides: %{name}-manpages = %{epoch}:%{version}-%{release}
@@ -286,8 +286,9 @@ It is based on the network stack of gVisor. Compared to libslirp,
gvisor-tap-vsock brings a configurable DNS server and
dynamic port forwarding.
-%prep
-%autosetup -Sgit -n %{name}-%{built_tag_strip}
+%_topdir /tmp/rpmbuild
+%prep -n %{name}-480c7fbf5361f3bd8c1ed81fe4b9910c5c73b186
+%autosetup -Sgit -n %{name}-480c7fbf5361f3bd8c1ed81fe4b9910c5c73b186
sed -i 's;@@PODMAN@@\;$(BINDIR);@@PODMAN@@\;%{_bindir};' Makefile
# untar dnsname
@@ -329,6 +330,8 @@ export BUILDTAGS="seccomp exclude_graphdriver_devicemapper $(hack/btrfs_installe
%gobuild -o bin/%{name} %{import_path}/cmd/%{name}
+%gobuild -o bin/quadlet %{import_path}/cmd/quadlet
+
# build %%{name}-remote
export BUILDTAGS="seccomp exclude_graphdriver_devicemapper exclude_graphdriver_btrfs btrfs_noversion $(hack/selinux_tag.sh) $(hack/systemd_tag.sh) $(hack/libsubid_tag.sh) remote"
%gobuild -o bin/%{name}-remote %{import_path}/cmd/%{name}
@@ -408,6 +411,9 @@ rm -f %{buildroot}%{_datadir}/user-tmpfiles.d/%{name}-docker.conf
%{_bindir}/%{name}
%dir %{_libexecdir}/%{name}
%{_libexecdir}/%{name}/rootlessport
+%{_libexecdir}/%{name}/quadlet
+%{_systemdgeneratordir}/podman-system-generator
+%{_systemdusergeneratordir}/podman-user-generator
%{_datadir}/bash-completion/completions/%{name}
# By "owning" the site-functions dir, we don't need to Require zsh
%dir %{_datadir}/zsh/site-functions
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description It looks like there's something wrong with the mounts for this specific container. Specifically when the runtime tries to write files like
.containerenv
orresolv.conf
. The error messages differ between runtimes. Also, this only happens with podman running as root.crun + no network:
runc + no network:
crun + default bridge:
runc + default bridge:
Output of
podman version
:Output of
podman info
:Package info (output of
rpm -q podman
:Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?
Yes
Additional environment details (AWS, VirtualBox, physical, etc.): Fedora CoreOS aarch64 bare metal.