From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by mx.groups.io with SMTP id smtpd.web12.562.1666127858343265496 for ; Tue, 18 Oct 2022 14:17:38 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=eUaLoFF3; spf=pass (domain: gmail.com, ip: 209.85.214.175, mailfrom: pedro.falcato@gmail.com) Received: by mail-pl1-f175.google.com with SMTP id b2so15045554plc.7; Tue, 18 Oct 2022 14:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=b4KiOl7Dw88fVyHKxartz539rLrwbBd8ariE+wVmtuY=; b=eUaLoFF3V9qaaeE56tUkuy2Q4pm5EadNB/0w00LATBgjc1JrtfFnBXURJB8bcZxVyS XueVtmr1m7i3yvgsBo/tEVCqSVr5IW9i6A5NxpLBkNUMxJew1qoI4hOJ344eDLp8xwPL raz8ZhHQWVjIGDzk1rTNypMEHEmTNhQUWDHU/7rOAWbJOwIwvhRCuV/HPFQJ8+ganvXC idGhbznOVH0Gp5QvOnn5xsYRxR2q1OwQDarOtQFvdnpHtPFqIvFPUDWv3TfSI1ijacto VOWrNeyYMeE/33/M4JiDX/M73hA5BNecAqfN0ywDtx5FyT2MBTLHjs/2vdvwslLeJtLa u76w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=b4KiOl7Dw88fVyHKxartz539rLrwbBd8ariE+wVmtuY=; b=oBdV78dQZnPpyw6Bf+nkQ/wY3TDXyLtRDBkZhOS2GFGOUUdre8NqvX8PIWxA9DIvUP exczykaEfvaKJpIwsSKvpXnczxGUPrCj+xGO+R0qj/viMm8FyhowIcsGn98Z1FU/vtAw NGFCWyCeI+oWLo8giO5L3p8I7Rs23gfZQhEoDAPyfwniFos0RosqfODxR3/Kxqg1ReT7 2kq/ZUdO6hYWyLWjZtyFZhdZQ0L+QFkzGcx6pa+AC4LcqFbKeks+DZXtta6rWcEAXh0k 9BYojjO/fHEXRWGS3q21PsYghQn+zfgzUlnUSgZ53CKRi6rMDJ3UpkJpZiuWujx0/R6n SPgg== X-Gm-Message-State: ACrzQf0LmZAXh/ChBIKjPP9k0r1/qgBV60sgzo+BMUYfopMr4vNTfk7r pkpP1rnGMKAq/Md+KWHS/FMUI9dZ5EvJ5ifcM/ZCy7qcOIY= X-Google-Smtp-Source: AMsMyM56dChjcoHpmlKktEQqkkwyADhBMqU9TeZZVs/LT5pL21fplfgbUiJYjDDRXYEPhU1o1K+Pgnj+WikmKKbbZwg= X-Received: by 2002:a17:902:f687:b0:185:4163:3368 with SMTP id l7-20020a170902f68700b0018541633368mr5200003plg.25.1666127857533; Tue, 18 Oct 2022 14:17:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Pedro Falcato" Date: Tue, 18 Oct 2022 22:17:25 +0100 Message-ID: Subject: Re: [edk2-rfc] Boot Order not persistent : UEFI variables not getting stored in NVRAM disk ? To: rfc@edk2.groups.io, het.gala@nutanix.com Cc: edk2-devel-groups-io Content-Type: multipart/alternative; boundary="00000000000019495005eb559fb3" --00000000000019495005eb559fb3 Content-Type: text/plain; charset="UTF-8" PS: With "emulates" I mean that it uses RAM to store variables. This naturally ends up getting cleared on a reboot, which is possibly what you're seeing. On Tue, Oct 18, 2022 at 10:16 PM Pedro Falcato wrote: > Hi, > > (cc devel) > NVRAM has nothing to do with disks or EFI partitions. > Are you using OVMF? How are you using it? OVMF itself emulates variable > storage if you run it in the wrong way. > > On Tue, Oct 18, 2022 at 4:00 PM wrote: > >> Hi EDK2 community, >> >> I have a used case, where I am trying to change boot order for multiboot >> (multiple OS) systems and for singleboot systems. I was able to change the >> boot order and set auto boot time-out only if there is EFI partition >> available in a disk. The boot order is not persisted i.e. on a VM reboot, >> the boot order sets back to default in absence of disk or EFI partition in >> disk. Even though there is a NVRAM disk available, I am not able to change >> the boot order in UEFI firmware settings. So, I have a couple of doubts >> regarding this, so decided to start with a discussion. >> 1. Is it necessary to have EFI partition in disks to store UEFI variables >> like boot order / auto boot time-out and others ? >> 2. Does the workflow of OVMF demands to store the UEFI variables only >> into EFI partition and not into NVRAM disk ? >> >> >> >> >> >> > > -- > Pedro Falcato > -- Pedro Falcato --00000000000019495005eb559fb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
PS: With "emulates" I mean that it uses RAM to s= tore variables. This naturally ends up getting cleared on a reboot, which i= s possibly what you're seeing.

=
On Tue, Oct 18, 2022 at 10:16 PM Pedr= o Falcato <pedro.falcato@gmai= l.com> wrote:
Hi,

(cc devel)
NVRAM has nothing to do with disks or EFI partitions.
Are y= ou using OVMF? How are you using it? OVMF itself emulates variable storage = if you run it in the wrong way.

On Tue, Oct 18, 2022 at 4:00 PM &l= t;het.gala@nutani= x.com> wrote:
Hi EDK2 community,

I have a used case, where I am trying to change boot order for multiboot (m= ultiple OS) systems and for singleboot systems. I was able to change the bo= ot order and set auto boot time-out only if there is EFI partition availabl= e in a disk. The boot order is not persisted i.e. on a VM reboot, the boot = order sets back to default in absence of disk or EFI partition in disk. Eve= n though there is a NVRAM disk available, I am not able to change the boot = order in UEFI firmware settings. So, I have a couple of doubts regarding th= is, so decided to start with a discussion.
1. Is it necessary to have EFI partition in disks to store UEFI variables l= ike boot order / auto boot time-out and others ?
2. Does the workflow of OVMF demands to store the UEFI variables only into = EFI partition and not into NVRAM disk ?







--
Pedro Falcato


--
Pedro Falcato
--00000000000019495005eb559fb3--