From owner-freebsd-stable@freebsd.org Mon Apr 8 07:19:11 2019 Return-Path: Delivered-To: freebsd-stable@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 3B8801577412 for ; Mon, 8 Apr 2019 07:19:11 +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 DF4468B9DD for ; Mon, 8 Apr 2019 07:19:07 +0000 (UTC) (envelope-from tsoome@me.com) Received: from [10.131.72.237] (113-100-157-37.dyn.estpak.ee [37.157.100.113]) by pv50p00im-ztbu10011701.me.com (Postfix) with ESMTPSA id B14518A018B; Mon, 8 Apr 2019 07:18:59 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? From: Toomas Soome X-Mailer: iPhone Mail (16E227) In-Reply-To: <30f7b617-1814-ad21-a445-a62758150dc3@omnilan.de> Date: Mon, 8 Apr 2019 10:18:51 +0300 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2417CFDF-9744-4600-853D-4A3759CB3137@me.com> References: <591B12C6.4040301@omnilan.de> <591B1A8B.6070803@omnilan.de> <591B1EA4.600@omnilan.de> <591B2523.6040101@omnilan.de> <7CF3AC8F-A778-40AE-B457-9B96AE5B4719@me.com> <591B284B.6070204@omnilan.de> <30f7b617-1814-ad21-a445-a62758150dc3@omnilan.de> To: Harry Schmalzbauer X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-08_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1904080069 X-Rspamd-Queue-Id: DF4468B9DD X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[me.com]; DKIM_TRACE(0.00)[me.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; MX_GOOD(-0.01)[mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, m x6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.co m, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud.com, mx3.mail.icloud.com, mx1.mail.icloud.com, mx6.mail.icloud.com, mx4.mail.icloud.com, mx5.mail.icloud.com, mx2.mail.icloud .com,mx3.mail.icloud.com,mx1.mail.icloud.com,mx6.mail.icloud.com,mx4.mail.icloud.com,mx5.mail.icloud.com,mx2.mail.icloud.com,mx3.mail.icloud.com,mx1.mail.icloud.com,mx6.mail.icloud.com,mx4.mail.icloud.com,mx5.mail.icloud.com,mx2.mail.icloud.com,mx3.mail.icloud.com,mx1.mail.icloud.com,mx6.mail.icloud.com,mx4.mail.icloud.com,mx5.mail.icloud.com,mx2.mail.icloud.com,mx3.mail.icloud.com,mx1.mail.icloud.com,mx6.mail.icloud.com,mx4.mail.icloud.com,mx5.mail.icloud.com,mx2.mail.icloud.com,mx3.mail.icloud.com,mx1.mail.icloud.com,mx6.mail.icloud.com,mx4.mail.icloud.com,mx5.mail.icloud.com,mx2.mail.icloud.com,mx3.mail.icloud.com]; NEURAL_HAM_SHORT(-0.53)[-0.534,0]; RCVD_IN_DNSWL_LOW(-0.10)[53.6.58.17.list.dnswl.org : 127.0.5.1]; SUBJECT_ENDS_QUESTION(1.00)[]; 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)[]; FROM_EQ_ENVFROM(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)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_LOW(-1.00)[me.com.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-0.86)[ipnet: 17.58.0.0/20(-2.12), asn: 714(-2.11), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 07:19:11 -0000 Yes, I still do remember it, just need to find time to port the feature.=20 Of course the root cause there is much more complicated (we can not assume t= o have contigous space above 1MB), but we mostly can cope... Sent from my iPhone > On 8 Apr 2019, at 09:44, Harry Schmalzbauer wrote: >=20 >> Am 16.05.2017 um 18:26 schrieb Harry Schmalzbauer: >> Bez=C3=BCglich Toomas Soome's Nachricht vom 16.05.2017 18:20 (localtime):= >>>> On 16. mai 2017, at 19:13, Harry Schmalzbauer wrot= e: >>>>=20 >>>> Bez=C3=BCglich Toomas Soome's Nachricht vom 16.05.2017 18:00 (localtime= ): >>>>>> On 16. mai 2017, at 18:45, Harry Schmalzbauer >>>>> > wrote: >>>>>>=20 >>>>>> Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 16.05.2017 17:28 (l= ocaltime): >>>>>>> Bez=C3=BCglich Toomas Soome's Nachricht vom 16.05.2017 16:57 (localt= ime): >>>>>>>>> On 16. mai 2017, at 17:55, Harry Schmalzbauer >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>> Hello, >>>>>>>>>=20 >>>>>>>>> unfortunately I had some trouble with my preferred MFS-root setups= . >>>>>>>>> It seems EFI loader doesn't handle type md_image correctly. >>>>>>>>>=20 >>>>>>>>> If I load any md_image with loader invoked by gptboot or gptzfsboo= t, >>>>>>>>> 'lsmod' >>>>>>>>> shows "elf kernel", "elf obj module(s)" and "md_image". >>>>>>>>>=20 >>>>>>>>> Using the same loader.conf, but EFI loader, the md_image-file is >>>>>>>>> prompted and sems to be loaded, but not registered. There's no >>>>>>>>> md_image >>>>>>>>> with 'lsmod', hence it's not astonsihing that kernel doesn't attac= h md0 >>>>>>>>> so booting fails since there's no rootfs. >>>>>>>>>=20 >>>>>>>>> Any help highly appreciated, hope Toomas doesn't mind beeing >>>>>>>>> initially CC'd. >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>>=20 >>>>>>>>> -harry >>>>>>>> The first question is, how large is the md_image and what other >>>>>>>> modules are loaded? >>>>>>> Thanks for your quick response. >>>>>>>=20 >>>>>>> The images are 50-500MB uncompressed (provided by gzip compressed fi= le). >>>>>>> Small ammount of elf modules, 5, each ~50kB. >>>>>> On the real HW, there's vmm and some more: >>>>>> Id Refs Address Size Name >>>>>> 1 46 0xffffffff80200000 16M kernel >>>>>> 2 1 0xffffffff8121d000 86K unionfs.ko >>>>>> 3 1 0xffffffff81233000 3.1M zfs.ko >>>>>> 4 2 0xffffffff81545000 51K opensolaris.ko >>>>>> 5 7 0xffffffff81552000 279K usb.ko >>>>>> 6 1 0xffffffff81598000 67K ukbd.ko >>>>>> 7 1 0xffffffff815a9000 51K umass.ko >>>>>> 8 1 0xffffffff815b6000 46K aesni.ko >>>>>> 9 1 0xffffffff815c3000 54K uhci.ko >>>>>> 10 1 0xffffffff815d1000 65K ehci.ko >>>>>> 11 1 0xffffffff815e2000 15K cc_htcp.ko >>>>>> 12 1 0xffffffff815e6000 3.4M vmm.ko >>>>>> 13 1 0xffffffffa3a21000 12K ums.ko >>>>>> 14 1 0xffffffffa3a24000 9.1K uhid.ko >>>>>>=20 >>>>>> Providing md_image uncompressed doesn't change anything. >>>>>>=20 >>>>>> Will deploy a /usr separated rootfs, which is only ~100MB uncompresse= d >>>>>> and see if that changes anything. >>>>>> That's all I can provide, code is far beyond my knowledge... >>>>>>=20 >>>>>> -harry >>>>>=20 >>>>> The issue is, that current UEFI implementation is using 64MB staging >>>>> memory for loading the kernel and modules and files. When the boot is >>>>> called, the relocation code will put the bits from staging area into t= he >>>>> final places. The BIOS version does not need such staging area, and th= at >>>>> will explain the difference. >>>>>=20 >>>>> I actually have different implementation to address the same problem, >>>>> but thats for illumos case, and will need some work to make it usable >>>>> for freebsd; the idea is actually simple - allocate staging area per >>>>> loaded file and relocate the bits into the place by component, not as >>>>> continuous large chunk (this would also allow to avoid the mines like >>>>> planted by hyperv;), but right now there is no very quick real solutio= n >>>>> other than just build efi loader with larger staging size. >>>> Ic, thanks for the explanation. >>>> While not aware about the purpose of the staging area nor the >>>> consequences of enlarging it, do you think it's feasable increasing it >>>> to 768Mib? >>>>=20 >>>> At least now I have an idea baout the issue and an explanation why >>>> reducing md_imgae to 100MB hasn't helped =E2=80=93 still more than 64..= . >>>>=20 >>>> Any quick hint where to define the staging area size highly appreciated= , >>>> fi there are no hard objections against a 768MB size. >>>>=20 >>>> -harry >>> The problem is that before UEFI Boot Services are not switched off, the m= emory is managed (and owned) by the firmware, >> Hmm, I've been expecting something like that (owend by firmware) ;-) >>=20 >> So I'll stay with CSM for now, and will happily be an early adopter if >> you need someone to try anything (-stable mergable). >=20 > Hello Toomas, >=20 > thanks for your ongoing FreeBSD commits, saw your recent libstand improvem= ents and the efiloader commit. > Which remembers me nagging the skilled ones for my unmet needs ;-) >=20 > I guess nobody had time to look at the MFS-root limitation with EFI vs. BI= OS. > If you have any news/plans, please share. > The ability to boot via EFI gives a much better console experience/usabili= ty for admins, but on MFS-root system, I'm still forced to use the old loade= r path, because of the 64MB size limit. >=20 > Do you think there's a chance that this will be resolved for FreeBSD? >=20 > Thanks, >=20 > -harry >=20