/usr/share/ifupdown2/ifupdown/main.py
parser.readfp(configFP)
Need change to:
parser.read_file(configFP)
Last edited:
Proxmox Virtual Environment 9.0 released!
- Thread starter t.lamprecht
- Start date
parser.readfp(configFP)
Need change to:
parser.read_file(configFP)
ip a a 192.168.100.30/24 dev ens3
Error: either "local" is duplicate, or "device" is garbage.
That did not work. My /etc/network/interfaces is clean without much in it.
auto ens3
iface ens3 inet static
address 192.168.100.30
netmask 255.255.255.0
gateway 192.168.100.1
Error: either "local" is duplicate, or "device" is garbage.
That did not work. My /etc/network/interfaces is clean without much in it.
auto ens3
iface ens3 inet static
address 192.168.100.30
netmask 255.255.255.0
gateway 192.168.100.1
This worked. My issue was not with the PVE upgrade to 9.0. That went smooth as butter. I then upgraded the Proxmox Backup Server to 4.0, and after reboot the networking was hard down. Apparently part of the process upgraded python, and the latest version replaced the syntax used for that particular method. This fixed the networking issues, but sure seems unrelated to Proxmox, and mode related to Linux directly. Scary as this could of happened to any user that upgraded the distribution to Trixie.
After I got the networking back up, I did find a pbs-enterprise.sources file and # all the lines out. This allowed the apt update to run smoothly with no errors. Thank you>
But there were no packages to install or update. This issue probably will effect other users that update to 4.0 of Proxmox Backup Server. Just a heads up.
** I stand corrected. I had to disable the Enterprise, and then ADD the non-production repository. SO let the upgrade begin. LOL
*** UPDATE:
Proxmox 9.0 went OK. Did have some NFS Storage that went offline. Had to run a repair from console, and it took awhile. Then the NFS was online and accessible. Had to run: lvconvert --repair SSD-STORAGE/SSD_STORAGE (This took a while to complete. PVE went offline, but then came back online and storage was accessible.) SSD-STORAGE is my Pool Name and Volume Name. (lvs -a)
Proxmox Backup Server was good except for the deprecated command I had to replace. Hopefully other won't run into that. But all is working. Super thankful for this support forum as they got me back up and running. I appreciate everyone's contributions.
Last edited:
Just did a completely fresh install, tried this twice (both on fresh installs).
The very first container created has a bug where it does not show as "on" in the tree despite very clearly being on and operating.
There are 3 solutions:
-Make a 2nd additional container, then both of them will magically appear "on".
-Delete and remake the first container.
-Restart the server
The very first container created has a bug where it does not show as "on" in the tree despite very clearly being on and operating.
There are 3 solutions:
-Make a 2nd additional container, then both of them will magically appear "on".
-Delete and remake the first container.
-Restart the server
Attachments
I believe I'm experiencing this same issue (unable to boot after upgrade; eventually it takes me to BIOS). Proxmox is installed on an ext4 partition on an NVMe. I don't know how to resolve this. Please help.
Worth noting, using the Proxmox installation ISO version 9, and choosing Rescue Boot, it boots me into my local Proxmox.
Last edited:
I get the following warning from pve8to9:
WARN: The matching CPU microcode package 'intel-microcode' could not be found! Consider installing it to receive the latest security and bug fixes for your CPU.
apt install intel-microcode
But if i try to install i get:
apt install intel-microcode
E: Unable to locate package intel-microcode
Edit: Had to add non-free-firmware to the repository
WARN: The matching CPU microcode package 'intel-microcode' could not be found! Consider installing it to receive the latest security and bug fixes for your CPU.
apt install intel-microcode
But if i try to install i get:
apt install intel-microcode
E: Unable to locate package intel-microcode
Edit: Had to add non-free-firmware to the repository
Last edited:
Everything is running fine for me, but I don't see a difference in disk IO performance between ZFS Direct IO being enabled or disabled. Is PVE overriding this?
This is how I (or at least I think I am) setting ZFS direct IO to be enabled:
Then, within my ZFS pool named rpool, I create a file and run fio with random write and direct=0 and direct=1 and the result is about the same:
Reason for repeating is I don't understand how fio is ZFS aware and it might bypass that setting.
So then I did a couple of other things:
1. rsync on host
2. Copy/Paste large data file on Windows
Copy/paste using UI (don't do it twice, standby cache will cheat)
I also tried rebooting and repeating, no change.
This is how I (or at least I think I am) setting ZFS direct IO to be enabled:
Code:
zfs set direct=always rpoolThen, within my ZFS pool named rpool, I create a file and run fio with random write and direct=0 and direct=1 and the result is about the same:
Code:
apt install sysstat -y
apt install fio -y
rm /dev/zvol/rpool/data/test.file
fio --filename=/dev/zvol/rpool/data/test.file --name=sync_randrw --rw=randrw --bs=4M --direct=0 --sync=1 --numjobs=1 --ioengine=psync --iodepth=1 --refill_buffers --size=8G --loops=2 --group_reporting
rm /dev/zvol/rpool/data/test.file
fio --filename=/dev/zvol/rpool/data/test.file --name=sync_randrw --rw=randrw --bs=4M --direct=1 --sync=1 --numjobs=1 --ioengine=psync --iodepth=1 --refill_buffers --size=8G --loops=2 --group_reportingReason for repeating is I don't understand how fio is ZFS aware and it might bypass that setting.
So then I did a couple of other things:
1. rsync on host
Code:
zfs set direct=always rpool
rsync -aP /dev/zvol/rpool/data/test_random_disk.qcow2 /dev/zvol/rpool/data/test_random_disk_io_direct_enabled.qcow2
zfs set direct=disabled rpool
rsync -aP /dev/zvol/rpool/data/test_random_disk.qcow2 /dev/zvol/rpool/data/test_random_disk_io_direct_disabled.qcow22. Copy/Paste large data file on Windows
Code:
fsutil file createnew C:\test_disk.dat 8589934592I also tried rebooting and repeating, no change.
Thank you so much, my friend. You’re genuinely a blessing in my life.
I truly appreciate your guidance.
Successful upgrade here. Two node cluster + Q device. In place upgrade with no subscription repo as it is used in homelab. All ZFS pools for storage. Minor bumps during the upgrade process but fairly smooth.
Only problem that I haven't been able to solve... I had Webauthn setup for MFA for my GUI users. It's been successfully working on 8.4 for months. However, now with the upgrade, I'm getting a 401 auth error.
I've taken the following steps:
1. Confirmed that original settings were still in place.
2. Confirmed that the security certificate is still valid.
3. Deleted and reentered my Webauthn passkey.
4. Tried different formats for Webauthn Name/Origin/ID.
No luck so far. Definitely not a deal breaker but if anyone's faced a similar issue, would love to hear if you've found a solution.
Only problem that I haven't been able to solve... I had Webauthn setup for MFA for my GUI users. It's been successfully working on 8.4 for months. However, now with the upgrade, I'm getting a 401 auth error.
I've taken the following steps:
1. Confirmed that original settings were still in place.
2. Confirmed that the security certificate is still valid.
3. Deleted and reentered my Webauthn passkey.
4. Tried different formats for Webauthn Name/Origin/ID.
No luck so far. Definitely not a deal breaker but if anyone's faced a similar issue, would love to hear if you've found a solution.
I solved my issue by:
- Booting into Rescue Mode with the Proxmox Installation ISO (version 9) which booted into my local Proxmox install.
- Running
proxmox-boot-tool init /dev/nvme0n1p2- /dev/nvme0n1p2 is my EFI boot partition
- Reboot
Last edited:
This was going to be my next step. I tried it before I made my post but also my iso did not have the grub packages install so I just shut it down and decided I would come back to it later.
Thanks for this clarification, @Stoiko Ivanov .
I'm using ZFS with UEFI, and secure boot disabled, and SystemD-Boot is used on my nodes instead of Grub, so this applies to me.
I'm on the latest version of PVE 8 in the enterprise repo.
I appear to have the full SystemD boot package installed:
Bash:
root@andromeda2:~# apt search systemd-boot
Sorting... Done
Full Text Search... Done
proxmox-kernel-helper/stable,now 8.1.4 all [installed]
Function for various kernel maintenance tasks.
pve-kernel-helper/stable 7.3-4 all
Function for various kernel maintenance tasks.
systemd-boot/stable-security,now 252.38-1~deb12u1 amd64 [installed]
simple UEFI boot manager - tools and services
systemd-boot-dbgsym/stable 252.12-pmx1 amd64
debug symbols for systemd-boot
systemd-boot-efi/stable-security,now 252.38-1~deb12u1 amd64 [installed]
simple UEFI boot manager - EFI binariesI'm still a bit confused about this. I looked the the wiki ( https://pve.proxmox.com/wiki/Upgrad...ation_automatically_and_should_be_uninstalled ) and understand that the metapackage needs to be uninstalled, but I'm not sure how to do that on PVE 8 without breaking PVE 8.
The Wiki:
The pve8to9 script, though, doesn't warn me about SystemD-Boot.
I'm not sure if that means I'm okay to upgrade or not. This is really confusing.
Run the ugrade on a single host. Almost everything ist fine. If I run
Running the suggested
pve8to9 --full after upgrade I get. Running pve8to9--full prior update returns no warning.
Code:
WARN: Found '3' RRD files that have not yet been migrated to the new schema.
pve-storage-9.0/node2/nfs-storage1
pve-storage-9.0/node2/nfs-storage1
pve-storage-9.0/node2/nfs-storage1
Please run the following command manually:
/usr/libexec/proxmox/proxmox-rrd-migration-tool --migrate/usr/libexec/proxmox/proxmox-rrd-migration-tool --migrate returns
Code:
Migrating RRD metrics data for nodes…
Migrated metrics of all nodes to new format
Migrating RRD metrics data for storages…
Migrated metrics of all storages to new format
Migrating RRD metrics data for virtual guests…
Using 6 thread(s)
No guest metrics to migrate
that was not the right part of the log (that seems to have been an upgrade to 8.3/8.4 packages?) - but it also looks like it got interrupted at the grub install stage which is peculiar..
Yes
Yes - because you're still on PVE-8 (bookworm) - I thought that the following part should explain that:
which is also why the pve8to9 script does not warn you before upgrading to pve-9 (trixie):
I will warn you after upgrading to 9 (at that point the system will have `systemd-boot-tools`, `systemd-boot-efi` (both of which we need) and `systemd-boot` (which you want to get rid of installed)
Thanks for the feedback - much appreciated (the clearer our guides are the smoother the upgrades for our community will be) - any suggestions how to improve that part? - Thanks!