Date: Wed, 12 Dec 2018 12:53:14 +0100 From: Milan Obuch <freebsd-hackers@dino.sk> Cc: freebsd-hackers@freebsd.org Subject: Re: EFI boot with multiple alternate boot/OS partitions - possible? Message-ID: <20181212125314.75464bac@zeta.dino.sk> In-Reply-To: <20181130174510.2944ffae@zeta.dino.sk> References: <20181130151820.1a197589@zeta.dino.sk> <CANCZdfqZtTS6qyJNRXfXdwWdd_expzGeNy0ON7GH-H2OxUjn3w@mail.gmail.com> <20181130174510.2944ffae@zeta.dino.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 30 Nov 2018 17:45:10 +0100
Milan Obuch <freebsd-hackers@dino.sk> wrote:
> On Fri, 30 Nov 2018 09:23:31 -0700
> Warner Losh <imp@bsdimp.com> wrote:
>
> > On Fri, Nov 30, 2018 at 7:26 AM Milan Obuch
> > <freebsd-hackers@dino.sk> wrote:
[ snip ]
> > > Then partitions' roles are swapped, as /etc/fstab file in now
> > > active secondary partition would be
> > >
> > > # Device Mountpoint FStype Options Dump Pass#
> > > /dev/sdda0p2 /alt ufs ro 2 2
> > > /dev/sdda0p3 / ufs ro 1 1
> > > /dev/sdda0p4 none swap sw 0 0
> > >
> > > Any ideas/hints would be appreciated, I tried to look into
> > > efibootmgr and efivar man pages, but got no clear idea how they
> > > could be used for my purpose. I do not fully understand some
> > > details of EFI boot process, so if some good material for reading
> > > is available, let me know (I did some googling, but found no
> > > definitive answers yet).
> >
> > efibootmgr is what you want, though if it's under-documented we
> > should fix that. Assuming that p1 is the ESP, you should be able to
> > do:
> >
> > efibootmgr -c -l ssd0p1:/efi/freebsd/loader.efi -k
> > ssd0p3:/boot/kernel/kernel -b 10 -a
> > efibootmgr -c -l ssd0p1:/efi/freebsd/loader.efi -k
> > ssd0p2:/boot/kernel/kernel -b 11 -a
> >
> > this will setup Boot0010 and Boot0011.
> >
> > You can then set the order either with efibootmgr -o or efibootmgr
> > -n. In theory you can also use the full unix path for the -k and -l
> > lines if things are mounted, but I hadn't fixed all the weird edge
> > cases with that which kept cropping up (I think they are are fixed
> > since I can't recreate the problems, but I'm not 100% sure).
> >
>
> Thank you for quick reply! Yes, this looks really well, so I test what
> you wrote to verify it (and learn a bit more, again). This just fills
> one gap in my undestanding the process of UEFI boot. I try to read our
> man pages again, and if verified successfully, write something to
> document this usage.
>
I experiment a bit with it, command arguments need slight modification:
efibootmgr -c -l sdda0p1:/efi/boot/bootx64.efi -k sdda0p2:/boot/kernel/kernel -a Boot0003
There is a complaint when trying to use -b option, rejected as invalid
option. Also -a option requires argument, so I ended with the command I
wrote. This is usable for my purpose.
I do not understand in detail variable behavior... First, I have
following:
efibootmgr -v
BootCurrent: 0004
Timeout : 1 seconds
BootOrder : 0004, 0001, 0000, 0002
+Boot0004* HD(1,GPT,22d32889-ec10-11e8-8f99-00073249ad88,0x28,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)
sdda0p1:/EFI/BOOT/BOOTX64.EFI (null)
HD(3,GPT,32401f28-ec10-11e8-8f99-00073249ad88,0x364028,0x300000)/File(\boot\kernel\kernel)
sdda0p3:/boot/kernel/kernel //boot/kernel/kernel
Boot0001 UEFI: Built-in EFI Shell VenMedia(5023b95c-db26-429b-a648-bd47664c8012)
Boot0000 Windows Boot Manager VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
HD(2,GPT,02c27b37-4fb4-4890-8382-f4d25a60f5e9,0xe1800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)
Boot0002 ubuntu VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
HD(1,GPT,dc7cd941-1c91-4076-89db-2650d73ef7a5,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)
Then, after issuing command to create new variable, I got
efibootmgr -v
BootCurrent: 0004
Timeout : 1 seconds
BootOrder : 0003, 0004, 0001, 0000, 0002
Boot0003* HD(1,GPT,22d32889-ec10-11e8-8f99-00073249ad88,0x28,0x64000)/File(\efi\boot\bootx64.efi)
sdda0p1:/efi/boot/bootx64.efi (null)
HD(2,GPT,d8ae0cb4-ec14-11e8-8041-00073249ad88,0x64028,0x300000)/File(\boot\kernel\kernel)
sdda0p2:/boot/kernel/kernel /alt//boot/kernel/kernel
+Boot0004* HD(1,GPT,22d32889-ec10-11e8-8f99-00073249ad88,0x28,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)
sdda0p1:/EFI/BOOT/BOOTX64.EFI (null)
HD(3,GPT,32401f28-ec10-11e8-8f99-00073249ad88,0x364028,0x300000)/File(\boot\kernel\kernel)
sdda0p3:/boot/kernel/kernel //boot/kernel/kernel
Boot0001 UEFI: Built-in EFI Shell VenMedia(5023b95c-db26-429b-a648-bd47664c8012)
Boot0000 Windows Boot Manager VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
HD(2,GPT,02c27b37-4fb4-4890-8382-f4d25a60f5e9,0xe1800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)
Boot0002 ubuntu VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
HD(1,GPT,dc7cd941-1c91-4076-89db-2650d73ef7a5,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)
This changes partition used for system load, but after reboot, I am
getting
efibootmgr -v
BootCurrent: 0003
Timeout : 1 seconds
BootOrder : 0003, 0001, 0000, 0002
+Boot0003* HD(1,GPT,22d32889-ec10-11e8-8f99-00073249ad88,0x28,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)
sdda0p1:/EFI/BOOT/BOOTX64.EFI (null)
HD(2,GPT,d8ae0cb4-ec14-11e8-8041-00073249ad88,0x64028,0x300000)/File(\boot\kernel\kernel)
sdda0p2:/boot/kernel/kernel //boot/kernel/kernel
Boot0001 UEFI: Built-in EFI Shell VenMedia(5023b95c-db26-429b-a648-bd47664c8012)
Boot0000 Windows Boot Manager VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
HD(2,GPT,02c27b37-4fb4-4890-8382-f4d25a60f5e9,0xe1800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)
Boot0002 ubuntu VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
HD(1,GPT,dc7cd941-1c91-4076-89db-2650d73ef7a5,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)
which means original Boot0004 is lost. This is not a big deal, I just
thought boot variables are being kept once defined, so it is necessary
just switch active one, but if it needs new definition when partition
swap is desired again, it is just a line in a script, so no trouble at
all.
Thanks again and regards,
Milan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181212125314.75464bac>