From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id E257D1FF15C for ; Fri, 11 Jul 2025 11:47:11 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 995C9CD00; Fri, 11 Jul 2025 11:47:56 +0200 (CEST) Mime-Version: 1.0 Date: Fri, 11 Jul 2025 11:47:23 +0200 Message-Id: From: "Christoph Heiss" To: "Proxmox VE development discussion" X-Mailer: aerc 0.20.1 References: <20250711080302.163858-1-c.ebner@proxmox.com> <55101ee3-e736-49cc-b50b-768e6a7ad0f4@proxmox.com> In-Reply-To: <55101ee3-e736-49cc-b50b-768e6a7ad0f4@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.030 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" 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` 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