Recent content by geppi

It looks like the download link for the APK earlier in this thread is outdated in the meantime. A newer version can be downloaded from pve-mobile-testbuild-1.4.2.apk with (sha256sum 40a8c083d478794d94ba81fc234cf4adafbbaf7f4f5b8a4a08cb0ec2f5e3d976). The new version solves the deserialization...

I'm using the APK with sha256: 0c3be4ce4a17f100a4885cd3a0b377b00edc35212ce241e6b65332cf32fbf03a When tapping on an lxc container an error window is popping up with deserialization errors. It is the container vmid that's causing the error message: type '_Smi' is not a subtype of type 'String' in...

Done: Bug 3877 - Feature request: Allow lxc.sysctl.net.* keys in the PVE LXC config

Thank you for the link with the allowed keys. Would it be possible to elaborate a little on why the lxc.sysctl.net.* keys are not allowed although the kernel parameters can be configured from inside even an unprivileged container ? Obviously they're namespaced, right ? Is my understanding...

I'm a little confused reagarding what's possible with an unprivileged container when it comes to setting values in /proc/sys. I'm in partucular interested in everything below /proc/sys/net. I have an unprivileged container in which everything below /proc/sys/net is owned and writable by root...

In besagtem Thread im Englischen Forum hat Thomas Lamprecht meine oben gestellte Frage inzwischen beantwortet: Demnach ist nicht zu erwarten, dass sich in absehbarer Zeit etwas an der Notwendigkeit ändern wird, das Nesting zu aktivieren. Für unprivilegierte Container sollte dies jedoch keine...

Will the requirement to set nesting=1 persist in the future for runnning newer versions of systemd without problems or is there a chance that the "container runtime interface requirements" of systemd, which Thomas has mentioned above, will specifiy the required namespaces to pre-create them ?

In einem Thread im Englischen Forum schrieb Thomas Lamprecht bezüglich der systemd Versionen neuer als 247: Wird das Setzen von nesting=1 denn für die Zukunft Vorraussetzung bleiben um die neueren systemd Versionen in einem unpriviligierten Container laufen zu lassen oder besteht die...

not sure how that should help to prevent the Proxmox installer from wiping out the existing boot variables in the EFI NVRAM

This I understand, but it also wiped out the boot variable for 'proxmox-2', which was the entry to boot from the second SDD of the rpool mirror. Apart from that it would be a nice feature if one could define the name of the bootloader in the installer, which could default to 'proxmox'.

I decided that it would be a good idea to install Proxmox VE 5.3 to a USB thumb drive just as a rescue system which would enable me to independently mount my zfs rpool from the SSD mirror. So I plugged in a USB thumb dive with the Proxmox installer and another thumbdrive to install to...

ESXi does not write to the USB thumb drive after completing the boot process. It pretty much completely resides in RAM. ESXi also takes the following measures to avoid writing to the USB thumb drive: Due to the I/O sensitivity of USB and SD devices the installer does not create a scratch...

Thank you for the link. Now I think I understand the concerns. If I understand it correctly my setup will be safe as long as there will be no Proxmox kernel upgrade because: - no changes will be made to the ESP by Proxmox - no other software will modify the ESP in my case because I'm not...

Sorry, that's a little bit too short for me to understand. What needs to be kept in sync ? The two ESP partitions ? Don't you also have to keep the two BIOS Boot Partitions in sync for the Legacy mode booting ?

After operating a ZFS "all in one" ESXi/OmniOS/napp-it server for the past 6 years I was curious to see how ZoL and Open Source virtualization have developed in the meantime. Proxmox seemed to be a very good solution to investigate. Since my OmniOS storage server is booting from a mirrored ZFS...