I thought I’d share my experience doing this, as it was quite a pain, and maybe this will help someone else. It contains the process I took to set it all up, and the workarounds, and solutions that I found along the way.

  1. Hardware that I used: Raspberry Pi 1 Model B rev 2.0, SanDisk Ultra SD Card (32GB).
  2. I had issues using the Raspberry Pi Imager (v1.8.5, Flatpak): It initially flashed pretty quickly, but the verification process was taking an unreasonably long time — I waited ~30mins before giving up, and cancelling it; so, I ended up manually fashing the image to the SD card:
    1. I connected the SD card to a computer (running Arch Linux).
    2. I located what device corresponded to it by running lsblk (/dev/sdd, in my case).
    3. I downloaded the image from here. I specifically chose the “Raspberry Pi OS Lite” option, as it was 32-bit, it had Debian Bookworm, which was the version needed for podman-compose (as seen here), and it lacked a desktop environment, which I wanted, as I was running it headless.
    4. I then flashed the image to the SD card with dd if=<downloaded-raspbian-image> of=<drive-device> BS=50M status=progress
      • <downloaded-raspbian-image> is the path to the file downloaded from step 3.
      • <drive-device> is the device that corresponds to the SD card, as found in step 2.2.
      • BS=50M I found that 50M is an adequately sized buffer size. I tested some from 1M to 100M.
      • status=progress is a neat option that shows you the live status of the command’s execution (write speed, how much has been written, etc.).
  3. I enabled SSH for headless access. This was rather poorly documented (which was a theme for this install).
    1. To enable SSH, as noted here, one must put an empty file named ssh at the “root of the SD card”. This is, unfortunately, rather misleading. What one must actually do is put that file in the root of the boot partition. That is not to say the directory /boot contained in the root partition, rootfs, but, instead, it must be placed within the boot partition, bootfs (bootfs, and rootfs are the two partitions written to the SD card whe you flash the downloaded image). So the proper path would be <bootfs>/ssh. I simply mounted bootfs within my file manager, but, without that, I would have had to manually locate which partition corresponded to that, and mount it manually to be able to create the file. The ownership of the file didn’t seem to matter — it was owned by my user, rather than root (as was every other file in that directory, it seemed).
    2. One must then enable password authentication in the SSH daemon, otherwise one won’t be able to connect via SSH using a password (I don’t understand why this is not the default):
      1. Edit <bootfs>/etc/ssh/sshd_config
      2. Set PasswordAuthentication yes (I just found the line that contained PasswordAuthentication, uncommented the line, and set it to yes).
  4. I changed the hostname by editing <rootfs>/etc/hostname and replacing it with one that I wanted.
  5. I created a user (the user is given sudo priveleges automatically)
    1. Create a file at <bootfs>/userconf.txt — that is, create a file named userconf.txt in the bootfs partition (again, poorly documented here).
    2. As mentioned in that documentation, add a single line in that file of the format `<username>:<password>, where
      • <username> is the chosen username for the user.
      • <password> is the salted hash of your chosen password, which is generated by running openssl passwd -6 and following its prompts.
  6. Plug the SD card into the Pi, plug in power, and wait for it to boot. This is an old Pi, so it takes a good minute to boot fully and become available. You can ping it with ping <hostname>.local to see when it comes online (where <hostname> is yor chosen hostname).
  7. SSH into the Pi with ssh <username>@<hostname>.local (You’ll of course need mDNS, like Avahi, setup on your device running SSH).
  8. Make sure that everything is updated on the Pi with sudo apt update && sudo apt upgrade
  9. Install Podman with sudo apt install podman (the socket gets automatically started by apt).
  10. Install Podman Compose with sudo apt install podman-compose.
  11. Create the compose file compose.yaml. Written using the official as reference, it contains the following:
version: "3"
services:
  pihole:
    container_name: pihole
    image: docker.io/pihole/pihole:latest
    ports:
      - "<host-ip>:53:53/tcp"
      - "<host-ip>:53:53/udp"
      - "80:80/tcp"
    environment:
      TZ: '<your-tz-timezone>'
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
  • <host-ip> is the ip of the device running the container. The reason for why this is needed can be found in the solution of this post.
  • <your-tz-timezone> is your timezone as listed here.
  • For the line that contains image: docker.io/pihole/pihole:latest, docker.io is necessary, as Podman does not default to using hub.docker.com.
  • Note that there isn’t a restart: unless-stopped policy. Apparently, podman-compose currently doesn’t support restart policies. One would have to create a Systemd service (which I personally think is quite ugly to expect of a user) to be able to restart the service at boot.
  1. (NOTE: if you wan’t to skip step 13, run this command as sudo) Pull the image with podman-compose --podman-pull-args="--arch=arm/v6" pull
    • --podman-pull-args="--arch=arm/v6" is necessary as podman-compose doesn’t currently support specifying the platform in the compose file.
      • Specifying the architecture itself is required as, from what I’ve found, Podman appears to have a bug where it doesn’t properly recognize the platform of this Pi, so you have to manually specify which architecture that it is i.e. armv6 (you can see this architecture mentioned here under “latest”).
    • This took a little while on my Pi. The download rate was well below my normal download rate, so I assume the single threaded CPU is just being too bogged down to handle a high download rate.
    • Don’t be concerned if it stays at the “Copying blob…” phase for a while. This CPU is seriously slow.
  2. Allow podman to use ports below 1024, so that it can run rootless:
    • Edit /etc/sysctl.conf, and add the line net.ipv4.ip_unprivileged_port_start=53. This allows all non-priveleged users to access ports >=53. Not great, but it’s what’s currently needed. You can avoid this step by running step 12, and 14 as sudo.
    • Apply this with sysctl -p
  3. (NOTE: if you wan’t to skip step 13, run this command as sudo) Start the container with podman-compose up -d.
    • It will take a while to start. Again, this Pi is slow.
    • Don’t worry if podman-compose ps shows that the container is “unhealthy”. This should go away after about a minute, or so. I think it’s just in that state while it starts up.
  4. Access the Pihole’s admin panel in a browser at http://<host-ip>/admin.
    • The password is found in the logs. You can find it with podman-compose logs | grep random. The password is randomly generated everytime the container starts. If you want to set your own password, then you have to specify it in the compose file as mentioned here.
  • AggressivelyPassive@feddit.de
    link
    fedilink
    English
    arrow-up
    11
    arrow-down
    1
    ·
    10 months ago

    Given the extremely limited resources: why bother with containers? You’re not going to run many other services anyway.

    • Static_Rocket@lemmy.world
      link
      fedilink
      English
      arrow-up
      10
      arrow-down
      1
      ·
      10 months ago

      You say that like there a large overhead to containers…

      Even in this case that overhead is negligible. Container configs and artifacts are also more portable and easier to backup.

      • AggressivelyPassive@feddit.de
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        1
        ·
        10 months ago

        It’s a raspberry pi 1. Those things have 256mb of RAM and you simply won’t do much porting around pihole.

        Containers do have limitations, and this is one.

        • Kalcifer@sh.itjust.worksOP
          link
          fedilink
          English
          arrow-up
          2
          ·
          10 months ago

          It’s a raspberry pi 1. Those things have 256mb of RAM

          The exact model that I am using, which I referenced in my post, actually has 512MB of RAM.

    • Kalcifer@sh.itjust.worksOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      10 months ago

      Given the extremely limited resources: why bother with containers?

      While, from what I can see, containers virtually don’t add any resource overhead, it’s honestly moreso that I favor consistency. Containerization is well documented, it is well supported, and its behaviour (if one is familiar with the platform) tends to be more predictable than running a service natively.

    • Trainguyrom@reddthat.com
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      1
      ·
      9 months ago

      Containers are great for consistency with web services, and help with avoiding (and providing an easy rollback in the case of) breakage with updates

  • Trainguyrom@reddthat.com
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    9 months ago

    This is a great writeup of errata related to this configuration! I am curious what kind of performance you’re seeing for DNS requests considering how old and anemic the first gen Pi is

    • Kalcifer@sh.itjust.worksOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      9 months ago

      I am curious what kind of performance you’re seeing for DNS requests considering how old and anemic the first gen Pi is

      I haven’t done any rigorous tests to gather empirical data for an accurate comparison, but, annectdotally, it, at least, doesn’t feel any slower than when I had my router (Linksys E8450) resolving to Cloudflare.

  • mikezane@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    10 months ago

    Now that it is up and running, do you think it’s is a good service? While you may not like the setup, do you enjoy the results?

    • Kalcifer@sh.itjust.worksOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      10 months ago

      Now that it is up and running, do you think it’s is a good service?

      That’s a good question. The service itself is well made — it functions as advertised, it has satisfactorily intuitive UX, a sizeable community, and a good amount of documentation. I’m not sure, yet, if it’s a service that I personally need — I set it up mostly for the benefit of others.

      While you may not like the setup

      The main pain points were the sparse, vague, and misleading documentation that I encountered — I understand that documentation is difficult, but for a company like Raspberry Pi, my standards, and expecations are quite a bit higher. I probably won’t use Podman anymore, as I don’t find its setup overly user friendly, currently, as compared to something like docker. I had never used Podman before, and I was considering switching my existing services over to it, so this was sort of meant to be a trial run on something with little impact. I will keep an eye on Podman, but I will stick with Docker for the time being.

      do you enjoy the results?

      I personally don’t notice its effects as much, but I do like what I’m seeing for others. It has also made me aware of some other issues that I’ll have to look into, so that is good.

      • mikezane@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        10 months ago

        Thank you, I am thinking of seeing one up to, also mostly for my family rather than myself.

  • mb_@lemm.ee
    link
    fedilink
    English
    arrow-up
    2
    ·
    9 months ago

    It is nice that you got it running, but when everything you end up doing is running services in low ports or needing specific IP address in different networks, rootless podman is just a PITA.

    In my case I have one pihole running on a docker container and another one that runs directly on a VM.

    Someone said before “what’s the point of running in a container”… Well, there really isn’t any measurable overhead and you have the benefit of having a very portable configuration.

    I do think the compromises one has to go through for podman rootless are not worth in this case, for me, not even the rootful worked properly (a few years ago), but this is a nice walkthrough for people wanting to understand more.