I've been messing around with podman in Arch and porting my self-hosted services over to it. However, it's been finicky and I am wondering if anybody here could help me out with a few things.
podman-restart.service
on system reboot. I realized they were the ones that depended on my slow external BTRFS drive. Currently its mounted with x-systemd.automount,x-systemd.device-timeout=5
so that it doesn't hang up the boot if I disconnect it, but it seems like Podman doesn't like this. If I remove the systemd options the containers properly boot up automatically, but I risk boot hangs if the drive ever gets disconnected from my system. I have already tried x-systemd.before=podman-restart.service
and x-systemd.required-by=podman-restart.service
, and even tried increasing the device-timeout to no avail.When it attempts to start the container, I see this in journalctl:
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: libpod-742b4595dbb1ce604440d8c867e72864d5d4ce1f2517ed111fa849e59a608869.scope: Deactivated successfully.
Aug 27 21:15:46 arch-nas conmon[3124]: conmon 742b4595dbb1ce604440 : runtime stderr: error stat'ing file `/external/share`: Too many levels of symbolic links
Aug 27 21:15:46 arch-nas conmon[3124]: conmon 742b4595dbb1ce604440 : Failed to create container: exit status 1
libcrun
and libpod-conmon-.scope
to timeout. Any idea what's causing this? This delay gets pretty annoying especially on an Arch system since I am constantly restarting due to updates.All the containers are started using docker-compose
with podman-docker
if that's relevant.
Any help appreciated!
EDIT: So it seems like podman really doesn't like systemd automount. Switching to nofail, x-systemd.before=podman-restart.service
seems like a decent workaround if anyone's interested.
cross-posted from: https://lemmy.world/post/3754933
While experimenting with ProtonVPN's Wireguard configs, I realized that my real IPv6 address was leaking while IPv4 was correctly going through the tunnel. How do I prevent this from happening?
I've already tried adding
::/0
to theAllowedIPs
option and IPv6 is listed as disabled in the NetworkManager profile.
While experimenting with ProtonVPN's Wireguard configs, I realized that my real IPv6 address was leaking while IPv4 was correctly going through the tunnel. How do I prevent this from happening?
I've already tried adding ::/0
to the AllowedIPs
option and IPv6 is listed as disabled in the NetworkManager profile.
So I have been running into a weird issue lately where if I disconnect a Bluetooth audio device, it will remain visible in the KDE audio mixer. Reconnecting the audio device then adds a duplicate entry and the keyboard volume control for it is completely broken. It stays at the same volume. This was working just fine about a week ago and I've already downgraded pipewire, kpipewire, bluedevil, and plasma-pa to no avail. Nothing shows up in the logs, so I don't know exactly what's causing this bug.
Anyone else experiencing the same thing?
Arch Linux Kernel 6.4.8-arch1-1 Pipewire 0.3.77-1 KDE Plasma: 5.27.7 KDE Frameworks Version: 5.108.0 Qt 5.15.10
EDIT: Seems like simply changing the Bluetooth A2DP audio profile causes this issue as well. I have Bluetooth earbuds that have both AAC and SBC modes and toggling between them just creates more and more duplicate devices with the same name.
THE FIX: Seems like pipewire-pulse
0.3.77 was the culprit after all. Downgrade it to pipewire-pulse 0.3.76 and then do a systemctl --user restart pipewire-pulse
to workaround this issue.
EDIT 2: pipewire-pulse 0.3.77-2 has the patch backported. Feel free to update to latest version in Arch repos.
Relevant bug report: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3414
I am subscribed to this community from Lemmy and the icon is broken. I don't even see it on kbin.social fedia.io. Let's get our favorite mascot back!
Here's what it looks like from lemmy.world:
EDIT: If the icon is working for you, either your browser or your instance may be caching the icon and thereby hiding the issue.
EDIT 2: Icon seems to be working now! Thanks mods!
https://youtu.be/SrQlGdoGUko
ВІіzzаrd explains why they can't fix DіаbІо 4.► Aѕmоngold'ѕ Twitch: https://www.twitch.tv/zackrawrr► Aѕmоngold'ѕ Twitter: https://twitter.com/aѕmоngold► Aѕmо...
I tried both Mullvad and Mozilla VPN and when I do a dns test, both are still using my ISP's DNS instead of the VPN's. This only happens on my Arch systems, works fine on my phone.
EDIT: Turns out these VPN clients depend on systemd-resolved in order to change your DNS. Enabling the service makes it work properly. A bit scary that they don't give you a warning that you're leaking DNS if you don't have systemd-resolved enabled.
I am in the process of making a DIY NAS box and I am debating between mdadm + BTRFS and ZFS. What are your experiences with using ZFS on Arch? Have you run into any major issues? Does ZFS being an external kernel module cause any annoyances with the frequent Arch kernel updates?
Give me the dirty details! Any recommendations or pitfalls I should avoid?
Thanks!
cross-posted from: https://lemmy.world/post/1313651
Every time I plug in my Quadcast S USB mic into my Arch Linux box, I can't properly go into deep sleep. Unplugging it before attempting to sleep makes it work again, but its annoying to have to do that every time. How do I debug this and where do I even submit a bug report for this?
Here's the relevant journalctl:
Jul 10 11:59:39 systemd[1]: Starting System Suspend... Jul 10 11:59:39 systemd-sleep[70254]: Entering sleep state 'suspend'... Jul 10 11:59:39 kernel: PM: suspend entry (deep) Jul 10 11:59:39 kernel: Filesystems sync: 0.066 seconds Jul 10 11:59:42 kernel: Freezing user space processes Jul 10 11:59:42 kernel: Freezing user space processes completed (elapsed 0.001 seconds) Jul 10 11:59:42 kernel: OOM killer disabled. Jul 10 11:59:42 kernel: Freezing remaining freezable tasks Jul 10 11:59:42 kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds) Jul 10 11:59:42 kernel: printk: Suspending console(s) (use no_console_suspend to debug) Jul 10 11:59:42 kernel: serial 00:04: disabled Jul 10 11:59:42 kernel: sd 2:0:0:0: [sdb] Synchronizing SCSI cache Jul 10 11:59:42 kernel: sd 1:0:0:0: [sda] Synchronizing SCSI cache Jul 10 11:59:42 kernel: sd 5:0:0:0: [sdc] Synchronizing SCSI cache Jul 10 11:59:42 kernel: sd 1:0:0:0: [sda] Stopping disk Jul 10 11:59:42 kernel: sd 2:0:0:0: [sdb] Stopping disk Jul 10 11:59:42 kernel: sd 5:0:0:0: [sdc] Stopping disk Jul 10 11:59:42 kernel: ACPI: PM: Preparing to enter system sleep state S3 Jul 10 11:59:42 kernel: ACPI: PM: Saving platform NVS memory Jul 10 11:59:42 kernel: Disabling non-boot CPUs ... Jul 10 11:59:42 kernel: Wakeup pending. Abort CPU freeze Jul 10 11:59:42 kernel: Non-boot CPUs are not disabled Jul 10 11:59:42 kernel: ACPI: PM: Waking up from system sleep state S3 Jul 10 11:59:42 kernel: sd 5:0:0:0: [sdc] Starting disk Jul 10 11:59:42 kernel: sd 2:0:0:0: [sdb] Starting disk Jul 10 11:59:42 kernel: sd 1:0:0:0: [sda] Starting disk Jul 10 11:59:42 kernel: serial 00:04: activated
Thanks in advance!
Every time I plug in my Quadcast S USB mic into my Arch Linux box, I can't properly go into deep sleep. Unplugging it before attempting to sleep makes it work again, but its annoying to have to do that every time. How do I debug this and where do I even submit a bug report for this?
Here's the relevant journalctl:
Jul 10 11:59:39 systemd[1]: Starting System Suspend...
Jul 10 11:59:39 systemd-sleep[70254]: Entering sleep state 'suspend'...
Jul 10 11:59:39 kernel: PM: suspend entry (deep)
Jul 10 11:59:39 kernel: Filesystems sync: 0.066 seconds
Jul 10 11:59:42 kernel: Freezing user space processes
Jul 10 11:59:42 kernel: Freezing user space processes completed (elapsed 0.001 seconds)
Jul 10 11:59:42 kernel: OOM killer disabled.
Jul 10 11:59:42 kernel: Freezing remaining freezable tasks
Jul 10 11:59:42 kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
Jul 10 11:59:42 kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Jul 10 11:59:42 kernel: serial 00:04: disabled
Jul 10 11:59:42 kernel: sd 2:0:0:0: [sdb] Synchronizing SCSI cache
Jul 10 11:59:42 kernel: sd 1:0:0:0: [sda] Synchronizing SCSI cache
Jul 10 11:59:42 kernel: sd 5:0:0:0: [sdc] Synchronizing SCSI cache
Jul 10 11:59:42 kernel: sd 1:0:0:0: [sda] Stopping disk
Jul 10 11:59:42 kernel: sd 2:0:0:0: [sdb] Stopping disk
Jul 10 11:59:42 kernel: sd 5:0:0:0: [sdc] Stopping disk
Jul 10 11:59:42 kernel: ACPI: PM: Preparing to enter system sleep state S3
Jul 10 11:59:42 kernel: ACPI: PM: Saving platform NVS memory
Jul 10 11:59:42 kernel: Disabling non-boot CPUs ...
Jul 10 11:59:42 kernel: Wakeup pending. Abort CPU freeze
Jul 10 11:59:42 kernel: Non-boot CPUs are not disabled
Jul 10 11:59:42 kernel: ACPI: PM: Waking up from system sleep state S3
Jul 10 11:59:42 kernel: sd 5:0:0:0: [sdc] Starting disk
Jul 10 11:59:42 kernel: sd 2:0:0:0: [sdb] Starting disk
Jul 10 11:59:42 kernel: sd 1:0:0:0: [sda] Starting disk
Jul 10 11:59:42 kernel: serial 00:04: activated
Thanks in advance!
@Molecular0079
@lemmy.world