[FEATURE]: In Pi Imager, when user chooses 32 bits version, please explain it will be switched to 64bits if user doesn't put arm_64bit=0 inside config.txt

[romdudu60]

Is your feature request related to a problem? Please describe.

Well I have lost 1 day of my life to understand why I was not able to use gitlab-runner with docker executor.
Problem was I was thinking my arch was 32 but it was 64.
In Pi Imager, I had chosen 32-bit.
Anyway the feature is good (to be able to switch). But please check user are aware of it.

Describe the solution you would like to see implemented

some pop-up or else explaining the feature. Or an option to chose inside pi imager.

Describe alternatives you've considered

I understood by myself after having restting my whole system.

Additional context

32 or 64, we need to know.

Version

1.8.5 (Default)

[lurch]

As I understand it, if you boot a 32-bit OS on a 64-bit capable Pi (i.e. a Pi4 or a Pi5) then you actually get a 32-bit userland on top of a 64-bit kernel. Perhaps it's this that was confusing "docker executor" ?

ping @aallan in case there's any tweaks that need to be made to https://www.raspberrypi.com/documentation/

[aallan]

As far as I'm aware the documentation already says that it's a 32-bit user land, but a 64-bit kernel. It's been that way for a few years now. The default option is 64-bit, and that's been the case since Bullseye I think? It's clearly labelled in Imager as such.

[lurch]

raspberrypi/bookworm-feedback#120 also mentions problems with docker in a mixed 32-bit / 64-bit environment. (I know very little about docker myself 🤷‍♂️ )

[aallan]

From my conversation with the Docker team it should not work at all on 32-bit image? They're 64-bit only. At least last time I looked?

[romdudu60]

Gitlab needs 32 bits (as far as I know). So when I used Pi Imager, I had chosen 32bits image. But, I understood after some times that arch command was giving aarch64. I was surprised. First I thought I didn't choose the good image in pi imager. I started again from zero (choosing carefully 32 bits). And arch was still giving aarch64. Maybe you, specialists, thinks it's normal and it's the way it has to be. But for me it was confusing. Then I understood I could revert to 32 bits in changing config.txt. Now it's working. I did this issue because I'm not the only one expecting 32 bits when I select 32 bits image. I have a Rpi 4.
raspberrypi/firmware#1795 (comment)

[romdudu60]

From my conversation with the Docker team it should not work at all on 32-bit image? They're 64-bit only. At least last time I looked?

I followed this page from their website. It looks like working. https://docs.docker.com/engine/install/raspberry-pi-os/

[romdudu60]

raspberrypi/bookworm-feedback#120 also mentions problems with docker in a mixed 32-bit / 64-bit environment. (I know very little about docker myself 🤷‍♂️ )

Thank you @lurch , I use bullseye because gitlab asks buster or bullseye with raspberry pi os.

[romdudu60]

As far as I'm aware the documentation already says that it's a 32-bit user land, but a 64-bit kernel. It's been that way for a few years now. The default option is 64-bit, and that's been the case since Bullseye I think? It's clearly labelled in Imager as such.

@aallan I didn't go through the documentation, I clicked "choose os" then Raspberry Pi OS (32 bits) bullseye. But I agree, there's a special page on documentation dealing with config.txt. It's mentioned that arm_64bits defaults to 1 on Pi 4s.

[tdewey-rpi]

@romdudu60 Unfortunately, feature request rejected.

While I appreciate this is less-than-trivial, this is covered by Raspberry Pi Documentation (https://www.raspberrypi.com/documentation/computers/linux_kernel.html#kernel), and is niche enough of a use-case that I believe adding additional messaging around this topic would degrade the experience for a new user sufficiently that we'd see more widespread user confusion.

As ever, I am prepared to change my mind, and the criteria are broadly consistent:

1. If my assumption on this being a "niche" use case turns out to be incorrect
2. If a design proposal that can mitigate the extraneous information for the naive use case can be found

As a result, while I empathise with the request, I am forced to close this issue. Note that does not preclude further responses - for example, to work through a proposal for (2).