EFI boot with multiple alternate boot/OS partitions - possible?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

EFI boot with multiple alternate boot/OS partitions - possible?

Milan Obuch-22
Hi,

I am working on a project using relatively simple workstation,
basically web browser with custom backend, running page with javascript
communicating with said backend to display status of some processes
(customer's technology aka real world) being supervised. Current
prototype uses UP2 board with 32 GB eMMC, where EFI BIOS is used.

So far so good, everything runs to project manager's satisfaction, just
there is one problem to solve - UPS is not used in order to keep
installation simpler and cost lower, so I need to find a way how to run
everything from read-only mounted file systems, but occasional update
could be requested.

It is manageable when dealing with application/libraries, both from
ports and custom programms, but if OS partition is to be upgraded,
maybe for security reason or the like, power outage in wrong instant
could render whole system unusable. In order to minimise risks with
such an upgrade, I would like to employ following scheme:

(partial partition layout from gpart show)

        40    409600      1  efi  (200M)
    409640   3145728      2  freebsd-ufs  (1.5G)
   3555368   3145728      3  freebsd-ufs  (1.5G)
   6701096   8388608      4  freebsd-swap  (4.0G)

(other partition for application data, cache etc)

with /etc/fstab corresponding part being

# Device      Mountpoint  FStype  Options  Dump  Pass#
/dev/sdda0p2  /           ufs     ro       1     1
/dev/sdda0p3  /alt        ufs     ro       2     2
/dev/sdda0p4  none        swap    sw       0     0

When upgrade request is being handled, /alt filesystem is being remount
with read-write access, receives whole OS installation, relevant config
files in /etc directory are being copied into /alt/etc directory,
resulting in usable alternate OS copy. This can be verified for
accuracy etc. and system should be switched to use partition 3 for
next boot, something like nextboot command with -k option makes, but
whole partition, not just directory with kernel is switched...

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).

Or should I modify my partitions by inserting second efi, so the result
would be like

        40    409600      1  efi  (200M)
    409640   3145728      2  freebsd-ufs  (1.5G)
   xxxxx68    409600      3  efi  (200M)
   xxxxx68   3145728      4  freebsd-ufs  (1.5G)
   xxxxx96   8388608      5  freebsd-swap  (4.0G)

and EFI BIOS will see those two efi partitions as two independent
systems allowing me to switch them with some BootOrder vars? I would
like to avoid having two efi partitions, 200 MB basically wasted space
is not too much in today's devices, but as the whole eMMC is 32 GB in
size, it is not negligible, it could be missed sometimes...

Regards,
Milan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: EFI boot with multiple alternate boot/OS partitions - possible?

Warner Losh
On Fri, Nov 30, 2018 at 7:26 AM Milan Obuch <[hidden email]> wrote:

> Hi,
>
> I am working on a project using relatively simple workstation,
> basically web browser with custom backend, running page with javascript
> communicating with said backend to display status of some processes
> (customer's technology aka real world) being supervised. Current
> prototype uses UP2 board with 32 GB eMMC, where EFI BIOS is used.
>
> So far so good, everything runs to project manager's satisfaction, just
> there is one problem to solve - UPS is not used in order to keep
> installation simpler and cost lower, so I need to find a way how to run
> everything from read-only mounted file systems, but occasional update
> could be requested.
>
> It is manageable when dealing with application/libraries, both from
> ports and custom programms, but if OS partition is to be upgraded,
> maybe for security reason or the like, power outage in wrong instant
> could render whole system unusable. In order to minimise risks with
> such an upgrade, I would like to employ following scheme:
>
> (partial partition layout from gpart show)
>
>         40    409600      1  efi  (200M)
>     409640   3145728      2  freebsd-ufs  (1.5G)
>    3555368   3145728      3  freebsd-ufs  (1.5G)
>    6701096   8388608      4  freebsd-swap  (4.0G)
>
> (other partition for application data, cache etc)
>
> with /etc/fstab corresponding part being
>
> # Device      Mountpoint  FStype  Options  Dump  Pass#
> /dev/sdda0p2  /           ufs     ro       1     1
> /dev/sdda0p3  /alt        ufs     ro       2     2
> /dev/sdda0p4  none        swap    sw       0     0
>
> When upgrade request is being handled, /alt filesystem is being remount
> with read-write access, receives whole OS installation, relevant config
> files in /etc directory are being copied into /alt/etc directory,
> resulting in usable alternate OS copy. This can be verified for
> accuracy etc. and system should be switched to use partition 3 for
> next boot, something like nextboot command with -k option makes, but
> whole partition, not just directory with kernel is switched...
>
> 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).

