Figure out the future of multiple generic x86_64 images

[mtoman]

At this moment we have two "generic intel" types, one of them is genericx86-64-ext from balena-intel and the other one is generic-amd64 from this repo. Though similar there are differences between them:

• Kernel configuration
• genericx86-64-ext supports both BIOS and UEFI boot while generic-amd64 only supports UEFI
• genericx86-64-ext builds a flasher while generic-amd64 builds a flat image
• Naming is not very descriptive for either of the two (the NUC being called genericx86-64 adds even more to this)

We need to discuss this and decide how to approach this, the two obvious ways are:

• Keep both and improve docs/naming
• Replace one by another in a transparent way

[jakogut]

Kernel configuration

I think we should build a fairly generic kernel, suitable for a wide range of hardware, like distros do.

genericx86-64-ext supports both BIOS and UEFI boot while generic-amd64 only supports UEFI

BIOS/MBR booting is basically obsolete. UEFI has had widespread support in PCs and servers since at least 2008. Even if someone does have hardware lying around that's that old, a Raspberry Pi 4 would be more practical and capable. Maybe it's worth discussing dropping support for BIOS/MBR?

genericx86-64-ext builds a flasher while generic-amd64 builds a flat image

Maybe it's worth building both in this repository?

I think it's also worth revisiting how flashing is done for the x86 images. Before I learned that the flasher image automatically and without input or confirmation overwrites the internal disk with balenaOS, I almost wiped out all the data on my laptop trying to boot it. In that instance, what I really wanted was balenaOS booting off a USB drive, not installing to my internal disk.

[kb2ma]

My confusion on this topic as a docker-compose file creator led me to this issue. Thanks for the clear summary. Without understanding the internal complexities, I think a single image named 'generic-amd64' would make the compose file creator's task much simpler.

[mtoman]

The balena-intel counterpart: balena-os/balena-intel#374

[alexgg]

This was discussed in an arch call https://jel.ly.fish/a3972594-b0c7-4fcb-8b05-e3836536cb95 and I am writing an improvement with the conclusions https://jel.ly.fish/93e4dc69-93b5-46ff-9631-62d9be4d75c5

[alexgg]

This is now begin tracked as an improvement.