keep networking packages for containers

[yodaaut]

Hi,
I wanted to use a default debian lxc container in proxmox and convert it to DietPi.
The main problem was that the container was losing network connectivity during the installation procedure and could not reinstall required packages.
This fix keeps the required packages and the convertion succeeds.

I have tested it with debian 11 with dhcp and fixed ip, both works well now ;)

[MichaIng]

The network packages are not installed/removed for container images intentionally at the moment. We will only add them in conjunction with a choice/flag or even a new hardware model for network-capable containers.

Also, this change on the installer does not address the issue that network is not set up as part of the first boot setup. This is currently skipped on container images (with hardware ID 75).

Please see the related request here: #5204 (comment)

Handling the input/variable/flag would at best be added here just before or after the WiFi input: https://github.com/MichaIng/DietPi/blob/92c4963/.build/images/dietpi-installer#L458

The actual packages should then be added here where other container/non-container packages are added: https://github.com/MichaIng/DietPi/blob/92c4963/.build/images/dietpi-installer#L877

[yodaaut]

The network packages are not installed/removed for container images intentionally at the moment. We will only add them in conjunction with a choice/flag or even a new hardware model for network-capable containers.

Yes maybe I misunderstood what the HW_Model "Container" really is.
I was more thinking about LXC-Containers which behave more or less like VMs but without their overhead. So maybe a new hardware model would suite better here. In case of LXC networking packages should be kept or they won't work correct.

Also, this change on the installer does not address the issue that network is not set up as part of the first boot setup. This is currently skipped on container images (with hardware ID 75).

I'm not quite sure what u like to achieve here. In my usecase i like to convert an existing debian lxc and all the networking stuff already happened after container creation on the host (proxmox) side, either with fixed or dhcp address. After convertion has completed you can still change or keep the configured address on first boot setup.

Please see the related request here: #5204 (comment)

Was going through that but I think it's a different usecase, as i only like to convert from an existing, not building a new container.

Handling the input/variable/flag would at best be added here just before or after the WiFi input: https://github.com/MichaIng/DietPi/blob/92c4963/.build/images/dietpi-installer#L458

The actual packages should then be added here where other container/non-container packages are added: https://github.com/MichaIng/DietPi/blob/92c4963/.build/images/dietpi-installer#L877

good point, this would be a better place for keeping the necessary packages.

If you like i would try to introduce next available HW-Model-ID (i think 81 should be free) or like you did here:

DietPi/.build/images/dietpi-installer

Lines 374 to 375 in 92c4963

	'62.1' ': NanoPi M3/T3'
	'62.2' ': NanoPi Fire3'

something like 75.1 (docker) and 75.2 (lxc)

[Joulinar]

75.1 (docker)

We thought about a DietPi Docker image in past but did not found a real use case for it.

[MichaIng]

I'm not quite sure what u like to achieve here. In my usecase i like to convert an existing debian lxc and all the networking stuff already happened after container creation on the host (proxmox) side, either with fixed or dhcp address. After convertion has completed you can still change or keep the configured address on first boot setup.

I'm not sure whether Proxmox itself re-adds /etc/network/interfaces entries, but dietpi-installer removes and does not re-create this file on container systems, see around line 1650. It should be possible to setup network form the error handler on first boot, if ifupdown is installed, but it would be great to handle container systems with network capabilities just like VM and physical board systems. So have /etc/network/interfaces, have it adjusted on first boot according to dietpi.txt entries, have the interfaces brought up accordingly etc.

[MichaIng]

If you like i would try to introduce next available HW-Model-ID (i think 81 should be free) or like you did here:

DietPi/.build/images/dietpi-installer

Lines 374 to 375 in 92c4963

	'62.1' ': NanoPi M3/T3'
	'62.2' ': NanoPi Fire3'

)

something like 75.1 (docker) and 75.2 (lxc)

Yes, using 75.1 and 75.2 is probably the most straight forward way. I would not differentiate between container engines here, but really only between network and no-network containers, respectively "configure network in guest" and "use host network". So all checks for hardware model 75 would then be hardware model 75 + variant 1, else nothing needs to be changed. In other DietPi scripts (firstboot/setup), we then skip network setup steps if hardware model 75 and ifup command not available.

[yodaaut]

Thank you for your guidance! I've finally updated my PR 🎉
Let me know if any further adjustments are needed.