Add support for the i386 architecture

[static-void-main]

This PR adds support for the i386 architecture.

Description

Adds a new image that is able to run on 32-bit hosts. The image is based on 32-bit versions of debian-debootstrap and S6.

Motivation and Context

Being able to run Pi-hole through Docker on 32-bit machines. The i386 architecture is officially supported on Debian according to Supported Operating Systems.

How Has This Been Tested?

Built and pushed the image to a private Docker Hub repo with Actions. Deployed it to an Atom N280 powered thin client with Docker Compose. Runs great.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[lightswitch05]

To support this, wouldn't the FTL need a corresponding i386 build? Just because the docker image support i386 doesn't mean Pihole itself would run. Right?

https://github.com/pi-hole/docker-base-images/blob/edf2e156c54959cb6c9fb1a679755945892a114e/docker-compose.yaml#L30-L73

[static-void-main]

Hey Daniel! I would think so, and looks like the support is already there https://github.com/pi-hole/docker-base-images/blob/edf2e156c54959cb6c9fb1a679755945892a114e/docker-compose.yaml#L60. Here is what gets downloaded during the build https://github.com/pi-hole/docker-pi-hole/pull/818/checks?check_run_id=2257113716#step:3:2063. Lastly, I can absolutely confirm it is working because this image is currently running on a CPU that has no AMD64 support whatsoever (https://ark.intel.com/content/www/us/en/ark/products/41411/intel-atom-processor-n280-512k-cache-1-66-ghz-667-mhz-fsb.html).

[lightswitch05]

I clearly don't understand all the nuances between x86, i386, etc.

Luckily, me understanding architectures isn't a requirement for PRs. You've done a good job following the same pattern from the other architectures. Unfortunately, you have a conflict, so that will need to be fixed. Also, I think you might be missing a change in here as well?

docker-pi-hole/gh-actions-deploy.sh

Lines 51 to 56 in 731cd5e

	declare -A annotate_map=(
	["amd64"]="--arch amd64"
	["armel"]="--arch arm --variant v6"
	["armhf"]="--arch arm --variant v7"
	["arm64"]="--arch arm64 --variant v8"
	)

Otherwise, I think it will be up to someone else to decide if this is something the project wants to support or not.

[static-void-main]

Good catch regarding gh-actions-deploy.sh, updated that one as well. Thanks!

[lightswitch05]

Looks good to me. I'm unable to test it, and so I would also be unable to support this feature- but all the changes look correct

[DL6ER]

Yes, there is a dedicated i386 build for FTL, see pi-hole/FTL/.circleci/config.yml#L53-L97.

Concerning i386 (note the i) and x86_32:
The Intel 80386, also known as the i386, or just 386, was a 32-bit microprocessor introduced by Intel in 1985. It was succeeded by 486, 586 (aka Pentium) and the rest of the x86 architecture CPUs. But the i386 stuck around as a label and is still sometimes used as an alias to x86. Just like amd64 is used as an alias to x64 architecture, even though there are (obviously) Intel x64 processors as well.

Check out Intel 80386 for more information.

To be independent of vendor-specific names we prefer x86_32 and x86_64 over i386 and amd64 as labels.

[DL6ER]

That being said I should also mention that the end of the 32-bit era is coming closer. Ubuntu/RedHat/SuSe, they all stopped offering 32 bit versions of their operating systems already years ago. IIRC Ubuntu even announced that they will stop supporting 32bit applications on 64bit operating systems.

Debian is like the last garrison for 32-bit operating systems. But even here Wheezy required 486, Jessy 586 and current versions need at minimum a 686 CPU. At the time Debian drops 32bit support (not in the next few years) the last 32-bit only computers - I think those are the Intel Atom processors from 2008 (?) - will really have gotten unsuitable for any job that needs to be done and buying a $10 ARM computer will likely pay off in money spend for electricity alone.

I think we will support 32 bit as long as there is at least one Debian release that officially supports it, though. Unless there are external limitation that force us away from being 32 bit compatible but I don't see this happening (would also be an issue for ARM).