From owner-freebsd-hackers@freebsd.org Sun Mar 24 02:21:47 2019 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 1BF5A15448DD for ; Sun, 24 Mar 2019 02:21:47 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A5F68E166 for ; Sun, 24 Mar 2019 02:21:45 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 1EFF9C055A for ; Sat, 23 Mar 2019 20:22:50 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XI31A5v9tL1L for ; Sat, 23 Mar 2019 20:22:50 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA for ; Sat, 23 Mar 2019 20:22:49 -0600 (MDT) To: FreeBSD Hackers From: Rebecca Cran Subject: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" Message-ID: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> Date: Sat, 23 Mar 2019 20:21:43 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 0A5F68E166 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.71 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bluestop.org:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-1.00)[ipnet: 65.100.0.0/14(-4.88), asn: 209(-0.02), country: US(-0.07)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mail.bluestop.org]; DKIM_TRACE(0.00)[bluestop.org:+]; DMARC_POLICY_ALLOW(-0.50)[bluestop.org,quarantine]; NEURAL_HAM_SHORT(-0.70)[-0.702,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:209, ipnet:65.100.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[] 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: Sun, 24 Mar 2019 02:21:47 -0000 I've been working on EFI support, and have a review (https://reviews.freebsd.org/D19588) to add a script, efi-update-loader, which will update the ESP containing the FreeBSD boot1.efi or loader.efi. I'd like to integrate it into the build system so it gets run when users do a "make installworld", but I'm lost looking through Makefile.inc1 - I have no clue where to add the code. Does anyone understand where and what to add? -- Rebecca Cran From owner-freebsd-hackers@freebsd.org Sun Mar 24 09:01:18 2019 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 5A8561551619; Sun, 24 Mar 2019 09:01:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 3FF55730DE; Sun, 24 Mar 2019 09:01:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2O914lC009017 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 Mar 2019 11:01:07 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2O914lC009017 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2O913nC009016; Sun, 24 Mar 2019 11:01:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Mar 2019 11:01:03 +0200 From: Konstantin Belousov To: Rebecca Cran Cc: FreeBSD Hackers , arch@freebsd.org Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" Message-ID: <20190324090103.GO1923@kib.kiev.ua> References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home 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: Sun, 24 Mar 2019 09:01:18 -0000 On Sat, Mar 23, 2019 at 08:21:43PM -0600, Rebecca Cran via freebsd-hackers wrote: > I've been working on EFI support, and have a review > (https://reviews.freebsd.org/D19588) to add a script, efi-update-loader, > which will update the ESP containing the FreeBSD boot1.efi or loader.efi. > > I'd like to integrate it into the build system so it gets run when users > do a "make installworld", but I'm lost looking through Makefile.inc1 - I > have no clue where to add the code. > > Does anyone understand where and what to add? Can we take use of the opportunity and finally stop installing loader at installworld target at all, please ? Add e.g. installloader target which would do whatever needed to loader. From owner-freebsd-hackers@freebsd.org Sun Mar 24 11:01:48 2019 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 4F0811554ECD; Sun, 24 Mar 2019 11:01:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 8787777643; Sun, 24 Mar 2019 11:01:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2OB1cmi085645 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 Mar 2019 13:01:41 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2OB1cmi085645 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2OB1cIF085644; Sun, 24 Mar 2019 13:01:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Mar 2019 13:01:38 +0200 From: Konstantin Belousov To: Bruce Evans Cc: Mark Millard , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed] Message-ID: <20190324110138.GR1923@kib.kiev.ua> References: <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190306172003.GD2492@kib.kiev.ua> <20190308001005.M2756@besplex.bde.org> <20190307222220.GK2492@kib.kiev.ua> <20190309144844.K1166@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190309144844.K1166@besplex.bde.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home 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: Sun, 24 Mar 2019 11:01:48 -0000 On Sat, Mar 09, 2019 at 06:00:14PM +1100, Bruce Evans wrote: > I more strongly disclike (sic) the more complete merge. The central APIs > have even more parameters and reduced type safety to describe objects as > (offset, size) pairs. I changed the patch to be type-safe. Now I like it even more. It provides 1. internal 2. concise 3. type-safe API to fetch data from timehands. The implementation needs to be read only once. > Small delicate loops are ideal for duplicating. They are easier to > understand individually and short enough to compare without using diff > to see gratuitous and substantive differences. Multiple instances are > only hard to write and maintain. Since these multiple instances are > already written, they are only harder to maintain. This is a good argument to have bintime_off and getthmember unmerged (there are two small but delicate loops). The API is internal, so it is only matter for maintainer, which means that the absence of duplication is important. More, all that arguments clearly explain why there should be not twenty similar loops scattered over the source. > > >> XX void > >> XX binuptime(struct bintime *bt) > >> XX { > >> XX @@ -361,7 +383,7 @@ > >> XX th = timehands; > >> XX gen = atomic_load_acq_int(&th->th_generation); > >> XX *bt = th->th_offset; > >> XX - bintime_addx(bt, th->th_scale * tc_delta(th)); > >> XX + bintime_adddelta(bt, th); > >> XX atomic_thread_fence_acq(); > >> XX } while (gen == 0 || gen != th->th_generation); > >> XX } > >> > >> This is the kind of non-churning change that I like. > > Ok. I made all cases where timehands are read, more uniform by > > moving calculations after the generation loop. This makes the > > atomic part of the functions easier to see, and loop body has lower > > chance to hit generation reset. > > I think this change is slightly worse: > - it increases register pressure. 'scale' and 'delta' must be read in a > alost program program before the loop exit test. The above order uses > them and stores the results to memory, so more registers are free for > the exit test. i386 certainly runs out of registers. IIRC, i386 now > spills 'gen'. It would have to spill something to load 'gen' or 'th' > for the test. Which does not matter on any modern architecture anyway. > - it enlarges the window between reading 'scale' and 'delta' and the > caller seeing the results. Preemption in this window gives results > that may be far in the past. My opinion is that quickly exiting the code and avoid retry is more important (as in performance) than making an impression that we protect against preemption. If preemption is important for the caller, then the calling place must use some measures like interrupt disabling and re-checking the time after the operation. Preemption can occur after the loop exit with the same consequences. > The 'get' name is another problem. I would like all the get*time > functions and not add new names starting with 'get'. The library > implementation already doesn't bother optimizing the get*time functions, > but always uses the hardware timecounter. > > getfoo() is a more natural name than foo_get() for the action of getting > foo, but the latter is better for consistency, especially in code that > puts the subsystem name first in nearby code. > > The get*time functions would be better if they were more like > time_second. Note that time_second is racy if time_t is too larger > for the arch so that accesses to it are not atomic, as happens on > 32-bit arches with premature 64-bit time_t. However, in this 32/64 > case, the race is only run every 136 years, with the next event > scheduled in 2038, so this race is even less important now than other > events scheduled in 2038. Bintimes are 96 or 128 bits, so directly > copying a global like time_second for them would race every 1/2**32 > second on 2-bit arches or every 1 second on 64-bit arches. Most of > the loops on the generation count are for fixing these races, but > perhaps a simpler method would work. On 64-bit arches with atomic > 64 accesses on 32-bit boundaries, the following would work: > - set the lower 32 bits of the fraction to 0, or ignore them > - load the higher 32 bits of the fraction and the lower 32 bits of the > seconds > - race once every 136 years starting in 2038 reading the higher 32 bits > of the seconds non-atomically. > - alternatively, break instead of racing in 2038 by setting the higher > 32 bits to 0. This is the same as using sbintimes instead of bintimes. > - drop a few more lower bits by storing a right-shifted value. Right > shifting by just 1 gives a race frequency of once per 272 years, with > the next one in 2006. It would make sense if the functions were written from scratch, but since we already have the generation counts, it is not obvious that such change is useful. But if we decide to go that route (later), my current patch only requires exactly one location getthmember() to experiment with and to change after. So you effectively made yet another, and perhaps most convincing, argument, for me. > > > diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c > > index 2656fb4d22f..8d12847f2cd 100644 > > --- a/sys/kern/kern_tc.c > > +++ b/sys/kern/kern_tc.c > > @@ -200,20 +202,56 @@ tc_delta(struct timehands *th) > > * the comment in for a description of these 12 functions. > > */ > > > > -#ifdef FFCLOCK > > -void > > -fbclock_binuptime(struct bintime *bt) > > +static __inline void > > +bintime_off(struct bintime *bt, u_int off) > > { > > struct timehands *th; > > - unsigned int gen; > > + struct bintime *btp; > > + uint64_t scale, x; > > + u_int delta, gen, large_delta; > > > > do { > > th = timehands; > > gen = atomic_load_acq_int(&th->th_generation); > > - *bt = th->th_offset; > > - bintime_addx(bt, th->th_scale * tc_delta(th)); > > You didn't fully obfuscate this by combinining this function with > getthmember() so as to deduplicate the loop. > > > + btp = (struct bintime *)((vm_offset_t)th + off); > > Ugly conversion to share code. This is technically incorrect. Improving > the casts gives: > > btp = (void *)(uintptr_t)((uintptr_t)(void *)th + off); > > but this assumes that arithmetic on the intermediate integer does what > is espected. uintptr_t is only guaranteed to work when the intermediate > representation held in it is not adjusted. vm_offset_t has the semantic that is needed for the arithmetic. It is better uintptr_t for kernel, where we know that all object pointers are compatible with vm_offset_t (AKA flat tag-less memory model). > > Fixing the API gives > > static __inline void > bintime_off(struct bintime *btp, struct bintime *base_btp) > > where base_btp is &th->th_bintime or &th->th_offset. > > (th_offset and th_bintime are badly named. th_offset is really a base > time and the offset is tc_delta(). th_bintime is also a base time. > It is the same as th_offset with another actual offset (the difference > between UTC and local time) already added to it as an optimization. In > old versions, th_bintime didn't exist, but the related struct members > th_nanotime and th_microtime existed, since these benefit more from > not converting on every call. How could it be &th->th_offset, when th is calculated inside the call ? But I did modified the API in this spirit, indeed. It takes the member name directly as an argument. > > My old version even documents the struct members, while -current still > has no comments. The comments were lost to staticization. My version > mostly adds "duh" to the banal comments after recovering them: > > XX /* > XX * XXX rotted comment cloned from . > XX * > XX * th_counter is undocumented (duh). > XX * > XX * th_adjustment [PPM << 16] which means that the smallest unit of correction > XX * you can apply amounts to 481.5 usec/year. > XX * > XX * th_scale is undocumented (duh). > XX * > XX * th_offset_count is the contents of the counter which corresponds to the > XX * > XX * rest of the offset_* values. > XX * > XX * th_offset is undocumented (duh). > XX * > XX * th_microtime is undocumented (duh). > XX * > XX * th_nanotime is undocumented (duh). > XX * > XX * XXX especially massive bitrot here. "three" is now "many"... > XX * Each timecounter must supply an array of three timecounters. This is needed > XX * to guarantee atomicity in the code. Index zero is used to transport > XX * modifications, for instance done with sysctl, into the timecounter being > XX * used in a safe way. Such changes may be adopted with a delay of up to 1/HZ. > XX * Index one and two are used alternately for the actual timekeeping. > XX * > XX * th_generation is undocumented (duh). > XX * > XX * th_next is undocumented (duh). > XX */ > > > + *bt = *btp; > > + scale = th->th_scale; > > + delta = tc_delta(th); > > + large_delta = th->th_large_delta; > > I had forgotten that th_scale is so volatile (it may be adjusted on > every windup). th_large_delta is equally volatile. So moving the > calculation outside of the loop gives even more register pressure > than I noticed above. > > > atomic_thread_fence_acq(); > > } while (gen == 0 || gen != th->th_generation); > > + > > + if (__predict_false(delta < large_delta)) { > > + /* Avoid overflow for scale * delta. */ > > + x = (scale >> 32) * delta; > > + bt->sec += x >> 32; > > + bintime_addx(bt, x << 32); > > + bintime_addx(bt, (scale & 0xffffffff) * delta); > > + } else { > > + bintime_addx(bt, scale * delta); > > + } > > +} > > + > > +static __inline void > > +getthmember(void *out, size_t out_size, u_int off) > > +{ > > + struct timehands *th; > > + u_int gen; > > + > > + do { > > + th = timehands; > > + gen = atomic_load_acq_int(&th->th_generation); > > + memcpy(out, (char *)th + off, out_size); > > This isn't so ugly or technically incorrect. Now the object is generic, > so the reference to it should be passed as (void *objp, size_t objsize) > instead of the type-safe (struct bintime *base_bpt). _Generic is what gave me a hint how to make the implementation type-safe. diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index 2656fb4d22f..4e94f762026 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -72,6 +72,7 @@ struct timehands { struct timecounter *th_counter; int64_t th_adjustment; uint64_t th_scale; + u_int th_large_delta; u_int th_offset_count; struct bintime th_offset; struct bintime th_bintime; @@ -90,6 +91,7 @@ static struct timehands th1 = { static struct timehands th0 = { .th_counter = &dummy_timecounter, .th_scale = (uint64_t)-1 / 1000000, + .th_large_delta = 1000000, .th_offset = { .sec = 1 }, .th_generation = 1, .th_next = &th1 @@ -200,20 +202,72 @@ tc_delta(struct timehands *th) * the comment in for a description of these 12 functions. */ -#ifdef FFCLOCK -void -fbclock_binuptime(struct bintime *bt) +static __inline void +bintime_off(struct bintime *bt, u_int off) { struct timehands *th; - unsigned int gen; + struct bintime *btp; + uint64_t scale, x; + u_int delta, gen, large_delta; do { th = timehands; gen = atomic_load_acq_int(&th->th_generation); - *bt = th->th_offset; - bintime_addx(bt, th->th_scale * tc_delta(th)); + btp = (struct bintime *)((vm_offset_t)th + off); + *bt = *btp; + scale = th->th_scale; + delta = tc_delta(th); + large_delta = th->th_large_delta; atomic_thread_fence_acq(); } while (gen == 0 || gen != th->th_generation); + + if (__predict_false(delta >= large_delta)) { + /* Avoid overflow for scale * delta. */ + x = (scale >> 32) * delta; + bt->sec += x >> 32; + bintime_addx(bt, x << 32); + bintime_addx(bt, (scale & 0xffffffff) * delta); + } else { + bintime_addx(bt, scale * delta); + } +} +#define GETTHBINTIME(dst, member) \ +do { \ + _Static_assert(_Generic(((struct timehands *)NULL)->member, \ + struct bintime: 1, default: 0) == 1, \ + "struct timehands member is not of struct bintime type"); \ + bintime_off(dst, __offsetof(struct timehands, member)); \ +} while (0) + +static __inline void +getthmember(void *out, size_t out_size, u_int off) +{ + struct timehands *th; + u_int gen; + + do { + th = timehands; + gen = atomic_load_acq_int(&th->th_generation); + memcpy(out, (char *)th + off, out_size); + atomic_thread_fence_acq(); + } while (gen == 0 || gen != th->th_generation); +} +#define GETTHMEMBER(dst, member) \ +do { \ + _Static_assert(_Generic(*dst, \ + __typeof(((struct timehands *)NULL)->member): 1, \ + default: 0) == 1, \ + "*dst and struct timehands member have different types"); \ + getthmember(dst, sizeof(*dst), __offsetof(struct timehands, \ + member)); \ +} while (0) + +#ifdef FFCLOCK +void +fbclock_binuptime(struct bintime *bt) +{ + + GETTHBINTIME(bt, th_offset); } void @@ -237,16 +291,8 @@ fbclock_microuptime(struct timeval *tvp) void fbclock_bintime(struct bintime *bt) { - struct timehands *th; - unsigned int gen; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - *bt = th->th_bintime; - bintime_addx(bt, th->th_scale * tc_delta(th)); - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHBINTIME(bt, th_bintime); } void @@ -270,100 +316,55 @@ fbclock_microtime(struct timeval *tvp) void fbclock_getbinuptime(struct bintime *bt) { - struct timehands *th; - unsigned int gen; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - *bt = th->th_offset; - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(bt, th_offset); } void fbclock_getnanouptime(struct timespec *tsp) { - struct timehands *th; - unsigned int gen; + struct bintime bt; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - bintime2timespec(&th->th_offset, tsp); - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(&bt, th_offset); + bintime2timespec(&bt, tsp); } void fbclock_getmicrouptime(struct timeval *tvp) { - struct timehands *th; - unsigned int gen; + struct bintime bt; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - bintime2timeval(&th->th_offset, tvp); - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(&bt, th_offset); + bintime2timeval(&bt, tvp); } void fbclock_getbintime(struct bintime *bt) { - struct timehands *th; - unsigned int gen; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - *bt = th->th_bintime; - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(bt, th_bintime); } void fbclock_getnanotime(struct timespec *tsp) { - struct timehands *th; - unsigned int gen; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - *tsp = th->th_nanotime; - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(tsp, th_nanotime); } void fbclock_getmicrotime(struct timeval *tvp) { - struct timehands *th; - unsigned int gen; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - *tvp = th->th_microtime; - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(tvp, th_microtime); } #else /* !FFCLOCK */ + void binuptime(struct bintime *bt) { - struct timehands *th; - u_int gen; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - *bt = th->th_offset; - bintime_addx(bt, th->th_scale * tc_delta(th)); - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHBINTIME(bt, th_offset); } void @@ -387,16 +388,8 @@ microuptime(struct timeval *tvp) void bintime(struct bintime *bt) { - struct timehands *th; - u_int gen; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - *bt = th->th_bintime; - bintime_addx(bt, th->th_scale * tc_delta(th)); - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHBINTIME(bt, th_bintime); } void @@ -420,85 +413,47 @@ microtime(struct timeval *tvp) void getbinuptime(struct bintime *bt) { - struct timehands *th; - u_int gen; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - *bt = th->th_offset; - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(bt, th_offset); } void getnanouptime(struct timespec *tsp) { - struct timehands *th; - u_int gen; + struct bintime bt; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - bintime2timespec(&th->th_offset, tsp); - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(&bt, th_offset); + bintime2timespec(&bt, tsp); } void getmicrouptime(struct timeval *tvp) { - struct timehands *th; - u_int gen; + struct bintime bt; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - bintime2timeval(&th->th_offset, tvp); - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(&bt, th_offset); + bintime2timeval(&bt, tvp); } void getbintime(struct bintime *bt) { - struct timehands *th; - u_int gen; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - *bt = th->th_bintime; - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(bt, th_bintime); } void getnanotime(struct timespec *tsp) { - struct timehands *th; - u_int gen; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - *tsp = th->th_nanotime; - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(tsp, th_nanotime); } void getmicrotime(struct timeval *tvp) { - struct timehands *th; - u_int gen; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - *tvp = th->th_microtime; - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(tvp, th_microtime); } #endif /* FFCLOCK */ @@ -514,15 +469,8 @@ getboottime(struct timeval *boottime) void getboottimebin(struct bintime *boottimebin) { - struct timehands *th; - u_int gen; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - *boottimebin = th->th_boottime; - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(boottimebin, th_boottime); } #ifdef FFCLOCK @@ -1038,15 +986,8 @@ getmicrotime(struct timeval *tvp) void dtrace_getnanotime(struct timespec *tsp) { - struct timehands *th; - u_int gen; - do { - th = timehands; - gen = atomic_load_acq_int(&th->th_generation); - *tsp = th->th_nanotime; - atomic_thread_fence_acq(); - } while (gen == 0 || gen != th->th_generation); + GETTHMEMBER(tsp, th_nanotime); } /* @@ -1464,6 +1405,7 @@ tc_windup(struct bintime *new_boottimebin) scale += (th->th_adjustment / 1024) * 2199; scale /= th->th_counter->tc_frequency; th->th_scale = scale * 2; + th->th_large_delta = MIN(((uint64_t)1 << 63) / scale, UINT_MAX); /* * Now that the struct timehands is again consistent, set the new From owner-freebsd-hackers@freebsd.org Sun Mar 24 22:55:46 2019 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 66E46154736C for ; Sun, 24 Mar 2019 22:55:46 +0000 (UTC) (envelope-from lc525@cam.ac.uk) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 1A3DF6C103 for ; Sun, 24 Mar 2019 22:55:44 +0000 (UTC) (envelope-from lc525@cam.ac.uk) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cam.ac.uk; s=20180806.ppsw; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ikJGdQDobyV8t4imhSbPuUVFZg3VyU2kJhgFV3Ty6ro=; b=NIGq6rYjZPagms8mAq+oQuSdTU yQez4EHU+W3XsPY6rHqSYfX153H0KmUjROOyHfQJ6OWMh7rpheNEKrbrrWcVeexMWu7FASDE/2SMm D1A0G7ASke2czv2Pmi93bXYxolMaLK+BJ5pdgnwFsEeBYYsgLZN0Sb6U3pdPRCo54wdo=; X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from host81-158-109-169.range81-158.btcentralplus.com ([81.158.109.169]:57310 helo=[192.168.50.98]) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:lc525) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) id 1h8C1g-000SsP-ec (Exim 4.91) (return-path ); Sun, 24 Mar 2019 22:55:36 +0000 Subject: Re: netboot from NFS in an UEFI environment To: Rebecca Cran , freebsd-hackers@freebsd.org References: <2fafa521-0d34-522b-9a39-0689efbd7f3a@cam.ac.uk> <5e06c19f-4d95-afc5-155b-a1b2d3bed88b@bluestop.org> From: Lucian Carata Openpgp: id=BC9780C1939D37116415A1171AFE0D9B85AA6C3E Autocrypt: addr=lc525@cam.ac.uk; prefer-encrypt=mutual; keydata= mQINBFBJy24BEAC46IqhthUGwYfnmgYgSW9BPTK7P87t1zbpO3fQ//wqA3rvZmmHw8KHvTNZ r/YLXgFck9rGBY4uen1S4pla83B4gg9i3+oj15NnIAqFx1s2tWTRLcmhuEcxo4OAwnBXcVQk qe05Q7cwP2XjNqHz8R0HQNkxu2vGj6BVd5daSz+RCnc5peU0yPpaYLNTg6Z28/u5v8SUNo0L pU4il6N6+FGLVH4hRBgRDcrMp/1NLjOqRdq5Ul+49EF7Nnx8OniRp8fn60J6ilf5v/Zat3cD 1AjyBsbXeLZpkH2Peh22DjEr+MBrsW5Aqv/AadWAG1sUhl3LpNgU0I2e9W9eo7oYPCsKHxtM gK5/fg8IrC+fSghD5xpTUuPttRtUZPdomX8HK12yCJP9uLsf3oVPudBOkO8t4XsfNPsoTIHS cjI2bOQ2ZAV6HPYVqOuRd9AmV/0qHJbFrbzw694ZCZ+CnivKNWSANWVTgLtDd15oPQAoKZut SI1chHyTcT8/U/98QaJ7D3i+PB/xgIQmBYfnCzuNHdfsSONaiwzeiBxksUftnzHp4c0SlS34 Lom47DjuBN3+6Qae4AP475AFfwxWee1VWY7Jzc/YyM8gh7HeGKHEIOoygC/hBFBeGQOmlQTo uMoKfAm7V+ycMPWzQzddRembJs2IretTnkY7Xy33uhO5oAfGnwARAQABtB9MdWNpYW4gQ2Fy YXRhIDxsYzUyNUBjYW0uYWMudWs+iQJUBBMBCAA+AhsDAh4BAheABQsJCAcDBRUKCQgLBRYC AwEAFiEEvJeAwZOdNxFkFaEXGv4Nm4WqbD4FAlp5tjsFCQ3yUbgACgkQGv4Nm4WqbD5DhA// Uwtfi8l/OV6LJw3wyh6zmTFynZxKcgFICGittmYvh2iWYW9yipL9NqYeAIkfHv7uhy4i1xOf xk7YuwxJkGvRRCxWJEaLXo6Et0S+6YSmGb5ly4O4mCeO6FqD2nsvMREzIqS4S4DB8zoMcmwH c3ygr7M8VdT3oZEHGDCMxkcbSrjXZPw8fj5DHVSAtMNfLB56bt4CGFvHN6ltvVlnRXccxHjq tiG2MoyFO0M9llAHgtyDLZW30ykhDJMH9IjncEGWQghbN3PEekFbdaP67p2qtunfLspprWRk ewBs3CaTZq33Iw7598nxUiwBXTC2hOo1lb7wAPKHPrzL0yfCsVMEQZeaW1jZ2DPUR8xlUkXR i4KoT90f+XX1IrUQLz1eyEe++hWav+9Sw+VuvKciTGzKf3YtdSWePA7uMS1gGClL9o//26cr BxdWcOKI8BSTeKfQoq9tEzjaK6KUjSg9pDeLci+nrZ/ZAtOrEhuPnmmAhA7dUWjWwCem6YDg 2g3kvRmhCfJ97JA7ZKlG/dIbo/IYKiSmeGlNqcvZ5XeEwa6OEz9O8rMftSxAcimzN8SkrxSH mwD8OVSHdD5EJIHdn4S49VIUpZkTNiU45D3hcJazxZfp2mrtDXDdsCpf7Sr7Jqn/bVvHXKj2 2e6E1QhNNNr5KVZz9v1C4Nb5Sz2rK2XJHCS5AQ0EUwJY8QEIAMtiEQcFWyCp5lJgbB0mMQLi meBS3uG2LmU1NyMMCr3kidCFT6d82wknUQI72h15Cqz7vo/uSnwGznbxuyrhPfkJeaQR4kd/ GnCBBkgOmhFa3/68caZGg+jJsDOxJqmiUtpVWIuxxFOjhnQVcwcC8/5RbehwNCo2/ysEF4K+ rohybCjKAEP9V0jkRcv4lNy70eu1/ziQfFm3KFYPoIEXrcYM3/UTORNKkTbBl8rJJosLbdUF InTGhZQ9aNILMApkZP5uEYIxZHOrHCv2ZJFpTw5YW+oIbpYwoiBlGm+2EM9DdU8bHqBxlukf ZQrES/k4sCVBBVz0BrMywTJkGQlxk98AEQEAAYkDWwQYAQgAJgIbAhYhBLyXgMGTnTcRZBWh Fxr+DZuFqmw+BQJaebbYBQkLOcTnASnAXSAEGQEIAAYFAlMCWPEACgkQcAb2FA62obFaDwf8 C3XQ3M/aue+/lE+xJgOALi56Bm1jBJT9Q01T2uSp2XqRLnc0eD9/gZAq1hnHYG77Ao1bZ/Ra 4k0yQqvtx7eKqWZzVKpZwsSrTtKjgQTI6jk/sQ3M6wxLjxNEWjXHoQ/vlktcoYZai+HXKY25 1wEqveU/JX2VT56a5JsuYnPdGjOxSYZbn8YHplYHrbdqY4S8JH5DW31XESEq2lFAVGn3irx9 0Ky97MkdfdF4XKGdWJkI7DyFkUd0cKCdvC7YTdZ+W5YVhbLT/XLfAWG+bnyBg2NI/8wQgDkF beqRTVaPytb2GP01enqHI05y1Y01z9eZkNVM2tz2SCZVkeAOeuHheQkQGv4Nm4WqbD7OgQ/9 EZWVFDFe6+pXHC6W574R3tIjyo5nHRzv7JBRlW9WAMRO1RoVw4oqiNzaYkKFL287NRoziB3h nGN0dZ7iDSsS6n1a4ZU48nQ6NoPH/XURXX1FzNjHrC5gYovin47kMAoxXXnIgesY5dMMKNT5 FzilHxJi5gPcGP6tXnN+1BOyQnQ1gQhTucoIE4b1m9LM3rkELk2yecFX0xmt/bVipx52oNbk FaVimuZuF3daYLokCqmxTgJ48MI/oq5Ae8MJ6g6P35uY/dp2/pMAW1S/JVRdfeR7kWeQPjtT U70CPMQ8nmYOpkhDmpKF8Bgy7t8cYVStJN5hrZJOE113zmYjWACSFFoDdihzudz8DaRGeunL C4PMnYUFM+NOn1eLV/IDCPEvAHHQyqE5lxFkSQVjdnJdYZdIyXN3o3LglLZ3TforPdIpEi2O /tleicdQYieOCvGjD6qi1HIx8psC6uLVcwmeCS5u3cvf65aHDlHnr/kEZUCgYfGBNMi+mNXX f6+gWJSgZduQzlpQ3Kkx5d1K8uusH57mOqpcHZgEoZs2APHpc7EvQ6E3B8Zra1Ey0FGA6kuB QtPk1+7AZ9cw5mB+k6UV7CK6jtoOnhWbDQY7ygvvfXACCPXYxO9aXqMHHkhUmJJHfST+XmS1 ZrxDABqLnjm5l/f5m1VQ1xB89fgSzdOQEOQ= Message-ID: <321ae3e8-dfd2-8119-fe80-98bec2721cb7@cam.ac.uk> Date: Sun, 24 Mar 2019 22:55:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <5e06c19f-4d95-afc5-155b-a1b2d3bed88b@bluestop.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1A3DF6C103 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cam.ac.uk header.s=20180806.ppsw header.b=NIGq6rYj; spf=pass (mx1.freebsd.org: domain of lc525@cam.ac.uk designates 131.111.8.130 as permitted sender) smtp.mailfrom=lc525@cam.ac.uk X-Spamd-Result: default: False [-5.09 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:131.111.0.0/16]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DKIM_TRACE(0.00)[cam.ac.uk:+]; RCVD_IN_DNSWL_MED(-0.20)[130.8.111.131.list.dnswl.org : 127.0.11.2]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[mx.cam.ac.uk,mx.cam.ac.uk,mx.cam.ac.uk]; NEURAL_HAM_SHORT(-0.95)[-0.946,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-0.94)[ip: (-1.71), ipnet: 131.111.0.0/16(-0.85), asn: 786(-2.04), country: GB(-0.09)]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[169.109.158.81.zen.spamhaus.org : 127.0.0.10]; ASN(0.00)[asn:786, ipnet:131.111.0.0/16, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[cam.ac.uk:s=20180806.ppsw]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(0.00)[cam.ac.uk.dwl.dnswl.org : 127.0.11.2]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cam.ac.uk]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_COMPOSITE_RCVD_IN_DNSWL_MED_DWL_DNSWL_MED(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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: Sun, 24 Mar 2019 22:55:46 -0000 I am indeed passing root-path as {NFS-server-IP}:path/to/freebsd/root But it looks to me loader.efi doesn't look at root-path at all (at least not until it fails). I see it first searches for a device (currdev) and when it finds one (net0 in my case when PXE booting) it tries to determine whether it is a valid device in sanity_check_currdev() by doing: > stat("/boot/defaults/loader.conf") > stat("/boot/kernel/kernel") Of course, having no other information at this stage (as in, the actual root path), this fails. Now, I've tried overwriting currdev (by explicitly setting rootdev) but without success. The manual says "currdev Selects the default device. Syntax for devices is odd." but I don't know whether it would be possible to pass information about both the device and a root path (for example). All the pieces seem to be there, as you mention. So before digging deeper I thought I would ask whether this is a supported scenario or not (i.e should it "just work"), or whether I'm doing something obviously silly. in iPXE I'm currently doing: chain nfs://{path/to/loader.efi} root-path={NFS-server-IP}:path/to/freebsd/root dhcp.root-path={same as root-path} I'm passing root-path manually instead of through DHCP as I've been playing around with various options to see what might work; i've checked that when loader.efi starts it does have root-path set correctly (by executing `show root-path`) --- Lucian On 3/22/19 3:40 AM, Rebecca Cran wrote: > On 3/20/19 11:21 AM, Lucian Carata wrote: > >> Looking through the source code (stand/efi/loader/main.c) I see that there is an attempt to list devices, with a comment saying "this handle list is only for netboot" -- which shows that at least netbooting on UEFI has been considered, but I'm not sure how to pass the path of the NFS root so that the boot continues. >> >> Any ideas on how to do this (or something equivalent) would be greatly appreciated. > > > stand/efi/conf.c does have nfs_fsops, so it should be supported. Maybe an obvious question, but have you tried setting the DHCP option 'root-path' ? > > > -- > > Rebecca Cran > From owner-freebsd-hackers@freebsd.org Sun Mar 24 23:47:33 2019 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 4D30F15489C1; Sun, 24 Mar 2019 23:47:33 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C90586D819; Sun, 24 Mar 2019 23:47:32 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 8AACFC0A16; Sun, 24 Mar 2019 17:48:28 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0j6xUlv5kZu2; Sun, 24 Mar 2019 17:48:28 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 17:48:28 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Konstantin Belousov Cc: FreeBSD Hackers , arch@freebsd.org References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> From: Rebecca Cran Message-ID: Date: Sun, 24 Mar 2019 17:47:23 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190324090103.GO1923@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: C90586D819 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.991,0] 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: Sun, 24 Mar 2019 23:47:33 -0000 On 3/24/19 3:01 AM, Konstantin Belousov wrote: > > Can we take use of the opportunity and finally stop installing loader > at installworld target at all, please ? > > Add e.g. installloader target which would do whatever needed to loader. Others have suggested adding a new step as well. I'm not sure we need it as a make target, but perhaps a generic script such as "update-loader" that will call "efi-update-loader" if on a UEFI system, or "boot0cfg" etc. on an MBR system (i.e. it knows how to install boot/loader code for all systems we support)? Also, about the naming: would you prefer 'install' or 'update' in the script name? When you say "stop installing loader", do you mean stop installing /boot/loader* entirely, or leave installworld installing those, but have updating the ESP as the extra step? -- Rebecca Cran From owner-freebsd-hackers@freebsd.org Sun Mar 24 23:57:24 2019 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 1BA0215491B7 for ; Sun, 24 Mar 2019 23:57:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B390D6DEB1 for ; Sun, 24 Mar 2019 23:57:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x734.google.com with SMTP id k130so4320919qke.3 for ; Sun, 24 Mar 2019 16:57:23 -0700 (PDT) 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=yCZJXOframkGITwVFoML9O1rte5dwvfAWAqdYiHRIPY=; b=gpSpe9g3H84yESz2SDYTK77j4L3nPJTSzhIJam27GDTpYaFU7CuUXoG7JFdM1+Q69K 6yHCwWQv50jOYUhjnoM2NWyS4xGrIcsH2wdHgF9Nwr4X43w/SQYvQ5akfsWdkccNHRdf PA7ZJuWBgvEIh/+usysyeuCJGAhf5DmvqAkzNEPzHf6FJIuvvSiTewMjaukZ5KFbIiBg rKKNf29p3nDmMO2CcoMo850xu9qY5/u5ZeQhvKNuYbEI63pZLMNAOxVlqlfinjtfLS4o DSaY2/hGmKIYVLlImEhMVU0UjFC2/jVEe7m3y4cBE2viQNr6EsQK3jQeAcZVt/986dau QUVA== 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=yCZJXOframkGITwVFoML9O1rte5dwvfAWAqdYiHRIPY=; b=aWVXLffPILzHVqeVysz+A6OZEFF3SWwaaLg2ESuJU4PkitvxxFCIhyPgRFBl60UGfT d8L6GfP+EwOUEIm3w8LACAvaUQAd2DWnvXStbP3eGFA6GxF5OfjMOx+Qgo+9JSpRh44D dt6OFN7EwE/a4rdEwU93JV8MMDBE32CsF/12y2hs3ai6XAxcdczx8uvuNerB7lPSni0W jkRQAQbrYZ8xEtTRA8KfS2CPMl8arD7RYnkXmp+1tYG1DJg7aHeEaQQOEggY476r/0ez sEfTcpA7zO8PRPLgYiD26fgtlX10kLS2/zcefz0tUagFPV7of7NAR3DA7qp78xRtDo0p 3/Hw== X-Gm-Message-State: APjAAAXw9aw+KM0SmDDbgT/IgQA5DEmXITR4+S7G6Ee8rQ/SjIzKpRyD t6cKlH+yF0GcCwu/rC1eMlwEkfZvjm3gMN2exyLU1w== X-Google-Smtp-Source: APXvYqz5al1H4Se+HcOtFX3hmr2ATebrdcdWYonJYHZxq38c+kv0/xs9OD9p9sqdw6Fq2YJh0PcCDJSQk3e2QS4GnFg= X-Received: by 2002:a05:620a:15c4:: with SMTP id o4mr17179803qkm.175.1553471842974; Sun, 24 Mar 2019 16:57:22 -0700 (PDT) MIME-Version: 1.0 References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> In-Reply-To: From: Warner Losh Date: Sun, 24 Mar 2019 17:57:12 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Rebecca Cran Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: B390D6DEB1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.995,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Sun, 24 Mar 2019 23:57:24 -0000 On Sun, Mar 24, 2019 at 5:48 PM Rebecca Cran via freebsd-hackers < freebsd-hackers@freebsd.org> wrote: > On 3/24/19 3:01 AM, Konstantin Belousov wrote: > > > > > Can we take use of the opportunity and finally stop installing loader > > at installworld target at all, please ? > > > > Add e.g. installloader target which would do whatever needed to loader. > > > Others have suggested adding a new step as well. I'm not sure we need it > as a make target, but perhaps a generic script such as "update-loader" > that will call "efi-update-loader" if on a UEFI system, or "boot0cfg" > etc. on an MBR system (i.e. it knows how to install boot/loader code for > all systems we support)? Also, about the naming: would you prefer > 'install' or 'update' in the script name? > > > When you say "stop installing loader", do you mean stop installing > /boot/loader* entirely, or leave installworld installing those, but have > updating the ESP as the extra step? > He's asking for stopping doing a make install in src/stand. I'm thinking that's a good thing. We should update the ESP's \efi\freebsd\loader.efi, but leave the\efi\boot\bootXXXX.efi alone as part of this new installloader phase. Again, only if the ESP is mounted, and we have a default spot for it. For this script, I don't think hunting for the ESP is the right way to go... which means we need to define a standard place for the ESP to be mounted, which we should do before we turn on any of these features. We have the start of a generic script to update things in src/tools/boot/install-boot.sh which was supposed to install boot blocks on everything known to run FreeBSD. Warner From owner-freebsd-hackers@freebsd.org Mon Mar 25 00:02:56 2019 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 2983C15497AD; Mon, 25 Mar 2019 00:02:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 67D1F6E439; Mon, 25 Mar 2019 00:02:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2P02fTi035581 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Mar 2019 02:02:44 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2P02fTi035581 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2P02fZT035580; Mon, 25 Mar 2019 02:02:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Mar 2019 02:02:41 +0200 From: Konstantin Belousov To: Rebecca Cran Cc: FreeBSD Hackers , arch@freebsd.org Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" Message-ID: <20190325000241.GS1923@kib.kiev.ua> References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home 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: Mon, 25 Mar 2019 00:02:56 -0000 On Sun, Mar 24, 2019 at 05:47:23PM -0600, Rebecca Cran wrote: > On 3/24/19 3:01 AM, Konstantin Belousov wrote: > > > > > Can we take use of the opportunity and finally stop installing loader > > at installworld target at all, please ? > > > > Add e.g. installloader target which would do whatever needed to loader. > > > Others have suggested adding a new step as well. I'm not sure we need it > as a make target, but perhaps a generic script such as "update-loader" > that will call "efi-update-loader" if on a UEFI system, or "boot0cfg" > etc. on an MBR system (i.e. it knows how to install boot/loader code for > all systems we support)? Also, about the naming: would you prefer > 'install' or 'update' in the script name? I do not see the need in the script which would call another commands. Having efi_update_loader alone would be fine, but I doubt that this script can do much except in situations where a lot of pre-assumptions are true. I believe that despite all the efforts put into efibootmgr and installer, it is hard/impossible to make the script not dangerous, except if the whole configuration was created by our installer. > > > When you say "stop installing loader", do you mean stop installing > /boot/loader* entirely, or leave installworld installing those, but have > updating the ESP as the extra step? I mean 'do not touch my ESP' on installworld. From owner-freebsd-hackers@freebsd.org Mon Mar 25 00:20:20 2019 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 F1D5D154A039; Mon, 25 Mar 2019 00:20:19 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A7DA6EBC5; Mon, 25 Mar 2019 00:20:19 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 36272C0A4D; Sun, 24 Mar 2019 18:21:22 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uWGl4vsUr5MR; Sun, 24 Mar 2019 18:21:21 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 18:21:21 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> From: Rebecca Cran Message-ID: <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> Date: Sun, 24 Mar 2019 18:20:17 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Rspamd-Queue-Id: 8A7DA6EBC5 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 25 Mar 2019 00:20:20 -0000 On 3/24/19 5:57 PM, Warner Losh wrote: > > He's asking for stopping doing a make install in src/stand. I'm > thinking that's a good thing. We should update the ESP's > \efi\freebsd\loader.efi, but leave the\efi\boot\bootXXXX.efi alone as > part of this new installloader phase. Again, only if the ESP is > mounted, and we have a default spot for it. For this script, I don't > think hunting for the ESP is the right way to go... which means we > need to define a standard place for the ESP to be mounted, which we > should do before we turn on any of these features. > > We have the start of a generic script to update things in > src/tools/boot/install-boot.sh which was supposed to install boot > blocks on everything known to run FreeBSD. Only updating \efi\freebsd\loader.efi is the wrong thing to do in my opinion: there are situations like on ARM where EFI variables aren't persistent, and we need \efi\boot\bootxxxx.efi for booting. What we could do is check if QueryVariableInfo returns EFI_UNSUPPORTED, in which case we know any changes to BootXXXX variables won't survive a reboot, and we need BOOTxxxx.efi. Is it safe to assume there's only a single ESP in the system? Is it not normal for there to be one ESP per disk for mirrored configurations, in which case each would need to be updated? Do you envision src/tools/boot/install-boot.sh moving to /usr/sbin, or remaining where it is? We'd also need to update the ESP for binary installs using freebsd-update. -- Rebecca Cran From owner-freebsd-hackers@freebsd.org Mon Mar 25 00:32:15 2019 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 6ED8F154A6BA; Mon, 25 Mar 2019 00:32:15 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4E196F250; Mon, 25 Mar 2019 00:32:14 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-oi1-x229.google.com with SMTP id t206so5634749oib.3; Sun, 24 Mar 2019 17:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3EmgJR6FIuqg2wxDs0+7sNzkmfnDmv1Fc0k0+TqsnOY=; b=cf7Jb4yoitUOSVMLFGsDwTenTD3KIyfeDrzibnFKrVK2n2P4spYgWidVJvEVv0hCPY H8Ocu/ev6CUeC4HBEMc+wy5G7C4Ubp0moGp+rVhmexD5rRxmeBCGiP3Xw2ksJyi6Badw ojgHOTeJCtmrq6MrA9hrLsk32a2AO+fXTGdN90sNqP8t9OX+qDfaagSzrlwKYCRtHBge 5Syg+WSsUyLN4JrhkLwAztk8/09jVWkajnhGHhBgCnC3ZFlVjzGp0Wn2iJRl32hW/ndK U4AzfOO/zNjuB1S9fvBCm0XNeA9QqgOk663/aET+K1RijpSUunWjsZE9KuRkz5lBtTXW wrbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3EmgJR6FIuqg2wxDs0+7sNzkmfnDmv1Fc0k0+TqsnOY=; b=sHQtr0zPnMHrDMJzX2QViDgnpiFYKh10ZKdqrPadMRNE65oa8n1BSN+SlZ8txwu6t2 7u+JND4O0+JMi8YPWIgTv/PZlf4lPYbC7u7VvSaZfugoP7pOpbpNm5Gt/l0FwQOVm0eF KTUTddvTmm42FA+ymVoOxLdKbMqGC93lm78AkdZv/sJeuRM2aWgZJpRzG8PRGrAOFRNX BGjxFDyHWV6pf2Vzz78wby4snCbvB3nW6BCUWcAefXoiQD5DdqrCdMlB4ULkA4qoF5us TFSli4ab2QHLTJibvmZ0HFwtIesaiOuwf2Llw8CJ5xkgAIExNc8VHsbAq90P/o0L6DTJ xDRw== X-Gm-Message-State: APjAAAXo8C1aOPatG96MZVqjnxQi+JdDG/iWG62FOHK9iGLjU3SZiCHr mN86zH4kopJO+4ak66lF4aYQ/9Qd X-Google-Smtp-Source: APXvYqz+HdBjBLom83EdE308E29M6Jws+/4LFW30fe6rhHirQXBH49wgFrnRT95m0yj1ChL0lScEcg== X-Received: by 2002:aca:eb93:: with SMTP id j141mr9908318oih.178.1553473934005; Sun, 24 Mar 2019 17:32:14 -0700 (PDT) Received: from [100.168.146.207] ([172.56.6.99]) by smtp.gmail.com with ESMTPSA id e17sm5769609otp.41.2019.03.24.17.32.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Mar 2019 17:32:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" From: Enji Cooper X-Mailer: iPhone Mail (16D57) In-Reply-To: <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> Date: Sun, 24 Mar 2019 17:32:10 -0700 Cc: Warner Losh , Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> To: Rebecca Cran X-Rspamd-Queue-Id: E4E196F250 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.985,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Mon, 25 Mar 2019 00:32:15 -0000 > On Mar 24, 2019, at 17:20, Rebecca Cran via freebsd-hackers wrote: >=20 >> On 3/24/19 5:57 PM, Warner Losh wrote: >>=20 >>=20 >> He's asking for stopping doing a make install in src/stand. I'm thinking t= hat's a good thing. We should update the ESP's \efi\freebsd\loader.efi, but l= eave the\efi\boot\bootXXXX.efi alone as part of this new installloader phase= . Again, only if the ESP is mounted, and we have a default spot for it. For t= his script, I don't think hunting for the ESP is the right way to go... whic= h means we need to define a standard place for the ESP to be mounted, which w= e should do before we turn on any of these features. >>=20 >> We have the start of a generic script to update things in src/tools/boot/= install-boot.sh which was supposed to install boot blocks on everything know= n to run FreeBSD. >=20 >=20 > Only updating \efi\freebsd\loader.efi is the wrong thing to do in my opini= on: there are situations like on ARM where EFI variables aren't persistent, a= nd we need \efi\boot\bootxxxx.efi for booting. What we could do is check if Q= ueryVariableInfo returns EFI_UNSUPPORTED, in which case we know any changes t= o BootXXXX variables won't survive a reboot, and we need BOOTxxxx.efi. >=20 > Is it safe to assume there's only a single ESP in the system? Is it not no= rmal for there to be one ESP per disk for mirrored configurations, in which c= ase each would need to be updated? >=20 > Do you envision src/tools/boot/install-boot.sh moving to /usr/sbin, or rem= aining where it is? We'd also need to update the ESP for binary installs usi= ng freebsd-update. I was wondering about builds from scratch, as well=E2=80=94images comple= tely lacking boot blocks like Jenkins builds. Thanks! -Enji= From owner-freebsd-hackers@freebsd.org Mon Mar 25 00:49:31 2019 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 E6160154AE0D for ; Mon, 25 Mar 2019 00:49:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 645506FAFD for ; Mon, 25 Mar 2019 00:49:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x732.google.com with SMTP id k130so4365799qke.3 for ; Sun, 24 Mar 2019 17:49:30 -0700 (PDT) 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=jQ7anEgsKTXSI0JC0fK+0Sq6mGbkY0ArWO40A+8431Y=; b=jQPVDRq+JaCo9lorOxNXWLC9D7JaMXi64LhRkHboMdfrM4M+Sq7NC6C/3igpKPXq11 ZXo5EGtr5Mxz25guHcsNjFOeRtZgwvJMOM4yScD+Aj079HuyJNpzpziqq4ItbVavyrop K2VbH6Sblsg/49QpJ1QYhPsse05DFka/VXhapg73j2wAdoErEsZjPpTw0aRufyeL1N6x lpIwbssmZcbM4ifZ/AZ7WVdQsHjuhwZPU3FXUxp3crWDRptl/3dIv+tAPFZdrN8+34vR d6pTQRl5uQFOtME38TdAnRRUHlnuy7fxDTxLcOo8l+bklNX/zH1UDtYcXdSfJonyVRbZ L/8A== 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=jQ7anEgsKTXSI0JC0fK+0Sq6mGbkY0ArWO40A+8431Y=; b=cd35RnVEB2dmNx5njYLr9aJ22Eh+LkcX+VBmV4XakU4nWrnjhJ6K/+NnE8Fxua5mug LBf+Ls+gyFhCN0CLAstVmkQjOUyZv3pPeTbMWZD2kuXZwgDA6KgWSOfRQ0cmSvuyGs9w jLML0pGAhUWepaPxpOVOCICbyzrp5eqz+CF7bL26M1y66EpvY9YsAeNSnvtTJe+UzqHW x8wFQnaQtqHdu8I6lhwg+nk7ytofAzUmT/aeiQ3YbVk3mpFyk6I78Wriz/jCz3wzig9T UNbcrs++sLw0b3paIHFlvkO1tBhm7zbtmseqE7e1xqE5tZkNwvrPTVKR0+72v+z0XmAb JlUg== X-Gm-Message-State: APjAAAWr20EJLesLHsKyB0FDCUyUIL0BHgLbEC+rozUsonG2R7HtZhGL MdglyfTc9CbPKtMseKZgjkgIJwfsNhR0l9SYyENoEg== X-Google-Smtp-Source: APXvYqzWNCeSKZjMzbHcsL0yvKmJanpI11DGsFx5LHOlrWWHk4HYUpZXFfppkVdb89XLJzTT4QRtnjxYgmvIM3JlLYs= X-Received: by 2002:a37:bce:: with SMTP id 197mr18053852qkl.46.1553474969741; Sun, 24 Mar 2019 17:49:29 -0700 (PDT) MIME-Version: 1.0 References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> In-Reply-To: <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> From: Warner Losh Date: Sun, 24 Mar 2019 18:49:17 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Rebecca Cran Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 645506FAFD X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.978,0] 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: Mon, 25 Mar 2019 00:49:31 -0000 On Sun, Mar 24, 2019, 6:20 PM Rebecca Cran wrote: > On 3/24/19 5:57 PM, Warner Losh wrote: > > > He's asking for stopping doing a make install in src/stand. I'm thinking > that's a good thing. We should update the ESP's \efi\freebsd\loader.efi, > but leave the\efi\boot\bootXXXX.efi alone as part of this new installloader > phase. Again, only if the ESP is mounted, and we have a default spot for > it. For this script, I don't think hunting for the ESP is the right way to > go... which means we need to define a standard place for the ESP to be > mounted, which we should do before we turn on any of these features. > > We have the start of a generic script to update things in > src/tools/boot/install-boot.sh which was supposed to install boot blocks on > everything known to run FreeBSD. > > > Only updating \efi\freebsd\loader.efi is the wrong thing to do in my > opinion: there are situations like on ARM where EFI variables aren't > persistent, and we need \efi\boot\bootxxxx.efi for booting. What we could > do is check if QueryVariableInfo returns EFI_UNSUPPORTED, in which case we > know any changes to BootXXXX variables won't survive a reboot, and we need > BOOTxxxx.efi. > Systems that don't support variables are a super duper weird special case. Let's not let them drive the design. I want to get to (a) a standardized mount point and (b) drive people towards having the boot loader be in /efi/freebsd/loader.efi. our tooling should reflect that first and foremost. The weirdo, special cases that likely won't be updating from source are secondary. Let's get a good design flow down first for the most common case, one that encourages the most people to adopt the standard boot flow as possible. Is it safe to assume there's only a single ESP in the system? Is it not > normal for there to be one ESP per disk for mirrored configurations, in > which case each would need to be updated? > None of those are safe. We shouldn't look for the ESP to mount. It should be mounted and we should only update it if it is. DWIM will get us into a lot of trouble with the boot path, I believe. Do you envision src/tools/boot/install-boot.sh moving to /usr/sbin, or > remaining where it is? We'd also need to update the ESP for binary installs > using freebsd-update > Eventually, but it has a ways to go. Warner > -- > Rebecca Cran > From owner-freebsd-hackers@freebsd.org Mon Mar 25 00:51:27 2019 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 00CEF154B0A5 for ; Mon, 25 Mar 2019 00:51:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9685F6FE82 for ; Mon, 25 Mar 2019 00:51:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x836.google.com with SMTP id t28so8484774qte.6 for ; Sun, 24 Mar 2019 17:51:26 -0700 (PDT) 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=D8cSRfTNV/YycywAIKQPNAQnzVmklsOC9K5kQL7BZBA=; b=GDTCXE6ZcrSh4ehjybToufN1GhCEb4MiKywZXUkO2Y+Lm3tX5nopX5tXiaVyxV0VXU 11JCScXeGyJacFVIqC2sp/zPRf/6ga2cuUvxhwt9+SWzLHtGaSo/uzjEdLybcPatrshk JEB98wNkM33nLghUia03dyA4M3sO2/3QgNTnB0TN8j38NSS1qBSpTWdYcYCb7lIXYutX oPNEG7710VJ3kC9FZaUjuvjd/wxCOx5c/sC+8uhM3J3+BbPhcFahIKroLpMrLkSeuW9L nVm4tyBfRnopI9W+/3RCOvQUOOJ2BkUI+/0IloRN3XnGliKkPYQ/wgMcbtpRusLUu2+9 2RcQ== 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=D8cSRfTNV/YycywAIKQPNAQnzVmklsOC9K5kQL7BZBA=; b=jFBC0oMB+89izOFnOxkaiE/6NDlzZwwflP2COa8OpzHK/gvuDLp/oTWjvOsef8VVAS k/BEsBiCXyWS6YyO9/QfXfRBM0Sd6vpbufV+4rIiAtICmOrkXrpLdIXPvqLjR112KRP9 brnT22Rz8K1y3AxUQkh5WRXnQ+IFHrtq2hhvPraiF4g+x6r/a/P/YBsGJ8B3zBQIUzZ7 Huq/PkvT6L46y9rvXXwKzlf+Lqg3RnmlIio8yo+ayPWdPBPckAQbe7iX20XQQtTT9yBg 88xw6Sshg0ZYa/QnaPxv1ZFUHATm7IdR5XMCAq5FLacEn2MxohGctSHqA+IAaXG9B/TP ioCQ== X-Gm-Message-State: APjAAAWuOdz8P9lcqS9EXYEiRfkRXOkP77kKDqdBR1/qJwfQ1rLt+yY8 LyNaAtOpYDzQbEI8DNvd46sP4frf00GXPJ77QlgsTQ== X-Google-Smtp-Source: APXvYqwfnjvOdYNY6k1i6jmLE2WUOttXjifPQZfMIrm3I+hZ5quPU+o0dXU5eC3+lEl5c4fXnsBMsMitVmj2PDmge08= X-Received: by 2002:ac8:28d0:: with SMTP id j16mr18553323qtj.15.1553475085947; Sun, 24 Mar 2019 17:51:25 -0700 (PDT) MIME-Version: 1.0 References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> In-Reply-To: From: Warner Losh Date: Sun, 24 Mar 2019 18:51:13 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Garrett Cooper Cc: Rebecca Cran , Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 9685F6FE82 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Mon, 25 Mar 2019 00:51:27 -0000 On Sun, Mar 24, 2019, 6:32 PM Enji Cooper wrote: > > > On Mar 24, 2019, at 17:20, Rebecca Cran via freebsd-hackers < > freebsd-hackers@freebsd.org> wrote: > > > >> On 3/24/19 5:57 PM, Warner Losh wrote: > >> > >> > >> He's asking for stopping doing a make install in src/stand. I'm > thinking that's a good thing. We should update the ESP's > \efi\freebsd\loader.efi, but leave the\efi\boot\bootXXXX.efi alone as par= t > of this new installloader phase. Again, only if the ESP is mounted, and w= e > have a default spot for it. For this script, I don't think hunting for th= e > ESP is the right way to go... which means we need to define a standard > place for the ESP to be mounted, which we should do before we turn on any > of these features. > >> > >> We have the start of a generic script to update things in > src/tools/boot/install-boot.sh which was supposed to install boot blocks = on > everything known to run FreeBSD. > > > > > > Only updating \efi\freebsd\loader.efi is the wrong thing to do in my > opinion: there are situations like on ARM where EFI variables aren't > persistent, and we need \efi\boot\bootxxxx.efi for booting. What we could > do is check if QueryVariableInfo returns EFI_UNSUPPORTED, in which case w= e > know any changes to BootXXXX variables won't survive a reboot, and we nee= d > BOOTxxxx.efi. > > > > Is it safe to assume there's only a single ESP in the system? Is it not > normal for there to be one ESP per disk for mirrored configurations, in > which case each would need to be updated? > > > > Do you envision src/tools/boot/install-boot.sh moving to /usr/sbin, or > remaining where it is? We'd also need to update the ESP for binary instal= ls > using freebsd-update. > > I was wondering about builds from scratch, as well=E2=80=94images com= pletely > lacking boot blocks like Jenkins builds. > You wouldn't run installloader on those. It's also a reason I don't want to guess too much... Warner > Thanks! > -Enji From owner-freebsd-hackers@freebsd.org Mon Mar 25 00:54:15 2019 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 2B0A3154B2DE; Mon, 25 Mar 2019 00:54:15 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9DEDE700F6; Mon, 25 Mar 2019 00:54:14 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 2D77FC0AA8; Sun, 24 Mar 2019 18:55:17 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xkT3_JHVcEbw; Sun, 24 Mar 2019 18:55:16 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 18:55:16 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh , Garrett Cooper Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> From: Rebecca Cran Message-ID: <49d1a599-b479-edb1-a88f-48cae19b55af@bluestop.org> Date: Sun, 24 Mar 2019 18:54:12 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Rspamd-Queue-Id: 9DEDE700F6 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Mon, 25 Mar 2019 00:54:15 -0000 On 3/24/19 6:51 PM, Warner Losh wrote: > > On Sun, Mar 24, 2019, 6:32 PM Enji Cooper > wrote: > > > >     I was wondering about builds from scratch, as well—images > completely lacking boot blocks like Jenkins builds. > > > You wouldn't run installloader on those. It's also a reason I don't > want to guess too much... The script as it is looks for partitions of type 'efi' which have a FreeBSD \efi\boot\boot${arch}.efi or \efi\freebsd\loader.efi, and if they exist it'll update them - the assumption being that booting FreeBSD already works, since it's been installed/configured via the installer or some other method. -- Rebecca Cran From owner-freebsd-hackers@freebsd.org Mon Mar 25 00:55:49 2019 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 9B08B154B473; Mon, 25 Mar 2019 00:55:49 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3807370264; Mon, 25 Mar 2019 00:55:49 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 15CAFC0AB1; Sun, 24 Mar 2019 18:56:52 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6kJd_QahdH8S; Sun, 24 Mar 2019 18:56:51 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 18:56:51 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Konstantin Belousov Cc: FreeBSD Hackers , arch@freebsd.org References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> From: Rebecca Cran Message-ID: <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> Date: Sun, 24 Mar 2019 18:55:47 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190325000241.GS1923@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 3807370264 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Mon, 25 Mar 2019 00:55:49 -0000 On 3/24/19 6:02 PM, Konstantin Belousov wrote: > > Having efi_update_loader alone would be fine, but I doubt that this > script can do much except in situations where a lot of pre-assumptions > are true. I believe that despite all the efforts put into efibootmgr > and installer, it is hard/impossible to make the script not dangerous, > except if the whole configuration was created by our installer. It currently does nothing except if there is one or more partitions of type 'efi' that contain a \efi\boot\boot${arch}.efi or \efi\freebsd\loader.efi that contain strings from the FreeBSD boot1.efi or loader.efi. Perhaps that's too much guessing, and we should only ever update /boot/msdos or /boot/efi or wherever we decide to mount it. -- Rebecca Cran From owner-freebsd-hackers@freebsd.org Mon Mar 25 01:34:45 2019 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 1B205154CDCD for ; Mon, 25 Mar 2019 01:34:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2A0D71A35 for ; Mon, 25 Mar 2019 01:34:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x836.google.com with SMTP id y36so8573780qtb.3 for ; Sun, 24 Mar 2019 18:34:44 -0700 (PDT) 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=VdvE+KGTsGuE+pmu8fmbNeAK396tsYhHvb0KhY6v+4I=; b=Ofq25uzEk1NlSjQ3rMs7Ozux1kSDdYUTjI3W/6fHHn0ZeJQW9+6hvSfQvtrGFUeD31 nvYhhwGiA4OqA3FIRyMbA++7C4HlccXjdtk3kaqsEKZyBC3pl9t0Wt4UQsW600rlTexZ /vJsbjK1WagIthMetsr1Db6t8HT06k6oROesrB8i0vfCabXVY8Ra1VI0E2jZ04nKCNh2 tvmJU4e5v3llzml2CiUkXQgqjM8Z4aZLsly2g1TElD/RXDz21crXLyFxUkQQEq9YilJ/ lvAB5hwE3Qn2gN21TWJQdKCnGC2UMcYaB+KVS2WCsRlua14YIzdNmlcVec3zDs/RDoEB C5tQ== 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=VdvE+KGTsGuE+pmu8fmbNeAK396tsYhHvb0KhY6v+4I=; b=lwK1OOkZf2Z0lCs0byP7r0k35r/aSvS+igbe/f4ofHUdn+newRkctZ6qq/tHQFx2Eu UGoSBSHiSnfp1y76pGSpXeV301Q0eAzp4cjBo6DfRXJqFD0fm3sTPkCL2En8aCPJumi1 Z11+sLy33oN3udoY0mcqJBGxl7ZS449h8hv7kHjn3hGRWZnMCLY78PhAxDjJS5QESDoo UP7dvlqzlxnSEn6+mq1jUl0QGZ58b0sbGwrOnQ0tgFBxGxtQlQ/3olsoKFLcpOqo87sV FQR7rjjTY6g14sc6WR5+/iBbskvln7G2p+zuWusesskcSOnYBeoq357CxqypXeCuO6nu 3Xow== X-Gm-Message-State: APjAAAWO3fMEzNZ9mWNLGsPXTzovIBPyrhx4qmS37K8ri6bmMIBBqvsi Fi4bNXEzbmHM2H+HRawtfbllniAs+Wrp0Kte5TTYPw== X-Google-Smtp-Source: APXvYqyw6NMttqVIpT4q/GN+FUZVdHFkry4svbU5lNqCWmDZlNL4WX98uiS3Znzw3t/0M0PXrtPpAPki+qmtKQyY5Dc= X-Received: by 2002:ac8:4685:: with SMTP id g5mr11735232qto.242.1553477684110; Sun, 24 Mar 2019 18:34:44 -0700 (PDT) MIME-Version: 1.0 References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> In-Reply-To: <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> From: Warner Losh Date: Sun, 24 Mar 2019 19:34:33 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Rebecca Cran Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: B2A0D71A35 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Mon, 25 Mar 2019 01:34:45 -0000 On Sun, Mar 24, 2019 at 6:59 PM Rebecca Cran via freebsd-arch < freebsd-arch@freebsd.org> wrote: > On 3/24/19 6:02 PM, Konstantin Belousov wrote: > > > > > Having efi_update_loader alone would be fine, but I doubt that this > > script can do much except in situations where a lot of pre-assumptions > > are true. I believe that despite all the efforts put into efibootmgr > > and installer, it is hard/impossible to make the script not dangerous, > > except if the whole configuration was created by our installer. > > > It currently does nothing except if there is one or more partitions of > type 'efi' that contain a \efi\boot\boot${arch}.efi or > \efi\freebsd\loader.efi that contain strings from the FreeBSD boot1.efi > or loader.efi. Perhaps that's too much guessing, and we should only ever > update /boot/msdos or /boot/efi or wherever we decide to mount it. > Right. We need a standard location (that maybe can be overridden, like you can with /boot, if you really want), and that's likely the first order of business. I don't think we should be second guessing, though. And we shouldn't be touching \efi\boot anything unless specifically instructed to do so. I'm deeply uncomfortable with guessing whether or not to do something... Warner From owner-freebsd-hackers@freebsd.org Mon Mar 25 01:52:37 2019 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 CDCF9154D7F4; Mon, 25 Mar 2019 01:52:37 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 651D7725F1; Mon, 25 Mar 2019 01:52:37 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 920A1C0AF8; Sun, 24 Mar 2019 19:53:39 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id D6LG_xGsqKGM; Sun, 24 Mar 2019 19:53:39 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 19:53:39 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> From: Rebecca Cran Message-ID: Date: Sun, 24 Mar 2019 19:52:34 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 651D7725F1 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Mon, 25 Mar 2019 01:52:38 -0000 On 3/24/19 7:34 PM, Warner Losh wrote: > > Right. We need a standard location (that maybe can be overridden, like you > can with /boot, if you really want), and that's likely the first order of > business. I don't think we should be second guessing, though. And we > shouldn't be touching \efi\boot anything unless specifically instructed to > do so. I'm deeply uncomfortable with guessing whether or not to do > something... Okay. I'm pretty frustrated at only getting this feedback now: I guess I should post here more often! I thought we'd had this discussion a few months ago and you were against mounting the ESP by default, but I can revisit the installer and have it mount to /boot/msdos or /boot/efi or wherever. -- Rebecca Cran From owner-freebsd-hackers@freebsd.org Mon Mar 25 02:06:39 2019 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 9AF8A154DDBD; Mon, 25 Mar 2019 02:06:39 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3489F72C8B; Mon, 25 Mar 2019 02:06:39 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 72A56C0B1B; Sun, 24 Mar 2019 20:07:41 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AU0hisuNZWnT; Sun, 24 Mar 2019 20:07:40 -0600 (MDT) Received: from [10.0.10.197] (unknown [65.103.231.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 20:07:40 -0600 (MDT) Date: Sun, 24 Mar 2019 20:05:43 -0600 From: rebecca@bluestop.org To: Warner Losh , Justin Hibbits Cc: Konstantin Belousov , "=?utf-8?Q?freebsd-arch=40freebsd.org?=" , FreeBSD Hackers Message-ID: In-Reply-To: References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" X-Readdle-Message-ID: db0955a4-6de5-4c7a-b653-4a17a91042b4@Spark MIME-Version: 1.0 X-Rspamd-Queue-Id: 3489F72C8B X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.945,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: Mon, 25 Mar 2019 02:06:39 -0000 On Mar 24, 2019, 8:04 PM -0600, Justin Hibbits , wrote: > > When I added /boot/uboot, primarily for powerpc, Ian suggested we > unify them all into /boot/bootfs, since ARM uses /boot/msdos. With > the EFI partition now needed, I think /boot/bootfs is the better > solution, and the installer can pick the bootfs to mount there into > the fstab. I like that. Rebecca From owner-freebsd-hackers@freebsd.org Mon Mar 25 02:30:16 2019 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 1F971154E6E8; Mon, 25 Mar 2019 02:30:16 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ABFCA736FC; Mon, 25 Mar 2019 02:30:15 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id B5856C0B40; Sun, 24 Mar 2019 20:31:17 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8FBvfxhnXHbK; Sun, 24 Mar 2019 20:31:17 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 20:31:17 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> From: Rebecca Cran Message-ID: <4cdd585b-2469-fb19-9ac6-5d0af7b9f607@bluestop.org> Date: Sun, 24 Mar 2019 20:30:13 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: ABFCA736FC X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.969,0] 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: Mon, 25 Mar 2019 02:30:16 -0000 On 3/24/19 7:34 PM, Warner Losh wrote: > > Right. We need a standard location (that maybe can be overridden, like you > can with /boot, if you really want), and that's likely the first order of > business. I don't think we should be second guessing, though. And we > shouldn't be touching \efi\boot anything unless specifically instructed to > do so. I'm deeply uncomfortable with guessing whether or not to do > something... I'd be wary of *not* touching \efi\boot, since both Microsoft and Linux installs \efi\boot\bootx64.efi. And with desktop systems often not having an UEFI Shell built in and no option to browse for a boot loader from the BIOS, if the FreeBSD boot entry gets lost somehow they're stuck. I discovered recently that rEFInd at least knows to look for \efi\freebsd\loader.efi, but otherwise recovery could be pretty tricky for people who aren't familiar with UEFI. Perhaps adding an option to the efi-update-loader script to search for and list potential ESPs could help, along with good documentation of efibootmgr etc. -- Rebecca Cran From owner-freebsd-hackers@freebsd.org Mon Mar 25 02:45:31 2019 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 258E5154EF6B for ; Mon, 25 Mar 2019 02:45:31 +0000 (UTC) (envelope-from james.wright@jigsawdezign.com) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CAE17456A for ; Mon, 25 Mar 2019 02:45:30 +0000 (UTC) (envelope-from james.wright@jigsawdezign.com) Received: from [192.168.0.15] ([82.18.193.38]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.179]) with ESMTPSA (Nemesis) id 1N6KQZ-1gtFwg1YpV-016j1o for ; Mon, 25 Mar 2019 03:45:23 +0100 Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: freebsd-hackers@freebsd.org References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> <4cdd585b-2469-fb19-9ac6-5d0af7b9f607@bluestop.org> From: James Wright Message-ID: <6fcddcfe-8d0e-d493-7a1b-2ba093dacabb@jigsawdezign.com> Date: Mon, 25 Mar 2019 02:45:22 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <4cdd585b-2469-fb19-9ac6-5d0af7b9f607@bluestop.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Provags-ID: V03:K1:tRyWguORGIPz3jj+cljpXxzcEv788JKxG65uiWqREu/TsMY1pdx nHpAoZh1zMC4qfRWQXxU8GqkTbkE3s+csYASwsQ03Hmm//QSC5+PEylcchZti1wxv6wS3Po 6YP/JOXonw5wP+N7Rvrad8U6q5JhdaSYq+7av/ksnDTtqNTmKG0bKVYu/FR+A6P/EUdtP/k EtvZktI8TVMxFl958xkHw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:oodvE6ELMPA=:J5zakbu1gBnKvDyI8V79WJ eUG6PXiVi69m64zkCT2yZtRUuYHRJrxgM9NxQYFq63KfPbwHpXK2hHrh5kQlAf/QKLo9vzxji sx7cqeewFcQIXXm633wpmROnvJjE6ghTv4YfV64b0kj9ONdadEB1U1rwpaV2EhkiCdbZ6vKR7 fDQARg9Ph3g0n1AP9SANmguj6VJ/aSd2NvRQgHfEPB7yCORU1Zp+AKnkXZCXswhKjNTkvm1Br EF3EZYhgLrcIjzU4QpohzII4z0yAmtaUO/3qpjWcOaQw74N4ouMfFF9WqBA6BGsn++bdF9GIQ M18J09DXRoWVE1Jx7vKS1SiU8EU60WraG7enaJCHh6eagzH/YNkZqPPz1Gr7hhQeaJlLtwaEY mNf2O9hidlz2AO3Z2d+ayMvxJtAnhdLgDFBt9Jh+VEpROvnIH0hbKqLzhnlsL+aFmxbKBibFm TJdhpbAScpER7NGOvJyqvpDSPjdzBcvp1nA2imcnYWvrhn+aKuNrMSCJ6GARw7mo4JD9rr96E aUG5cs9E1+v779AuU6Ns+HNgVWAFwlLX6Q97C1Fkc2O7+LRwdy4PATqU1kTz96tEk4AOZQkry I83b2zeArCc6XGlU0qw/7V6P03FH/RDs4/8YYBxGkgRVDPeqhX0lb/MpYN+h++AVo35B5F9nB /5/7L5h6SQbdADaCGWKQbHP6lUA4A/cDnxY8I5Ejwmy4Pak3dDRjnaotkjinxkrXzW8MLbu1y ud1XVvRy5Qs6slfn3X+VWDf8G+eJHsvQguRNHYBbkNlFxWO+iqJbPt3eEwLqaEUzpUWzSrLvr IS30HCB X-Rspamd-Queue-Id: 8CAE17456A X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Mon, 25 Mar 2019 02:45:31 -0000 FYI... I run a quad boot (OSX, FreeBSD, Debian, Win10) setup on a MacbookAir using rEFInd. Nothing annoys me more than the OSX, Linux, and Win10 updates that decide without warning to replace the boot loader on the ESP. FreeBSD was the only OS that doesn't do this (I'm fine with updating /efi/freebsd/loader.efi manually), please could we not mess about replacing boot loaders on the ESP unless explicitly asked to? On 25/03/2019 02:30, Rebecca Cran via freebsd-hackers wrote: > On 3/24/19 7:34 PM, Warner Losh wrote: > >> >> Right. We need a standard location (that maybe can be overridden, >> like you >> can with /boot, if you really want), and that's likely the first >> order of >> business. I don't think we should be second guessing, though. And we >> shouldn't be touching \efi\boot anything unless specifically >> instructed to >> do so. I'm deeply uncomfortable with guessing whether or not to do >> something... > > > I'd be wary of *not* touching \efi\boot, since both Microsoft and > Linux installs \efi\boot\bootx64.efi. And with desktop systems often > not having an UEFI Shell built in and no option to browse for a boot > loader from the BIOS, if the FreeBSD boot entry gets lost somehow > they're stuck. I discovered recently that rEFInd at least knows to > look for \efi\freebsd\loader.efi, but otherwise recovery could be > pretty tricky for people who aren't familiar with UEFI. Perhaps adding > an option to the efi-update-loader script to search for and list > potential ESPs could help, along with good documentation of efibootmgr > etc. > > From owner-freebsd-hackers@freebsd.org Mon Mar 25 03:19:50 2019 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 205A3154FCC4 for ; Mon, 25 Mar 2019 03:19:50 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 41C80756F1 for ; Mon, 25 Mar 2019 03:19:48 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 7B846C0B6E; Sun, 24 Mar 2019 21:20:50 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id z4gpe0WmLJxE; Sun, 24 Mar 2019 21:20:50 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sun, 24 Mar 2019 21:20:50 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: James Wright , freebsd-hackers@freebsd.org References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> <4cdd585b-2469-fb19-9ac6-5d0af7b9f607@bluestop.org> <6fcddcfe-8d0e-d493-7a1b-2ba093dacabb@jigsawdezign.com> From: Rebecca Cran Message-ID: <0905d5e8-fd5c-a1ac-ef38-84a01bd557fa@bluestop.org> Date: Sun, 24 Mar 2019 21:19:45 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <6fcddcfe-8d0e-d493-7a1b-2ba093dacabb@jigsawdezign.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 41C80756F1 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.92 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bluestop.org:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.00)[ipnet: 65.100.0.0/14(-4.89), asn: 209(-0.03), country: US(-0.07)]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bluestop.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bluestop.org,quarantine]; MX_GOOD(-0.01)[mail.bluestop.org]; NEURAL_HAM_SHORT(-0.91)[-0.914,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:209, ipnet:65.100.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[] 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: Mon, 25 Mar 2019 03:19:50 -0000 On 3/24/19 8:45 PM, James Wright wrote: > > FYI... I run a quad boot (OSX, FreeBSD, Debian, Win10) setup on a > MacbookAir using rEFInd. Nothing annoys me more than the OSX, Linux, > and Win10 updates that decide without warning to replace the boot > loader on the ESP. FreeBSD was the only OS that doesn't do this (I'm > fine with updating /efi/freebsd/loader.efi manually), please could we > not mess about replacing boot loaders on the ESP unless explicitly > asked to? Good point - that does annoy me too! -- Rebecca Cran From owner-freebsd-hackers@freebsd.org Mon Mar 25 02:02:51 2019 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 A5C54154DCCF; Mon, 25 Mar 2019 02:02:51 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01C4372B84; Mon, 25 Mar 2019 02:02:51 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-lj1-x22a.google.com with SMTP id q66so6368171ljq.7; Sun, 24 Mar 2019 19:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cwru-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aJeu1NTURKy1VWVkLtvE5BtQ2OWfA6tHpBYYJQICpn8=; b=FCLd0ArOzBJvkh22jT0tanZmm9kQj9tDlsbCqaizikpzsl0by6S1liKLmQh1t3iT4h nopUmhtIdOh/3PZ3T0NpHC8S2sKlWm7W0gIP1fxJfKeE4/owD/v4yHBEVcbFX53PocFF UkcH9iChb0HqP03lFOLOGMPx89Mfls4WMf9fPkHVyQAH+aNknf0MsZLUsGDXMObeKxLW YVOectw34807j1gZsT32fiM9iIKwdSgdHQjSja/6sespd4XSRcTmSGisUI2tUl4TE6W3 e7YvxKwSpKcbb80lsHSJEwmYWTaDOY1BPOcj8WdAp8s1luC4PjpgCXErZQbmRiw1uIih MsjQ== 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=aJeu1NTURKy1VWVkLtvE5BtQ2OWfA6tHpBYYJQICpn8=; b=VPK1c2leUgIIx8Q+oHMkEAW3TJTPbLf2ITzin/u4hqtmjWnKZYKm9xWkk/t99K3+4m Z446DS1jdFS0aTknMunLWpmuv6AMS3lyrEYYkC08Hh+oO/1F2nsVEwYSzbX1TMApptyE w3a/73Tv5L1elfznbVR15o+J/RpupFRxpw8Nv6fYMzdiTYwpjKCKtGe0dzHlapRCdRQ6 ShNlqdepaNTIVR7mWbY26I5HiHmUulaP4g0NXFay3UBczxNiH3m/EPpMj5ZOXfNfC9/v 84FH7v62WRHH3CTinPukDUBXE/Twyn2pnuKr2+rbu7ZVMLOoWUo1+cAEnfz1xhmGclmI SUqQ== X-Gm-Message-State: APjAAAUmOg7+Y04v87TmFockyci5cw3KzbMSXxJVDSkjRE0zpxqasby4 fVBTbo4igsnYrueJLGxgHfQ8/qIKHsoSv4xyUoE= X-Google-Smtp-Source: APXvYqwAZTZC0373bARniAumS0NoPfLQzQFvuTl7y7XcfLHMTdHOhvrXp7y1fpWkLczcdQ3g2TK8V68L538K9fAn7cM= X-Received: by 2002:a2e:974d:: with SMTP id f13mr11430479ljj.140.1553479369343; Sun, 24 Mar 2019 19:02:49 -0700 (PDT) MIME-Version: 1.0 References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <20190325000241.GS1923@kib.kiev.ua> <6badde15-d8f4-c4ea-2061-0d3c80c6e82a@bluestop.org> In-Reply-To: From: Justin Hibbits Date: Sun, 24 Mar 2019 21:02:36 -0500 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: Rebecca Cran , Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 01C4372B84 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.943,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-Mailman-Approved-At: Mon, 25 Mar 2019 03:22:39 +0000 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: Mon, 25 Mar 2019 02:02:52 -0000 On Sun, Mar 24, 2019 at 8:38 PM Warner Losh wrote: ... > > Right. We need a standard location (that maybe can be overridden, like you > can with /boot, if you really want), and that's likely the first order of > business. I don't think we should be second guessing, though. And we > shouldn't be touching \efi\boot anything unless specifically instructed to > do so. I'm deeply uncomfortable with guessing whether or not to do > something... > > Warner When I added /boot/uboot, primarily for powerpc, Ian suggested we unify them all into /boot/bootfs, since ARM uses /boot/msdos. With the EFI partition now needed, I think /boot/bootfs is the better solution, and the installer can pick the bootfs to mount there into the fstab. - Justin From owner-freebsd-hackers@freebsd.org Mon Mar 25 09:26:49 2019 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 F0187155883F; Mon, 25 Mar 2019 09:26:48 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AEBD788681; Mon, 25 Mar 2019 09:26:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2P9QgaN078737; Mon, 25 Mar 2019 02:26:42 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2P9QgYK078736; Mon, 25 Mar 2019 02:26:42 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: <20190324090103.GO1923@kib.kiev.ua> To: Konstantin Belousov Date: Mon, 25 Mar 2019 02:26:42 -0700 (PDT) CC: Rebecca Cran , FreeBSD Hackers , arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: AEBD788681 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.14 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.01)[-0.009,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.50)[0.502,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.74)[0.739,0]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.02)[ip: (0.08), ipnet: 69.59.192.0/19(0.04), asn: 13868(0.02), country: US(-0.07)] 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: Mon, 25 Mar 2019 09:26:49 -0000 > On Sat, Mar 23, 2019 at 08:21:43PM -0600, Rebecca Cran via freebsd-hackers wrote: > > I've been working on EFI support, and have a review > > (https://reviews.freebsd.org/D19588) to add a script, efi-update-loader, > > which will update the ESP containing the FreeBSD boot1.efi or loader.efi. > > > > I'd like to integrate it into the build system so it gets run when users > > do a "make installworld", but I'm lost looking through Makefile.inc1 - I > > have no clue where to add the code. > > > > Does anyone understand where and what to add? > > Can we take use of the opportunity and finally stop installing loader > at installworld target at all, please ? > > Add e.g. installloader target which would do whatever needed to loader. +1 boot code and loaders should always be seperated from the install target. Historically this was casued by the fact that the boot code and loader lived outside the file system and required operations beyond updating /usr/mdec (very ancient) or /boot/boot* (historical). Now that /boot/loader* is an immeditate effect on the bootability of the system it makes since to seperate this from the installworld target. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Mar 25 10:33:31 2019 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 45AB6155AC1A; Mon, 25 Mar 2019 10:33:31 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB9618B3E4; Mon, 25 Mar 2019 10:33:30 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2PAXMuC079241; Mon, 25 Mar 2019 03:33:22 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2PAXMBK079240; Mon, 25 Mar 2019 03:33:22 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903251033.x2PAXMBK079240@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: To: rebecca@bluestop.org Date: Mon, 25 Mar 2019 03:33:22 -0700 (PDT) CC: Warner Losh , Justin Hibbits , Konstantin Belousov , "=?utf-8?Q?freebsd-arch=40freebsd.org?=" , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: BB9618B3E4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.937,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Mon, 25 Mar 2019 10:33:31 -0000 > On Mar 24, 2019, 8:04 PM -0600, Justin Hibbits , wrote: > > > > When I added /boot/uboot, primarily for powerpc, Ian suggested we > > unify them all into /boot/bootfs, since ARM uses /boot/msdos. With > > the EFI partition now needed, I think /boot/bootfs is the better > > solution, and the installer can pick the bootfs to mount there into > > the fstab. > > > I like that. +1 > Rebecca -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Mar 25 10:33:51 2019 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 8AE84155AC6C; Mon, 25 Mar 2019 10:33:51 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2617D8B44F; Mon, 25 Mar 2019 10:33:50 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [192.168.0.12] (cpc91194-cmbg18-2-0-cust919.5-4.cable.virginm.net [80.6.183.152]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 9A2F04E6E6; Mon, 25 Mar 2019 10:33:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1553510021; bh=Z8MAmmC/K8A9vCio/5nSFTsKReU1TEGDIP9cGfn8Wts=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=diWjpZWxC203lQ0fMViGvt+ArAmDZbEyj2MxU22WGidLAfXTcvG+J1mLNfglQvLl9 Jli3UZuNxbh12VoLGCeq3XLK/TlqvjsciK1+o7l5ma31zLjkgdWreMtfvMvwnPsRs6 BC6v6r4y7AfutZAW8oCjZLyzkEROlTU8WvzTH87uEwuGDNsUd7CoiwdnFacPUs2xja 29Y2YDZ3mrSPCa8xHQLNMFXFwNb/LDIPQKYDpfhMVN8skRrEFcSl8I3EuqN7rdEm18 c4f081xWBmLrTWA9I4EZZky6oOu8N7vE0Reel/ZRVXf0SAtmyR0BHfxF5wEk5m61bF 9SBaxyr1EZ32fsNnPC8///TF4tv8UEqDWTDSXEK7pKrzo43Pn9iTNnkmT4rMQSLg8C /o/BmY9+DUxPJkR1qoHrTsuvASNLJBtWy+PhpMLtoidK4/vk1xYIkTQhc6oi1JLdcd eMCDz+Vs4b7VKDO6mkQbmZJJsCLnPL+beHh3yGTUta2uiGStGeAJtEspTyERG0Iszj zc1BkcHTHUrwWL04Pm5hc64M0yzo+Na7AzgDXmaV/jzvYiacArTki3ls7EcOtQAyV6 ScakReWiO4llhYOv9BsI+Kr2Y9BHVuFqpzNCZXRX+oaLJAF+RgxGWcdYvJm7L/fbr6 IrPnGVi+v/vPSk0RBCVxdwOE= From: Andrew Turner Message-Id: <2E6E33E9-FF5E-4198-AC48-37C0873CAF95@fubar.geek.nz> Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" Date: Mon, 25 Mar 2019 10:33:40 +0000 In-Reply-To: Cc: Rebecca Cran , Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" To: Warner Losh References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 2617D8B44F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.967,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 25 Mar 2019 10:33:51 -0000 > On 25 Mar 2019, at 00:49, Warner Losh wrote: >=20 > On Sun, Mar 24, 2019, 6:20 PM Rebecca Cran > wrote: >=20 >> On 3/24/19 5:57 PM, Warner Losh wrote: >>=20 >>=20 >> He's asking for stopping doing a make install in src/stand. I'm = thinking >> that's a good thing. We should update the ESP's = \efi\freebsd\loader.efi, >> but leave the\efi\boot\bootXXXX.efi alone as part of this new = installloader >> phase. Again, only if the ESP is mounted, and we have a default spot = for >> it. For this script, I don't think hunting for the ESP is the right = way to >> go... which means we need to define a standard place for the ESP to = be >> mounted, which we should do before we turn on any of these features. >>=20 >> We have the start of a generic script to update things in >> src/tools/boot/install-boot.sh which was supposed to install boot = blocks on >> everything known to run FreeBSD. >>=20 >>=20 >> Only updating \efi\freebsd\loader.efi is the wrong thing to do in my >> opinion: there are situations like on ARM where EFI variables aren't >> persistent, and we need \efi\boot\bootxxxx.efi for booting. What we = could >> do is check if QueryVariableInfo returns EFI_UNSUPPORTED, in which = case we >> know any changes to BootXXXX variables won't survive a reboot, and we = need >> BOOTxxxx.efi. >>=20 > Systems that don't support variables are a super duper weird special = case. > Let's not let them drive the design. I want to get to (a) a = standardized > mount point and (b) drive people towards having the boot loader be in > /efi/freebsd/loader.efi. our tooling should reflect that first and > foremost. The weirdo, special cases that likely won't be updating from > source are secondary. Let's get a good design flow down first for the = most > common case, one that encourages the most people to adopt the standard = boot > flow as possible. Systems that don=E2=80=99t support reading variables are weird, however = systems that don=E2=80=99t support writing valuables are common for arm = and arm64. The EBBR spec [1] that Arm and others are working on allows = both reading and writing variables via the runtime services as optional = [2]. This is because these variables may be stored on the same media as = the OS. It would be nice if we could support this case, even if it=E2=80=99s not = the default on systems that support setting variables. Andrew [1] https://github.com/ARM-software/ebbr [2] = https://github.com/ARM-software/ebbr/blob/v1.0-rc1/source/chapter2-uefi.rs= t From owner-freebsd-hackers@freebsd.org Mon Mar 25 10:36:37 2019 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 9A305155AEEE for ; Mon, 25 Mar 2019 10:36:37 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 730E98B752 for ; Mon, 25 Mar 2019 10:36:36 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2PAaX8Q079264; Mon, 25 Mar 2019 03:36:33 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2PAaXsA079263; Mon, 25 Mar 2019 03:36:33 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903251036.x2PAaXsA079263@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: <6fcddcfe-8d0e-d493-7a1b-2ba093dacabb@jigsawdezign.com> To: James Wright Date: Mon, 25 Mar 2019 03:36:33 -0700 (PDT) CC: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 730E98B752 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [0.95 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.28)[0.285,0]; NEURAL_HAM_LONG(-0.44)[-0.437,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.20)[0.202,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.02)[ip: (0.08), ipnet: 69.59.192.0/19(0.04), asn: 13868(0.02), country: US(-0.07)] 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: Mon, 25 Mar 2019 10:36:37 -0000 > > FYI... I run a quad boot (OSX, FreeBSD, Debian, Win10) setup on a > MacbookAir using rEFInd. Nothing annoys me more than the OSX, Linux, and > Win10 updates that decide without warning to replace the boot loader on > the ESP. FreeBSD was the only OS that doesn't do this (I'm fine with > updating /efi/freebsd/loader.efi manually), please could we not mess > about replacing boot loaders on the ESP unless explicitly asked to? I absolutely agree with this possition. As one who at any time may have various disk drives mounted that have nothing to do with my currently running system code that mucks with bootcode that is not explicityly invoked by me is very likely to make a mess of things. I very often have more than one boot type drive attached to a system. > On 25/03/2019 02:30, Rebecca Cran via freebsd-hackers wrote: > > On 3/24/19 7:34 PM, Warner Losh wrote: > > > >> > >> Right. We need a standard location (that maybe can be overridden, > >> like you > >> can with /boot, if you really want), and that's likely the first > >> order of > >> business. I don't think we should be second guessing, though. And we > >> shouldn't be touching \efi\boot anything unless specifically > >> instructed to > >> do so. I'm deeply uncomfortable with guessing whether or not to do > >> something... > > > > > > I'd be wary of *not* touching \efi\boot, since both Microsoft and > > Linux installs \efi\boot\bootx64.efi. And with desktop systems often > > not having an UEFI Shell built in and no option to browse for a boot > > loader from the BIOS, if the FreeBSD boot entry gets lost somehow > > they're stuck. I discovered recently that rEFInd at least knows to > > look for \efi\freebsd\loader.efi, but otherwise recovery could be > > pretty tricky for people who aren't familiar with UEFI. Perhaps adding > > an option to the efi-update-loader script to search for and list > > potential ESPs could help, along with good documentation of efibootmgr > > etc. > > > > > > _______________________________________________ > 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" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Mar 25 15:06:00 2019 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 893AE15643FF for ; Mon, 25 Mar 2019 15:06:00 +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 "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 22E7C702D2 for ; Mon, 25 Mar 2019 15:06:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82e.google.com with SMTP id v32so10608367qtc.10 for ; Mon, 25 Mar 2019 08:06:00 -0700 (PDT) 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=FDfsshC9FKErvG/Uc+ILi7Fjxse6R0055fLkUe05UPQ=; b=kf0HGvprXrrnWEF0viPKHCNtWCxHPd87TfYFZxJ1T+21mgdJi5MgQ+1m9HgP3CHewB SkWPJLRVUDhPs9Qiq468x8AKILZQlT63GnK/+TFBgpsYN0E2g1Od2At0+qXZ5bx9T9Uj Y/t9h7DXK3mHrbLuH+yFLrFbJEbuxTHU0dnlo4QVfwB7A93ItKDLA9hA+v4P75QpLGYz ENpjgjqN8xQWJErf7RBS6Tqy54J1Co8Yn3gwnTc+3z3t0B4+r+D4sudo7DaZ/9a9Odxp C79VxLS4nP8EEIlXJviOmpo3RbVTJr3n+j8YZCZbJlydO/OpMQ/tM5NcbHfYfcw5ErDg J0Zg== 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=FDfsshC9FKErvG/Uc+ILi7Fjxse6R0055fLkUe05UPQ=; b=pPKbs6CpypnJjPX3M1pCWAgoZATEUzkd8WTTFXTQzAln/O78FE7LpYCXgSVhn+wbwF JNIBFXXeHLt+VPtuYYSzXg9H6Vcm/Q+dtK7uRUCmIj+Et1lcG+4pNSFB7R4cShPI5RZH NT6pPzuIwk5ViMdp74g1IIz5zakUj7tNMnaKvhekyeB3bws7eVCjW7+jFxS9qAAKNFMR P8WKqfQIN9OEtg16iYBmoqXJyP3PGxtGJbHsG0xzrMjVb6M1F6pkuOBG9jQnIBp2xOA1 x2AMKraSR7mgAnFzrTn1y062jXMFLQ7JjPZdjEHsxWs8Ui2oCQZU++nHB8AnNH1aU22Y 49KA== X-Gm-Message-State: APjAAAUy09y6Z6U1aiHKjLEzY3Jm6uux7oY+QJAxZKozOcQI1QRGt03x wqOgyrlPwbIKwQClXqzPJ8LYFHN4JhFEEMyyXiOClEqw X-Google-Smtp-Source: APXvYqzFLUDxjfu0plK9EZWKzOJodrQLiAvkmqamurWgJG4+4IStDM+r4XQeMvhehvqZzjVIXtYQNMqYZtxXj/tlkg4= X-Received: by 2002:a0c:d2fc:: with SMTP id x57mr19537966qvh.214.1553526359472; Mon, 25 Mar 2019 08:05:59 -0700 (PDT) MIME-Version: 1.0 References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> In-Reply-To: <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> From: Warner Losh Date: Mon, 25 Mar 2019 09:05:45 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , Rebecca Cran , FreeBSD Hackers X-Rspamd-Queue-Id: 22E7C702D2 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.979,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Mon, 25 Mar 2019 15:06:00 -0000 On Mon, Mar 25, 2019, 3:28 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > On Sat, Mar 23, 2019 at 08:21:43PM -0600, Rebecca Cran via > freebsd-hackers wrote: > > > I've been working on EFI support, and have a review > > > (https://reviews.freebsd.org/D19588) to add a script, > efi-update-loader, > > > which will update the ESP containing the FreeBSD boot1.efi or > loader.efi. > > > > > > I'd like to integrate it into the build system so it gets run when > users > > > do a "make installworld", but I'm lost looking through Makefile.inc1 - > I > > > have no clue where to add the code. > > > > > > Does anyone understand where and what to add? > > > > Can we take use of the opportunity and finally stop installing loader > > at installworld target at all, please ? > > > > Add e.g. installloader target which would do whatever needed to loader. > > +1 boot code and loaders should always be seperated from the > install target. Historically this was casued by the fact that > the boot code and loader lived outside the file system and > required operations beyond updating /usr/mdec (very ancient) > or /boot/boot* (historical). Now that /boot/loader* is an > immeditate effect on the bootability of the system it makes > since to seperate this from the installworld target. > We started installing /boot/loader with install world in FreeBSD -3.x and it has affected the boot ability that whole time... in the early days of loader, the kernel loader handoff protocol was immature enough to need a matched kernel. But that period lasted only a few months... loader has also been weird in other ways as well, since some embedded systems used the one in its, while others needed an extra step. As UEFI support has matured we're finding there are several issues around it as well where updating the ESP needs to be tied to updating /boot for the system to work sometimes. It has grown more complex over time, so we should separate. It's been a little weird on all the non x86 platforms to different degrees, but now that our main platform is affected it's become clear we may need to change. But we need to do so carefully as this violates POLA in a huge way, as well as needing doc changes in a bajillion places. Warner -- > Rod Grimes > rgrimes@freebsd.org > _______________________________________________ > 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" > From owner-freebsd-hackers@freebsd.org Mon Mar 25 18:34:55 2019 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 4471B154937C; Mon, 25 Mar 2019 18:34:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCD7482243; Mon, 25 Mar 2019 18:34:54 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id BFB34157B; Mon, 25 Mar 2019 18:34:52 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh , "Rodney W. Grimes" Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> Date: Mon, 25 Mar 2019 11:34:50 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: DCD7482243 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.962,0] 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: Mon, 25 Mar 2019 18:34:55 -0000 On 3/25/19 8:05 AM, Warner Losh wrote: > We started installing /boot/loader with install world in FreeBSD -3.x and > it has affected the boot ability that whole time... in the early days of > loader, the kernel loader handoff protocol was immature enough to need a > matched kernel. But that period lasted only a few months... loader has > also been weird in other ways as well, since some embedded systems used the > one in its, while others needed an extra step. As UEFI support has matured > we're finding there are several issues around it as well where updating the > ESP needs to be tied to updating /boot for the system to work sometimes. It > has grown more complex over time, so we should separate. It's been a little > weird on all the non x86 platforms to different degrees, but now that our > main platform is affected it's become clear we may need to change. > > But we need to do so carefully as this violates POLA in a huge way, as well > as needing doc changes in a bajillion places. I think we should treat files on the ESP the same way we treat other boot blocks. installworld should continue to install the latest version into /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some other tool is used by the user to copy the updated loader.efi into the ESP. I think the main difference here is that traditionally other boot blocks didn't change very often, so no one really needed to update it them post-install. loader.efi changes often enough we probably need to document updating the ESP as an optional step in the upgrade process. I think having an automagical script will probably go sideways, but standardizing where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) means we can provide a script with defaults (or instructions) that work with the standardized approach. -- John Baldwin From owner-freebsd-hackers@freebsd.org Mon Mar 25 19:27:35 2019 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 B303D154AE6A for ; Mon, 25 Mar 2019 19:27:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53D9684357 for ; Mon, 25 Mar 2019 19:27:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82f.google.com with SMTP id v32so11714670qtc.10 for ; Mon, 25 Mar 2019 12:27:35 -0700 (PDT) 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=TV9WE/1CHx0uhsY0wUvZtlzys+nMywFvBDp7zNPrPNE=; b=CZm3Dd1b604cnUQ3yKbfWheMaVY2PLefzAvRxRoyd+smLYXSJZVnEsY0JkCBGV5gJU JXEynvk55a3LVAZi/La9U5LM9TNpvo61WiqrYYFhevGJuhwgbjr5feIiGGqtmWLPoNJl EV2SZglhyLklCb9QRzDzIExY8tyiiv6fX7YpldOggMM2qDLOgLnF4sIbfULZvE8Pvgre wUzngHI4CmMV9nI6FBN3TRWabWK7+YZA9t0ewgR0sIkjPZgLX0akRp7vlg7o+jqqKrKi JmfMNaqjNalW198l7rqjQgdSDTN4f6wPtnXLIUuG5tii40Y9fWVyrp6uUPG7R/4cgBNS DrLg== 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=TV9WE/1CHx0uhsY0wUvZtlzys+nMywFvBDp7zNPrPNE=; b=DRf4SleGQWMaOC5m94eMwVCcnhRm2DJNNlRxSYIwAsOMLl5XlnyVoxptpw7Se6Vnkw +zsvkS5JWmZOSlilTX66biNQneoikXaJHIukXjjmpfTy3HwR3LX1TFe6QZ1k5VqI0omc hL1ugjfDbztVzPc0DF/XKxniwtxMDUn4MoI9vC0BIYmpzPME55BCcbuOjLu2QVn2I1ml tty0gpOrdtTQ7KNq4aSjt5/g8gSx83CF9eYKxmesZgoksz6CJ4pzPXYGvLOiLUaucJI4 m3LLHFMq+uTgmdbwzzIlfw9dp8FuKMvkYCFjHJLK/ByxzFxwOSbrsYUB8dAfCONUEOBO OG3w== X-Gm-Message-State: APjAAAXhohQaWqfSnoEUCu3em7QTfy6lyYJYf67CZyAkGhLTIQP6XhVg 6s4oBwPWgswKoCc+hC+UkBrw53+5ficmYBARLnFSrw== X-Google-Smtp-Source: APXvYqwVR8xULRC2s3FfaOQK7Yg3u/ufj4hCrX0Htgjzu+JFwhmHj25ukrTCBvqgh5sHx8yZ40Ux1F5TLCXMtkQlWjM= X-Received: by 2002:ac8:1aec:: with SMTP id h41mr21143132qtk.345.1553542054660; Mon, 25 Mar 2019 12:27:34 -0700 (PDT) MIME-Version: 1.0 References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> In-Reply-To: <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> From: Warner Losh Date: Mon, 25 Mar 2019 13:27:21 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: John Baldwin Cc: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran X-Rspamd-Queue-Id: 53D9684357 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.957,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Mon, 25 Mar 2019 19:27:35 -0000 On Mon, Mar 25, 2019, 12:34 PM John Baldwin wrote: > On 3/25/19 8:05 AM, Warner Losh wrote: > > We started installing /boot/loader with install world in FreeBSD -3.x and > > it has affected the boot ability that whole time... in the early days of > > loader, the kernel loader handoff protocol was immature enough to need a > > matched kernel. But that period lasted only a few months... loader has > > also been weird in other ways as well, since some embedded systems used > the > > one in its, while others needed an extra step. As UEFI support has > matured > > we're finding there are several issues around it as well where updating > the > > ESP needs to be tied to updating /boot for the system to work sometimes. > It > > has grown more complex over time, so we should separate. It's been a > little > > weird on all the non x86 platforms to different degrees, but now that our > > main platform is affected it's become clear we may need to change. > > > > But we need to do so carefully as this violates POLA in a huge way, as > well > > as needing doc changes in a bajillion places. > > I think we should treat files on the ESP the same way we treat other boot > blocks. installworld should continue to install the latest version into > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some other > tool is used by the user to copy the updated loader.efi into the ESP. > > I think the main difference here is that traditionally other boot blocks > didn't change very often, so no one really needed to update it them > post-install. loader.efi changes often enough we probably need to document > updating the ESP as an optional step in the upgrade process. I think > having an automagical script will probably go sideways, but standardizing > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) means > we can provide a script with defaults (or instructions) that work with > the standardized approach. > I think we need to have some automation in place. Something very specific and concrete. Otherwise we run the risk of updating the support files without updating loader.efi, possibly breaking boot if we wanted to add a new API to lua that the startup scripts call. Without an update of loader.efi, this generates an error. I view /efi/boot/* as boot blocks, for these purposes, bit /efi/freebsd as fair game to update. So there is some nuance here we need to take into account and avoid absolutes about the BSP. -- > John Baldwin > From owner-freebsd-hackers@freebsd.org Mon Mar 25 20:30:15 2019 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 24DB2154CEC0; Mon, 25 Mar 2019 20:30:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B89C5862F1; Mon, 25 Mar 2019 20:30:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 562E92173; Mon, 25 Mar 2019 20:30:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Mon, 25 Mar 2019 13:30:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B89C5862F1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.960,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Mon, 25 Mar 2019 20:30:15 -0000 On 3/25/19 12:27 PM, Warner Losh wrote: > On Mon, Mar 25, 2019, 12:34 PM John Baldwin wrote: > >> On 3/25/19 8:05 AM, Warner Losh wrote: >>> We started installing /boot/loader with install world in FreeBSD -3.x and >>> it has affected the boot ability that whole time... in the early days of >>> loader, the kernel loader handoff protocol was immature enough to need a >>> matched kernel. But that period lasted only a few months... loader has >>> also been weird in other ways as well, since some embedded systems used >> the >>> one in its, while others needed an extra step. As UEFI support has >> matured >>> we're finding there are several issues around it as well where updating >> the >>> ESP needs to be tied to updating /boot for the system to work sometimes. >> It >>> has grown more complex over time, so we should separate. It's been a >> little >>> weird on all the non x86 platforms to different degrees, but now that our >>> main platform is affected it's become clear we may need to change. >>> >>> But we need to do so carefully as this violates POLA in a huge way, as >> well >>> as needing doc changes in a bajillion places. >> >> I think we should treat files on the ESP the same way we treat other boot >> blocks. installworld should continue to install the latest version into >> /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some other >> tool is used by the user to copy the updated loader.efi into the ESP. >> >> I think the main difference here is that traditionally other boot blocks >> didn't change very often, so no one really needed to update it them >> post-install. loader.efi changes often enough we probably need to document >> updating the ESP as an optional step in the upgrade process. I think >> having an automagical script will probably go sideways, but standardizing >> where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) means >> we can provide a script with defaults (or instructions) that work with >> the standardized approach. >> > > I think we need to have some automation in place. Something very specific > and concrete. Otherwise we run the risk of updating the support files > without updating loader.efi, possibly breaking boot if we wanted to add a > new API to lua that the startup scripts call. Without an update of > loader.efi, this generates an error. > > I view /efi/boot/* as boot blocks, for these purposes, bit /efi/freebsd as > fair game to update. So there is some nuance here we need to take into > account and avoid absolutes about the BSP. Hmm, I guess we considered it a bad idea to store all the support scripts (not loader.conf, but all the 4th/lua) on the esp beside the loader? That would make the ESP bits be a self-contained, consistent snapshot. loader.efi could perhaps prefer to find those files on the partition it was loaded from (you know that IIRC since when you are executed as an EFI app you get a pointer to your Image and it has a backpointer to the device you came from I thought) before looking for them on the root filesystem? This would let it still work when boot1.efi lives on the ESP instead, and also in the case that you just copied loader.efi into the ESP without the support scripts. -- John Baldwin From owner-freebsd-hackers@freebsd.org Mon Mar 25 20:41:30 2019 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 1A032154D641 for ; Mon, 25 Mar 2019 20:41:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACAF486C90 for ; Mon, 25 Mar 2019 20:41:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72d.google.com with SMTP id b74so6237472qkg.9 for ; Mon, 25 Mar 2019 13:41:29 -0700 (PDT) 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=QLkpG0JhvO0oH/Uv5/GxXzCVnUdEo3TcGGtNZrpnLeY=; b=yj6Z+Ar64xjzrNuoZjhKi9VM5NEGuR1Xt9yeZEKnQjFOsGwd1XpQJVn40rrE+HORrq Au5Ducf+YtctWYnRPMAHqvasZR3s2zNb3fDd5flV84kUViorm6/lNkCTtN4MGVcNhHJl bB1KH3Df1PXcNIG3ynJGSeIBi+Rb33oJT4iqwU4Pst9x0gjXKM9eCH1i5ed1q0K6pH2Z D59ZSTdEaG22NEOgys3YEWwzMyZhYE3u/yOnALeeLyHynKeUznqLL1L/l4el0HbSQG0O q44/MMpL+GK29y1UMGHGFN5P7hRGNf2XAB9PtGhsvNa6HVXqwFwl5C7GOmmXn6vmgZm5 fwQA== 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=QLkpG0JhvO0oH/Uv5/GxXzCVnUdEo3TcGGtNZrpnLeY=; b=nM+Mr2qdA1dvSdF5BD2G68KE2zsvAWxTZPhPZ/CiK9tw78XG56egVlSmeRM3X/oXqS 5eNms/4i9+1njatLINb+9a7eTF0IojNDgejftrvzg6III9O0IkZX4UpjF49CYipy9VTh Dp3qa8WxY4H86o8r3jJJHu2Lg8eoY2rltz2g7AoxnMkh44H0o40s3BvLKqR/OC2nN3Ny U6eJ9CKsedtx6RDLrGcY6uRwkAFKLbevowC7kXWA+WDMFd5RywLcZom/UcfH3d9b4OmP dJz9lObiebsCuI9/JTpRrVYb2wiAXjEpCFm1flenYPjgm9bSY8Kgc1FizBZthoXRxGiP oosw== X-Gm-Message-State: APjAAAWse2coBDeOH17cyGxdfyj4sIFC5s0pJfHiLpiF4f7OhQvLbuEP YUEWPdNVmkCpXM0cJ3EHKifSWMg4rHOKO3vtUNCL4w== X-Google-Smtp-Source: APXvYqyTppDY8D8ZcN/rAYyiQccixLSWDC3zZgDIr1m02RFQUvp3WdFnE2vCpHXN1DGemD1bHwhFqpa5EayZOAHSEwU= X-Received: by 2002:a05:620a:132b:: with SMTP id p11mr21713731qkj.279.1553546488966; Mon, 25 Mar 2019 13:41:28 -0700 (PDT) MIME-Version: 1.0 References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Mon, 25 Mar 2019 14:41:17 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: John Baldwin Cc: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran X-Rspamd-Queue-Id: ACAF486C90 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Mon, 25 Mar 2019 20:41:30 -0000 On Mon, Mar 25, 2019 at 2:30 PM John Baldwin wrote: > On 3/25/19 12:27 PM, Warner Losh wrote: > > On Mon, Mar 25, 2019, 12:34 PM John Baldwin wrote: > > > >> On 3/25/19 8:05 AM, Warner Losh wrote: > >>> We started installing /boot/loader with install world in FreeBSD -3.x > and > >>> it has affected the boot ability that whole time... in the early days > of > >>> loader, the kernel loader handoff protocol was immature enough to need > a > >>> matched kernel. But that period lasted only a few months... loader has > >>> also been weird in other ways as well, since some embedded systems used > >> the > >>> one in its, while others needed an extra step. As UEFI support has > >> matured > >>> we're finding there are several issues around it as well where updating > >> the > >>> ESP needs to be tied to updating /boot for the system to work > sometimes. > >> It > >>> has grown more complex over time, so we should separate. It's been a > >> little > >>> weird on all the non x86 platforms to different degrees, but now that > our > >>> main platform is affected it's become clear we may need to change. > >>> > >>> But we need to do so carefully as this violates POLA in a huge way, as > >> well > >>> as needing doc changes in a bajillion places. > >> > >> I think we should treat files on the ESP the same way we treat other > boot > >> blocks. installworld should continue to install the latest version into > >> /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some > other > >> tool is used by the user to copy the updated loader.efi into the ESP. > >> > >> I think the main difference here is that traditionally other boot blocks > >> didn't change very often, so no one really needed to update it them > >> post-install. loader.efi changes often enough we probably need to > document > >> updating the ESP as an optional step in the upgrade process. I think > >> having an automagical script will probably go sideways, but > standardizing > >> where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) > means > >> we can provide a script with defaults (or instructions) that work with > >> the standardized approach. > >> > > > > I think we need to have some automation in place. Something very specific > > and concrete. Otherwise we run the risk of updating the support files > > without updating loader.efi, possibly breaking boot if we wanted to add a > > new API to lua that the startup scripts call. Without an update of > > loader.efi, this generates an error. > > > > I view /efi/boot/* as boot blocks, for these purposes, bit /efi/freebsd > as > > fair game to update. So there is some nuance here we need to take into > > account and avoid absolutes about the BSP. > > Hmm, I guess we considered it a bad idea to store all the support scripts > (not loader.conf, but all the 4th/lua) on the esp beside the loader? That > would make the ESP bits be a self-contained, consistent snapshot. > loader.efi > could perhaps prefer to find those files on the partition it was loaded > from > (you know that IIRC since when you are executed as an EFI app you get a > pointer to your Image and it has a backpointer to the device you came from > I thought) before looking for them on the root filesystem? This would let > it still work when boot1.efi lives on the ESP instead, and also in the case > that you just copied loader.efi into the ESP without the support scripts. > Yea, now we're far into the weeds of dynamic design, and I'm not sure this is a good idea at all. Every time we've tried to pivot with a "just do X" it's burned us on this stuff. I hate the idea of just adding one ore layer of complexity as well, though to be honest, there may be some need to have some standardized fallback for the horrific UEFI implementations that are out there which are deficient in a number of ways that would lead us to needing some not uefi variable fallack mechanism. I'd hate to design that and then have another wart looking for this stuff, as well as users needing to do weird stuff to read in loader.conf and modifying it (more POLA violation if we move it to the ESP, for example). I've not had a chance to connect all the dots, but the few I've tried strong suggest this idea may not hunt. Let's step back and do a complete design doc. I've started writing one up and will post it when I'm done. Warner From owner-freebsd-hackers@freebsd.org Mon Mar 25 21:02:01 2019 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 7D457154DEE9; Mon, 25 Mar 2019 21:02:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C9C4878AE; Mon, 25 Mar 2019 21:02:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 2F74C25C8; Mon, 25 Mar 2019 21:02:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Mon, 25 Mar 2019 14:01:59 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 1C9C4878AE X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.965,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Mon, 25 Mar 2019 21:02:01 -0000 On 3/25/19 1:41 PM, Warner Losh wrote: > On Mon, Mar 25, 2019 at 2:30 PM John Baldwin wrote: > >> On 3/25/19 12:27 PM, Warner Losh wrote: >>> On Mon, Mar 25, 2019, 12:34 PM John Baldwin wrote: >>> >>>> On 3/25/19 8:05 AM, Warner Losh wrote: >>>>> We started installing /boot/loader with install world in FreeBSD -3.x >> and >>>>> it has affected the boot ability that whole time... in the early days >> of >>>>> loader, the kernel loader handoff protocol was immature enough to need >> a >>>>> matched kernel. But that period lasted only a few months... loader has >>>>> also been weird in other ways as well, since some embedded systems used >>>> the >>>>> one in its, while others needed an extra step. As UEFI support has >>>> matured >>>>> we're finding there are several issues around it as well where updating >>>> the >>>>> ESP needs to be tied to updating /boot for the system to work >> sometimes. >>>> It >>>>> has grown more complex over time, so we should separate. It's been a >>>> little >>>>> weird on all the non x86 platforms to different degrees, but now that >> our >>>>> main platform is affected it's become clear we may need to change. >>>>> >>>>> But we need to do so carefully as this violates POLA in a huge way, as >>>> well >>>>> as needing doc changes in a bajillion places. >>>> >>>> I think we should treat files on the ESP the same way we treat other >> boot >>>> blocks. installworld should continue to install the latest version into >>>> /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some >> other >>>> tool is used by the user to copy the updated loader.efi into the ESP. >>>> >>>> I think the main difference here is that traditionally other boot blocks >>>> didn't change very often, so no one really needed to update it them >>>> post-install. loader.efi changes often enough we probably need to >> document >>>> updating the ESP as an optional step in the upgrade process. I think >>>> having an automagical script will probably go sideways, but >> standardizing >>>> where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) >> means >>>> we can provide a script with defaults (or instructions) that work with >>>> the standardized approach. >>>> >>> >>> I think we need to have some automation in place. Something very specific >>> and concrete. Otherwise we run the risk of updating the support files >>> without updating loader.efi, possibly breaking boot if we wanted to add a >>> new API to lua that the startup scripts call. Without an update of >>> loader.efi, this generates an error. >>> >>> I view /efi/boot/* as boot blocks, for these purposes, bit /efi/freebsd >> as >>> fair game to update. So there is some nuance here we need to take into >>> account and avoid absolutes about the BSP. >> >> Hmm, I guess we considered it a bad idea to store all the support scripts >> (not loader.conf, but all the 4th/lua) on the esp beside the loader? That >> would make the ESP bits be a self-contained, consistent snapshot. >> loader.efi >> could perhaps prefer to find those files on the partition it was loaded >> from >> (you know that IIRC since when you are executed as an EFI app you get a >> pointer to your Image and it has a backpointer to the device you came from >> I thought) before looking for them on the root filesystem? This would let >> it still work when boot1.efi lives on the ESP instead, and also in the case >> that you just copied loader.efi into the ESP without the support scripts. >> > > Yea, now we're far into the weeds of dynamic design, and I'm not sure this > is a good idea at all. Every time we've tried to pivot with a "just do X" > it's burned us on this stuff. I hate the idea of just adding one ore layer > of complexity as well, though to be honest, there may be some need to have > some standardized fallback for the horrific UEFI implementations that are > out there which are deficient in a number of ways that would lead us to > needing some not uefi variable fallack mechanism. I'd hate to design that > and then have another wart looking for this stuff, as well as users needing > to do weird stuff to read in loader.conf and modifying it (more POLA > violation if we move it to the ESP, for example). I've not had a chance to > connect all the dots, but the few I've tried strong suggest this idea may > not hunt. > > Let's step back and do a complete design doc. I've started writing one up > and will post it when I'm done. I think a design doc makes sense. FWIW, I was only suggesting that the support scripts and perhaps /boot/defaults be on the ESP, but the actual loader.conf would still only be read from the rootfs. Right now loader has two special variables: currdev and rootdev. You could imagine a 'bootdev' and that for certain path lookups we try bootdev before currdev, but still fall back to currdev if the open on bootdev fails. But I think it's worth stepping back and walking through the design. My point about installworld is that today it is pretty straight forward what it means in terms of just installing files into / and that works fine for cross-release installs via DESTDIR, etc. Updating the ESP seems to be a bit more fraught with peril such that I'm not really sure I want installworld to try to do that vs having a separate step. The thought about having the "support scripts" live on the ESP is an orthogonal point about trying to have the loader be self-contained when it lives on the ESP. In this case I think of self-contained as being "what are the things equivalent to shared libraries that it needs to run", but not user-editable config files like loader.conf. -- John Baldwin From owner-freebsd-hackers@freebsd.org Tue Mar 26 00:40:55 2019 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 5E3DD15526C0; Tue, 26 Mar 2019 00:40:55 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED4108E51E; Tue, 26 Mar 2019 00:40:54 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id E2320C1909; Mon, 25 Mar 2019 18:41:49 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id u_ayBvyt48qT; Mon, 25 Mar 2019 18:41:49 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Mon, 25 Mar 2019 18:41:49 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh , John Baldwin Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , "Rodney W. Grimes" , FreeBSD Hackers References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> From: Rebecca Cran Message-ID: Date: Mon, 25 Mar 2019 18:40:46 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: ED4108E51E X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.95)[-0.948,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Tue, 26 Mar 2019 00:40:55 -0000 On 3/25/19 2:41 PM, Warner Losh wrote: > > Let's step back and do a complete design doc. I've started writing one up > and will post it when I'm done. It's probably worth at least taking a look at what Linux has done to support UEFI, Secure Boot, and its Default Boot Behavior (https://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/) to see if there's anything we can learn, or leverage. Also, the shim (https://github.com/rhboot/shim) is BSD licensed, so we could use it if we wanted. -- Rebecca Cran From owner-freebsd-hackers@freebsd.org Tue Mar 26 02:08:14 2019 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 386BB1557FE0 for ; Tue, 26 Mar 2019 02:08:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAA8E6C377 for ; Tue, 26 Mar 2019 02:08:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x841.google.com with SMTP id k2so12879217qtm.1 for ; Mon, 25 Mar 2019 19:08:13 -0700 (PDT) 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=ZnlBkrnu7i/35TUdewrxFDbP3xlajBNaP8swvQIpO0E=; b=qYcig7+12MxIMCGSYnRiYVW0vQyikfIZNGzzDKGxzn99WunkxIZvTSpQbczq/GcwyH K0eHIIVmWAtsRrWTIb+1v+wxzgoTg/b3/WuPlTmc05bffLdbseguAUM8Wbkq57BzlCRP Of8MQamvQ8Lb2VvnGO2tKtlAaScXFjdWG4l8/E/fnBTZifzDjbdUkVZR3k4PbonIQY8Z EvIwpnva4eUFN4uDA+3pns4qYQw8M1l97kdM2mcj3jEI5DTCDMrXRqLOlAf9y5louoiF Mn4CqkuTOY3uzFItmKztSrO9V0ofEkQqAQv47gtq1i3moH+9axBjqLqqRBZPUb43/MYz 4/5A== 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=ZnlBkrnu7i/35TUdewrxFDbP3xlajBNaP8swvQIpO0E=; b=Xq/pUTH/gXoGXM6NrSxnfmXmzp1MfwT3LBTiNQhOrqz2vRBKXg7dRGZ5bXMTTkzq/6 4BY1dMdVNU/TxtEpVCuBNz69SajWZxTQ2XtE84JQuXh7Xye5H2Y+wMp0jskCViVCmryz KOgYcYEUT8b7uQDJMV+cgkRqFJAYfaCf5PcDwpuAFOfe+yzxVn99rVlNg1m6q0Ptqlvj Y+rrotGtQXa781AHCzgEbI8w54v7/CMnSk3+DvURHR8mirgBtE4A2hzaTNyjJzifImjK rcRdIwTm8B3V+EUA6XrKXY6qAgPPSbWWoaWNeMehV/429o4VF0wDOEx2utRmG6FR1xjo O6XA== X-Gm-Message-State: APjAAAXXyUHkO8wyIdFQ1+rq0Tw+rnAT5/Q2iv35TL25sJjphhinM57p SXKp5PYGoivIiW5yXP9py7+oHqpsdk189JWj19A/nA== X-Google-Smtp-Source: APXvYqyVEaSk++sDoCSkhPCKOxxRrOp+SCmm8Kv1ru3m3j14kJQesDmrzkFHL4JK+HlyRB0od1mFH07SKZHRN76nUU8= X-Received: by 2002:ac8:28d0:: with SMTP id j16mr23881750qtj.15.1553566093181; Mon, 25 Mar 2019 19:08:13 -0700 (PDT) MIME-Version: 1.0 References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Mon, 25 Mar 2019 20:08:01 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Rebecca Cran Cc: John Baldwin , Konstantin Belousov , "freebsd-arch@freebsd.org" , "Rodney W. Grimes" , FreeBSD Hackers X-Rspamd-Queue-Id: CAA8E6C377 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.963,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Tue, 26 Mar 2019 02:08:14 -0000 On Mon, Mar 25, 2019, 6:40 PM Rebecca Cran wrote: > On 3/25/19 2:41 PM, Warner Losh wrote: > > > > > Let's step back and do a complete design doc. I've started writing one up > > and will post it when I'm done. > > > It's probably worth at least taking a look at what Linux has done to > support UEFI, Secure Boot, and its Default Boot Behavior > (https://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/) > > to see if there's anything we can learn, or leverage. Also, the shim > (https://github.com/rhboot/shim) is BSD licensed, so we could use it if > we wanted. > We started moving away from boot1.efi because it was duplicating all the features of loader.efi, but without the interactive features. Different filesystems, crypto, boot order details, etc. It was a pita to maintain two similar things with different enough details :( this starts to move back to that, and I'm not sure that is a good idea. It seemed like the right choice, but maybe we could consider taking another look at that... when it first arrived, boot1.efi could easily fit the install once and forget forever. As the features grew, that assumption changed. This is why I'm putting together a design doc. There is no easy button here. I thought it was no brainer yes to drop it and just use loader.efi, but as things get more complicated I've become less sure... Warner > -- > > Rebecca Cran > > From owner-freebsd-hackers@freebsd.org Tue Mar 26 02:34:25 2019 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 E59D9155B662 for ; Tue, 26 Mar 2019 02:34:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-it1-x144.google.com (mail-it1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 129976EA0D for ; Tue, 26 Mar 2019 02:34:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-it1-x144.google.com with SMTP id h9so17476094itl.1 for ; Mon, 25 Mar 2019 19:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=eCs2d0/NWeiAiEOaiKn0FntyxLRIuNlPvVPrBWn6yMg=; b=ns9fSxQwK5w8oIxlS4XWMsmprD0p3Rrd737oNmYSzQJ+//NUZYbzUf73YlpVJVgmE7 v+Rsd9cTjmG+AWuNyet+qpzHUCSaUupW/Af+PGdglUvaCDWMoL/cQEZsz+dhu16bgiL/ DH6fBx5xQVLQnsGwWMbml8buuSQH7QN3OcWsLOZ9xJboibDLhRXEKA+F1or+JCvuzuQ4 NUC7O7FBD4g1Y1QECr4J3nsnU91G6q0ougaDlwTGBpbp7sxMyRChF+j65hzp2l4x/epL RZhG4q25V/8VpapDZg/VDxyoK4PZS6gzCgQor6vOWNHn7YxF2WOiCAgrXRCucvHTGFSp 0XBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=eCs2d0/NWeiAiEOaiKn0FntyxLRIuNlPvVPrBWn6yMg=; b=spoQzQ5StB3dANybNaXevWfnXxRiNEUU5xKHIrZi55Aof9D8cX0vPTspaGQxpPCD0L 8bS3mNYyzsvt4BnRsXNBC45hhmpBV7LBP+AXOAqhKohAzCMreaP/JBwOJL7vNmPtbrOq IqkaBtHYQbHsmYpLIHH0G6x8EouTYteKV+ujnP0Ool6fL4EIrgh+zTyRRZkaR8hWSvrY zq9hQ0Egw/2tUqcWMW43W9EyU9/oZ7Ulh8Lpt6jkgUlTRuDdfMm4Yi3G6S3oZS/sabZ3 fhJsgvY0ES7/IEfguxnu3EEJck/+mSFTPWfLx7FvBoxItMb209F/2fw6uCuHivkjRDCC WhMQ== X-Gm-Message-State: APjAAAW92EI2zG00g5ZuO8k4G2tvgKtVutpLHH4mIoCcFVQyIZuepRX7 BpFvWLmy2oVqa9llNL8WZ7s= X-Google-Smtp-Source: APXvYqxw5yHLOEnb8cXnejTW+tZMjxrrW/glPVfFOStiu4eDK7w41GFVuVvmWgfMMDZhrPvHvhDkgw== X-Received: by 2002:a24:f802:: with SMTP id a2mr1772870ith.24.1553567663245; Mon, 25 Mar 2019 19:34:23 -0700 (PDT) Received: from raichu (toroon0560w-lp140-01-69-159-36-102.dsl.bell.ca. [69.159.36.102]) by smtp.gmail.com with ESMTPSA id o9sm6552986itb.23.2019.03.25.19.34.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Mar 2019 19:34:22 -0700 (PDT) Sender: Mark Johnston Date: Mon, 25 Mar 2019 22:34:19 -0400 From: Mark Johnston To: Poul-Henning Kamp Cc: Warner Losh , FreeBSD Hackers , Alfonso Siciliano Subject: Re: kern_sysctl.c interface Message-ID: <20190326023419.GB62914@raichu> References: <20190313013530.d96fc84c362bb489178357eb@gmail.com> <78358.1552464694@critter.freebsd.dk> <885.1552506820@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <885.1552506820@critter.freebsd.dk> User-Agent: Mutt/1.11.3 (2019-02-01) X-Rspamd-Queue-Id: 129976EA0D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=ns9fSxQw; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::144 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-3.06 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.69)[-0.686,0]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; 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]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.1.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]; IP_SCORE(-0.67)[ip: (1.76), ipnet: 2607:f8b0::/32(-2.87), asn: 15169(-2.15), country: US(-0.07)]; MID_RHS_NOT_FQDN(0.50)[] 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: Tue, 26 Mar 2019 02:34:25 -0000 On Wed, Mar 13, 2019 at 07:53:40PM +0000, Poul-Henning Kamp wrote: > -------- > In message > , Warner Losh writes: > > >> > * This interface is under work and consideration, and should probably > >> > * be killed with a big axe by the first person who can find the time. > >> > * (be aware though, that the proper interface isn't as obvious as it > >> > * may seem, there are various conflicting requirements. > >> > >> I think that is a comment I added more than 20 years ago because we, > >> or at least I, wondered if the sysctl-OID tree should be moved to > >> something SNMP-OID compatible. > >> > >> I dont know of anything happening after that. > > > >I suspect after 20ish years the comment can be removed, eh? > > Well, it's still a butt-ugly and inefficient interface... I don't know that it'd help much with efficiency, but lately I've wanted an fd-based interface for sysctl so as to be able to use Capsicum to restrict the sysctl namespace. The idea is that a sysctlfd would reference a node in the sysctl hierarchy, and it would be possible to read or write a descendent node using the relative sysctlfd, like the *at() system calls. Only sysctls reachable from an open sysctlfd could be accessed while in capability mode. Today, we have a situation where sysctls are either statically flagged as CTLFLAG_CAPRD and thus are readable in capability mode, or you have to talk to another process over a unix socket and have it access the sysctl on your behalf. I'm not sure what an ideal syscall interface for this would look like. I think you could probably implement the idea using the existing __sysctl() syscall, by having a magic OID that writes an fd to the out buffer. Ideally you'd be able to use relative names to refer to sysctl, so that if you had an fd for dev.cpu, you could read CPU 0's temperature with something like: sysctlat(cpufd, "0.temperature", oldp, &oldlen, NULL, 0); That could avoid resolving "dev.cpu" each time it's read, so it'd be more efficient than what we do today. A real interface has to handle iteration and name resolution (hopefully avoiding an extra syscall just for resolution). It also needs to handle sysctl nodes that are addressed by OID, like kern.proc.pid.. From owner-freebsd-hackers@freebsd.org Tue Mar 26 03:45:04 2019 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 9BE0E155FA11; Tue, 26 Mar 2019 03:45:04 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B220722BA; Tue, 26 Mar 2019 03:45:03 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2Q3ipRQ082842; Mon, 25 Mar 2019 20:44:51 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2Q3iolq082841; Mon, 25 Mar 2019 20:44:50 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903260344.x2Q3iolq082841@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: To: Warner Losh Date: Mon, 25 Mar 2019 20:44:50 -0700 (PDT) CC: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 0B220722BA X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.978,0] 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: Tue, 26 Mar 2019 03:45:04 -0000 > On Mon, Mar 25, 2019, 3:28 AM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > On Sat, Mar 23, 2019 at 08:21:43PM -0600, Rebecca Cran via > > freebsd-hackers wrote: > > > > I've been working on EFI support, and have a review > > > > (https://reviews.freebsd.org/D19588) to add a script, > > efi-update-loader, > > > > which will update the ESP containing the FreeBSD boot1.efi or > > loader.efi. > > > > > > > > I'd like to integrate it into the build system so it gets run when > > users > > > > do a "make installworld", but I'm lost looking through Makefile.inc1 - > > I > > > > have no clue where to add the code. > > > > > > > > Does anyone understand where and what to add? > > > > > > Can we take use of the opportunity and finally stop installing loader > > > at installworld target at all, please ? > > > > > > Add e.g. installloader target which would do whatever needed to loader. > > > > +1 boot code and loaders should always be seperated from the > > install target. Historically this was casued by the fact that > > the boot code and loader lived outside the file system and > > required operations beyond updating /usr/mdec (very ancient) > > or /boot/boot* (historical). Now that /boot/loader* is an > > immeditate effect on the bootability of the system it makes > > since to seperate this from the installworld target. > > > > We started installing /boot/loader with install world in FreeBSD -3.x and > it has affected the boot ability that whole time... in the early days of > loader, the kernel loader handoff protocol was immature enough to need a > matched kernel. But that period lasted only a few months... loader has > also been weird in other ways as well, since some embedded systems used the > one in its, while others needed an extra step. As UEFI support has matured > we're finding there are several issues around it as well where updating the > ESP needs to be tied to updating /boot for the system to work sometimes. It > has grown more complex over time, so we should separate. It's been a little > weird on all the non x86 platforms to different degrees, but now that our > main platform is affected it's become clear we may need to change. > > But we need to do so carefully as this violates POLA in a huge way, as well > as needing doc changes in a bajillion places. So it appears we agree, we sould do this, and we need to wear Nomex clothing while doing so as it is an easy place to get burned badly if we do not end up with a good set of tooling, or make mistakes along the way. > Warner > > Rod Grimes -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Tue Mar 26 03:48:21 2019 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 BF00B155FC89 for ; Tue, 26 Mar 2019 03:48:21 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C38F7258E for ; Tue, 26 Mar 2019 03:48:17 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2Q3mFed082867; Mon, 25 Mar 2019 20:48:15 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2Q3mFEg082866; Mon, 25 Mar 2019 20:48:15 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903260348.x2Q3mFEg082866@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> To: John Baldwin Date: Mon, 25 Mar 2019 20:48:15 -0700 (PDT) CC: Warner Losh , "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 2C38F7258E X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.976,0] 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: Tue, 26 Mar 2019 03:48:21 -0000 > On 3/25/19 8:05 AM, Warner Losh wrote: > > We started installing /boot/loader with install world in FreeBSD -3.x and > > it has affected the boot ability that whole time... in the early days of > > loader, the kernel loader handoff protocol was immature enough to need a > > matched kernel. But that period lasted only a few months... loader has > > also been weird in other ways as well, since some embedded systems used the > > one in its, while others needed an extra step. As UEFI support has matured > > we're finding there are several issues around it as well where updating the > > ESP needs to be tied to updating /boot for the system to work sometimes. It > > has grown more complex over time, so we should separate. It's been a little > > weird on all the non x86 platforms to different degrees, but now that our > > main platform is affected it's become clear we may need to change. > > > > But we need to do so carefully as this violates POLA in a huge way, as well > > as needing doc changes in a bajillion places. > > I think we should treat files on the ESP the same way we treat other boot > blocks. installworld should continue to install the latest version into > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some other > tool is used by the user to copy the updated loader.efi into the ESP. > > I think the main difference here is that traditionally other boot blocks > didn't change very often, so no one really needed to update it them > post-install. loader.efi changes often enough we probably need to document > updating the ESP as an optional step in the upgrade process. I think > having an automagical script will probably go sideways, but standardizing > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) means > we can provide a script with defaults (or instructions) that work with > the standardized approach. Is there anyway to stash an easy to extract "version" in loader.* so that a Makefile/.sh script could easily check to see that your boot code is == `uname -KU` and just emit a warning at the end of installworld? > John Baldwin -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Tue Mar 26 04:08:44 2019 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 6637C1560979; Tue, 26 Mar 2019 04:08:44 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01F1F732B2; Tue, 26 Mar 2019 04:08:43 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 13AC9C1ABD; Mon, 25 Mar 2019 22:09:44 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YkMn-4QDMSM8; Mon, 25 Mar 2019 22:09:43 -0600 (MDT) Received: from [10.0.10.197] (unknown [65.103.231.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Mon, 25 Mar 2019 22:09:43 -0600 (MDT) Date: Mon, 25 Mar 2019 22:03:46 -0600 From: rebecca@bluestop.org To: John Baldwin , "Rodney W. Grimes" Cc: FreeBSD Hackers , "=?utf-8?Q?freebsd-arch=40freebsd.org?=" , Konstantin Belousov Message-ID: <3abca0c1-3681-43a5-af21-5a89c8764d0c@Spark> In-Reply-To: <201903260348.x2Q3mFEg082866@gndrsh.dnsmgr.net> References: <201903260348.x2Q3mFEg082866@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" X-Readdle-Message-ID: 3abca0c1-3681-43a5-af21-5a89c8764d0c@Spark MIME-Version: 1.0 X-Rspamd-Queue-Id: 01F1F732B2 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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: Tue, 26 Mar 2019 04:08:44 -0000 On Mar 25, 2019, 9:49 PM -0600, Rodney W. Grimes , wrote: > > Is there anyway to stash an easy to extract =22version=22 in > loader.* so that a Makefile/.sh script could easily check > to see that your boot code is =3D=3D =60uname -KU=60 and just emit > a warning at the end of installworld=3F Currently, one of the strings that are embedded in loader*.efi reports th= e loader version 1.1. Though we might want to have something like Linux=E2= =80=99 boot.csv with a version in that file. Rebecca From owner-freebsd-hackers@freebsd.org Tue Mar 26 04:58:06 2019 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 75D9D1562A7A for ; Tue, 26 Mar 2019 04:58:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15BBF756DB for ; Tue, 26 Mar 2019 04:58:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x835.google.com with SMTP id t28so13142662qte.6 for ; Mon, 25 Mar 2019 21:58:06 -0700 (PDT) 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=a67+bSvzKlmkEKTaFgxjooU1ufiuKiUj9IubDgqW8zM=; b=W4sApfGa/Go/PRLdi0Q3E1T4cUD6SVkdM0riskSO1XVWDMlw4z1f8wIpUAj0VgtxPq NiHLhXad3HuZn0vDYwwYiLN75+Uiwfysh65GbSNHvbXJCk3z9WQZEOdv4D6NzimVrFbq aLNLPxBbuWAUhbwqnx49dwG8G5ysNlFicw3BKoebBFNVm5J22i9HQD8D8awyYMCE2Fd1 0lFx6iTclIzd2PIx20zZkUq/q/wFwbd5GhmWkCWkHsMz+pNjov44VHbw/F7mfVBTk2my Nn8L+TGkNVfc56NEvrRWh3dZ3vthDrTMb1nVmpVpXSJYQa+vPXyD4LpNnIIpzl6cQtAf gb+w== 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=a67+bSvzKlmkEKTaFgxjooU1ufiuKiUj9IubDgqW8zM=; b=WWGpDO5nNYFP9PeDggtqTR7E6Cuy84MN5IHsKJSQtW+wZR2jbKMwjLPvnQn5lUDcWh MgGmLpRBv5J7n0pxAxzWaF+kpsFgiZMrYvPZAXZ6NLwxFKjaBaVz9LqtPCSVxm/HpVtA ZfNXJR6lHzuZKSwnR+jvmnf+IlgDfxC0Wr4JWRQqrW9z6QhDO8Q4vAI9y6OHztiCEM/U 1bS986OGaSTq1vSNEA2QPPBzG9Znvvp8YY8akxSjpHCWE7HL3jzZT5z7l+VKL0FI87Ly WkSK/MEY72TdGmuzIibc1fTL6aq4q1GSTeH6Y4cWQpdZ4mbo2Ldlf1eTfNSw01OCnGdD 9rhw== X-Gm-Message-State: APjAAAWpJzQsZK4vW13E9CJT+Pkp+YqTtDHW0NA6pAB0DU+0kdICVtbv RM95QDg8mlG3b8ZXdb7p2gpxYpBeJ3CQWwXSj+GO4A== X-Google-Smtp-Source: APXvYqzl2kwbYxTQ7T8G+O0F7RSD622lpyiZn1k6YYrQ/GTeCpMNikbqKqQBa7NWJx1at5sTD8iiXyS6suy7ZSrWyMU= X-Received: by 2002:a0c:b501:: with SMTP id d1mr24240075qve.115.1553576285641; Mon, 25 Mar 2019 21:58:05 -0700 (PDT) MIME-Version: 1.0 References: <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> <201903260348.x2Q3mFEg082866@gndrsh.dnsmgr.net> In-Reply-To: <201903260348.x2Q3mFEg082866@gndrsh.dnsmgr.net> From: Warner Losh Date: Mon, 25 Mar 2019 22:57:53 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" Cc: John Baldwin , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran X-Rspamd-Queue-Id: 15BBF756DB X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Tue, 26 Mar 2019 04:58:06 -0000 On Mon, Mar 25, 2019, 9:48 PM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > On 3/25/19 8:05 AM, Warner Losh wrote: > > > We started installing /boot/loader with install world in FreeBSD -3.x > and > > > it has affected the boot ability that whole time... in the early days > of > > > loader, the kernel loader handoff protocol was immature enough to need > a > > > matched kernel. But that period lasted only a few months... loader has > > > also been weird in other ways as well, since some embedded systems > used the > > > one in its, while others needed an extra step. As UEFI support has > matured > > > we're finding there are several issues around it as well where > updating the > > > ESP needs to be tied to updating /boot for the system to work > sometimes. It > > > has grown more complex over time, so we should separate. It's been a > little > > > weird on all the non x86 platforms to different degrees, but now that > our > > > main platform is affected it's become clear we may need to change. > > > > > > But we need to do so carefully as this violates POLA in a huge way, as > well > > > as needing doc changes in a bajillion places. > > > > I think we should treat files on the ESP the same way we treat other boot > > blocks. installworld should continue to install the latest version into > > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some other > > tool is used by the user to copy the updated loader.efi into the ESP. > > > > I think the main difference here is that traditionally other boot blocks > > didn't change very often, so no one really needed to update it them > > post-install. loader.efi changes often enough we probably need to > document > > updating the ESP as an optional step in the upgrade process. I think > > having an automagical script will probably go sideways, but standardizing > > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) means > > we can provide a script with defaults (or instructions) that work with > > the standardized approach. > > Is there anyway to stash an easy to extract "version" in > loader.* so that a Makefile/.sh script could easily check > to see that your boot code is == `uname -KU` and just emit > a warning at the end of installworld? > No. There is no simple version we can check to make sure things are a matched set.. Warner > John Baldwin > -- > Rod Grimes > rgrimes@freebsd.org > From owner-freebsd-hackers@freebsd.org Tue Mar 26 05:03:42 2019 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 95D181562FA0; Tue, 26 Mar 2019 05:03:42 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C01475CC0; Tue, 26 Mar 2019 05:03:41 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2Q53Y3k083257; Mon, 25 Mar 2019 22:03:34 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2Q53Ydo083256; Mon, 25 Mar 2019 22:03:34 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903260503.x2Q53Ydo083256@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: To: Warner Losh Date: Mon, 25 Mar 2019 22:03:34 -0700 (PDT) CC: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , Rebecca Cran , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 0C01475CC0 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Tue, 26 Mar 2019 05:03:42 -0000 > On Mon, Mar 25, 2019, 9:48 PM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > On 3/25/19 8:05 AM, Warner Losh wrote: > > > > We started installing /boot/loader with install world in FreeBSD -3.x > > and > > > > it has affected the boot ability that whole time... in the early days > > of > > > > loader, the kernel loader handoff protocol was immature enough to need > > a > > > > matched kernel. But that period lasted only a few months... loader has > > > > also been weird in other ways as well, since some embedded systems > > used the > > > > one in its, while others needed an extra step. As UEFI support has > > matured > > > > we're finding there are several issues around it as well where > > updating the > > > > ESP needs to be tied to updating /boot for the system to work > > sometimes. It > > > > has grown more complex over time, so we should separate. It's been a > > little > > > > weird on all the non x86 platforms to different degrees, but now that > > our > > > > main platform is affected it's become clear we may need to change. > > > > > > > > But we need to do so carefully as this violates POLA in a huge way, as > > well > > > > as needing doc changes in a bajillion places. > > > > > > I think we should treat files on the ESP the same way we treat other boot > > > blocks. installworld should continue to install the latest version into > > > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some other > > > tool is used by the user to copy the updated loader.efi into the ESP. > > > > > > I think the main difference here is that traditionally other boot blocks > > > didn't change very often, so no one really needed to update it them > > > post-install. loader.efi changes often enough we probably need to > > document > > > updating the ESP as an optional step in the upgrade process. I think > > > having an automagical script will probably go sideways, but standardizing > > > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) means > > > we can provide a script with defaults (or instructions) that work with > > > the standardized approach. > > > > Is there anyway to stash an easy to extract "version" in > > loader.* so that a Makefile/.sh script could easily check > > to see that your boot code is == `uname -KU` and just emit > > a warning at the end of installworld? > > > > No. There is no simple version we can check to make sure things are a > matched set.. Then I would call that a pretty fatal flaw in design. There needs to be a way to find out what version of "loader" /boot/loader.efi is there. I was also not asking if we have a way now, I was asking if there was a way to implement, and I doubt the answer to that question is no. > Warner > > John Baldwin > > Rod Grimes rgrimes@freebsd.org 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 Why does your mail client wrap my <70 column signature? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Tue Mar 26 05:22:16 2019 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 6DF1815637DC for ; Tue, 26 Mar 2019 05:22:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A5D376782 for ; Tue, 26 Mar 2019 05:22:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x830.google.com with SMTP id k2so13218865qtm.1 for ; Mon, 25 Mar 2019 22:22:16 -0700 (PDT) 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=X6ZvhkB9+6S+YCbihFHP420W7UtaeGi612fLw1q7tR0=; b=IPHpogiLpTYksb8JDQALhLstJ5DvUpywNAQr3oiIxGenvlm+xCOLrGo2pOEfH3j8Ce 5I3DWZ719yPUVSuyD8oZG73FxYLJ8YLdBhKnu8+0iXQW69Eui6qGoTmBLfBtbIJjLQwg BcFN44sZhtqwwShtiD8yPdO90puwWzEXES9W4ov52//EsPhCL3Cgmrf++ANFOnEjWOt6 GLxzFMEjl45qci2YYNVZq7brzr1btDWo0ZuVXGkA6wGknDjkNd+y5A9HV1TZoV1ws2Dm T4cwjMUUWY7aMZrIY0oYqxQdGrDN9ROENMc6SI/QVwQATIg1nsdGJCwgfTOGoFeFgecz yULw== 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=X6ZvhkB9+6S+YCbihFHP420W7UtaeGi612fLw1q7tR0=; b=Q+hjt0pnQVyMvVKOX88Ip/EaxOBHk6SyqmHxtjeFX7VMw/1NM4KSkQfqWg2IxWwLfj yy+ghxNCYvV4T3cHhxMVRHqQkv6cFsvLfyVoRW6UxM8vpeV/wb8OZfiv7Uu3wuq2g0nE 6oz7iwZz0zBbmEv39XQsNbDPGTLsoGjj1tdf64SFz+ewn4MIi6f+3Y7hQe0UTmPgwaMm J1CODXHrIVgVBtDub9vM77d3XB72j1BVuxO0V+9r/KbiEThfv92ze/wMbYRxG9adcPCc vTrXfh1QP5xvKpi0vv78t4JItM8hlQxvrOsSxtMwoNbPYakeYfKiis98FFxcLcwh/Iuh qPAw== X-Gm-Message-State: APjAAAVUJpDUhCe8juJ4FqtJrburDJvGKNEEMBqbyOxCcjKqZ0bPaZTt NiSURORsAkhUFpYr4TSIYdk3tIGEM+WlMyYaGyV2yA== X-Google-Smtp-Source: APXvYqwd/33WqVXC3c/4hwUUnHuZZP+g4pEcbdAc8zGnzTp6dluOViAdJ4PkD/2Y865M91b1KD3i0Xjty8b0Fjkt6XM= X-Received: by 2002:a0c:9ba7:: with SMTP id o39mr23057951qve.153.1553577735560; Mon, 25 Mar 2019 22:22:15 -0700 (PDT) MIME-Version: 1.0 References: <201903260503.x2Q53Ydo083256@gndrsh.dnsmgr.net> In-Reply-To: <201903260503.x2Q53Ydo083256@gndrsh.dnsmgr.net> From: Warner Losh Date: Mon, 25 Mar 2019 23:22:03 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , Rebecca Cran , FreeBSD Hackers X-Rspamd-Queue-Id: 0A5D376782 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.966,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Tue, 26 Mar 2019 05:22:16 -0000 On Mon, Mar 25, 2019, 11:03 PM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > On Mon, Mar 25, 2019, 9:48 PM Rodney W. Grimes < > > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > > > On 3/25/19 8:05 AM, Warner Losh wrote: > > > > > We started installing /boot/loader with install world in FreeBSD > -3.x > > > and > > > > > it has affected the boot ability that whole time... in the early > days > > > of > > > > > loader, the kernel loader handoff protocol was immature enough to > need > > > a > > > > > matched kernel. But that period lasted only a few months... > loader has > > > > > also been weird in other ways as well, since some embedded systems > > > used the > > > > > one in its, while others needed an extra step. As UEFI support has > > > matured > > > > > we're finding there are several issues around it as well where > > > updating the > > > > > ESP needs to be tied to updating /boot for the system to work > > > sometimes. It > > > > > has grown more complex over time, so we should separate. It's been > a > > > little > > > > > weird on all the non x86 platforms to different degrees, but now > that > > > our > > > > > main platform is affected it's become clear we may need to change. > > > > > > > > > > But we need to do so carefully as this violates POLA in a huge > way, as > > > well > > > > > as needing doc changes in a bajillion places. > > > > > > > > I think we should treat files on the ESP the same way we treat other > boot > > > > blocks. installworld should continue to install the latest version > into > > > > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some > other > > > > tool is used by the user to copy the updated loader.efi into the ESP. > > > > > > > > I think the main difference here is that traditionally other boot > blocks > > > > didn't change very often, so no one really needed to update it them > > > > post-install. loader.efi changes often enough we probably need to > > > document > > > > updating the ESP as an optional step in the upgrade process. I think > > > > having an automagical script will probably go sideways, but > standardizing > > > > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) > means > > > > we can provide a script with defaults (or instructions) that work > with > > > > the standardized approach. > > > > > > Is there anyway to stash an easy to extract "version" in > > > loader.* so that a Makefile/.sh script could easily check > > > to see that your boot code is == `uname -KU` and just emit > > > a warning at the end of installworld? > > > > > > > No. There is no simple version we can check to make sure things are a > > matched set.. > > Then I would call that a pretty fatal flaw in design. There needs > to be a way to find out what version of "loader" /boot/loader.efi > is there. > > I was also not asking if we have a way now, I was asking if there > was a way to implement, and I doubt the answer to that question is > no. > I know. We've not needed it before, and I'm having trouble seeing it now how it is connected to uname -UK. The path forward isn't DWIM. There are too many variables. Without DWIM requirements, a tight, buttoned up version isn't needed. Warner > Warner > > > John Baldwin > > > Rod Grimes rgrimes@freebsd.org > > > 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 > Why does your mail client wrap my <70 column signature? > Ask Google. Warner > -- > Rod Grimes > rgrimes@freebsd.org > From owner-freebsd-hackers@freebsd.org Tue Mar 26 06:21:10 2019 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 1E57E1565791; Tue, 26 Mar 2019 06:21:10 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C86580748; Tue, 26 Mar 2019 06:21:09 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2Q6L4AS083616; Mon, 25 Mar 2019 23:21:04 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2Q6L4x7083615; Mon, 25 Mar 2019 23:21:04 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903260621.x2Q6L4x7083615@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: To: Warner Losh Date: Mon, 25 Mar 2019 23:21:04 -0700 (PDT) CC: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 5C86580748 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.967,0] 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: Tue, 26 Mar 2019 06:21:10 -0000 > On Mon, Mar 25, 2019, 11:03 PM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > On Mon, Mar 25, 2019, 9:48 PM Rodney W. Grimes < > > > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > > > > > On 3/25/19 8:05 AM, Warner Losh wrote: > > > > > > We started installing /boot/loader with install world in FreeBSD > > -3.x > > > > and > > > > > > it has affected the boot ability that whole time... in the early > > days > > > > of > > > > > > loader, the kernel loader handoff protocol was immature enough to > > need > > > > a > > > > > > matched kernel. But that period lasted only a few months... > > loader has > > > > > > also been weird in other ways as well, since some embedded systems > > > > used the > > > > > > one in its, while others needed an extra step. As UEFI support has > > > > matured > > > > > > we're finding there are several issues around it as well where > > > > updating the > > > > > > ESP needs to be tied to updating /boot for the system to work > > > > sometimes. It > > > > > > has grown more complex over time, so we should separate. It's been > > a > > > > little > > > > > > weird on all the non x86 platforms to different degrees, but now > > that > > > > our > > > > > > main platform is affected it's become clear we may need to change. > > > > > > > > > > > > But we need to do so carefully as this violates POLA in a huge > > way, as > > > > well > > > > > > as needing doc changes in a bajillion places. > > > > > > > > > > I think we should treat files on the ESP the same way we treat other > > boot > > > > > blocks. installworld should continue to install the latest version > > into > > > > > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some > > other > > > > > tool is used by the user to copy the updated loader.efi into the ESP. > > > > > > > > > > I think the main difference here is that traditionally other boot > > blocks > > > > > didn't change very often, so no one really needed to update it them > > > > > post-install. loader.efi changes often enough we probably need to > > > > document > > > > > updating the ESP as an optional step in the upgrade process. I think > > > > > having an automagical script will probably go sideways, but > > standardizing > > > > > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) > > means > > > > > we can provide a script with defaults (or instructions) that work > > with > > > > > the standardized approach. > > > > > > > > Is there anyway to stash an easy to extract "version" in > > > > loader.* so that a Makefile/.sh script could easily check > > > > to see that your boot code is == `uname -KU` and just emit > > > > a warning at the end of installworld? > > > > > > > > > > No. There is no simple version we can check to make sure things are a > > > matched set.. > > > > Then I would call that a pretty fatal flaw in design. There needs > > to be a way to find out what version of "loader" /boot/loader.efi > > is there. > > > > I was also not asking if we have a way now, I was asking if there > > was a way to implement, and I doubt the answer to that question is > > no. > > > > I know. We've not needed it before, and I'm having trouble seeing it now > how it is connected to uname -UK. The path forward isn't DWIM. There are > too many variables. Without DWIM requirements, a tight, buttoned up version > isn't needed. I attached it to uname -UK as from an operational standpoint the easy semi-unique or matching qualifier for compatibilty is exactly that token. I am not advocating we enforce a version match, but that it would certain of helped me several times in the past to know that my /boot/* files are from 1100122 1100122 and hence need to be updated. The current BTX 1.1 is bit rot, that value has not changed in ages and tells me nothing about what boot code I am running, why do we even output it? > Warner > > Warner > > > > John Baldwin > > > > Rod Grimes rgrimes@freebsd.org > > 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 > > Why does your mail client wrap my <70 column signature? > Ask Google. Your saying gmail is doing this when you reply? Interesting > Warner > > Rod Grimes > > rgrimes@freebsd.org -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Tue Mar 26 09:33:59 2019 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 6423F154881A; Tue, 26 Mar 2019 09:33:59 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB4D6876E6; Tue, 26 Mar 2019 09:33:58 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id A16F9C1D9C; Tue, 26 Mar 2019 03:34:58 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DtKf7IdZBypQ; Tue, 26 Mar 2019 03:34:58 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Tue, 26 Mar 2019 03:34:58 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" , Warner Losh Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers References: <201903260621.x2Q6L4x7083615@gndrsh.dnsmgr.net> From: Rebecca Cran Message-ID: <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> Date: Tue, 26 Mar 2019 03:33:56 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <201903260621.x2Q6L4x7083615@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: CB4D6876E6 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.958,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Tue, 26 Mar 2019 09:33:59 -0000 On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > The current BTX 1.1 is bit rot, that value has not changed in ages > and tells me nothing about what boot code I am running, why do we > even output it? Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, Revision 1.1" in "strings /boot/loader.efi" shows one way we could easily embed a useful version number. -- Rebecca Cran From owner-freebsd-hackers@freebsd.org Tue Mar 26 13:31:30 2019 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 8F867155269B for ; Tue, 26 Mar 2019 13:31:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F6416A9B0 for ; Tue, 26 Mar 2019 13:31:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x834.google.com with SMTP id k14so14541707qtb.0 for ; Tue, 26 Mar 2019 06:31:30 -0700 (PDT) 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=b/LwgLws8PXDoFdSqOpJx+xXQus+a3WnwBim54+BN0A=; b=IMtKQNVlfJgpyub1wxGBiJ+D7Ak0LzAo6Lxozb8S5Q/v8Oij9NawFm60kUE24t5h/j t58icdNtLhWzo8oTPyA2BO/bpmK4zw0LPGywwit4GkEWVa9NxBz8qENU3l1ztvqVT0eb o6H89cA4EpFf2YJs+TMOq60sJjFcKAJcwf0an94oM7YOC5NDLCKM600ElGWymZ5+91tK pN/8eu8XiVgFIRaCJgDevgvoFR5zGbWuerfrAoQcmKwZUD3H+f05JmOGHhD9kNicZoAK p5q3hUrZAmML6yF+iK0OfrCKrSn+yDZjOyGUgweapfhpaCNHg2yBn3cRdBjisp6Ovu38 Pkrg== 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=b/LwgLws8PXDoFdSqOpJx+xXQus+a3WnwBim54+BN0A=; b=MRlt276a+lrRqgvkmwAATYFzO9a4OX0MZjmcHiDNsZOcSRylTuggtuZ3Q9WQy3s4ia EnruZsxgtB7VeAG1HOHJHBguAd4G2wh7foTknWo1Hkh0PjQdLEcJfh15418QM2z9WYKx FO34zQxQjJxx2yZVJ3zDZOoqqdPojoiYfzsb0E+NMSRZxsBXKOzY3kiSS0QlHTpuw/BE 3zkE08h6gGQy9kQwfFBbULnRyFu7VsYbBwrDQ3+1s41c+NE1WTYdVmba5eRXucBHD5N6 NThq36d0IeUBuWEktCMNi/U6zxBcYuDSDeVMaFc6MUls1WKJUhKfkyZ2+D1N2xLT07jb P7NQ== X-Gm-Message-State: APjAAAVQ64xfjnFLuYKDUREZ/v5lk2ene/eLnyWfdR7wPpDNOoKYMg6B gV9gjeKtwAe8Vxu1dEBmWKmt5PYcnseGseLBgmgwzg== X-Google-Smtp-Source: APXvYqzPizmxhODmL2WChh050Pm/s8UPqzvemSsivlPWzFGqgkZ3FffSp8OgpF975aIhx7rQwwBSFYwgwQfESbe+N8U= X-Received: by 2002:ac8:4685:: with SMTP id g5mr18745190qto.242.1553607089347; Tue, 26 Mar 2019 06:31:29 -0700 (PDT) MIME-Version: 1.0 References: <201903260621.x2Q6L4x7083615@gndrsh.dnsmgr.net> <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> In-Reply-To: <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> From: Warner Losh Date: Tue, 26 Mar 2019 07:31:17 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Rebecca Cran Cc: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers X-Rspamd-Queue-Id: 0F6416A9B0 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Tue, 26 Mar 2019 13:31:30 -0000 On Tue, Mar 26, 2019, 3:33 AM Rebecca Cran wrote: > On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > > > > The current BTX 1.1 is bit rot, that value has not changed in ages > > and tells me nothing about what boot code I am running, why do we > > even output it? > > > Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, Revision > 1.1" in "strings /boot/loader.efi" shows one way we could easily embed a > useful version number. > It's the useful part that I objected to. We wanted to do it, but haven't for the last 20 years of trying. I doubt we'll do any better in the future, especially with the repeatable build stuff closing many doors of trying to automate it. Warner > From owner-freebsd-hackers@freebsd.org Wed Mar 27 08:47:31 2019 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 33A9315482FF; Wed, 27 Mar 2019 08:47:31 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A27206BCDB; Wed, 27 Mar 2019 08:47:30 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2R8lNtB088824; Wed, 27 Mar 2019 01:47:23 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2R8lMxc088823; Wed, 27 Mar 2019 01:47:22 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> To: Rebecca Cran Date: Wed, 27 Mar 2019 01:47:22 -0700 (PDT) CC: "Rodney W. Grimes" , Warner Losh , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: A27206BCDB X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Wed, 27 Mar 2019 08:47:31 -0000 > On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > > > > The current BTX 1.1 is bit rot, that value has not changed in ages > > and tells me nothing about what boot code I am running, why do we > > even output it? > > > Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, Revision > 1.1" in "strings /boot/loader.efi" shows one way we could easily embed a > useful version number. Please go implement the placing of the version that is used to cause uname -U to output 1200086 or whatever from /usr/sbin/uname at build time, which is not an issue at all as far as reproducabile builds as that version number is the same no mater how many times you run the build. This is the current defining value that says your kernel is compatible with userland and should also be the defining value for if your boot code is also compatible. Thanks, -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed Mar 27 14:20:22 2019 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 551CC15512A3; Wed, 27 Mar 2019 14:20:22 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E139576862; Wed, 27 Mar 2019 14:20:21 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 4F725C2DAC; Wed, 27 Mar 2019 08:21:14 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ya-f8ypkdZ6U; Wed, 27 Mar 2019 08:21:14 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Wed, 27 Mar 2019 08:21:14 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" Cc: Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers References: <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> From: Rebecca Cran Message-ID: <80ab3ea0-ed02-112c-d013-16aa360a8bf3@bluestop.org> Date: Wed, 27 Mar 2019 08:20:14 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: E139576862 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.97 / 15.00]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.970,0]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Wed, 27 Mar 2019 14:20:22 -0000 On 3/27/19 2:47 AM, Rodney W. Grimes wrote: > > Please go implement the placing of the version that is used to > cause uname -U to output 1200086 or whatever from /usr/sbin/uname > at build time, which is not an issue at all as far as reproducabile > builds as that version number is the same no mater how many times you > run the build. > > This is the current defining value that says your kernel is compatible > with userland and should also be the defining value for if your boot > code is also compatible. I do think that'll be useful, so I'll try and get that into the design doc that Warner's writing! -- Rebecca Cran From owner-freebsd-hackers@freebsd.org Wed Mar 27 14:25:22 2019 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 2644D155171E; Wed, 27 Mar 2019 14:25:22 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFB8176EA1; Wed, 27 Mar 2019 14:25:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 57E7713696; Wed, 27 Mar 2019 14:25:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f181.google.com with SMTP id j89so14594153ljb.1; Wed, 27 Mar 2019 07:25:21 -0700 (PDT) X-Gm-Message-State: APjAAAUurQXbdqP8vJjYgjo+EPMGzPWVq49BKkrq6waT/sAy1XqFwxpJ EpRQCEjUOyPqZ613EXeKguaL0KFVZRUJfyRoz2c= X-Google-Smtp-Source: APXvYqwS1CUpIdeO07lEN+q/BuhbrAmHzYjuARonsVxmYhE0IVjEdR+5kv0YMJ/ASPqH1AUJhrDBCWQvzlzcnMIKxo0= X-Received: by 2002:a2e:5c7:: with SMTP id 190mr19336874ljf.108.1553696719850; Wed, 27 Mar 2019 07:25:19 -0700 (PDT) MIME-Version: 1.0 References: <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> In-Reply-To: <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> From: Kyle Evans Date: Wed, 27 Mar 2019 09:25:05 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" Cc: Rebecca Cran , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: BFB8176EA1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.97)[-0.966,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Wed, 27 Mar 2019 14:25:22 -0000 On Wed, Mar 27, 2019 at 3:47 AM Rodney W. Grimes wrote: > > > On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > > > > > > > The current BTX 1.1 is bit rot, that value has not changed in ages > > > and tells me nothing about what boot code I am running, why do we > > > even output it? > > > > > > Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, Revision > > 1.1" in "strings /boot/loader.efi" shows one way we could easily embed a > > useful version number. > > Please go implement the placing of the version that is used to > cause uname -U to output 1200086 or whatever from /usr/sbin/uname > at build time, which is not an issue at all as far as reproducabile > builds as that version number is the same no mater how many times you > run the build. > > This is the current defining value that says your kernel is compatible > with userland and should also be the defining value for if your boot > code is also compatible. > This feels slightly wrong/misleading. We change loader -> kernel handoff far, far, far less frequently than we change userland <-> kernel compatibility. I don't have any constructive feedback otherwise, though, and it does at least provide an indicator of how old your boot bits are relative to the rest of the world. From owner-freebsd-hackers@freebsd.org Wed Mar 27 15:24:13 2019 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 845BB1552D2B for ; Wed, 27 Mar 2019 15:24:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F162D80EFB for ; Wed, 27 Mar 2019 15:24:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-lf1-x133.google.com with SMTP id u9so11577324lfe.11 for ; Wed, 27 Mar 2019 08:24:12 -0700 (PDT) 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=Cw8Oj+xmVH3AUxa/tV2nqMXSjCj2kGzimJSuADGVqF4=; b=rqAQq1H4fUE6yMEk8JRD3HTAmtflZEA0iLwv5rxzxpiRoRmrlBSt7fQgN2NtxsbljL ra7FTzwVWFO9P14b/7811LncSHSyx46R2nFjRs/q0AImjREBdtAX0oReen9WExqF7qK/ 9c3pQ8dtDs/CL7s9LwCJdOynJ1qO+NvY7E8GmA5RXnzPZhfJFnqRaSXxkEdhoWUFbkt0 doSOHLB416S8ZHMTBnKXMB3sY9aRWWDtkNVSaji+0dHPDWSkJH0FmbMdq2YSuXxNlHC0 I03z07dfXFfnFHxA7jYBQg7TSV7yeGpW3ESHO9EscxACKCAQPrE3Tl4QyWo/Nw23HZUI Nx8g== 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=Cw8Oj+xmVH3AUxa/tV2nqMXSjCj2kGzimJSuADGVqF4=; b=P3gE/QBXgzhbC3Qob5Qjp+ZLf6Us96ljsjyqMDAfWMqDUCc+P+PCP8ZwUwl6SujRxR Y0Y7iDBLvaFLsFqO3EmJ6dRMTQ+PuZekGd0wkkjWXado3de12dfsJ0BCMGL7sXM+G9hf NI16WMPuV5SqHckuySv7t4NKKoAR85+Qbq18a4MxtedBIP+fxmsghFixyG+XS1L2pR2W 7Me+XfRkTUtgH9cphqMo3Kkasrtv+7lh0nK0kfYShw4nBqV9i6JEDT+gVgy1y0j6opvS mcGuE9hMVva3FCusLK7Zes0sLPRziaq54c4t8WfcH8FUNe4gf+lc58eF3zOakeSKJ513 m13Q== X-Gm-Message-State: APjAAAUpTbVDJac4Tbj/zr0mS4G3705Sf4BPm3AtK0Ijb8MvUcjwhrC5 9cBMogpGRMsMG6g9nYHshEGvccdWFlGR8OeQFhWPQA== X-Google-Smtp-Source: APXvYqzLfgNyWtYifyQwpn65JZfx5UcvA6qJ4RokVaefjRetm1OiYbkTcjICFiea6WjMLmaQeW2d/06UrlP+9CBRLoE= X-Received: by 2002:ac2:592f:: with SMTP id v15mr14302952lfi.133.1553700250994; Wed, 27 Mar 2019 08:24:10 -0700 (PDT) MIME-Version: 1.0 References: <0828a41a-c25d-37a2-25b3-82c35c9a5c5d@bluestop.org> <201903270847.x2R8lMxc088823@gndrsh.dnsmgr.net> In-Reply-To: From: Warner Losh Date: Wed, 27 Mar 2019 09:23:59 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Kyle Evans Cc: "Rodney W. Grimes" , Konstantin Belousov , Rebecca Cran , FreeBSD Hackers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: F162D80EFB X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.971,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Wed, 27 Mar 2019 15:24:13 -0000 On Wed, Mar 27, 2019 at 8:26 AM Kyle Evans wrote: > On Wed, Mar 27, 2019 at 3:47 AM Rodney W. Grimes > wrote: > > > > > On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > > > > > > > > > > The current BTX 1.1 is bit rot, that value has not changed in ages > > > > and tells me nothing about what boot code I am running, why do we > > > > even output it? > > > > > > > > > Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, Revision > > > 1.1" in "strings /boot/loader.efi" shows one way we could easily embed > a > > > useful version number. > > > > Please go implement the placing of the version that is used to > > cause uname -U to output 1200086 or whatever from /usr/sbin/uname > > at build time, which is not an issue at all as far as reproducabile > > builds as that version number is the same no mater how many times you > > run the build. > > > > This is the current defining value that says your kernel is compatible > > with userland and should also be the defining value for if your boot > > code is also compatible. > > > > This feels slightly wrong/misleading. We change loader -> kernel > handoff far, far, far less frequently than we change userland <-> > kernel compatibility. I don't have any constructive feedback > otherwise, though, and it does at least provide an indicator of how > old your boot bits are relative to the rest of the world. > Right. The loader has nothing to do with the userland (apart from sharing some minor bits of code that are too boring to be versioned). There are two versions we're interested in for the loader. First is the loader <-> kernel handoff. That's not materially changed in decades, so it's version number is still basically 1. there are some fine details here I'm purposely glossing over, but they are far down in the noise. The second is the loader to loader support files version. We don't actually version this, but you can't install /boot/loader* without installing the companion files. This often will work (especially in the FORTH era when the code velocity of the .4th files was so slow and the new FORTH words / loader commands were added so rarely), but not always. In the LUA era, we're still in the up-take phase of things. We've gotten to parity (more or less) with FORTH and now it's time to innovate. That innovation will likely require new lua primitives to be implemented in C, which requires a matched set of the loader and support files. This is nothing new (we had it when FORTH was moving quickly all the time, and had it less often when new features like ZFS booting came in). There's a new wrinkle, though, in all this, which is our desire to get rid of boot1.efi and replace it with loader.efi. This brings the issue of 'cross-threading' of updates to the fore. That's an interesting issue, and that won't be solved by the uname version hack. We could burn the sys/param.h version into loader.efi but it wouldn't detect anything in the lua files we install. We could add a new lua file that's just the version an complain when there's a mismatch, but that seems to just introduce a failure mode that's not effective at solving problems (there will be a lot of false positives, because the loader changes like I'm worried about happen at about 1/50th the rate of version bumps). We could invent something for the boot loader, but that would be fragile, and have all the same issues of 'what to do' when there's a mismatch. We're likely better off wrapping new features in such a way as they can be missing and the code will still work with reduced functionality. This is why it feels wrong to me. It's a poor fit to the problem at hand, the number isn't conveniently encoded in the right places and it's unclear what to do with mismatches. Warner From owner-freebsd-hackers@freebsd.org Wed Mar 27 17:31:18 2019 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 CB9EE1555702 for ; Wed, 27 Mar 2019 17:31:18 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6554085099 for ; Wed, 27 Mar 2019 17:31:18 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2RHVG3F090753; Wed, 27 Mar 2019 10:31:16 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2RHVGJd090752; Wed, 27 Mar 2019 10:31:16 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903271731.x2RHVGJd090752@gndrsh.dnsmgr.net> Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" In-Reply-To: To: Warner Losh Date: Wed, 27 Mar 2019 10:31:16 -0700 (PDT) CC: Kyle Evans , Konstantin Belousov , Rebecca Cran , "freebsd-arch@freebsd.org" , "Rodney W. Grimes" , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 6554085099 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Wed, 27 Mar 2019 17:31:19 -0000 > On Wed, Mar 27, 2019 at 8:26 AM Kyle Evans wrote: > > > On Wed, Mar 27, 2019 at 3:47 AM Rodney W. Grimes > > wrote: > > > > > > > On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > > > > > > > > > > > > > The current BTX 1.1 is bit rot, that value has not changed in ages > > > > > and tells me nothing about what boot code I am running, why do we > > > > > even output it? > > > > > > > > > > > > Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, Revision > > > > 1.1" in "strings /boot/loader.efi" shows one way we could easily embed > > a > > > > useful version number. > > > > > > Please go implement the placing of the version that is used to > > > cause uname -U to output 1200086 or whatever from /usr/sbin/uname > > > at build time, which is not an issue at all as far as reproducabile > > > builds as that version number is the same no mater how many times you > > > run the build. > > > > > > This is the current defining value that says your kernel is compatible > > > with userland and should also be the defining value for if your boot > > > code is also compatible. > > > > > > > This feels slightly wrong/misleading. We change loader -> kernel > > handoff far, far, far less frequently than we change userland <-> > > kernel compatibility. I don't have any constructive feedback > > otherwise, though, and it does at least provide an indicator of how > > old your boot bits are relative to the rest of the world. > > > > Right. The loader has nothing to do with the userland (apart from sharing > some minor bits of code that are too boring to be versioned). There are two > versions we're interested in for the loader. > > First is the loader <-> kernel handoff. That's not materially changed in > decades, so it's version number is still basically 1. there are some fine > details here I'm purposely glossing over, but they are far down in the > noise. > > The second is the loader to loader support files version. We don't actually > version this, but you can't install /boot/loader* without installing the > companion files. This often will work (especially in the FORTH era when the > code velocity of the .4th files was so slow and the new FORTH words / > loader commands were added so rarely), but not always. In the LUA era, > we're still in the up-take phase of things. We've gotten to parity (more or > less) with FORTH and now it's time to innovate. That innovation will likely > require new lua primitives to be implemented in C, which requires a matched > set of the loader and support files. This is nothing new (we had it when > FORTH was moving quickly all the time, and had it less often when new > features like ZFS booting came in). There's a new wrinkle, though, in all > this, which is our desire to get rid of boot1.efi and replace it with > loader.efi. This brings the issue of 'cross-threading' of updates to the > fore. That's an interesting issue, and that won't be solved by the uname > version hack. We could burn the sys/param.h version into loader.efi but it > wouldn't detect anything in the lua files we install. We could add a new > lua file that's just the version an complain when there's a mismatch, but > that seems to just introduce a failure mode that's not effective at solving > problems (there will be a lot of false positives, because the loader > changes like I'm worried about happen at about 1/50th the rate of version > bumps). We could invent something for the boot loader, but that would be > fragile, and have all the same issues of 'what to do' when there's a > mismatch. We're likely better off wrapping new features in such a way as > they can be missing and the code will still work with reduced functionality. > > This is why it feels wrong to me. It's a poor fit to the problem at hand, > the number isn't conveniently encoded in the right places and it's unclear > what to do with mismatches. I care nothing about miss matches, I care to know from witch sources my loader.* /boot/* files come from and that is just a royal PITA to figure out without something like this. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu Mar 28 12:46:02 2019 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 5B7D3155BF4C for ; Thu, 28 Mar 2019 12:46:02 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [IPv6:2a01:4f8:d0a:2645::2]) (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 16E546EFA3 for ; Thu, 28 Mar 2019 12:46:00 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [78.46.172.3] (helo=sslproxy06.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1h9UPm-0000Dm-Qj for freebsd-hackers@freebsd.org; Thu, 28 Mar 2019 13:45:50 +0100 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy06.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1h9UPm-000EdX-L6 for freebsd-hackers@freebsd.org; Thu, 28 Mar 2019 13:45:50 +0100 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 4BF472A1611 for ; Thu, 28 Mar 2019 13:45:53 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id CCCyzojP6MXh for ; Thu, 28 Mar 2019 13:45:52 +0100 (CET) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id DA3E82A167E for ; Thu, 28 Mar 2019 13:45:52 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id G2zt5JucqwGI for ; Thu, 28 Mar 2019 13:45:52 +0100 (CET) Received: from huber-nb-linux.suse (unknown [192.168.96.161]) by mail.embedded-brains.de (Postfix) with ESMTPSA id C5C612A1611 for ; Thu, 28 Mar 2019 13:45:52 +0100 (CET) To: FreeBSD From: Sebastian Huber Subject: What is the purpose of BURN_BRIDGES? Message-ID: <1fd4571d-0da1-e325-b6a1-a3cc12f2f05d@embedded-brains.de> Date: Thu, 28 Mar 2019 13:45:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.100.2/25402/Thu Mar 28 08:54:39 2019) X-Rspamd-Queue-Id: 16E546EFA3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=softfail (mx1.freebsd.org: 2a01:4f8:d0a:2645::2 is neither permitted nor denied by domain of sebastian.huber@embedded-brains.de) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-2.82 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_SEVEN(0.00)[8]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(-0.81)[ipnet: 2a01:4f8::/29(-2.12), asn: 24940(-1.92), country: DE(-0.01)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[embedded-brains.de]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mx.embeddedbrains.de,mx.netmuc.net]; NEURAL_HAM_SHORT(-0.91)[-0.906,0]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; HAS_X_AS(0.00)[] 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: Thu, 28 Mar 2019 12:46:02 -0000 Hello, I turned on BURN_BRIDGES in my global kernel configuration and now I get=20 undefined references, e.g. /build/rtems/5/lib/gcc/powerpc-rtems5/7.4.0/../../../../powerpc-rtems5/bi= n/ld:=20 ./libbsd.a(ip6_output.c.18.o): in function `_bsd_ip6_output': /scratch/git-rtems-libbsd/build/powerpc-rtems5-qoriq_e6500_64-default/../= ../freebsd/sys/netinet6/ip6_output.c:548:=20 undefined reference to `_bsd_in6_selectroute_fib' /build/rtems/5/lib/gcc/powerpc-rtems5/7.4.0/../../../../powerpc-rtems5/bi= n/ld:=20 ./libbsd.a(nd6.c.18.o): in function `nd6_llinfo_timer': /scratch/git-rtems-libbsd/build/powerpc-rtems5-qoriq_e6500_64-default/../= ../freebsd/sys/netinet6/nd6.c:881:=20 undefined reference to `_bsd_nd6_ns_output' /build/rtems/5/lib/gcc/powerpc-rtems5/7.4.0/../../../../powerpc-rtems5/bi= n/ld:=20 ./libbsd.a(nd6.c.18.o): in function `nd6_resolve_slow': /scratch/git-rtems-libbsd/build/powerpc-rtems5-qoriq_e6500_64-default/../= ../freebsd/sys/netinet6/nd6.c:2461:=20 undefined reference to `_bsd_nd6_ns_output' /build/rtems/5/lib/gcc/powerpc-rtems5/7.4.0/../../../../powerpc-rtems5/bi= n/ld:=20 ./libbsd.a(nd6_nbr.c.18.o): in function `nd6_dad_ns_output': /scratch/git-rtems-libbsd/build/powerpc-rtems5-qoriq_e6500_64-default/../= ../freebsd/sys/netinet6/nd6_nbr.c:1513:=20 undefined reference to `_bsd_nd6_ns_output' This is because of (in6_src.c): #ifndef BURN_BRIDGES int in6_selectroute_fib(struct sockaddr_in6 *dstsock, struct ip6_pktopts *opt= s, =C2=A0=C2=A0=C2=A0 struct ip6_moptions *mopts, struct route_in6 *ro, =C2=A0=C2=A0=C2=A0 struct ifnet **retifp, struct rtentry **retrt, u_int = fibnum) { =C2=A0=C2=A0=C2=A0 return (selectroute(dstsock, opts, mopts, ro, retifp, =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 retrt, 0, fibnum)); } #endif And (ip6_output.c): int ip6_output(struct mbuf *m0, struct ip6_pktopts *opt, =C2=A0=C2=A0=C2=A0 struct route_in6 *ro, int flags, struct ip6_moptions = *im6o, =C2=A0=C2=A0=C2=A0 struct ifnet **ifpp, struct inpcb *inp) { ... =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 if (ro->ro_lle) =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 LLE_FREE(ro->ro= _lle);=C2=A0=C2=A0=C2=A0 /* zeros ro_lle */ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 ro->ro_lle =3D NULL; =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 if (fwd_tag =3D=3D NULL) { =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 bzero(&dst_sa, = sizeof(dst_sa)); =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 dst_sa.sin6_fam= ily =3D AF_INET6; =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 dst_sa.sin6_len= =3D sizeof(dst_sa); =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 dst_sa.sin6_add= r =3D ip6->ip6_dst; =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 error =3D in6_selectroute_fib(&dst= _sa, opt, im6o, ro, &ifp, =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 &rt, fibnum); =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 if (error !=3D 0) { =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 if (ifp !=3D NU= LL) =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 in6_ifstat_inc(ifp, ifs6_out_discard); =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 goto bad; =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 } No BURN_BRIDGES conditional compilation. Is this option supposed to=20 work? What is its purpose? I enabled it to get rid of some legacy stuff=20 in bpf.c. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Thu Mar 28 14:45:25 2019 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 25E32155F905 for ; Thu, 28 Mar 2019 14:45:25 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4AC0274E1B for ; Thu, 28 Mar 2019 14:45:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f180.google.com with SMTP id k23so8565508lji.13 for ; Thu, 28 Mar 2019 07:45:24 -0700 (PDT) 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=HCunTQuX4bSMUWTsL34qDoJS201TtLVEQ+yjnCQ/ju4=; b=iVlVYmQ9sHTOVPc/NR4NiLlglkozrQVrvuHyeD2l9nNAgJj0gizcDmy+oIIMwbKnme T7oBEbLnK0nk16792niWdwJxOCTA07B67jR8DZOtrc3sCw7qQu80TwMdMNvxr7P2CsOR 6YqVNlwGE+LPzu7dn6HXlTnxJfqM0d0QXU4QBC1Fq7sZk2yDZ7QPYtEAsdwOhwRRkSyw J2IDcZ8YI3Sd0UdxvdLZ+oZyy9vrWeyXfX/mazKTD4wbw+4uTMRFAE/BiRi+DXUTbwMa EhRViQIxwCeCTXaYJj5GS55lv9BmubrJVtsumIFlYX6shq6HjTQgEDmYblwjf7W8/HmS vE3Q== X-Gm-Message-State: APjAAAVgrrs6eatVKrTXItF28CuWknyTuLFwnGY1/d4pzC2kObJx6iNb bZWcWa0ywiZhea9dXvkgmYWZL8nZ46I+yF7PR/o= X-Google-Smtp-Source: APXvYqw+IQ5+lNDLWaqWg4nu5vBMX0ixZgQ1xO/Ca+abvjyYwxhvIgLGI8ymlIfhk8PFOyPmZL5bV2xqSZt08UyFPoA= X-Received: by 2002:a2e:8582:: with SMTP id b2mr8877664lji.24.1553783843912; Thu, 28 Mar 2019 07:37:23 -0700 (PDT) MIME-Version: 1.0 References: <1fd4571d-0da1-e325-b6a1-a3cc12f2f05d@embedded-brains.de> In-Reply-To: <1fd4571d-0da1-e325-b6a1-a3cc12f2f05d@embedded-brains.de> From: Alan Somers Date: Thu, 28 Mar 2019 08:37:12 -0600 Message-ID: Subject: Re: What is the purpose of BURN_BRIDGES? To: Sebastian Huber Cc: FreeBSD Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4AC0274E1B X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.06 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; IP_SCORE(-1.30)[ip: (-0.40), ipnet: 209.85.128.0/17(-3.87), asn: 15169(-2.15), country: US(-0.07)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[180.208.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.75)[-0.751,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 28 Mar 2019 14:45:25 -0000 On Thu, Mar 28, 2019 at 6:46 AM Sebastian Huber wrote: > > Hello, > > I turned on BURN_BRIDGES in my global kernel configuration and now I get > undefined references, e.g. > > > No BURN_BRIDGES conditional compilation. Is this option supposed to > work? What is its purpose? I enabled it to get rid of some legacy stuff > in bpf.c. > > -- > Sebastian Huber, embedded brains GmbH I've often wondered that myself. "svn blame" turns up the following. Evidentially the code didn't disappear in 6.0 after all. ------------------------------------------------------------------------ r116236 | imp | 2003-06-11 22:39:32 -0600 (Wed, 11 Jun 2003) | 5 lines New global option: BURN_BRIDGES Compile out code that will disappear in 6.0, per Peter Wemm's bridge burning proposal. From owner-freebsd-hackers@freebsd.org Thu Mar 28 19:06:40 2019 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 23E801565DDF for ; Thu, 28 Mar 2019 19:06:40 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BB18186BBD; Thu, 28 Mar 2019 19:06:37 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id AAFF22025670; Thu, 28 Mar 2019 19:06:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id x2SJ6TNO011831 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 28 Mar 2019 19:06:29 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id x2SJ6S6g011830; Thu, 28 Mar 2019 19:06:28 GMT (envelope-from phk) To: Alan Somers cc: Sebastian Huber , FreeBSD Subject: Re: What is the purpose of BURN_BRIDGES? In-reply-to: From: "Poul-Henning Kamp" References: <1fd4571d-0da1-e325-b6a1-a3cc12f2f05d@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11828.1553799988.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Mar 2019 19:06:28 +0000 Message-ID: <11829.1553799988@critter.freebsd.dk> X-Rspamd-Queue-Id: BB18186BBD X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [5.14 / 15.00]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[phk.freebsd.dk]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.88)[0.878,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.dk]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.91)[0.912,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.97)[0.970,0]; R_SPF_NA(0.00)[]; IP_SCORE(0.09)[ip: (0.16), ipnet: 130.225.0.0/16(0.08), asn: 1835(0.21), country: EU(-0.00)] 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: Thu, 28 Mar 2019 19:06:40 -0000 -------- In message , Alan Somers writes: >New global option: BURN_BRIDGES > >Compile out code that will disappear in 6.0, per Peter Wemm's bridge >burning proposal. Yeah, turned out Peters matches were not as dry as we had hoped :-) -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Thu Mar 28 19:49:53 2019 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 C4CAD1567252 for ; Thu, 28 Mar 2019 19:49:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C7EE888B2 for ; Thu, 28 Mar 2019 19:49:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x834.google.com with SMTP id v32so24576798qtc.10 for ; Thu, 28 Mar 2019 12:49:53 -0700 (PDT) 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=lGpNPJECqEG9g2L7J5OE+LHwWyN5oqY22cvR/ddDSmE=; b=SkaC29mG8BGKR139lq3kOGM4+UYSDZP2sMABfWBmLVDlYs/lYSnc6k/y/UXGwjJfKZ GFhGyF+3S4tXfBTAXQIQ74sJ1qv9qhE6kZUYen3TQr5++1rnYPf/340M0ODvpy21W2h9 tLHlN3zRLcSz9YdTe0FnYXfbwfv5pNghtpkpiytOC9CiQ2tnHNlCC1hg2jpoUfjJnKrF S557kQYmk4hp/iP40IOTKBW502nA/+6sfM7lGNGdGwbUqAn82UvCjv3loBBTsESLv9n2 fkTNq2dYXBGacka1H7FKlGSG8BUKIaBlf+uETpzPfVwmcB0iLmMfvbyFmEo1xVcda805 GFZA== 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=lGpNPJECqEG9g2L7J5OE+LHwWyN5oqY22cvR/ddDSmE=; b=sSa7TyCbdjazQ1W5MW7j9jULRCSKyO/wQ/lgY1CwjwLACKh33b35Lpt7gCHcvDzZ56 57Z+dJppgmN/N5FSLAfbDKf1RE8zcgVipf+fuyi/EnrGeZ0/1xDGwtt3gq7XqlQYhTgP 3z8pLe3V78MNCWyAZzonyYvyYEZYJVsfylH8ndhmv1i1sbIDSrlqjAkUr8/IsByZrgbc I7bOADX9Iscc/pJTeg3ET+UXutwbb6qpBIBO/Kw8HqyVXMfbnIkN0QJczh11vptKDeUs M9bUxEn/rfNSv+HD+eqN86/mSMWDZKghfXanwAjfA5MVHt69QPgSwMC6pctL4VDpUGUF XhqA== X-Gm-Message-State: APjAAAXpUFUMBd8Smx9y/TaBLWJmbC7X0ktwQ2Ry4x99lzdsoH+CrH/2 7mp4NfHl+DkYt+hY2ocpXgCDo0K7gugf+ENWbuQVaH9D X-Google-Smtp-Source: APXvYqx69sdQHqmkRtW9NiwjE47eRtDgCY6lkqEIt0YMjEUwTj6ptj7SGMTb2arYy9wzj4rXzbLf5j+R3MOJdmDzEGk= X-Received: by 2002:a0c:8a59:: with SMTP id 25mr38137820qvu.191.1553802592145; Thu, 28 Mar 2019 12:49:52 -0700 (PDT) MIME-Version: 1.0 References: <1fd4571d-0da1-e325-b6a1-a3cc12f2f05d@embedded-brains.de> <11829.1553799988@critter.freebsd.dk> In-Reply-To: <11829.1553799988@critter.freebsd.dk> From: Warner Losh Date: Thu, 28 Mar 2019 13:49:40 -0600 Message-ID: Subject: Re: What is the purpose of BURN_BRIDGES? To: Poul-Henning Kamp Cc: Alan Somers , Sebastian Huber , FreeBSD X-Rspamd-Queue-Id: 0C7EE888B2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=SkaC29mG X-Spamd-Result: default: False [-4.59 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; IP_SCORE(-2.76)[ip: (-8.71), ipnet: 2607:f8b0::/32(-2.87), asn: 15169(-2.15), country: US(-0.07)]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[4.3.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]; NEURAL_HAM_SHORT(-0.82)[-0.824,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 28 Mar 2019 19:49:54 -0000 On Thu, Mar 28, 2019, 1:08 PM Poul-Henning Kamp wrote: > -------- > In message < > CAOtMX2jCHqrESzNZKpOcfEL1oc4JRP2u5io7zTMj9AiJO71Cfw@mail.gmail.com> > , Alan Somers writes: > > >New global option: BURN_BRIDGES > > > >Compile out code that will disappear in 6.0, per Peter Wemm's bridge > >burning proposal. > > Yeah, turned out Peters matches were not as dry as we had hoped :-) > It was intended as a way to tag old, obscure code for removal. It lost steam, though I'd like to kill most of the code under it... many of the bridges to be removed were, just not all of them. Warner -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > 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" > From owner-freebsd-hackers@freebsd.org Thu Mar 28 20:43:56 2019 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 0C0AD1568CD7 for ; Thu, 28 Mar 2019 20:43:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1934C8B327 for ; Thu, 28 Mar 2019 20:43:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x829.google.com with SMTP id h39so171492qte.2 for ; Thu, 28 Mar 2019 13:43:55 -0700 (PDT) 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=NIKQRQJT2zh/ZMuYCTx1k5eOO+fJ/n8sHhrGG3B8ziw=; b=C9XqRH3psXobpYln6E9BSVAVobF+f2V+gDrGoE+BNVpz11IkzE3aAd9dfd4SxrBr3+ NIgixS+7QOHRySj1AeigerL4CmURmHJSDbjzC8S5OT+oFGDNMZ97zmCzDsCfYfzSKY2B +WSm5uvWIMtkR0WarxPLWgoR3/kaxdoqscDanDXtmLr/97H+fMjsapYnfiFVGNavQMBj h20uGuCvyCA/EBb0mJVbkb/RO3pQGa5Hg4L4HaRTo4DbE8Ykf9/Q/Meoa5CNKB5ZBSib JIReKaNB2rRmI4RKbShQly1KQlB1Hae7eO70cTCE4lCwqErsmZfKp4BN8ccUiOMqsHKj l4hg== 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=NIKQRQJT2zh/ZMuYCTx1k5eOO+fJ/n8sHhrGG3B8ziw=; b=pz2gFbXdBblQWdmRpmXwqDGU488FG05DVU3/ghQ0q1LD/3DhRQ4lZgM7zejWxb/J94 ls4tszXQ8GLFFuEJXNx6w8u/Fl7zcuutRfFLij9J7hgIvQ8b2NM5esGAX1/oHPW/xvuf EpgOhau8kn5J83nmoNONWMBKnIWvoC/r1l/zOWp8H9ZTCHglZUmQ4c3/KQEelRbzHwzA IOJLXZs724FJm1j6EefSOmFRN6XcaB17jwUOsys4lK5uhCYr2LQJ+maVo12O75o803j7 F2+kI2uxcuN1AZ1vsEcFwulGquJlqP6tS8eqwaj2rSRAoTcO98JugtyMa32UCYdL5gix s9Ig== X-Gm-Message-State: APjAAAXF9uFTC8W7DzFpgwr9ezmLWTNRuo+wSX6Fb4iy24irhThXT4ie 3r7qqthIssNN0Q+EbirWGhYc093bQZRdRpqZRe09Uw== X-Google-Smtp-Source: APXvYqxopW3gKF4oP8VLxK7oP0iY/IzFQ4uNK5fX54bMds67hZhegJgUuKOnCMQEjeRhd4dTBT+suOo4/Q5rB4d3/fQ= X-Received: by 2002:a0c:9838:: with SMTP id c53mr38308482qvd.242.1553805833388; Thu, 28 Mar 2019 13:43:53 -0700 (PDT) MIME-Version: 1.0 References: <201903271731.x2RHVGJd090752@gndrsh.dnsmgr.net> In-Reply-To: <201903271731.x2RHVGJd090752@gndrsh.dnsmgr.net> From: Warner Losh Date: Thu, 28 Mar 2019 14:43:41 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: "Rodney W. Grimes" Cc: Kyle Evans , Konstantin Belousov , Rebecca Cran , "freebsd-arch@freebsd.org" , FreeBSD Hackers X-Rspamd-Queue-Id: 1934C8B327 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=C9XqRH3p X-Spamd-Result: default: False [-5.67 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[9.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]; NEURAL_HAM_SHORT(-0.83)[-0.834,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; 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(-2.83)[ip: (-9.07), ipnet: 2607:f8b0::/32(-2.87), asn: 15169(-2.15), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 28 Mar 2019 20:43:56 -0000 On Wed, Mar 27, 2019 at 11:31 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > On Wed, Mar 27, 2019 at 8:26 AM Kyle Evans wrote: > > > > > On Wed, Mar 27, 2019 at 3:47 AM Rodney W. Grimes > > > wrote: > > > > > > > > > On 3/26/19 12:21 AM, Rodney W. Grimes wrote: > > > > > > > > > > > > > > > > > The current BTX 1.1 is bit rot, that value has not changed in > ages > > > > > > and tells me nothing about what boot code I am running, why do we > > > > > > even output it? > > > > > > > > > > > > > > > Sure, but the fact it shows up as "FreeBSD/amd64 EFI loader, > Revision > > > > > 1.1" in "strings /boot/loader.efi" shows one way we could easily > embed > > > a > > > > > useful version number. > > > > > > > > Please go implement the placing of the version that is used to > > > > cause uname -U to output 1200086 or whatever from /usr/sbin/uname > > > > at build time, which is not an issue at all as far as reproducabile > > > > builds as that version number is the same no mater how many times you > > > > run the build. > > > > > > > > This is the current defining value that says your kernel is > compatible > > > > with userland and should also be the defining value for if your boot > > > > code is also compatible. > > > > > > > > > > This feels slightly wrong/misleading. We change loader -> kernel > > > handoff far, far, far less frequently than we change userland <-> > > > kernel compatibility. I don't have any constructive feedback > > > otherwise, though, and it does at least provide an indicator of how > > > old your boot bits are relative to the rest of the world. > > > > > > > Right. The loader has nothing to do with the userland (apart from sharing > > some minor bits of code that are too boring to be versioned). There are > two > > versions we're interested in for the loader. > > > > First is the loader <-> kernel handoff. That's not materially changed in > > decades, so it's version number is still basically 1. there are some fine > > details here I'm purposely glossing over, but they are far down in the > > noise. > > > > The second is the loader to loader support files version. We don't > actually > > version this, but you can't install /boot/loader* without installing the > > companion files. This often will work (especially in the FORTH era when > the > > code velocity of the .4th files was so slow and the new FORTH words / > > loader commands were added so rarely), but not always. In the LUA era, > > we're still in the up-take phase of things. We've gotten to parity (more > or > > less) with FORTH and now it's time to innovate. That innovation will > likely > > require new lua primitives to be implemented in C, which requires a > matched > > set of the loader and support files. This is nothing new (we had it when > > FORTH was moving quickly all the time, and had it less often when new > > features like ZFS booting came in). There's a new wrinkle, though, in all > > this, which is our desire to get rid of boot1.efi and replace it with > > loader.efi. This brings the issue of 'cross-threading' of updates to the > > fore. That's an interesting issue, and that won't be solved by the uname > > version hack. We could burn the sys/param.h version into loader.efi but > it > > wouldn't detect anything in the lua files we install. We could add a new > > lua file that's just the version an complain when there's a mismatch, but > > that seems to just introduce a failure mode that's not effective at > solving > > problems (there will be a lot of false positives, because the loader > > changes like I'm worried about happen at about 1/50th the rate of version > > bumps). We could invent something for the boot loader, but that would be > > fragile, and have all the same issues of 'what to do' when there's a > > mismatch. We're likely better off wrapping new features in such a way as > > they can be missing and the code will still work with reduced > functionality. > > > > This is why it feels wrong to me. It's a poor fit to the problem at hand, > > the number isn't conveniently encoded in the right places and it's > unclear > > what to do with mismatches. > > I care nothing about miss matches, I care to know from witch sources > my loader.* /boot/* files come from and that is just a royal PITA to > figure out without something like this. > You do have the $FreeBSD$ tags for most of that today. For some of the boot pieces you'll never know more than the date it was installed because we're using 7.45kb of the 7.5kb available in boot2 and there's no room. For the other things, there's not really been requests to have more than we have today and it would come at a cost of additional space at a time when we're feeling space pressure in most of the components due to the new features that have rolled in since FreeBSD 10.x or so (secure boot, crypto signing, more filesystems, encrypted filesystems, etc). It all adds up... Warner From owner-freebsd-hackers@freebsd.org Fri Mar 29 06:03:06 2019 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 870F2155B118 for ; Fri, 29 Mar 2019 06:03:06 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (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 41DFE80A79 for ; Fri, 29 Mar 2019 06:03:04 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [78.46.172.3] (helo=sslproxy06.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1h9kbW-0003FD-8d; Fri, 29 Mar 2019 07:03:02 +0100 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy06.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1h9kbW-000NEA-3Y; Fri, 29 Mar 2019 07:03:02 +0100 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 886BA2A1611; Fri, 29 Mar 2019 07:03:05 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ECxYSBTUCs7i; Fri, 29 Mar 2019 07:03:05 +0100 (CET) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 387372A167E; Fri, 29 Mar 2019 07:03:05 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id v15MUa6B73q2; Fri, 29 Mar 2019 07:03:05 +0100 (CET) Received: from huber-nb-linux.suse (unknown [192.168.96.161]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 205262A1611; Fri, 29 Mar 2019 07:03:05 +0100 (CET) Subject: Re: What is the purpose of BURN_BRIDGES? To: Warner Losh Cc: FreeBSD References: <1fd4571d-0da1-e325-b6a1-a3cc12f2f05d@embedded-brains.de> <11829.1553799988@critter.freebsd.dk> From: Sebastian Huber Message-ID: Date: Fri, 29 Mar 2019 07:03:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.100.2/25402/Thu Mar 28 08:54:39 2019) X-Rspamd-Queue-Id: 41DFE80A79 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-2.49 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_SEVEN(0.00)[8]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; IP_SCORE(-0.39)[asn: 24940(-1.94), country: DE(-0.01)]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[embedded-brains.de]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx.embeddedbrains.de]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[148.215.10.85.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_SHORT(-0.80)[-0.798,0]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; HAS_X_AS(0.00)[] 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, 29 Mar 2019 06:03:06 -0000 On 28/03/2019 20:49, Warner Losh wrote: > > > On Thu, Mar 28, 2019, 1:08 PM Poul-Henning Kamp > wrote: > > -------- > In message > > > , Alan Somers writes: > > >New global option: BURN_BRIDGES > > > >Compile out code that will disappear in 6.0, per Peter Wemm's brid= ge > >burning proposal. > > Yeah, turned out Peters matches were not as dry as we had hoped :-) > > > It was intended as a way to tag old, obscure code for removal. It lost=20 > steam, though I'd like to kill most of the code under it... many of=20 > the bridges to be removed were, just not all of them. My aim was to get rid of the legacy support in sys/net/bpf.c. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Sat Mar 30 13:46:33 2019 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 B0A4E1550EE3; Sat, 30 Mar 2019 13:46:33 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B54088AE7; Sat, 30 Mar 2019 13:46:32 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-ed1-x52c.google.com with SMTP id d1so4338947edd.13; Sat, 30 Mar 2019 06:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=HWLojJw9Rcb0Ts4D1CpYBeoeLrL0aRkugqetLXv/oUs=; b=a6+edsrdhGV5zfAd/YZgG4XlO7ZKkZHkKKyItZICFdcA6+J7VVAWlXfnDaoHachmpa x4AxP09++9nzCVnd585/8DOIfA8lHfYu+M2k5d85pDfzrmkmqarhyz1qH06KPjYtOkXe iSQKOG9cR1rUKrHxIn600NCs9yO0tQ7VH8xz5AKMx7gKP2c2A0YZ4a4XAroCTirP/GF5 fXimkCtSiWRZcwReoPD01qg+2JhkgB4tzWY7KYnoj527jqetRkshIReFunA7H+gjbEIK I5nCgx8HioSvZ8WAtkAh/IK02fio0QTei4ipqV4pvfVUjtCALwcf1MKR/34mXjbaO8da i7Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=HWLojJw9Rcb0Ts4D1CpYBeoeLrL0aRkugqetLXv/oUs=; b=HvaYkyN3zihlei6i4tosrsWEzK4zmOVPbXwOYJ5rwBtkAFQpPXj88M23mKCPOu585b afunyiLNwC/Vr5KRkBQLjwuYessEQ6HtNldxQotObc5ldu0URe7fZR5kHixnE9BHjKZC CZxkwReO5OwrcVFWF7FYRqETwAEpMT6g70yPTcIh8wWCqsJNYYGYMkzZVhYNlB1Y0FH+ TUWg0A0Kxx+JN5IM3MoVnUdiEDMpHt5P+zN+SlDs4+IYfYC+ROVK+fXwleL8NVw40CVc agd/Bt5rU5wWO8ZU9l0uAlm7VmIUIs7TklpzTYs+ZX21y8CqU6tKd49dVCL0czRCEWUI 3H8w== X-Gm-Message-State: APjAAAU+v11mil0/TYC1/siYl3L2ih8riajA/O5ON8CVzkTkWwmCScUF hRjH838ePSaZsMcQgKunZPO3TdI9 X-Google-Smtp-Source: APXvYqxdFrdfoCrqpgBqNtscSO8YEUBlQmgPjUypF7HZUjKCu+tKlCCwar/AOeUGq9Ss278kk1l+ZQ== X-Received: by 2002:a50:86a7:: with SMTP id r36mr35462446eda.259.1553953590977; Sat, 30 Mar 2019 06:46:30 -0700 (PDT) Received: from rimwks ([2001:470:1f15:3d8:c95:8c12:4f5f:87ba]) by smtp.gmail.com with ESMTPSA id a38sm1509712eda.71.2019.03.30.06.46.29 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sat, 30 Mar 2019 06:46:30 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sat, 30 Mar 2019 16:46:28 +0300 To: freebsd-hackers@freebsd.org Cc: current@freebsd.org, amd64@freebsd.org, Rozhuk.IM@gmail.com Subject: Boot hang on ryzen based notebook Message-ID: <20190330164628.138a2bad@rimwks> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6B54088AE7 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=a6+edsrd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=rozhukim@gmail.com X-Spamd-Result: default: False [-6.04 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.80)[-0.800,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[c.2.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.73)[ip: (-9.10), ipnet: 2a00:1450::/32(-2.36), asn: 15169(-2.14), country: US(-0.07)]; MID_RHS_NOT_FQDN(0.50)[] 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: Sat, 30 Mar 2019 13:46:34 -0000 Hello! Cant boot on ASUS VivoBook 15 X505ZA (AMD Ryzen 5 2500U) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236899 Sreenshot: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203257 Any ideas how to start? From owner-freebsd-hackers@freebsd.org Sat Mar 30 14:37:44 2019 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 CCAF6155299A; Sat, 30 Mar 2019 14:37:44 +0000 (UTC) (envelope-from dariusmihaim@gmail.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69D598A4B3; Sat, 30 Mar 2019 14:37:44 +0000 (UTC) (envelope-from dariusmihaim@gmail.com) Received: by mail-qt1-x829.google.com with SMTP id h39so5987325qte.2; Sat, 30 Mar 2019 07:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/1wXILBKpKyGs/zYNSnpzMw1tkVyRAHEUv/jrWiD65g=; b=OTtEM/ZpAnowk4Lb5DRoU/Nt7+Lknd69g25+UBJ0hUKBeNJS5wqBvAgyz8SzSDJl+B IMFrcjAYM8aNftEnvweI6Z8LdLq7ttNO0F7KH+qhO5BfoXDdzV1RxEarfu82FUqXIcbl XPRGuBSzfnFImMnVcL/Z8tc2xzutnNmNRxiKUGCGTozXdhR44T48gUPYDgVlAxmZGd5V vP7ujc9GWMp/jxdsgFr01Ce0CbIJUdXd9ubPj8QaAWB+cOwqowi/exim5JOaVOHIxQjB laDC92niPGO5E6GDmFS414Sn19ePJct9wiYiC3fQX+IaZEFNZxlQReOPg9PKRgHZcWUk /0JQ== 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=/1wXILBKpKyGs/zYNSnpzMw1tkVyRAHEUv/jrWiD65g=; b=qM4VbnO1GaT1yTLbgtnWxYvizXQVp6JmR8nhe15PL05QznUdAIhtEPaMk6vatUCRit B1fVFPMTU/rnvG680mIB8ZWqXdD5R6hcBjx1hDYJDFl/7iglxM+dXMWfetGkrjXA4Qh6 VimLu61tuT0Sz5+k2YTmK25KjO5Vs8PnmqI0dFhsJVsTYLadkgzYh9Of2AXqpxWeLJsm WnGsWpPNvxboAOMZc1q2JLEAfzsi2p23G9JJdp9CKYXbXyY6HdlfIit9xNp23Vn3HgvX hQLDqRoNt7edqGj/hCbRBbltetpaMUXRsEq8GhJQtMBOpdksL/KI4lj2tiOODj8KA652 5W4Q== X-Gm-Message-State: APjAAAX3XwkVaqJCh4e0GfR1lVnNtlxfFWLTppGiUKTgmYakoosS/qkF L5yfAgOLVzH7X/KQtqke+6lbkectzL+EE8Z28BY= X-Google-Smtp-Source: APXvYqyujjKOwjFjZVIIRQuzjnIgGyD+c4XDLx9g0TL/V//QC11nq5WtY8946+VcPbKzZlYBIzQph/nHmd2KsNgO+W8= X-Received: by 2002:a0c:9e0f:: with SMTP id p15mr38738254qve.178.1553956664041; Sat, 30 Mar 2019 07:37:44 -0700 (PDT) MIME-Version: 1.0 References: <20190330164628.138a2bad@rimwks> In-Reply-To: <20190330164628.138a2bad@rimwks> From: Darius Mihai Date: Sat, 30 Mar 2019 16:37:06 +0200 Message-ID: Subject: Re: Boot hang on ryzen based notebook To: Rozhuk Ivan Cc: freebsd-hackers@freebsd.org, amd64@freebsd.org, current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 69D598A4B3 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; TAGGED_RCPT(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Sat, 30 Mar 2019 14:37:45 -0000 On Sat, Mar 30, 2019 at 3:49 PM Rozhuk Ivan wrote: > > Hello! > > Cant boot on ASUS VivoBook 15 X505ZA (AMD Ryzen 5 2500U) > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236899 > Sreenshot: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203257 > > Any ideas how to start? > Hello, I haven't actually tried with FreeBSD, but Linux also seems to have a similar problem that can be fixed by disabling ACPI. See 11.13.2.3 in https://www.freebsd.org/doc/handbook/acpi-overview.html and tell us how it works. Darius From owner-freebsd-hackers@freebsd.org Sat Mar 30 16:25:31 2019 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 757F51556EC2; Sat, 30 Mar 2019 16:25:31 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E04B8E291; Sat, 30 Mar 2019 16:25:30 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id CDE29C5039; Sat, 30 Mar 2019 10:26:21 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id etS3ViRfcMeW; Sat, 30 Mar 2019 10:26:21 -0600 (MDT) Received: from photon.int.bluestop.org (unknown [65.103.231.197]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA; Sat, 30 Mar 2019 10:26:21 -0600 (MDT) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> From: Rebecca Cran Message-ID: Date: Sat, 30 Mar 2019 10:25:27 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 8E04B8E291 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.72 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bluestop.org:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.98)[ip: (-9.86), ipnet: 65.100.0.0/14(-4.90), asn: 209(-0.06), country: US(-0.07)]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bluestop.org:+]; MX_GOOD(-0.01)[cached: mail.bluestop.org]; DMARC_POLICY_ALLOW(-0.50)[bluestop.org,quarantine]; NEURAL_HAM_SHORT(-0.73)[-0.732,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:209, ipnet:65.100.0.0/14, country:US]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[] 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: Sat, 30 Mar 2019 16:25:31 -0000 On 3/24/19 5:57 PM, Warner Losh wrote: > > He's asking for stopping doing a make install in src/stand. I'm thinking > that's a good thing. We should update the ESP's \efi\freebsd\loader.efi, > but leave the\efi\boot\bootXXXX.efi alone as part of this new installloader > phase. Again, only if the ESP is mounted, and we have a default spot for > it. For this script, I don't think hunting for the ESP is the right way to > go... which means we need to define a standard place for the ESP to be > mounted, which we should do before we turn on any of these features. I booted openSUSE Tumbleweed last night on my ASUS ROG Zenith Extreme board for the first time in a while and updated it to the latest revision. This morning I went to boot into FreeBSD and the "FreeBSD" boot entry had disappeared! Fortunately I have rEFInd installed so I could select the "UEFI OS" entry and get back into FreeBSD, but that's another reason we need to be really careful about relying too heavily on the boot manager variables. -- Rebecca Cran From owner-freebsd-hackers@freebsd.org Sat Mar 30 17:06:29 2019 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 5D82315585DC for ; Sat, 30 Mar 2019 17:06:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F24048FA14 for ; Sat, 30 Mar 2019 17:06:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x833.google.com with SMTP id k14so6276916qtb.0 for ; Sat, 30 Mar 2019 10:06:28 -0700 (PDT) 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=et1HN7DwT/JyZLbP775T3iyUFGmQl0xx+NK+/h0gV2I=; b=g6/7Vkf8iyHZ2rIJcOXHS6XiGSxhkJo2h5Rf0YJeLu0WeC6s43MF6PO3W4n1CPl+Rt 1uufOz7Tmfa/zPgyZy1QovtVHSWj6Mny5kgKc84OLyiwmB7wW3a6OOxI2f5stWIRInSf Ell/aU6ddYb+l7HU6yPGc2K3UADHXdxyOoQhZONUIYAUSo1yQ708ezvzhUmzBKc25We7 bQG3XbFPYCPo+UDdvXTShuf7t8aTgFuB6WnJ4KZHRb5SAoangpUEYSiyBZWieGklKung jZp4LlRcUhpZ3RF4p1ZerKMLwhuWS/u15cd8nWqf9LUpxf0zx9nbCeGA+ECin6bVbFz/ NrhQ== 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=et1HN7DwT/JyZLbP775T3iyUFGmQl0xx+NK+/h0gV2I=; b=ASiLBR8TSpphp8Om6hhutauZTDWcohPsOH9jypD+rR3iELJ+6CuNgBGSh20LUJM6JR 8+ustZBlFzFyz3klls9bkDiX0fSiM+wflqrltFAxkmKaLyXFWG5TTXsLt0HZ22/cSOPv 4hhgGblxJLm1bHo72oc1P76l+SCMoXJmgPPfQk7InAc7JPmYTq24YQiEz/+oHTkXYwob 2r/+hStSOI4Rksw7TFxl+6tXo8B10pQ15Mn978fMFCkP8hNjKcQz4r3k5BOT6ojkEtTX Yagy7r+GxxfBDZa+VtmwwKyooVa4ndJ5vn2jbGrb0DpiFwbT4cnptPhHfY2HyySRtSQe VWuw== X-Gm-Message-State: APjAAAWvBigYmCsLcFqQqXxCGVrEsTpfWrknBY+SongKJBXIp4lpiR0K eX1yxZjokwe07gkNRccDsjutatoduAHMcuPiw2EOuA== X-Google-Smtp-Source: APXvYqw+D95+G3+bXNsxb12Mpx73isbklS3fQNTeAlrc/qOoW4tYVtGpBRZwiuIfcV33ebVJ8gDCVDCVQTmOYaQrJLY= X-Received: by 2002:a0c:b501:: with SMTP id d1mr46600040qve.115.1553965588180; Sat, 30 Mar 2019 10:06:28 -0700 (PDT) MIME-Version: 1.0 References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> In-Reply-To: From: Warner Losh Date: Sat, 30 Mar 2019 11:06:16 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Rebecca Cran Cc: Konstantin Belousov , FreeBSD Hackers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: F24048FA14 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.95)[-0.945,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Sat, 30 Mar 2019 17:06:29 -0000 On Sat, Mar 30, 2019 at 10:25 AM Rebecca Cran wrote: > On 3/24/19 5:57 PM, Warner Losh wrote: > > > > He's asking for stopping doing a make install in src/stand. I'm thinking > > that's a good thing. We should update the ESP's \efi\freebsd\loader.efi, > > but leave the\efi\boot\bootXXXX.efi alone as part of this new > installloader > > phase. Again, only if the ESP is mounted, and we have a default spot for > > it. For this script, I don't think hunting for the ESP is the right way > to > > go... which means we need to define a standard place for the ESP to be > > mounted, which we should do before we turn on any of these features. > > > I booted openSUSE Tumbleweed last night on my ASUS ROG Zenith Extreme > board for the first time in a while and updated it to the latest > revision. This morning I went to boot into FreeBSD and the "FreeBSD" > boot entry had disappeared! Fortunately I have rEFInd installed so I > could select the "UEFI OS" entry and get back into FreeBSD, but that's > another reason we need to be really careful about relying too heavily on > the boot manager variables. > I understand that. However, boot manager variables are the standard, and are the first thing we should use. Having alternatives has already been established for the crazy arm environments that can't be bothered to implement write. There are limits, however, to how much of the crazy can be contained here, and how far we can go without hitting serious 'make a guess' territory that jeopardizes the ability to do something complicated for people that need to have multiple things that look like they might be bootable, but prefer one over the other (the most common case of this is nanobsd's ping-pong upgrade, though there are others). Do you know why the FreeBSD entry disappeared? Was it something that the BIOS did? Was it a bug / feature in openSUSE? You installer rEFInd, so maybe that did something naughty. It would be great to know how this came to pass by recreating it. But all of that is orthogonal to the ask that we separate out the boot loader installation from the world, which implies we need to finally standardize on an ESP mount point and likely other things as well. Warner From owner-freebsd-hackers@freebsd.org Sat Mar 30 17:41:43 2019 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 9ED4B155AE19; Sat, 30 Mar 2019 17:41:43 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C35C6D4C3; Sat, 30 Mar 2019 17:41:43 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-ed1-x536.google.com with SMTP id s39so4698320edb.2; Sat, 30 Mar 2019 10:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=DhHeNY5AmT7hQJSIU5Os4UVWoncZPDvcqGg0ARzqQ2I=; b=harjSURu3vCYYSBVa8YH3iXVMs2vbMqga/MlAp49ZYqi0X2Lq4hH8/2RasrXc+O+K3 CMWlAw9QLCwVVHkKvyGDKaTbplpLoSthJ6UDoQvWR0+cQmsgPGmIAv9lKwQMqT3WtFq7 6Ja9p6b4TFn2AsRoDQ1x7SLJ8/9Xfwhn5fuFUy2FnSjKUBmQ9isxqVrm+zJuDJsAJ2zN oXQQRspksjH7jM7bFAIGSm3cH8DXyVuZbTuI+FG+tjNHZtQjpGARlnOwhMMjt2f1Lkrt NwmHi9wlIzS6HqhCR3vUjrc/8bknCzUfNj4xe1OD7I32olcatE6b0fNhWCaGjT69TCqd TRVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=DhHeNY5AmT7hQJSIU5Os4UVWoncZPDvcqGg0ARzqQ2I=; b=BrhNRdA6vmQMGawQCHHbigUT7MhT0yzgOBlhGg/pSZQCRbTQtv27tqJwnHuaXDz8NG un4wZnlMrIQGZvjZPwQagWLlMGsHnB7iIdOZC/SSnAc9w4pfAVD48rx7fnRiDZJuRxB7 VUhl3mocah+LgaL5kxnD896GVjiGGLPltg6eKPkC6XA59tvrmxLLMWP/TYFEHNyQFfyG fULYOvUsogaMeJm8Aj3Rb0cN6+2w4is+cOl7wA92CpqP/+r+65uRHH/r0p2GGDCoPvCj L1FyVwHxel/3DCXcogfsodCiIRtsaXayRMS1g6qgfBeYJopfMNCl8PFWV6BPjOyDtjGV inNA== X-Gm-Message-State: APjAAAVhpi8s3JoO9Lsv59Ck9SF+KD4tfO9m03jOLkwvjY3MwOVIfvpL QNH+B28JUyuG2Q/Y6aepZ++7unnw X-Google-Smtp-Source: APXvYqxtx2eDOiw660GJq7l6aBFyqdeFYZkaGpFKyoOZFKkhlJVAQAjM3TPDPZeUwYTjOpoK3H6aVw== X-Received: by 2002:a50:b482:: with SMTP id w2mr36967086edd.41.1553967701036; Sat, 30 Mar 2019 10:41:41 -0700 (PDT) Received: from rimwks ([2001:470:1f15:3d8:c95:8c12:4f5f:87ba]) by smtp.gmail.com with ESMTPSA id b2sm1678500eda.36.2019.03.30.10.41.39 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sat, 30 Mar 2019 10:41:40 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sat, 30 Mar 2019 20:41:38 +0300 To: Darius Mihai Cc: freebsd-hackers@freebsd.org, current@freebsd.org Subject: Re: Boot hang on ryzen based notebook Message-ID: <20190330204138.18fe8443@rimwks> In-Reply-To: References: <20190330164628.138a2bad@rimwks> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1C35C6D4C3 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Sat, 30 Mar 2019 17:41:43 -0000 On Sat, 30 Mar 2019 16:37:06 +0200 Darius Mihai wrote: > I haven't actually tried with FreeBSD, but Linux also seems to have a > similar problem that can be fixed by disabling ACPI. > See 11.13.2.3 in > https://www.freebsd.org/doc/handbook/acpi-overview.html and tell us > how it works. > Panic with hint.apic.0.disabled="1": https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203260&action=edit I try also hw.mca.enabled=0, but it panic on cpu_initclocks_bsp(). - "No usable event timer found!" From owner-freebsd-hackers@freebsd.org Sat Mar 30 17:49:45 2019 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 BEDC4155B47C; Sat, 30 Mar 2019 17:49:45 +0000 (UTC) (envelope-from dariusmihaim@gmail.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 "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E0546DC96; Sat, 30 Mar 2019 17:49:45 +0000 (UTC) (envelope-from dariusmihaim@gmail.com) Received: by mail-qt1-x82e.google.com with SMTP id v32so6042035qtc.10; Sat, 30 Mar 2019 10:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sJlVgL9LYT/CI+4UuX/GBuxGQBA6VOtcd0Ptk5gamsA=; b=auCL8YV3HfVFI9Ry5uCAJ9M9Y9bgjhhnTGmYv8S1zdiP0yuHvkZ0p5qiJbGUSHxNlh R7nwMpf2x03Ml2fE08xtImr9CTj0A4wlTyj/bI+E/Oq1SsqTWB4m3DSaJ7u8eWZj/kVJ WmvEbyt+GCzMo6Wi+FJxizhRAhDu1yXVQh80HMtRsK31B6GX730ukL0o+gGtIfKAASwL u4D6bbwX3R3rROncLSLIz9jS/2uYr4+VMsTeRTJxasdoiaUR9/66wsJJ93J87ZOrmaBq 7hihwY0FbluoKj04rFXX8L9fh8mG32CasIGL+24/BN4sZfoBUEPclRl0ytyhbckwId/h aU7g== 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=sJlVgL9LYT/CI+4UuX/GBuxGQBA6VOtcd0Ptk5gamsA=; b=nsNQvF5xRTeRF3tZTzRW4J6qEXOJszCuDRTlWlDV1dp4ILEytDWbY/IYHqZB77KNY9 wwjRpEf7oNYYNkIFAG1CIjNMinteGTsvDC5xhttqmnr7hFvRPglL7cHGflklsjqDwCFq csKUq0kdIXnoPCAuSmBODtBt5fIYaKviq4NV61k990QQWkuzhmz+kB2hk0xnHxNNTR2z oA0fx/XaXvMvQtYMtlvmz2R5GdmyWTg9/hCsqRlMBRt+SylE2ZZ7RD2CWxjiqsIHJd6D zBX2lwHOIaGZLs+jPYgGkGnRpPyA7F7dfc9Qp0qaMmw8sjHk5aQYdeykSpYyNr1ruh21 wgQA== X-Gm-Message-State: APjAAAUkCOq/DCId31PrtND3Wp4HkKl9ruL5KRaS1NpOM1vDYBdpKXR4 UCgECT1QHH53AtXkM1wTrDT7HOd2CxdZStQUdTi0aw== X-Google-Smtp-Source: APXvYqyGJAqc5XgVaoj4pNcMRb4WAHGQiK6BE4q1hERN0WpkVwEq8Ar/yw4MpjE1MV92+vrfCvZ1TYnEgp98T+yW/84= X-Received: by 2002:ac8:34a2:: with SMTP id w31mr48654639qtb.164.1553968184759; Sat, 30 Mar 2019 10:49:44 -0700 (PDT) MIME-Version: 1.0 References: <20190330164628.138a2bad@rimwks> <20190330204138.18fe8443@rimwks> In-Reply-To: <20190330204138.18fe8443@rimwks> From: Darius Mihai Date: Sat, 30 Mar 2019 19:49:06 +0200 Message-ID: Subject: Re: Boot hang on ryzen based notebook To: Rozhuk Ivan Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 5E0546DC96 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.90)[-0.902,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] 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: Sat, 30 Mar 2019 17:49:45 -0000 On Sat, Mar 30, 2019 at 7:41 PM Rozhuk Ivan wrote: > > On Sat, 30 Mar 2019 16:37:06 +0200 > Darius Mihai wrote: > > > > I haven't actually tried with FreeBSD, but Linux also seems to have a > > similar problem that can be fixed by disabling ACPI. > > See 11.13.2.3 in > > https://www.freebsd.org/doc/handbook/acpi-overview.html and tell us > > how it works. > > > > Panic with hint.apic.0.disabled="1": > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203260&action=edit > > I try also hw.mca.enabled=0, but it panic on cpu_initclocks_bsp(). - "No usable event timer found!" You wrote "apic.0.disabled", not "acpi.0.disabled". Are you sure you wrote the correct command? You do not want to disable the APIC (interrupt controller), but the ACPI (control and power interface). On a side note, you wrote "current@freebsd.org", so I've added "freebsd-current@freebsd.org" (I hope that's what you originally meant). Darius From owner-freebsd-hackers@freebsd.org Sat Mar 30 18:09:02 2019 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 E5B55155C256 for ; Sat, 30 Mar 2019 18:09:01 +0000 (UTC) (envelope-from plmahan@gmail.com) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 109B96EAF9 for ; Sat, 30 Mar 2019 18:09:01 +0000 (UTC) (envelope-from plmahan@gmail.com) Received: by mail-ua1-x930.google.com with SMTP id p13so1752328uaa.11 for ; Sat, 30 Mar 2019 11:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2FDhXH/JwXK6GRFNrfOhGjwkN4QrHaR6jg7hPHjLswE=; b=Q2egU/PCKtrp1+E0UjO/Em8KdHOGLozXUx2ySkTuqWokGTybpJ004+HS4sDHvZHx7r v3WOtg2OdGcJHKnf7yFR8ORNDog551oeX9O5oZzVeEc/lVa6pUIdE5SqJiitDxtJl7fa w2u4Gu/9cGqOPT/EUJbmBrnm8zdJgOBXfpZAHejYQOvX8tWLTEeBi6sZc/areGLqGq7I syqtD9VqJDQs6JDP22Ann61m0BrRYiIL7paVq9JUgi2/TuyjRDc5Sa3yHSjjN8Ij9cEh 554HuRCXrSs8W2nj9EIm+QPX6XlQKHp9JThDVJJb8tRjuR7UVrZ5GIU+s4azzW20syQb 3sgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2FDhXH/JwXK6GRFNrfOhGjwkN4QrHaR6jg7hPHjLswE=; b=UDjU1/hQxF41CJoZr+3X2cEfB16AwZFfPCPC16cC9qzDEb3vNb73lkun3CxpSJ/HNf YuIBcBqFCD+b5AnRdXnYLxk1TtOIZP2nJ4Itd1BDBY2HmB2QEr2b4d/ykbCRFhnW9aim pgVkvSvWVSjUm1C7tnmzsTWWr2NQq2RnA6KhGOIUWDxy0tdlX9lhm1mh+b+QgI1uS2kk TLzc3Kz3OvloVOP92mTHK0YA8LtbJ2ouQbgqGpcrdOxyo8VdszLRE4RYDeU8J+niRUY1 KiwSsdgS4d3VjOTnJGK82ttxECs3syLVCoVqjnFH2LlA89JV5YmIOluVqr417qF6HmSf sA8Q== X-Gm-Message-State: APjAAAXZKSIzlpk2JqPMEDa35ZM0Les189v0x/XkE3r5/oO6Ba5mrVa5 qyAg0BF73gLutZJmhTgp0nY/kHw2w9JN90eC5/lS9g== X-Google-Smtp-Source: APXvYqwrAY5GFlImV3srhaQSTYWRHxCg1+Az23+gnyUfiqLRfNDEP90rYfCYm+FBVIB36XgndAgGd4NrE9Ub448UQpU= X-Received: by 2002:ab0:4e07:: with SMTP id g7mr22135865uah.111.1553969340174; Sat, 30 Mar 2019 11:09:00 -0700 (PDT) MIME-Version: 1.0 From: Patrick Mahan Date: Wed, 27 Mar 2019 22:20:20 -0700 Message-ID: Subject: Skipping installworld To: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 109B96EAF9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Q2egU/PC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of plmahan@gmail.com designates 2607:f8b0:4864:20::930 as permitted sender) smtp.mailfrom=plmahan@gmail.com X-Spamd-Result: default: False [-4.21 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; URI_COUNT_ODD(1.00)[1]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.27)[-0.269,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DATE_IN_PAST(1.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.93)[ip: (-9.56), ipnet: 2607:f8b0::/32(-2.88), asn: 15169(-2.14), country: US(-0.07)]; RCVD_IN_DNSWL_NONE(0.00)[0.3.9.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]; RCVD_COUNT_TWO(0.00)[2] 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: Sat, 30 Mar 2019 18:09:02 -0000 All, FreeBSD 11.2-RELEASE-p7 AMD64 I am trying to debug a PAM/dovecot issue and want to add some more detail debugging to the PAM code. Do I really need to do an installworld just to install the changed PAM module (pam_unix.so) or can I safely copy it by hand? Thanks, Patrick From owner-freebsd-hackers@freebsd.org Sat Mar 30 18:17:44 2019 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 777A6155C8A1; Sat, 30 Mar 2019 18:17:44 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1004F6F124; Sat, 30 Mar 2019 18:17:43 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lj1-x232.google.com with SMTP id y6so4617571ljd.12; Sat, 30 Mar 2019 11:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=5dI91p53lF/pusBwo+1mTpqLUPv1OOI3WDIjBTcnMQE=; b=VJ/VgQEVOzCpHqZXVq9buNmPByJFMpfEIdwLlz0XiXAWrD/uqssFXnn9TU1FrnS5EE iqrzQxaOzk+mOAF4Nmh9Euqj7QxB535oiNoEp5aikzt9eBeu7C11bz85cDG/AMKmYXlu gBbDR9eTSQnoIvSG8+NBcfX5AJARlZp5cvA1jZv7mlUyaqJNX2PzNp9slYAvXZMRU+0U qa/xKNCHqTz9Tsv2ux0zTUOwsnwHWwgud5V0GIbAe02jLi/3/NLde7ohXSbF/QrTKG0H EFv/gNRS+O93ODZuKAdWY4hcen3dDqQ8G5H7BKugpzFvgWuwm+wMhOx4mfNp1uWplvlk G2UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=5dI91p53lF/pusBwo+1mTpqLUPv1OOI3WDIjBTcnMQE=; b=XZfiTA5v+5+VntzisbUKM5pzE8ReOKHW0IVp8HrtmIVqt7PkjhSlb0/Iqs0MVvI8sg NonhJLpuXhCb9dwYegAS5LoXeFv9PLK6MpP/UgeCG8nbGgNEgsmkSd38kIySDfwmrKhj WdsVn9JM/A8aGi3wchUvq0xHcbD39wMnP/A26iKiqiUm8/PcxBgEA57Ajh6627szhtsu FqlzdxWIgu6PDonRw2OmTu+vfyW7LNSVOj/0MzFV2JY9RFH0QeclNDASUUqNwuQ0bw7t l1bEBleWDEhKO5zmhZRCIWK9+1apbzQwQX/Rb30cabHTM5RkvBgWUZmlJTKJAhkXw8kA TYFw== X-Gm-Message-State: APjAAAVdlNhQHYHstawVl8/Pq/kirdxIwMi2IMjiDZnUTVQ86DkfNlOw X56TkCf56N4qXcrt1kEW+LNR2NcT X-Google-Smtp-Source: APXvYqwSOBCKmbYKBzuBtyokWhr+nea3MMSUpTjKLvAqXgWBsm+M4TLiZleQba6p/FlGHWjmNj3E/g== X-Received: by 2002:a2e:9649:: with SMTP id z9mr12204282ljh.92.1553969861611; Sat, 30 Mar 2019 11:17:41 -0700 (PDT) Received: from rimwks ([2001:470:1f15:3d8:c95:8c12:4f5f:87ba]) by smtp.gmail.com with ESMTPSA id l21sm916437lfh.30.2019.03.30.11.17.39 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sat, 30 Mar 2019 11:17:40 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sat, 30 Mar 2019 21:17:36 +0300 To: Darius Mihai Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Boot hang on ryzen based notebook Message-ID: <20190330211736.05b39193@rimwks> In-Reply-To: References: <20190330164628.138a2bad@rimwks> <20190330204138.18fe8443@rimwks> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1004F6F124 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=VJ/VgQEV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::232 as permitted sender) smtp.mailfrom=rozhukim@gmail.com X-Spamd-Result: default: False [-5.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.74)[-0.744,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.74)[ip: (-9.13), ipnet: 2a00:1450::/32(-2.36), asn: 15169(-2.14), country: US(-0.07)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.3.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MID_RHS_NOT_FQDN(0.50)[] 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: Sat, 30 Mar 2019 18:17:44 -0000 On Sat, 30 Mar 2019 19:49:06 +0200 Darius Mihai wrote: > > > I haven't actually tried with FreeBSD, but Linux also seems to > > > have a similar problem that can be fixed by disabling ACPI. > > > See 11.13.2.3 in > > > https://www.freebsd.org/doc/handbook/acpi-overview.html and tell > > > us how it works. > > > > > > > Panic with hint.apic.0.disabled="1": > > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203260&action=edit > > > > I try also hw.mca.enabled=0, but it panic on cpu_initclocks_bsp(). > > - "No usable event timer found!" > > You wrote "apic.0.disabled", not "acpi.0.disabled". Are you sure you > wrote the correct command? You do not want to disable the APIC > (interrupt controller), but the ACPI (control and power interface). hint.acpi.0.disabled="1" - 11.13.1. Then set: panic: running without device atpic requires a local APIC From owner-freebsd-hackers@freebsd.org Sat Mar 30 19:51:02 2019 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 91243156048C; Sat, 30 Mar 2019 19:51:02 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A80F7337D; Sat, 30 Mar 2019 19:51:02 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id DEF6F16054; Sat, 30 Mar 2019 20:50:52 +0100 (CET) Date: Sat, 30 Mar 2019 20:51:41 +0100 From: Steffen Nurpmeso To: Rebecca Cran via freebsd-hackers Cc: Warner Losh , Konstantin Belousov , "freebsd-arch@freebsd.org" Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" Message-ID: <20190330195141.2HVp7%steffen@sdaoden.eu> In-Reply-To: References: <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> Mail-Followup-To: Rebecca Cran via freebsd-hackers , Warner Losh , Konstantin Belousov , "freebsd-arch@freebsd.org" User-Agent: s-nail v14.9.13-32-g7e84ad8b OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 2A80F7337D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.91 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.91)[-0.907,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Sat, 30 Mar 2019 19:51:02 -0000 Rebecca Cran via freebsd-hackers wrote in : |On 3/24/19 5:57 PM, Warner Losh wrote: ... |boot entry had disappeared! Fortunately I have rEFInd installed so I |could select the "UEFI OS" entry and get back into FreeBSD, but that's |another reason we need to be really careful about relying too heavily on |the boot manager variables. Thanks for bringing this name up. Maybe FreeBSD should pass some donations through to this rEFIt successor and start execution where that one ends. I have always been living in fear of using those badly documented Free(and other)BSD boot things, for true multiboot etc. i always had to end up with lilo or (horrors!) grub2. I can tell stories of systems where the Debian grub messed up freebsd booting, and the FreeBSD grub port only found freebsd. This is only fun for i-do-not-know-who, but anyway these have a vivid internet connection and multiple boxes available. I finally have found a home with syslinux and refit/refind. (Which is still very picky when you mess up configuration entries. For example it will find anything and include a manually entered configuration, but if you mess up the latter it will just break.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-hackers@freebsd.org Sat Mar 30 20:15:20 2019 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 B87EE15614DF for ; Sat, 30 Mar 2019 20:15:20 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6860974BF1 for ; Sat, 30 Mar 2019 20:15:19 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f174.google.com with SMTP id v13so4793032ljk.4 for ; Sat, 30 Mar 2019 13:15:19 -0700 (PDT) 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=YEeHXYUN/oNnlqS2jemVz6AZNFM0YV1OaynMk1wg4jo=; b=XVGttmyzBtd28wPJvIxM22vw0HyjmcOts8ysz+M6xpwu/FGd+5fTKqZsuXsbfP8CSj UOqopNRVlV2zZ1fWQs149HmGLUaMQVB1Qog1jS6FziSRIG0Ff/imOsuredSIbMZRI2NL Vii18qc12m/XnohMhiV3Ww8TvxxYwl4F8Y49EN2Pie2rMDdm+SU/GMmMcDAYfmtDF578 STHx6A2so1p018LmV+TLUIZfhpa6yczl0fbkPituWjSTWv3AlZG7wFXomPaL8JRh2Mak s4uUkJ4wL93jF6petE0Ui5rnT2xtoNHgiQkLNAGncQH4V3aZB71O7nJRxBAEUxiCcxmf leOw== X-Gm-Message-State: APjAAAXiQZzFH3sla1A6Q/nE/s/qMjp6yLzFIKZ4roKP9IowyFkerSLe //kZH2OgGN10mVM+P3exS6M4iGeuBAwnxeE6Wik= X-Google-Smtp-Source: APXvYqyBEUNCw7znUkFl+4rsGMLT1l3SUQsjnIvCFQEB/hkWKS2JKsQuGCvNDGPOedlsXR5UhBX1LMhqfW25ur74nAA= X-Received: by 2002:a2e:9703:: with SMTP id r3mr3386279lji.88.1553976912626; Sat, 30 Mar 2019 13:15:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sat, 30 Mar 2019 14:15:00 -0600 Message-ID: Subject: Re: Skipping installworld To: Patrick Mahan Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 6860974BF1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.174 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-4.12 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[174.208.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.80)[-0.795,0]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; IP_SCORE(-1.31)[ip: (-0.49), ipnet: 209.85.128.0/17(-3.87), asn: 15169(-2.14), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] 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: Sat, 30 Mar 2019 20:15:20 -0000 On Sat, Mar 30, 2019 at 12:09 PM Patrick Mahan wrote: > > All, > > FreeBSD 11.2-RELEASE-p7 AMD64 > > I am trying to debug a PAM/dovecot issue and want to add some more detail > debugging to the PAM code. Do I really need to do an installworld just to > install the changed PAM module (pam_unix.so) or can I safely copy it by > hand? > > Thanks, > > Patrick No need to do an installworld. You can safely do a "make && make install" from the lib/libpam directory. Just make sure that you build from the correct source tree for your release. -Alan From owner-freebsd-hackers@freebsd.org Sat Mar 30 20:50:42 2019 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 B5F111563147 for ; Sat, 30 Mar 2019 20:50:42 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 7EC6A76D72 for ; Sat, 30 Mar 2019 20:50:41 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id x2UKa6Mw012379 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Mar 2019 21:36:06 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id x2UKa1Ek012376; Sat, 30 Mar 2019 21:36:01 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Date: Sat, 30 Mar 2019 21:36:01 +0100 (CET) From: Wojciech Puchar To: Patrick Mahan cc: freebsd-hackers@freebsd.org Subject: Re: Skipping installworld In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 7EC6A76D72 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-6.75 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[puchar.net]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[90.144.1.194.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_SHORT(-0.87)[-0.869,0]; IP_SCORE(-3.57)[ip: (-9.42), ipnet: 194.1.144.0/24(-4.71), asn: 43476(-3.77), country: PL(0.05)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] 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: Sat, 30 Mar 2019 20:50:42 -0000 you may simply build any part of source with make and install in with make install. or copy selected files (those you want to replace) manually On Wed, 27 Mar 2019, Patrick Mahan wrote: > All, > > FreeBSD 11.2-RELEASE-p7 AMD64 > > I am trying to debug a PAM/dovecot issue and want to add some more detail > debugging to the PAM code. Do I really need to do an installworld just to > install the changed PAM module (pam_unix.so) or can I safely copy it by > hand? > > Thanks, > > Patrick > _______________________________________________ > 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" > > From owner-freebsd-hackers@freebsd.org Sat Mar 30 21:12:27 2019 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 3E6491563E2D for ; Sat, 30 Mar 2019 21:12:27 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 210AE8007A for ; Sat, 30 Mar 2019 21:12:25 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2ULCOcD006832; Sat, 30 Mar 2019 14:12:24 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2ULCOYF006831; Sat, 30 Mar 2019 14:12:24 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903302112.x2ULCOYF006831@gndrsh.dnsmgr.net> Subject: Re: Skipping installworld In-Reply-To: To: Wojciech Puchar Date: Sat, 30 Mar 2019 14:12:24 -0700 (PDT) CC: Patrick Mahan , freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 210AE8007A X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [0.33 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.52)[-0.524,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.01)[ip: (0.08), ipnet: 69.59.192.0/19(0.04), asn: 13868(0.02), country: US(-0.07)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.08)[0.082,0]; NEURAL_HAM_LONG(-0.13)[-0.128,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[] 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: Sat, 30 Mar 2019 21:12:27 -0000 > you may simply build any part of source with make and install in with make > install. or copy selected files (those you want to replace) manually This works less and less as time has moved on. And the foot shooting gets to be a larger and larger thing, especially if you are modifying or patching any thing. > On Wed, 27 Mar 2019, Patrick Mahan wrote: > > > All, > > > > FreeBSD 11.2-RELEASE-p7 AMD64 > > > > I am trying to debug a PAM/dovecot issue and want to add some more detail > > debugging to the PAM code. Do I really need to do an installworld just to > > install the changed PAM module (pam_unix.so) or can I safely copy it by > > hand? > > > > Thanks, > > > > Patrick > > _______________________________________________ > > 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" > > > > > _______________________________________________ > 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" > -- Rod Grimes rgrimes@freebsd.org