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 CF28C1FF13E for ; Fri, 06 Feb 2026 11:24:33 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E053B23DCA; Fri, 6 Feb 2026 11:25:05 +0100 (CET) Message-ID: Date: Fri, 6 Feb 2026 11:24:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH container 3/3] setup: make the architecture fall back to amd64 for empty strings To: Daniel Kral , pve-devel@lists.proxmox.com References: <20260204091740.102914-1-d.kral@proxmox.com> <20260204091740.102914-4-d.kral@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <20260204091740.102914-4-d.kral@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1770373392913 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.017 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 Message-ID-Hash: T7AGOWE6QIP3Y53FR4AES57CJG4VT4UM X-Message-ID-Hash: T7AGOWE6QIP3Y53FR4AES57CJG4VT4UM X-MailFrom: f.ebner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Am 04.02.26 um 10:17 AM schrieb Daniel Kral: > Otherwise, if the underlying detect_architecture(...) method returns any > false value, the return value of the call to protected_call(...) will Do you mean undef value here? If I return 0 inside a protected call I get 0 > return an empty string. not an empty string. There seems to be a difference in behavior between being in a nested protected call, which will return the result from the $sub directly, and a non-nested protected call, which reads the result from the pipe, which also results in an empty string when the result from $sub is undef. I think the change here is fine, but we might want to document the behavior for protected call. Or fix up the non-nested case to properly return undef if $sub returns undef. Can be it's own series and will require checking that use sites are happy with the change, but it seems like there's only a small bunch that look at the return value anyways. > This sets the architecture to an empty string and will make the > container fail to start. > > Signed-off-by: Daniel Kral > --- > src/PVE/LXC/Setup.pm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/PVE/LXC/Setup.pm b/src/PVE/LXC/Setup.pm > index 113093d..fb0207e 100644 > --- a/src/PVE/LXC/Setup.pm > +++ b/src/PVE/LXC/Setup.pm > @@ -153,7 +153,7 @@ sub new { > warn "Architecture detection failed: $err" if $err; > } > > - if (!defined($arch)) { > + if (!$arch) { > $arch = 'amd64'; > print "Falling back to $arch.\nUse `pct set VMID --arch ARCH` to change.\n"; > } else {