proxmox-biome didn't like this patch :(
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
On Fri, 11 Jul 2025 18:25:12 +0200, Christoph Heiss wrote:
> tl;dr: add transparent altname support by caching links under their
> primary name as well as any potential altname, and translating all
> interface names from the config into the primary interface name.
>
> The structure makes it also a
tl;dr: add transparent altname support by caching links under their
primary name as well as any potential altname, and translating all
interface names from the config into the primary interface name.
The structure makes it also as easy as possible to translate altnames in
other corners of ifupdown
Check that the configured swapsize is not greater than hdsize / 8 as
stated in the admin guide [0]. Define the behavior for the auto-installer as
well as the TUI and GUI installers.
[0] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#advanced_lvm_options
Signed-off-by: Michael Köppl
---
P
Instead of having parts of the RAID setup checks scattered in multiple
places, move the core of the checks to implementations of the
ZfsRaidLevel and BtrfsRaidLevel enums. Additionally, also move the unit
tests accordingly.
Signed-off-by: Michael Köppl
---
proxmox-installer-common/src/disk_check
The GUI and TUI installers already implement checks to ensure systems
have the minimum required number of disks available for the various RAID
configurations (min 2 disks for RAID1, min 4 disks for RAID10, etc).
This change adds an early check of the answer file to the
auto-installer, improving the
Adapt the return type of CidrAddressEditView's get_value implementation
for the FormViewGetValue trait to handle errors in case of invalid CIDR
similarly to other (parsing) errors done in the TUIs network dialog.
Signed-off-by: Michael Köppl
---
proxmox-tui-installer/src/main.rs | 8 +--
The goal of this series is to add additional sanity checks to the
auto-installer and the TUI and GUI installers. The following checks were
added:
* Btrfs / ZFS RAID: check if the required number of disks is available
* LVM: check if swapsize < hdsize
* Duplicate disks in answer file disk selection
Add checks for valid subnet mask (greater than /0 and at most /32 for
IPv4). In addition, check if the address entered by the user is valid
within the given subnet, i.e. not a network address or broadcast
address. /31 is considered an exception in accordance with RFC3021 [0],
considering any of the
Signed-off-by: Michael Köppl
---
proxmox-installer-common/src/utils.rs | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/proxmox-installer-common/src/utils.rs
b/proxmox-installer-common/src/utils.rs
index 8adcec0..1f225c8 100644
--- a/proxmox-installer-comm
Signed-off-by: Michael Köppl
---
proxmox-auto-installer/src/utils.rs | 12 +++-
proxmox-auto-installer/tests/parse-answer.rs | 1 +
.../parse_answer_fail/duplicate_disk.json | 3 +++
.../parse_answer_fail/duplicate_disk.toml | 15 +++
4 fil
Am 11.07.25 um 18:27 schrieb Michael Köppl:
> Check that the configured swapsize is not greater than hdsize / 8 as
> stated in the admin guide [0]. Define the behavior for the auto-installer as
> well as the TUI and GUI installers.
>
> [0] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#adva
On 7/10/25 14:48, Dominik Csapak wrote:
[snip]
Just for the record i also benchmarked a slower system here:
6x16 TiB spinners in raid-10 with nvme special devices
over a 2.5 g link:
current approach is ~61 MiB/s restore speed
with my patch it's ~160MiB/s restore speed with not much increase
in
On 11.07.2025 10:03, Christian Ebner wrote:
The installer assumes to have a valid mac address for all interfaces
as provided by the runtime env json file. Deserialization will fail
if this is not the case.
In some cases, the interface might however not provide a valid MAC
address, for example th
[snip]
diff --git a/proxmox-ve-config/src/sdn/fabric/section_config/mod.rs
b/proxmox-ve-config/src/sdn/fabric/section_config/mod.rs
index 7db378837eb1..174ea4d126c5 100644
--- a/proxmox-ve-config/src/sdn/fabric/section_config/mod.rs
+++ b/proxmox-ve-config/src/sdn/fabric/section_config/mod.rs
@@
On 7/11/25 10:27, Gabriel Goller wrote:
On 11.07.2025 10:03, Christian Ebner wrote:
The installer assumes to have a valid mac address for all interfaces
as provided by the runtime env json file. Deserialization will fail
if this is not the case.
In some cases, the interface might however not pr
The installer assumes to have a valid mac address for all interfaces
as provided by the runtime env json file. Deserialization will fail
if this is not the case.
In some cases, the interface might however not provide a valid MAC
address, for example the WWAN LTE module without any SIM installed on
superseded-by version 2:
https://lore.proxmox.com/pve-devel/30178a02-c6a4-4cb5-b5e7-f421dde03...@proxmox.com/T/
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
On Fri, 11 Jul 2025 12:16:07 +0200, Mira Limbeck wrote:
>
Applied to master and stable-8, thanks!
[1/1] pve8to9: fix log code ref
commit: dab5bbb371eae7bca29136c35dd6a94e0b338975
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://l
Signed-off-by: Hannes Duerr
---
src/PVE/Network/SDN/Dhcp.pm | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/PVE/Network/SDN/Dhcp.pm b/src/PVE/Network/SDN/Dhcp.pm
index 7dc38fb..65e40d4 100644
--- a/src/PVE/Network/SDN/Dhcp.pm
+++ b/src/PVE/Network/SDN/Dhcp.pm
@@ -6,7 +6,6 @@ use warnings;
At the moment it is possible to query the Dhcp plugin types from the
`use PVE::Network::SDN::Dhcp::Plugin` without importing
`PVE::Network::SDN::Dhcp`. In consequence the section config is not
created although one would have been expected it to be created.
Importing `use pve::network::sdn::Dhcp` w
On 7/11/25 11:47, Christoph Heiss wrote:
On Fri Jul 11, 2025 at 11:14 AM CEST, Thomas Lamprecht wrote:
Am 11.07.25 um 10:27 schrieb Gabriel Goller:
[..]
To be honest I'd rather filter out this interface. A zeroed out mac is
reserved for loopback interfaces and usually isn't routed.
It's not
when the responseText contains a plain message instead of JSON, the code
would throw an exception here that we don't catch and not show an error,
but also not progressing with the upload.
Catch the error, and show the originally generated message if
responseText is not valid JSON.
Signed-off-by:
Signed-off-by: Mira Limbeck
---
PVE/CLI/pve8to9.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/CLI/pve8to9.pm b/PVE/CLI/pve8to9.pm
index acf9a3c81..91b50cd9f 100644
--- a/PVE/CLI/pve8to9.pm
+++ b/PVE/CLI/pve8to9.pm
@@ -1561,7 +1561,7 @@ sub check_lvm_autoactivation {
The installer assumes to have a valid mac address for all interfaces
as provided by the runtime env json file. Deserialization will fail
if this is not the case.
In some cases, the interface might however not provide a valid MAC
address, for example the WWAN module without any SIM installed on
som
Am 11.07.25 um 12:03 schrieb Christian Ebner:
> On 7/11/25 11:47, Christoph Heiss wrote:
>> On Fri Jul 11, 2025 at 11:14 AM CEST, Thomas Lamprecht wrote:
>>> Am 11.07.25 um 10:27 schrieb Gabriel Goller:
>> [..]
To be honest I'd rather filter out this interface. A zeroed out mac is
reserve
On 7/11/25 12:25, Thomas Lamprecht wrote:
Am 11.07.25 um 12:03 schrieb Christian Ebner:
On 7/11/25 11:47, Christoph Heiss wrote:
On Fri Jul 11, 2025 at 11:14 AM CEST, Thomas Lamprecht wrote:
Am 11.07.25 um 10:27 schrieb Gabriel Goller:
[..]
To be honest I'd rather filter out this interface.
On 7/11/25 10:03, Christian Ebner wrote:
The installer assumes to have a valid mac address for all interfaces
as provided by the runtime env json file. Deserialization will fail
if this is not the case.
In some cases, the interface might however not provide a valid MAC
address, for example the W
On 7/9/25 09:12, Lukas Wagner wrote:
> The parameter to the gettext function needs to be a static string, otherwise
> xgettext[1,2] cannot
> extract it to generate the .pot file. While the xgettext tool has some basic
> understanding of the
> syntax of supported languages to parse these strings,
On 7/9/25 10:18, Lukas Wagner wrote:
>
> Good point. For v3, I slightly shortened the strings to
>
> "Always send email"
> "Send email on failure"
>
> Also, instead of rendering the recipient addresses in the same field by
> appending them to the string,
> I created a second display field "
[snip]
diff --git a/proxmox-ve-config/src/sdn/fabric/mod.rs
b/proxmox-ve-config/src/sdn/fabric/mod.rs
index 3342a7053d3f..a2132e8aff3f 100644
--- a/proxmox-ve-config/src/sdn/fabric/mod.rs
+++ b/proxmox-ve-config/src/sdn/fabric/mod.rs
@@ -1,11 +1,13 @@
pub mod section_config;
-use std::collectio
On Fri Jul 11, 2025 at 11:14 AM CEST, Thomas Lamprecht wrote:
> Am 11.07.25 um 10:27 schrieb Gabriel Goller:
[..]
>> To be honest I'd rather filter out this interface. A zeroed out mac is
>> reserved for loopback interfaces and usually isn't routed.
>
> It's not like we set the MAC to zero, rather
--- Begin Message ---
Hi Thomas
Am 10.07.25 um 17:46 schrieb DERUMIER, Alexandre:
> I'll try to fix all your comments for next week.
>
> I'm going on holiday end of the next week, the 18th july to around 10
> August, so I think It'll be the last time I can work on it before
> next
> month. But f
On Wed, 09 Jul 2025 10:14:32 +0200, Lukas Wagner wrote:
> The backup job details view was never updated after the overhaul of the
> notification system. In this commit we remove the left-over
> notification-policy/target handling and change the view so that we
> display the current configuration ba
On Wed, 09 Jul 2025 10:14:30 +0200, Lukas Wagner wrote:
> Those were only used in the first iteration of the new notification
> stack, which unfortunately hit pvetest too soon. These two keys have no
> effect and were proactively removed by the GUI when changing
> backup job settings.
>
> With the
On Wed, 09 Jul 2025 10:14:31 +0200, Lukas Wagner wrote:
> These were only used in the 'old' revamped notification stack which was
> briefly available on pvetest. With PVE 9 we can finally get completely
> rid of these.
>
>
Applied, thanks!
[1/2] ui: remove handling of obsolete notification-poli
[snip]
diff --git a/proxmox-ve-config/src/sdn/fabric/mod.rs
b/proxmox-ve-config/src/sdn/fabric/mod.rs
index 007be6a3fd8e..3342a7053d3f 100644
--- a/proxmox-ve-config/src/sdn/fabric/mod.rs
+++ b/proxmox-ve-config/src/sdn/fabric/mod.rs
@@ -1 +1,517 @@
pub mod section_config;
+
+use std::collection
On Fri, Jul 11, 2025 at 11:40:56AM +0200, Gabriel Goller wrote:
> > > [snip]
> > > diff --git a/proxmox-ve-config/src/sdn/fabric/mod.rs
> > > b/proxmox-ve-config/src/sdn/fabric/mod.rs
> > > index 3342a7053d3f..a2132e8aff3f 100644
> > > --- a/proxmox-ve-config/src/sdn/fabric/mod.rs
> > > +++ b/prox
Am 11.07.25 um 10:27 schrieb Gabriel Goller:
> On 11.07.2025 10:03, Christian Ebner wrote:
>> The installer assumes to have a valid mac address for all interfaces
>> as provided by the runtime env json file. Deserialization will fail
>> if this is not the case.
>>
>> In some cases, the interface mi
On Fri, 11 Jul 2025 11:15:16 +0200, Lukas Wagner wrote:
>
Applied, thanks!
[1/1] update apt sources for Trixie based release and move to deb822 format
commit: 82a986ee67ad8ec37ab8f8cae80e900c1d0c3fab
___
pve-devel mailing list
pve-devel@lists.
Starting with PVE 9, we will drop support for GlusterFS entirely [1]
as it is no longer properly maintained upstream [2].
Therefore, scan the storage config and suggest either moving to
different storages or using one's GlusterFS instances as directory
storage if a 'glusterfs' storage is found.
[
This is a breaking change as it affects the answer file fetch payload,
the mac address now being optional. The version is therefore bumped.
The installer assumes to have a valid mac address for all interfaces
as provided by the runtime environment json file. Deserialization
will however fail if th
Adapt error messages around these checks to follow a similar structure
as in the TUI (: ) instead of displaying them as
warnings, since they actually stop users from continuing anyway.
Signed-off-by: Michael Köppl
---
This is mostly to have both the TUI and GUI display actual errors with
context
The requirement of hdsize/4 was not checked anywhere and adding sanity
checks for maxroot<=hdsize/4 would stop users from installing PVE on
smaller disks (see [0]), whereas the installation actually tries its
best to successfully install even on disks below 12GB. So instead of
adding sanity checks,
superseded-by RFC version 3:
https://lore.proxmox.com/pve-devel/20250711153404.995040-1-c.eb...@proxmox.com/T/#u
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
45 matches
Mail list logo
