shouldn't the current directory be the default context for "podman build"?
by Robert P. J. Day
"man podman-build" suggests that the context argument is optional:
SYNOPSIS
podman build [options] [context]
podman image build [options] [context]
...
If no context directory is specified, then Podman will assume
the current working directory as the build context, which
should contain the Containerfile.
but if i have a directory with nothing but a Containerfile, i get:
$ podman build
Error: no context directory specified, and no containerfile specified
$
OTOH, specifying context of current directory:
$ podman build .
STEP 1: FROM alpine:latest
... etc etc ...
thoughts?
rday
1 week, 4 days
stopping podman container
by Matthias Apitz
Hello,
I'm facing the following small issue while stopping a podman container
on RedHat 8.9 and SuSE SLES 15SP4. Inside the container runs also a
SuSE SLES 15SP4:
$ podman run -d -p 2022:22 -p 28076:8076 -p 23045:3045 7c180cc3c676
c408e9d468cdebbc11a2d974ccf40e315fa724ada702e713359019a25b2b6882
...
$ podman stop c408e9d468cdebbc11a2d974ccf40e315fa724ada702e713359019a25b2b6882
WARN[0010] StopSignal SIGQUIT failed to stop container vibrant_bartik in 10 seconds, resorting to SIGKILL
c408e9d468cdebbc11a2d974ccf40e315fa724ada702e713359019a25b2b6882
The Dockerfile which is used to build the container end with:
$ tail -5 suse/Dockerfile
EXPOSE 22 8076 3045
ENTRYPOINT /usr/local/bin/start.sh
STOPSIGNAL SIGQUIT
Any ideas what I do wrong?
matthias
--
Matthias Apitz, ✉ guru(a)unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia. Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.
10 months
podman stop -t -1 container-id issue
by Manvendra Bhangui
Hi,
I have a container where I have my own program as init replacement. It
takes the responsibility of shutting down all my services properly (one of
them being MySQL). Sometimes some services need more than the default 10
seconds that podman stop command has before it resorts to SIGKILL.
So while playing with various timeout, I get a strange result with I use -1
(supposed to be for infinite wait). Giving -1 results in immediate SIGKILL
$ podman stop -t -1 indimail-mta
WARN[0000] StopSignal SIGTERM failed to stop container indimail-mta in
18446744073709551615 seconds, resorting to SIGKILL
indimail-mta
Looks like unsigned 64 bit integer has been used for something which can
have negative value
--
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
10 months
Podman on OpenWrt: Required dependency package kernel is not available in any repository.
by Nayla Nikolic
Hi
I try to install podman on OpenWrt. Sadly there is no guide in official
docs. Please update the docs.
# Error
Executing package manager
Installing podman (4.8.0-1) to root...
Downloading
https://downloads.openwrt.org/releases/23.05.0/packages/aarch64_generic/p...
Errors
Collected errors:
* pkg_hash_check_unresolved: cannot find dependency kernel (=
5.15.134-1-a61b316e83bc33130e55f5c8b8b65f74) for kmod-veth
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-veth
found, but incompatible with the architectures configured
* satisfy_dependencies_for: Cannot satisfy the following dependencies
for podman:
* kernel (= 5.15.134-1-a61b316e83bc33130e55f5c8b8b65f74)
* opkg_install_cmd: Cannot install package podman.
# Infos about my system:
Model FriendlyElec NanoPi R4S
Architecture ARMv8 Processor rev 4
Target Platform rockchip/armv8
Firmware Version OpenWrt 23.05.0 r23497-6637af95aa / LuCI openwrt-23.05
branch git-23.236.53405-fc638c8
Kernel Version 5.15.134
best regards
Nayla
10 months
buildah push xxxxx docker-daemon:image:tag error
by Михаил Иванов
Hallo,
When I try to push an image, created with buildah directly to docker,
it aborts with following error:
Error: pushing image "5d0da3dc9764" to "docker-daemon:test:2.0.0": writing blob: io: read/write on closed pipe
No errors are logged by dockerdaemon.
When I check what happens with strace, I see that it aborts on epoll_ctl error:
epoll_ctl(4, EPOLL_CTL_ADD, 7, {events=EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, data={u32=4150263831, u64=9210128152865538071}}) = -1 EPERM
7 is file descriptor which refers to some file under /var/lib/containers
(/var/lib/containers/storage/overlay-images/5d0da3dc976460b72c77d94c8a1ad043720b0416bfc16c52c45d4847e53fadb6/manifest)
Is this supposed to work or do I misunderstand sthing?
Best regards,
--
Michael Ivanov
10 months, 1 week
GPU devices in rootless
by lejeczek
Hi guys
I have _rootless_ container with PyTorch from ROCm
-> $ { export _NAME="pytorch_rocm"; export
_PATH=${HOME}/containers/FLATfiles/${_NAME}; echo; mkdir -p
${_PATH}/{,root,dockerx}; }; podman run -dt
--device=/dev/kfd --device=/dev/dri --group-add video
--shm-size 8G --security-opt seccomp=unconfined --volume
${_PATH}/root:/root:z --volume ${_PATH}/dockerx:/dockerx:z
-w /dockerx --name ${_NAME/\//_} rocm/pytorch:latest
which fails to:
root@4bc3c2ec2ab3:/dockerx# python3 -c 'import torch;
print(torch.cuda.is_available())'
False
Such _rootful_ container seems a okey but rootless "suffers"
such failures due to SELinux denials I think:
...
SELinux is preventing /opt/conda/envs/py_3.9/bin/python3.9
from 'read, write' accesses on the chr_file kfd. For
complete SELinux messages run: sealert -l
6b3db344-2ffc-4ecd-aa2c-2c1a2bfe23e4
SELinux is preventing /opt/conda/envs/py_3.9/bin/python3.9
from 'read, write' accesses on the chr_file kfd.
Would you know if this can be fixed, possibly without
building extra SE module(s)?
many thanks, L.
10 months, 1 week
ran out of storage - data lingers behind?
by lejeczek
Hi guys.
Deploying a container I ran of local storage space & process
failed - I see no new images nor container - yet disk space
resulted being more occupied.
I see _/var/lib/containers/storage/overlay_ being 21G large
with, with my only freeIPA container makes little sense -
there I looked first.
How to clean such "unfortunate" case?
many thanks, L.
10 months, 1 week
Podman v4.9.1 Released
by Ashley Cui
We’re excited to announce that Podman v4.9.1 has been released! This
release includes several AppleHV bugfixes, and includes an important update
to the QEMU version in the Mac pkginstaller. Here's what's new:
Bugfixes
- Fixed a bug where the --rootful option to podman machine set would not
set the machine to use the root connection (#21195
<https://github.com/containers/podman/issues/21195>).
- Fixed a bug where podman would crash when running in a containerized
environment with euid != 0 and capabilities set (#20766
<https://github.com/containers/podman/issues/20766>).
- Fixed a bug where the podman info command would crash on if called
multiple times when podman was running as euid=0 without CAP_SYS_ADMIN (
#20908 <https://github.com/containers/podman/issues/20908>).
- Fixed a bug where podman machine commands were not relayed to the
correct machine on AppleHV (#21115
<https://github.com/containers/podman/issues/21115>).
- Fixed a bug where the podman machine list and podman machine
inspect commands
would not show the correct Last Up time on AppleHV (#21244
<https://github.com/containers/podman/issues/21244>).
Misc
- Updated the Mac pkginstaller QEMU to v8.2.1
- Updated Buildah to v1.33.4
- Updated the containers/image library to v5.29.2
- Updated the containers/common library to v0.57.3
Try it out and let us know what you think!
--
Ashley Cui
10 months, 3 weeks