Extra caveat: This only works for UEFI implementations that have persistent
env vars. And non-broken UEFI BootMgr implementations. Supermicro has a
broken one that one needs to work around in various ugly ways (they won't
fix it, since they think it's a feature, but they are wrong).

Warner


> Or should I modify my partitions by inserting second efi, so the result
> would be like
>
>         40    409600      1  efi  (200M)
>     409640   3145728      2  freebsd-ufs  (1.5G)
>    xxxxx68    409600      3  efi  (200M)
>    xxxxx68   3145728      4  freebsd-ufs  (1.5G)
>    xxxxx96   8388608      5  freebsd-swap  (4.0G)
>
> and EFI BIOS will see those two efi partitions as two independent
> systems allowing me to switch them with some BootOrder vars? I would
> like to avoid having two efi partitions, 200 MB basically wasted space
> is not too much in today's devices, but as the whole eMMC is 32 GB in
> size, it is not negligible, it could be missed sometimes...
>
> Regards,
> Milan
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: EFI boot with multiple alternate boot/OS partitions - possible?

Milan Obuch-22
On Fri, 30 Nov 2018 09:23:31 -0700
Warner Losh <[hidden email]> wrote:

> On Fri, Nov 30, 2018 at 7:26 AM Milan Obuch <[hidden email]>
> wrote:

[ snip ]

> > It is manageable when dealing with application/libraries, both from
> > ports and custom programms, but if OS partition is to be upgraded,
> > maybe for security reason or the like, power outage in wrong instant
> > could render whole system unusable. In order to minimise risks with
> > such an upgrade, I would like to employ following scheme:
> >
> > (partial partition layout from gpart show)
> >
> >         40    409600      1  efi  (200M)
> >     409640   3145728      2  freebsd-ufs  (1.5G)
> >    3555368   3145728      3  freebsd-ufs  (1.5G)
> >    6701096   8388608      4  freebsd-swap  (4.0G)
> >
> > (other partition for application data, cache etc)
> >
> > with /etc/fstab corresponding part being
> >
> > # Device      Mountpoint  FStype  Options  Dump  Pass#
> > /dev/sdda0p2  /           ufs     ro       1     1
> > /dev/sdda0p3  /alt        ufs     ro       2     2
> > /dev/sdda0p4  none        swap    sw       0     0
> >
> > When upgrade request is being handled, /alt filesystem is being
> > remount with read-write access, receives whole OS installation,
> > relevant config files in /etc directory are being copied
> > into /alt/etc directory, resulting in usable alternate OS copy.
> > This can be verified for accuracy etc. and system should be
> > switched to use partition 3 for next boot, something like nextboot
> > command with -k option makes, but whole partition, not just
> > directory with kernel is switched...
> >
> > 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.

Once again, big thanks!

Regards,
Milan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: EFI boot with multiple alternate boot/OS partitions - possible?

Milan Obuch-22
On Fri, 30 Nov 2018 17:45:10 +0100
Milan Obuch <[hidden email]> wrote:

> On Fri, 30 Nov 2018 09:23:31 -0700
> Warner Losh <[hidden email]> wrote:
>
> > On Fri, Nov 30, 2018 at 7:26 AM Milan Obuch
> > <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"