Open Games-Crack opened 2 years ago
probably this could help for time being https://dietpi.com/phpbb/viewtopic.php?t=8612
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
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>
.
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
Thanks, I'll contact you via discord once I find time to start with the container image.
Ok, till then
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.
Any hope on this, I see its removed from all milestones...
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.
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
probably this can be used for time being https://dietpi.com/blog/?p=2642
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:
dietpi-installer
to (de)select a network stack when selecting a container as target system, like it is done for WiFi support.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.
Creating an image request
Formal device information
Is the SBC officially supported by the Debian installer?
If not, are there install instructions for Debian available?
Issues with Diet Pi