From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <m.heiserer@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 2832395E0B for <pve-devel@lists.proxmox.com>; Fri, 20 Jan 2023 15:18:53 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0AB0C8553 for <pve-devel@lists.proxmox.com>; Fri, 20 Jan 2023 15:18:23 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Fri, 20 Jan 2023 15:18:22 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id D9761455B3 for <pve-devel@lists.proxmox.com>; Fri, 20 Jan 2023 15:18:21 +0100 (CET) Message-ID: <7c9ad1b0-f02e-9eb0-19b5-836e18e2441f@proxmox.com> Date: Fri, 20 Jan 2023 15:18:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Content-Language: en-US To: Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20230117121723.65246-1-m.heiserer@proxmox.com> <197294f6-2746-37bc-4b88-8b09679b4ba0@proxmox.com> <410d44a8-95d2-7f99-61fb-8018b49e4df8@proxmox.com> <30584935-e2b2-c04a-0df2-ff2378a727f7@proxmox.com> From: Matthias Heiserer <m.heiserer@proxmox.com> In-Reply-To: <30584935-e2b2-c04a-0df2-ff2378a727f7@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.362 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment KAM_NUMSUBJECT 0.5 Subject ends in numbers excluding current years NICE_REPLY_A -0.094 Looks like a legit reply (A) 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. [qemuserver.pm, proxmox.com] Subject: Re: [pve-devel] [PATCH manager 1/2] GUI: efi disk: use correct version with aarch64 X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Fri, 20 Jan 2023 14:18:53 -0000 On 20.01.2023 14:17, Thomas Lamprecht wrote: > Am 20/01/2023 um 13:56 schrieb Matthias Heiserer: >> On 18.01.2023 15:07, Thomas Lamprecht wrote: >>> for subject: s/GUI/ui/ to better match the predominantly used one. >>> >>> Am 17/01/2023 um 13:17 schrieb Matthias Heiserer: >>>> Sets the EFI version to 2m when arch=aarch64. >>>> >>>> When the VM has arch=aarch64, creating an EFI disk failed with >>>> "Can't use an undefined value as an ARRAY reference at /usr/share/perl5/PVE/QemuServer.pm line 3382. (500)" >>>> >>>> That's because we only have EFI 2m available for aarch64. >>>> >>>> Reported in the forum: https://forum.proxmox.com/threads/121160/ >>>> >>> >>> If we go this route I'd also enforce using the correct one when changing >>> or creating VMs via the API. >> When creating via the API (and not setting a type) the default is used, which works with aarch64. Only if 4m is explicitly set, it errors. >> The ui user can't set the version, that's why I changed it there. > > but your quoted error makes it obvious that the backend doesn't really > catches the illegal combination explicitly, or am I'm missing something? > Sorry, maybe I misunderstood you. Yes, the backend fails with a worse message than it should, but it does fail. Changing the error wouldn't hurt though. >> >>> >>> Two possible alternatives: >>> - auto-select the existing one in the backend; drawback: if we ever add >>> another size for the AAVMF image we need to take extra/special care to >>> avoid breaking old systems. > >>> - build also an AAVMF image with 4MB, but one would need to check if this >>> is really possible in the first place or if there are other drawbacks. >> To me, the second option seems better, should it work. >> I don't like the idea of letting the user provide a parameter and silently ignoring it. > > yeah, I'd favor that one too I'll have a look at it