Image | LXC container

[Games-Crack]

Creating an image request

Formal device information

• Device name | LXC (Proxmox)
• Official product URL | https://www.proxmox.com/
• Image download URL | Debian (in downloads section)

Is the SBC officially supported by the Debian installer?

• It's not working with the current Installer of Diet Pi

If not, are there install instructions for Debian available?

• Download the Container image & create a Container (lxc) with Debian image downloaded

Issues with Diet Pi

• it tries to install grub and a kernel (LXC Container are like a chroot but with a initsystem), both are unnecessary
• it cant mount /dev/loop0 on / (use mount -o bind instead)
• uninstalls any DHCP client (first boot will fail if not a static IP)

[Joulinar]

probably this could help for time being https://dietpi.com/phpbb/viewtopic.php?t=8612

[MichaIng]

Many thanks for your request.

We'll create a generic container image soon, without GRUB, kernel and initramfs.

it cant mount /dev/loop0 on / (use mount -o bind instead)

Can you clarify? I didn't use Proxmox yet, but systemd-nspawn with /dev/loopX* bind-mounted into the container (from host), before booting it. Within the container it is then recognised as regular root partition. DietPi-PREP can only work when it is able to read info from the root mount and device, so that it can create a correct /etc/fstab. Is this not guaranteed when booting an LXE container?

uninstalls any DHCP client (first boot will fail if not a static IP)

DietPi-PREP installs the isc-dhcp-client, hence does not fail when no static IP is given. Or do you mean that an LXE container cannot lease from DHCP but must have a static IP instead? Actually in case of systemd-nspawn and Docker the hosts network is used directly, so the whole network stack, including DHCP client, ifupdown and /etc/network/interfaces can be skipped, which I planned for the (generic) container image as well. Would this not work with the LXE container?

@Joulinar
Meant here is a container, not the Proxmox VM 😉: https://pve.proxmox.com/wiki/Linux_Container

[Games-Crack]

1. It doesn't need to create a fstab the host handles that (Default fstab is empty)
2. after setting a static IP (via the network settings of proxmox), the First-time Setup ran, but before it didn't because it didn't run (had no network) the DHCP client still need runs in the container (if not set static by host) because it gets its own IP and doesn't share any networking with the host (the host interface is a bridge) (its like as if all VMS/container are connected to a network switch and everyone gets its own IP from the router)

[MichaIng]

It doesn't need to create a fstab the host handles that (Default fstab is empty)

But does an fstab hurt and does the container have access to /dev/loop0* devices? I guess it may hang when the initsystem tries to mount something where no matching block device is found. Generally it makes sense that it is not required, but it requires quite some more work to respect this everywhere for container systems to not attempt mounting or checking any block device. I haven't though about this so far since I use containers to generate real machine images, where block device access is required to derive UUID, generate boot and fstab configs etc.

Hmm the network thing makes it quite more complicated. Since by default the network stack with DHCP client is currently installed and active, does it mean ifupdown with isc-dhcp-client does not work with LXE containers, or is it simply the wrong interface names (eth0)? Basically within the container, can you show:

ip a

... probably when the container does not trigger udev events internally, in /etc/network/interfaces it needs to be auto <iface> instead of allow-hotplug <iface>.

[Games-Crack]

If you want, I can give u a LXC Container to play around with.
Do you, I'd need an ssh public key from you and some way of contacting you privately because I don't want my Server IP public
Do you have discord?

My Username: Games_Crack#3524

[MichaIng]

Thanks, I'll contact you via discord once I find time to start with the container image.

[Games-Crack]

Ok, till then

[MichaIng]

A first generic container image is up: https://dietpi.com/downloads/images/DietPi_Container-x86_64-Bullseye.7z
But it's with regular /etc/fstab and without network stack, hence wouldn't work as LXC container, as of above topics. It however works great with systemd-nspawn and serves well for testing DietPi scripts in GitHub actions and other CI/CD pipelines.

Taking care of some other topics now, but will add a flag for creating container images with network stack and, when required, such without /etc/fstab, for individual engine needs. And of course packing the raw image into an actual container appliance (where a raw image cannot be used) is another task then.

[ethanpil]

Any hope on this, I see its removed from all milestones...

[MichaIng]

Yeah sorry, I do not find time for this currently. I'll remove root drive handling for containers first (reasonable in nearly every case, actually) and enable network support optionally (an additional set of network-ready container images). These can be used as a basis for LXC containers. No ETA from my side, but everyone is welcome to start adding the functionality to dietpi-installer.

[meguroyama]

Hey there any chance this can be looked at again @MichaIng ? The default debian is pretty good already but would love a diet-pi version as well :P

[Joulinar]

probably this can be used for time being https://dietpi.com/blog/?p=2642

[MichaIng]

There is not much missing, only ifupdown to be installed and use on our container images. I'm not sure whether it is best to add a new hardware ID for containers with own network stack, or to:

1. Add an additional option to dietpi-installer to (de)select a network stack when selecting a container as target system, like it is done for WiFi support.
2. Go through first run setup steps and possibly other DietPi scripts to assure that network setup and options are done/offered for container images, in case ifupdown is installed.

Probably option 2 is actually easier to implement, though one must take more care to catch all cases where we do network-related decisions based on whether hardware ID is 75 (container) or not. Also it allows to switch on the fly by simply installing or uninstalling ifupdown. AFAIK also Proxmox allows to configure containers to use the host network directly instead of having their own, isn't it?

I won't find time for this soon, but will take/support any PR if someone else does and wants to tinker with the installer.