But that's exactly what I'd like to know. Whether I can do
[Match]
MACAddress=aa:bb:cc:dd:ee:ff
[Link]
Name=enp1s0
For an interface that is already called enp1s0 right now or whether that will result in some clash or race condition.
Regarding that ethernet interface renaming that takes place with kernel 6.8 as opposed to kernel 6.5 ...
I understand that you can configure a mapping via /etc/systemd/network/. The documentation suggests to use prefix en or eth.
Currently my interfaces are labelled enp1s0 to enp6s0 (six Intel...
Is there any way to check - while still on the old kernel - whether this renaming will affect oneself when rebooting with the 6.8 kernel, so that one could take the appropriate measures in the `/etc/network/interfaces` blindly before rebooting?
This renaming may not be a big issue for a machine...
Today I did the upgrade from PVE 7.4 to PVE 8.0 and it worked flawlessly. I did:
sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
apt update
apt dist-upgrade --download-only
apt install systemd-boot --download-only
qm shutdown 100
apt dist-upgrade
apt install systemd-boot
reboot now
It...
I just upgraded from PVE 7.4 to PVE 8.0 without any issues.
After the upgrade, I noticed that I now have the following obsolete packages still installed:
pve:~# apt list ?obsolete
Listing... Done
gcc-10-base/now 10.2.1-6 amd64 [installed,local]
gcc-9-base/now 9.3.0-22 amd64 [installed,local]...
systemd-boot is not pulled in via dependency, see https://pve.proxmox.com/wiki/Upgrade_from_7_to_8#Systemd-boot_.28for_ZFS_on_root_and_UEFI_systems_only.29
The point is, with PVE 7 (bullseye) I cannot install systemd-boot as it does not exist yet. When upgrading to PVE 8 (bookworm) I shall not...
Is there a possibilty to also "download but defer installation" of package systemd-boot, because that's required after the upgrade for ZFS/UEFI systems, I have read. I.e. is there a apt install --download-only systemd-boot (or equivalent)?
I'm just wondering what is the lesser risk:
1. being online while doing the upgrade and keeping the OPNsense VM running (against the advise)
2. doing the offline variant and getting into some kind of trouble where I would need internet but cannot start the VM
In my setup, it's the same, my OPNsense is a guest running on the Proxmox VE instance.
Is the "upgrade without guests running" a new prerequisite with the PVE 8.0? In the past I did all the upgrades (7.0 to 7.1, 7.1 to 7.2, 7.2 to 7.3, 7.3 to 7.4) with the OPNsense VM running and I haven't...
Does this mean, PVE has to be upgraded to version 8 first before PBS can be upgraded to version 3? I cannot upgrade PBS to version 3 first and then upgrade PVE to version 8 later on? Or did I misunderstand this FAQ entry?
Thanks for your write-up. Actually the step 1 is not required as systemd automatically creates the serial-getty for login if the console=ttyS# kernel boot parameter is present. I just did your step 2 and 3 and everything works fine.
However one question regarding the order of the two console...
You cannot do that for a unit running in headless mode without keyboard or monitor however. ;-)
Edit: In fact, I want to add console=ttySX console=tty0 parameters, so that I can use a serial console in case something goes wrong. But by doing so, I do not want to mess up by making a typo or in a...
Hi all,
I realize that recently there was the introduction of pve-efiboot-tool kernel pin XXX --next-boot to only have the kernel being used for the next boot, so that in case something does not work, the boot afterwards will revert to the currently used kernel.
Now I wonder whether a similar...
But understanding from your post, I *will* have to make sure that it boots up with kernel 5.13 instead of 5.15 the first time I reboot after upgrading?
Hi all,
I read a lot of reports here that GPU passthrough or RAID systems do not work any more with PVE 7.2 and kernel 5.15 when using intel_iommu=on and the advice is to go back to kernel 5.13 or turn intel_iommu=off - iI understood all the posts correctly.
i have however not seen a posting...
Ok, that relieves me a bit for two reasons:
1. For documentation purposes I put the statically set IPs into "reserved IPs" of the DHCPv4 configuration anyway, so your "step 2" is already done in my setup.
2. I now understand that you lost IPv4 access to the management of the PVE host due to...
I'm trying to understand ... but I'm not sure I followed correctly.
Where exactly does this different DHCP behaviour come into play? I don't assume that you hand out IPs via DHCP to neither the Proxmox VE server nor the pfsense running on a VM. I assume, both have statically set IPs?
So, even...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.