> man zfsHi,
How can I use ZFS encryption, I don't see any guidelines for that. Thank You Tiago
The grub way alone is not working for the systemd-boot used with ZFS on UEFI installations. We documented a how to in the "Host System Administration" chapter of our docs project.My setup is pve6 latest beta root on zfs (raid10) with UEFI boot.
Need some help!
# cat /etc/systemd/system/dovecot.service.d/PrivateTmp.conf
[Service]
PrivateTmp=false
ProtectSystem=false
PrivateDevices=false
# systemctl daemon-reload
# systemctl restart dovecot
Our kernel is based on the Ubuntu Kernel, currently on the 5.0 based kernel used by Ubuntu 19.04 "Disco". Ubuntu and we back port HW support patches as needed, so you should normally not have any problems regarding this.Is it possible to get newer kernels for new AMD Zen 2 processor support? even if its an unofficial kernel build. Or can we install the ubuntu kernel?
If all that is not possible what modules do I need to enable to build my own kernel?
Virtual Machines should not have such problems. Do you mean Containers (CTs)?Are there already any working Solutions for the Buster VM Problems?
Ye, sry, i mean CTs not VMs. I missed the Nesting Feature, now it's working. ThanksVirtual Machines should not have such problems. Do you mean Containers (CTs)?
For them one can use "unprivileged" CTs with the "nesting" Feature enabled, in a safe manner.
Zen 2 isn't working with the ubuntu 19.04 kernel. Many issues. rdrand, systemd fails, xhci fails. I am assuming ubuntu will backport the patches? If not can I install any ubuntu kernel or do I need special modules to be loaded?Our kernel is based on the Ubuntu Kernel, currently on the 5.0 based kernel used by Ubuntu 19.04 "Disco". Ubuntu and we back port HW support patches as needed, so you should normally not have any problems regarding this.
Does something not work for you?
+1 for a newer kernel. GVT-g for 8th gen (Coffe Lake) processors does not work with 5.0, but has been upstreamed in 5.1Our kernel is based on the Ubuntu Kernel, currently on the 5.0 based kernel used by Ubuntu 19.04 "Disco". Ubuntu and we back port HW support patches as needed, so you should normally not have any problems regarding this.
Does something not work for you?
That's not the kernel, that's the CPU and its firmware, where updates from AMD (microcode) and/or the mainboard (over their firmware) vendors are proposed, IIRC.rdrand, systemd fails
As long as you do not use ZFS you're somewhat fine, but you won't get real help here with a self-compiled kernel (as no other tests/uses it, at least no one from us), just FYI.If not can I install any ubuntu kernel or do I need special modules to be loaded?
Yes, and we can and will too, if you can point at a specific set of fixes we did not yet included you can point us to it too and we can take a look at it.. I am assuming ubuntu will backport the patches?
Newer kernel won't come for 6.0, but it's planned for a 6.x, we'll probably go then to the future 20.04 LTS kernel one available and stable, which will for sure be newer than 5.1+1 for a newer kernel. GVT-g for 8th gen (Coffe Lake) processors does not work with 5.0, but has been upstreamed in 5.1
Yes but there is a systemd patch to make boot not dependent on rdrand. OpenSuse tumbleweed already has a build with the patch.That's not the kernel, that's the CPU and its firmware, where updates from AMD (microcode) and/or the mainboard (over their firmware) vendors are proposed, IIRC.
Ah so not a kernel patchYes but there is a systemd patch to make boot not dependent on rdrand. OpenSuse tumbleweed already has a build with the patch.
Did you even tried booting the ISO on such a system out?* random-util: Eat up bad RDRAND values seen on AMD CPUs.
Some AMD CPUs return bogus data via RDRAND after a suspend/resume cycle
while still reporting success via the carry flag.
Filter out invalid data like -1 (and also 0, just to be sure).
(Closes: #921267)
No, sorry, I do not know which exact issue you're referring to, but we did quite some improvements regarding NVMe devices in the 6.0 installer, so if you can reproduce it with the Beta ISO or a hopefully soon coming final one we'd appreciated a detailed report in a own thread here or over at https://bugzilla.proxmox.com/Are you familiar with the 4k nvme issue I am referring to or should I attempt to install the proxmox iso again and document the issue here for you?
I have noticed the following log lines during this error in journald:... drop-down fields which are filled dynamically, e.g. the template selection in the "Create CT" wizard are filled only after a long delay or not at all...
Hi, same problem here.Very funny, pve5to6 declares:
FAIL: Unsupported SSH Cipher configured for root in /root/.ssh/config: 3des
With a cat /root/.ssh/config:
Ciphers blowfish-cbc,aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
The fun thing is that this file was written by PVE5 itself, as is, at its install
It should have been left empty or nonexistent.
While talking about ssh I see that the public key for user root created by pve5 at its install was an RSA 2048 (which is OK), but since ed25519 is supported in debian9/10, more secure and very fast, it probably should be the new choice.
Yes, just remove the offending ciphers. If you want you could replace it with the current, updated for Buster one:How can I solve it? just delete 3des word from config file?
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
I'm not able to reproduce your issue. If you (or others having this problem) like to help, just comment in https://github.com/swayf/proxmoxer/issues/79 For me, basic authentication and interaction with the cluster works.Well, the fun continues.
Before I did a clean install of 6.0 beta, I backed up my ansible playbooks from 5.4 VE which worked.
So did a 'apt-get install ansible' and 'apt-get python-pip. Then did a 'pip install proxmoxer'
When I run the playbook to create a VM, I get the following error:
'authorization on proxmox cluster failed with exception: invalid literal for float(): 6-0.1'
Did API access change from 5.4 to 6.0 beta?