Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Nov 2018 17:45:10 +0100
From:      Milan Obuch <freebsd-hackers@dino.sk>
To:        Warner Losh <imp@bsdimp.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: EFI boot with multiple alternate boot/OS partitions - possible?
Message-ID:  <20181130174510.2944ffae@zeta.dino.sk>
In-Reply-To: <CANCZdfqZtTS6qyJNRXfXdwWdd_expzGeNy0ON7GH-H2OxUjn3w@mail.gmail.com>
References:  <20181130151820.1a197589@zeta.dino.sk> <CANCZdfqZtTS6qyJNRXfXdwWdd_expzGeNy0ON7GH-H2OxUjn3w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 ]

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181130174510.2944ffae>