From owner-freebsd-hackers@freebsd.org Fri Nov 30 16:45:14 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 244E7114955A for ; Fri, 30 Nov 2018 16:45:14 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A77D6BED5 for ; Fri, 30 Nov 2018 16:45:12 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Fri, 30 Nov 2018 17:45:10 +0100 id 00DB9422.5C016916.0000BB37 Date: Fri, 30 Nov 2018 17:45:10 +0100 From: Milan Obuch To: Warner Losh 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: References: <20181130151820.1a197589@zeta.dino.sk> X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; i386-portbld-freebsd10.4) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1A77D6BED5 X-Spamd-Result: default: False [-0.61 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.895,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.80)[-0.800,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dino.sk]; NEURAL_SPAM_SHORT(0.39)[0.390,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mail.dino.sk]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.01)[country: SK(0.03)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:16160, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 16:45:14 -0000 On Fri, 30 Nov 2018 09:23:31 -0700 Warner Losh wrote: > On Fri, Nov 30, 2018 at 7:26 AM Milan Obuch > 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