From owner-freebsd-hackers@freebsd.org Fri Nov 30 16:23:45 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 B41D211486E5 for ; Fri, 30 Nov 2018 16:23:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA7416AB79 for ; Fri, 30 Nov 2018 16:23:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82e.google.com with SMTP id n21so6499611qtl.6 for ; Fri, 30 Nov 2018 08:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FouAgSzZz9mK1qzGMjzHP8olxPuQcnKJ3nPTYCuonCw=; b=Hu00TdQ2Z4HgjO0/rKJihpbGjokFsd1vjsp0WtFZmzIFd0NKxFIGlx/uBMQkP7FTpS MH71JniTEzPYeOknQWy+nDm4nt8XzSwj2To/x8njRqg0bjVWLVB/8iRaPG1FHmvc4DX8 JsfH/tFWqErYN4vYacvWzevVN9TjRd7Q7l0H6e5+zbAoOLLc5EbNdAKUHVBnvz6y5YGW qdjFvvlgGjJRXg4p6tAw6fqZ+k2gkux6D7gQqgPZyfk6qQtOR72H51/FKBYsaYnQXRAi oHT3jn8or2Q0lGt+/4aTWiMpVHsHH1hEEOMwBqhPsFrdoTw8gvdCON8f7bq3cXzdoW3c ouqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FouAgSzZz9mK1qzGMjzHP8olxPuQcnKJ3nPTYCuonCw=; b=glggN34m9X5COmAVRpXDJT/e7PlAhgbMRm7CxuR6tkHNmd7zw8kuA4yeAI2MVIAMWo 8Z2KNoaF0MVph8GjTt1uEEdPV0FNveyOdWmz0HfGSSeEyb+U3UA5gsSWRqgBn10Utelq fzpKXIwfhMOCazpitGS08/R8EnjRWuAqmfisyeme66KXgJ+8tXi4Ct3mOu/PvWtGVUz9 ZX1MCW1vinVPqcOJFuNRSE6i7gOm8PnhxC+dpmnTncOMqhy4on8/wRk2GBQfhEJdDGtq INksHSCaOzyX8JyfO/rFY7bwTwc1438EodcfUkXHUFkUBz0w8GvKgApBCvs6jwJC1PB0 keAQ== X-Gm-Message-State: AA+aEWb/p2M5qKfMqYRz19qAuLjG8zdNL4g7QUByVjvSt4IUARxOnITQ CNCeGBVxHYkIXCm0aDj5YfRqDHcJ3YhnOPGOxNTduDOz X-Google-Smtp-Source: AFSGD/WFYx//nVzX+Q+t9oszp1AKwPQ3ZPaqbRCD7YgtlctMbGvuGSP/OVlFxylSc4gYjU0NbuLiTA8XpkQnjH5hMjc= X-Received: by 2002:a05:6214:1087:: with SMTP id o7mr6254388qvr.115.1543595022771; Fri, 30 Nov 2018 08:23:42 -0800 (PST) MIME-Version: 1.0 References: <20181130151820.1a197589@zeta.dino.sk> In-Reply-To: <20181130151820.1a197589@zeta.dino.sk> From: Warner Losh Date: Fri, 30 Nov 2018 09:23:31 -0700 Message-ID: Subject: Re: EFI boot with multiple alternate boot/OS partitions - possible? To: freebsd-hackers@dino.sk Cc: "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: DA7416AB79 X-Spamd-Result: default: False [-2.32 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com]; NEURAL_HAM_MEDIUM(-0.88)[-0.884,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-0.86)[-0.860,0]; NEURAL_HAM_LONG(-0.93)[-0.935,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[e.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-0.63)[ipnet: 2607:f8b0::/32(-1.74), asn: 15169(-1.34), country: US(-0.09)]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:23:45 -0000 On Fri, Nov 30, 2018 at 7:26 AM Milan Obuch 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 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >