* [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without @ 2025-07-11 8:03 Christian Ebner 2025-07-11 8:06 ` Christian Ebner ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Christian Ebner @ 2025-07-11 8:03 UTC (permalink / raw) To: pve-devel 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 some laptops. Fix this by defaulting to an all zero MAC address if non is detected. Signed-off-by: Christian Ebner <c.ebner@proxmox.com> --- Please note: Untested, but I can test it based on an iso installer on affected hardware Proxmox/Install/RunEnv.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Proxmox/Install/RunEnv.pm b/Proxmox/Install/RunEnv.pm index e4f0eb0..d7ee258 100644 --- a/Proxmox/Install/RunEnv.pm +++ b/Proxmox/Install/RunEnv.pm @@ -110,7 +110,7 @@ my sub query_netdevs : prototype() { $ifs->{$name} = { index => $index, name => $name, - mac => $mac, + mac => $mac // '00:00:00:00:00:00', state => uc($state), }; $ifs->{$name}->{addresses} = \@valid_addrs if @valid_addrs; -- 2.47.2 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without 2025-07-11 8:03 [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without Christian Ebner @ 2025-07-11 8:06 ` Christian Ebner 2025-07-11 8:27 ` Gabriel Goller 2025-07-11 9:01 ` [pve-devel] superseded: " Christian Ebner 2 siblings, 0 replies; 10+ messages in thread From: Christian Ebner @ 2025-07-11 8:06 UTC (permalink / raw) To: pve-devel 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 WWAN module without any SIM installed on > some laptops. > > Fix this by defaulting to an all zero MAC address if non is detected. > > Signed-off-by: Christian Ebner <c.ebner@proxmox.com> Forgot to add: Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com> _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without 2025-07-11 8:03 [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without Christian Ebner 2025-07-11 8:06 ` Christian Ebner @ 2025-07-11 8:27 ` Gabriel Goller 2025-07-11 8:39 ` Christian Ebner 2025-07-11 9:14 ` Thomas Lamprecht 2025-07-11 9:01 ` [pve-devel] superseded: " Christian Ebner 2 siblings, 2 replies; 10+ messages in thread From: Gabriel Goller @ 2025-07-11 8:27 UTC (permalink / raw) To: Christian Ebner; +Cc: pve-devel 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 the WWAN module without any SIM installed on >some laptops. > >Fix this by defaulting to an all zero MAC address if non is detected. > >Signed-off-by: Christian Ebner <c.ebner@proxmox.com> >--- >Please note: Untested, but I can test it based on an iso installer on >affected hardware > > Proxmox/Install/RunEnv.pm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/Proxmox/Install/RunEnv.pm b/Proxmox/Install/RunEnv.pm >index e4f0eb0..d7ee258 100644 >--- a/Proxmox/Install/RunEnv.pm >+++ b/Proxmox/Install/RunEnv.pm >@@ -110,7 +110,7 @@ my sub query_netdevs : prototype() { > $ifs->{$name} = { > index => $index, > name => $name, >- mac => $mac, >+ mac => $mac // '00:00:00:00:00:00', > state => uc($state), > }; > $ifs->{$name}->{addresses} = \@valid_addrs if @valid_addrs; To be honest I'd rather filter out this interface. A zeroed out mac is reserved for loopback interfaces and usually isn't routed. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without 2025-07-11 8:27 ` Gabriel Goller @ 2025-07-11 8:39 ` Christian Ebner 2025-07-11 9:14 ` Thomas Lamprecht 1 sibling, 0 replies; 10+ messages in thread From: Christian Ebner @ 2025-07-11 8:39 UTC (permalink / raw) To: pve-devel 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 provide a valid MAC >> address, for example the WWAN module without any SIM installed on >> some laptops. >> >> Fix this by defaulting to an all zero MAC address if non is detected. >> >> Signed-off-by: Christian Ebner <c.ebner@proxmox.com> >> --- >> Please note: Untested, but I can test it based on an iso installer on >> affected hardware >> >> Proxmox/Install/RunEnv.pm | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/Proxmox/Install/RunEnv.pm b/Proxmox/Install/RunEnv.pm >> index e4f0eb0..d7ee258 100644 >> --- a/Proxmox/Install/RunEnv.pm >> +++ b/Proxmox/Install/RunEnv.pm >> @@ -110,7 +110,7 @@ my sub query_netdevs : prototype() { >> $ifs->{$name} = { >> index => $index, >> name => $name, >> - mac => $mac, >> + mac => $mac // '00:00:00:00:00:00', >> state => uc($state), >> }; >> $ifs->{$name}->{addresses} = \@valid_addrs if @valid_addrs; > > To be honest I'd rather filter out this interface. A zeroed out mac is > reserved for loopback interfaces and usually isn't routed. Okay, given that it might be better to filter it out and log that. Will send a v2 (including the subject prefix `pve-installer` I did forget on this patch) _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without 2025-07-11 8:27 ` Gabriel Goller 2025-07-11 8:39 ` Christian Ebner @ 2025-07-11 9:14 ` Thomas Lamprecht 2025-07-11 9:47 ` Christoph Heiss 1 sibling, 1 reply; 10+ messages in thread From: Thomas Lamprecht @ 2025-07-11 9:14 UTC (permalink / raw) To: Christian Ebner, pve-devel 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 might however not provide a valid MAC >> address, for example the WWAN module without any SIM installed on >> some laptops. >> >> Fix this by defaulting to an all zero MAC address if non is detected. >> >> Signed-off-by: Christian Ebner <c.ebner@proxmox.com> >> --- >> Please note: Untested, but I can test it based on an iso installer on >> affected hardware >> >> Proxmox/Install/RunEnv.pm | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/Proxmox/Install/RunEnv.pm b/Proxmox/Install/RunEnv.pm >> index e4f0eb0..d7ee258 100644 >> --- a/Proxmox/Install/RunEnv.pm >> +++ b/Proxmox/Install/RunEnv.pm >> @@ -110,7 +110,7 @@ my sub query_netdevs : prototype() { >> $ifs->{$name} = { >> index => $index, >> name => $name, >> - mac => $mac, >> + mac => $mac // '00:00:00:00:00:00', >> state => uc($state), >> }; >> $ifs->{$name}->{addresses} = \@valid_addrs if @valid_addrs; > > 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 it's just used for displaying. This way an admin can at least see the interface and select it for usage, even if they then need to correctly configure it manually after installation to make it actually work. That said, as manual intervention is required either way, filtering out might be OK, but your arguments here are IMO not justifying why that route should be chosen. FWIW, a third alternative might be that the rust implementation might also just have to learn to not expect a MAC... _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without 2025-07-11 9:14 ` Thomas Lamprecht @ 2025-07-11 9:47 ` Christoph Heiss 2025-07-11 10:03 ` Christian Ebner 0 siblings, 1 reply; 10+ messages in thread From: Christoph Heiss @ 2025-07-11 9:47 UTC (permalink / raw) To: Proxmox VE development discussion 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 it's just used for displaying. > This way an admin can at least see the interface and select it for usage, > even if they then need to correctly configure it manually after installation > to make it actually work. > > That said, as manual intervention is required either way, filtering out > might be OK, but your arguments here are IMO not justifying why that route > should be chosen. FWIW, a third alternative might be that the rust > implementation might also just have to learn to not expect a MAC... FWIW, there's also been a Bugzilla report a few days about this problem [0]. I've took a cursory glance at going about the third route here, although didn't really get to write much code due to other, more pressing things. If anyone wants to pick that up, short summary w.r.t the Rust part: - It's mostly about doing a `String` -> `Option<String>` conversion for `proxmox_installer_common::setup::Interface`, the MAC address from that is then only ever used the post-hook. - There's also `proxmox_auto_installer::sysinfo::NetdevWithMac`, which tries to read the MAC address from /sys/class/net. [0] https://bugzilla.proxmox.com/show_bug.cgi?id=6508 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without 2025-07-11 9:47 ` Christoph Heiss @ 2025-07-11 10:03 ` Christian Ebner 2025-07-11 10:25 ` Thomas Lamprecht 0 siblings, 1 reply; 10+ messages in thread From: Christian Ebner @ 2025-07-11 10:03 UTC (permalink / raw) To: Proxmox VE development discussion, Christoph Heiss 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 like we set the MAC to zero, rather it's just used for displaying. >> This way an admin can at least see the interface and select it for usage, >> even if they then need to correctly configure it manually after installation >> to make it actually work. >> >> That said, as manual intervention is required either way, filtering out >> might be OK, but your arguments here are IMO not justifying why that route >> should be chosen. FWIW, a third alternative might be that the rust >> implementation might also just have to learn to not expect a MAC... > > FWIW, there's also been a Bugzilla report a few days about this problem > [0]. > > I've took a cursory glance at going about the third route here, although > didn't really get to write much code due to other, more pressing things. > > If anyone wants to pick that up, short summary w.r.t the Rust part: > > - It's mostly about doing a `String` -> `Option<String>` conversion for > `proxmox_installer_common::setup::Interface`, the MAC address from > that is then only ever used the post-hook. > - There's also `proxmox_auto_installer::sysinfo::NetdevWithMac`, which > tries to read the MAC address from /sys/class/net. > > [0] https://bugzilla.proxmox.com/show_bug.cgi?id=6508 Okay, can have a look at this too, but do feel free to beat me to it! Not so familiar with the installer codebase and this smells like having some regression potential. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without 2025-07-11 10:03 ` Christian Ebner @ 2025-07-11 10:25 ` Thomas Lamprecht 2025-07-11 10:31 ` Christian Ebner 0 siblings, 1 reply; 10+ messages in thread From: Thomas Lamprecht @ 2025-07-11 10:25 UTC (permalink / raw) To: Proxmox VE development discussion, Christian Ebner, Christoph Heiss 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 >>>> reserved for loopback interfaces and usually isn't routed. >>> >>> It's not like we set the MAC to zero, rather it's just used for displaying. >>> This way an admin can at least see the interface and select it for usage, >>> even if they then need to correctly configure it manually after installation >>> to make it actually work. >>> >>> That said, as manual intervention is required either way, filtering out >>> might be OK, but your arguments here are IMO not justifying why that route >>> should be chosen. FWIW, a third alternative might be that the rust >>> implementation might also just have to learn to not expect a MAC... >> >> FWIW, there's also been a Bugzilla report a few days about this problem >> [0]. >> >> I've took a cursory glance at going about the third route here, although >> didn't really get to write much code due to other, more pressing things. >> >> If anyone wants to pick that up, short summary w.r.t the Rust part: >> >> - It's mostly about doing a `String` -> `Option<String>` conversion for >> `proxmox_installer_common::setup::Interface`, the MAC address from >> that is then only ever used the post-hook. >> - There's also `proxmox_auto_installer::sysinfo::NetdevWithMac`, which >> tries to read the MAC address from /sys/class/net. >> >> [0] https://bugzilla.proxmox.com/show_bug.cgi?id=6508 > > Okay, can have a look at this too, but do feel free to beat me to it! > Not so familiar with the installer codebase and this smells like having > some regression potential. Yeah, maybe, that's why simply falling back to some "unknown"-like value sounded promising to me. If we do not have any parsing/checks for the MAC value, we could indeed fall back to a literal "unknown", then it would be noticed if we try to use it (e.g., for interface link name-pinning in the installer) btw. what does the interface looks like, does it really have no MAC in the ip link output? _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without 2025-07-11 10:25 ` Thomas Lamprecht @ 2025-07-11 10:31 ` Christian Ebner 0 siblings, 0 replies; 10+ messages in thread From: Christian Ebner @ 2025-07-11 10:31 UTC (permalink / raw) To: Thomas Lamprecht, Proxmox VE development discussion, Christoph Heiss 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. 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 it's just used for displaying. >>>> This way an admin can at least see the interface and select it for usage, >>>> even if they then need to correctly configure it manually after installation >>>> to make it actually work. >>>> >>>> That said, as manual intervention is required either way, filtering out >>>> might be OK, but your arguments here are IMO not justifying why that route >>>> should be chosen. FWIW, a third alternative might be that the rust >>>> implementation might also just have to learn to not expect a MAC... >>> >>> FWIW, there's also been a Bugzilla report a few days about this problem >>> [0]. >>> >>> I've took a cursory glance at going about the third route here, although >>> didn't really get to write much code due to other, more pressing things. >>> >>> If anyone wants to pick that up, short summary w.r.t the Rust part: >>> >>> - It's mostly about doing a `String` -> `Option<String>` conversion for >>> `proxmox_installer_common::setup::Interface`, the MAC address from >>> that is then only ever used the post-hook. >>> - There's also `proxmox_auto_installer::sysinfo::NetdevWithMac`, which >>> tries to read the MAC address from /sys/class/net. >>> >>> [0] https://bugzilla.proxmox.com/show_bug.cgi?id=6508 >> >> Okay, can have a look at this too, but do feel free to beat me to it! >> Not so familiar with the installer codebase and this smells like having >> some regression potential. > > Yeah, maybe, that's why simply falling back to some "unknown"-like value > sounded promising to me. If we do not have any parsing/checks for the MAC > value, we could indeed fall back to a literal "unknown", then it would be > noticed if we try to use it (e.g., for interface link name-pinning in the > installer) > > btw. what does the interface looks like, does it really have no MAC > in the ip link output? No, the only content for the link line is `link/none`, no mac and brd address. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* [pve-devel] superseded: [PATCH] run-env: fallback to all zero mac for interfaces without 2025-07-11 8:03 [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without Christian Ebner 2025-07-11 8:06 ` Christian Ebner 2025-07-11 8:27 ` Gabriel Goller @ 2025-07-11 9:01 ` Christian Ebner 2 siblings, 0 replies; 10+ messages in thread From: Christian Ebner @ 2025-07-11 9:01 UTC (permalink / raw) To: pve-devel superseded-by version 2: https://lore.proxmox.com/pve-devel/30178a02-c6a4-4cb5-b5e7-f421dde03245@proxmox.com/T/ _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2025-07-11 10:30 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-07-11 8:03 [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without Christian Ebner 2025-07-11 8:06 ` Christian Ebner 2025-07-11 8:27 ` Gabriel Goller 2025-07-11 8:39 ` Christian Ebner 2025-07-11 9:14 ` Thomas Lamprecht 2025-07-11 9:47 ` Christoph Heiss 2025-07-11 10:03 ` Christian Ebner 2025-07-11 10:25 ` Thomas Lamprecht 2025-07-11 10:31 ` Christian Ebner 2025-07-11 9:01 ` [pve-devel] superseded: " Christian Ebner
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.