From owner-freebsd-current@freebsd.org Mon Jan 21 12:59:41 2019 Return-Path: Delivered-To: freebsd-current@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 AA5AB14A8E0E for ; Mon, 21 Jan 2019 12:59:41 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-ztbu10011701.me.com (pv50p00im-ztbu10011701.me.com [17.58.6.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4C8387E7B for ; Mon, 21 Jan 2019 12:59:40 +0000 (UTC) (envelope-from tsoome@me.com) Received: from [192.168.150.41] (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-ztbu10011701.me.com (Postfix) with ESMTPSA id ABE738A0070; Mon, 21 Jan 2019 12:59:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config) From: Toomas Soome In-Reply-To: Date: Mon, 21 Jan 2019 14:59:20 +0200 Cc: Warner Losh , Rebecca Cran , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <912985968.20190119125228@serebryakov.spb.ru> <1951151017.20190119235425@serebryakov.spb.ru> <4636753.YNO7O01DYZ@photon.int.bluestop.org> <17710465740.20190120134042@serebryakov.spb.ru> <3f4214e2-36af-cc87-0a3c-2c7ce26cffd8@FreeBSD.org> To: "lev@freebsd.org" X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-21_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=443 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1901210103 X-Rspamd-Queue-Id: C4C8387E7B X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.15 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[me.com:+]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; MX_GOOD(-0.01)[cached: mx1.mail.icloud.com]; NEURAL_HAM_SHORT(-0.92)[-0.919,0]; RCVD_IN_DNSWL_LOW(-0.10)[53.6.58.17.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[me.com]; ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[me.com:s=04042017]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-0.62)[ipnet: 17.58.0.0/20(-1.61), asn: 714(-1.42), country: US(-0.08)]; DWL_DNSWL_LOW(-1.00)[me.com.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 12:59:41 -0000 > On 21 Jan 2019, at 14:45, Lev Serebryakov wrote: >=20 > On 21.01.2019 15:39, Toomas Soome wrote: >=20 >>>> Is too complicated? Boot1.efi doesn't allow that, but loader.efi = does. >>> loader.efi lives on ESP partition, do I understand it right? So, it >>> could not be damaged with "bad" upgrade? >>=20 >> It could, unless the backup is created.=20 > Does it live on code (root) FS or ESP? I understand, that when you > upgrade ESP partition, you could ruin it, but typically root FS is > upgraded much more often than ESP/boot0/boot1 parts. >=20 > --=20 > // Lev Serebryakov >=20 If you are using boot1.efi, the loader.efi is in OS /boot/loader.efi = annd boot1.efi is stored to ESP and will execute loader.efi as bios = boot2 programs do. As UEFI does not *replace* the program which did call StartImage() but = both do stay in memory (so you have both boot1.efi and loader.efi in = memory), and boot1.efi does not add any significant features, we will = drop boot1.efi (it is already dropped in illumos btw), and will only use = loader.efi - and in this case, the loader.efi is installed to ESP and = will only start the kernel. This also does mean that in ideal world, the update should create backup = of boot program in ESP (this actually also does apply to boot1.efi), but = the default ESP created by FreeBSD used to be too small for that. With normal systems it should not be an issue because you can always = boot from usb stick/cd (image), but with embedded systems it may be = significant issue. But then again, if you are using stock (generic) OS = on embedded system, you are already doing it wrong and will get into the = trouble sooner or later:) rgds, toomas=