From owner-freebsd-stable@freebsd.org Sun Jul 12 06:28:50 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DECC13597BE for ; Sun, 12 Jul 2020 06:28:50 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from mx.sdf.org (mx.sdf.org [205.166.94.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.sdf.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4H0x1k3dz4BDl for ; Sun, 12 Jul 2020 06:28:49 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from sdf.org (IDENT:bennett@miku.sdf.org [205.166.94.6]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 06C6SfV5017848 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sun, 12 Jul 2020 06:28:42 GMT Received: (from bennett@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 06C6SfNB015907; Sun, 12 Jul 2020 01:28:41 -0500 (CDT) From: Scott Bennett Message-Id: <202007120628.06C6SfNB015907@sdf.org> Date: Sun, 12 Jul 2020 01:28:41 -0500 To: freebsd-stable@freebsd.org Subject: Re: swap space issues Cc: "Peter Jeremy Donald Wilde" User-Agent: Heirloom mailx 12.5 6/20/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B4H0x1k3dz4BDl X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.25 / 15.00]; FAKE_REPLY(1.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:205.166.94.0/24]; NEURAL_HAM_LONG(-1.01)[-1.011]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.03)[-1.025]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.42)[-0.418]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[sdf.org,quarantine]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14361, ipnet:205.166.94.0/24, country:US]; FREEMAIL_CC(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 06:28:50 -0000 I have read this entire thread to date with growing dismay, and I thank Donald Wilde for reporting his ongoing troubles, although they spoil my hopes that the kernel's memory management bugs that first became apparent in 11.2-RELEASE (and -STABLE around the same time) were not propagated into 12.x. A recent update to stable/12 source tree made it finally possible for me to build 12.1-STABLE under 11.4-PRERELEASE, and I was just about to install the upgrade when this thread appeared. On Fri, 26 Jun 2020 03:55:04 -0700 : Donald Wilde wrote: >On 6/26/20, Peter Jeremy wrote: >> On 2020-Jun-25 11:30:31 -0700, Donald Wilde wrote: >>>Here's 'pstat -s' on the i3 (which registers as cpu HAMMER): >>> >>>Device 1K-blocks Used Avail Capacity >>>/dev/ada0s1b 33554432 0 33554432 0% >>>/dev/ada0s1d 33554432 0 33554432 0% >>>Total 67108864 0 67108864 0% >> >> I strongly suggest you don't have more than one swap device on spinning >> rust - the VM system will stripe I/O across the available devices and >> that will give particularly poor results when it has to seek between the >> partitions. True. The only reason I can think of to use more than one swapping/ paging area on the same device for the same OS instance is for emergencies or highly unusual, temporary situations in which more space is needed until those situations conclude. and even in such situations, if the space can be found on another device, it should be placed there. Interleaving of swap space across multiple devices is intended as a performance enhancement akin to striping (a.k.a. RAID0), although the virtual memory isn't necessarily always actually striped across those devices. Adding a paging area on the same device as an existing one is an abhorrent situation, as Peter Jeremy noted, and it should be eliminated via swapoff(8) as soon as the extraordinary situation has passed. N.B. the GENERIC kernel sets a limit of four swap devices, although it can be rebuilt with a different limit. > >My intent is to make this machine function -- getting the bear >dancing. How deftly she dances is less important than that she dances >at all. My for-real boxen will have real HP and real cores and RAM. > >> >> Also, you can't actually use 64GB swap with 4GB RAM. If you look back >> through your boot messages, I expect you'll find messages like: >> warning: total configured swap (524288 pages) exceeds maximum recommended >> amount (498848 pages). >> warning: increase kern.maxswzone or reduce amount of swap. Also true. Unfortunately, no guidance whatsoever is provided to advise system administrators who need more space as to how to increase the relevant table sizes and limits. However, that is a documentation bug, not a code bug. > >Yes, as I posted, those were part of the failure stream from the synth >program. When I had kern.maxswzone increased, it got through boot >without complaining. > >> or maybe: >> WARNING: reducing swap size to maximum of xxxxMB per unit > >The warnings were there, in the as-it-failed complaints. > >> The absolute limit on swap space is vm.swap_maxpages pages but the >> realistic >> limit is about half that. By default the realistic limit is about 4?RAM >> (on >> 64-bit architectures), but this can be adjusted via kern.maxswzone (which >> defines the #bytes of RAM to allocate to swzone structures - the actual >> space allocated is vm.swzone). >> >> As a further piece of arcana, vm.pageout_oom_seq is a count that controls >> the number of passes before the pageout daemon gives up and starts killing >> processes when it can't free up enough RAM. "out of swap space" messages >> generally mean that this number is too low, rather than there being a >> shortage of swap - particularly if your swap device is rather slow. >> >Thanks, Peter! A second round of thanks to Peter Jeremy for pointing out this sysctl variable (vm.pageout_oom_seq), although thus far I have yet to see that it is actually effective in working around the memory management bugs. I have added the following lines to /etc/sysctl.conf. # Because FreeBSD 11.{2,3,4} tie up page frames unnecessarily, set value high #vm.pageout_wakeup_thresh=14124 # Default value vm.pageout_wakeup_thresh=112640 # 410 MB Between the two changes, the pagedaemon *seems* to have stopped killing important processes (or others) for now, which is a huge improvement and relief. Too bad FreeBSD needs the changes to be made to keep the system usable somewhat longer. My system has 8 GB of real memory. The kernel apparently refuses to swap in *any* process, even one as small as /bin/sh, when the free page frame list has less that ~410 MB of page frames on it. Setting the vm.pageout_wakeup_thresh to at least 410 MB *seems* to help reduce the number of times a process that has been marked as swapped out when the system has been under some form of memory pressure, but it doesn't stop it from happening when the kernel has pagefixed far too many page frames and hasn't pagefreed them when no longer really requiring them to remain in real memory. I don't know whether the bug is one of illegitimately pagefixing or failure to pagefree, but eventually the number of page frames tied up becomes so high that too few frames remain available for the kernel to be willing to page processes back in to resume them. Increasing vm.pageout_wakeup_thresh drastically from its default value is the primary way I have found to extend the time that my system remains usable before I am forced to reboot. As mentioned previously, I am dismayed that 12.1 appears to contain at least some of 11.2+'s bugs. Given that 11.1 went EOL a long time ago, that means that there is presently *NO PRODUCTION RELEASE OF FREEBSD AVAILABLE* since 11.1-RELEASE, the FreeBSD project web site's erroneous claims notwithstanding. This is an awful situation and probably calls for some corrective action by the FreeBSD core team. A production release does not force a reboot every few days or even every month or two in order to remain usable. That's one of the reasons Windows through XP and VISTA were never production systems, even though Mico$lop gave its users no production alternatives. FreeBSD used to do better and it should be doing better now. It is worth noting that a few years ago, FreeBSD project staff realized that an elderly Pentium II(?) machine running FreeBSD 2.something and still doing some simple, but necessary, task for the project had an uptime in excess of 19 *years*. That is a reliability record for any OS to strive for. It is a shame that FreeBSD's quality control no longer results in anything close to that. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-stable@freebsd.org Sun Jul 12 14:24:04 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4AD1C364C29 for ; Sun, 12 Jul 2020 14:24:04 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4TYH24KRz4bJw for ; Sun, 12 Jul 2020 14:24:03 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-pl1-x62f.google.com with SMTP id x8so4346032plm.10 for ; Sun, 12 Jul 2020 07:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=RMuDBp+GGkoxrt3Sv9nknH47ITShFpJXhcA4ZUXzfXE=; b=daOibBevqrLDlDIVwIqW9ZzJmng+Lo98lAJbQafgMeUEeBr75Stg6T2Hy9/sjs2lnH oDCPFpRIjmb6MGb/dYZzqy9uibn1Rny2tve5hkw7gyonFJRJdViFh2PZMePs96BKcobg bIi9IRE+GWSnnSnqpPV5mYzXbt61RfF3Mh/mkGVVFA7tuTr6B5Lb3TlZC5uEbp8N7Y9C gzbY3Jg4SDsHEaih0/jYkC5lZFwvlTLi3hzIkUCc1L9DfRfQodAX7nGBjz3botp9L4Fv VgST44KE02zuji8L1Uw7ToqzAUPBJEJysm1HnjWOPX9kbKGrIgyQMpzMXOZeuNV0Urqz 36Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=RMuDBp+GGkoxrt3Sv9nknH47ITShFpJXhcA4ZUXzfXE=; b=ZbzOr5eP1YwayI9vj7ig2Br5D2JRgm9j+FFAtbNoYDjFQxgBknfJPKz6maNGisd/ZZ JmIptH6BaHSlz9updfADkMCPeLnGDoo4bCoU28TK10vWxv0sQRCWMQ8CQiOPyEa01FMu TuWPX+z4hhV3VTKYw8ZUOik8WHd3fpZtQhSQC0R7kASByzWxyhnOrhmHBa3lvUyGaaBG cuJo6G5gK5j6erYO4IbfPIbpCGXNcnv0Ot6+XWtY3DyLNSoaLcT5dIi++dZMCqYaPNIF ICYcGExSuSj7IsgaTNAzHGr13f6kZdqVIIHChqdbejoYMKhcsfhzwkuqMFbgbZIdW5E9 iGSg== X-Gm-Message-State: AOAM533zZlFvUfFh/XhzzCgbJbnTjkn5HG+F+c0P/RQPYoPo9XPq0+UI TyrGZ9BheQviMOZAsCDnL14UocuY X-Google-Smtp-Source: ABdhPJx0tjH32PpVJLaJlCEdYV8asPoDyEPvYqj9LvHdL820lrqI4cr8++domyNKQY0Kx8ehf65VyQ== X-Received: by 2002:a17:90b:3842:: with SMTP id nl2mr14889869pjb.111.1594563841024; Sun, 12 Jul 2020 07:24:01 -0700 (PDT) Received: from [192.168.0.4] (174-26-193-115.phnx.qwest.net. [174.26.193.115]) by smtp.gmail.com with ESMTPSA id k2sm10771260pgm.11.2020.07.12.07.23.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Jul 2020 07:24:00 -0700 (PDT) Subject: Re: swap space issues To: Scott Bennett , freebsd-stable@freebsd.org References: <202007120628.06C6SfNB015907@sdf.org> From: Don Wilde Message-ID: <3afe4d2f-3b1e-a1c5-f947-5f57800317a6@gmail.com> Date: Sun, 12 Jul 2020 07:23:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <202007120628.06C6SfNB015907@sdf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4B4TYH24KRz4bJw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=daOibBev; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2607:f8b0:4864:20::62f as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-3.55 / 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:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.48)[-0.478]; RECEIVED_SPAMHAUS_PBL(0.00)[174.26.193.115:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.048]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.019]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::62f:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 14:24:04 -0000 On 7/11/20 11:28 PM, Scott Bennett via freebsd-stable wrote: > I have read this entire thread to date with growing dismay, and I > thank Donald Wilde for reporting his ongoing troubles, although they > spoil my hopes that the kernel's memory management bugs that first became > apparent in 11.2-RELEASE (and -STABLE around the same time) were not > propagated into 12.x. A recent update to stable/12 source tree made it > finally possible for me to build 12.1-STABLE under 11.4-PRERELEASE, and I > was just about to install the upgrade when this thread appeared. Spoiler alert. Since I gave up on Synth, I haven't had a single swap issue. It does appear to be one particular port that drove it nuts (apparently, one of the 'Google performance' bits, with a mismatched-brackets problem). I have rebuilt the machine several times, but that's more for my sense of tidiness than anything. I've got a little Crystal script that walks the installed packages and ports and updates them with system() calls. The machine is very slow, but it's not swapping at all. It is quite usable now with 12-STABLE. > > On Fri, 26 Jun 2020 03:55:04 -0700 : Donald Wilde > wrote: > >> On 6/26/20, Peter Jeremy wrote: >>> [snip] >>> I strongly suggest you don't have more than one swap device on spinning >>> rust - the VM system will stripe I/O across the available devices and >>> that will give particularly poor results when it has to seek between the >>> partitions. > True. The only reason I can think of to use more than one swapping/ > paging area on the same device for the same OS instance is for emergencies > or highly unusual, temporary situations in which more space is needed until > those situations conclude. and even in such situations, if the space can be > found on another device, it should be placed there. Interleaving of swap > space across multiple devices is intended as a performance enhancement > akin to striping (a.k.a. RAID0), although the virtual memory isn't > necessarily always actually striped across those devices. Adding a paging > area on the same device as an existing one is an abhorrent situation, as > Peter Jeremy noted, and it should be eliminated via swapoff(8) as soon as > the extraordinary situation has passed. N.B. the GENERIC kernel sets a > limit of four swap devices, although it can be rebuilt with a different > limit. That's good data, Scott, thanks! The only reason I got into that situation of trying to add another swap device was that it was crashing with OO swap messages. >> My intent is to make this machine function -- getting the bear >> dancing. How deftly she dances is less important than that she dances >> at all. My for-real boxen will have real HP and real cores and RAM. >> >>> Also, you can't actually use 64GB swap with 4GB RAM. If you look back >>> through your boot messages, I expect you'll find messages like: >>> warning: total configured swap (524288 pages) exceeds maximum recommended >>> amount (498848 pages). >>> warning: increase kern.maxswzone or reduce amount of swap. > Also true. Unfortunately, no guidance whatsoever is provided to advise > system administrators who need more space as to how to increase the relevant > table sizes and limits. However, that is a documentation bug, not a code > bug. I've got both my kern.max* and CCACHE set up mostly correctly. Everything builds and runs well, although I've found that it's helpful to only use -j3 while building, not -j4 which would be appropriate for my HAMMER i3. I'd much rather have the bear *dancing* than running into walls. :D >> Yes, as I posted, those were part of the failure stream from the synth >> program. When I had kern.maxswzone increased, it got through boot >> without complaining. >> >>> or maybe: >>> WARNING: reducing swap size to maximum of xxxxMB per unit >> The warnings were there, in the as-it-failed complaints. >> >>> The absolute limit on swap space is vm.swap_maxpages pages but the >>> realistic >>> limit is about half that. By default the realistic limit is about 4?RAM >>> (on >>> 64-bit architectures), but this can be adjusted via kern.maxswzone (which >>> defines the #bytes of RAM to allocate to swzone structures - the actual >>> space allocated is vm.swzone). >>> >>> As a further piece of arcana, vm.pageout_oom_seq is a count that controls >>> the number of passes before the pageout daemon gives up and starts killing >>> processes when it can't free up enough RAM. "out of swap space" messages >>> generally mean that this number is too low, rather than there being a >>> shortage of swap - particularly if your swap device is rather slow. >>> >> Thanks, Peter! > A second round of thanks to Peter Jeremy for pointing out this sysctl > variable (vm.pageout_oom_seq), although thus far I have yet to see that it is > actually effective in working around the memory management bugs. I have added > the following lines to /etc/sysctl.conf. > > # Because FreeBSD 11.{2,3,4} tie up page frames unnecessarily, set value high > #vm.pageout_wakeup_thresh=14124 # Default value > vm.pageout_wakeup_thresh=112640 # 410 MB [snip] I do totally agree that these are crucial issues for both operation and documentation, although my issues stemmed from bad _userland_ stack control. Those who live on -CURRENT are used to OOPS, but the rest of us get paid not to have them. I am happy with what the Core Team gives us, AND of course we want ['more','better','faster','STABLE']. :D From owner-freebsd-stable@freebsd.org Sun Jul 12 19:40:15 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6ECAA36C66A for ; Sun, 12 Jul 2020 19:40:15 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4cZ62NXqz3gFq for ; Sun, 12 Jul 2020 19:40:13 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-oi1-x232.google.com with SMTP id e4so9304233oib.1 for ; Sun, 12 Jul 2020 12:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i1i0KaPoUmJb+zYjDjlufC0FkBtXwHz4Zap+UGwZ1yo=; b=o05MGJPukvC+MTNSj4E31x6yCf9GPc58l9emX5ZoF2/IuEbAcG/ywQ+yAXl7u6HX8T BzMEXZMBUnN7XFlWmhYuGRPP9Wi5pS1ERWjl9F1MqtJ+mrauUl1QeWjQShrCMrDXCe+e oi42yIXg7N6Bj5641NHdfhLRiHXHupZ8aFQnihpXni3k41PwF23Mh5KLBgI3IeI808cy s6Wvl5BOnSiC7McD14qcjkkZOsbckvArJSQ1kdpC1NmzGXD2ABrrLMcI8FXIv8L2cg7R tH2Aw89HhQZyLRR86K/aapHCPGx9JH2s2j8OGhwmA538eL8m9tnKBKRiAaCDggCHPSfb 8qxQ== 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=i1i0KaPoUmJb+zYjDjlufC0FkBtXwHz4Zap+UGwZ1yo=; b=N8HMEpB4gKiSrVIRvWsDOkyANSTRddHOV0+xvbW0Ot+U+n1xrzoomZmrKxmVYnIXlz O+LHAReDAmIPm8M9ZhUqVZQg3vZrvXX0OetKLkedaAtgmZA0546QgZSpsVRL4D3hfcod T5Qpkf8Dcg9OsGv6C7+T9qjV3ym8a+M5YWIoEFWuFP4W8HXct6JI+tUlsygNnsZ4Dior uM/esQ/Ezs9mP7aMRwsi4+MMP+2Q8HQs+jzhNu30poNcKOM9JBK+n8rAVJ9d8Y1Jep7/ TWjrzIbFeF2Lkr8nb3dRUYxIh+cnDraOVDf2IVP0LERuv346WbHdrpi95fJz8pHaQwyb 21Bg== X-Gm-Message-State: AOAM531ZcrD/3jjaCg/hv4CYKCnELjwhI1THq/8LZrzWfxZ1KBBlLT6S UA37vjdxtYUikE/aOP2N/BlFayoDCCz1hzWGFND2KQ== X-Google-Smtp-Source: ABdhPJwPGMIjqjC+1w4kC474RuGziaPvzeiNKgU+pDGkc6pjRtue9v5NxQq8jmvDBFLLyQldIi5tFuS/SGXXH+zgkm8= X-Received: by 2002:aca:5693:: with SMTP id k141mr11233717oib.35.1594582812480; Sun, 12 Jul 2020 12:40:12 -0700 (PDT) MIME-Version: 1.0 References: <202007120628.06C6SfNB015907@sdf.org> <3afe4d2f-3b1e-a1c5-f947-5f57800317a6@gmail.com> In-Reply-To: <3afe4d2f-3b1e-a1c5-f947-5f57800317a6@gmail.com> From: Jonathan Chen Date: Mon, 13 Jul 2020 07:39:56 +1200 Message-ID: Subject: Re: swap space issues To: Don Wilde Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4B4cZ62NXqz3gFq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chen-org-nz.20150623.gappssmtp.com header.s=20150623 header.b=o05MGJPu; dmarc=none; spf=softfail (mx1.freebsd.org: 2607:f8b0:4864:20::232 is neither permitted nor denied by domain of jonc@chen.org.nz) smtp.mailfrom=jonc@chen.org.nz X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.921]; R_DKIM_ALLOW(-0.20)[chen-org-nz.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.89)[-0.893]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[chen.org.nz]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[chen-org-nz.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::232:from]; NEURAL_HAM_SHORT(-0.19)[-0.187]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 19:40:15 -0000 On Mon, 13 Jul 2020 at 02:24, Don Wilde wrote: > On 7/11/20 11:28 PM, Scott Bennett via freebsd-stable wrote: > > I have read this entire thread to date with growing dismay, and I > > thank Donald Wilde for reporting his ongoing troubles, although they > > spoil my hopes that the kernel's memory management bugs that first became > > apparent in 11.2-RELEASE (and -STABLE around the same time) were not > > propagated into 12.x. A recent update to stable/12 source tree made it > > finally possible for me to build 12.1-STABLE under 11.4-PRERELEASE, and I > > was just about to install the upgrade when this thread appeared. > Spoiler alert. Since I gave up on Synth, I haven't had a single swap > issue. It does appear to be one particular port that drove it nuts > (apparently, one of the 'Google performance' bits, with a > mismatched-brackets problem). I have rebuilt the machine several times, > but that's more for my sense of tidiness than anything. With synth you can reduce the number of workers to just "1" (ie: Number_of_builders=1), if you just want your ports-build to complete without any stress. However, one of the reasons why I use synth is _because_ of the stress it can place on my 12-STABLE snapshots. If the system is stable and performs well when under load, I feel just that bit more assured about using it in production environments. My 2 cents. -- Jonathan Chen From owner-freebsd-stable@freebsd.org Sun Jul 12 20:07:00 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 006BA36D393 for ; Sun, 12 Jul 2020 20:07:00 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4d8z1ZyMz3yqp for ; Sun, 12 Jul 2020 20:06:58 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-pg1-x52f.google.com with SMTP id e8so5052327pgc.5 for ; Sun, 12 Jul 2020 13:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=blqPoXYsd5g07DqJ75hJMN6w9pXcWt7QKZCECaC42zE=; b=Wav/b2Wo2i/skH3N0A7QGVMymDQBThwIYV2gmkVEKj64H+ZAE6ewBzjUrwEI6UXUAI S5jALI/nhRW/YZIdM4IS+DX8nq/cOuND/4JyJEG4Poyr/FepWbH4JEyDhYSQjF2eVO3a 8BHoqwdVTi/h6bfbSwWO3ZqLWnbAl5PF+ecCWQtu2ohMcl8dguzr/JNK+awpd+PGWFtJ EpAz+BLiFKbdkFd90hDHsW5TlmN6Dy2B48VaqsP9LjlDL+ZcK0uM3F2GrW0QQ7p3pgKw Nvb5qwz4HfMHK81H+zm0H3iYPAVNdt0C5NvCn2d/7GkcPs6X/jWulzI+uI1t4lCxwJcs RDBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=blqPoXYsd5g07DqJ75hJMN6w9pXcWt7QKZCECaC42zE=; b=cgMNQkIMOfcbhCJXcrnyWXkJMSWGYa3XPWpCh7xAKsZaYDCF5H6E/qK0IfQS5di+Rj 8fZr0LBgJHFxMJ1/S9xWlCl57B9o83vrF/PrBSm60w1kRt5frLhFzjMsGmFq7aU/67/p OANKpcR3v1I0275e4R6M1Z+SX9YRmfcS28HM0TWeDnK7HEI54/zGE3acvAUiytEhSUbZ YmJ+0PxkGBwon1nbqPNLXXI3J0bSVWYjUnOOdaP+3WVGdnVFPsFizYyNAvpmiK14eAkI bKztVHrwLGDhHjjQiLTUw6Qbwpe9odELNVjxTwOpA+HJu7d0Lm4/0Frfgk/3YUfkxWyx Guog== X-Gm-Message-State: AOAM530clkpu41/EntBP/7WO5iJIK2lf3ZKAke3B8qoPrbaVOhw2qYSE 9MWSJisMDb+LXqXSxaO6r6MVnQv9 X-Google-Smtp-Source: ABdhPJzMGKVmnpky/CT50F0DyBfSDGQhk1JtrUx+Ak0kD8zTSlFKvr8OWIBamsR0IVPdBdmMtXkRgg== X-Received: by 2002:aa7:8391:: with SMTP id u17mr26444993pfm.156.1594584417296; Sun, 12 Jul 2020 13:06:57 -0700 (PDT) Received: from [192.168.0.4] (174-26-193-115.phnx.qwest.net. [174.26.193.115]) by smtp.gmail.com with ESMTPSA id v28sm12349544pgn.81.2020.07.12.13.06.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Jul 2020 13:06:56 -0700 (PDT) Subject: Re: swap space issues To: Jonathan Chen Cc: freebsd-stable@freebsd.org References: <202007120628.06C6SfNB015907@sdf.org> <3afe4d2f-3b1e-a1c5-f947-5f57800317a6@gmail.com> From: Don Wilde Message-ID: <8e833afe-d28a-3cc6-983c-cd5eed88ad20@gmail.com> Date: Sun, 12 Jul 2020 13:06:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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: 4B4d8z1ZyMz3yqp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Wav/b2Wo; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2607:f8b0:4864:20::52f as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-3.90 / 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:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.84)[-0.837]; RECEIVED_SPAMHAUS_PBL(0.00)[174.26.193.115:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.050]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.017]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52f:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 20:07:00 -0000 On 7/12/20 12:39 PM, Jonathan Chen wrote: [snip] > With synth you can reduce the number of workers to just "1" (ie: > Number_of_builders=1), if you just want your ports-build to complete > without any stress. However, one of the reasons why I use synth is > _because_ of the stress it can place on my 12-STABLE snapshots. If the > system is stable and performs well when under load, I feel just that > bit more assured about using it in production environments. > > My 2 cents. Yeah, I did that. Problem was a bad update to a port, had mismatched bracket element so blew the stack. Same thing happened with one worker, one task. Made sure I didn't use that port again... ;-) -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** From owner-freebsd-stable@freebsd.org Mon Jul 13 02:25:39 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BBFDA35658C for ; Mon, 13 Jul 2020 02:25:39 +0000 (UTC) (envelope-from greg.bal4@gmail.com) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4nYt5rZ4z4Jx2 for ; Mon, 13 Jul 2020 02:25:38 +0000 (UTC) (envelope-from greg.bal4@gmail.com) Received: by mail-io1-xd2a.google.com with SMTP id a12so11825737ion.13 for ; Sun, 12 Jul 2020 19:25:38 -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=OtkYbdS+dAHN0l2AVyT4IxaM7+FUVJcS4WNH9SE79PQ=; b=KSoL357F4JxH3CE3PJMQlwsYKitvroYc29oplI56SrZxT1ke5vQy2nhFHRIuwAURd0 nfKvV8Dx4wUXccCbH9karVjGQdHJNpl9AbwFN+lZLltBwtIILnirwzMnvZDqmrpHY8wV BemCcN/tMn5PX6CSUh4YMqwUOC3ffPxsZXvY/qoN62tSEcuBYQOksTJzK2o6OQsgMcrW rJ4rQkedo7g37/CjSri0kfxHuDNcLf+3OgdZlDmCBvPSin6U0hKMFkSN8nk+3BF4rrnM syHRIiV152SfWLcVAlVcpW8dnP+fSRAZfbyC9hQCaz8aBY3dwiVeHnUpkLEN3eERpftW nDyQ== 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=OtkYbdS+dAHN0l2AVyT4IxaM7+FUVJcS4WNH9SE79PQ=; b=DOHXZcEGbEgDjxB5rpJVO+S+yfvduhQP7TSS2Q7z6sndmEcLE3B6+myqhAj54S1ITP GtIkmbX3S4W7PgF2edOKlx6KJz96K6EgpCS1jpj4D8oATv8TvFgdGVD8WQ1B2/LcHYWf feB34ZHh/XR0AkjY7h1lJBKprPqMlapwlHjnfuzM6PvG4A9BtQxQ+xTEt8Tin6yC+e1S OmIp6k9TdUU7uscek00T25iBtnOGUrKfPLhvPkpU05+dzSdI9pBouAovfrNjgGEtMNtD TnJo1y3j9OqBl8fOZVpzLmwtv4V6F4xxYeS8aJYqtvWXRSbKgZ/mOGbq7+nVwLtFEDT6 2hEQ== X-Gm-Message-State: AOAM532BfkltWsQ/KXgpcr3qfZeLM6PlLNE7xOB6XcrxSRY8BBE/LbD+ aR23Dsye1Oq0AzKl8LpivQNJ1REpxD89OMqsvVt0S7Nl X-Google-Smtp-Source: ABdhPJytpHDX75SbUSjao54D0KbUl3Td7zjCFwVKFJ1SMJw9A07Z7Hm/b7jS92lS/IP/2USvDQljDjd475JNFtOTmms= X-Received: by 2002:a5d:8f98:: with SMTP id l24mr58175626iol.141.1594607136974; Sun, 12 Jul 2020 19:25:36 -0700 (PDT) MIME-Version: 1.0 From: Greg Balfour Date: Sun, 12 Jul 2020 21:25:26 -0500 Message-ID: Subject: 11.4-RELEASE i386 won't boot To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4B4nYt5rZ4z4Jx2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=KSoL357F; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gregbal4@gmail.com designates 2607:f8b0:4864:20::d2a as permitted sender) smtp.mailfrom=gregbal4@gmail.com X-Spamd-Result: default: False [-3.53 / 15.00]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.996]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2a:from]; NEURAL_HAM_SHORT(-0.54)[-0.539]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 02:25:39 -0000 I have an ancient Pentium machine(*) that I've been keeping up to date using freebsd-update. It has run everything fine up through 11.3-RELEASE-p11. However it does not like the 11.4-RELEASE kernel. /boot/kernel/kernel text=0x128f22b data=0xe9748+0x2890f4 syms=[0x4+0xea3e0+0x4+0x1797e9] /boot/entropy size=0x1000 Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK set boot_verbose OK boot Booting... \ int=00000006 err=00000000 efl=00010002 eip=c0ba6fa2 eax=00000001 ebx=0201ec00 ecx=00000000 edx=c19ef18c esi=c19eed34 edi=c19eeaa0 ebp=c201fd08 esp=c19ee704 cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 cs:eip=0f 45 d1 c1 e0 04 89 56-20 66 89 46 26 a1 d0 2c 95 c1 89 46 28 5e 5d c3-90 90 90 90 90 90 55 89 ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 0c e7 9e c1 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted The old 11.3 kernel still boots fine. /boot/kernel.old/kernel text=0x12941cb data=0xe8e74+0x2890ec syms=[0x4+0xe9c90+0x4+0x178d4c] OK boot -s Booting... Copyright (c) 1992-2019 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.3-RELEASE-p11 #0: Wed Jul 8 05:39:37 UTC 2020 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0) VT(vga): resolution 640x480 CPU: Pentium/P55C (233.03-MHz 586-class CPU) Origin="GenuineIntel" Id=0x543 Family=0x5 Model=0x4 Stepping=3 Features=0x8001bf real memory = 133169152 (127 MB) avail memory = 98197504 (93 MB) ... The kernel file is good and there's nothing in loader.conf that should cause a problem. # md5 -r /boot/kernel/kernel 40f1065ab4aff80489b456386e9721c0 /boot/kernel/kernel # cat /boot/loader.conf console="comconsole vidconsole" hint.acpi.0.disabled=1 # removing this doesn't help beastie_disable="YES" Any suggestions? (*) I occasionally have to pull data off 5-1/4 inch floppies and this machine is equipped to do that. From owner-freebsd-stable@freebsd.org Mon Jul 13 05:45:40 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6B21D359177 for ; Mon, 13 Jul 2020 05:45:40 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from mx.sdf.org (mx.sdf.org [205.166.94.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.sdf.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4t0g2ctBz4SN4 for ; Mon, 13 Jul 2020 05:45:39 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from sdf.org (IDENT:bennett@miku.sdf.org [205.166.94.6]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 06D5jaXm027870 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 13 Jul 2020 05:45:36 GMT Received: (from bennett@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 06D5jaOj023832; Mon, 13 Jul 2020 00:45:36 -0500 (CDT) From: Scott Bennett Message-Id: <202007130545.06D5jaOj023832@sdf.org> Date: Mon, 13 Jul 2020 00:45:36 -0500 To: freebsd-stable@freebsd.org, dwilde1@gmail.com Subject: Re: swap space issues References: <202007120628.06C6SfNB015907@sdf.org> <3afe4d2f-3b1e-a1c5-f947-5f57800317a6@gmail.com> In-Reply-To: <3afe4d2f-3b1e-a1c5-f947-5f57800317a6@gmail.com> User-Agent: Heirloom mailx 12.5 6/20/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B4t0g2ctBz4SN4 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.77 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.005]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:205.166.94.0/24]; NEURAL_HAM_LONG(-0.98)[-0.977]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_SHORT(0.02)[0.016]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[sdf.org,quarantine]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14361, ipnet:205.166.94.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 05:45:40 -0000 Don Wilde wrote: > > On 7/11/20 11:28 PM, Scott Bennett via freebsd-stable wrote: > > I have read this entire thread to date with growing dismay, and I > > thank Donald Wilde for reporting his ongoing troubles, although they > > spoil my hopes that the kernel's memory management bugs that first became > > apparent in 11.2-RELEASE (and -STABLE around the same time) were not > > propagated into 12.x. A recent update to stable/12 source tree made it > > finally possible for me to build 12.1-STABLE under 11.4-PRERELEASE, and I > > was just about to install the upgrade when this thread appeared. > Spoiler alert. Since I gave up on Synth, I haven't had a single swap > issue. It does appear to be one particular port that drove it nuts > (apparently, one of the 'Google performance' bits, with a > mismatched-brackets problem). I have rebuilt the machine several times, > but that's more for my sense of tidiness than anything. > > I've got a little Crystal script that walks the installed packages and > ports and updates them with system() calls. > The machine is very slow, but it's not swapping at all. That's good. I use portmaster, but not often at present because a "portmaster -a" run can only be done two or three times per boot before real memory is locked down to the extent that the system is no longer functional (i.e., even a scrub of ZFS pools comes to a halt in mid scrub due to lack of a sufficient supply of free page frames). The build procedures of certain ports consistently get killed by the OOM killer, along with much collateral damage. I've noticed that lang/golang and lang/rust are prime examples now, although both used to build without problems. > > It is quite usable now with 12-STABLE. I don't see any good reason to go through the hassle and lost time of an upgrade across a major release boundary if I still won't have a production OS afterward. I'm already dealing with a graphics stack rendered unsafe to use by the ongoing churn in X11 code. (See PR #247441, kindly filed for me by Pau Amma.) > > > > On Fri, 26 Jun 2020 03:55:04 -0700 : Donald Wilde > > wrote: > > > >> On 6/26/20, Peter Jeremy wrote: > >>> > [snip] > >>> I strongly suggest you don't have more than one swap device on spinning > >>> rust - the VM system will stripe I/O across the available devices and > >>> that will give particularly poor results when it has to seek between the > >>> partitions. > > True. The only reason I can think of to use more than one swapping/ > > paging area on the same device for the same OS instance is for emergencies > > or highly unusual, temporary situations in which more space is needed until > > those situations conclude. and even in such situations, if the space can be > > found on another device, it should be placed there. Interleaving of swap > > space across multiple devices is intended as a performance enhancement > > akin to striping (a.k.a. RAID0), although the virtual memory isn't > > necessarily always actually striped across those devices. Adding a paging > > area on the same device as an existing one is an abhorrent situation, as > > Peter Jeremy noted, and it should be eliminated via swapoff(8) as soon as > > the extraordinary situation has passed. N.B. the GENERIC kernel sets a > > limit of four swap devices, although it can be rebuilt with a different > > limit. > That's good data, Scott, thanks! The only reason I got into that > situation of trying to add another swap device was that it was crashing > with OO swap messages. I don't recall you posting those messages, but it sounds like exactly the *temporary* situation in which adding an inappropriately placed paging area can be used long enough to get you out of a bind without a reboot, even though performance will probably suffer until you have removed it again. Poor performance is usually preferable to no performance if it is only temporary. One cautionary note in such situations, though, applies to remote paging areas. Sparse files allocated on the remote system should not be used as paging areas. For example, I discovered the hard way (i.e., the problem was not documented) that SunOS would crash if a sparse file via NFS were added as a paging area and the SunOS system tried to write a page out to an unallocated region of the file, which was essentially all of the file at first. > >> My intent is to make this machine function -- getting the bear > >> dancing. How deftly she dances is less important than that she dances > >> at all. My for-real boxen will have real HP and real cores and RAM. > >> > >>> Also, you can't actually use 64GB swap with 4GB RAM. If you look back > >>> through your boot messages, I expect you'll find messages like: > >>> warning: total configured swap (524288 pages) exceeds maximum recommended > >>> amount (498848 pages). > >>> warning: increase kern.maxswzone or reduce amount of swap. > > Also true. Unfortunately, no guidance whatsoever is provided to advise > > system administrators who need more space as to how to increase the relevant > > table sizes and limits. However, that is a documentation bug, not a code > > bug. > I've got both my kern.max* and CCACHE set up mostly correctly. > Everything builds and runs well, although I've found that it's helpful > to only use -j3 while building, not -j4 which would be appropriate for > my HAMMER i3. I'd much rather have the bear *dancing* than running into > walls. :D I have encountered many ports where MAKE_JOBS_UNSAFE should have been set, but hadn't been. If you have installed ports-mgmt/portcont, you can set this on a per-port basis as you encounter these ports. There are others that fail to build with MAKE_JOBS_NO >= 4, but will build just fine with MAKE_JOBS_NO=3 or 2. However, such failures to build are usually timing problems where one process tries to put a file into a directory that doesn't exist yet or to read a file that hasn't yet been created. These are not situations involving the OOM killer. If you'd like the lines from my /usr/local/etc/ports.conf file for those I've encountered to date, just email me privately for them. > >> Yes, as I posted, those were part of the failure stream from the synth > >> program. When I had kern.maxswzone increased, it got through boot > >> without complaining. > >> > >>> or maybe: > >>> WARNING: reducing swap size to maximum of xxxxMB per unit > >> The warnings were there, in the as-it-failed complaints. > >> > >>> The absolute limit on swap space is vm.swap_maxpages pages but the > >>> realistic > >>> limit is about half that. By default the realistic limit is about 4?RAM > >>> (on > >>> 64-bit architectures), but this can be adjusted via kern.maxswzone (which > >>> defines the #bytes of RAM to allocate to swzone structures - the actual > >>> space allocated is vm.swzone). > >>> > >>> As a further piece of arcana, vm.pageout_oom_seq is a count that controls > >>> the number of passes before the pageout daemon gives up and starts killing > >>> processes when it can't free up enough RAM. "out of swap space" messages Yeah, those messages are half truth and half lie. The true part is that the processes mentioned have indeed been killed. The lie is that the system is out of swap space. (I have seen these messages issued with as little as 217 MB in use out of 24 GB available on my system.) The kernel might not always provide all relevant information in error messages, but it should *never* LIE to us. > >>> generally mean that this number is too low, rather than there being a > >>> shortage of swap - particularly if your swap device is rather slow. > >>> > >> Thanks, Peter! > > A second round of thanks to Peter Jeremy for pointing out this sysctl > > variable (vm.pageout_oom_seq), although thus far I have yet to see that it is > > actually effective in working around the memory management bugs. I have added > > the following lines to /etc/sysctl.conf. > > > > # Because FreeBSD 11.{2,3,4} tie up page frames unnecessarily, set value high > > #vm.pageout_wakeup_thresh=14124 # Default value > > vm.pageout_wakeup_thresh=112640 # 410 MB > > [snip] > > I do totally agree that these are crucial issues for both operation and > documentation, although my issues stemmed from bad _userland_ stack > control. Yes, this is a frequent problem I've observed in the attitudes of programmers who never experienced working with real-memory-only OS. They often lack any awareness of wasteful memory usage, ordering of array accesses, locality of reference issues, etc., resulting in truly ridiculous amounts of bloat and lost performance, not to mention the failures to perform at all such as you encountered. In their minds, virtual memory frees them from all concerns about these issues, so their schoolteachers, now brought up the same way, don't even teach them about such things and perhaps still don't know about them themselves. Another problem, especially with programmers whose memories have not yet accumulated many painful experiences, is the attraction toward newer, more exciting features accompanied by a disinterest in tracking down and fixing existing bugs, even fairly critical bugs. This problem, if left unchecked by management, can lead to terrible predicaments like the one FreeBSD is in now, namely, having no production releases being supported. DragonflyBSD, NetBSD, and OpenBSD do not, AFAIK, suffer from this predicament at present. They are behind to varying degrees in terms of newer, more exciting features, but at least they appear to work. For example, sdf.org has well over 70,000 users and runs quite a few servers to do so. It runs NetBSD miku 8.1_STABLE NetBSD 8.1_STABLE (GENERIC) #0: Wed Sep 11 03:47:45 UTC 2019 root@ol:/sdf/sys/NetBSD-8/sys/arch/amd64/compile/GENERIC amd64 at present. (miku.sdf.org is one of the servers.) Its uptime is currently 306 days. They run several VMs of FreeBSD, OpenBSD, LINUX, and possibly others on some of the servers. ZFS appeared in NetBSD 9.0. I don't know the sysadmin's reasons for not upgrading to it so far, but I suspect they have to do with the number of systems to upgrade, the fact that it is a .0 release, and that root on ZFS and ZFS boot environments are not yet supported, as used to be the case with FreeBSD. I'm not ready to switch to NetBSD quite yet and would not enjoy doing so, but it has been a steadily improving alternative to FreeBSD of late, and if FreeBSD does not release a production system in the meantime, NetBSD may become a better choice for many of us who want to run a production OS. It also offers an alternative to Micro$lop for the so-called "Internet of Things", which no other FOSS OS does, AFAIK, although I don't know enough about LINUX to be sure. > > Those who live on -CURRENT are used to OOPS, but the rest of us get paid > not to have them. I've been using -STABLE for the last several major releases, but because of the vast numbers of conflicts and failures buried throughout the ports tree and the horrendous amount of time it takes to rebuild most of my installed ports I am considering surrendering to using -RELEASE and using quarterly packages, in spite of the loss of features that doing so entails. That would still not deal with the dependency conflicts or the installation of identically named files by different ports, but it would reduce the time spent on building ports that fail to install. > > I am happy with what the Core Team gives us, AND of course we want > ['more','better','faster','STABLE']. :D > As Mark Linimon pointed out, the Core Team only does that indirectly. However, it is the Core Team's job to give firm direction or redirection to those who do the designing and coding to avoid regressions, avoid ignoring the introduction of bugs, especially those that render a system unfit for production use, enhance testing, and so on. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-stable@freebsd.org Mon Jul 13 08:42:17 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B9BD935CE2D for ; Mon, 13 Jul 2020 08:42:17 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4xwT2Xqcz4cC3 for ; Mon, 13 Jul 2020 08:42:16 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 06D8gXBG086110 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 13 Jul 2020 01:42:46 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: , In-Reply-To: <202007130545.06D5jaOj023832@sdf.org> From: Chris Reply-To: bsd-lists@BSDforge.com To: Scott Bennett Subject: Re: swap space issues Date: Mon, 13 Jul 2020 01:42:39 -0700 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4B4xwT2Xqcz4cC3 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 08:42:17 -0000 On Mon, 13 Jul 2020 00:45:36 -0500 Scott Bennett bennett@sdf=2Eorg said > Don Wilde wrote: >=20 > > > > On 7/11/20 11:28 PM, Scott Bennett via freebsd-stable wrote: > > > I have read this entire thread to date with growing dismay, and= I > > > thank Donald Wilde for reporting his ongoing troubles, although they > > > spoil my hopes that the kernel's memory management bugs that first be= came > > > apparent in 11=2E2-RELEASE (and -STABLE around the same time) were not > > > propagated into 12=2Ex=2E A recent update to stable/12 source tree made = it > > > finally possible for me to build 12=2E1-STABLE under 11=2E4-PRERELEASE, a= nd I > > > was just about to install the upgrade when this thread appeared=2E > > Spoiler alert=2E Since I gave up on Synth, I haven't had a single swap=20 > > issue=2E It does appear to be one particular port that drove it nuts=20 > > (apparently, one of the 'Google performance' bits, with a=20 > > mismatched-brackets problem)=2E I have rebuilt the machine several times,= =20 > > but that's more for my sense of tidiness than anything=2E > > > > I've got a little Crystal script that walks the installed packages and= =20 > > ports and updates them with system() calls=2E > > The machine is very slow, but it's not swapping at all=2E >=20 > That's good=2E I use portmaster, but not often at present because a > "portmaster -a" run can only be done two or three times per boot before r= eal > memory is locked down to the extent that the system is no longer function= al > (i=2Ee=2E, even a scrub of ZFS pools comes to a halt in mid scrub due to lack= of > a > sufficient supply of free page frames)=2E > The build procedures of certain ports consistently get killed by the > OOM > killer, along with much collateral damage=2E I've noticed that lang/golang > and > lang/rust are prime examples now, although both used to build without > problems=2E > > > > It is quite usable now with 12-STABLE=2E >=20 > I don't see any good reason to go through the hassle and lost time of > an > upgrade across a major release boundary if I still won't have a productio= n > OS > afterward=2E I'm already dealing with a graphics stack rendered unsafe to = use > by > the ongoing churn in X11 code=2E (See PR #247441, kindly filed for me by P= au > Amma=2E) > > > > > > On Fri, 26 Jun 2020 03:55:04 -0700 : Donald Wilde > > > wrote: > > > > > >> On 6/26/20, Peter Jeremy wrote: > > >>> > > [snip] > > >>> I strongly suggest you don't have more than one swap device on spin= ning > > >>> rust - the VM system will stripe I/O across the available devices a= nd > > >>> that will give particularly poor results when it has to seek betwee= n the > > >>> partitions=2E > > > True=2E The only reason I can think of to use more than one swap= ping/ > > > paging area on the same device for the same OS instance is for emerge= ncies > > > or highly unusual, temporary situations in which more space is needed > > until > > > those situations conclude=2E and even in such situations, if the space = can > > be > > > found on another device, it should be placed there=2E Interleaving of = swap > > > space across multiple devices is intended as a performance enhancemen= t > > > akin to striping (a=2Ek=2Ea=2E RAID0), although the virtual memory isn't > > > necessarily always actually striped across those devices=2E Adding a p= aging > > > area on the same device as an existing one is an abhorrent situation,= as > > > Peter Jeremy noted, and it should be eliminated via swapoff(8) as soo= n as > > > the extraordinary situation has passed=2E N=2EB=2E the GENERIC kernel sets= a > > > limit of four swap devices, although it can be rebuilt with a differe= nt > > > limit=2E > > That's good data, Scott, thanks! The only reason I got into that=20 > > situation of trying to add another swap device was that it was crashing= =20 > > with OO swap messages=2E >=20 > I don't recall you posting those messages, but it sounds like exactly > the > *temporary* situation in which adding an inappropriately placed paging ar= ea > can > be used long enough to get you out of a bind without a reboot, even thoug= h > performance will probably suffer until you have removed it again=2E Poor > performance is usually preferable to no performance if it is only tempora= ry=2E > One cautionary note in such situations, though, applies to remote > paging > areas=2E Sparse files allocated on the remote system should not be used as > paging areas=2E For example, I discovered the hard way (i=2Ee=2E, the problem = was > not documented) that SunOS would crash if a sparse file via NFS were adde= d > as > a paging area and the SunOS system tried to write a page out to an > unallocated > region of the file, which was essentially all of the file at first=2E >=20 > > >> My intent is to make this machine function -- getting the bear > > >> dancing=2E How deftly she dances is less important than that she dance= s > > >> at all=2E My for-real boxen will have real HP and real cores and RAM=2E > > >> > > >>> Also, you can't actually use 64GB swap with 4GB RAM=2E If you look b= ack > > >>> through your boot messages, I expect you'll find messages like: > > >>> warning: total configured swap (524288 pages) exceeds maximum > > recommended > > >>> amount (498848 pages)=2E > > >>> warning: increase kern=2Emaxswzone or reduce amount of swap=2E > > > Also true=2E Unfortunately, no guidance whatsoever is provided t= o advise > > > system administrators who need more space as to how to increase the > > relevant > > > table sizes and limits=2E However, that is a documentation bug, not a = code > > > bug=2E > > I've got both my kern=2Emax* and CCACHE set up mostly correctly=2E=20 > > Everything builds and runs well, although I've found that it's helpful= =20 > > to only use -j3 while building, not -j4 which would be appropriate for= =20 > > my HAMMER i3=2E I'd much rather have the bear *dancing* than running into= =20 > > walls=2E :D >=20 > I have encountered many ports where MAKE_JOBS_UNSAFE should have been > set, > but hadn't been=2E If you have installed ports-mgmt/portcont, you can set = this > on > a per-port basis as you encounter these ports=2E There are others that fai= l > to > build with MAKE_JOBS_NO >=3D 4, but will build just fine with MAKE_JOBS_N= O=3D3 or > 2=2E > However, such failures to build are usually timing problems where one > process > tries to put a file into a directory that doesn't exist yet or to read a > file > that hasn't yet been created=2E These are not situations involving the OOM > killer=2E > If you'd like the lines from my /usr/local/etc/ports=2Econf file for those > I've > encountered to date, just email me privately for them=2E >=20 > > >> Yes, as I posted, those were part of the failure stream from the syn= th > > >> program=2E When I had kern=2Emaxswzone increased, it got through boot > > >> without complaining=2E > > >> > > >>> or maybe: > > >>> WARNING: reducing swap size to maximum of xxxxMB per unit > > >> The warnings were there, in the as-it-failed complaints=2E > > >> > > >>> The absolute limit on swap space is vm=2Eswap_maxpages pages but the > > >>> realistic > > >>> limit is about half that=2E By default the realistic limit is about = 4?RAM > > >>> (on > > >>> 64-bit architectures), but this can be adjusted via kern=2Emaxswzone > > (which > > >>> defines the #bytes of RAM to allocate to swzone structures - the ac= tual > > >>> space allocated is vm=2Eswzone)=2E > > >>> > > >>> As a further piece of arcana, vm=2Epageout_oom_seq is a count that > > controls > > >>> the number of passes before the pageout daemon gives up and starts > > killing > > >>> processes when it can't free up enough RAM=2E "out of swap space" > > messages >=20 > Yeah, those messages are half truth and half lie=2E The true part is > that > the processes mentioned have indeed been killed=2E The lie is that the sys= tem > is > out of swap space=2E (I have seen these messages issued with as little as = 217 > MB > in use out of 24 GB available on my system=2E) The kernel might not always > provide > all relevant information in error messages, but it should *never* LIE to = us=2E >=20 > > >>> generally mean that this number is too low, rather than there being= a > > >>> shortage of swap - particularly if your swap device is rather slow=2E > > >>> > > >> Thanks, Peter! > > > A second round of thanks to Peter Jeremy for pointing out this = sysctl > > > variable (vm=2Epageout_oom_seq), although thus far I have yet to see th= at it > > is > > > actually effective in working around the memory management bugs=2E I h= ave > > added > > > the following lines to /etc/sysctl=2Econf=2E > > > > > > # Because FreeBSD 11=2E{2,3,4} tie up page frames unnecessarily, set va= lue > > high > > > #vm=2Epageout_wakeup_thresh=3D14124 # Default value > > > vm=2Epageout_wakeup_thresh=3D112640 # 410 MB > > > > [snip] > > > > I do totally agree that these are crucial issues for both operation and= =20 > > documentation, although my issues stemmed from bad _userland_ stack=20 > > control=2E >=20 > Yes, this is a frequent problem I've observed in the attitudes of > programmers > who never experienced working with real-memory-only OS=2E They often lack = any > awareness of wasteful memory usage, ordering of array accesses, locality = of > reference issues, etc=2E, resulting in truly ridiculous amounts of bloat an= d > lost > performance, not to mention the failures to perform at all such as you > encountered=2E > In their minds, virtual memory frees them from all concerns about these > issues, so > their schoolteachers, now brought up the same way, don't even teach them > about such > things and perhaps still don't know about them themselves=2E Feeling the same way=2E C++ IMHO was the beginning of the end -- abstraction = / objects do not lead to a better understanding of what you're doing, if you'= ve never worked on "bare metal" (at the "chip" level)=2E Those w/o knowledge in assembler never really fully understand what their doing=2E Sorry=2E Couldn't resist=2E > Another problem, especially with programmers whose memories have not > yet > accumulated many painful experiences, is the attraction toward newer, mor= e > exciting > features accompanied by a disinterest in tracking down and fixing existin= g > bugs, > even fairly critical bugs=2E This problem, if left unchecked by management= , > can lead > to terrible predicaments like the one FreeBSD is in now, namely, having n= o > production releases being supported=2E DragonflyBSD, NetBSD, and OpenBSD d= o > not, > AFAIK, suffer from this predicament at present=2E They are behind to varyi= ng > degrees > in terms of newer, more exciting features, but at least they appear to wo= rk=2E=20 > For > example, sdf=2Eorg has well over 70,000 users and runs quite a few servers = to > do so=2E > It runs >=20 > NetBSD miku 8=2E1_STABLE NetBSD 8=2E1_STABLE (GENERIC) #0: Wed Sep 11 03:47:4= 5 > UTC 2019 root@ol:/sdf/sys/NetBSD-8/sys/arch/amd64/compile/GENERIC amd64 >=20 > at present=2E (miku=2Esdf=2Eorg is one of the servers=2E) Its uptime is current= ly > 306 days=2E > They run several VMs of FreeBSD, OpenBSD, LINUX, and possibly others on s= ome > of the > servers=2E ZFS appeared in NetBSD 9=2E0=2E I don't know the sysadmin's reason= s > for not > upgrading to it so far, but I suspect they have to do with the number of > systems to > upgrade, the fact that it is a =2E0 release, and that root on ZFS and ZFS b= oot > environments are not yet supported, as used to be the case with FreeBSD=2E = I'm > not > ready to switch to NetBSD quite yet and would not enjoy doing so, but it = has > been > a steadily improving alternative to FreeBSD of late, and if FreeBSD does = not > release > a production system in the meantime, NetBSD may become a better choice fo= r > many of > us who want to run a production OS=2E It also offers an alternative to > Micro$lop for > the so-called "Internet of Things", which no other FOSS OS does, AFAIK, > although I > don't know enough about LINUX to be sure=2E > > > > Those who live on -CURRENT are used to OOPS, but the rest of us get pai= d=20 > > not to have them=2E >=20 > I've been using -STABLE for the last several major releases, but beca= use > of > the vast numbers of conflicts and failures buried throughout the ports tr= ee > and > the horrendous amount of time it takes to rebuild most of my installed po= rts > I am > considering surrendering to using -RELEASE and using quarterly packages, = in > spite > of the loss of features that doing so entails=2E That would still not deal > with the=20 > dependency conflicts or the installation of identically named files by > different > ports, but it would reduce the time spent on building ports that fail to > install=2E > > > > I am happy with what the Core Team gives us, AND of course we want=20 > > ['more','better','faster','STABLE']=2E :D > > > As Mark Linimon pointed out, the Core Team only does that indirectly=2E= =20 > However, > it is the Core Team's job to give firm direction or redirection to those = who > do the > designing and coding to avoid regressions, avoid ignoring the introductio= n of > bugs, > especially those that render a system unfit for production use, enhance > testing, > and so on=2E >=20 >=20 > Scott Bennett, Comm=2E ASMELG, CFIAG > ********************************************************************** > * Internet: bennett at sdf=2Eorg *xor* bennett at freeshell=2Eorg * > *--------------------------------------------------------------------* > * "A well regulated and disciplined militia, is at all times a good * > * objection to the introduction of that bane of all free governments * > * -- a standing army=2E" * > * -- Gov=2E John Hancock, New York Journal, 28 January 1790 * > ********************************************************************** --Chris From owner-freebsd-stable@freebsd.org Mon Jul 13 18:01:49 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8A1B336C25F for ; Mon, 13 Jul 2020 18:01:49 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (gvr.gvr.org [62.251.117.91]) (using TLSv1.2 with cipher DHE-RSA-CAMELLIA256-SHA256 (256/256 bits)) (Client CN "gvr.gvr.org", Issuer "Gandi Standard SSL CA 2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5BL44Tp6z4Jk0; Mon, 13 Jul 2020 18:01:48 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (localhost [127.0.0.1]) by gvr.gvr.org (Postfix) with ESMTP id 9FA7E583DF; Mon, 13 Jul 2020 20:01:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at gvr.org Received: from gvr.gvr.org ([127.0.0.1]) by gvr.gvr.org (gvr.gvr.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id K_7MuuOoGPi7; Mon, 13 Jul 2020 20:01:41 +0200 (CEST) Received: by gvr.gvr.org (Postfix, from userid 657) id 64A5D583DC; Mon, 13 Jul 2020 20:01:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gvr.org; s=20190204; t=1594663301; bh=cFv1YaiGhIjxpoPGLmHSFMmpuztiITTsH3s6TzQ3fWU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=rIT7B4RJmxOPRtPuKqbvaKR9dljVsGuJhbEYyefJnYXFDNFBMMyTQGE4rv69LdWpI xqHw+m2/eRYLa/mSVjwjmFB5cJod3DYDaPe1mNBS+RZA31R7eI/uCf/f/unFmf42n3 tRTMqY6cYQjwBxyiJtUsE38u3g5zoMqmvK7dH7IP08pl6VDnyqkCMZ4Rxzd+mcSTz3 jvatIZrH34/NPLLMROoULh7tyW5P8JrJ1R2vQ+gRZ8VVM2CsUW6ZuRHINYCKmisEdK yx/cL55Qph+BSfFJzlgciz04bWJEGZg419iwiwwx4luBRi+9Louk63jkGu8tYGo57b bX91+4jtBg5Jg== Date: Mon, 13 Jul 2020 20:01:41 +0200 From: Guido van Rooij To: Kyle Evans Cc: FreeBSD-STABLE Mailing List Subject: Re: 12.1p7 no longer boots after doing zpool upgrade -a Message-ID: <20200713180141.GA21770@gvr.gvr.org> References: <20200709131201.GA3464@co.gvr.org> <20200710182903.GA7412@gvr.gvr.org> <20200710184446.GA8358@gvr.gvr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4B5BL44Tp6z4Jk0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gvr.org header.s=20190204 header.b=rIT7B4RJ; dmarc=none; spf=pass (mx1.freebsd.org: domain of guido@gvr.org designates 62.251.117.91 as permitted sender) smtp.mailfrom=guido@gvr.org X-Spamd-Result: default: False [-3.16 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; R_DKIM_ALLOW(-0.20)[gvr.org:s=20190204]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gvr.org]; NEURAL_HAM_LONG(-1.01)[-1.011]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gvr.org:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.66)[-0.661]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:3265, ipnet:62.251.0.0/17, country:NL] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 18:01:49 -0000 On Fri, Jul 10, 2020 at 02:28:12PM -0500, Kyle Evans wrote: > > > > There was one question I forgot to ask: > > Could I have known that my method of updating the ESP was not correct? > > If so, where is this documented? > > > > It is probably unlikely, to be honest. I don't know that we do a good > job of advising people/documenting how to update the ESP. In fact, I > have no idea where any of it's documented except the wiki: > https://wiki.freebsd.org/UEFI > Hi Kyle, I think that if the "new" method is stable as you say, the changes done in r342283 based on https://reviews.freebsd.org/D17947 should be MFC'ed, don't you think? Because then boot1.efi and boot1.efifat wil not even be created anymore and the old documentation would be clearly out of date (in fact it would even be better when both boot1.efi and boot1.efifat would be mentioned in ObsoleteFiles.inc) -Guido From owner-freebsd-stable@freebsd.org Mon Jul 13 20:10:23 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D610036F6E5; Mon, 13 Jul 2020 20:10:23 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5FBR53JHz4Sch; Mon, 13 Jul 2020 20:10:23 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 99DD214877; Mon, 13 Jul 2020 20:10:23 +0000 (UTC) Date: Mon, 13 Jul 2020 20:10:23 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2020-07-12 Message-ID: <20200713201023.GA65411@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 20:10:23 -0000 FreeBSD CI Weekly Report 2020-07-12 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-07-06 to 2020-07-12. During this period, we have: * 1964 builds (95.7% (+0.0) passed, 4.3% (+0.0) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 225 test runs (86.7% (-4.7) passed, 13.3% (+6.1) unstable, 0.0% (-1.4) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 36 doc and www builds (100% (+4.3) passed) Test case status (on 2020-07-12 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | --------- | --------- | ----- | ------- | | head/amd64 | 7859 (+2) | 7767 (+5) | 0 (0) | 92 (-3) | | head/i386 | 7857 (+2) | 7758 (+5) | 0 (0) | 99 (-3) | | 12-STABLE/amd64 | 7617 (0) | 7557 (+1) | 0 (0) | 60 (-1) | | 12-STABLE/i386 | 7615 (0) | 7547 (+1) | 0 (0) | 68 (-1) | | 11-STABLE/amd64 | 6912 (0) | 6861 (0) | 0 (0) | 51 (0) | | 11-STABLE/i386 | 6910 (0) | 6854 (-3) | 0 (0) | 56 (+3) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200712 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcomed. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandlerCursesGUI.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' collect2: error: ld returned 1 exit status ``` ## Regressions * lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on amd64 after r360915 https://bugs.freebsd.org/246537 * lib.msun.ctrig_test.test_inf_inputs starts failing after llvm10 import https://bugs.freebsd.org/244732 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) Fix in review: https://reviews.freebsd.org/D25284 ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3749 tests, 2277 success, 647 failures, 825 skipped ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ * sys.kern.ptrace_test.ptrace__procdesc_reparent_wait_child https://bugs.freebsd.org/243605 * sys.kern.ptrace_test.ptrace__parent_wait_after_attach https://bugs.freebsd.org/244055 * sys.kern.ptrace_test.ptrace__parent_exits_before_child https://bugs.freebsd.org/244056 * sys.net.if_lagg_test.witness (i386) https://bugs.freebsd.org/244163 * PipePdfork.WildcardWait in sys.capsicum.capsicum-test.main https://bugs.freebsd.org/244165 * sys.net.if_lagg_test.lacp_linkstate_destroy_stress (i386) https://bugs.freebsd.org/244168 * sys.netinet6.frag6.frag6_07.frag6_07 https://bugs.freebsd.org/244170 * sys.netinet.fibs_test.udp_dontroute6 https://bugs.freebsd.org/244172 * sys.netpfil.pf.nat.exhaust https://bugs.freebsd.org/244703 * sys.geom.class.gate.ggate_test.ggated (i386) https://bugs.freebsd.org/244737 * sys.kern.sysv_test.msg https://bugs.freebsd.org/233649 ## Issues ### Cause build fails * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 * https://bugs.freebsd.org/246443 sys.net.if_clone_test.epair_stress sometimes exceeds timeout limit but not caught by kyua * https://bugs.freebsd.org/247510 sys.net.if_lagg_test.status_stress panics kernel on i386 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-stable@freebsd.org Tue Jul 14 15:00:12 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5C9B3365833 for ; Tue, 14 Jul 2020 15:00:12 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5kG32VmBz4N2x; Tue, 14 Jul 2020 15:00:11 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id 06EEwmaa018398 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Jul 2020 07:58:48 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id 06EEwlBu018397; Tue, 14 Jul 2020 07:58:47 -0700 (PDT) (envelope-from warlock) Date: Tue, 14 Jul 2020 07:58:47 -0700 From: John Kennedy To: Kyle Evans Cc: Guido van Rooij , FreeBSD-STABLE Mailing List Subject: Re: 12.1p7 no longer boots after doing zpool upgrade -a Message-ID: <20200714145847.GB11731@phouka1.phouka.net> References: <20200709131201.GA3464@co.gvr.org> <20200709211854.GA11731@phouka1.phouka.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4B5kG32VmBz4N2x X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net X-Spamd-Result: default: False [3.31 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.26)[0.263]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[phouka.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.92)[0.920]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.93)[0.925]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US]; FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 15:00:12 -0000 On Fri, Jul 10, 2020 at 02:25:02PM -0500, Kyle Evans wrote: > > So one recipe doesn't even seem to make the freebsd-boot partition, so is it > > optional for a pure UEFI boot? Should we always gpart-bootcode it if it exists > > and upgrade BOOTx64.efi when the EFI partition exists, or is there a few more > > wrinkles we need to worry about? > > Correct, freebsd-boot is not needed for a pure UEFI boot. I wouldn't > necessarily bother updating the freebsd-boot partition unless you > suspect you may need to switch back to legacy boot at some point; UEFI > is now rock-solid on all of my systems, so I've personally found no > such need and on many of them I've removed the old freebsd-boot bits. > > If you've got an ESP, you should update that manually. If you want to > maintain the option of legacy boot, you should use gpart-bootcode for > that but don't use it on the ESP with boot1.efifat. I don't know why I would. Its pretty hard to find a non-UEFI motherboard these days and, as you've said, it's been pretty solid. I don't think I said it initially, but this originally started off of 12.0 boot media (~2019/5/31), rather than me partitioning it by hand or some more modern 12.1+ stick. > > In any case, is it a logical theory that my possible boot-order problem > > is because drive order got swapped and maybe one wasn't properly updated? > > They seem to be the same: > > > > # md5 /dev/nvd[01]p2 > > MD5 (/dev/nvd0p2) = 2ded438a2c97ea551446cc2d1d3b498e > > MD5 (/dev/nvd1p2) = 2ded438a2c97ea551446cc2d1d3b498e > > > > Ideally I'd like to have not boot through the UEFI boot menu every time. > > > > I'm not sure why the drive order seems to matter right now. > > > > When you get booted back to the UEFI menu, is it a specific drive that > you must select or do both equally work from that point? My options are basically M.2_1 and M.2_2 (not sure what labeled them, I think that is the exact name, can confirm later). #2 is currently the "first" drive, and changing boot order in the BIOS to favor #1 doesn't seem to fix that. As I said, the motherboard died and the drives were moved to a new system and I suspect that the order was swapped. I never had a reason to question my ability to boot from the 2nd disk, and hadn't done anything that merited an upgrade that made me look at it this closely. Before I figured out what was going on, it would work some of the time. I suspect a race condition (where sometimes #1 would "win"), but I can't find something that makes #2 a bad initial boot disk. I don't see anything in the boot messages that say which drive it had glommed onto. I can't say that I've tried to select #2. I can try that later on today. It's doing my weekly upgrade-build right now. From owner-freebsd-stable@freebsd.org Tue Jul 14 16:59:09 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 20121368A4F for ; Tue, 14 Jul 2020 16:59:09 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5mvH5yXLz3VZS; Tue, 14 Jul 2020 16:59:07 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-pl1-x633.google.com with SMTP id 72so7282886ple.0; Tue, 14 Jul 2020 09:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=qX9cZA2Lq84m3bsz93OV7A2tv77UnuX3Qdb2C/hxkrA=; b=nSwIg1DdT7UBv1EtQxHbE2irf1vtnzxik85GRbpYbXpiXg8IXkG7dAP1HH7nfv2d5x m2+Tz124xJL4q/HuK/Tmh3xqLkC36M/iCoB2YePRVNqBmfcW9PZ/+n9vuUuhfF3jaS3O tok8KEKYASQQfmNRuGxHnkR96HwTqJuDtipaY8pehGQW0eLGr6h5h260JRKUn1wieWZY Elnfw9NW1NZWbBy4xfoLHjfc9trZdaxAA53w4E9lgjKxUSkEDjfClimb8e+AniYu+nIN S/dnZzCBXkvSwFZdrQmT1xA3rBt0nAmTaPGV5mxLgHeokirOTVFiFO/cgdGpD/J6kLoe juZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=qX9cZA2Lq84m3bsz93OV7A2tv77UnuX3Qdb2C/hxkrA=; b=h+BxSjr4msKxw63IBcVBe4vfr3X7bw59cVVAhg4EW1Xb5izpBKD4VuVsKyudntDHQ3 5ZIWbbTP8dBF955CPBLfYWHr+K/rC4hQeK25IeCFJ8+19KyuazscBda/giHDKfFQ2KPz y2Nxrh6s1MZwjqGreFjERNyvLaF3TwjZb3NM27u7SjDFi4R8gUDmXQUo2uWYcQtgpG3V TBIAD9zDpHCK5OlNz5SlfvYznBZwa/ayGodhFC1aZMrFwuVh0tA7HGm954aU0XLF0uZv 5A83UrJp+lIxMhOj2MKYSGmJXAlCq54gTd9GQP+Hn4wPxjz1L4T5hTWkWvdFkVAU7HSi 2WIA== X-Gm-Message-State: AOAM532PhB7QYjKIt/nibipiBeMZhdE3nobo/n1535EfEXGj8IYJdDny pQ5pgrtRMY00u+EZ6N32ng+EPDk5szayoA== X-Google-Smtp-Source: ABdhPJxGkfFqeHgP+i9UDReDRT1VLUAe/ZdhbVpcm1CsEGDQoRODtQpROckwbVxW0wQiWzukLzQtKg== X-Received: by 2002:a17:90a:3909:: with SMTP id y9mr5091216pjb.188.1594745945894; Tue, 14 Jul 2020 09:59:05 -0700 (PDT) Received: from [192.168.0.4] (174-26-202-167.phnx.qwest.net. [174.26.202.167]) by smtp.gmail.com with ESMTPSA id br9sm2923525pjb.56.2020.07.14.09.59.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jul 2020 09:59:05 -0700 (PDT) To: freebsd-stable@freebsd.org, yuri@FreeBSD.org From: Don Wilde Subject: quirk in libpng16.{a|so} Message-ID: <05550c7e-e76b-5373-03ec-8e9008f3927f@gmail.com> Date: Tue, 14 Jul 2020 09:59:03 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 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: 4B5mvH5yXLz3VZS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=nSwIg1Dd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2607:f8b0:4864:20::633 as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-3.53 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[174.26.202.167:received]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.005]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.05)[-1.048]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::633:from]; NEURAL_HAM_SHORT(-0.48)[-0.477]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 16:59:09 -0000 Hi, Yuri -- I understand that you maintain the png++ "C++ wrapper for libpng"? There's a game engine I'm trying to work with on my 12-stable system, called Drag[en]gine. https://dragondreams.ch/ It's a complicated port, and I'll end up tweaking some heavy-duty OpenGL graphics to get it to do stuff for me. The first issue is that our libpng16 library is missing a C++ call: png_access_version_number(), which causes its setup program (a Python script)to crash. I have both png and png++ installed and both libpng16.so and libpng16.a are present. I'm in the process of (also) installing it on my Ubuntu 18.04.4 machine. It hasn't given me this libpng16 issue. What do you think of this problem? Is this yours or is it the actual libpng library itself? -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** From owner-freebsd-stable@freebsd.org Tue Jul 14 18:05:30 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D5E3236ABBE for ; Tue, 14 Jul 2020 18:05:30 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5pMs1kB9z47yG; Tue, 14 Jul 2020 18:05:28 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-pl1-x636.google.com with SMTP id x8so7338254plm.10; Tue, 14 Jul 2020 11:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=L4pfAPXoYfdJ8POBQVcvZ/lHv2INhBnKDLADWts2wKQ=; b=gtOSJp2AVOUirHml1EQr/nyng7LP35leK3Fn9BnDoBd0k0CamSHZNR5RHy0ippFZ93 q9/Ybu+c1Kvoetcc/a4KJxmAVEJRwvZOef0ZOgbO3tBUHI88JyyDSztitrGkQz0mCavN BCjAQkrLjnrb8PYlrxkDOK12LyPwNj8okUkxqUpGISvvBpkfJIBZHvAkmQRMBqj2bl96 PQA00du73cHujXic1cd5bnk09nEMHiNbWs89JzMb7OTufqHZCXrHpUcqk00agLnDih/t kj7orJR7rDRWLhq9dl0JjFOZbYIMyQ84xN3p8Fa6FN+vTcGdU8lZ7JH4Ugc0P0KPvA3l kWsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=L4pfAPXoYfdJ8POBQVcvZ/lHv2INhBnKDLADWts2wKQ=; b=gwUZdNolAvLzEwekECWQRa0M9VFpY6H7fAU1fpQ3zpp5qgQbdlmUkkjk9+K217PN1I 31rVhmTqNN5gHYA7pFA1jPkwzDMOTu8vdiCQbM6DdM42aoX2UN3Yw+4EgbGEQ4Xqp6dI kc7cX4KnhtT8QYM26TGujqxY4aPdR7WyLNdOvbTlQRmTTnxxnsQi9QI7uxyd2C5Np1kB 7mozh8VNk7biJ7I7KbgAB4w5qW+8GIvVwe4MYdX6S+32S1ZOkc7poPmWf825aQI8ZyoX h0rV5lFZ2L7aKEfiR0vVQ4D19H4uPGJsSx47P5Awbwo/TloMDKP79Z6yHTYY2fXBP4AX RhjA== X-Gm-Message-State: AOAM530HYgeXxQphb94lCJd07JfaAQnShxW9/BHoa8VR+c9rKZN7K/rT cr1LVE3czxDNQaMyivWFWNjCkyf3VKc= X-Google-Smtp-Source: ABdhPJxDWaMK9/q89i3NDrlzD9A+mTSQFrf9PEEBJzNcGo9EvelF7tpYjRdBhQB7yvKoJwfgTuokSA== X-Received: by 2002:a17:902:7688:: with SMTP id m8mr1046676pll.12.1594749926716; Tue, 14 Jul 2020 11:05:26 -0700 (PDT) Received: from [192.168.0.4] (174-26-202-167.phnx.qwest.net. [174.26.202.167]) by smtp.gmail.com with ESMTPSA id i66sm17260504pfc.12.2020.07.14.11.05.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jul 2020 11:05:25 -0700 (PDT) Subject: Re: quirk in libpng16.{a|so} To: yuri@freebsd.org Cc: freebsd-stable@freebsd.org References: <05550c7e-e76b-5373-03ec-8e9008f3927f@gmail.com> From: Don Wilde Message-ID: <0fc386c4-35dc-39de-a0f0-365e82d4efde@gmail.com> Date: Tue, 14 Jul 2020 11:05:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------2213BD46D49BCD2C860E8E1F" Content-Language: en-US X-Rspamd-Queue-Id: 4B5pMs1kB9z47yG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=gtOSJp2A; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2607:f8b0:4864:20::636 as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-2.77 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.85)[-0.849]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[174.26.202.167:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.04)[-1.043]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.975]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-python]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::636:from]; RCVD_TLS_ALL(0.00)[] X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 18:05:31 -0000 This is a multi-part message in MIME format. --------------2213BD46D49BCD2C860E8E1F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/14/20 10:10 AM, yuri@freebsd.org wrote: > On 2020-07-14 09:59, Don Wilde wrote: >> Hi, Yuri -- I understand that you maintain the png++ "C++ wrapper for >> libpng"? >> >> There's a game engine I'm trying to work with on my 12-stable system, >> called Drag[en]gine. >> >> https://dragondreams.ch/ >> >> It's a complicated port, and I'll end up tweaking some heavy-duty >> OpenGL graphics to get it to do stuff for me. The first issue is that >> our libpng16 library is missing a C++ call: >> png_access_version_number(), which causes its setup program (a Python >> script)to crash. >> >> I have both png and png++ installed and both libpng16.so and >> libpng16.a are present. >> >> I'm in the process of (also) installing it on my Ubuntu 18.04.4 >> machine. It hasn't given me this libpng16 issue. >> >> What do you think of this problem? Is this yours or is it the actual >> libpng library itself? >> > > Hi Don, > > > I used png++ on both Linux (CentOS) and FreeBSD without any problems. > > > I also can't find png_access_version_number() call in the png++ sources. Okay, this must actually be a call in the actual libpng sources. > > > Could you please provide an example code that exhibits the problem? Here's what happens, though there's evidently quite a bit of construction that happens in the middle. scons is Yet Another Super-Make, and it's plus (evidently) is that it can also generate Android and Windows code. I type 'scons -h', and the output is: scons: Reading SConscript files ... Checking for zlibVersion() in C++ library z... yes Checking for png_access_version_number() in C++ library png16... no KeyError: 'forceRuntimeLibs':   File "/opt/dragengine/SConstruct", line 633:     duplicate=0, exports='parent_env parent_targets parent_report' )   File "/usr/local/lib/python3.7/site-packages/SCons/Script/SConscript.py", line 660:     return method(*args, **kw)   File "/usr/local/lib/python3.7/site-packages/SCons/Script/SConscript.py", line 597:     return _SConscript(self.fs, *files, **subst_kw)   File "/usr/local/lib/python3.7/site-packages/SCons/Script/SConscript.py", line 286:     exec(compile(scriptdata, scriptname, 'exec'), call_stack[-1].globals)   File "/opt/dragengine/extern/libpng/SConscript", line 120: forceRuntimeLibs.extend(parent_targets['lib_zlib']['forceRuntimeLibs']) The SConscript files are generated from the (attached) custom.py, from what I understand. The error happens in the construct between lines 631 - 633 of that attached SConscript file (which acts like Makefile does for C and C++). Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** --------------2213BD46D49BCD2C860E8E1F Content-Type: text/plain; charset=UTF-8; name="SConstruct" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="SConstruct" ZnJvbSBTQ29uc0NvbW1vbiBpbXBvcnQgKg0KZnJvbSBTQ29uc1BsYXRmb3JtQW5kcm9pZCBp bXBvcnQgYW5kcm9pZFVwZGF0ZUVudg0KDQojIGNyZWF0ZSBlbnZpcm9ubWVudA0KdG9vbHMg PSBBUkdVTUVOVFMuZ2V0KCAndG9vbHMnLCAnJyApDQppZiB0b29sczoNCglpZiB0b29scyA9 PSAnbWluZ3c2NCc6DQoJCXBhcmVudF9lbnYgPSBFbnZpcm9ubWVudCggQ1BQUEFUSD0nLics IExJQlBBVEg9Jy4nLCB0b29scz1bJ21pbmd3J10gKQ0KCQkNCgkJY29tcGlsZXIgPSAneDg2 XzY0LXc2NC1taW5ndzMyJw0KCQlpZiBub3QgcGFyZW50X2Vudi5EZXRlY3QoICd7fS1nKysn LmZvcm1hdCggY29tcGlsZXIgKSApOg0KCQkJcHJpbnQoICdXaW5kb3dzIDY0LWJpdCBDcm9z cy1Db21waWxlciBub3QgZm91bmQuJyApDQoJCQlSZXR1cm4oKQ0KCQkNCgkJcGFyZW50X2Vu di5SZXBsYWNlKCBDQyA9ICd7fS1nY2MnLmZvcm1hdCggY29tcGlsZXIgKSApDQoJCXBhcmVu dF9lbnYuUmVwbGFjZSggQ1hYID0gJ3t9LWcrKycuZm9ybWF0KCBjb21waWxlciApICkNCgkJ cGFyZW50X2Vudi5SZXBsYWNlKCBMRCA9ICd7fS1sZCcuZm9ybWF0KCBjb21waWxlciApICkN CgkJcGFyZW50X2Vudi5SZXBsYWNlKCBBUiA9ICd7fS1hcicuZm9ybWF0KCBjb21waWxlciAp ICkNCgkJcGFyZW50X2Vudi5SZXBsYWNlKCBTVFJJUCA9ICd7fS1zdHJpcCcuZm9ybWF0KCBj b21waWxlciApICkNCgkJI3BhcmVudF9lbnYuUmVwbGFjZSggTUFLRSA9ICd7fS1tYWtlJy5m b3JtYXQoIGNvbXBpbGVyICkgKQ0KCQlwYXJlbnRfZW52LlJlcGxhY2UoIFJBTkxJQiA9ICd7 fS1yYW5saWInLmZvcm1hdCggY29tcGlsZXIgKSApDQoJCXBhcmVudF9lbnYuUmVwbGFjZSgg Tk0gPSAne30tbm0nLmZvcm1hdCggY29tcGlsZXIgKSApDQoJCXBhcmVudF9lbnYuUmVwbGFj ZSggUkMgPSAne30td2luZHJlcycuZm9ybWF0KCBjb21waWxlciApICkNCgkJcGFyZW50X2Vu di5SZXBsYWNlKCBETExUT09MID0gJ3t9LWRsbHRvb2wnLmZvcm1hdCggY29tcGlsZXIgKSAp DQoJCQ0KCQlwYXJlbnRfZW52LlJlcGxhY2UoIFNIQ0NGTEFHUyA9IFsgJyRDQ0ZMQUdTJyBd ICkgIyByZW1vdmUgLWZQSUMgaWYgaW5jbHVkZWQuIGp1c3QgdG8gc2lsZW5jZSBtaXNsZWFk aW5nIHdhcm5pbmdzDQoJCXBhcmVudF9lbnYuUmVwbGFjZSggU0hMSUJQUkVGSVggPSAnJyAp ICMgZml4IHByZWZpeCBzaW5jZSB0aGUgZW52aXJvbm1lbnQgaXMgc2V0IHVwIGZvciB1bml4 DQoJCXBhcmVudF9lbnYuUmVwbGFjZSggU0hMSUJTVUZGSVggPSAnLmRsbCcgKSAjIGZpeCBz dWZmaXggc2luY2UgdGhlIGVudmlyb25tZW50IGlzIHNldCB1cCBmb3IgdW5peA0KCQlwYXJl bnRfZW52LlJlcGxhY2UoIExJQlBSRUZJWCA9ICcnICkgIyBmaXggcHJlZml4IHNpbmNlIHRo ZSBlbnZpcm9ubWVudCBpcyBzZXQgdXAgZm9yIHVuaXgNCgkJcGFyZW50X2Vudi5SZXBsYWNl KCBMSUJQUkVGSVhFUyA9IFsgJycgXSApICMgZml4IHByZWZpeCBzaW5jZSB0aGUgZW52aXJv bm1lbnQgaXMgc2V0IHVwIGZvciB1bml4DQoJCXBhcmVudF9lbnYuUmVwbGFjZSggTElCU1VG RklYID0gJy5saWInICkNCgkJcGFyZW50X2Vudi5SZXBsYWNlKCBMSUJTVUZGSVhFUyA9IFsg Jy5saWInLCAnLmEnIF0gKQ0KCQkNCgkJcGFyZW50X2VudlsgJ09TX05BTUUnIF0gPSAnd2lu MzInDQoJCXBhcmVudF9lbnZbICdTWVNfUExBVEZPUk0nIF0gPSAnd2luMzInDQoJCXBhcmVu dF9lbnZbICdDUk9TU0NPTVBJTEVfSE9TVCcgXSA9IGNvbXBpbGVyDQoJCXBhcmVudF9lbnZb ICdDUk9TU0NPTVBJTEVfU1lTUk9PVCcgXSA9ICcvdXNyL3t9Jy5mb3JtYXQoIGNvbXBpbGVy ICkNCgkJDQoJCSMgcHJldmVudCBzdGRjKys2IHByb2JsZW1zIHdpdGggbWlzc25pZyBzeW1i b2xzIG9uIGRpZmZlcmVudCBjb21waWxlcnMNCgkJI3BhcmVudF9lbnYuQXBwZW5kKCBDUFBG TEFHUyA9IFsgJy1zdGQ9YysrMTEnIF0gKQ0KCQkjcGFyZW50X2Vudi5BcHBlbmQoIENST1NT Q09NUElMRV9DRkxBR1MgPSBbICctc3RkPWMrKzExJyBdICkNCgkJI3BhcmVudF9lbnYuQXBw ZW5kKCBDUk9TU0NPTVBJTEVfQ1BQRkxBR1MgPSBbICctc3RkPWMrKzExJyBdICkNCgkJDQoJ CXByaW50KCAnKioqIFVzaW5nIFdpbmRvd3MgNjQgQ3Jvc3MgQ29tcGlsZXInICkNCgkJDQoJ ZWxzZToNCgkJcGFyZW50X2VudiA9IEVudmlyb25tZW50KCBDUFBQQVRIPScuJywgTElCUEFU SD0nLicsIHRvb2xzPVsgdG9vbHMgXSApDQoJCXBhcmVudF9lbnZbICdPU19OQU1FJyBdID0g b3MubmFtZQ0KCQlwYXJlbnRfZW52WyAnU1lTX1BMQVRGT1JNJyBdID0gc3lzLnBsYXRmb3Jt DQoNCmVsaWYgc3lzLnBsYXRmb3JtID09ICd3aW4zMic6DQoJcHJpbnQoICdXaW5kb3dzIGRl dGVjdGVkLiBTZXR0aW5nIHVwIE1pbkdXNjQgdG9vbGNoYWluJyApDQoJcGFyZW50X2VudiA9 IEVudmlyb25tZW50KCBDUFBQQVRIPScuJywgTElCUEFUSD0nLicsIHRvb2xzPVsgJ21pbmd3 JyBdICkNCgkiIiJwYXJlbnRfZW52LlJlcGxhY2UoIENDID0gJ3g4Nl82NC13NjQtbWluZ3cz Mi1nY2MuZXhlJyApDQoJcGFyZW50X2Vudi5SZXBsYWNlKCBDWFggPSAneDg2XzY0LXc2NC1t aW5ndzMyLWcrKy5leGUnICkNCglwYXJlbnRfZW52LlJlcGxhY2UoIExEID0gJ3g4Nl82NC13 NjQtbWluZ3czMi1nKysuZXhlJyApDQoJcGFyZW50X2Vudi5SZXBsYWNlKCBBUiA9ICd4ODZf NjQtdzY0LW1pbmd3MzItYXInICkNCglwYXJlbnRfZW52LlJlcGxhY2UoIFNUUklQID0gJ3g4 Nl82NC13NjQtbWluZ3czMi1zdHJpcCcgKQ0KCXBhcmVudF9lbnYuUmVwbGFjZSggTUFLRSA9 ICd4ODZfNjQtdzY0LW1pbmd3MzItbWFrZScgKQ0KCXBhcmVudF9lbnYuUmVwbGFjZSggUkMg PSAneDg2XzY0LXc2NC1taW5ndzMyLXdpbmRyZXMnICkNCglwYXJlbnRfZW52LlJlcGxhY2Uo IFJDID0gJ3g4Nl82NC13NjQtbWluZ3czMi1kbGx0b29sJyApIiIiDQoJI3BhcmVudF9lbnYu QXBwZW5kKCBFTlYgPSB7ICdQQVRIJyA6ICdDOlxcTWluR1dcXHg4Nl82NC13NjQtbWluZ3cz MlxcYmluXFwnIH0gKQ0KCSNwYXJlbnRfZW52LkFwcGVuZCggRU5WID0geyAnUEFUSCcgOiAn QzpcTWluR1dcYmluO0M6XE1pbkdXXGxpYmV4ZWNcZ2NjXHg4Nl82NC13NjQtbWluZ3czMlw0 LjguMzsnICsgb3MuZW52aXJvblsgJ1BBVEgnIF0gfSApDQoJIyNwYXJlbnRfZW52LkFwcGVu ZCggRU5WID0geyAnUEFUSCcgOiAnQzpcTWluR1dcYmluOycgKyBvcy5lbnZpcm9uWyAnUEFU SCcgXSB9ICkNCglwYXJlbnRfZW52WyAnT1NfTkFNRScgXSA9IG9zLm5hbWUNCglwYXJlbnRf ZW52WyAnU1lTX1BMQVRGT1JNJyBdID0gc3lzLnBsYXRmb3JtDQoNCmVsc2U6DQoJcGFyZW50 X2VudiA9IEVudmlyb25tZW50KCBDUFBQQVRIPScuJywgTElCUEFUSD0nLicgKQ0KCXBhcmVu dF9lbnZbICdPU19OQU1FJyBdID0gb3MubmFtZQ0KCXBhcmVudF9lbnZbICdTWVNfUExBVEZP Uk0nIF0gPSBzeXMucGxhdGZvcm0NCg0KcGFyZW50X2Vudi5Ub29sKCdsb2dTdGRPdXQnKQ0K aWYgcGFyZW50X2VudlsnTG9nU3RkT3V0X0VuYWJsZWQnXToNCglwYXJlbnRfZW52WydMT0df U1REX09VVF9GSUxFJ10gPSBvcGVuKCdidWlsZC5sb2cnLCAndycpDQoNCnBhcmVudF9lbnYu VG9vbCgncnVuSXNvbGF0ZWQnKQ0KDQpwYXJlbnRfZW52LlRvb2woJ21hY29zX2J1bmRsZScp DQoNCkluaXRDb21tb24oIHBhcmVudF9lbnYgKQ0KI3ByaW50KCdvcy5uYW1lJywgb3MubmFt ZSkNCiNwcmludCgnc3lzLnBsYXRmb3JtJywgc3lzLnBsYXRmb3JtKQ0KDQojIGFwcGVuZCBm bGFncw0KcGFyZW50X2Vudi5SZXBsYWNlKCBNT0RVTEVfQ1BQRkxBR1MgPSBbXSApDQpwYXJl bnRfZW52LlJlcGxhY2UoIE1PRFVMRV9MSU5LRkxBR1MgPSBbXSApDQoNCmlmICdDUFBGTEFH UycgaW4gb3MuZW52aXJvbjoNCglwYXJlbnRfZW52LkFwcGVuZCggQ1BQRkxBR1MgPSBvcy5l bnZpcm9uWyAnQ1BQRkxBR1MnIF0gKQ0KDQppZiAnTERGTEFHUycgaW4gb3MuZW52aXJvbjoN CglwYXJlbnRfZW52LkFwcGVuZCggTElOS0ZMQUdTID0gb3MuZW52aXJvblsgJ0xERkxBR1Mn IF0gKQ0KDQppZiBwYXJlbnRfZW52WydPU1Bvc2l4J106DQoJcGFyZW50X2Vudi5BcHBlbmQo IENQUEZMQUdTID0gWyAnLURPU19VTklYJyBdICkNCg0KaWYgcGFyZW50X2VudlsnT1NXaW5k b3dzJ106DQoJcGFyZW50X2Vudi5BcHBlbmQoIENQUEZMQUdTID0gWyAnLURPU19XMzInLCAn LW13aW5kb3dzJyBdICkNCgkjIG1pbmd3IHJlcXVpcmVzIHRoaXMgdG8gcmVjb2duaXplIHdX aW5NYWluDQoJcGFyZW50X2Vudi5BcHBlbmQoIENQUEZMQUdTID0gWyAnLW11bmljb2RlJyBd ICkNCgkNCmVsaWYgcGFyZW50X2VudlsnT1NCZU9TJ106DQoJcGFyZW50X2Vudi5BcHBlbmQo IENQUEZMQUdTID0gWyAnLURPU19CRU9TJyBdICkNCglwYXJlbnRfZW52LkFwcGVuZCggTElO S0ZMQUdTID0gWyAnLUwvYm9vdC9jb21tb24vbGliJyBdICkNCgkNCmVsaWYgcGFyZW50X2Vu dlsnT1NNYWNPUyddOg0KCXBhcmVudF9lbnYuQXBwZW5kKENQUEZMQUdTID0gWyctRE9TX01B Q09TJ10pDQoNCmlmIG5vdCAocGFyZW50X2VudlsnT1NQb3NpeCddIG9yIHBhcmVudF9lbnZb J09TV2luZG93cyddIG9yIHBhcmVudF9lbnZbJ09TQmVPUyddIG9yIHBhcmVudF9lbnZbJ09T TWFjT1MnXSk6DQoJRXhpdCggJ05vIHN1cHBvcnRlZCBPUyBmb3VuZCEnKQ0KDQojIHBhcmFt ZXRlcnMNCiNwYXJhbXMgPSBWYXJpYWJsZXMoIFsgJ3BhcmFtZXRlcnMuY2FjaGUnLCAnY3Vz dG9tLnB5JyBdICkNCnBhcmFtcyA9IFZhcmlhYmxlcyggWyAnY3VzdG9tLnB5JyBdICkNCg0K cGFyYW1zLkFkZCggRW51bVZhcmlhYmxlKCAncGxhdGZvcm1fYW5kcm9pZCcsICdCdWlsZCBm b3IgQW5kcm9pZCBwbGF0Zm9ybScsICdubycsIFsnbm8nLCdhcm12NycsJ3g4NiddICkgKQ0K cGFyYW1zLkFkZCggQm9vbFZhcmlhYmxlKCAnd2l0aF90ZXN0cycsICdCdWlsZCBlbmdpbmUg dGVzdHMnLCBGYWxzZSApICkNCnBhcmFtcy5BZGQoIEJvb2xWYXJpYWJsZSggJ3dpdGhfZGVi dWcnLCAnQnVpbGQgd2l0aCBkZWJ1ZyBzeW1ib2xzIGZvciBHREIgdXNhZ2UnLCBGYWxzZSAp ICkNCnBhcmFtcy5BZGQoIEJvb2xWYXJpYWJsZSggJ3dpdGhfd2FybmVycm9ycycsICdUcmVh dCB3YXJuaW5ncyBhcyBlcnJvcnMgKCBkZXYtYnVpbGRzICknLCBGYWxzZSApICkNCnBhcmFt cy5BZGQoIEJvb2xWYXJpYWJsZSggJ3dpdGhfc2FuaXRpemUnLCAnRW5hYmxlIHNhbml0aXpp bmcgKGRldi1idWlsZHMpJywgRmFsc2UgKSApDQpwYXJhbXMuQWRkKCBCb29sVmFyaWFibGUo ICd3aXRoX3Nhbml0aXplX3RocmVhZCcsICdFbmFibGUgdGhyZWFkIHNhbml0aXppbmcgKGRl di1idWlsZHMpJywgRmFsc2UgKSApDQpwYXJhbXMuQWRkKCBCb29sVmFyaWFibGUoICd3aXRo X3ZlcmJvc2UnLCAnVmVyYm9zZSBjb21waWxhdGlvbiBzaG93aW5nIGNvbW1hbmQgbGluZXMo IGRldi1idWlsZHMgKScsIEZhbHNlICkgKQ0KcGFyYW1zLkFkZChTdHJpbmdWYXJpYWJsZSgn Zm9yY2VfdmVyc2lvbicsICdGb3JjZSB2ZXJzaW9uIChlbXB0eSB0byBkaXNhYmxlKScsICcn KSkNCg0KcGFyYW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAnd2l0aF9zeXN0ZW1femxpYics ICdVc2UgU3lzdGVtIFpsaWInICkgKQ0KcGFyYW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAn d2l0aF9zeXN0ZW1fbGlicG5nJywgJ1VzZSBTeXN0ZW0gbGlicG5nJyApICkNCnBhcmFtcy5B ZGQoIFRlcm5hcnlWYXJpYWJsZSggJ3dpdGhfc3lzdGVtX3NuZGlvJywgJ1VzZSBTeXN0ZW0g c25kaW8nICkgKQ0KcGFyYW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAnd2l0aF9zeXN0ZW1f bGliYXBuZycsICdVc2UgU3lzdGVtIGxpYmFwbmcnICkgKQ0KcGFyYW1zLkFkZCggVGVybmFy eVZhcmlhYmxlKCAnd2l0aF9zeXN0ZW1fbGlianBlZycsICdVc2UgU3lzdGVtIEpQRUcnICkg KQ0KcGFyYW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAnd2l0aF9zeXN0ZW1fb3BlbmFsJywg J1VzZSBTeXN0ZW0gT3BlbkFMJyApICkNCnBhcmFtcy5BZGQoIExpc3RWYXJpYWJsZSggJ3dp dGhfb3BlbmFsX2JhY2tlbmRzJywgJ1doZW4gY29tcGlsaW5nIE9wZW5BTCB3aGF0IGJhY2tl bmRzIGFyZSByZXF1aXJlZCcsDQoJW10sIFsnYWxzYScsICdwdWxzZWF1ZGlvJywgJ3BvcnRh dWRpbycsICdvc3MnXSApICkNCnBhcmFtcy5BZGQoIFRlcm5hcnlWYXJpYWJsZSggJ3dpdGhf c3lzdGVtX2xpYm9nZycsICdVc2UgU3lzdGVtIGxpYm9nZycgKSApDQpwYXJhbXMuQWRkKCBU ZXJuYXJ5VmFyaWFibGUoICd3aXRoX3N5c3RlbV9saWJ2b3JiaXMnLCAnVXNlIFN5c3RlbSBs aWJ2b3JiaXMnICkgKQ0KcGFyYW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAnd2l0aF9zeXN0 ZW1fbGlidGhlb3JhJywgJ1VzZSBTeXN0ZW0gbGlidGhlb3JhJyApICkNCnBhcmFtcy5BZGQo IFRlcm5hcnlWYXJpYWJsZSggJ3dpdGhfc3lzdGVtX2ZveCcsICdVc2UgU3lzdGVtIEZPWCBU b29sa2l0JyApICkNCnBhcmFtcy5BZGQoIFRlcm5hcnlWYXJpYWJsZSggJ3dpdGhfc3lzdGVt X2RyYWdvbnNjcmlwdCcsICdVc2UgU3lzdGVtIERyYWdvblNjcmlwdCcgKSApDQpwYXJhbXMu QWRkKCBQYXRoVmFyaWFibGUoICd3aXRoX2RyYWdvbnNjcmlwdF9pbmMnLA0KCSdQYXRoIHRv IERyYWdvblNjcmlwdCBpbmNsdWRlIGZpbGVzIG9yIGVtcHR5IHRvIHVzZSBzeXN0ZW0gZGVm YXVsdCcsDQoJJycsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KcGFyYW1zLkFkZCgg UGF0aFZhcmlhYmxlKCAnd2l0aF9kcmFnb25zY3JpcHRfbGliJywNCgknUGF0aCB0byBEcmFn b25TY3JpcHQgbGlicmFyeSBmaWxlcyBvciBlbXB0eSB0byB1c2Ugc3lzdGVtIGRlZmF1bHQn LA0KCScnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCnBhcmFtcy5BZGQoIFRlcm5h cnlWYXJpYWJsZSggJ3dpdGhfc3lzdGVtX2xpYmZmaScsICdVc2UgU3lzdGVtIGxpYmZmaScg KSApDQpwYXJhbXMuQWRkKCBUZXJuYXJ5VmFyaWFibGUoICd3aXRoX3N5c3RlbV9saWJsdGRs JywgJ1VzZSBTeXN0ZW0gbGlibHRkbCcgKSApDQpwYXJhbXMuQWRkKCBUZXJuYXJ5VmFyaWFi bGUoICd3aXRoX3N5c3RlbV9saWJzaWdzZWd2JywgJ1VzZSBTeXN0ZW0gbGlic2lnc2Vndicg KSApDQpwYXJhbXMuQWRkKCBUZXJuYXJ5VmFyaWFibGUoICd3aXRoX3N5c3RlbV9zbWFsbHRh bGsnLCAnVXNlIFN5c3RlbSBTbWFsbHRhbGsnICkgKQ0KcGFyYW1zLkFkZCggVGVybmFyeVZh cmlhYmxlKCAnd2l0aF9zeXN0ZW1fbGliZXZkZXYnLCAnVXNlIFN5c3RlbSBsaWJldmRldicg KSApDQpwYXJhbXMuQWRkKCBUZXJuYXJ5VmFyaWFibGUoICd3aXRoX3N5c3RlbV9saWJ1c2In LCAnVXNlIFN5c3RlbSBsaWJ1c2InICkgKQ0KcGFyYW1zLkFkZCggVGVybmFyeVZhcmlhYmxl KCAnd2l0aF9zeXN0ZW1fbGliaGlkYXBpJywgJ1VzZSBTeXN0ZW0gbGliaGlkYXBpJyApICkN CnBhcmFtcy5BZGQoIFRlcm5hcnlWYXJpYWJsZSggJ3dpdGhfc3lzdGVtX2xpYm9wZW5obWQn LCAnVXNlIFN5c3RlbSBsaWJvcGVuaG1kJyApICkNCnBhcmFtcy5BZGQoIFRlcm5hcnlWYXJp YWJsZSggJ3dpdGhfc3lzdGVtX2ZmdHcnLCAnVXNlIFN5c3RlbSBmZnR3JyApICkNCg0KcGFy YW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAnd2l0aF9vcGVuZ2wnLCAnVXNlIE9wZW5HTCcg KSApDQpwYXJhbXMuQWRkKCBUZXJuYXJ5VmFyaWFibGUoICd3aXRoX3B5dGhvbicsICdVc2Ug UHl0aG9uJyApICkNCnBhcmFtcy5BZGQoIFRlcm5hcnlWYXJpYWJsZSggJ3dpdGhfbnBhcGlz ZGsnLCAnVXNlIE5QQVBJIFNESycgKSApDQpwYXJhbXMuQWRkKCBUZXJuYXJ5VmFyaWFibGUo ICdidWlsZF9hdWRpb19vcGVuYWwnLCAnQnVpbGQgT3BlbkFMIEF1ZGlvIE1vZHVsZScgKSAp DQpwYXJhbXMuQWRkKCBUZXJuYXJ5VmFyaWFibGUoICdidWlsZF9jcl9iYXNpYycsICdCdWls ZCBCYXNpYyBDcmFzaC1SZWNvdmVyeSBNb2R1bGUnICkgKQ0KcGFyYW1zLkFkZCggVGVybmFy eVZhcmlhYmxlKCAnYnVpbGRfZ3JhcGhpY3Nfb3BlbmdsJywgJ0J1aWxkIE9wZW5HTCBHcmFw aGljcyBNb2R1bGUnICkgKQ0KcGFyYW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAnYnVpbGRf aW1hZ2VfcG5nJywgJ0J1aWxkIFBORyBJbWFnZSBNb2R1bGUnICkgKQ0KcGFyYW1zLkFkZCgg VGVybmFyeVZhcmlhYmxlKCAnYnVpbGRfaW1hZ2VfcG5nM2QnLCAnQnVpbGQgUE5HLTNEIElt YWdlIE1vZHVsZScgKSApDQpwYXJhbXMuQWRkKCBUZXJuYXJ5VmFyaWFibGUoICdidWlsZF9p bWFnZV9qcGVnJywgJ0J1aWxkIEpQRUcgSW1hZ2UgTW9kdWxlJyApICkNCnBhcmFtcy5BZGQo IFRlcm5hcnlWYXJpYWJsZSggJ2J1aWxkX2lucHV0X3gnLCAnQnVpbGQgWCBJbnB1dCBNb2R1 bGUnICkgKQ0KcGFyYW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAnYnVpbGRfaW5wdXRfdzMy JywgJ0J1aWxkIFdpbmRvd3MgSW5wdXQgTW9kdWxlJyApICkNCnBhcmFtcy5BZGQoIFRlcm5h cnlWYXJpYWJsZSggJ2J1aWxkX2lucHV0X2Jlb3MnLCAnQnVpbGQgQmVPUyBJbnB1dCBNb2R1 bGUnICkgKQ0KcGFyYW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAnYnVpbGRfaW5wdXRfbWFj b3MnLCAnQnVpbGQgTWFjT1MgSW5wdXQgTW9kdWxlJyApICkNCnBhcmFtcy5BZGQoIFRlcm5h cnlWYXJpYWJsZSggJ2J1aWxkX2lucHV0X2FuZHJvaWQnLCAnQnVpbGQgQW5kcm9pZCBJbnB1 dCBNb2R1bGUnICkgKQ0KcGFyYW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAnYnVpbGRfcGh5 c2ljc19idWxsZXQnLCAnQnVpbGQgQnVsbGV0IFBoeXNpY3MgTW9kdWxlJywgVHJ1ZSApICkN CnBhcmFtcy5BZGQoIFRlcm5hcnlWYXJpYWJsZSggJ2J1aWxkX3NjcmlwdF9kcycsICdCdWls ZCBEcmFnb25TY3JpcHQgU2NyaXB0IE1vZHVsZScgKSApDQpwYXJhbXMuQWRkKCBUZXJuYXJ5 VmFyaWFibGUoICdidWlsZF9zY3JpcHRfcHl0aG9uJywgJ0J1aWxkIFB5dGhvbiBTY3JpcHQg TW9kdWxlJyApICkNCnBhcmFtcy5BZGQoIFRlcm5hcnlWYXJpYWJsZSggJ2J1aWxkX3Njcmlw dF9zbWFsbHRhbGsnLCAnQnVpbGQgU21hbGx0YWxrIFNjcmlwdCBNb2R1bGUnICkgKQ0KcGFy YW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAnYnVpbGRfc291bmRfb2dnJywgJ0J1aWxkIE9H RyBWb3JiaXMgU291bmQgTW9kdWxlJyApICkNCnBhcmFtcy5BZGQoIFRlcm5hcnlWYXJpYWJs ZSggJ2J1aWxkX3ZpZGVvX3RoZW9yYScsICdCdWlsZCBUaGVvcmEgVmlkZW8gTW9kdWxlJyAp ICkNCnBhcmFtcy5BZGQoIFRlcm5hcnlWYXJpYWJsZSggJ2J1aWxkX3ZpZGVvX2FwbmcnLCAn QnVpbGQgQW5pbWF0ZWQgUE5HIFZpZGVvIE1vZHVsZScgKSApDQpwYXJhbXMuQWRkKCBUZXJu YXJ5VmFyaWFibGUoICdidWlsZF9pZ2RlJywgJ0J1aWxkIElHREUnICkgKQ0KcGFyYW1zLkFk ZCggVGVybmFyeVZhcmlhYmxlKCAnYnVpbGRfZ3VpbGF1bmNoZXInLCAnQnVpbGQgR1VJIExh dW5jaGVyJyApICkNCnBhcmFtcy5BZGQoIFRlcm5hcnlWYXJpYWJsZSggJ2J1aWxkX2xhdW5j aGVyX2FuZHJvaWQnLCAnQnVpbGQgQW5kcm9pZCBMYXVuY2hlcicgKSApDQpwYXJhbXMuQWRk KCBUZXJuYXJ5VmFyaWFibGUoICdidWlsZF9hcmNoaXZlX2RlbGdhJywgJ0J1aWxkIERFTEdB IEFyY2hpdmUgTW9kdWxlJyApICkNCg0KcGFyYW1zLkFkZCggRW51bVZhcmlhYmxlKCAnYXJj aGl2ZV9mb3JtYXQnLCAnQXJjaGl2ZSBmaWxlIGZvcm1hdCcsICd0YXJiejInLCBbJ3RhcmJ6 MicsICd6aXAnXSApICkNCnBhcmFtcy5BZGQoIFN0cmluZ1ZhcmlhYmxlKCAnYXJjaGl2ZV9u YW1lX2VuZ2luZScsDQoJJ0FyY2hpdmUgZmlsZSBuYW1lIHdpdGhvdXQgZXh0ZW5zaW9uIGZv ciBEcmFnW2VuXWdpbmUgYXJjaGl2ZScsICdkcmFnZW5naW5lJyApICkNCnBhcmFtcy5BZGQo IFN0cmluZ1ZhcmlhYmxlKCAnYXJjaGl2ZV9uYW1lX2VuZ2luZV9kZXYnLA0KCSdBcmNoaXZl IGZpbGUgbmFtZSB3aXRob3V0IGV4dGVuc2lvbiBmb3IgRHJhZ1tlbl1naW5lIERldmVsb3Bt ZW50IGFyY2hpdmUnLCAnZHJhZ2VuZ2luZS1kZXYnICkgKQ0KcGFyYW1zLkFkZCggU3RyaW5n VmFyaWFibGUoICdhcmNoaXZlX25hbWVfaWdkZScsDQoJJ0FyY2hpdmUgZmlsZSBuYW1lIHdp dGhvdXQgZXh0ZW5zaW9uIGZvciBJR0RFIGFyY2hpdmUnLCAnZGVpZ2RlJyApICkNCnBhcmFt cy5BZGQoIFN0cmluZ1ZhcmlhYmxlKCAnYXJjaGl2ZV9uYW1lX2lnZGVfZGV2JywNCgknQXJj aGl2ZSBmaWxlIG5hbWUgd2l0aG91dCBleHRlbnNpb24gZm9yIElHREUgRGV2ZWxvcG1lbnQg YXJjaGl2ZScsICdkZWlnZGVfZGV2JyApICkNCnBhcmFtcy5BZGQoIFN0cmluZ1ZhcmlhYmxl KCAnYXJjaGl2ZV9uYW1lX3NwZWNpYWwnLA0KCSdBcmNoaXZlIGZpbGUgbmFtZSB3aXRob3V0 IGV4dGVuc2lvbiBmb3IgU3BlY2lhbCBhcmNoaXZlJywgJ2Rlc3BlY2lhbCcgKSApDQpwYXJh bXMuQWRkKCBTdHJpbmdWYXJpYWJsZSggJ2luc3RhbGxlcl9uYW1lX2VuZ2luZScsDQoJJ0lu c3RhbGxlciBmaWxlIG5hbWUgd2l0aG91dCBleHRlbnNpb24gZm9yIERyYWdbZW5dZ2luZSBp bnN0YWxsZXInLCAnaW5zdGFsbC1kcmFnZW5naW5lJyApICkNCnBhcmFtcy5BZGQoIFN0cmlu Z1ZhcmlhYmxlKCAnaW5zdGFsbGVyX25hbWVfZW5naW5lX2RldicsDQoJJ0luc3RhbGxlciBm aWxlIG5hbWUgd2l0aG91dCBleHRlbnNpb24gZm9yIERyYWdbZW5dZ2luZSBEZXZlbG9wbWVu dCBpbnN0YWxsZXInLCAnaW5zdGFsbC1kcmFnZW5naW5lLWRldicgKSApDQpwYXJhbXMuQWRk KCBTdHJpbmdWYXJpYWJsZSggJ2luc3RhbGxlcl9uYW1lX2lnZGUnLA0KCSdJbnN0YWxsZXIg ZmlsZSBuYW1lIHdpdGhvdXQgZXh0ZW5zaW9uIGZvciBJR0RFIGluc3RhbGxlcicsICdpbnN0 YWxsLWRlaWdkZScgKSApDQpwYXJhbXMuQWRkKCBTdHJpbmdWYXJpYWJsZSggJ2luc3RhbGxl cl9uYW1lX2lnZGVfZGV2JywNCgknSW5zdGFsbGVyIGZpbGUgbmFtZSB3aXRob3V0IGV4dGVu c2lvbiBmb3IgSUdERSBEZXZlbG9wbWVudCBpbnN0YWxsZXInLCAnaW5zdGFsbC1kZWlnZGUt ZGV2JyApICkNCg0KDQppZiBwYXJlbnRfZW52WydPU01hY09TJ106DQoJcGFyYW1zLkFkZCgg VGVybmFyeVZhcmlhYmxlKCAnd2l0aF9kbCcsICdVc2UgdGhlIGR5bmFtaWMgbGlicmFyeSBz eXN0ZW0nICkgKQ0KCXBhcmFtcy5BZGQoIFRlcm5hcnlWYXJpYWJsZSggJ3dpdGhfcHRocmVh ZCcsICdVc2UgcHRocmVhZCcgKSApDQoJcGFyYW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAn d2l0aF94JywgJ1VzZSB0aGUgWCBXaW5kb3cgU3lzdGVtJyApICkNCgkNCglwYXJhbXMuQWRk KEVudW1WYXJpYWJsZSgnaWdkZV90b29sa2l0JywgJ1Rvb2xLaXQgdG8gdXNlIGZvciBidWls ZGluZyBJR0RFJywgJ251bGwnLCBbJ251bGwnXSkpDQoJDQoJcGFyYW1zLkFkZCggUGF0aFZh cmlhYmxlKCAncHJlZml4JywgJ1N5c3RlbSBwYXRoJywgJy91c3InLCBQYXRoVmFyaWFibGUu UGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdsaWJkaXInLCAn U3lzdGVtIGxpYnJhcmllcycsICcke3ByZWZpeH0vbGliJywgUGF0aFZhcmlhYmxlLlBhdGhB Y2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAnaW5jbHVkZWRpcicsICdT eXN0ZW0gaW5jbHVkZXMnLCAnJHtwcmVmaXh9L2luY2x1ZGUnLCBQYXRoVmFyaWFibGUuUGF0 aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdkYXRhZGlyJywgJ1N5 c3RlbSBzaGFyZXMnLCAnJHtwcmVmaXh9L3NoYXJlJywgUGF0aFZhcmlhYmxlLlBhdGhBY2Nl cHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAnc3lzY29uZmRpcicsICdTeXN0 ZW0gY29uZmlndXJhdGlvbicsICcvZXRjJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSAp DQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAnZXhlY2RpcicsICdTeXN0ZW0gYmluYXJp ZXMnLCAnL0FwcGxpY2F0aW9ucycsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBh cmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3N5c3ZhcmRpcicsICdTeXN0ZW0gdmFyJywgJyR7 cHJlZml4fS92YXInLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRk KCBQYXRoVmFyaWFibGUoICdjYWNoZWRpcicsICdTeXN0ZW0gY2FjaGUnLCAnJHtzeXN2YXJk aXJ9L2xpYicsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KDQoJcGFyYW1zLkFkZCgg UGF0aFZhcmlhYmxlKCAncGF0aF9kZV9iaW4nLCAnUGF0aCB0byB0aGUgRHJhZ1tlbl1naW5l IGJpbmFyaWVzJywNCgkJJyR7ZXhlY2Rpcn0nLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCAp ICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2RlX2xpYicsICdQYXRoIHRv IHRoZSBEcmFnW2VuXWdpbmUgbGlicmFyaWVzJywNCgkJJyR7bGliZGlyfScsIFBhdGhWYXJp YWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhf ZGVfaW5jbHVkZScsICdQYXRoIHRvIHRoZSBEcmFnW2VuXWdpbmUgaGVhZGVycycsDQoJCSck e2luY2x1ZGVkaXJ9L2RyYWdlbmdpbmUnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkN CglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2RlX2NvbmZpZycsICdQYXRoIHRv IHRoZSBEcmFnW2VuXWdpbmUgY29uZmlndXJhdGlvbicsDQoJCScke3N5c2NvbmZkaXJ9L2Ry YWdlbmdpbmUnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQ YXRoVmFyaWFibGUoICdwYXRoX2RlX2RhdGEnLCAnUGF0aCB0byB0aGUgRHJhZ1tlbl1naW5l IGRhdGEnLA0KCQknJHtsaWJkaXJ9L2RyYWdlbmdpbmUnLCBQYXRoVmFyaWFibGUuUGF0aEFj Y2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2RlX3NoYXJlJywg J1BhdGggdG8gdGhlIERyYWdbZW5dZ2luZSBzaGFyZXMnLA0KCQknJHtkYXRhZGlyfS9kcmFn ZW5naW5lJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0 aFZhcmlhYmxlKCAncGF0aF9kZV9jYWNoZScsICdQYXRoIHRvIHRoZSBEcmFnW2VuXWdpbmUg Y2FjaGUnLA0KCQknJHtjYWNoZWRpcn0vZHJhZ2VuZ2luZScsIFBhdGhWYXJpYWJsZS5QYXRo QWNjZXB0ICkgKQ0KDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0aF9pZ2RlX2Jp bicsICdQYXRoIHRvIHRoZSBJR0RFIGJpbmFyaWVzJywNCgkJJyR7ZXhlY2Rpcn0nLCBQYXRo VmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdw YXRoX2lnZGVfbGliJywgJ1BhdGggdG8gdGhlIElHREUgbGlicmFyaWVzJywNCgkJJyR7bGli ZGlyfScsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBhdGhW YXJpYWJsZSggJ3BhdGhfaWdkZV9pbmNsdWRlJywgJ1BhdGggdG8gdGhlIElHREUgaGVhZGVy cycsDQoJCScke2luY2x1ZGVkaXJ9L2RlaWdkZScsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0 ICkgKQ0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfaWdkZV9jb25maWcnLCAn UGF0aCB0byB0aGUgSUdERSBjb25maWd1cmF0aW9uJywNCgkJJyR7c3lzY29uZmRpcn0vZGVp Z2RlJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZh cmlhYmxlKCAncGF0aF9pZ2RlX2RhdGEnLCAnUGF0aCB0byB0aGUgSUdERSBkYXRhJywNCgkJ JyR7bGliZGlyfS9kZWlnZGUnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJh bXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2lnZGVfc2hhcmUnLCAnUGF0aCB0byB0aGUg SUdERSBzaGFyZXMnLA0KCQknJHtkYXRhZGlyfS9kZWlnZGUnLCBQYXRoVmFyaWFibGUuUGF0 aEFjY2VwdCApICkNCg0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfbGF1bmNo ZXJfYmluJywgJ1BhdGggdG8gdGhlIExhdW5jaGVyIGJpbmFyaWVzJywNCgkJJyR7ZXhlY2Rp cn0nLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFy aWFibGUoICdwYXRoX2xhdW5jaGVyX2Jpbl9saWInLCAnUGF0aCB0byB0aGUgTGF1bmNoZXIg YmluYXJ5IGxpYnJhcmllcycsDQoJCScke2xpYmRpcn0nLCBQYXRoVmFyaWFibGUuUGF0aEFj Y2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2xhdW5jaGVyX2Nv bmZpZycsICdQYXRoIHRvIHRoZSBMYXVuY2hlciBjb25maWd1cmF0aW9uJywNCgkJJyR7c3lz Y29uZmRpcn0vZGVsYXVuY2hlcicsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBh cmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfbGF1bmNoZXJfZGF0YScsICdQYXRoIHRv IHRoZSBMYXVuY2hlciBkYXRhJywNCgkJJyR7bGliZGlyfS9kZWxhdW5jaGVyJywgUGF0aFZh cmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0 aF9sYXVuY2hlcl9zaGFyZScsICdQYXRoIHRvIHRoZSBMYXVuY2hlciBzaGFyZXMnLA0KCQkn JHtkYXRhZGlyfS9kZWxhdW5jaGVyJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJ cGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0aF9sYXVuY2hlcl9nYW1lcycsICdQYXRo IHRvIHRoZSBMYXVuY2hlciBnYW1lcycsDQoJCScvb3B0L2RlbGF1bmNoZXIvZ2FtZXMnLCBQ YXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCg0KCQ0KZWxpZiBwYXJlbnRfZW52WydPU0Jl T1MnXToNCglwYXJhbXMuQWRkKCBUZXJuYXJ5VmFyaWFibGUoICd3aXRoX2RsJywgJ1VzZSB0 aGUgZHluYW1pYyBsaWJyYXJ5IHN5c3RlbScgKSApDQoJcGFyYW1zLkFkZCggVGVybmFyeVZh cmlhYmxlKCAnd2l0aF9wdGhyZWFkJywgJ1VzZSBwdGhyZWFkJyApICkNCglwYXJhbXMuQWRk KCBUZXJuYXJ5VmFyaWFibGUoICd3aXRoX3gnLCAnVXNlIHRoZSBYIFdpbmRvdyBTeXN0ZW0n ICkgKQ0KCQ0KCXBhcmFtcy5BZGQoRW51bVZhcmlhYmxlKCdpZ2RlX3Rvb2xraXQnLCAnVG9v bEtpdCB0byB1c2UgZm9yIGJ1aWxkaW5nIElHREUnLCAnbnVsbCcsIFsnbnVsbCddKSkNCgkN CglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwcmVmaXgnLCAnU3lzdGVtIHBhdGgnLCAn L2Jvb3Qvc3lzdGVtJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFk ZCggUGF0aFZhcmlhYmxlKCAnbGliZGlyJywgJ1N5c3RlbSBsaWJyYXJpZXMnLCAnJHtwcmVm aXh9L2xpYicsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBh dGhWYXJpYWJsZSggJ2luY2x1ZGVkaXInLCAnU3lzdGVtIGluY2x1ZGVzJywgJyR7cHJlZml4 fS9kZXZlbG9wL2luY2x1ZGUnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJh bXMuQWRkKCBQYXRoVmFyaWFibGUoICdkYXRhZGlyJywgJ1N5c3RlbSBzaGFyZXMnLCAnJHtw cmVmaXh9L2RhdGEnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRk KCBQYXRoVmFyaWFibGUoICdzeXNjb25mZGlyJywgJ1N5c3RlbSBjb25maWd1cmF0aW9uJywg JyR7cHJlZml4fS9zZXR0aW5ncycsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBh cmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ2V4ZWNkaXInLCAnU3lzdGVtIGJpbmFyaWVzJywg JyR7cHJlZml4fS9iaW4nLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMu QWRkKCBQYXRoVmFyaWFibGUoICdzeXN2YXJkaXInLCAnU3lzdGVtIHZhcicsICcke3ByZWZp eH0vdmFyJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0 aFZhcmlhYmxlKCAnY2FjaGVkaXInLCAnU3lzdGVtIGNhY2hlJywgJyR7cHJlZml4fS9jYWNo ZScsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBhdGhWYXJp YWJsZSggJ2RvY2RpcicsICdTeXN0ZW0gZG9jdW1lbnRhdGlvbicsICcke3ByZWZpeH0vZG9j dW1lbnRhdGlvbicsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KDQoJcGFyYW1zLkFk ZCggUGF0aFZhcmlhYmxlKCAncGF0aF9kZV9iaW4nLCAnUGF0aCB0byB0aGUgRHJhZ1tlbl1n aW5lIGJpbmFyaWVzJywNCgkJJyR7ZXhlY2Rpcn0nLCBQYXRoVmFyaWFibGUuUGF0aEFjY2Vw dCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2RlX2xpYicsICdQYXRo IHRvIHRoZSBEcmFnW2VuXWdpbmUgbGlicmFyaWVzJywNCgkJJyR7bGliZGlyfScsIFBhdGhW YXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3Bh dGhfZGVfaW5jbHVkZScsICdQYXRoIHRvIHRoZSBEcmFnW2VuXWdpbmUgaGVhZGVycycsDQoJ CScke2luY2x1ZGVkaXJ9L2RyYWdlbmdpbmUnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCAp ICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2RlX2NvbmZpZycsICdQYXRo IHRvIHRoZSBEcmFnW2VuXWdpbmUgY29uZmlndXJhdGlvbicsDQoJCScke3N5c2NvbmZkaXJ9 L2RyYWdlbmdpbmUnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRk KCBQYXRoVmFyaWFibGUoICdwYXRoX2RlX2RhdGEnLCAnUGF0aCB0byB0aGUgRHJhZ1tlbl1n aW5lIGRhdGEnLA0KCQknJHtsaWJkaXJ9L2RyYWdlbmdpbmUnLCBQYXRoVmFyaWFibGUuUGF0 aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2RlX3NoYXJl JywgJ1BhdGggdG8gdGhlIERyYWdbZW5dZ2luZSBzaGFyZXMnLA0KCQknJHtkYXRhZGlyfS9k cmFnZW5naW5lJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCgg UGF0aFZhcmlhYmxlKCAncGF0aF9kZV9jYWNoZScsICdQYXRoIHRvIHRoZSBEcmFnW2VuXWdp bmUgY2FjaGUnLA0KCQknJHtjYWNoZWRpcn0vZHJhZ2VuZ2luZScsIFBhdGhWYXJpYWJsZS5Q YXRoQWNjZXB0ICkgKQ0KDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0aF9pZ2Rl X2JpbicsICdQYXRoIHRvIHRoZSBJR0RFIGJpbmFyaWVzJywNCgkJJyR7ZXhlY2Rpcn0nLCBQ YXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUo ICdwYXRoX2lnZGVfbGliJywgJ1BhdGggdG8gdGhlIElHREUgbGlicmFyaWVzJywNCgkJJyR7 bGliZGlyfScsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBh dGhWYXJpYWJsZSggJ3BhdGhfaWdkZV9pbmNsdWRlJywgJ1BhdGggdG8gdGhlIElHREUgaGVh ZGVycycsDQoJCScke2luY2x1ZGVkaXJ9L2RlaWdkZScsIFBhdGhWYXJpYWJsZS5QYXRoQWNj ZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfaWdkZV9jb25maWcn LCAnUGF0aCB0byB0aGUgSUdERSBjb25maWd1cmF0aW9uJywNCgkJJyR7c3lzY29uZmRpcn0v ZGVpZ2RlJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0 aFZhcmlhYmxlKCAncGF0aF9pZ2RlX2RhdGEnLCAnUGF0aCB0byB0aGUgSUdERSBkYXRhJywN CgkJJyR7bGliZGlyfS9kZWlnZGUnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglw YXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2lnZGVfc2hhcmUnLCAnUGF0aCB0byB0 aGUgSUdERSBzaGFyZXMnLA0KCQknJHtkYXRhZGlyfS9kZWlnZGUnLCBQYXRoVmFyaWFibGUu UGF0aEFjY2VwdCApICkNCg0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfbGF1 bmNoZXJfYmluJywgJ1BhdGggdG8gdGhlIExhdW5jaGVyIGJpbmFyaWVzJywNCgkJJyR7ZXhl Y2Rpcn0nLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRo VmFyaWFibGUoICdwYXRoX2xhdW5jaGVyX2Jpbl9saWInLCAnUGF0aCB0byB0aGUgTGF1bmNo ZXIgYmluYXJ5IGxpYnJhcmllcycsDQoJCScke2xpYmRpcn0nLCBQYXRoVmFyaWFibGUuUGF0 aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2xhdW5jaGVy X2NvbmZpZycsICdQYXRoIHRvIHRoZSBMYXVuY2hlciBjb25maWd1cmF0aW9uJywNCgkJJyR7 c3lzY29uZmRpcn0vZGVsYXVuY2hlcicsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0K CXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfbGF1bmNoZXJfZGF0YScsICdQYXRo IHRvIHRoZSBMYXVuY2hlciBkYXRhJywNCgkJJyR7bGliZGlyfS9kZWxhdW5jaGVyJywgUGF0 aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAn cGF0aF9sYXVuY2hlcl9zaGFyZScsICdQYXRoIHRvIHRoZSBMYXVuY2hlciBzaGFyZXMnLA0K CQknJHtkYXRhZGlyfS9kZWxhdW5jaGVyJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSAp DQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0aF9sYXVuY2hlcl9nYW1lcycsICdQ YXRoIHRvIHRoZSBMYXVuY2hlciBnYW1lcycsDQoJCScvYm9vdC9zeXN0ZW0vZGVsYXVuY2hl ci9nYW1lcycsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCQ0KZWxpZiBwYXJlbnRf ZW52WydPU1Bvc2l4J106DQoJcGFyYW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAnd2l0aF9k bCcsICdVc2UgdGhlIGR5bmFtaWMgbGlicmFyeSBzeXN0ZW0nICkgKQ0KCXBhcmFtcy5BZGQo IFRlcm5hcnlWYXJpYWJsZSggJ3dpdGhfcHRocmVhZCcsICdVc2UgcHRocmVhZCcgKSApDQoJ cGFyYW1zLkFkZCggVGVybmFyeVZhcmlhYmxlKCAnd2l0aF94JywgJ1VzZSB0aGUgWCBXaW5k b3cgU3lzdGVtJyApICkNCgkNCglwYXJhbXMuQWRkKEVudW1WYXJpYWJsZSgnaWdkZV90b29s a2l0JywgJ1Rvb2xLaXQgdG8gdXNlIGZvciBidWlsZGluZyBJR0RFJywgJ2ZveCcsIFsnZm94 JywnbnVsbCddKSkNCgkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwcmVmaXgnLCAn U3lzdGVtIHBhdGgnLCAnL3VzcicsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBh cmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ2xpYmRpcicsICdTeXN0ZW0gbGlicmFyaWVzJywg JyR7cHJlZml4fS9saWInLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMu QWRkKCBQYXRoVmFyaWFibGUoICdpbmNsdWRlZGlyJywgJ1N5c3RlbSBpbmNsdWRlcycsICck e3ByZWZpeH0vaW5jbHVkZScsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBhcmFt cy5BZGQoIFBhdGhWYXJpYWJsZSggJ2RhdGFkaXInLCAnU3lzdGVtIHNoYXJlcycsICcke3By ZWZpeH0vc2hhcmUnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRk KCBQYXRoVmFyaWFibGUoICdzeXNjb25mZGlyJywgJ1N5c3RlbSBjb25maWd1cmF0aW9uJywg Jy9ldGMnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRo VmFyaWFibGUoICdleGVjZGlyJywgJ1N5c3RlbSBiaW5hcmllcycsICcke3ByZWZpeH0vYmlu JywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlh YmxlKCAnc3lzdmFyZGlyJywgJ1N5c3RlbSB2YXInLCAnL3ZhcicsIFBhdGhWYXJpYWJsZS5Q YXRoQWNjZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ2NhY2hlZGlyJywg J1N5c3RlbSBjYWNoZScsICcke3N5c3ZhcmRpcn0vbGliJywgUGF0aFZhcmlhYmxlLlBhdGhB Y2NlcHQgKSApDQoJDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0aF9kZV9iaW4n LCAnUGF0aCB0byB0aGUgRHJhZ1tlbl1naW5lIGJpbmFyaWVzJywNCgkJJyR7ZXhlY2Rpcn0n LCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFi bGUoICdwYXRoX2RlX2xpYicsICdQYXRoIHRvIHRoZSBEcmFnW2VuXWdpbmUgbGlicmFyaWVz JywNCgkJJyR7bGliZGlyfScsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBhcmFt cy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfZGVfaW5jbHVkZScsICdQYXRoIHRvIHRoZSBE cmFnW2VuXWdpbmUgaGVhZGVycycsDQoJCScke2luY2x1ZGVkaXJ9L2RyYWdlbmdpbmUnLCBQ YXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUo ICdwYXRoX2RlX2NvbmZpZycsICdQYXRoIHRvIHRoZSBEcmFnW2VuXWdpbmUgY29uZmlndXJh dGlvbicsDQoJCScke3N5c2NvbmZkaXJ9L2RyYWdlbmdpbmUnLCBQYXRoVmFyaWFibGUuUGF0 aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2RlX2RhdGEn LCAnUGF0aCB0byB0aGUgRHJhZ1tlbl1naW5lIGRhdGEnLA0KCQknJHtsaWJkaXJ9L2RyYWdl bmdpbmUnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRo VmFyaWFibGUoICdwYXRoX2RlX3NoYXJlJywgJ1BhdGggdG8gdGhlIERyYWdbZW5dZ2luZSBz aGFyZXMnLA0KCQknJHtkYXRhZGlyfS9kcmFnZW5naW5lJywgUGF0aFZhcmlhYmxlLlBhdGhB Y2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0aF9kZV9jYWNoZScs ICdQYXRoIHRvIHRoZSBEcmFnW2VuXWdpbmUgY2FjaGUnLA0KCQknJHtjYWNoZWRpcn0vZHJh Z2VuZ2luZScsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCQ0KCXBhcmFtcy5BZGQo IFBhdGhWYXJpYWJsZSggJ3BhdGhfaWdkZV9iaW4nLCAnUGF0aCB0byB0aGUgSUdERSBiaW5h cmllcycsDQoJCScke2V4ZWNkaXJ9JywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJ cGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0aF9pZ2RlX2xpYicsICdQYXRoIHRvIHRo ZSBJR0RFIGxpYnJhcmllcycsDQoJCScke2xpYmRpcn0nLCBQYXRoVmFyaWFibGUuUGF0aEFj Y2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2lnZGVfaW5jbHVk ZScsICdQYXRoIHRvIHRoZSBJR0RFIGhlYWRlcnMnLA0KCQknJHtpbmNsdWRlZGlyfS9kZWln ZGUnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFy aWFibGUoICdwYXRoX2lnZGVfY29uZmlnJywgJ1BhdGggdG8gdGhlIElHREUgY29uZmlndXJh dGlvbicsDQoJCScke3N5c2NvbmZkaXJ9L2RlaWdkZScsIFBhdGhWYXJpYWJsZS5QYXRoQWNj ZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfaWdkZV9kYXRhJywg J1BhdGggdG8gdGhlIElHREUgZGF0YScsDQoJCScke2xpYmRpcn0vZGVpZ2RlJywgUGF0aFZh cmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0 aF9pZ2RlX3NoYXJlJywgJ1BhdGggdG8gdGhlIElHREUgc2hhcmVzJywNCgkJJyR7ZGF0YWRp cn0vZGVpZ2RlJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJDQoJcGFyYW1zLkFk ZCggUGF0aFZhcmlhYmxlKCAncGF0aF9sYXVuY2hlcl9iaW4nLCAnUGF0aCB0byB0aGUgTGF1 bmNoZXIgYmluYXJpZXMnLA0KCQknJHtleGVjZGlyfScsIFBhdGhWYXJpYWJsZS5QYXRoQWNj ZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfbGF1bmNoZXJfYmlu X2xpYicsICdQYXRoIHRvIHRoZSBMYXVuY2hlciBiaW5hcnkgbGlicmFyaWVzJywNCgkJJyR7 bGliZGlyfScsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBh dGhWYXJpYWJsZSggJ3BhdGhfbGF1bmNoZXJfY29uZmlnJywgJ1BhdGggdG8gdGhlIExhdW5j aGVyIGNvbmZpZ3VyYXRpb24nLA0KCQknJHtzeXNjb25mZGlyfS9kZWxhdW5jaGVyJywgUGF0 aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAn cGF0aF9sYXVuY2hlcl9kYXRhJywgJ1BhdGggdG8gdGhlIExhdW5jaGVyIGRhdGEnLA0KCQkn JHtsaWJkaXJ9L2RlbGF1bmNoZXInLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglw YXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2xhdW5jaGVyX3NoYXJlJywgJ1BhdGgg dG8gdGhlIExhdW5jaGVyIHNoYXJlcycsDQoJCScke2RhdGFkaXJ9L2RlbGF1bmNoZXInLCBQ YXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUo ICdwYXRoX2xhdW5jaGVyX2dhbWVzJywgJ1BhdGggdG8gdGhlIExhdW5jaGVyIGdhbWVzJywN CgkJJy9vcHQvZGVsYXVuY2hlci9nYW1lcycsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkg KQ0KCQ0KZWxpZiBwYXJlbnRfZW52WydPU1dpbmRvd3MnXToNCglwYXJhbXMuQWRkKEVudW1W YXJpYWJsZSgnaWdkZV90b29sa2l0JywgJ1Rvb2xLaXQgdG8gdXNlIGZvciBidWlsZGluZyBJ R0RFJywgJ2ZveCcsIFsnZm94JywnbnVsbCddKSkNCgkNCglwYXJhbXMuQWRkKCBQYXRoVmFy aWFibGUoICdwcm9ncmFtZmlsZXMnLCAnV2luZG93IHByb2dyYW0gZmlsZXMgZGlyZWN0b3J5 JywNCgkJJ0BQcm9ncmFtRmlsZXMnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglw YXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdzeXN0ZW1yb290JywgJ1dpbmRvdyBzeXN0ZW0g cm9vdCBkaXJlY3RvcnknLA0KCQknQFN5c3RlbScsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0 ICkgKQ0KCQ0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfZGVfc2RrJywgJ1Bh dGggdG8gRHJhZ1tlbl1naW5lIFNESyBkaXJlY3RvcnknLA0KCQknJHtwYXRoX2RlfS9TREsn LCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFi bGUoICdwYXRoX2RlX3Nka19saWInLCAnUGF0aCB0byBEcmFnW2VuXWdpbmUgU0RLIGxpYnJh cmllcycsDQoJCScke3BhdGhfZGVfc2RrfS9saWInLCBQYXRoVmFyaWFibGUuUGF0aEFjY2Vw dCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2RlX3Nka19pbmMnLCAn UGF0aCB0byBEcmFnW2VuXWdpbmUgU0RLIGluY2x1ZGVzJywNCgkJJyR7cGF0aF9kZV9zZGt9 L2luY2x1ZGUnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCgkNCglwYXJhbXMuQWRk KCBQYXRoVmFyaWFibGUoICdwYXRoX2RlJywgJ1BhdGggdG8gdGhlIERyYWdbZW5dZ2luZSBJ bnN0YWxsYXRpb24nLA0KCQknJHtwcm9ncmFtZmlsZXN9L0RyYWdlbmdpbmUnLCBQYXRoVmFy aWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRo X2RlX2JpbicsICdQYXRoIHRvIHRoZSBEcmFnW2VuXWdpbmUgYmluYXJpZXMnLA0KCQknJHtw YXRoX2RlfS9CaW4nLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRk KCBQYXRoVmFyaWFibGUoICdwYXRoX2RlX2xpYicsICdQYXRoIHRvIHRoZSBEcmFnW2VuXWdp bmUgbGlicmFyaWVzJywNCgkJJyR7cGF0aF9kZV9zZGtfbGlifScsIFBhdGhWYXJpYWJsZS5Q YXRoQWNjZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfZGVfaW5j bHVkZScsICdQYXRoIHRvIHRoZSBEcmFnW2VuXWdpbmUgaGVhZGVycycsDQoJCScke3BhdGhf ZGVfc2RrX2luY30vZHJhZ2VuZ2luZScsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0K CXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfZGVfY29uZmlnJywgJ1BhdGggdG8g dGhlIERyYWdbZW5dZ2luZSBjb25maWd1cmF0aW9uJywNCgkJJyR7cGF0aF9kZX0vQ29uZmln JywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlh YmxlKCAncGF0aF9kZV9kYXRhJywgJ1BhdGggdG8gdGhlIERyYWdbZW5dZ2luZSBkYXRhJywN CgkJJyR7cGF0aF9kZX0vRGF0YScsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBh cmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfZGVfc2hhcmUnLCAnUGF0aCB0byB0aGUg RHJhZ1tlbl1naW5lIHNoYXJlcycsDQoJCScke3BhdGhfZGV9L1NoYXJlJywgUGF0aFZhcmlh YmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0aF9k ZV9jYWNoZScsICdQYXRoIHRvIHRoZSBEcmFnW2VuXWdpbmUgY2FjaGUnLA0KCQknQExvY2Fs QXBwRGF0YS9EcmFnZW5naW5lL0NhY2hlJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSAp DQoJDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0aF9pZ2RlX3NkaycsICdQYXRo IHRvIERyYWdbZW5dZ2luZSBJR0RFIFNESyBkaXJlY3RvcnknLA0KCQknJHtwYXRoX2lnZGV9 L1NESycsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBhdGhW YXJpYWJsZSggJ3BhdGhfaWdkZV9zZGtfbGliJywgJ1BhdGggdG8gRHJhZ1tlbl1naW5lIElH REUgU0RLIGxpYnJhcmllcycsDQoJCScke3BhdGhfaWdkZV9zZGt9L2xpYicsIFBhdGhWYXJp YWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhf aWdkZV9zZGtfaW5jJywgJ1BhdGggdG8gRHJhZ1tlbl1naW5lIElHREUgU0RLIGluY2x1ZGVz JywNCgkJJyR7cGF0aF9pZ2RlX3Nka30vaW5jbHVkZScsIFBhdGhWYXJpYWJsZS5QYXRoQWNj ZXB0ICkgKQ0KCQ0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfaWdkZScsICdQ YXRoIHRvIHRoZSBJR0RFIEluc3RhbGxhdGlvbicsDQoJCScke3Byb2dyYW1maWxlc30vREVJ R0RFJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZh cmlhYmxlKCAncGF0aF9pZ2RlX2JpbicsICdQYXRoIHRvIHRoZSBJR0RFIGJpbmFyaWVzJywN CgkJJyR7cGF0aF9pZ2RlfS9CaW4nLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglw YXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdwYXRoX2lnZGVfbGliJywgJ1BhdGggdG8gdGhl IElHREUgbGlicmFyaWVzJywNCgkJJyR7cGF0aF9pZ2RlX3Nka19saWJ9JywgUGF0aFZhcmlh YmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0aF9p Z2RlX2luY2x1ZGUnLCAnUGF0aCB0byB0aGUgSUdERSBoZWFkZXJzJywNCgkJJyR7cGF0aF9p Z2RlX3Nka19pbmN9L2RlaWdkZScsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCXBh cmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfaWdkZV9jb25maWcnLCAnUGF0aCB0byB0 aGUgSUdERSBjb25maWd1cmF0aW9uJywNCgkJJyR7cGF0aF9pZ2RlfS9Db25maWcnLCBQYXRo VmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRoVmFyaWFibGUoICdw YXRoX2lnZGVfZGF0YScsICdQYXRoIHRvIHRoZSBJR0RFIGRhdGEnLA0KCQknJHtwYXRoX2ln ZGV9L0RhdGEnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQ YXRoVmFyaWFibGUoICdwYXRoX2lnZGVfc2hhcmUnLCAnUGF0aCB0byB0aGUgSUdERSBzaGFy ZXMnLA0KCQknJHtwYXRoX2lnZGV9L1NoYXJlJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQg KSApDQoJDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0aF9sYXVuY2hlcicsICdQ YXRoIHRvIHRoZSBMYXVuY2hlciBJbnN0YWxsYXRpb24nLA0KCQknJHtwYXRoX2RlfS9MYXVu Y2hlcnMnLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMuQWRkKCBQYXRo VmFyaWFibGUoICdwYXRoX2xhdW5jaGVyX2JpbicsICdQYXRoIHRvIHRoZSBMYXVuY2hlciBi aW5hcmllcycsDQoJCScke3BhdGhfbGF1bmNoZXJ9L0JpbicsIFBhdGhWYXJpYWJsZS5QYXRo QWNjZXB0ICkgKQ0KCXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfbGF1bmNoZXJf YmluX2xpYicsICdQYXRoIHRvIHRoZSBMYXVuY2hlciBiaW5hcnkgbGlicmFyaWVzJywNCgkJ JyR7cGF0aF9sYXVuY2hlcl9iaW59JywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJ cGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0aF9sYXVuY2hlcl9jb25maWcnLCAnUGF0 aCB0byB0aGUgTGF1bmNoZXIgY29uZmlndXJhdGlvbicsDQoJCSdAUm9hbWluZ0FwcERhdGEv REVMYXVuY2hlcnMvQ29uZmlnJywgUGF0aFZhcmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFy YW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0aF9sYXVuY2hlcl9kYXRhJywgJ1BhdGggdG8g dGhlIExhdW5jaGVyIGRhdGEnLA0KCQknJHtwYXRoX2xhdW5jaGVyfS9EYXRhJywgUGF0aFZh cmlhYmxlLlBhdGhBY2NlcHQgKSApDQoJcGFyYW1zLkFkZCggUGF0aFZhcmlhYmxlKCAncGF0 aF9sYXVuY2hlcl9zaGFyZScsICdQYXRoIHRvIHRoZSBMYXVuY2hlciBzaGFyZXMnLA0KCQkn JHtwYXRoX2xhdW5jaGVyfS9TaGFyZScsIFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0K CXBhcmFtcy5BZGQoIFBhdGhWYXJpYWJsZSggJ3BhdGhfbGF1bmNoZXJfZ2FtZXMnLCAnUGF0 aCB0byB0aGUgTGF1bmNoZXIgZ2FtZXMnLA0KCQknJHtwYXRoX2xhdW5jaGVyfS9HYW1lcycs IFBhdGhWYXJpYWJsZS5QYXRoQWNjZXB0ICkgKQ0KCQ0KZWxzZToNCglFeGl0KCAnTm8gc3Vw cG9ydGVkIE9TIGZvdW5kIScpDQoNCnBhcmFtcy5VcGRhdGUoIHBhcmVudF9lbnYgKQ0KI3By aW50KHBhcmVudF9lbnYuRHVtcCgpKQ0KDQojIGRldGVybWluZSBzYW5pdGl6ZSBmbGFncyB0 byB1c2UNCnBhcmVudF9lbnYuUmVwbGFjZShTQU5JVElaRV9GTEFHUyA9IFtdKQ0KDQppZiBw YXJlbnRfZW52Wyd3aXRoX2RlYnVnJ10gYW5kIHBhcmVudF9lbnZbJ3dpdGhfc2FuaXRpemUn XToNCglpZiBwYXJlbnRfZW52Wyd3aXRoX3Nhbml0aXplX3RocmVhZCddOg0KCQlwYXJlbnRf ZW52LkFwcGVuZChTQU5JVElaRV9GTEFHUyA9IFsnLWZzYW5pdGl6ZT10aHJlYWQnXSkNCgkJ DQoJZWxzZToNCgkJcGFyZW50X2Vudi5BcHBlbmQoU0FOSVRJWkVfRkxBR1MgPSBbDQoJCQkn LWZzYW5pdGl6ZT1hZGRyZXNzJywNCgkJCSctZnNhbml0aXplLWFkZHJlc3MtdXNlLWFmdGVy LXNjb3BlJywNCgkJCSctZnNhbml0aXplPXBvaW50ZXItY29tcGFyZScsDQoJCQknLWZzYW5p dGl6ZT1wb2ludGVyLXN1YnRyYWN0J10pDQoJCXBhcmVudF9lbnYuQXBwZW5kKFNBTklUSVpF X0ZMQUdTID0gWw0KCQkJJy1mc2FuaXRpemU9bGVhayddKQ0KCQlwYXJlbnRfZW52LkFwcGVu ZChTQU5JVElaRV9GTEFHUyA9IFsNCgkJCSctZnNhbml0aXplPXVuZGVmaW5lZCcsDQoJCQkn LWZzYW5pdGl6ZT1zaGlmdCcsDQoJCQknLWZzYW5pdGl6ZT1zaGlmdC1leHBvbmVudCcsDQoJ CQknLWZzYW5pdGl6ZT1zaGlmdC1iYXNlJywNCgkJCSctZnNhbml0aXplPWludGVnZXItZGl2 aWRlLWJ5LXplcm8nLA0KCQkJJy1mc2FuaXRpemU9dW5yZWFjaGFibGUnLA0KCQkJJy1mc2Fu aXRpemU9dmxhLWJvdW5kJywNCgkJCSctZnNhbml0aXplPW51bGwnLA0KCQkJJy1mc2FuaXRp emU9cmV0dXJuJywNCgkJCSctZnNhbml0aXplPXNpZ25lZC1pbnRlZ2VyLW92ZXJmbG93JywN CgkJCSctZnNhbml0aXplPWJvdW5kcycsDQoJCQknLWZzYW5pdGl6ZT1ib3VuZHMtc3RyaWN0 JywNCgkJCSctZnNhbml0aXplPWFsaWdubWVudCcsDQoJCQknLWZzYW5pdGl6ZT1vYmplY3Qt c2l6ZScsDQoJCQknLWZzYW5pdGl6ZT1mbG9hdC1kaXZpZGUtYnktemVybycsDQoJCQknLWZz YW5pdGl6ZT1mbG9hdC1jYXN0LW92ZXJmbG93JywNCgkJCSctZnNhbml0aXplPW5vbm51bGwt YXR0cmlidXRlJywNCgkJCSctZnNhbml0aXplPXJldHVybnMtbm9ubnVsbC1hdHRyaWJ1dGUn LA0KCQkJJy1mc2FuaXRpemU9Ym9vbCcsDQoJCQknLWZzYW5pdGl6ZT1lbnVtJywNCgkJCSct ZnNhbml0aXplPXZwdHInLA0KCQkJJy1mc2FuaXRpemU9cG9pbnRlci1vdmVyZmxvdycsDQoJ CQknLWZzYW5pdGl6ZT1idWlsdGluJ10pDQoNCiMgZm9yIG1vZHVsZXMgaGlkZSBldmVyeXRo aW5nIGV4Y2VwdCB0aGUgZW50cnkgcG9pbnQuIGZvciB0aGlzIHRoZSBkZWZhdWx0IHZpc2li aWxpdHkNCiMgaXMgc2V0IHRvIGhpZGRlbiBhbmQgb25seSB0aGUgZW50cnkgcG9pbnQgaXMg cXVhbGlmaWVkIHdpdGggbm9ybWFsIHZpc2liaWxpdHkuDQojIGhpZGluZyBhbHNvIGlubGlu ZXMgaXMgYW4gb3B0aW1pemF0aW9uIGFuZCBoZWxwcyB0byByZW1vdmUgc29tZSBzcGVjaWFs IGNhc2VzLg0KIyB0aGUgdmVyc2lvbiBzY3JpcHQgaXMgcmVxdWlyZWQgdG8gaGlkZSBzeW1i b2xzIG9mIGxpbmtlZCBzdGF0aWMgbGlicmFyaWVzLg0KIyB0aGUgLXMgZmxhZyBldmVudHVh bGx5IHN0cmlwcyB1bnVzZWQgY29kZSBsaW5rZWQgaW4gYnkgc3RhdGljIGxpYnJhcmllcw0K DQppZiBwYXJlbnRfZW52Wyd3aXRoX2RlYnVnJ106DQoJcGFyZW50X2Vudi5BcHBlbmQoTU9E VUxFX0NQUEZMQUdTID0gWyctRE1PRF9FTlRSWV9QT0lOVF9BVFRSPSddKQ0KCWlmIHBhcmVu dF9lbnZbJ3dpdGhfc2FuaXRpemUnXToNCgkJcGFyZW50X2Vudi5BcHBlbmQoTU9EVUxFX0NQ UEZMQUdTID0gcGFyZW50X2VudlsnU0FOSVRJWkVfRkxBR1MnXSkNCgkJcGFyZW50X2Vudi5B cHBlbmQoTU9EVUxFX0xJTktGTEFHUyA9IHBhcmVudF9lbnZbJ1NBTklUSVpFX0ZMQUdTJ10p DQoJDQplbHNlOg0KCXBhcmVudF9lbnYuQXBwZW5kKE1PRFVMRV9DUFBGTEFHUyA9IFsnLWZ2 aXNpYmlsaXR5PWhpZGRlbiddKQ0KCXBhcmVudF9lbnYuQXBwZW5kKE1PRFVMRV9MSU5LRkxB R1MgPSBbJy1mdmlzaWJpbGl0eT1oaWRkZW4nXSkNCgkNCglwYXJlbnRfZW52LkFwcGVuZChN T0RVTEVfQ1hYRkxBR1MgPSBbJy1mdmlzaWJpbGl0eS1pbmxpbmVzLWhpZGRlbiddKQ0KCXBh cmVudF9lbnYuQXBwZW5kKE1PRFVMRV9MSU5LRkxBR1MgPSBbJy1mdmlzaWJpbGl0eS1pbmxp bmVzLWhpZGRlbiddKQ0KCQ0KCWlmIG5vdCBwYXJlbnRfZW52WydPU01hY09TJ106DQoJCXBh cmVudF9lbnYuQXBwZW5kKE1PRFVMRV9MSU5LRkxBR1MgPSBbJy1XbCwtLXZlcnNpb24tc2Ny aXB0PW1vZHVsZS52ZXJzaW9uJ10pDQoJCXBhcmVudF9lbnYuQXBwZW5kKE1PRFVMRV9MSU5L RkxBR1MgPSBbJy1zJ10pDQoJcGFyZW50X2Vudi5BcHBlbmQoTU9EVUxFX0NQUEZMQUdTID0g WyctRE1PRF9FTlRSWV9QT0lOVF9BVFRSPV9fYXR0cmlidXRlX19cXChcXCh2aXNpYmlsaXR5 XFwoXFwiZGVmYXVsdFxcIlxcKVxcKVxcKSddKQ0KDQojIGFuZHJvaWQNCmlmIHBhcmVudF9l bnZbICdwbGF0Zm9ybV9hbmRyb2lkJyBdICE9ICdubyc6DQoJcGFyYW1zLkFkZCggUGF0aFZh cmlhYmxlKCAnbmRrcm9vdCcsICdQYXRoIHRvIE5ESyB0b29sY2hhaW4gKE5ES19ST09UIGVu di1wYXJhbSBieSBkZWZhdWx0KScsDQoJCW9zLnBhdGguZXhwYW5kdXNlciggb3MuZW52aXJv blsnTkRLX1JPT1QnXSApLCBQYXRoVmFyaWFibGUuUGF0aEFjY2VwdCApICkNCglwYXJhbXMu QWRkKCBTdHJpbmdWYXJpYWJsZSggJ2FwaWxldmVsJywgJ0FuZHJvaWQgQVBJIGxldmVsJywg JzE4JyApICkNCglwYXJhbXMuQWRkKCBCb29sVmFyaWFibGUoICdoYXJkZnAnLCAnVXNlIGhh cmR3YXJlIGZsb2F0aW5nIHBvaW50IHN1cHBvcnQgaW5zdGVhZCBvZiBzb2Z0ZnAgb24gQVJN djcgb25seScsIEZhbHNlICkgKQ0KCQ0KCXBhcmFtcy5VcGRhdGUoIHBhcmVudF9lbnYgKQ0K CQ0KCWFuZHJvaWRVcGRhdGVFbnYoIHBhcmVudF9lbnYgKQ0KDQojIGRpc2FibGUgdmVyYm9z ZSBjb21waWxlIG1lc3NhZ2VzIGlmIHJlcXVlc3RlZA0KaWYgbm90IHBhcmVudF9lbnZbICd3 aXRoX3ZlcmJvc2UnIF06DQoJRGlzYWJsZVZlcmJvc2VDb21waWxpbmcoIHBhcmVudF9lbnYg KQ0KDQppZiBwYXJlbnRfZW52Wyd3aXRoX2RlYnVnJ106DQoJaWYgcGFyZW50X2VudlsnT1NX aW5kb3dzJ106DQoJCXBhcmVudF9lbnYuQXBwZW5kKENQUEZMQUdTID0gWyctZycsICctZ3N0 YWJzJywgJy1nZ2RiJ10pDQoJZWxzZToNCgkJcGFyZW50X2Vudi5BcHBlbmQoQ1BQRkxBR1Mg PSBbJy1nJ10pDQoJCSMgbWluZ3cgcHJvZHVjZXMgaW50ZXJuYWwgY29tcGlsZXIgZXJyb3Jz IG9uIDgueCBHQ0MuIGRpc2FibGVkIHVudGlsIGZpeGVkIG9yIGEgY2hlY2sgaXMgcHJlc2Vu dA0KCQlwYXJlbnRfZW52LkFwcGVuZChDUFBGTEFHUyA9IFsnLWZuby1vbWl0LWZyYW1lLXBv aW50ZXInXSkNCg0KIyBzZXQgZmxhZ3MgYmFzZWQgb24gcGFyYW1ldGVycw0KaWYgcGFyZW50 X2VudlsgJ3BsYXRmb3JtX2FuZHJvaWQnIF0gPT0gJ25vJzoNCglwYXJlbnRfZW52LkFwcGVu ZCggQ1BQRkxBR1MgPSBbICctTzInIF0gKSAgIyBiZWNhdXNlIGFuZHJvaWQgcGxhdGZvcm0g c2NyaXB0IGRlZmluZXMgdGhpcyBhbHJlYWR5DQpwYXJlbnRfZW52LkFwcGVuZCggQ1BQRkxB R1MgPSBbICctV2FsbCcgXSApDQoNCiMgZGlzYWJsZSB0aGUgbmV3IChhbmQgdHJ1ZWx5IHN0 dXBpZCkgbmV3IGdjYyA4LjEgc2hlbmFuaWdhbnMuDQojIHNlZSBodHRwczovL2djYy5nbnUu b3JnL29ubGluZWRvY3MvZ2NjL0NfMDAyYl8wMDJiLURpYWxlY3QtT3B0aW9ucy5odG1sI2lu ZGV4LVdjbGFzcy1tZW1hY2Nlc3MgLg0KIyB0aGUgaWRlYSBiZWhpbmQgYWxsIHRoaXMgaXMg YWxsIG5pY2UgYW5kIGRhbmR5IGJ1dCBpdCBwcmV2ZW50cyBsZWdpdCBmYXN0IG1lbW9yeSBo YW5kbGluZw0KIyB0cnlpbmcgdG8gcHJldGVuZCBpZGlvdHMgZnJvbSBzaG9vdGluZyB0aGVt c2VsdmVzIGluIHRoZSBmb290LiBpZiBzb21lYm9keSB1c2VzIG1lbWNweSB0aGVuDQojIGhl IHNob3VsZCBrbm93IHdoYXQgaGUgaXMgZG9pbmcgc28gc3RvcCBicmVha2luZyBidWlsZHMg d2l0aCBub24tc2Vuc2UgZXJyb3JzLg0KcGFyZW50X2Vudi5BcHBlbmQoQ1hYRkxBR1MgPSBb Jy1Xbm8tY2xhc3MtbWVtYWNjZXNzJ10pDQoNCmlmIHBhcmVudF9lbnZbICd3aXRoX3dhcm5l cnJvcnMnIF06DQoJcGFyZW50X2Vudi5BcHBlbmQoIENQUEZMQUdTID0gWyAnLVdlcnJvcicg XSApDQoNCmlmIHBhcmVudF9lbnZbICdwbGF0Zm9ybV9hbmRyb2lkJyBdICE9ICdubyc6DQoJ cGFyZW50X2Vudi5BcHBlbmQoQ1BQRkxBR1MgPSBbJy1Xbm8tdW51c2VkLXByaXZhdGUtZmll bGQnXSkNCglwYXJlbnRfZW52LkFwcGVuZChDUFBGTEFHUyA9IFsnLVduby10YXV0b2xvZ2lj YWwtY29uc3RhbnQtY29tcGFyZSddKQ0KDQojIG5vIGRlZmF1bHQgdGFyZ2V0cw0KRGVmYXVs dCggTm9uZSApDQoNCiMgZGVmaW5lIHRoZSB0YXJnZXRzIGFycmF5IGFuZCByZXBvcnRzIGRp Y3Rpb25hcnkgdG8gYmUgZmlsbGVkDQpwYXJlbnRfdGFyZ2V0cyA9IHt9DQpwYXJlbnRfcmVw b3J0ID0ge30NCg0KIyByZXBvcnQgc3R1ZmYNCmlmIHBhcmVudF9lbnZbJ09TUG9zaXgnXToN CglwYXJlbnRfcmVwb3J0WyAncHJlZml4JyBdID0gcGFyZW50X2Vudi5zdWJzdCggcGFyZW50 X2VudlsgJ3ByZWZpeCcgXSApDQoJcGFyZW50X3JlcG9ydFsgJ2RyYWdlbmdpbmUgYmluYXJ5 IHBhdGgnIF0gPSBwYXJlbnRfZW52LnN1YnN0KCBwYXJlbnRfZW52WyAncGF0aF9kZV9iaW4n IF0gKQ0KCXBhcmVudF9yZXBvcnRbICdkcmFnZW5naW5lIGxpYnJhcnkgcGF0aCcgXSA9IHBh cmVudF9lbnYuc3Vic3QoIHBhcmVudF9lbnZbICdwYXRoX2RlX2xpYicgXSApDQoJcGFyZW50 X3JlcG9ydFsgJ2RyYWdlbmdpbmUgaW5jbHVkZSBwYXRoJyBdID0gcGFyZW50X2Vudi5zdWJz dCggcGFyZW50X2VudlsgJ3BhdGhfZGVfaW5jbHVkZScgXSApDQoJcGFyZW50X3JlcG9ydFsg J2RyYWdlbmdpbmUgY29uZmlndXJhdGlvbiBwYXRoJyBdID0gcGFyZW50X2Vudi5zdWJzdCgg cGFyZW50X2VudlsgJ3BhdGhfZGVfY29uZmlnJyBdICkNCglwYXJlbnRfcmVwb3J0WyAnZHJh Z2VuZ2luZSBkYXRhIHBhdGgnIF0gPSBwYXJlbnRfZW52LnN1YnN0KCBwYXJlbnRfZW52WyAn cGF0aF9kZV9kYXRhJyBdICkNCglwYXJlbnRfcmVwb3J0WyAnZHJhZ2VuZ2luZSBzaGFyZWQg ZGF0YSBwYXRoJyBdID0gcGFyZW50X2Vudi5zdWJzdCggcGFyZW50X2VudlsgJ3BhdGhfZGVf c2hhcmUnIF0gKQ0KCXBhcmVudF9yZXBvcnRbICdkcmFnZW5naW5lIGNhY2hlIHBhdGgnIF0g PSBwYXJlbnRfZW52LnN1YnN0KCBwYXJlbnRfZW52WyAncGF0aF9kZV9jYWNoZScgXSApDQoN CmVsaWYgcGFyZW50X2VudlsnT1NXaW5kb3dzJ106DQoJcGFyZW50X3JlcG9ydFsgJ3N5c3Rl bSBsaWJyYXJ5IHBhdGgnIF0gPSBwYXJlbnRfZW52LnN1YnN0KCBwYXJlbnRfZW52WyAnc3lz dGVtcm9vdCcgXSApDQoJcGFyZW50X3JlcG9ydFsgJ2RyYWdlbmdpbmUgc2RrIHBhdGgnIF0g PSBwYXJlbnRfZW52LnN1YnN0KCBwYXJlbnRfZW52WyAncGF0aF9kZV9zZGsnIF0gKQ0KCXBh cmVudF9yZXBvcnRbICdkcmFnZW5naW5lIHBhdGgnIF0gPSBwYXJlbnRfZW52LnN1YnN0KCBw YXJlbnRfZW52WyAncGF0aF9kZScgXSApDQoJcGFyZW50X3JlcG9ydFsgJ2RyYWdlbmdpbmUg YmluYXJ5IHBhdGgnIF0gPSBwYXJlbnRfZW52LnN1YnN0KCBwYXJlbnRfZW52WyAncGF0aF9k ZV9iaW4nIF0gKQ0KCXBhcmVudF9yZXBvcnRbICdkcmFnZW5naW5lIGxpYnJhcnkgcGF0aCcg XSA9IHBhcmVudF9lbnYuc3Vic3QoIHBhcmVudF9lbnZbICdwYXRoX2RlX2xpYicgXSApDQoJ cGFyZW50X3JlcG9ydFsgJ2RyYWdlbmdpbmUgaW5jbHVkZSBwYXRoJyBdID0gcGFyZW50X2Vu di5zdWJzdCggcGFyZW50X2VudlsgJ3BhdGhfZGVfaW5jbHVkZScgXSApDQoJcGFyZW50X3Jl cG9ydFsgJ2RyYWdlbmdpbmUgY29uZmlndXJhdGlvbiBwYXRoJyBdID0gcGFyZW50X2Vudi5z dWJzdCggcGFyZW50X2VudlsgJ3BhdGhfZGVfY29uZmlnJyBdICkNCglwYXJlbnRfcmVwb3J0 WyAnZHJhZ2VuZ2luZSBkYXRhIHBhdGgnIF0gPSBwYXJlbnRfZW52LnN1YnN0KCBwYXJlbnRf ZW52WyAncGF0aF9kZV9kYXRhJyBdICkNCglwYXJlbnRfcmVwb3J0WyAnZHJhZ2VuZ2luZSBz aGFyZWQgZGF0YSBwYXRoJyBdID0gcGFyZW50X2Vudi5zdWJzdCggcGFyZW50X2VudlsgJ3Bh dGhfZGVfc2hhcmUnIF0gKQ0KCXBhcmVudF9yZXBvcnRbICdkZWlnZGUgcGF0aCcgXSA9IHBh cmVudF9lbnYuc3Vic3QoIHBhcmVudF9lbnZbICdwYXRoX2lnZGUnIF0gKQ0KCXBhcmVudF9y ZXBvcnRbICdkZWlnZGUgYmluYXJ5IHBhdGgnIF0gPSBwYXJlbnRfZW52LnN1YnN0KCBwYXJl bnRfZW52WyAncGF0aF9pZ2RlX2JpbicgXSApDQoJcGFyZW50X3JlcG9ydFsgJ2RlaWdkZSBs aWJyYXJ5IHBhdGgnIF0gPSBwYXJlbnRfZW52LnN1YnN0KCBwYXJlbnRfZW52WyAncGF0aF9p Z2RlX2xpYicgXSApDQoJcGFyZW50X3JlcG9ydFsgJ2RlaWdkZSBpbmNsdWRlIHBhdGgnIF0g PSBwYXJlbnRfZW52LnN1YnN0KCBwYXJlbnRfZW52WyAncGF0aF9pZ2RlX2luY2x1ZGUnIF0g KQ0KCXBhcmVudF9yZXBvcnRbICdkZWlnZGUgY29uZmlndXJhdGlvbiBwYXRoJyBdID0gcGFy ZW50X2Vudi5zdWJzdCggcGFyZW50X2VudlsgJ3BhdGhfaWdkZV9jb25maWcnIF0gKQ0KCXBh cmVudF9yZXBvcnRbICdkZWlnZGUgZGF0YSBwYXRoJyBdID0gcGFyZW50X2Vudi5zdWJzdCgg cGFyZW50X2VudlsgJ3BhdGhfaWdkZV9kYXRhJyBdICkNCglwYXJlbnRfcmVwb3J0WyAnZGVp Z2RlIHNoYXJlZCBkYXRhIHBhdGgnIF0gPSBwYXJlbnRfZW52LnN1YnN0KCBwYXJlbnRfZW52 WyAncGF0aF9pZ2RlX3NoYXJlJyBdICkNCglwYXJlbnRfcmVwb3J0WyAnZHJhZ2VuZ2luZSBj YWNoZSBwYXRoJyBdID0gcGFyZW50X2Vudi5zdWJzdCggcGFyZW50X2VudlsgJ3BhdGhfZGVf Y2FjaGUnIF0gKQ0KCSNwYXJlbnRfcmVwb3J0WyAncHJvZ3JhbSBmaWxlcycgXSA9IHBhcmVu dF9lbnYuc3Vic3QoIHBhcmVudF9lbnZbICdwcm9ncmFtZmlsZXMnIF0gKQ0KDQpwYXJlbnRf cmVwb3J0WyAncGxhdGZvcm1fYW5kcm9pZCcgXSA9IHBhcmVudF9lbnZbICdwbGF0Zm9ybV9h bmRyb2lkJyBdDQppZiBwYXJlbnRfZW52WyAncGxhdGZvcm1fYW5kcm9pZCcgXSAhPSAnbm8n Og0KCXBhcmVudF9yZXBvcnRbICduZGtyb290JyBdID0gcGFyZW50X2Vudi5zdWJzdCggcGFy ZW50X2VudlsgJ25ka3Jvb3QnIF0gKQ0KCXBhcmVudF9yZXBvcnRbICdhcGlsZXZlbCcgXSA9 IHBhcmVudF9lbnZbICdhcGlsZXZlbCcgXQ0KCXBhcmVudF9yZXBvcnRbICdoYXJkZnAnIF0g PSAneWVzJyBpZiBwYXJlbnRfZW52WyAnaGFyZGZwJyBdIGVsc2UgJ25vJw0KDQpwYXJlbnRf cmVwb3J0WyAnYnVpbGQgZHJhZ2VuZ2luZSB0ZXN0cycgXSA9ICd5ZXMnIGlmIHBhcmVudF9l bnZbICd3aXRoX3Rlc3RzJyBdIGVsc2UgJ25vJw0KcGFyZW50X3JlcG9ydFsgJ3RyZWF0IHdh cm5pbmdzIGFzIGVycm9ycycgXSA9ICd5ZXMnIGlmIHBhcmVudF9lbnZbICd3aXRoX3dhcm5l cnJvcnMnIF0gZWxzZSAnbm8nDQpwYXJlbnRfcmVwb3J0WyAnYnVpbGQgd2l0aCBkZWJ1ZyBz eW1ib2xzJyBdID0gJ3llcycgaWYgcGFyZW50X2VudlsgJ3dpdGhfZGVidWcnIF0gZWxzZSAn bm8nDQpwYXJlbnRfcmVwb3J0WyAnYnVpbGQgd2l0aCBzYW5pdGl6aW5nJyBdID0gJ3llcycg aWYgcGFyZW50X2VudlsgJ3dpdGhfc2FuaXRpemUnIF0gZWxzZSAnbm8nDQpwYXJlbnRfcmVw b3J0WyAnYnVpbGQgd2l0aCB0aHJlYWQgc2FuaXRpemluZycgXSA9ICd5ZXMnIGlmIHBhcmVu dF9lbnZbICd3aXRoX3Nhbml0aXplX3RocmVhZCcgXSBlbHNlICdubycNCg0KDQoNCiMgZXh0 ZXJuYWwgbGlicmFyaWVzDQpleHRkaXJzID0gW10NCmV4dGRpcnMuYXBwZW5kKCAnZXh0ZXJu L3psaWInICkNCmV4dGRpcnMuYXBwZW5kKCAnZXh0ZXJuL2xpYnBuZycgKQ0KZXh0ZGlycy5h cHBlbmQoICdleHRlcm4vbGliYXBuZycgKQ0KZXh0ZGlycy5hcHBlbmQoICdleHRlcm4vbGli anBlZycgKQ0KZXh0ZGlycy5hcHBlbmQoICdleHRlcm4vc25kaW8nICkNCmV4dGRpcnMuYXBw ZW5kKCAnZXh0ZXJuL29wZW5hbCcgKQ0KZXh0ZGlycy5hcHBlbmQoICdleHRlcm4vbGlib2dn JyApDQpleHRkaXJzLmFwcGVuZCggJ2V4dGVybi9saWJ2b3JiaXMnICkNCmV4dGRpcnMuYXBw ZW5kKCAnZXh0ZXJuL2xpYnRoZW9yYScgKQ0KZXh0ZGlycy5hcHBlbmQoICdleHRlcm4vZm94 JyApDQpleHRkaXJzLmFwcGVuZCggJ2V4dGVybi9kcmFnb25zY3JpcHQnICkNCmV4dGRpcnMu YXBwZW5kKCAnZXh0ZXJuL2xpYmZmaScgKQ0KZXh0ZGlycy5hcHBlbmQoICdleHRlcm4vbGli bHRkbCcgKQ0KZXh0ZGlycy5hcHBlbmQoICdleHRlcm4vbGlic2lnc2VndicgKQ0KI2V4dGRp cnMuYXBwZW5kKCAnZXh0ZXJuL3NtYWxsdGFsaycgKQ0KZXh0ZGlycy5hcHBlbmQoICdleHRl cm4vbGliZXZkZXYnICkNCmV4dGRpcnMuYXBwZW5kKCAnZXh0ZXJuL2xpYnVzYicgKQ0KZXh0 ZGlycy5hcHBlbmQoICdleHRlcm4vbGliaGlkYXBpJyApDQpleHRkaXJzLmFwcGVuZCggJ2V4 dGVybi9saWJvcGVuaG1kJyApDQpleHRkaXJzLmFwcGVuZCggJ2V4dGVybi9mZnR3JyApDQoN CmZvciBleHRkaXIgaW4gZXh0ZGlyczoNCglTQ29uc2NyaXB0KCBkaXJzPWV4dGRpciwgdmFy aWFudF9kaXI9J3t9L2J1aWxkJy5mb3JtYXQoIGV4dGRpciApLA0KCQlkdXBsaWNhdGU9MCwg ZXhwb3J0cz0ncGFyZW50X2VudiBwYXJlbnRfdGFyZ2V0cyBwYXJlbnRfcmVwb3J0JyApDQoN ClNDb25zY3JpcHQoIGRpcnM9J2V4dGVybi9taW5ndycsIHZhcmlhbnRfZGlyPSdleHRlcm4v bWluZ3cvYnVpbGQnLA0KCWR1cGxpY2F0ZT0wLCBleHBvcnRzPSdwYXJlbnRfZW52IHBhcmVu dF90YXJnZXRzIHBhcmVudF9yZXBvcnQnICkNCg0KIyBkcmFnW2VuXWdpbmUgZ2FtZSBlbmdp bmUNClNDb25zY3JpcHQoIGRpcnM9J3NyYy9kcmFnZW5naW5lJywgdmFyaWFudF9kaXI9J3Ny Yy9kcmFnZW5naW5lL2J1aWxkJywgZHVwbGljYXRlPTAsDQoJZXhwb3J0cz0ncGFyZW50X2Vu diBwYXJlbnRfdGFyZ2V0cyBwYXJlbnRfcmVwb3J0JyApDQoNCnNjZGlycyA9IFtdDQoNCiMg Z2FtZSBlbmdpbmUgbW9kdWxlcw0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9tb2R1bGVzL2FuaW1h dG9yL2RlYW5pbWF0b3InICkNCg0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9tb2R1bGVzL2FpL2Rl YWknICkNCg0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9tb2R1bGVzL2FuaW1hdGlvbi9kZWFuaW0n ICkNCg0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9tb2R1bGVzL2F1ZGlvL251bGwnICkNCnNjZGly cy5hcHBlbmQoICdzcmMvbW9kdWxlcy9hdWRpby9vcGVuYWwnICkNCg0Kc2NkaXJzLmFwcGVu ZCggJ3NyYy9tb2R1bGVzL2NyYXNocmVjb3Zlcnkvc2ltcGx5cXVpdCcgKQ0Kc2NkaXJzLmFw cGVuZCggJ3NyYy9tb2R1bGVzL2NyYXNocmVjb3ZlcnkvYmFzaWNyZWNvdmVyeScgKQ0KDQpz Y2RpcnMuYXBwZW5kKCAnc3JjL21vZHVsZXMvZm9udC9kZWZvbnQnICkNCg0Kc2NkaXJzLmFw cGVuZCggJ3NyYy9tb2R1bGVzL2dyYXBoaWMvbnVsbCcgKQ0Kc2NkaXJzLmFwcGVuZCggJ3Ny Yy9tb2R1bGVzL2dyYXBoaWMvb3BlbmdsJyApDQoNCnNjZGlycy5hcHBlbmQoICdzcmMvbW9k dWxlcy9pbWFnZS9wbmcnICkNCnNjZGlycy5hcHBlbmQoICdzcmMvbW9kdWxlcy9pbWFnZS9w bmczZCcgKQ0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9tb2R1bGVzL2ltYWdlL3RnYScgKQ0Kc2Nk aXJzLmFwcGVuZCggJ3NyYy9tb2R1bGVzL2ltYWdlL2pwZWcnICkNCg0Kc2NkaXJzLmFwcGVu ZCggJ3NyYy9tb2R1bGVzL2lucHV0L2NvbnNvbGUnICkNCnNjZGlycy5hcHBlbmQoICdzcmMv bW9kdWxlcy9pbnB1dC94c3lzdGVtJyApDQpzY2RpcnMuYXBwZW5kKCAnc3JjL21vZHVsZXMv aW5wdXQvdzMyaW5wdXQnICkNCnNjZGlycy5hcHBlbmQoICdzcmMvbW9kdWxlcy9pbnB1dC9i ZW9zJyApDQpzY2RpcnMuYXBwZW5kKCAnc3JjL21vZHVsZXMvaW5wdXQvbWFjb3MnICkNCnNj ZGlycy5hcHBlbmQoICdzcmMvbW9kdWxlcy9pbnB1dC9hbmRyb2lkJyApDQoNCnNjZGlycy5h cHBlbmQoICdzcmMvbW9kdWxlcy9sYW5ncGFjay9kZWxhbmdwYWNrJyApDQoNCnNjZGlycy5h cHBlbmQoICdzcmMvbW9kdWxlcy9tb2RlbC9kZW1vZGVsJyApDQoNCnNjZGlycy5hcHBlbmQo ICdzcmMvbW9kdWxlcy9uZXR3b3JrL2Jhc2ljJyApDQoNCnNjZGlycy5hcHBlbmQoICdzcmMv bW9kdWxlcy9vY2NsdXNpb25tZXNoL2Rlb2NjbHVzaW9ubWVzaCcgKQ0KDQpzY2RpcnMuYXBw ZW5kKCAnc3JjL21vZHVsZXMvcGh5c2ljcy9idWxsZXQnICkNCg0Kc2NkaXJzLmFwcGVuZCgg J3NyYy9tb2R1bGVzL3JpZy9kZXJpZycgKQ0KDQpzY2RpcnMuYXBwZW5kKCAnc3JjL21vZHVs ZXMvc2NyaXB0aW5nL2RyYWdvbnNjcmlwdCcgKQ0KI3NjZGlycy5hcHBlbmQoICdzcmMvbW9k dWxlcy9zY3JpcHRpbmcvcHl0aG9uJyApDQojc2NkaXJzLmFwcGVuZCggJ3NyYy9tb2R1bGVz L3NjcmlwdGluZy9zbWFsbHRhbGsnICkNCg0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9tb2R1bGVz L3NraW4vZGVza2luJyApDQoNCnNjZGlycy5hcHBlbmQoICdzcmMvbW9kdWxlcy9zb3VuZC9v Z2d2b3JiaXMnICkNCg0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9tb2R1bGVzL3N5bnRoZXNpemVy L2Rlc3ludGhlc2l6ZXInICkNCg0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9tb2R1bGVzL3ZpZGVv L3RoZW9yYScgKQ0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9tb2R1bGVzL3ZpZGVvL2FwbmcnICkN Cg0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9tb2R1bGVzL2FyY2hpdmUvZGVsZ2EnICkNCg0Kc2Nk aXJzLmFwcGVuZCggJ3NyYy9tb2R1bGVzL2NvbWJpbmVkL2ZieCcgKQ0KDQojIGxhdW5jaGVy cw0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9sYXVuY2hlci9jb25zb2xlJyApDQpzY2RpcnMuYXBw ZW5kKCAnc3JjL2xhdW5jaGVyL2d1aScgKQ0KI3NjZGlycy5hcHBlbmQoICdzcmMvbGF1bmNo ZXIvYW5kcm9pZCcgKQ0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9sYXVuY2hlci9saXZlJyApDQoN CiMgdGVzdHMNCnNjZGlycy5hcHBlbmQoICdzcmMvdGVzdHMnICkNCg0KIyBpbnRlZ3JhdGVk IGdhbWUgZGV2ZWxvcG1lbnQgZW52aXJvbm1lbnQNCnNjZGlycy5hcHBlbmQoICdzcmMvZGVp Z2RlL2RlaWdkZScgKQ0KDQpzY2RpcnMuYXBwZW5kKCAnc3JjL2RlaWdkZS9lZGl0b3JzL3dv cmxkJyApDQpzY2RpcnMuYXBwZW5kKCAnc3JjL2RlaWdkZS9lZGl0b3JzL2FuaW1hdG9yJyAp DQpzY2RpcnMuYXBwZW5kKCAnc3JjL2RlaWdkZS9lZGl0b3JzL3JpZ2VkaXRvcicgKQ0Kc2Nk aXJzLmFwcGVuZCggJ3NyYy9kZWlnZGUvZWRpdG9ycy9mb250JyApDQpzY2RpcnMuYXBwZW5k KCAnc3JjL2RlaWdkZS9lZGl0b3JzL3NreScgKQ0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9kZWln ZGUvZWRpdG9ycy9za2luJyApDQpzY2RpcnMuYXBwZW5kKCAnc3JjL2RlaWdkZS9lZGl0b3Jz L3BhcnRpY2xlRW1pdHRlcicgKQ0Kc2NkaXJzLmFwcGVuZCggJ3NyYy9kZWlnZGUvZWRpdG9y cy9zcGVlY2hBbmltYXRpb24nICkNCnNjZGlycy5hcHBlbmQoICdzcmMvZGVpZ2RlL2VkaXRv cnMvY29udmVyc2F0aW9uJyApDQpzY2RpcnMuYXBwZW5kKCAnc3JjL2RlaWdkZS9lZGl0b3Jz L2xhbmdwYWNrJyApDQpzY2RpcnMuYXBwZW5kKCAnc3JjL2RlaWdkZS9lZGl0b3JzL3N5bnRo ZXNpemVyJyApDQpzY2RpcnMuYXBwZW5kKCAnc3JjL2RlaWdkZS9lZGl0b3JzL2dhbWVEZWZp bml0aW9uJyApDQpzY2RpcnMuYXBwZW5kKCAnc3JjL2RlaWdkZS9lZGl0b3JzL3Byb2plY3Qn ICkNCg0KZm9yIHNjZGlyIGluIHNjZGlyczoNCglTQ29uc2NyaXB0KCBkaXJzPXNjZGlyLCB2 YXJpYW50X2Rpcj0ne30vYnVpbGQnLmZvcm1hdCggc2NkaXIgKSwNCgkJZHVwbGljYXRlPTAs IGV4cG9ydHM9J3BhcmVudF9lbnYgcGFyZW50X3RhcmdldHMgcGFyZW50X3JlcG9ydCcgKQ0K DQojdG9vbHMNClNDb25zY3JpcHQoIGRpcnM9J3NyYy90b29scy9ibGVuZGVyJywgdmFyaWFu dF9kaXI9J3NyYy90b29scy9ibGVuZGVyL2J1aWxkJywNCglkdXBsaWNhdGU9MCwgZXhwb3J0 cz0ncGFyZW50X2VudiBwYXJlbnRfdGFyZ2V0cyBwYXJlbnRfcmVwb3J0JyApDQoNCiMgc3Bl Y2lhbCBzdHVmZg0KU0NvbnNjcmlwdCggZGlycz0nc3JjL2xhdW5jaGVyL3VzYmRyaXZlJywg dmFyaWFudF9kaXI9J3NyYy9sYXVuY2hlci91c2Jkcml2ZS9idWlsZCcsDQoJZHVwbGljYXRl PTAsIGV4cG9ydHM9J3BhcmVudF9lbnYgcGFyZW50X3RhcmdldHMgcGFyZW50X3JlcG9ydCcg KQ0KDQoNCg0KIyBhcmNoaXZpbmcNClNDb25zY3JpcHQoIGRpcnM9J2FyY2hpdmUnLCB2YXJp YW50X2Rpcj0nYXJjaGl2ZS9idWlsZCcsDQoJZHVwbGljYXRlPTAsIGV4cG9ydHM9J3BhcmVu dF9lbnYgcGFyZW50X3RhcmdldHMgcGFyZW50X3JlcG9ydCcgKQ0KDQoiIiINClNDb25zY3Jp cHQoICdzcmMvdG9vbHMvbGF1bmNoZXIvYW5kcm9pZC9TQ29uc2NyaXB0U3BlY2lhbCcsDQoJ dmFyaWFudF9kaXI9J3NyYy90b29scy9sYXVuY2hlci9hbmRyb2lkL2J1aWxkX2FwaycsDQoJ ZHVwbGljYXRlPTAsIGV4cG9ydHM9J3BhcmVudF9lbnYgcGFyZW50X3RhcmdldHMgcGFyZW50 X3JlcG9ydCcgKQ0KIiIiDQoNClNDb25zY3JpcHQoJ2FyY2hpdmUvU0NvbnNIYWlrdUhwa2cu cHknLCB2YXJpYW50X2Rpcj0nYXJjaGl2ZS9idWlsZFBhY2thZ2UnLA0KCWR1cGxpY2F0ZT0w LCBleHBvcnRzPSdwYXJlbnRfZW52IHBhcmVudF90YXJnZXRzIHBhcmVudF9yZXBvcnQnKQ0K DQoNCg0KIyBpbnN0YWxsZXJzDQpTQ29uc2NyaXB0KGRpcnM9J2luc3RhbGxlcicsIHZhcmlh bnRfZGlyPSdpbnN0YWxsZXIvYnVpbGQnLA0KCWR1cGxpY2F0ZT0wLCBleHBvcnRzPSdwYXJl bnRfZW52IHBhcmVudF90YXJnZXRzIHBhcmVudF9yZXBvcnQnKQ0KDQoNCiNwYXJhbXMuU2F2 ZSggJ3BhcmFtZXRlcnMuY2FjaGUnLCBwYXJlbnRfZW52ICkNCg0KIyBhZGQgYWxpYXNlcw0K YnVpbGRBbGwgPSBbXQ0KaW5zdGFsbEFsbCA9IFtdDQppbnN0YWxsQWxsUnVudGltZSA9IFtd DQppbnN0YWxsRW5naW5lUnVudGltZSA9IFtdDQppbnN0YWxsSWdkZVJ1bnRpbWUgPSBbXQ0K ZG94eWdlbkFsbCA9IFtdDQpjbG9jQWxsID0gW10NCmNsb2NSZXBvcnRzID0gW10NCg0KZm9y IGtleSBpbiBwYXJlbnRfdGFyZ2V0czoNCglpZiAnYnVpbGQnIGluIHBhcmVudF90YXJnZXRz WyBrZXkgXToNCgkJYnVpbGRBbGwuYXBwZW5kKCBwYXJlbnRfdGFyZ2V0c1sga2V5IF1bICdi dWlsZCcgXSApDQoJDQoJaWYgJ2luc3RhbGwnIGluIHBhcmVudF90YXJnZXRzWyBrZXkgXToN CgkJaW5zdGFsbEFsbC5hcHBlbmQoIHBhcmVudF90YXJnZXRzWyBrZXkgXVsgJ2luc3RhbGwn IF0gKQ0KCQlpZiAnaW5zdGFsbC1ydW50aW1lJyBpbiBwYXJlbnRfdGFyZ2V0c1sga2V5IF06 DQoJCQlpbnN0YWxsQWxsUnVudGltZS5hcHBlbmQoIHBhcmVudF90YXJnZXRzWyBrZXkgXVsg J2luc3RhbGwtcnVudGltZScgXSApDQoJCWVsc2U6DQoJCQlpbnN0YWxsQWxsUnVudGltZS5h cHBlbmQoIHBhcmVudF90YXJnZXRzWyBrZXkgXVsgJ2luc3RhbGwnIF0gKQ0KCQ0KCWlmICdp bnN0YWxsLWVuZ2luZS1ydW50aW1lJyBpbiBwYXJlbnRfdGFyZ2V0c1trZXldOg0KCQlpbnN0 YWxsRW5naW5lUnVudGltZS5hcHBlbmQocGFyZW50X3RhcmdldHNba2V5XVsnaW5zdGFsbC1l bmdpbmUtcnVudGltZSddKQ0KCQ0KCWlmICdpbnN0YWxsLWlnZGUtcnVudGltZScgaW4gcGFy ZW50X3RhcmdldHNba2V5XToNCgkJaW5zdGFsbElnZGVSdW50aW1lLmFwcGVuZChwYXJlbnRf dGFyZ2V0c1trZXldWydpbnN0YWxsLWlnZGUtcnVudGltZSddKQ0KCQ0KCWlmICdkb3h5Z2Vu JyBpbiBwYXJlbnRfdGFyZ2V0c1sga2V5IF06DQoJCWRveHlnZW5BbGwuYXBwZW5kKCBwYXJl bnRfdGFyZ2V0c1sga2V5IF1bICdkb3h5Z2VuJyBdICkNCgkNCglpZiAnY2xvYycgaW4gcGFy ZW50X3RhcmdldHNbIGtleSBdOg0KCQljbG9jQWxsLmFwcGVuZCggcGFyZW50X3RhcmdldHNb IGtleSBdWyAnY2xvYycgXSApDQoJCWNsb2NSZXBvcnRzLmFwcGVuZCggcGFyZW50X3Rhcmdl dHNbIGtleSBdWyAnY2xvY1JlcG9ydCcgXSApDQoNCnRhcmdldEJ1aWxkQWxsID0gcGFyZW50 X2Vudi5BbGlhcyggJ2J1aWxkJywgYnVpbGRBbGwgKQ0KcGFyZW50X3RhcmdldHNbICdidWls ZCcgXSA9IHsNCgknbmFtZScgOiAnQnVpbGQgRXZlcnl0aGluZycsDQoJJ3RhcmdldCcgOiB0 YXJnZXRCdWlsZEFsbCB9DQoNCnRhcmdldEluc3RhbGxBbGwgPSBwYXJlbnRfZW52LkFsaWFz KCAnaW5zdGFsbCcsIGluc3RhbGxBbGwgKQ0KcGFyZW50X3RhcmdldHNbICdpbnN0YWxsJyBd ID0gew0KCSduYW1lJyA6ICdJbnN0YWxsIEV2ZXJ5dGhpbmcnLA0KCSd0YXJnZXQnIDogdGFy Z2V0SW5zdGFsbEFsbCB9DQoNCnRhcmdldEluc3RhbGxBbGxSdW50aW1lID0gcGFyZW50X2Vu di5BbGlhcyggJ2luc3RhbGxfcnVudGltZScsIGluc3RhbGxBbGxSdW50aW1lICkNCnBhcmVu dF90YXJnZXRzWyAnaW5zdGFsbF9ydW50aW1lJyBdID0gew0KCSduYW1lJyA6ICdJbnN0YWxs IEV2ZXJ5dGhpbmcgUnVudGltZSAobm8gZGV2ZWxvcG1lbnQgZmlsZXMpJywNCgkndGFyZ2V0 JyA6IHRhcmdldEluc3RhbGxBbGxSdW50aW1lIH0NCg0KdGFyZ2V0SW5zdGFsbEVuZ2luZVJ1 bnRpbWUgPSBwYXJlbnRfZW52LkFsaWFzKCdpbnN0YWxsX2VuZ2luZV9ydW50aW1lJywgaW5z dGFsbEVuZ2luZVJ1bnRpbWUpDQpwYXJlbnRfdGFyZ2V0c1snaW5zdGFsbF9lbmdpbmVfcnVu dGltZSddID0gew0KCSduYW1lJyA6ICdJbnN0YWxsIEVuZ2luZSBSdW50aW1lIChubyBkZXZl bG9wbWVudCBmaWxlcyknLA0KCSd0YXJnZXQnIDogdGFyZ2V0SW5zdGFsbEVuZ2luZVJ1bnRp bWUgfQ0KDQp0YXJnZXRJbnN0YWxsSWdkZVJ1bnRpbWUgPSBwYXJlbnRfZW52LkFsaWFzKCdp bnN0YWxsX2lnZGVfcnVudGltZScsIGluc3RhbGxJZ2RlUnVudGltZSkNCnBhcmVudF90YXJn ZXRzWydpbnN0YWxsX2lnZGVfcnVudGltZSddID0gew0KCSduYW1lJyA6ICdJbnN0YWxsIElH REUgUnVudGltZSAobm8gZGV2ZWxvcG1lbnQgZmlsZXMpJywNCgkndGFyZ2V0JyA6IHRhcmdl dEluc3RhbGxJZ2RlUnVudGltZSB9DQoNCnRhcmdldERveHlnZW5BbGwgPSBwYXJlbnRfZW52 LkFsaWFzKCAnZG94eWdlbicsIGRveHlnZW5BbGwgKQ0KcGFyZW50X3RhcmdldHNbICdkb3h5 Z2VuJyBdID0gew0KCSduYW1lJyA6ICdEb3h5Z2VuIEV2ZXJ5dGhpbmcnLA0KCSd0YXJnZXQn IDogdGFyZ2V0RG94eWdlbkFsbCB9DQoNCmlmIGNsb2NSZXBvcnRzOg0KCXRhcmdldENsb2NT dW1tYXJ5ID0gcGFyZW50X2Vudi5BbGlhcyggJ2Nsb2Nfc3VtbWFyeScsDQoJCUJ1aWxkQ0xP Q1N1bW1hcnkoIHBhcmVudF9lbnYsIGNsb2NSZXBvcnRzLCAnY2xvY3N1bW1hcnkuY3N2JyAp ICkNCgljbG9jQWxsLmFwcGVuZCggdGFyZ2V0Q2xvY1N1bW1hcnkgKQ0KDQp0YXJnZXRDbG9j QWxsID0gcGFyZW50X2Vudi5BbGlhcyggJ2Nsb2MnLCBjbG9jQWxsICkNCnBhcmVudF90YXJn ZXRzWyAnY2xvYycgXSA9IHsNCgknbmFtZScgOiAnQ0xvYyBFdmVyeXRoaW5nJywNCgkndGFy Z2V0JyA6IHRhcmdldENsb2NBbGwgfQ0KDQojIGRlZmF1bHQgaXMgYnVpbGRpbmcgYW5kIGlu c3RhbGxpbmcgZXZlcnl0aGluZw0KRGVmYXVsdCggJ2luc3RhbGwnICkNCg0KDQoNCiMgcHJv ZHVjZSBoZWxwDQpIZWxwKCBCdWlsZEhlbHBUZXh0KCBwYXJlbnRfdGFyZ2V0cyApICkNCg0K IyBwcmludCBvdXQgcmVwb3J0DQpQcmludENvbmZpZ1JlcG9ydCggcGFyZW50X3JlcG9ydCAp DQo= --------------2213BD46D49BCD2C860E8E1F-- From owner-freebsd-stable@freebsd.org Wed Jul 15 22:29:14 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BEA10370BEC; Wed, 15 Jul 2020 22:29:14 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) (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 4B6X9j13Ddz4P8d; Wed, 15 Jul 2020 22:29:12 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 59EA258100C; Wed, 15 Jul 2020 18:29:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 15 Jul 2020 18:29:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.dev; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=E LGUs4n/WBH16Kw7woKSGvBg1VFX+D/v3+yQNeUAHX0=; b=buA8iYHjMGI7pGenB pcBN2UBXHx0De3HARkbpUaS+7BTZSmLDZwBZpEPrhxXuSNyf49EZyVE1RFdvhWHA v30l3X0WtxIrPV1NXZYrHqzzL0OH8b7HEFSngf/zYkhJN9gN+krxARk3lZSqhvWI IdCxRsp56EqWawN1Z41R2rFfAWUngNz0bJ9Wx4KfB+g9ybQBYUfaBiPBtRv5phV/ 3VsYfCQwVWYUwT5phfMddz1QqklfkKGPqVt2qrGbnYOKEz5PwA2Y+Zga7o5rIAUg +j1rEwkR9rKF+rtSt1WnqjFpCPT7vag9P/SSaZ1WLwrg64k2Y1fDFJomcAMFP3jW p3RRw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=ELGUs4n/WBH16Kw7woKSGvBg1VFX+D/v3+yQNeUAH X0=; b=UjTQtEqF8jv6abjN24I+nXNOoPGWOBHTXh13zB/sv5F3xnObfyks4mJEq VXnY4bUGbkwMlTMIl6nqnvwh7TgTjHbew6dPH0pc9hSIquqwoy2OZ17BQ/5VcH1b E5tyMPaM/cGVglfP+g8wGs5KsAHq/RQxxOY4yqhwaqGa5nl/wOqnnkX1T5Wyes2Z NdHtbG3i6jV63ci5QhfDFxa9T7e3TeiRXJULkDPRVl4bwzhuCjAdAmljo+TpfkGK kXp8cnjhfLJYC8IiiXTdVwZZY/HoUJzeXi6QmCwWW8u/FJtpSklc1ZV+U54MNiE4 s0waLLpNl/Jn0KkRzsT/uzqH9khUw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfeefgddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeehnecuhfhrohhmpegjuhhrihcu rfgrnhhkohhvuceohihurhhiphhvseihuhhrihhpvhdruggvvheqnecuggftrfgrthhtvg hrnhepffdvudffheegffejjeekieduffffgefgjefftedugeeiudfhheetfffhvefgtefg necukfhppeeluddrvdegtddruddvgedrudefjeenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpeihuhhrihhpvheshihurhhiphhvrdguvghv X-ME-Proxy: Received: from [192.168.1.6] (unknown [91.240.124.137]) by mail.messagingengine.com (Postfix) with ESMTPA id 2CCD33060067; Wed, 15 Jul 2020 18:29:10 -0400 (EDT) Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2020 To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> From: Yuri Pankov Message-ID: <7025a36e-52bf-ca18-185f-3c9adebdf26b@yuripv.dev> Date: Thu, 16 Jul 2020 01:29:09 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B6X9j13Ddz4P8d X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 22:29:14 -0000 Daniel Ebdrup Jensen wrote: [nothing] At least in Thunderbird the text is not inline, and rather shows as attachment. From owner-freebsd-stable@freebsd.org Wed Jul 15 22:59:36 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DB358372B31 for ; Wed, 15 Jul 2020 22:59:36 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6Xrm4spkz4ctF for ; Wed, 15 Jul 2020 22:59:36 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id 8E1F028F9; Wed, 15 Jul 2020 22:59:36 +0000 (UTC) Date: Thu, 16 Jul 2020 00:59:34 +0200 From: Daniel Ebdrup Jensen To: freebsd-stable@freebsd.org Subject: FreeBSD Quarterly Status Report - Second Quarter 2020 Message-ID: <20200715225934.jfasvsa3g36ssxwx@nerd-thinkpad.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6ppadjxpmznoj5nk" Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 22:59:36 -0000 --6ppadjxpmznoj5nk Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - Second Quarter 2020 Introduction This report will be covering FreeBSD related projects between April and June, and covers a diverse set of topics ranging from kernel updates over userland and ports, as well to third-party work. Some hilights picked with the roll of a d100 include, but are not limited to, the ability to forcibly unmounting UFS when the underlying media becomes inaccessible, added preliminary support for Bluetooth Low Energy, a introduction to the FreeBSD Office Hours, and a repository of software collections called potluck to be installed with the pot utility, as well as many many more things. As a little treat, readers can also get a rare report from the quarterly team. Finally, on behalf of the quarterly team, I would like to extend my deepest appreciation and thank you to salvadore@, who decided to take down his shingle. His contributions not just the quarterly reports themselves, but also the surrounding tooling to many-fold ease the work, are immeassurable. We hope you find the report as interesting as we have, Daniel Ebdrup Jensen (debdrup@), on behalf of the quarterly team. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Foundation * FreeBSD Core Team * FreeBSD Release Engineering Team * Cluster Administration Team * Continuous Integration * Ports Collection * FreeBSD Office Hours * Quarterly Status Reports Team Projects * FreeBSD on Microsoft HyperV and Azure * Git Migration Working Group * Lua Usage in FreeBSD * Linux compatibility layer update * NFS over TLS implementation Kernel * SoC audio framework and more audio drivers * bhyve - NVMe emulation improvements * Bluetooth Support * DRM Drivers Update * DTS Update * ENA FreeBSD Driver Update * Forcible Unmount of UFS/FFS Filesystems on Disk Failure * i.MX 8M support * Intel wireless and 11ac update * amd64 5-Level Paging Structures support * Not-transparent superpages * NXP ARM64 SoC support * amd64 pmap Fine-grained pv lists locking * Lockless routing lookups and scalable multipath * ZSTD Compression in ZFS * CheriBSD 2020 Q2 Architectures * Continuous Integration on !x86 * FreeBSD/RISC-V Project Userland Programs * Import of new implementation of bc and dc * Binutils Retirement * Run-Time Dynamic Linker improvements * VHDX support in mkimg(1) Ports * Bastille * KDE on FreeBSD * Haskell on FreeBSD * rtsx - Porting driver for Realtek SD card reader from OpenBSD * Valgrind updates Documentation * FreeBSD Translations on Weblate Miscellaneous * FreshPorts * PCI passthrough with bhyve on Intel and for OpenBSD guests * SageMath Third-Party Projects * chaifi - a tool to simplify joining public WiFi networks * MixerTUI * Potluck - Flavour & Image Repository for pot __________________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Foundation Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides resources to improve security, quality assurance, and release engineering efforts; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: COVID-19 Impact to the Foundation Like other organizations, we put policies in place for all of our staff members to work from home. We also put a temporary ban on travel for staff members. We are continuing our work supporting the community and Project, but some of our work and responses may be delayed because of changes in some of our priorities and the impact of limited childcare for a few of our staff members. Partnerships and Commercial User Support We help facilitate collaboration between commercial users and FreeBSD developers. We also meet with companies to discuss their needs and bring that information back to the Project. Not surprisingly, the stay at home orders, combined with our company ban on travel during Q2 made in-person meetings non-existent. However, the team was able to continue meeting with our partners and commercial users virtually. These meetings help us understand some of the applications where FreeBSD is used. Fundraising Efforts Last quarter we raised $268,400! Thank you to the individuals and organizations that stepped in to help fund our efforts. We'd like to thank Netflix, employees of Nginx, Beckhoff Automation, and Mozilla Foundation for their large contributions last quarter, which helped bring our 2020 fundraising effort to $339k. We hope other organizations will follow their lead and give back to help us continue supporting FreeBSD. These are trying times, and we deeply appreciate every donation that has come in from $5 to $150,000. We're still here giving 110% to supporting FreeBSD! We are 100% funded by donations, and those funds go towards software development work to improve FreeBSD, FreeBSD advocacy around the world, keeping FreeBSD secure, continuous integration improvements, sponsoring BSD-related and computing conferences (even the virtual events!), legal support for the Project, and many other areas. Please consider making a donation to help us continue and increase our support for FreeBSD. We also have the Partnership Program, to provide more benefits for our larger commercial donors. Find out more information about the partnership program and share with your companies! OS Improvements A number of FreeBSD Foundation grant recipients started, continued working on, or completed projects during the second quarter. These include: * WiFi improvements * Linuxulator application compatibility * DRM / Graphics driver updates * Zstd compression for OpenZFS * Online RAID-Z expansion * if_bridge performance improvements You can find more details about most of these projects in other quarterly reports. Staff members also worked on a number of larger projects, including: * Run-Time Dynamic Linker (rtld) improvements * Improved FreeBSD support on Microsoft HyperV and Azure * Fine-grained locking for amd64 pmap * 5-level paging structures for amd64 * Non-transparent superpages * Migration to a Git repository * Tool chain modernization Many of these projects also have detailed entries in other quarterly report entries. Staff members also put in significant effort in many ways other than larger, individual projects. These include assisting with code reviews, bug report triage, security report triage and advisory handling, addressing syzkaller reports, and ongoing maintenance and bug fixes in functional areas such as the tool chain, developer tools, virtual memory kernel subsystem, low-level x86 infrastructure, sockets and protocols, and others. University of Waterloo Co-op Foundation co-op students Colin, Tiger, and Yang completed their winter 2020 work term during the second quarter, and continued on with the next school term in their respective programs. Although COVID-19 presented a unique challenge and prompted an abrupt transition to remote work just over half way through the term, all three learned a lot and provided positive contributions to the FreeBSD Project and to the Foundation. A few projects that were in progress or completed during the work term were committed to the FreeBSD tree in the second quarter. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member who is working on improving continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. During the second quarter of 2020, Foundation staff continued improving the Project's CI infrastructure, monitoring regressions and working with contributors to fix the failing build and test cases. The setting up of VM host for CI jobs and staging environment is in progress. We are also working with other teams in the Project for their testing needs. For example, we added jobs for running full tests on non-x86 architectures. We are also working with many external projects and companies to improve their support of FreeBSD. See the FreeBSD CI section of this report for completed work items and detailed information. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. We started working on getting the new NYI Chicago colocation facility prepared for some of the new FreeBSD hardware we are planning on purchasing. NYI generously provides this for free to the Project. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. As is the case for most of us in this industry, COVID-19 has put our in-person events on hold. In addition to attending virtual events, we are continually working on new training initiatives and updating our selection of how-to guides to facilitate getting more folks to try out FreeBSD. Check out some of the advocacy and education work we did last quarter: * Silver sponsor of BSDCan 2020. The event was held virtually, June 2-6, 2020 * Community Sponsor of Rootconf 2020. The event was held virtually, June 19-20, 2020 * Annual FreeBSD Day, June 19. This year's celebration was postponed in support of Juneteeth. However the activities surrounding FreeBSD Day have been transformed into an ongoing series of online sessions. See FreeBSD Fridays below for more information. * Presented 27 Years of FreeBSD and Why You Should Get Involved as part of a Linux Professional Institute series of webinars on June 24, 2020. * Attended and presented at the virtual Open Source Summit 2020. * Announced FreeBSD Fridays: A series of 101 classes designed to get you started with FreeBSD. Find out more in the announcement * Participated as an Admin for Google Summer of Code 2020 * Participated in the new FreeBSD Office Hours series including holding our own Foundation led office hours. Videos from the one hour sessions can be found on the Project's YouTube Channel. You can watch ours here. In addition to the information found in the Development Projects update section of this report, take a minute to check out the latest update blogs: * 5x if_bridge Performance Improvement * My Experience as a FreeBSD Foundation Co-Op Student Keep up to date with our latest work in our Bi-Monthly newsletters. Mellanox provided an update on how and why they use FreeBSD in our latest Contributor Case Study. We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues on the Journal site. You can find out more about events we attended and upcoming events. We have continued our work with a new website developer to help us improve our website. Work is nearly complete to make it easier for community members to find information more easily and to make the site more efficient. We look forward to unveiling the refreshed site in Q3. Foundation Board Meeting Our annual board meeting was held on Tuesday June 2, 2020. We normally hold this meeting the Tuesday before BSDCan, in Ottawa, Ontario, Canada, but with the company travel ban, and the conference going virtual, our meeting went virtual for the first time. The purpose of the annual board meeting is to hold our board director and officer elections, review work accomplished over the past year, and put together strategic goals for the upcoming 12 months. The board generally has two all-day board meetings each year, this one, and a more informal one in January, typically held in Berkeley. Both meetings allow us to connect, reevaluate and discuss new ideas, while assessing what we should do to help the Project. Some of our longer-term goals include Growing User and Developer Communities, Developing Training and OS Course Content, Improving desktop/laptop experience, Promoting FreeBSD (as you can see in all the advocacy work listed above), and Improving Testing Capabilities. Results of the director and officer elections were: * Justin Gibbs (President) * Benedict Reuschling (Vice President) * Kirk McKusick (Treasurer) * Philip Paeps (Secretary) * Deb Goodkin (Assistant Secretary) * Robert Watson (Director) * Hiroki Sato (Director) * George Neville-Neil (Director) Find out more about the FreeBSD Foundation Board of Directors on our website. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to the FreeBSD Foundation's web site to find out how we support FreeBSD and how we can help you! __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. The Core Team held 10 meetings during the second quarter of 2020, including a 2020-05-21 joint meeting with members of the FreeBSD Foundation. Here are some highlights from that meeting: * Deb requested guidance on how the Foundation can support the community. Core and Foundation members believe that more developer support is necessary to fill gaps in areas where commercial customers do not provide backing. The clearest example of such a gap is the desktop experience, including graphics and wireless support. What makes this request different from past requests is that rather than support for one-time projects, ongoing positions are necessary for a consistently high-quality desktop experience. "FreeBSD not being able to run on your laptop is the first step to irrelevance." Ed Maste * Both teams discussed topics for upcoming sessions of FreeBSD Office Hours, informal FreeBSD video conferences that anyone can attend. Everyone agreed that the Office Hours have been a useful way for different parts of the Project to engage with each other and with the wider community. Kudos to Allan Jude for initiating the Office Hours and for everyone who has helped make them a success by hosting or attending sessions. * Both teams agreed that they should meet once per quarter. The second annual community survey closed on 2020-06-16. The purpose of the survey is to collect data from the public to help guide the Project's efforts and priorities. As an example, last year's survey results helped initiate the Project's conversion to Git. Thank you to all who took the time to respond. The results will be released soon. The Core-initiated Git Working Group continued to make progress, but there are still some remaining issues to be worked out with the translation from Subversion. Hopefully the new Git src repository will be ready for use this summer. A beta version has been published for people to test and a preliminary version of a Using Git for FreeBSD Development primer will soon be ready to share. Core, the Git Working Group, and Release Engineering are working towards the goal of releasing 12.2 from the new Git repository. Following the results of a Core-initiated developer survey, The FreeBSD Project has adopted a new LLVM-derived [code of conduct](https://www.freebsd.org/internal/code-of-conduct.html). The eleventh FreeBSD Core Team was elected by active developers. From a pool of 23, the 9 successful candidates for core.11 are: * Sean Chittenden (seanc, incumbent) * Baptiste Daroussin (bapt) * Kyle Evans (kevans) * Mark Johnston (markj) * Scott Long (scottl) * Warner Losh (imp, incumbent) * Ed Maste (emaste) * George V. Neville-Neil (gnn) * Hiroki Sato (hrs, incumbent) A new Core Team secretary, Muhammad Moinur Rahman (bofh), was unanimously approved by core.11. The outgoing core team met three times with the new core team to help with the transition. Core.10 wishes core.11 a successful term. __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 11.4-RELEASE announcement=20 URL: https://www.freebsd.org/releases/11.4R/announce.html FreeBSD 11.4-RELEASE schedule=20 URL: https://www.freebsd.org/releases/11.4R/schedule.html FreeBSD development snapshots=20 URL: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code slushes, and maintaining the respective branches, among other things. During the second quarter of 2020, the Release Engineering Team started work on the 11.4-RELEASE cycle, the fifth release from the stable/11 branch. The release cycle went quite smoothly, with both BETA3 and RC3 removed from the schedule. This allowed the final release to occur one week earlier than originally scheduled, which was announced June 16. FreeBSD 11.4-RELEASE is expected to be the final 11.x release. The FreeBSD Release Engineering Team would like to thank everyone involved in this cycle for their hard work. Additionally throughout the quarter, several development snapshots builds were released for the head, stable/12, and stable/11 branches. Much of this work was sponsored by Rubicon Communications, LLC (netgate.com) and the FreeBSD Foundation. __________________________________________________________________ Cluster Administration Team Links Cluster Administration Team members=20 URL: https://www.freebsd.org/administration.html#t-clusteradm Contact: Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the Project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on the following: * Upgrade all x86 ref- and universe-machines * Setup Amsterdam (PKT) mirror * Solve hardware issue for bugzilla and svnweb backend * Setup public beta git server * Decommission CyberOne Data (CYB) mirror * Ongoing systems administration work: + Accounts management for committers. + Backups of critical infrastructure. + Keeping up with security updates in 3rd party software. Work in progress: * Setup Malaysia (KUL) mirror * Setup Brazil (BRA) mirror * Review the service jails and service administrators operation. * Infrastructure of building aarch64 and powerpc64 packages + NVME issues on PowerPC64 Power9 blocking dual socket machine from being used as pkg builder. + Drive upgrade test for pkg builders (SSDs) courtesy of the FreeBSD Foundation. + Boot issues with Aarch64 reference machines. * New NYI.net sponsored colocation space in Chicago-land area. * Work with git working group * Check new hardware requirement from other teams * Searching for more providers that can fit the requirements for a generic mirrored layout or a tiny mirror __________________________________________________________________ Continuous Integration Links FreeBSD Jenkins Instance=20 URL: https://ci.FreeBSD.org FreeBSD Hardware Testing Lab=20 URL: https://ci.FreeBSD.org/hwlab FreeBSD CI artifact archive=20 URL: https://artifact.ci.FreeBSD.org FreeBSD CI weekly report=20 URL: https://hackmd.io/@FreeBSD-CI FreeBSD Jenkins wiki=20 URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki=20 URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI=20 URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@=20 URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository=20 URL: https://github.com/freebsd/freebsd-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system for the FreeBSD project. The CI system firstly checks the committed changes can be successfully built, then performs various tests and analysis over the newly built results. The artifacts from the build jobs are archived in the artifact server for further testing and debugging needs. The CI team members examine the failing builds and unstable tests and work with the experts in that area to fix the codes or adjust test infrastructure. The details of these efforts are available in the weekly CI reports. During the second quarter of 2020, we continue working with the contributors and developers in the project for their testing needs and also keep working with external projects and companies to improve their support of FreeBSD. Important changes: * All -test jobs will run tests under /usr/tests, previously only x86 architectures doing this. See the Continuous Integration on !x86 section in this report for more information. * Compression algorithm of disk images on the artifact server has been changed to zstd to speed up compression and decompression. * The build and test results will be sent to the dev-ci mailing list soon. Feedback and help with analysis is very appreciated! New jobs added: * https://ci.freebsd.org/job/FreeBSD-head-armv7-test/ * https://ci.freebsd.org/job/FreeBSD-head-aarch64-test/ * https://ci.freebsd.org/job/FreeBSD-head-mips64-test/ * https://ci.freebsd.org/job/FreeBSD-head-powerpc64-test/ Work in progress: * Collecting and sorting CI tasks and ideas here * Testing and merging pull requests in the the FreeBSD-ci repo * Setting up a builder dedicated to run jobs using provisioned VMs. * Setting up the CI stage environment and putting the experimental jobs on it * Implementing automatic tests on bare metal hardware * Adding drm ports building tests against -CURRENT * Planning to run ztest and network stack tests * Adding external toolchain related jobs * Improving the hardware lab to be more mature and adding more hardware * Helping more 3rd software get CI on FreeBSD through a hosted CI solution * Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and don't hesistate to join the effort! Sponsor: The FreeBSD Foundation __________________________________________________________________ Ports Collection Links About FreeBSD Ports=20 URL: https://www.FreeBSD.org/ports/ Contributing to Ports=20 URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html FreeBSD Ports Monitoring=20 URL: http://portsmon.freebsd.org/index.html Ports Management Team=20 URL: https://www.freebsd.org/portmgr/index.html Contact: Ren=E9 Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. There are currently 2,373 open ports PRs of which 526 are unassigned, for a total of 39,628 ports. In the last quarter there were 10,315 commits to HEAD and 476 to the quarterly branch by respectively 178 and 65 committers. Compared to the quarter before, this means a significant increase in commits and also a slight decrease in open PRs. During the last quarter, we welcomed Hiroki Tagato (tagattie@). We said goodbye to seanc@, zleslie@, gnn@ and salvadore@. A few default versions got bumped: * Java (new) at 8 * Lazarus to 2.0.8 It is now possible to write pkg scripts in Lua instead of sh. They have two advantages over their sh versions: * they run in a Capsicum sandbox * they respect rootdir, the directory which pkg will use as the starting point to install all packages under. Some user-facing packages were also updated: * pkg to 1.14.6 * Firefox to 78.0.1 * Thunderbird to 68.10.0 * Chromium to 83.0.4103.116 * Ruby to 2.5.8, 2.6.6, and 2.7.1 * Qt5 to 5.14.2 During the last quarter, antoine@ ran 55 exp-runs to test port version updates, make liblzma use libmd, flavor devel/scons and Lua ports, add and update library functions in the base system, make malloc.h usable again, remove as(1) from the base system, and augment sed(1) with -f. __________________________________________________________________ FreeBSD Office Hours Links Office Hours on the FreeBSD Wiki=20 URL: https://wiki.freebsd.org/OfficeHours Poll: What time would you prefer Office Hours be at=20 URL: https://forms.gle/3HjjRx9KMcM3SL4H7 live.FreeBSD.org: Aggregation of Live streams=20 URL: https://live.freebsd.org/ Contact: Allan Jude Starting on the first of April 2020, the FreeBSD project has started hosting regular video streams to foster greater communication within the wider FreeBSD community. The first of these sessions took the form of a public question and answer session, which drew over 60 participants. A second session was held two weeks later at a time more appropriate for those in Asia, but only drew 20 participants. With the help of the FreeBSD Foundation, we ran a poll to discover what times worked best for the greatest number of people. On May 13th the FreeBSD Foundation hosted a session where the community could ask questions of or about the foundation. On May 27th many of the candidates for the new FreeBSD Core Team joined an office hours session to answer questions from the community. Finally on June 24th another general question and answer office hours was held. Each office hours session consists of a video meeting of some FreeBSD developers or other subject matter experts, live streamed along with an IRC chat room for viewers to pose questions to the panel. The stream is recorded and posted to the official FreeBSD youtube channel. If you would like to host an office hours session, please contact: * Allan Jude * Anne Dickison Sponsor: ScaleEngine Inc. (video streaming) __________________________________________________________________ Quarterly Status Reports Team Links Quarterly status reports=20 URL: https://www.freebsd.org/news/status/ Git repository =20 URL: https://github.com/freebsd/freebsd-quarterly Contact: Quarterly Status Reports Contact: Daniel Ebdrup Jensen The Quarterly Status Reports Team collects and publish the reports that you are reading right now. Many improvements have been done recently and thus we believe it is useful that the Quarterly Status Reports Team submits a report. Not all the changes below are specific to the last quarter, but we list them here anyway since we did not write an entry for earlier reports. * Reports are now built using Makefiles. Among the many advantages, this allows us to easily sort reports logically. Indeed, starting with 2019Q4, all reports are sorted logically, while before they were sorted alphabetically within each category. * The conversion from markdown to docbook was performed using a python script, with some known bugs. Salvadore has rewritten the script using perl fixing most of the bugs. Some features are missing and many improvements are possible, but the script is very unlikely to receive any change since it will become obsolete as soon as the conversion to Hugo/AsciiDoctor is completed. * Another perl script to ease the preparation of the mail version of the reports was written. * One more perl script has been written to allow the quarterly team to send quarterly calls automatically using a cron job. We used it this quarter for the first time. * As you might have noticed, last quarterly calls have been sent to freebsd-quarterly-calls@: this is a new mailing list to which you can subscribe to receive calls for quarterly reports. Please note this is a moderated list, with very low traffic and a high signal to noise ratio. * If you read carefully the last quarterly calls, you should have noticed that we now ask you to send reports to quarterly-submissions@ instead of quarterly@. This was done to help the quarterly team distinguishing internal discussions from submissions. Please keep in mind however that the quarterly team prefers receiving pull requests, as they ease the administrative work. We would like to thank philip@, from the postmaster team, for having created the freebsd-quarterly-calls@ mailing list and the quarterly-submissions@ address for us. __________________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. FreeBSD on Microsoft HyperV and Azure Links FreeBSD on MicrosoftAzure wiki=20 URL: https://wiki.freebsd.org/MicrosoftAzure FreeBSD on Microsoft HyperV =20 URL: https://wiki.freebsd.org/HyperV Contact: FreeBSD Integration Services Team Contact: Wei Hu Contact: Li-Wen Hsu HyperV socket for FreeBSD implemented by Wei was checked into FreeBSD head branch on May 20th as r361275. It supports guest/host communications without the need for networking. Some HyperV and Azure features rely on this to be available in guests. Details of HyperV Socket is available here. This project is sponsored by Microsoft. Li-Wen is working on the FreeBSD release code related to Azure for the -CURRENT, 12-STABLE and 11-STABLE branches. The work-in-progress is available here. The 12.1-RELEASE image on Azure Marketplace is published. The work on the 11.4-RELEASE image on Azure Marketplace is in progress. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Git Migration Working Group Links Git conversion tooling repo=20 URL: https://github.com/freebsd/git_conv FreeBSD-git mailing list=20 URL: https://lists.freebsd.org/mailman/listinfo/freebsd-git Beta doc git repo=20 URL: https://cgit-beta.FreeBSD.org/doc Beta ports git repo=20 URL: https://cgit-beta.FreeBSD.org/ports Beta src git repo=20 URL: https://cgit-beta.FreeBSD.org/src Contact: Ed Maste Contact: Warner Losh Contact: Ulrich Sp=F6rlein Work continues on FreeBSD's migration from Subversion to Git. Ulrich has iterated on updates to svn2git in order to improve the fidelity of the conversion, particularly in regards to vendor (contrib) code updates. We believe the conversion is now at an acceptable state, but may make minor adjustments if additional issues are found. We expect to push modifications to the converter every two weeks (first and third Sunday of the month). This means that commit hashes in the beta repo will remain stable for at least two weeks at a time, to allow others to test and experiment with the beta repo. We are now working on updating FreeBSD processes and documentation. This includes: * Writing a Git Primer, akin to the existing Subversion primer * Updates to the Security Team's tools and processes * Release engineering updates * Ports and packages process updates Those with an interest in the migration to Git are encouraged to subscribe to the FreeBSD-git mailing list and test out the beta src, ports, and/or doc repositories. You are also welcome check out the wiki, issues, README and other documentation at the Git conversion tooling repo. We expect to be ready for the migration in the next quarter. Sponsor: The FreeBSD Foundation (in part) __________________________________________________________________ Lua Usage in FreeBSD Contact: Ed Maste Contact: Kyle Evans Contact: Ryan Moeller Lua is a small, efficient scripting language that FreeBSD imported before FreeBSD 12.0 for use in the bootloader. Since then, several projects outside of the bootloader have gained some amount of traction with Lua usage: * /usr/libexec/flua is now installed for internal usage * makesyscalls.sh was rewritten in Lua * pkg has gained support for lua scripts * lldb in the base system now supports lua scripting FreeBSD Lua ("flua") is a version of the lua interpreter that has several modules built-in for convenient usage within the base system. flua is installed with a non-standard name and in a location not included in $PATH so that it is not accidentally found by third-party software or configure scripts. The FreeBSD project makes no guarantees about upgrade cadence or module stability. That said, it is available for use by downstream projects and FreeBSD users aware of those limitations. Previous work with flua includes, for example, adding libucl support and future work includes libifconfig support for scripting usage. People interested in working with Lua in FreeBSD are welcome to get in contact to discuss other project ideas. To name a couple of potential projects, some interesting modules that have not been started but could prove useful (listed in no particular order): * libcrypt * libexpat * libjail * libnv * libxo __________________________________________________________________ Linux compatibility layer update Contact: Edward Tomasz Napierala Earlier Linuxulator work focused on code cleanups and improving diagnostic tools. Work has now shifted from cleanups to fixing actual applications. Current status is being tracked at Linux app status Wiki page. Initial focus is on applications that don't involve X11, mostly because they tend to be easier to test and debug, and the bug fixes are not application-specific. Example problems fixed include buggy madvise(2) handling, which could break applications linked against jemalloc; uname(2) returning wrong results for 32 bit apps, which caused problems for Steam; recvmsg(2) and accept(2) being broken in some circumstances, which was breaking Redis; and missing support for SO_REUSEPORT, SO_SNDBUFFORCE, SO_RCVBUFFORCE, and SO_PROTOCOL, which spammed the log files when running the Python regression test suite. The default soft open files limit is now automatically adjusted to 1024, as several Linux apps iterate over all the file descriptors up to that limit instead of using closefrom(2). There's ongoing work on cleanups and the debugging framework for Linux compatibility, such as logging warnings for unrecognized system call parameters, or adding the compat.linux.debug sysctl to turn the warnings off. The Linux Test Project tests that are being run as part of the the FreeBSD Continuous Integration infrastructure has been upgraded to 20200605 snapshot. This raised the number of test cases from 3670 to 3749, and, predictably, also the number of failures, from 583 to 647. There's still a lot to do: * There are pending reviews for patches that add extended attributes support, and fexecve(2) syscall, and they require wrapping up and committing * There are over 500 failing LTP tests. Some of them are false positives, some are easy to fix bugs, and some require adding new system calls. Any help is welcome. Sponsor: The FreeBSD Foundation __________________________________________________________________ NFS over TLS implementation Contact: Rick Macklem In an effort to improve NFS security, an internet draft which I expect will become an RFC soon specifies the use of TLS 1.3 to encrypt all data traffic on a Sun RPC connection used for NFS. Although NFS has been able to use sec=3Dkrb5p to encrypt data on the wire, this requires a Kerberos environment and, as such, has not been widely adopted. It also required that encryption/decryption be done in software, since only the RPC message NFS arguments are encrypted. Since Kernel TLS is capable of using hardware assist to improve performance and does not require Kerberos, NFS over TLS may be more widely adopted, once implementations are available. The project to implement this has largely been completed. The code will slowly be merged into head/current and at least the kernel portion should be in FreeBSD-13. To support clients such as laptops, the daemons that perform the TLS handshake may optionally handle client X.509 certificates from a site local CA. There are now exports(5) options to require client(s) to provide a valid X.509 certificate. The code is now available for testing. See: https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt Setting up system(s) for testing is still a little awkward, as explained by the above rough document. The main limitation in the current implementation is that it uses TLS1.2 and not TLS1.3. This should change once the KERN_TLS rx patch includes TLS1.3 support. Also, testing of pNFS configurations has not yet been done, but will be tested soon. Third party testing would be appreciated. __________________________________________________________________ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. SoC audio framework and more audio drivers Links rk3399_audio=20 URL: https://github.com/gonzoua/freebsd/tree/rk3399_audio Contact: Oleksandr Tymoshenko SoC audio framework made a good progress since last report. Support for AUX devices was added (devices like auxiliary amplifiers that are not part of main CODEC chip). To verify the framework design following audio drivers were added: recording support for RT5640 CODEC(Firefly-RK3399), Allwinner I2S, Alwinners sun8i and A64 CODECs (Pine A64+), both recording and playback. Current work in progress is RK3328 CODEC (Rock64) and ES8316 CODEC (RockPro64 and Pinebook Pro). __________________________________________________________________ bhyve - NVMe emulation improvements Links bhyve NVMe reviews=20 URL: https://reviews.freebsd.org/search/query/xvbcF20W__Km/ Contact: Chuck Tuffli The University of New Hampshire InterOperability Laboratory (a.k.a. UNH IOL) develops a suite of tests to determine if an NVMe device conforms to the specification and is interoperable with other NVMe products. This quarter, I undertook getting bhyve's emulated NVMe device to pass the mandatory tests. Changes include: * implement Flush command * implement Format NVM command * implement AER support * implement Namespace Identification Descriptor * fix Active Namespace list * fix queue creation and deletion * validate Deallocate range values * handle zero length DSM ranges * fix Get Log Page command * implement SMART data I/O statistics * validate the LBA start and count * add basic Firmware Commit support * add more compliant Get/Set Features * add Feature, Interrupt Vector Config * fix Get Features, Predictable Latency This was also a good opportunity to restructure parts of the code to make it more modular and easier to enhance. This includes * convert logging statements to parameterized macros * refactor I/O command handling * add locks around queue accesses * consolidate CQ update * base pci_nvme_ioreq size on advertised MDTS You can help by testing and/or commenting on the code reviews. __________________________________________________________________ Bluetooth Support Contact: Marc Veldman Bluetooth is a wireless technology for creating personal networks, connecting peripherals like keyboards and mice but also speakers and heart rate monitors. FreeBSD has limited Bluetooth Basic Rate (BR) support and no functional Bluetooth Low Energy (LE) support. During this quarter many small improvements have been made to help the development of Bluetooth LE support. A number of commands have been added to hccontrol(8), mainly to do LE functions. It is now possible to scan for LE devices within range using hccontrol. A panic that occurred when enabling LE support has also been fixed. Work is still needed to add Attribute Protocol (ATT) and Generic Attribute Profile (GATT) support. __________________________________________________________________ DRM Drivers Update Links drm-kmod=20 URL: https://github.com/freebsd/drm-kmod/ Contact: Emmanuel Vadot The drm drivers for FreeBSD 13-CURRENT have been updated to match Linux 5.3 This brings us a little bit closer to the last LTS release of Linux (5.4). The current plan is to first update the driver to match 5.4 and then look at making it work on FreeBSD-12-STABLE to have it ready for the 12.2 release. Sponsor: The FreeBSD Foundation __________________________________________________________________ DTS Update Contact: Emmanuel Vadot DTS files (Device Tree Sources) were updated to be on par with Linux 5.7 for HEAD and 5.6 for the 12-STABLE branch. __________________________________________________________________ ENA FreeBSD Driver Update Links ENA README=20 URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/R= EADME Contact: Michal Krawczyk Contact: Artur Rojek Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used. Completed since the last update: * Fixes for Rx refill to improve stability on low memory conditions (also released as an errata notice for FreeBSD-12.1) * Upstream of the v2.2.0 driver, introducing: + Add driver support for the upcoming HW features (reporting Tx drops, disabling meta caching) + Add sysctl tuneables for IO queue number + Create IO queues with optional size backoff + Rework the way of configration of drbr and Rx ring size to be more robust and stable + New HAL version + Driver is now marked as epoch ready + Default RSS key is created using RNG to improve security + Other minor fixes and improvements * MFC of the ENA v2.2.0 driver to the FreeBSD 11.4 Sponsor: Amazon.com Inc __________________________________________________________________ Forcible Unmount of UFS/FFS Filesystems on Disk Failure Links Phabricator Details=20 URL: https://reviews.freebsd.org/D24088 Contact: Chuck Silvers Contact: Kirk McKusick Commit -r361491 on May 25, 2020 enables a UFS file system to do a forcible unmount when the underlying media fails or becomes inaccessible. For example when a USB flash memory card hosting a UFS file system is unplugged. The rest of this report describes in more detail how forcible unmounts are done. Suprisingly, less than 500 lines of file system code were added or changed. The strategy for handling disk I/O errors when soft updates are enabled is to stop writing to the disk of the affected file system but continue to accept I/O requests and report that all future writes by the file system to that disk actually succeed. Then initiate an asynchronous forced unmount of the affected file system. There are two cases for disk I/O errors: * ENXIO, which means that this disk is gone and the lower layers of the storage stack already guarantee that no future I/O to this disk will succeed. * EIO (or most other errors), which means that this particular I/O request has failed but subsequent I/O requests to this disk might still succeed. For ENXIO, we can just clear the error and continue, because we know that the file system cannot affect the on-disk state after we see this error. For EIO or other errors, we arrange for the geom_vfs layer to reject all future I/O requests with ENXIO just like is done when the geom_vfs is orphaned. In both cases, the file system code can just clear the error and proceed with the forcible unmount. This new treatment of I/O errors is needed for writes of any buffer that is involved in a dependency. Most dependencies are described by a structure attached to the buffer's b_dep field, but some are created and processed as a result of the completion of the dependencies attached to the buffer. Clearing of some dependencies require a read. For example if there is a dependency that requires an inode to be written, the disk block containing that inode must be read, the updated inode copied into place in that buffer, and the buffer then written back to disk. Often the needed buffer is already in memory and can be used. But if it needs to be read from the disk, the read will fail, so we fabricate a buffer full of zeroes and pretend that the read succeeded. This zero'ed buffer can be updated and "written" back to disk. The only case where a buffer full of zeros causes the code to do the wrong thing is when reading an inode buffer containing an inode that still has an inode dependency in memory that will reinitialize the effective link count (i_effnlink) based on the actual link count (i_nlink) that we read. To handle this case we now store the i_nlink value that we wrote in the inode dependency so that it can be restored into the zero'ed buffer thus keeping the tracking of the inode link count consistent. Because applications depend on knowing when an attempt to write their data to stable storage has failed, the fsync(2) and msync(2) system calls need to return errors if data fails to be written to stable storage. So these operations return ENXIO for every call made on files in a file system where we have otherwise been ignoring I/O errors. Sponsor: Netflix __________________________________________________________________ i.MX 8M support Links D25274=20 URL: https://reviews.freebsd.org/D25274 Contact: Oleksandr Tymoshenko i.MX 8M is the family of application processors from NXP based on Arm=AE Cortex=AE-A53 and Cortex-M4 cores. The initial code drop for the platform support includes CCM driver and clock implementation, GPC driver, clock tree for i.MX 8M Quad. Most of the drivers from i.MX 6 can be reused for i.MX 8M systems with relatively minor modifications. Common changes include adding clock support and extending list of FDT compat strings. With the linked patch FreeBSD successfully booted to multiuser with NFS root on Nitrogen8M SBC. __________________________________________________________________ Intel wireless and 11ac update Links Initial project announcement=20 URL: https://lists.freebsd.org/pipermail/freebsd-wireless/2020-April/00= 9055.html The freebsd-wireless mailing list=20 URL: https://lists.freebsd.org/mailman/listinfo/freebsd-wireless Contact: Bjoern A. Zeeb The Intel Wireless cards are one of the most commonly used and ask for in FreeBSD notebooks. This project has three main goals: * newer Intel Wireless device support, * newer WiFi standards support for Intel Wireless, * integration of 802.11ac client support and infrastructure in FreeBSD. The first one is needed as iwm(4) currently does not support the latest generations of Intel Wireless cards at all. The second is needed as in FreeBSD iwm(4) does not even support 802.11n. The third one we want to catch up and use the improvements the new Wifi standard offers, e.g., speed. One of the decisions made was: rather than improving iwm(4) this work uses the dual-licensed native Linux driver under BSD license and the linuxkpi framework to stay as close to upstream as possible as a first step. This will give us several advantages, such as, the full support for all cards, quick support for new chipsets, vendor bug fixes, but also the ability to contribute back. At this point the lower level hardware attachments and the firmware loading and initialisation works. I plan to release a patchset for testing before mid-July, you can see if your currently supported or unsupported hardware will be detected. This first cut will not support any wireless operation yet, which will follow later in the year. If you want to help testing, please watch the freebsd-wireless list. Sponsor: The FreeBSD Foundation __________________________________________________________________ amd64 5-Level Paging Structures support Links Patch=20 URL: https://reviews.freebsd.org/D25273 Intel SDM=20 URL: https://software.intel.com/content/www/us/en/develop/articles/inte= l-sdm.html Intel whitepaper=20 URL: https://software.intel.com/content/www/us/en/develop/download/5-le= vel-paging-and-5-level-ept-white-paper.html Contact: Konstantin Belousov Since its introduction, x86 Long Mode (AKA 64bit execution mode, amd64 in FreeBSD terminology) uses 4-level paging structures, which provides 48 bits of virtual address space (LA48). FreeBSD evenly divides the space between userspace and kernel, giving both 47 virtual address bits. In near future Intel CPUs will start providing 5-level paging structures, i.e. giving 57 bits for virtual addresses (LA57). This means, with preservation of the existing divide between KVA and UVA, 56 bit for UVA, or 2^9 =3D 512 times more virtual memory. The amd64 pmap was modified to support both LA48 and LA57, defaulting to LA57 if hardware supports it. The tunable is provided to force using LA48 even if hardware can do LA57. The most interesting part of the patch is the switch from boot paging mode to LA57. Loaders, either legacy or UEFI, pass control to the kernel in Long Mode, which implies that the paging is turned on. This neccessarily means that it is LA48 mode. SDM states that paging mode cannot be switched while Long Mode is active, so kernel has to create new page table structures, turn Long Mode off, then load new %cr3 and finally re-enable Long Mode. I decided to only provide the larger virtual address space to usermode for the initial step, leaving KVA layout intact. The main motivation is that changing KVA arrangements requires changing the auto-tuning settings, which deserve separate work. Another argument for it is that most of the kernel memory is non-swappable, so cannot be over-commited. We have 2:1 ratio of useful KVA to physical memory (due to direct map), and until machines get more physical address lines, increasing KVA is not useful. After this was decided, creating a 5-level paging structure for kernel pmap from existing 4-level one is quite straightforward; we need to add one page for top level, create one PML5 entry to point to existing PML4 page, and create the famous self-referential entry for vtopte()/vtopde(). Care was taken to provide binary compatible layout of UVA for binaries that cannot be executed correctly with larger address space. For instance, programs could have knowledge about used bits in the addresses and used upper bits for other data, or implemented compressed pointers. Even if system runs in LA57 mode, specific binary can request LA48-compatible UVA by procctl(2) or by the flag in the FreeBSD features ELF note. Since I do not have access to a machine with LA57, development was done using QEMU. It would be interesting to try it on the real hardware. Sponsor: The FreeBSD Foundation __________________________________________________________________ Not-transparent superpages Links Patch=20 URL: https://reviews.freebsd.org/D24652 Contact: Konstantin Belousov FreeBSD already provides excellent support for superpages, in a manner completely transparent to applications. It tries to proactively prevent fragmentation, reserves contigous runs of the physical pages for linear allocations in managed objects, and auto-promote runs of small pages when they form complete superpage. The shortcomings of this approach directly follows from its strength: some applications want to get guaranteed superpage mappings, typically because the underlying physical memory is also offloaded into a hardware which also has memory mapping unit. For instance, Infiniband RMDA adapters do memory registration and remapping, which is more efficient with large pages. In such cases transparent (non-guaranteed) support cannot be used. The extension was developed for POSIX shared memory subsystem to allow the creator request that the shared memory object was backed by physically contiguous pages, with runs of specified size. The mmap(2) syscall is aware of such objects, and if the requested mapping is properly aligned, it will be served by superpages. The new type of the shared memory objects are backed by modified a physical pager, which only allocates contigous physical memory. The VM ensures that mappings of the objects are never split (clipped) on a non-superpage boundary. The fault handler is specially optimized to be very fast by quickly installing the superpage PTE, and to avoid touching all small pages constituing it. Currently the required pmap support is provided for amd64 with 2M and 1G superpage sizes. Sponsor: The FreeBSD Foundation __________________________________________________________________ NXP ARM64 SoC support Contact: Marcin Wojtas Contact: Artur Rojek Contact: Dawid Gorecki The Semihalf team initiated working on FreeBSD support for the NXP LS1046A SoC LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with integrated packet processing acceleration and high speed peripherals including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide range of networking, storage, security and industrial applications. Completed since the last update: * Improve code in a couple of review cycles and merge following new features to the FreeBSD-HEAD (r361458 - r361464): + QorIQ platform clockgen driver + LS1046A clockgen driver + GPIO support for QorIQ boards + QorIQ LS10xx AHCI driver + VF610 I2C controller support + TCA6416 GPIO expander + Epson RX-8803 RTC Todo: * Upstreaming of the QorIQ SDHCI driver - it is expected to be submitted/merged to HEAD in the Q3 of 2020. Sponsor: Alstom Group __________________________________________________________________ amd64 pmap Fine-grained pv lists locking Links Patch=20 URL: https://reviews.freebsd.org/D24217 Contact: Konstantin Belousov FreeBSD kernel Virtual Memory subsystem handles 'normal' application memory, i.e. anonymous or file-backed shared and private mappings, with so called managed pages. Managed page is fully controlled by VM, which tracks it status. In particular, managed page can be made read-only for write-back to the file, or unmapped for reuse (paging). The machine-dependent VM layer, pmap, must support managed pages, for instance it must provide operations such as pmap_remove_write() to downgrade all mappings to read-only, or pmap_remove_all() to unmap the page from all address spaces. To implement this kind of operations, while not causing the overhead of scanning all page tables, pmap must track existing mappings of the page. The tracking is done by allocating a small data structure 'pv entry' per mapping, and linking all pv entries for the given page into pv list. Since pv entries come from context of different address spaces, pmap must provide synchronization to guarantee correctness of the list structures. Current pmap allocates one mutex per one 2M physical superpage in NUMA configurations, and MAXCPU =3D=3D 256 locks hashed by = the page physical address for non-NUMA. The end result is often undeserved lock aliasing causing pv list locks contention, since all 4k pages in the 2M superpage share the same lock, and reservations typically cause adjasted pages to come from the same superpage. The proposed patch creates a new kernel synchronization primitive called one byte mutex, which is embedded into the currently unused padding in machine-dependent portion of the struct vm_page. This way each page gets dedicated pv list lock without using any more memory. In the ever-important buildkernel benchmark on non-NUMA config, this change provides 2x reduction of the system time. One complication is that old locking distribution scheme made a natural fit for superpages promotion and demotion, since all embedded small pages shared the same pv list lock, and the operations basically fold/unfold corresponding pv entries. Now the promotion and demotion operations require taking all locks for constituent small pages, which provides small but measurable impact on them. It is possible to optimize it further by providing the 'superlock' on the first page from the superpage run, but the affected operations are relatively rare so that it is not even obvious that implementing the optimization would not slow down other pathes. Another important nuance of the pv entries handling is that sometimes pv entries allocator must not fail. Typically this is required when kernel makes a call to pmap_enter() which must establish new mapping, and for managed page this includes allocating the pv entry if existing cannot be reused. If allocator cannot get a fresh page from the vm_page_alloc(9), it opts to destroy some other managed mapping to either get a reusable pv entry from current pmap, or destroy enough managed mappings from some other pmap to free whole page. To do the reclamation, currently all pages from which with pv entries are allocated, are linked in the global pv chunk list, which is protected by global (per-NUMA domain) mutex. Any allocation or free of pv entry has to lock the mutex, which is apparently a contention point for large machines. Patch removes the global list of chunks, instead linking all pmaps in the global list like it is done on i386 (but for different reason). Now the global lock is only taken for pmap creation and free, which corresponds to fork/exec and exit of a process, and when pv allocator starts reclaiming from other pmaps (which is normally does not happen). Sponsor: The FreeBSD Foundation __________________________________________________________________ Lockless routing lookups and scalable multipath Links Implementation of scalable multipath=20 URL: https://reviews.freebsd.org/D24141#change-ZOjdMqgDgUr7 Contact: Alexander Chernikov The primary goal of this work is to bring scalable routing multipath implementation, enabled by default. Another goal is enabling high-performance routing lookups. Multipath will close long-standing feature gap that modern networking OS must have. Lockless routing lookups will remove lookup bottlenecks, improve both dataplane and control plane performance for the setups with large number of routes. Background The initial routing kpi was introduced back in 1980. It was a nice generic approach back then, as no one knew how the protocols would evolve. It has been enormously successful as it was able to survive for 20+ years. Unfortunately, this kpi does not try to protect subsystem internals from the outside users, resulting in tight coupling with other subsystems. As a result, making changes is hard, leading to compromises and piling technical debt. Implementation overview Most changes are based on introduction of the concept of nexthops. Nexthops are separate datastructures, containing all necessary information to perform packet forwarding such as gateway, interface and mtu. They are shared among the routes, providing more pre-computed cache-efficient data while requiring less memory. Interested reader can find more detailed description in D24141. Another overview can be found in Nexthop object talk describing Linux implementation. Multipath implementation extends nexthop concept further by introducing nexthop groups. Each route has a pointer to either nexthops or a nexthop group, decoupling lookup algorithm from the routing stack internals. Both nexthops and nexthop groups are immutable and use epoch(9)-backed reclamation. A pre-requisite for lockless routing lookup is the introduction of modular lookup framework, allowing to attach any longes-prefix-match algorithm implementation to any IPv4/IPv6 fib. Currently there are plans to use modified DIR-24-8 algorithm from DPDK for both IPv4 and IPv6 families as an example of base lockless implementation. Status * Nexthop objects [ DONE ] * Introduction of nexthop objects [ DONE ] * Conversion of old KPI users to the new one [ DONE ] * Conversion of route caching to nexthop caching [ DONE ] * Conversion of struct rtentry field access to nhop field access [ DONE ] * Eliminating old lookup KPI and hiding struct rtentry [ DONE ] Multipath [ IN PROGRESS ] * Switch control plane consumers to use (rtentry, nhop) pairs instead of rtentry to allow multipath changes happen transparently [ 90% DONE ] * Introduce nexthop group objects * Add mutipath support for the rib (routing information base) manipulation functions * Add flowid generation for outbound traffic to enable load balancing Modular longest-prefix-match lookup algorithm [ IN PROGRESS ] * Design control plane framework for attaching algorithms [ 90% DONE ] * Port IPv6 lockless lookup algorithm [ DONE ] * Port IPv4 lockless lookup algorithm __________________________________________________________________ ZSTD Compression in ZFS Contact: Allan Jude Zstandard (ZSTD) is a modern high-performance compression algorithm designed to provide the compression ratios of gzip while offering much better performance. ZSTD has been adopted in FreeBSD for a number of other uses, including compressing kernel crash dumps, as a replacement for gzip or bzip for compressing log files, and for future versions of pkg(8). This effort to complete the integration of ZSTD into ZFS is sponsored by the FreeBSD Foundation. Integrating ZSTD into ZFS will further extend the transparent compression feature of ZFS by offering higher compression ratios without the performance penalty associated with gzip. ZSTD offers compression levels ranging from 1 (low compression) to 22 (maximum compression), plus ZSTD-Fast levels that offer less compression but even greater speed. This will allow the storage administrator to select the performance-vs-compression tradeoff that best suits their needs. Tasks remaining to be completed: * Extend ZFS to support compression algorithms with large numbers of levels * Solve issues around the inheritence of compression settings * Restore compression level when reading blocks from disk * Create a future-proofing scheme to handle changing versions of ZSTD * Extend ZFS replication to handle backwards compatibility with pools that do not yet support ZSTD * Resolve issues around backwards compatibility when ZSTD is configured but not used Sponsor: The FreeBSD Foundation __________________________________________________________________ CheriBSD 2020 Q2 Links CHERI-CPU =20 URL: http://www.cheri-cpu.org DARPA FETT Bug Bounty Program=20 URL: https://fett.darpa.mil Contact: Alex Richardson Contact: Andrew Turner Contact: Brooks Davis Contact: Edward Tomasz Napierala Contact: Jessica Clarke Contact: John Baldwin Contact: Robert Watson Contact: Ruslan Bukin CheriBSD extends FreeBSD to implement memory protection and software compartmentalization features supported by the CHERI instruction set extensions. Support for CHERI-RISC-V in CheriBSD has continued to mature this quarter in tandem with refinements to the CHERI-RISC-V architecture. We have recently made CheriBSD's "pure capability" (CheriABI) process environment the default ABI rather than a compatibility layer. It has grown support for: * dynamically linked binaries (previously only statically-linked binaries were supported) * C++ including exceptions * sealed return address and function pointer capabilities ("sentries") which provide additional CFI protection * initial MMU protections for loading and storing tags At this point, CHERI-RISC-V support in CheriBSD is generally on par with support for CHERI-MIPS. Much of this effort has been focused on preparing CheriBSD on CHERI-RISC-V for inclusion as a demonstrator system in DARPA's Finding Exploits to Thwart Tampering (FETT Bug Bounty program). In addition, work has begun this quarter on porting CheriBSD to Arm's Morello SoC. Morello is a prototype demonstrator board which adds CHERI extensions to ARMv8-A. We've recently switched to a dev-branch model where active work takes place on the dev branch and we periodically merge to master with synchronization between CheriBSD and dependencies like CHERI-LLVM. For those interested in what it's like to program for CHERI, we've recently released a CHERI C/C++ Programming Guide. __________________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. Continuous Integration on !x86 Contact: Edward Tomasz Napierala For quite a while the FreeBSD CI infrastructure has been running FreeBSD builds and regression tests, making it easy to spot regressions. While CI was building images for all architectures, the regression tests were only run on amd64 and i386, which means they couldn't detect architecture-specific runtime breakage on non-x86 architectures. This poses a problem not only for FreeBSD itself, but also for people working on FreeBSD forks for !x86, such as the CHERI project at University of Cambridge and SRI International. The goal of this project is to run regression tests on the remaining architectures supported by FreeBSD: ARM, ARM64, MIPS, POWER, and RISC-V. The tests are being run using common, mostly machine-independent scripts. Those required some changes to make it possible to use QEMU in addition to Bhyve, the hypervisor used for x86 tests. The sysutils/u-boot-qemu-arm and sysutils/u-boot-qemu-arm64 ports were added to the Ports Collection. Finally, each of the architectures required some tweaks, to account for different configuration requirements - for example the MIPS kernel doesn't support VirtIO disks, or even AHCI, whereas on ARM64 the U-Boot gets confused with more than one VirtIO disk. On ARM, we're currently at 52 failures and 590 skipped tests, of 5925 tests ran (https://ci.freebsd.org/job/FreeBSD-head-armv7-test/lastCompletedBuild/t= estReport/). On ARM64 it's 19 failures and 160 skipped (https://ci.freebsd.org/job/FreeBSD-head-aarch64-test/lastCompletedBuild= /testReport/). On MIPS it's 172 failures and 734 skipped (https://ci.freebsd.org/job/FreeBSD-head-mips64-test/lastCompletedBuild/= testReport/). For POWER, and RISC-V the results are not available yet. Remaining work: * Failing regression tests need to be fixed. * The tests are quite slow on QEMU, for example the ARM64 run takes about five hours. Running them automatically after each commit would quickly overload the CI cluster. A solution would be to e.g. run them daily. * Some of the jobs still fail to produce results: powerpc64 deadlocks at the end of regression test suite due to an unkillable process, riscv64 panics randomly, and on mips64 kyua(1) often crashes on jemalloc assertion. Those might be fixed by an upcoming QEMU port update. Sponsor: DARPA __________________________________________________________________ FreeBSD/RISC-V Project Links Wiki=20 URL: https://wiki.freebsd.org/riscv Contact: Mitchell Horne Contact: freebsd-riscv Mailing List Contact: IRC #freebsd-riscv channel on freenode The FreeBSD/RISC-V project is providing support for running FreeBSD on the RISC-V Instruction Set Architecture. Since RISC-V is still a young and evolving platform, one of our goals is to have FreeBSD be a well-supported option for users as RISC-V hardware increases in availability. This quarter saw a number of improvements to the boot process. The physmem interface used by arm and arm64 to enumerate physical memory resources was moved to machine-independent code and adopted on RISC-V. As a result, the kernel is now able to detect and exclude physical memory reserved by devices or firmware. A bug that prevented the kernel from using physical memory below its load address was fixed. This typically did not manifest in much waste, as the kernel is loaded 2MB after the start of physical memory by default. In future boot configurations, the impact would have been much larger. Our port for OpenSBI was updated to v0.8, bringing several new features and fixes. In particular, it brought the Hardware State Management (HSM) extension, which can be used to start and stop CPUs. FreeBSD will now use this extension whenever it detects that it is available. There has also been a lot of work done to port FreeBSD's standard bootloader, loader(8), to RISC-V. This has big advantages in terms of boot flexibility, and brings us closer to what's needed to produce official FreeBSD/RISC-V release images. By leveraging UEFI support from u-boot, loader.efi can be used in a manner similar to arm and arm64. Next quarter will likely bring u-boot ports for RISC-V targets, pending the v2020.07 release. Booting the kernel directly via SBI firmware will continue to be supported. __________________________________________________________________ Userland Programs Changes affecting the base system and programs in it. Import of new implementation of bc and dc Links Official repository =20 URL: https://git.yzena.com/gavin/bc Repository mirror on GitHub=20 URL: https://github.com/gavinhoward/bc/ Contact: Stefan Esser Contact: Gavin D. Howard A new version of bc and dc has been imported into FreeBSD-CURRENT and enabled by default. An import into 12-STABLE is planned before the end of July, but it will not be enabled by default (will require "WITH_GH_BC=3Dyes" to be set in /etc/src.conf). This version has been developed by Gavin D. Howard with the goal to provide a highly portable and POSIX compatible implementation. It offers GNU bc compatibility and should be a drop-in replacement for the bc in FreeBSD, except for standard-violating behavior of the bc currently in FreeBSD (e.g., the modulo operator). Additional features: * High performance (up to more than a factor of 100 faster than the current FreeBSD implementation in some tests) * support of message catalogs with a large number of languages supported in the current release (contributions of further translations are welcome). * Extra built-in functions and operators. * Extended library of advanced math functions * Detailed man-page explaining standard conformant and extended features * One shared binary for bc and dc (bc is not just a pre-processor that relies on dc for the actual computations) The only dc feature not supported by the dc is the execution of sub-processes, since the author considers it a security hazard for a calculator to have. This code is also available as a port and package (math/gh-bc or gh-bc), e.g. for use with a FreeBSD binary release. __________________________________________________________________ Binutils Retirement Links GPL in Base wiki page=20 URL: https://wiki.freebsd.org/GPLinBase Contact: Ed Maste We have been working on migrating to a modern and copyfree or permissively licensed toolchain for quite some time. In the last quarter we retired two obsolete GNU bintuils: objdump, and as. Many uses of objdump can be replaced with readelf, and llvm-objdump is also available in the base system. Ports that depend on objdump have been updated to rely on the GNU binutils port or package. The GNU as utility was used by both the base system and by ports. As with objdump, ports that require GNU as have generally been updated to depend on binutils. One file in the base system (skein_block_asm.s) proved troublesome during earlier attempts to migrate to using Clang's integrated assembler (IAS). However, after the update to Clang 10 (and with some trivial modifications to the source) IAS can assemble the file. Both GNU as and objdump have been removed from FreeBSD-CURRENT and will be absent from FreeBSD 13.0. TODO The final task in the binutils retirement project is to remove GNU GDB 6.1. It is currently retained for crashinfo(8). Sponsor: The FreeBSD Foundation __________________________________________________________________ Run-Time Dynamic Linker improvements Contact: Konstantin Belousov Rtld gets some number of small bug fixes and improvements. RTLD_DEEPBIND dlopen(3) flag was implemented, despite being a strange and even unsafe idea, for compatibility with glibc. Several improvements to the direct execution mode were made. Most interesting are perhaps the '-v' switch to report some configuration parameters for rtld, the ability to specify argv0 different from the executed binary name, and fixes to properly set osrel/ABI for the directly executed binary. The link_map structure that is used by tools that need to know the list of loaded shared objects (like gdb and wine) was made more compatible with glibc, while keeping existing FreeBSD ABI intact. In the course of the link_map work, it become apparent that rtld sometimes needs to report presence of features that cannot be deduced by just a runtime test for symbol presence or for function behavior. For that, a scheme of reporting features with uniformingly named symbols was designed - see the rtld(1) man-page (in CURRENT) for an explanation. Position-independent (PIE) binaries on FreeBSD are now marked with the DF_1_PIE DT_FLAG1 flag. Otherwise, such binaries are just ET_DYN objects and it is quite hard to distinguish proper dynamically shared object (DSO) from PIE binary. The problem is that for binaries, the static linker strips some information which is required for proper loading as a DSO, and additonally, binaries contains relocations like copy-relocations that cannot be handled for non-main binaries at all. With the flag addition, rtld properly detects binaries and refuses to load them with dlopen() or as DT_NEEDED dependency. ldd(1) also misdetected PIE vs. DSO, and required a fix to parse dynamic segments to not try to dlopen() them. Sponsor: The FreeBSD Foundation __________________________________________________________________ VHDX support in mkimg(1) Contact: Oleksandr Tymoshenko VHDX is the successor of Microsoft's VHD virtual drive file format. It increases maximum capacity of the virtual drive to 64TB and introduces features to better handle power/system failures. VHDX is the required format for 2nd generation Hyper-V VMs. __________________________________________________________________ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. Bastille Links Bastille GitHub =20 URL: https://github.com/bastillebsd/bastille Bastille Templates=20 URL: https://gitlab.com/bastillebsd-templates Bastille Website =20 URL: https://bastillebsd.org Contact: Christer Edwards Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD. Bastille Templates automate container setup allowing you to easily reproduce containers as needed. Bastille is available in ports at sysutils/bastille. Q2 2020 Status In Q2 2020 Bastille merged some exciting new features into GitHub. Changes include: * experimental support for new Bastillefile template syntax * added mount and umount sub-commands * added a default Vagrantfile for simple testing * experimental support for empty containers * improvements to VNET DHCP support * cosmetic bugfixes in error output * extended config file documentation * updated bastille help output * option to (-f) force destroy container sysutils/bastille was updated to 0.6.20200414 (latest). New Bastille templates added this quarter include: * Percona database server * Asterisk SIP server * dnsmasq DNS/DHCP server (VNET required) * nginx pkg server for poudriere Everything mentioned here was done under COVID-19 quarantine. Special thanks to everyone that contributed during this time. __________________________________________________________________ KDE on FreeBSD Links KDE FreeBSD =20 URL: https://freebsd.kde.org/ KDE Community FreeBSD=20 URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages the software produced by the KDE Community for FreeBSD. The software includes a full desktop environment KDE Plasma, IDE KDevelop, a PIM suite Kontact and hundreds of other applications that can be used on any FreeBSD desktop machine. This quarter has been an ever-so-peculiar one. While we are used to working remotely, collaborating over the internet to update the ports tree, it's qualitatively different when the whole world locks down. Meanwhile, software continues to be released, so this quarter the kde@ team: * Restored a patch that closes down a remote TCP held by X11 applications that use the ICE library. Thanks to Colin Percival for reporting it. It went missing in one of the port updates. To prevent this in the future, the patch has been upstreamed. PR 229772. * Chased KDE-adjacent software like CMake, Cutelyst, Latte-dock and Nheko through new releases. In particular CMake takes a lot of effort every time because it is a build-time dependency of over 2000 ports. * graphics/poppler was updated to the latest upstream release. This is a low-level dependency for many document-viewing applications, and like CMake requires chasing a lot of other software. Poppler is one of the components shared between various software stacks (and "desktop environments") under the desktop@ group, in which kde@ participates. * KDE Frameworks release like clockwork, reaching KDE Frameworks 5.70 mid-may. * KDE Applications -- the KDE release service, really, which delivers libraries, applications, and add-ons -- had one large release, with 20.04.1 landing in the ports tree also mid-may and its monthly update 20.04.2 in mid-june. * Some new Wayland support for KDE Plasma -- we have not tested this on FreeBSD -- has appeared and has been duly packaged. * A great deal of preparation has gone into Qt 5.15. Many ports have been pre-emptively patched for this new -- and last -- LTS release of Qt 5. The update itself has not yet landed, pending a few last bits of fallout. The kde@ team would like to thank Antoine for many exp-runs, mikael@ for useful tips, swills@ for patience and kai@ for dealing with WebEngine. The next big round of updates for the KDE stack is slated: CMake 3.18, Qt 5.15 LTS, and KDE Frameworks 5.71. __________________________________________________________________ Haskell on FreeBSD Links Haskell language homepage=20 URL: http://www.haskell.org/ Ports development repo =20 URL: https://github.com/freebsd/freebsd-ports-haskell Contact: Gleb Popov Haskell is a general-purpose strictly-typed pure functional language. The Haskell on FreeBSD projects strives to provide the up-to-date Haskell toolchain as well as various application written in this language. This quarter brought the long-awaited GHC update, which is now at version 8.8.3. Along the compiler, the Haskell build system frontend, cabal-install, was also upgraded to 3.0.2.0. During this update, numerous Haskell ports were updated too. All existing ports of Haskell applications were migrated to USES=3Dcabal, which implements Go-style build proccess - all dependencies are compiled as part of the build. As a consequence, ports for Haskell libraries have been deprecated and removed. Upgrading GHC became a tedious task for a single person, so a new GitHub repository was created under the FreeBSD organization - freebsd-ports-haskell. Right now, work is being done on preparing another GHC upgrade in the ghc-upgrade-810 branch. Any contributions are welcome. __________________________________________________________________ rtsx - Porting driver for Realtek SD card reader from OpenBSD Links rtsx =20 URL: https://github.com/hlh-restart/rtsx PR204521=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204521 Contact: Henri Hennebert The rtsx driver for Realtek SD card reader has been ported from OpenBSD. Its development snapshot is available via the sysutils/rtsx-kmod port. From March to May 2020, the code has been completed with the help of Gary Jennejohn (gj@) and Jesper Schmitz Mouridsen (jsm@). Some tweaks have been imported from the Linux counterpart. The driver has been successfully tested with: * RTS5209 under head (Lenovo ThinkPad L520) * RTS5227 under stable/11 and releng/12.1 (HP ProBook 430 g2, Lenovo ThinkPad T450/T450s) * RTS5229 under releng/12.1 (Lenovo IdeaPad 120S-14IAP) * RTS522A under releng/12.1 and head (Intel NUC8i5BE, Lenovo ThinkPad P50s) * RTS525A under releng/12.1 (Dell Latitude E5570) * RTL8411B under stable/12 (Acer Aspire E 15 E5-576-77W6) The driver should also work for Realtek RTS5249, RTL8402 and RTL8411. More tests are welcome, especially for the devices not yet tested. These devices may require more tweaks. PR204521 contains the bulk of exchanges for completion of the code. __________________________________________________________________ Valgrind updates Links Patch for valgrind=20 URL: https://reviews.freebsd.org/D25452 Contact: Paul Floyd Contact: Kyle Evans A large amount of work has been done to rebase FreeBSD support on top of Valgrind 3.17.0, and to address numerous test suite failures. Currently, almost all of the regression tests pass on amd64. This is a major improvement over the current state of affairs, in which the Valgrind is quite out of date and is missing important functionality. Some follow-up work aims to make FreeBSD an officially supported target platform for Valgrind. The devel/valgrind-devel port is in the process of being updated to point at the new work. __________________________________________________________________ Documentation Noteworthy changes in the documentation tree, in manpages, or in external books/documents. FreeBSD Translations on Weblate Links Translate FreeBSD on Weblate wiki=20 URL: https://wiki.freebsd.org/DocTranslationOnWeblate FreeBSD Weblate Instance=20 URL: https://translate-dev.freebsd.org/ Contact: Danilo G. Baio Contact: Edson Brandi This quarter was improved the renderization of RTL (Right-to-left) languages on the FreeBSD Documentation. We faced this issue after the first RTL language joined the translations effort (fa_IR). We are looking forward to receive more languages and translators to the project as well. Q2 2020 Status * 10 languages (No new languages) * 80 registered users (33 new users since last quarter) Languages * Chinese (Simplified) (zh_CN) * Chinese (Traditional) (zh_TW) * French (fr_FR) * German (de_DE) * Italian (it_IT) * Norwegian (nb_NO) * Persian (fa_IR) * Portuguese (pt_BR) * Spanish (es_ES) * Turkish (tr-TR) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. __________________________________________________________________ Miscellaneous Objects that defy categorization. FreshPorts Links FreshPorts =20 URL: http://freshports.org/ FreshPorts blog=20 URL: http://news.freshports.org/ Contact: Dan Langille FreshPorts, and its sister site, FreshSource, have reported upon FreeBSD commits for 20 years. They cover all commits, not just ports. FreshPorts tracks the commits and extracts data from the port Makefiles to create a database of information useful to both port developers and port users. For example, https://www.freshports.org/security/acme.sh/ shows the history of this port, back to its creation in May 2017. git Work on git started back in September. It was ignored for a while and started back in mid-June with the creation of new git-specific jails for commit ingress (commit processing gitdev) and for the website. Serhii (Sergey) Kozlov created a script to transform GIT commit entries into XML digestible by FreshPorts. This was a huge step foward for the effort. The next step include: * incorporate a that script the automated processes of FreshPorts * migrate to new test & stage versions of FreshPorts * test * get ready for prod Help wanted git is not far away now. I could use helpers to * review code * watch the commits on the devgit websites * catch missing stuff Thank you Packages FreshPorts now displays the packages version available from the repo sources. This covers all primary tiers (e.g. FreeBSD:12:amd64) and all secondary tiers (e.g. FreeBSD:13:powerpc64). This helps uses know what versions they can expect and when then repo was last built. Dependency lines Some things are easiest done via copy/paste. If you are working on a port Makefile and need to add a new dependency, FreshPorts shows the dependency line for that port. For example: acme.sh>0:security/acme.sh Libraries are also covered by this feature. Python ports were recently adjusted to display ${PYTHON_PKGNAMEPREFIX}virtualenv>0:devel/py-virtualenv instead of py37-virtualenv>0:devel/py-virtualenv You can read more about this change in [issue #73](https://github.com/FreshPorts/freshports/issues/73). Watch ports I maintain The search page has long had the "Ports I Maintain" button (if you are logged in). This feature recently branched out to a new automated watch list option: Watch ports I maintain. This report subscription will notify you of any commits to the ports you maintain. Your email address on FreshPorts must match the value in the MAINTAINER field of the port. This is always a daily report. From time to time, an infrastructure change will occur which touches your port. This feature ensures you know about that change. Repology links Repology links were requested. This allows you to see what versions of that port are in the repositories of other systems. A link to repology.org appears on every port page. Further reading Based upon things you didn't know FreshPorts can do There are many things FreshPorts can do, including search Makefile's and pkg-plist. This is from a recent blog post: * provides example dependency line. e.g. p5-XML-RSS>0:textproc/p5-XML-RSS * list of dependencies for a port * list of ports depending upon this port * see default configuration options * what packages install a given file (e.g. bin/unzip) * find out what ports a person maintains * find Makefiles which contain references to bunzip * search results can be plain-text consisting of a list of foo/bar ports * the Maximum Effort checkbox on the search page does nothing * committers can be notified of sanity test failures after the commit * find a commit, any commit, based on SVN revision number, e.g. : https://www.freshports.org/commit.php?revision=3D352332 Javascript help wanted We recently upgraded some outdated Javascript modules. This broke our [JavaScript based graphs](https://www.freshports.org/graphs2.php). We could use some help on fixing that please. The starting points are listed on that URL. If you need a working website to play with, please contact me with a ssh public-key. Sponsor: hardware provided by iXsystems __________________________________________________________________ PCI passthrough with bhyve on Intel and for OpenBSD guests Links bhyve Intel bug report=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229852 bhyve OpenBSD bug report=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245392 PCI passthrough with bhyve (FreeBSD wiki article)=20 URL: https://wiki.freebsd.org/bhyve/pci_passthru Contact: Anatoli Contact: Callum Contact: Peter Grehan bhyve(8) is a hypervisor that supports running a variety of guest operating systems in virtual machines. bhyve(8) includes support for PCI devices passthru, a technique to pass host PCI devices to a virtual machine for its exclusive control and use. For some years, PCI passthrough (ppt) in bhyve was not working on some Intel systems and for OpenBSD guests due to two bugs. The first one was crashing FreeBSD host when bhyve was started with ppt on Intel processors with two VT-d translation units (IOMMU), included in most Skylake and newer Intel processors. The second bug was preventing correct interrupts handling for OpenBSD guests. As a result, OpenBSD guests running on bhyve were not able to use any PCI devices passed through to them from the host. During the last 2 months the second bug was identified and fixed and they both were backported to 12.1-RELEASE (p7). So now it's possible to fully take advantage of PCI passthrough (ppt) with bhyve in a production-ready RELEASE version. The most typical case for ppt is to pass to the guest network adapters for its complete control, but you can also pass through USB devices (including external HDDs). Note though, passthrough of VGA and GPU devices is not supported yet (for more details see the 3rd link). A particularly interesting case for ppt is to use OpenBSD guest as a firewall and a router for a FreeBSD server. With ppt you can achieve this all inside a single server. You could pass to the OpenBSD guest a network adapter connected to the internet and it would take a complete control of it. After filtering the traffic, it could pass good packets via virtual network interfaces to other guests or to the host. Once a network adapter is passed through, a FreeBSD host not only doesn't see it and hence doesn't handle the network traffic, it doesn't even have to initialize the adapter (e.g. in case of a WiFi card, it's the guest that loads the firmware). In simple terms the host only passes the device interrupts to the guest as they come from the hardware. Everything related to the device management happens inside the guest so there's no danger that some network traffic exploits some issue in the host's network stack and causes the host to crash or misbehave in other ways. __________________________________________________________________ SageMath Links SageMath site=20 URL: https://www.sagemath.org/ Contact: Thierry Thomas SageMath is a free open-source mathematics software system licensed under the GPL. It builds on top of many existing open-source packages: NumPy, SciPy, matplotlib, Sympy, Maxima, GAP, FLINT, R and many more. Thanks to SageMath it is possible to access their combined power through a common, Python-based language or directly via interfaces or wrappers. The goal is creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab. This is a complex port, with a lot of dependencies, and it has been broken for some time. Upstream is working on easing its packaging, and many previously bundled applications can now be replaced by external packages. If you are interested, it would be nice to create a team of maintainers * to maintain some of the dependencies; * to maintain SageMath itself and prepare the next release (9.2 is coming!). __________________________________________________________________ Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. chaifi - a tool to simplify joining public WiFi networks Links chaifi=20 URL: https://github.com/gonzoua/chaifi Contact: Oleksandr Tymoshenko chaifi is a TUI (text UI) utility aimed at simplifying the process of joining public WiFi networks in places like coffee shops or libraries. It replaces the process of scanning and manually editing wpa_supplicant.conf with an interactive dialog. The utility is in no way a replacement for full-featured network managers in major desktop environments. Still, if you're working from a console or using a tiling window manager, it may save you some seconds (or in worst case minutes) of your time. __________________________________________________________________ MixerTUI Links mixertui=20 URL: https://gitlab.com/alfix/mixertui Contact: Alfonso Sabato Siciliano MixerTUI is a volume mixer with a Terminal User Interface built on the FreeBSD sound system. It can show the current Sound Driver configuration and select an audio device: to get its information, to change the volume or to set it as default, the last feature allows to switch easily audio from/to laptop and hdmi, headphones and speakers, and so on. MixerTUI can be installed via the audio/mixertui port. I would like to thank the FreeBSD community for the tips, feedbacks and patches to improve this project. __________________________________________________________________ Potluck - Flavour & Image Repository for pot Links Potluck Repository & Project=20 URL: https://potluck.honeyguide.net/ Potluck on github =20 URL: https://github.com/hny-gd/potluck pot project =20 URL: https://pot.pizzamig.dev Contact: Stephan Lichtenauer pot is a jail management tool that also supports orchestration through nomad. Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: A repository of pot flavours and complete images for usage with pot. This should simplify setting up complex software with many packages and ports in comparison to manual configuration: Potluck aims to provide a content library as an additional layer of abstraction, on top of existing infrastructure like pkg, that pot has to offer. Pot "flavour" files are provided on [Github]((https://github.com/hny-gd/potluck)) and fed into a Jenkins instance. On the Potluck Repository, for each flavour, detailed descriptions as well as ready-made images to be imported by pot are provided. The initial project has been set up, and three simple flavours, along with a complete Jitsi Meet instance in a jail has been created as a Proof of Concept that should allow running a fully-fledged video conference system with just a few easy commands within a few minutes. As only the initial versions have been set up and implemented so far, general feedback, tests, as well as additional, useful flavours are very welcome! __________________________________________________________________ News Home | Status Home Site Map | Legal Notices | =A9 1995-2020 The FreeBSD Project. All rights reserved. --6ppadjxpmznoj5nk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl8PilZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87oulwf9GBShg8eDSai7oluVI+NTjlhwsdKo50KJ5w6+sk1jfkaqJ6Z8ksVRC/Dh l+lWGrccd2jqh1kX0fux/Ex9nbWugxKm7yDoLg1a+uWyRYhdsfU2DgnCDhwfXZ6x Lav5MnrRFl/SzGP6ZCgKqf8GjdrIezjBJ/6o6FgUi1D48YhODRLKwmtH7HlBICup 4zuuNK+nHNN7TEb4nK2iD2ucUIZ6vwOlrc8QlO5003pluyx+aVf/U8trHSarRaru YapajM6IBlkmovLGZoJ1NPpv/Fdt6PeAUiwGJxb6kY0g9O93hOjzruS18FWBV2XE rsZ7B6vAA5f0qzeMEWZBKVeXBNLavw== =LuZE -----END PGP SIGNATURE----- --6ppadjxpmznoj5nk-- From owner-freebsd-stable@freebsd.org Thu Jul 16 10:18:46 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8503D35CD48 for ; Thu, 16 Jul 2020 10:18:46 +0000 (UTC) (envelope-from dev@null.cz) Received: from dev.null.cz (dev.null.cz [IPv6:2a01:430:34:0:2:0:dead:babe]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "dev.null.cz", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6qwP0kRYz4L7F for ; Thu, 16 Jul 2020 10:18:44 +0000 (UTC) (envelope-from dev@null.cz) Received: by dev.null.cz (Postfix, from userid 1001) id D31A8771D0; Thu, 16 Jul 2020 12:18:35 +0200 (CEST) Date: Thu, 16 Jul 2020 12:18:35 +0200 From: Marek 'Buki' =?utf-8?Q?Kozlovsk=C3=BD?= To: freebsd-stable@freebsd.org Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2020 Message-ID: <20200716101835.GF7344@dev.null.cz> References: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> <7025a36e-52bf-ca18-185f-3c9adebdf26b@yuripv.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7025a36e-52bf-ca18-185f-3c9adebdf26b@yuripv.dev> X-Rspamd-Queue-Id: 4B6qwP0kRYz4L7F X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of dev@null.cz has no SPF policy when checking 2a01:430:34:0:2:0:dead:babe) smtp.mailfrom=dev@null.cz X-Spamd-Result: default: False [3.10 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.04)[0.037]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[null.cz]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.95)[0.946]; NEURAL_SPAM_LONG(0.92)[0.920]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[freebsd@dev.null.cz,dev@null.cz]; RCVD_COUNT_ZERO(0.00)[0]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24971, ipnet:2a01:430::/32, country:CZ]; FROM_NEQ_ENVFROM(0.00)[freebsd@dev.null.cz,dev@null.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 10:18:46 -0000 On Thu, Jul 16, 2020 at 01:29:09AM +0300, Yuri Pankov wrote: > Daniel Ebdrup Jensen wrote: > [nothing] > > At least in Thunderbird the text is not inline, and rather shows as > attachment. Actually, it shows inline in 68.10.0_CS(32-bit) and text attachment in 68.10.0_EN(64-bit). So take your pick whether it's the arch or locale difference MK From owner-freebsd-stable@freebsd.org Thu Jul 16 17:01:24 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 95651367E45 for ; Thu, 16 Jul 2020 17:01:24 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) (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 4B70rz1Kg7z3YB3 for ; Thu, 16 Jul 2020 17:01:22 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id 1D4584F2; Thu, 16 Jul 2020 13:01:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 16 Jul 2020 13:01:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.dev; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=M M454KJ/n6OkWTHPHpy4n7+Tagl8Tl1IuMh6G9pqTSw=; b=S5a70FB/O1ec3WMvt 4bDOawugcCwzyMgCEivntEZFHMOfYnUiWnHP+3ykOM6smaw8xAn07hbNORcYN8EH LcJlXkbmkPLleoNfZKh/TuxNOYuYRqp0HrRKRPQAoCoaIKrm/wwDK39gZmQpKdMX U5oQVB3oHmeiz3lOziQMl3Gntj7jqlCwChDZwRHyGMYpoFPPEF6sqHXQplKLq/9k z79Z5zsEpRrvwf6MN5p8XezWcvbA8v6fCvsEo+Pywtn7K9mqJGj8WsEgIVCGKcMa HOCf/wtcUnILDRVqIDbWLT97IjIMeeGeJclsSo1/RYstqv/gDSmshcXLOkQQ2NQe +s18Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=MM454KJ/n6OkWTHPHpy4n7+Tagl8Tl1IuMh6G9pqT Sw=; b=lOPglJCaOVKBX5+eUNL1LgRuRLKZ6H7lER/XIyZ4X8xtUl3lGclIIWVl0 k5ekbU69gXqYwh847HTVY+JZSxVQu+H2pP/1oMliQpaDPl6m6tIPIERJjYjDO3Yb RTx/K9Egy+Pxy/SwBz5AqDGOVJd1igx8BSWPcPQeNALQgWJAq8jRWjZd5PoetaDP 8Cr5zjBtrKI/vVSqXob6qFQuD6h976EE1dHoKULgp/+ntVoBSgSaUTRa1TU2O4pr iT7N/Z1sv0Ft6x7/lVEsRoNH1G0MefybZIImOhAdBzUlZUSEjk12VSfFBXoRxIJM T8UfH5i6ECN4pbVR/1sDOiY2Z+kKQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfeeggddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpegjuhhrihcurfgrnhhkohhvuceohihurhhiphhvseihuhhr ihhpvhdruggvvheqnecuggftrfgrthhtvghrnhepudeuffegtdehffdtffefkefhgfelie eitefghfeugeelfeduffegtdeufeekgfdvnecukfhppeeluddrvdegtddruddvgedrudef jeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeihuh hrihhpvheshihurhhiphhvrdguvghv X-ME-Proxy: Received: from [192.168.1.6] (unknown [91.240.124.137]) by mail.messagingengine.com (Postfix) with ESMTPA id 6AE7230600A6; Thu, 16 Jul 2020 13:01:19 -0400 (EDT) Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2020 To: =?UTF-8?Q?Marek_=27Buki=27_Kozlovsk=c3=bd?= , freebsd-stable@freebsd.org References: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> <7025a36e-52bf-ca18-185f-3c9adebdf26b@yuripv.dev> <20200716101835.GF7344@dev.null.cz> From: Yuri Pankov Message-ID: <475c45ee-6ca4-5cd1-a8d9-fd7beedb8da7@yuripv.dev> Date: Thu, 16 Jul 2020 20:01:17 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200716101835.GF7344@dev.null.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4B70rz1Kg7z3YB3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yuripv.dev header.s=fm1 header.b=S5a70FB/; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=lOPglJCa; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuripv@yuripv.dev designates 64.147.123.17 as permitted sender) smtp.mailfrom=yuripv@yuripv.dev X-Spamd-Result: default: False [-3.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yuripv.dev:s=fm1,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.01)[-1.012]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.17]; NEURAL_HAM_LONG(-1.00)[-1.003]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[yuripv.dev]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yuripv.dev:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.88)[-0.878]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.17:from] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 17:01:24 -0000 Marek 'Buki' Kozlovský wrote: > On Thu, Jul 16, 2020 at 01:29:09AM +0300, Yuri Pankov wrote: >> Daniel Ebdrup Jensen wrote: >> [nothing] >> >> At least in Thunderbird the text is not inline, and rather shows as >> attachment. > > Actually, it shows inline in 68.10.0_CS(32-bit) and text attachment in > 68.10.0_EN(64-bit). So take your pick whether it's the arch or locale difference There were 2 versions sent, which one are you talking about? attachment: Message-ID: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> inline: Message-ID: <20200715225934.jfasvsa3g36ssxwx@nerd-thinkpad.local> From owner-freebsd-stable@freebsd.org Thu Jul 16 19:00:43 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E993336AE84 for ; Thu, 16 Jul 2020 19:00:43 +0000 (UTC) (envelope-from freebsd@dev.null.cz) Received: from dev.null.cz (dev.null.cz [80.79.26.115]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "dev.null.cz", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B73Vf07Ksz3gJD for ; Thu, 16 Jul 2020 19:00:41 +0000 (UTC) (envelope-from freebsd@dev.null.cz) Received: from [194.108.1.47] (sal9000.vdi.cz.net [194.108.1.47]) by dev.null.cz (Postfix) with ESMTPSA id 1B16476F3A; Thu, 16 Jul 2020 21:00:38 +0200 (CEST) Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2020 To: Yuri Pankov , freebsd-stable@freebsd.org References: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> <7025a36e-52bf-ca18-185f-3c9adebdf26b@yuripv.dev> <20200716101835.GF7344@dev.null.cz> <475c45ee-6ca4-5cd1-a8d9-fd7beedb8da7@yuripv.dev> From: =?UTF-8?Q?Marek_=27Buki=27_Kozlovsk=c3=bd?= Message-ID: <44f1f2da-4344-930a-4df1-a02d85313fe1@null.cz> Date: Thu, 16 Jul 2020 21:00:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <475c45ee-6ca4-5cd1-a8d9-fd7beedb8da7@yuripv.dev> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4B73Vf07Ksz3gJD X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@dev.null.cz has no SPF policy when checking 80.79.26.115) smtp.mailfrom=freebsd@dev.null.cz X-Spamd-Result: default: False [1.72 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.17)[-0.167]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.35)[0.345]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[null.cz]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.64)[0.641]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24971, ipnet:80.79.16.0/20, country:CZ]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 19:00:44 -0000 Oh, my bad. Mixed up the one in -announce with the one in -stable :( Sorry for the confusion. MK On 16. 7. 2020 19:01, Yuri Pankov wrote: > Marek 'Buki' Kozlovský wrote: >> On Thu, Jul 16, 2020 at 01:29:09AM +0300, Yuri Pankov wrote: >>> Daniel Ebdrup Jensen wrote: >>> [nothing] >>> >>> At least in Thunderbird the text is not inline, and rather shows as >>> attachment. >> >> Actually, it shows inline in 68.10.0_CS(32-bit) and text attachment in >> 68.10.0_EN(64-bit). So take your pick whether it's the arch or locale >> difference > > There were 2 versions sent, which one are you talking about? > > attachment: > Message-ID: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> > > inline: > Message-ID: <20200715225934.jfasvsa3g36ssxwx@nerd-thinkpad.local> From owner-freebsd-stable@freebsd.org Thu Jul 16 20:19:56 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7A54B36C4AD; Thu, 16 Jul 2020 20:19:56 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B75G34hCcz42dw; Thu, 16 Jul 2020 20:19:55 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-pj1-x102a.google.com with SMTP id ls15so5360142pjb.1; Thu, 16 Jul 2020 13:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=dzaeCT4SeKEpmtaA85bq2q4QzEehm/Y11YYz+3/10RQ=; b=J3MmT/JbQyzf2TlL/qJi+GqhpJSf8EbYQNIz+XBPX281bShkM+2k9Vxru92Y2f+rv2 YdQ+p6QPD9xeiiVkpskxl//FyhB6zPxaMFWeu+owMnXR1zb5t53NYeX4X1/Yk2VVSlTv fpJsv7ZmCDYtvE8gGMjuvdqugaEwOO1JLM9vCDvI19a1/RrYqUEbBaDbsbWNexzi9KtT WVN44TVQPXiJl0A1PmeBDLtkf0UY2n1dl9DdePSfMLive85vjD5rfnVR5qdhPltuEU7y /jRAK8t/5QPSYdkoVmrJdp/Ad97cxqNdvyaOuMN6IqYzWT9UlPwJ/lVpkgq16AAc/ldo CpWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=dzaeCT4SeKEpmtaA85bq2q4QzEehm/Y11YYz+3/10RQ=; b=VPnz5dShc47wt1D512G87WAfYxCLU40Up2zBzID8xmJFlh6+dTWgrTjDyMO8lFMiRO Xjn9kfGXVI5OejtTny85oaCfSgFk7XZzDMKRKLSc2TkBrXKI9n1aRI6WILXC4NSCS7xN 9eGbp5WRBgBR27Xhr/rrbFXBR8RIxk7JjwkZFhOwOWqiSt7V1d6h3fdpqC/C5/GDWLoT /weY8nBKR1JpzUUBRRX+2U5t6fmKeI3o4Z6iw33vrWM474v45QGUA6iF0HXURWu1YCNr l1ANeOB7ENIa+HGHMiLKWwo11VAlhqgvUuhy72MIMm90Kk66z3BFSNBZDHWXIdi+e4R2 jUfA== X-Gm-Message-State: AOAM532GuuTwXSmk/q2vWs4bszjKDewsXyWsE/hsbS0yfOGZ0wJXPLOM DzvQ5PMtkiHy+YNu1h8piLdKg5aH X-Google-Smtp-Source: ABdhPJz17PcOGrjXT99zJv/vVdnohlTlCQPaSp3phZ4sgcw7a5vPU9Cxq2M7N6ZoJMbXqkh4I0avhQ== X-Received: by 2002:a17:90a:246:: with SMTP id t6mr6660824pje.230.1594930793298; Thu, 16 Jul 2020 13:19:53 -0700 (PDT) Received: from [192.168.0.4] (71-223-3-53.phnx.qwest.net. [71.223.3.53]) by smtp.gmail.com with ESMTPSA id h1sm5898266pgn.41.2020.07.16.13.19.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jul 2020 13:19:52 -0700 (PDT) To: FreeBSD Mailing List , freebsd-stable@freebsd.org From: Don Wilde Subject: URGENT: Microsoft overwrites boot loader! Message-ID: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> Date: Thu, 16 Jul 2020 13:19:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 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: 4B75G34hCcz42dw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=J3MmT/Jb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2607:f8b0:4864:20::102a as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-2.63 / 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:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; SUBJECT_ENDS_EXCLAIM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[71.223.3.53:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.022]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.971]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.36)[0.360]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102a:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 20:19:56 -0000 The [deleted] ones in Redmond have done it again. My multi-OS GRUB2 boot loader is gone, and in its place is a 500M partition called 'Windows boot loader'. The purpose is to force us to look at MS' new version of Edge. All my old boot files are gone. It's taken me much of the morning to get underneath this, since on this unit my only OS (other than Doze 10) with a WM and GUI is Ubuntu. That's the last time I will allow this, and I'm calling those [deleted]s tomorrow to give them a piece of my mind. After that I will erase every vestige of that obscene OS from my disk. -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** From owner-freebsd-stable@freebsd.org Thu Jul 16 20:28:48 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7FB8D36CDA4 for ; Thu, 16 Jul 2020 20:28:48 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B75SH5qlwz43bt for ; Thu, 16 Jul 2020 20:28:47 +0000 (UTC) (envelope-from tomek@cedro.info) Received: by mail-wr1-x433.google.com with SMTP id f7so8495129wrw.1 for ; Thu, 16 Jul 2020 13:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dn0nfY1CkTuqPbUut5SxcRWL/e8rKhvDOQolNFYBmJQ=; b=biGzTir00TAcx0uiTzttCFLedjbDF0UdvJVgrvnfbf4WKvwlPONqD5QEaIBJllQ+n+ 56zn4ghwJ8EFqrxOVBUeRsG05Nc16EWA5Bh/wxOid0M1Ax3tS1CEi8adGXrXBsM240+q d1ATS9bhQUUPueHhin4jceZKm4GYxFl86bJImjSINozCc+bN+GaXGTfStfsItypFXAeM 6fTBy9SlMUuW60WjtBWXOI6NBeResx2hZA0cVglA0bDFEfI8vggXwUOd4wDSGeq5d3iC EWq3CBGFkKYyp1wxdLXa9oXNdGveAZgqasK/AzFUaPT5CW+GeyZlLWE8hbLkbwBXpGmx 1yhw== 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=dn0nfY1CkTuqPbUut5SxcRWL/e8rKhvDOQolNFYBmJQ=; b=Gnc0e5VOZSGiSAo/BqAqtfYEnYqsYn/pr9SRAOHat8ecqIS+WQAJtk4PfTqQpPZ72O RAJGTOxvw6Ucyfbp2IWu9x7XFVhXtTnvzUfHCF+9cx4i85UVDn6waBHm+ZN3ixTcbJrN wfUqVuzDzCigA2+1/uYtnAQHqyqvrYfQWIp66c18NKaqBMvFhp7sJ94a0oua7jsg9bOm 0NK2v8JFhlZf6BOYYMSO95B1cqECb8SsbeO2tuUIajNPjrvaT9mUecu76WcKwMSvAF32 GwayaBRjCSdFjstlQTDeFgFb7PtB+VTkM0J14Mef+gUe4oyxsQVqCQEQSlhFVUG4Z/id bZdw== X-Gm-Message-State: AOAM532/3TGUpWDHdWEvNbMrhi/7HM6+0QPGzoHIu2+hNak83sEdg1fl EZD7DhKSN0m9SpFfKG+T957pGmJzaoVJNoivlW1Kdg== X-Google-Smtp-Source: ABdhPJxhKZEAuaLpkFcLxWABYeadAeKDhJ/kAF6f6elj2VRdKi2knZsS+7O4ifB+aCALz6WWtIRDWcnB9H/gmc9nai0= X-Received: by 2002:a5d:5647:: with SMTP id j7mr6402347wrw.242.1594931326078; Thu, 16 Jul 2020 13:28:46 -0700 (PDT) MIME-Version: 1.0 References: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> In-Reply-To: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> From: Tomasz CEDRO Date: Thu, 16 Jul 2020 22:28:33 +0200 Message-ID: Subject: Re: URGENT: Microsoft overwrites boot loader! To: Don Wilde Cc: FreeBSD Mailing List , FreeBSD Stable X-Rspamd-Queue-Id: 4B75SH5qlwz43bt X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=biGzTir0; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2a00:1450:4864:20::433) smtp.mailfrom=tomek@cedro.info X-Spamd-Result: default: False [-1.25 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.56)[-0.561]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.27)[0.274]; NEURAL_HAM_LONG(-0.66)[-0.664]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[cedro.info]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cedro.info:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::433:from]; SUBJECT_ENDS_EXCLAIM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 20:28:48 -0000 czw., 16 lip 2020, 22:20 u=C5=BCytkownik Don Wilde napisa=C5=82: > That's the last time I will allow this, and I'm calling those [deleted]s > tomorrow to give them a piece of my mind. After that I will erase every > vestige of that obscene OS from my disk. > I did that long time ago :-) I have one dedicated laptop if I am really forced to use M$ crap but by all means necessary I avoid it for more than 15 years :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > From owner-freebsd-stable@freebsd.org Thu Jul 16 20:28:54 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4F71336CCAB; Thu, 16 Jul 2020 20:28:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B75SP3hYDz43TK; Thu, 16 Jul 2020 20:28:53 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f49.google.com with SMTP id h13so5280025otr.0; Thu, 16 Jul 2020 13:28:53 -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=mTC02h/lahE6vn5btXOaRyXVx44RWarbSP+w6b0Behk=; b=en6wi16+BPRSGpZH5QMeOOLEu/6XpJXSJX6v7Cs1aCm8ATai8JUAqw5LCgJxVcPHce WaMX0xzduf/eyjLlMhjbgKKMchoLzM2xgCC4BxTV8hUTWVfenSt43XGJWi/+oFqBzGhd ePy982glnp0XtKnlIpg/z+1RjvW/v2J9felVoOm/x1tu7I5jNVOovJw54vI9q2nbu/XI 52k3Z/BQ4tEePNEkhmODSuT3jJzwt4H/esFeLfwUbWIh6sYFMvWmysYLN0ZZRf3PXwBt nxbvHGxBVwHVfEVlH7xT0sSGiitNyTMUnMSCotEtVPitXrQRq++eosuuuT57lld02019 XzNQ== X-Gm-Message-State: AOAM531SxJsboFRB73j0YDUzmKE6Xhg6fOmX27JXmjzTba+ix5gJFW0A XZiGBKxeVgiPdYa9G7W02uYnQ+YrfDjgqcdwRWE= X-Google-Smtp-Source: ABdhPJwK/dmaIlxO1bl7e5kGO/9wnniqWX19Y4ukcMsAEI2jUtkDeu7Oyn3uyndDehFkV8Y5C1ZD5J6t15jbeaFLXvU= X-Received: by 2002:a9d:2788:: with SMTP id c8mr5676727otb.251.1594931332220; Thu, 16 Jul 2020 13:28:52 -0700 (PDT) MIME-Version: 1.0 References: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> In-Reply-To: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> From: Alan Somers Date: Thu, 16 Jul 2020 14:28:41 -0600 Message-ID: Subject: Re: URGENT: Microsoft overwrites boot loader! To: Don Wilde Cc: FreeBSD Mailing List , FreeBSD X-Rspamd-Queue-Id: 4B75SP3hYDz43TK X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.49 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-1.25 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.76)[-0.758]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-0.79)[-0.786]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.49:from]; NEURAL_SPAM_SHORT(0.29)[0.289]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.49:from]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 20:28:54 -0000 On Thu, Jul 16, 2020 at 2:20 PM Don Wilde wrote: > The [deleted] ones in Redmond have done it again. My multi-OS GRUB2 boot > loader is gone, and in its place is a 500M partition called 'Windows > boot loader'. > > The purpose is to force us to look at MS' new version of Edge. All my > old boot files are gone. > > It's taken me much of the morning to get underneath this, since on this > unit my only OS (other than Doze 10) with a WM and GUI is Ubuntu. > > That's the last time I will allow this, and I'm calling those [deleted]s > tomorrow to give them a piece of my mind. After that I will erase every > vestige of that obscene OS from my disk. > > -- > Don Wilde > **************************************************** > * What is the Internet of Things but a system * > * of systems including humans? * > **************************************************** > Edge? I thought that was a browser. What does it have to do with boot loaders? -Alan From owner-freebsd-stable@freebsd.org Thu Jul 16 21:18:02 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6E5F936E323 for ; Thu, 16 Jul 2020 21:18:02 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B76Y53Shyz46jx for ; Thu, 16 Jul 2020 21:18:01 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (096-033-205-208.res.spectrum.com [96.33.205.208]) by colo1.denninger.net (Postfix) with ESMTP id 23B8F21108B for ; Thu, 16 Jul 2020 17:17:24 -0400 (EDT) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (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 denninger.net (Postfix) with ESMTPSA id AFC10230C48 for ; Thu, 16 Jul 2020 17:17:24 -0400 (EDT) Subject: Re: URGENT: Microsoft overwrites boot loader! To: freebsd-stable@freebsd.org References: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> From: Karl Denninger Autocrypt: addr=karl@denninger.net; prefer-encrypt=mutual; keydata= xsFNBF1Rd+gBEACmLAH7SAzdQq57ZN56QQEy0jDFfH5BvGOMZgCaP+Y5lJQ5u9WphCoCALMs Rg0o1Q9DRNWgUmy/cgsxioXAEzZFXXzOHPJhwplVOgfjxnoByD5KQhWG8Owm9QmATdtiZPSV 4UYVNUIbZv7btSnnAXysG2OUHajYS5PVeFQxFbhNFq/SS8VaXr1WEVTFa8NFKp2W3/KY1A+U KKDUlYwnOauK3fnY9chF2IRSoxAbBJFrJ4lPGz04HtzNos4Q9CBfTphKcdFjcPntNS9wrqs3 sm+7hLNTH9B2Kj6aekG5UhD03eyP+gevTgBy51RL6ULzI13Kc4aeyOByuBXrA8D2m2Ee67iy 4+ZSxM9Wn1gQce5624OWzCYIGBH2r75Bshp1KHKu36N2rN//kyKYnwl/z6UZB/S9cMUFKZgL gFx7QxpFX/HvSiBcPfcGS0meModpg6qma7/2jRoQAXacslpiT+uOfRGspNbnglkbw435RzX/ kMUclJQNZBBBUpPiGjVCjeBTiAfN8TyjS+pWzwxNCUZWbYO5xVaS0gbIhgVNoBOGn1rdTsdA PP65SRjaoL5KY6bzkkzrXLB2Djx8/p4vr0qIqxIQWbewJq3xKyKGiqI46ae77BF7k0B++Ndx g9K9UeWKl/iJ0eoI0ftR+xH3aIHTU1Or3j/tj4j8Z0tnVSyt1wARAQABzSNLYXJsIERlbm5p bmdlciA8a2FybEBkZW5uaW5nZXIubmV0PsLBfwQTAQgAKQUCXVF36AIbIwUJCWYBgAcLCQgH AwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEG8twBXrj1l4swkP/3uOzRxW16K6H4JIEIRMUEbt nxDhmk+gR/7H9phg7HtvR7i22QejZX1N1NHcGRNmBwLshWVjJkHKhCE/AM8Cf9XyaV2ft6qn g1xK6NuhapxVuaaMeCVPUzsPkTcR+JMl72ZR4Q+mJMVQButCITekmr7aIzIZ80fF0t86rnq+ O74ZGt0SAMsLV/GAKlIw8fGMi9Xj4OKDgqmxTnIoV4+0mpo26W957pnlOrjN3/6VqWUyAdHH DkyqsuP/9jx2f5pZCcD7X04+93GI+sGb1s6BOFRHq2oJgs6W0z0nPx5Ks9MDDgSQlxXAryje 17WphTR7DWn1BeF3Y8AhRkzc2+Mgc5s1i2fPe6YwvksDNOEyNXIvFV7chwDQYb0Q3I8XsoHu 2WUjXp0kVokobJPdVdY55nbY+brezweRJMiEpFtGOmoUekQWlI5KS1kE8+Xuqpm+MSxEpqY8 5ncPt0lekOrICGajlOotkUK86iVemlW1rMzMc5Xwp9j8oxa+bRtGD6u1rYz4i+qIdE+GSCBy 1nnHN/my0nefhQyHXr8wGVEbyiMZCten9fm1iXpBr0jY+tvtbo8XqZQG7Lr+3kSO6VUgc8kW IPf2HxIV7AnGUN+ddZGCcPPhb2mY/Yy7si54wJFj6YoG+/+rNjF9F5d8WeLoeUWczgHTvZmS o6F7UhjjuwzgzsFNBF1Rd+gBEADNVFS8nQ+kpKOpgtP+f3bCVxHAm7eHMbX6oew5yZiQwfD+ 1RWNWLVOMeTt7G2e5HsHpJOUwFUJhbDb0omB0r38xTSVSAig9kmUfb7tTMJG2bG7WfWykBOM WIZ4OhCf+ISv9dUkjNgx4ionWotFxwDiPRwWumVQ7WYZmRZlhDWMiaHgKvBrjJ7Y6GKPRbQc 5/0Qz9xGhXKlFxDQrrSMkyRThIOxXqdfD9z3rEsV3ZwOojzNsnkIImnQMKyIAR0FBQop34G9 wDQi7fxk8wGIfDszwfR4oAdDdPGq4gcAvE7Fd3xKyNpGyjSED5szoaFjldaZSXQIffquSUvy sFCTTLRIso5Dn9uQgi57gIv+5mnyKBfm2Z2P6pEQPSt073TED9rS0+JpniJL7rKRVpO5niqw sQJS6ht+JF88rXro+SiwxD/KeDpTuuJ10+ohLVi1Y+X82X7BIQEhqtFp9FVJSds4o/eNyaHd SoqfoeWMy3EV+rdJ3DneXcPS1BgxO57Rko5Hx3NUSVK83ovFb+Ofes9SLNdqNu3xAUcfpRdS DyxzpVbCq6Y2CIojiaweiYe5BOBhmR9OPGhqP8YD7GukYmQufAVuOrIVyctBlVPHgMBb+UX+ ItYXuX4weSJWLOsmM45xd/EYvBq2DWFpKlyihoktNzTGqxGsNeG7gCOEUTAnUwARAQABwsFl BBgBCAAPBQJdUXfoAhsMBQkJZgGAAAoJEG8twBXrj1l4Dm0P/iEx2gIHSOnvgpG799Vf2RM0 7gPbDWzDaw8YTV49H+VTOqq7RlT52aO0QfNAmtppX0V1/5f30fuSCF46NWnYGu35P/LvOAPb sLbeWCyJy4GOPN4cjsBMbgmooGdl24RdcvGMmY177o7oOSWBqXfhAj+YA6r+hEar1qxqLgwB Gy8wAId4qYSQhN/FxiQbyUs2tPAI6Wn/41pI7Hu6WgmRGpZrBv8HhVV9Gl7jallSsS/g+fhu WRbDKCknUS5SX3+w2AUFr4kf62gSSxXBxd075KnViV9c0sraAPI31XbM5QUc0Xssfaqs6Srr z4MjKaLhb7GD8C1JwI23PuGdFvk9WK996UvIyjdWIE99VSlg/5gEKkXzwx7oysrSG9BqkfGf I4addK55xRQPul0V3s2LtDoQTxg3VHrL6wrvGhYUcTHLmlsvNx1EOb5a3xBT+SUK/Ltq08LW YcmNbU/G217MlfvDJYHCb0uOtxqJFm8RiZGj2eEcLgvyWnlWCD2rfP4EqCxmpr3Ic725FiQR cBbdTV3clTgclhBG3TA9dxVjfZDcatz5cFBwXP8k5Yn9tNl90T2r79V4SNh1mCHtGTSEf449 qz9tm7EguLchjmoirJTuiipZKcalcHAHtz4VPUykdXsrfEJTzdEcujzqF6v/9CY+DjpAd3et Z0vw7xC5tS+b Message-ID: Date: Thu, 16 Jul 2020 17:17:23 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020700080801040901070705" X-Rspamd-Queue-Id: 4B76Y53Shyz46jx X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-5.52 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.005]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.002]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; NEURAL_HAM_SHORT(-0.62)[-0.617]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 21:18:02 -0000 This is a cryptographically signed message in MIME format. --------------ms020700080801040901070705 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/16/2020 16:28, Alan Somers wrote: > On Thu, Jul 16, 2020 at 2:20 PM Don Wilde wrote: > >> The [deleted] ones in Redmond have done it again. My multi-OS GRUB2 bo= ot >> loader is gone, and in its place is a 500M partition called 'Windows >> boot loader'. >> >> The purpose is to force us to look at MS' new version of Edge. All my >> old boot files are gone. >> >> It's taken me much of the morning to get underneath this, since on thi= s >> unit my only OS (other than Doze 10) with a WM and GUI is Ubuntu. >> >> That's the last time I will allow this, and I'm calling those [deleted= ]s >> tomorrow to give them a piece of my mind. After that I will erase ever= y >> vestige of that obscene OS from my disk. >> >> -- >> Don Wilde >> **************************************************** >> * What is the Internet of Things but a system * >> * of systems including humans? * >> **************************************************** >> > Edge? I thought that was a browser. What does it have to do with boot= > loaders? Microsoft does this on any of their "Feature" updates.=C2=A0 I managed to= figure out how to arrange my EFI setup so that all I have to do is restore the index in the BIOS to point back at REFIND, and everything else is still there. But.... if you stick the FreeBSD loader where Microsoft wants to clobber it, yeah, it'll do that.=C2=A0 It doesn't actually blast the partition th= ough -- just the single file where they want to stuff it. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020700080801040901070705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNzE2MjExNzI0 WjBPBgkqhkiG9w0BCQQxQgRACTTxL+72TqDHdg2Eks0QTKNoBZLGBkmIckgrdvJ+gkc0Vixw CHjygnH1AewBsU1MXHT1cIoW4VrEXQNxbBAN4zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCLoCEpGEAVxDiNdbegCy1KNLAucN7Ol586MbknQXs+4WJolsbHUB32styb3gOQi6aI eSUVjrc1U+a6VshSo6I5POfeOL3mXsTiD1M4vNLgKhNuaVcLEE8uIQAQoxvlbkTqssJv/Fmx X9nYKcG7wdGO1zs+0A2twetHSYmVpTTdqiZ1H80v1/hUZus0uAfGzMbGrH2qyqCNSg944+fD xnqLWRk07/27q1zBc1yhU6vxHrko2T8iyMgOrBmpTaGCdCg2eqOtillSgPe0+ndN29su5E/R f0BGPkSzsGrIGyc9EvRYk3ogJHSbCxcYQF098VUzx0o7zC6SBdZmtFW+Omani+QlholdDxZ6 AMWSBxQASpBt9/MfkLzmQGagiW+hLdptJ4meIFUll+fYau43tPafeurzBT1VBBfEt1iHvo3t DyCyYg0SopZzYJ3t1I5F3bDuSLOWDVuqd34PmjE2WJprgVk9RsSarezfKZSfwosFiCCNPUo+ m1/qgYlJ+65T6072sbEqf0Vw+YRUebpyJV9q6R2eQoRssOQr5OlnQ52h5jLwjHhmNS6LC8W7 XhprXsK7tywkRoR67JPd6WhFkAyheJJj0oSNOmoRfn3p2oKWFLTu0fqmr+cqj0i1FIniqmwL x/lJtDm6u4ADaPpxKePIoRdT/3xqhLh7DVmhz0Z06wAAAAAAAA== --------------ms020700080801040901070705-- From owner-freebsd-stable@freebsd.org Thu Jul 16 23:47:05 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B4E56370FA3; Thu, 16 Jul 2020 23:47:05 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B79s46t18z4Fn4; Thu, 16 Jul 2020 23:47:04 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-pf1-x42e.google.com with SMTP id 207so4475498pfu.3; Thu, 16 Jul 2020 16:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=FMhXYmo4fAvu3bPsh8zGvi0fCScbIEtGxQwBdvIuygM=; b=VMFpbKHgEF2d7+nlkpQr6Kc//l2rcsw8XJH1B4W/nMlh3c2QUSrWb6qcJa4bx0DQXy BW684W4g+bunhOG7LDpePAw5J/XGIAv9qHPFYIm5Tbpyn+t+rXzSxMPIwFKRfBqjL9tE FJ1yCW2ImOZbROzUCK8wMFS0nLkDYtMrs7d6AgxuAVPw1k4RTLDua9liT6fu//vqka13 jJ7f/LxqiiWFGbdPW29wC7IdSvW8U/SBh8nenD1ocwPCtErYiBoynWr/fSv0enwvLbjw HWNIvMttR8EyDDAkb7sdxIae6NL85z3wnrN9rXy3xY42eCbJn9/fsdVrYFtTT6wluwLR qxQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=FMhXYmo4fAvu3bPsh8zGvi0fCScbIEtGxQwBdvIuygM=; b=hTVbnhxew1SoonhTwRqe5pkfhtXR17OAKCrLqPgGQizuZgtSukR7siwbvh7BrjCfOX tX1HMGCgeb++OJkaN2Qc4s9Jqi/QzoKhT4vxC8q+t7abYwRykhYNeDhrfKv+qHZp7Cbz fvO+pDGx9j9TZBZRieRx5td+EqnoErE1wQxLDXWTXP6MxAhPe0w7iWiphiuhSs0Iwx4g X9D5MBzihGgLh+ux3c5X1SzX4GLaSlR3btaJYzhN6OKrxbsIa628cWuCDYe08+bM2kPb u/Y2+eHYhwwtb0WuTTg5qB3uAY+EdCtGeJWzlAuoIBMkru0h0X/K3hbjLWApWfGC6sgB fFWA== X-Gm-Message-State: AOAM530ljfte2Am2+4WWN5fGqL8BV22ihq76JxATBCEgV2Jm9GuGqyI1 Lo8UP/3iTJ2d/31Z0UMjwSYhBr+c4F0= X-Google-Smtp-Source: ABdhPJz7BrPZC6norf9l0i+vR9PtNVWU67ZLZYHdeZOkAH+ifURrBQup2n7OZb2syOZ7VQZTOHd/Ig== X-Received: by 2002:aa7:98c6:: with SMTP id e6mr5748023pfm.17.1594943222655; Thu, 16 Jul 2020 16:47:02 -0700 (PDT) Received: from [192.168.0.4] (71-223-3-53.phnx.qwest.net. [71.223.3.53]) by smtp.gmail.com with ESMTPSA id e15sm5661336pgt.17.2020.07.16.16.47.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jul 2020 16:47:01 -0700 (PDT) Subject: Re: URGENT: Microsoft overwrites boot loader! To: Alan Somers Cc: FreeBSD Mailing List , FreeBSD References: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> From: Don Wilde Message-ID: Date: Thu, 16 Jul 2020 16:47:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Rspamd-Queue-Id: 4B79s46t18z4Fn4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=VMFpbKHg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2607:f8b0:4864:20::42e as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-3.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.61)[-0.609]; SUBJECT_ENDS_EXCLAIM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[71.223.3.53:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.924]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.957]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42e:from]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 23:47:05 -0000 On 7/16/20 1:28 PM, Alan Somers wrote: > On Thu, Jul 16, 2020 at 2:20 PM Don Wilde > wrote: > > The [deleted] ones in Redmond have done it again. My multi-OS > GRUB2 boot > loader is gone, and in its place is a 500M partition called 'Windows > boot loader'. > > The purpose is to force us to look at MS' new version of Edge. All my > old boot files are gone. > > It's taken me much of the morning to get underneath this, since on > this > unit my only OS (other than Doze 10) with a WM and GUI is Ubuntu. > > That's the last time I will allow this, and I'm calling those > [deleted]s > tomorrow to give them a piece of my mind. After that I will erase > every > vestige of that obscene OS from my disk. > > -- > Don Wilde > **************************************************** > * What is the Internet of Things but a system      * > * of systems including humans?                     * > **************************************************** > > > Edge?  I thought that was a browser.  What does it have to do with > boot loaders? > -Alan It is. They over-wrote my boot loader with a special package touting their upgrade and its features. AUTOEXEC.bat is no longer sufficient for them! The only way to get out of it was to reboot to a different disk. By installing a new copy of Ubuntu from DVD on a portion of that drive, I was able to get to the rest of my disk through its GRUB2 (which had been trashed by MS). I sent a really pointed message to MS "Senior Technical Advisors" but nobody (of more than a dozen who were on-line and saw it) responded. I hope nobody commits seppuku, but I'll bet there will be some resignations. MS Windows is the toxic RoundUp of the software world, and 10 is the most egregious one yet. -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** From owner-freebsd-stable@freebsd.org Thu Jul 16 23:56:05 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C3A593712BC; Thu, 16 Jul 2020 23:56:05 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7B3S6d2nz4Gcb; Thu, 16 Jul 2020 23:56:04 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f172.google.com with SMTP id j11so6540705oiw.12; Thu, 16 Jul 2020 16:56:04 -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=KRBjTTjrAx0FmhFK/BgUMrQDrGtGxt2J3gZgJQufGE8=; b=QjEd19PHiZoLV5/TR6Jj+zaCBIW+JhGul+zP+SerHcJo5HjqKaQoyE4g+Rg9uLE3/m lA1KAsxXRjkS0w86U6YHcCbAyelj9eHQggQG61TF4nX+wB1wn0GpMcvRGjq3Y7UG2Pf5 qNxrVKdiafUQLMuVSFOvfzXB39BWG/ydNRHPp4AVl+q1pxMoiXyNIOaVoY/TPaLGot0R zK/reuBP0B+E6bkGsq8W2MITOROiDxkf0YGiFmCULFM4atRg5TRWngQOAQKU7vv69DYD KubqiALTFQYO4J8H6AshR6pjF0OEW1/8VCR+o07pvUZ9m1FYHuLZWs6gMExJCWnXqfag UhhA== X-Gm-Message-State: AOAM5314ogs/N3ZPfg/E8JoJOkFoIZY20u9VBJjVGYIQeK1GOc+sqx8x fRhgNv9r3M4uKhxLJIqr/OE3t9m3MHaRBvORa+k= X-Google-Smtp-Source: ABdhPJzTudxEiGiSSfaDfZdBj8lepMMVqOCyZKwUzGSZ6QcdE7svj40O2yaKjK9jVnURZclkWMucw59MylAmACG9xUc= X-Received: by 2002:aca:59d7:: with SMTP id n206mr5663419oib.73.1594943763600; Thu, 16 Jul 2020 16:56:03 -0700 (PDT) MIME-Version: 1.0 References: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> In-Reply-To: From: Alan Somers Date: Thu, 16 Jul 2020 17:55:52 -0600 Message-ID: Subject: Re: URGENT: Microsoft overwrites boot loader! To: Don Wilde Cc: FreeBSD Mailing List , FreeBSD X-Rspamd-Queue-Id: 4B7B3S6d2nz4Gcb X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.172 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-1.43 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.58)[-0.584]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-0.61)[-0.609]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.24)[-0.237]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.172:from]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.172:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 23:56:05 -0000 On Thu, Jul 16, 2020 at 5:47 PM Don Wilde wrote: > > On 7/16/20 1:28 PM, Alan Somers wrote: > > On Thu, Jul 16, 2020 at 2:20 PM Don Wilde wrote: > >> The [deleted] ones in Redmond have done it again. My multi-OS GRUB2 boot >> loader is gone, and in its place is a 500M partition called 'Windows >> boot loader'. >> >> The purpose is to force us to look at MS' new version of Edge. All my >> old boot files are gone. >> >> It's taken me much of the morning to get underneath this, since on this >> unit my only OS (other than Doze 10) with a WM and GUI is Ubuntu. >> >> That's the last time I will allow this, and I'm calling those [deleted]s >> tomorrow to give them a piece of my mind. After that I will erase every >> vestige of that obscene OS from my disk. >> >> -- >> Don Wilde >> **************************************************** >> * What is the Internet of Things but a system * >> * of systems including humans? * >> **************************************************** >> > > Edge? I thought that was a browser. What does it have to do with boot > loaders? > -Alan > > It is. They over-wrote my boot loader with a special package touting their > upgrade and its features. > > AUTOEXEC.bat is no longer sufficient for them! > > The only way to get out of it was to reboot to a different disk. By > installing a new copy of Ubuntu from DVD on a portion of that drive, I was > able to get to the rest of my disk through its GRUB2 (which had been > trashed by MS). > > I sent a really pointed message to MS "Senior Technical Advisors" but > nobody (of more than a dozen who were on-line and saw it) responded. I hope > nobody commits seppuku, but I'll bet there will be some resignations. > > MS Windows is the toxic RoundUp of the software world, and 10 is the most > egregious one yet. > Are you saying that they overwrite the bootloader in order to display some kind of popup add before the main OS loads? That makes no sense whatsoever. It is the crazy ravings of a madman. Except, I know Don to be reliable. There's definitely a madman involved with this story somehow, but I don't think it's Don. -Alan From owner-freebsd-stable@freebsd.org Fri Jul 17 00:00:29 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 02085371893; Fri, 17 Jul 2020 00:00:29 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7B8W65mZz4H0K; Fri, 17 Jul 2020 00:00:27 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-pj1-x1044.google.com with SMTP id cv18so3473856pjb.1; Thu, 16 Jul 2020 17:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=roEkrFm06bvJCaHQSwyKlOknO4FHy1CONDbZBp64ULc=; b=Bx+e0IX+vapkFumZFjUKb3BWm7y40oYsjmHE0gCzxrXDf0hwXvlSyomOeVvpP1Q2FX LV86U7Lvu+NZgD3Een5M5RvZz8myG1bYdLnyjyhQBBkRdyFTqxtjCx/3sAz3z1rlD4F0 vnT1xCN0m7slXkEE6wq38CnFf24Kc362GzTLogoGRwN3SBpPdf4KyjJlW00kqQMXQ78C vHn8A4yIfljXjbXX5iwUKS6tjZBzbiOWSf0tSgy+e3FPByrrQG22jtqCsoOmvt5D3Uhi eqGFyqXRWJywXkDehU7pl2JEZE+Ze7yoVy8qR7Q3e2HoruelaTgEEdhXaKBigzg3N60t uNWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=roEkrFm06bvJCaHQSwyKlOknO4FHy1CONDbZBp64ULc=; b=VF3J0dzF9TJcbSa4SuVNmnBKVR+hAcjGr8Y6wZ+bzgEk8P490Ptjz798h3UhobHrfl 5CfUHlmD0/44q59VFcObrDl0IZIC5DBTw5Zus/avQkHH5lLOsaEAhwg3kwlnqnCaLPEg rUdVhoxdputak/SltDuHLqd0+buABnAUQZnlN9sChDJt+j92VvQfzXf+us++P/kvKxqG VSEljwkmedVIjY8sQ0mccFCLVeMUCOUu9brNcd46EtrLERTLL1AwWe/tt3GpOFTH/y5K U/yFjjnrFE5u6R0iJnoID/ANOAevX5LdU7Pw03eHlvFdmCh0xCWX1PNJhaKucJzi2dE0 3mig== X-Gm-Message-State: AOAM530pdslHwujlwpfuiGxcggzbn1I4yRt9SSf+fhapjHeo7VZp8s8T FhJye0W/S20Sd641OSfV0mpoj5/oDYY= X-Google-Smtp-Source: ABdhPJwM1ENdXSAekCRp9cSOs7k8fLUqoNDk3I4Cr9gKp6tTok7W3hhz79bh2vqr9ShQY9gRC1mjEA== X-Received: by 2002:a17:90a:354d:: with SMTP id q71mr7558563pjb.216.1594944024338; Thu, 16 Jul 2020 17:00:24 -0700 (PDT) Received: from [192.168.0.4] (71-223-3-53.phnx.qwest.net. [71.223.3.53]) by smtp.gmail.com with ESMTPSA id z25sm5811059pfg.140.2020.07.16.17.00.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jul 2020 17:00:23 -0700 (PDT) Subject: Re: URGENT: Microsoft overwrites boot loader! To: Valeri Galtsev Cc: FreeBSD Mailing List , FreeBSD Stable References: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> <8D1E28F3-ADCF-4CF1-BA2A-B071887A6E4E@kicp.uchicago.edu> From: Don Wilde Message-ID: <60edae09-428d-0048-1c7d-9e96a60c44e6@gmail.com> Date: Thu, 16 Jul 2020 17:00:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <8D1E28F3-ADCF-4CF1-BA2A-B071887A6E4E@kicp.uchicago.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4B7B8W65mZz4H0K X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Bx+e0IX+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2607:f8b0:4864:20::1044 as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-3.54 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; 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:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.61)[-0.609]; SUBJECT_ENDS_EXCLAIM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[71.223.3.53:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.952]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.98)[-0.976]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1044:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 00:00:29 -0000 On 7/16/20 2:28 PM, Valeri Galtsev wrote: > >> On Jul 16, 2020, at 3:28 PM, Tomasz CEDRO wrote: >> >> czw., 16 lip 2020, 22:20 użytkownik Don Wilde napisał: >> >>> That's the last time I will allow this, and I'm calling those [deleted]s >>> tomorrow to give them a piece of my mind. After that I will erase every >>> vestige of that obscene OS from my disk. >>> >> I did that long time ago :-) I have one dedicated laptop if I am really >> forced to use M$ crap but by all means necessary I avoid it for more than >> 15 years :-) >> > Microsoft does not admit that other systems exist. So, if I have to have multi boot system, usually laptop, as many sysadmins do, I install MS Widows first (often it is even not installation, but bringing up to the drive “image” machine vendor gives for “reinstallation”). If for whatever reason MS windows is installed not the first, I just restore boot of another system (say by booting it from live DVD) after Windows installation. My current PC laptop is triple boot: UbuntuEbonite linux (my apologies it is not CentOS), FreeBSD, and, of course MS Windows ;-) > > Valeri Actually, Doze WAS the first on that system, straight from Dell. I never had this issue before, even with the 7 - 10 upgrade, despite adding Ubuntu 18 to it many years ago. I was playing with GRUB Customizer the other day to add another drive dedicated to FreeBSD, and that may have installed my loader in the location MS trashed. I no longer need any program on Windows. I have gotten everything, even my payware model train programs with OpenGL, to work on Wine. It will be erased from my last disk this weekend. -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** From owner-freebsd-stable@freebsd.org Fri Jul 17 00:20:15 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 29FA2372729; Fri, 17 Jul 2020 00:20:15 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7BbL2p74z4J8H; Fri, 17 Jul 2020 00:20:14 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-pg1-x52f.google.com with SMTP id n5so5779757pgf.7; Thu, 16 Jul 2020 17:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=xjbV2o46MIJPEp+mnPrj5vfLiXvV9UBM0Ea9nEiQVoU=; b=W5q893rikNUBz+aKhuA/jzaT0qU2k5yUmkudWip91dXKiPOR8NC6EOJSdJXC8En0E3 9P4ZcvcYEFY3ONvGuXGYFlvEQjm/LS5eKeEQfm9uTPE2qqM8AzBjXpIcstNcaDpM1Vrt NQghE+4L18HEElWKNYy4uJ3NXbGOKMpDiHdz+ZEm/G2u05VxsxtfoiGskzv+lNMPMQTH uxf7436pwQCJfp/Lm0I3ZDHbuJyzqY6xaE1k49KSrLb3L8J94JHAlNJK0OhKj1aJN2R6 Xeq6qtPSlyr5sySmFZ7Nk89zmxSKBW120c9hS96uF980eMt3ceYHsoNcVrtPA8BR/B0f w5nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=xjbV2o46MIJPEp+mnPrj5vfLiXvV9UBM0Ea9nEiQVoU=; b=hqlH+l2MfwPmSfrGNVT1yk1DiOpgmQBrYYZMFHcxpwUN5ARVVdigqMy7z6Z7ADJmVf 8CLm67+abl58jcIcNn/7j6M41Lixsj4w65KTxOeT2ncSuGcK4+Q//6LQ8T+yTw41k0kZ S7iQbUHv7Bvp8M78SOoVa3VNV4tBNRzEs61KYi26EA/i6fV14Nw37pZS3qzjPovKktB1 LgOngGbf08GCxRgzmt30cYpsJx2vpFhYGjjkJ08rd0xD2iwvzN62ng8hl/IUsDyMaMlA 7E/KO2WpSlp0oaKFZ4T1PcXj3DAfeGhmT64ZG+KezIa5+7NZ29uV4evm6ofFm+hXifJT Ox+g== X-Gm-Message-State: AOAM531Q9/xAYB98PcAO5BcEJOqDNaNJ/jM7NLVfovwxPhBJdBpguS/9 OkTXFuMSoBDqBEptH6pWwkQnwtEaSTE= X-Google-Smtp-Source: ABdhPJxHESQ+HULeKLgswUyMw9Z32VL+Lx4ovTLZGrADvD/qWIC3JbZobVT+lifMOQYi51EkQblqpg== X-Received: by 2002:a63:e045:: with SMTP id n5mr6836200pgj.274.1594945211760; Thu, 16 Jul 2020 17:20:11 -0700 (PDT) Received: from [192.168.0.4] (71-223-3-53.phnx.qwest.net. [71.223.3.53]) by smtp.gmail.com with ESMTPSA id u73sm6050170pfc.113.2020.07.16.17.20.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jul 2020 17:20:10 -0700 (PDT) Subject: Re: URGENT: Microsoft overwrites boot loader! To: Alan Somers Cc: FreeBSD Mailing List , FreeBSD References: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> From: Don Wilde Message-ID: Date: Thu, 16 Jul 2020 17:20:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Rspamd-Queue-Id: 4B7BbL2p74z4J8H X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=W5q893ri; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2607:f8b0:4864:20::52f as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-3.43 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.55)[-0.553]; SUBJECT_ENDS_EXCLAIM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[71.223.3.53:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.924]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.956]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52f:from]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 00:20:15 -0000 On 7/16/20 4:55 PM, Alan Somers wrote: > On Thu, Jul 16, 2020 at 5:47 PM Don Wilde > wrote: > > > On 7/16/20 1:28 PM, Alan Somers wrote: >> On Thu, Jul 16, 2020 at 2:20 PM Don Wilde > > wrote: >> >> The [deleted] ones in Redmond have done it again. My multi-OS >> GRUB2 boot >> loader is gone, and in its place is a 500M partition called >> 'Windows >> boot loader'. >> >> The purpose is to force us to look at MS' new version of >> Edge. All my >> old boot files are gone. >> >> It's taken me much of the morning to get underneath this, >> since on this >> unit my only OS (other than Doze 10) with a WM and GUI is Ubuntu. >> >> That's the last time I will allow this, and I'm calling those >> [deleted]s >> tomorrow to give them a piece of my mind. After that I will >> erase every >> vestige of that obscene OS from my disk. >> >> -- >> Don Wilde >> **************************************************** >> * What is the Internet of Things but a system * >> * of systems including humans?  * >> **************************************************** >> >> >> Edge?  I thought that was a browser.  What does it have to do >> with boot loaders? >> -Alan > It is. They over-wrote my boot loader with a special package > touting their upgrade and its features. > > AUTOEXEC.bat is no longer sufficient for them! > > The only way to get out of it was to reboot to a different disk. > By installing a new copy of Ubuntu from DVD on a portion of that > drive, I was able to get to the rest of my disk through its GRUB2 > (which had been trashed by MS). > > I sent a really pointed message to MS "Senior Technical Advisors" > but nobody (of more than a dozen who were on-line and saw it) > responded. I hope nobody commits seppuku, but I'll bet there will > be some resignations. > > MS Windows is the toxic RoundUp of the software world, and 10 is > the most egregious one yet. > > > Are you saying that they overwrite the bootloader in order to display > some kind of popup add before the main OS loads?  That makes no sense > whatsoever.  It is the crazy ravings of a madman.  Except, I know Don > to be reliable. There's definitely a madman involved with this story > somehow, but I don't think it's Don. > > -Alan Thanks, Alan! After that one, I'm not even sure. From what others have said, I guess I've been lucky on this. Then again, I've been dodging MS bullets since the CP/M days... -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** From owner-freebsd-stable@freebsd.org Fri Jul 17 07:11:56 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D98EE35ADE9 for ; Fri, 17 Jul 2020 07:11:56 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from mail.ish.com.au (mail.ish.com.au [203.29.62.212]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7MkL3NYrz4f82 for ; Fri, 17 Jul 2020 07:11:54 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from [10.242.2.3] (helo=MacBook-Pro.local) by mail.ish.com.au with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.94 (FreeBSD)) (envelope-from ) id 1jwKX7-000Ka1-LK for freebsd-stable@freebsd.org; Fri, 17 Jul 2020 17:11:49 +1000 From: Aristedes Maniatis Subject: Ethernet interface Watchdog timeout To: freebsd-stable Message-ID: <2931240e-45c2-93e3-4746-48d4f566bd9f@ish.com.au> Date: Fri, 17 Jul 2020 17:11:49 +1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Thunderbird/79.0 MIME-Version: 1.0 Content-Language: en-AU X-Rspamd-Queue-Id: 4B7MkL3NYrz4f82 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.88 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[ish.com.au:s=mail]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:203.29.62.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-0.95)[-0.947]; RCPT_COUNT_ONE(0.00)[1]; MANY_INVISIBLE_PARTS(1.00)[10]; NEURAL_HAM_MEDIUM(-0.88)[-0.883]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[ish.com.au:+]; DMARC_POLICY_ALLOW(-0.50)[ish.com.au,quarantine]; NEURAL_HAM_SHORT(-0.05)[-0.049]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7545, ipnet:203.29.62.0/24, country:AU]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 07:11:56 -0000 Last night I needed to reboot switches connected to a FreeBSD server. There are two igb interfaces, bound via lagg0 as an LACP pair. Each is connected to a different switch and those switches support mlag (LAG distributed across more than one switch unit). One of the interfaces came back fine when its switch rebooted, but when the second switch was rebooted several hours later the other interface didn't. Both igb0 and igb1 interfaces are on the motherboard itself. This has happened once before, and rebooting the FreeBSD server resolved it. Obviously I'd like to understand the problem better first. Is there more debugging I could collect while the server is in this state? Physically removing the ethernet cable and plugging it back in does not bring the interface up. ifconfig down and up also does not help. What is this watchdog timeout that we are seeing in the logs? Ari # ifconfig igb0 igb0: flags=8c03 metric 0 mtu 1500     options=e507bb     ether ac:1f:6b:00:ea:b2     media: Ethernet autoselect     status: no carrier     nd6 options=29 # uname -a FreeBSD lash.internal 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC  amd64 # grep igb0 /var/log/messages Jul  8 23:00:43 lash kernel: igb0: Watchdog timeout (TX: 0 desc avail: 42 pidx: 1003) -- resetting Jul  8 23:00:43 lash kernel: igb0: link state changed to DOWN Jul  8 23:00:44 lash kernel: igb0: Watchdog timeout (TX: 7 desc avail: 1024 pidx: 0) -- resetting Jul  9 00:00:01 lash kernel: igb0: Watchdog timeout (TX: 7 desc avail: 1024 pidx: 0) -- resetting Jul  9 05:01:12 lash kernel: igb0: Watchdog timeout (TX: 7 desc avail: 1024 pidx: 0) -- resetting Jul  9 05:06:56 lash kernel: igb0: Watchdog timeout (TX: 7 desc avail: 1024 pidx: 0) -- resetting Jul  9 14:25:33 lash kernel: igb0: Watchdog timeout (TX: 7 desc avail: 1024 pidx: 0) -- resetting Jul  9 14:44:30 lash kernel: igb0: Watchdog timeout (TX: 7 desc avail: 1024 pidx: 0) -- resetting igb0@pci0:1:0:0:    class=0x020000 card=0x152115d9 chip=0x15218086 rev=0x01 hdr=0x00     vendor     = 'Intel Corporation'     device     = 'I350 Gigabit Network Connection'     class      = network     subclass   = ethernet     cap 01[40] = powerspec 3  supports D0 D3  current D0     cap 05[50] = MSI supports 1 message, 64 bit, vector masks     cap 11[70] = MSI-X supports 10 messages, enabled                  Table in map 0x1c[0x0], PBA in map 0x1c[0x2000]     cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR NS                  link x4(x4) speed 5.0(5.0) ASPM disabled(L0s/L1)     ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected     ecap 0003[140] = Serial 1 ac1f6bffff00eab2     ecap 000e[150] = ARI 1     ecap 0010[160] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI disabled                      0 VFs configured out of 8 supported                      First VF RID Offset 0x0180, VF RID Stride 0x0004                      VF Device ID 0x1520                      Page Sizes: 4096 (enabled), 8192, 65536, 262144, 1048576, 4194304     ecap 0017[1a0] = TPH Requester 1     ecap 0018[1c0] = LTR 1     ecap 000d[1d0] = ACS 1 # dmidecode -t baseboard # dmidecode 3.2 Scanning /dev/mem for entry point. SMBIOS 3.0 present. Handle 0x0002, DMI type 2, 15 bytes Base Board Information     Manufacturer: Supermicro     Product Name: X10DRW-i     Version: 1.02     Serial Number: NM173S002991     Asset Tag: Default string     Features:         Board is a hosting board         Board is replaceable     Location In Chassis: Default string     Chassis Handle: 0x0003     Type: Motherboard     Contained Object Handles: 0 Handle 0x0021, DMI type 41, 11 bytes Onboard Device     Reference Designation: ASPEED Video AST2400     Type: Video     Status: Enabled     Type Instance: 1     Bus Address: 0000:05:00.0 Handle 0x0022, DMI type 41, 11 bytes Onboard Device     Reference Designation: Intel Ethernet i350 #1     Type: Ethernet     Status: Enabled     Type Instance: 1     Bus Address: 0000:01:00.0 Handle 0x0023, DMI type 41, 11 bytes Onboard Device     Reference Designation: Intel Ethernet i350 #2     Type: Ethernet     Status: Enabled     Type Instance: 2     Bus Address: 0000:01:00.1 From owner-freebsd-stable@freebsd.org Fri Jul 17 07:47:10 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F305B35C09D for ; Fri, 17 Jul 2020 07:47:10 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7NW2296Lz3SGY for ; Fri, 17 Jul 2020 07:47:10 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by home.opsec.eu with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1jwL58-000Bss-GP; Fri, 17 Jul 2020 09:46:58 +0200 Date: Fri, 17 Jul 2020 09:46:58 +0200 From: Kurt Jaeger To: Aristedes Maniatis Cc: freebsd-stable Subject: Re: Ethernet interface Watchdog timeout Message-ID: <20200717074658.GA5015@home.opsec.eu> References: <2931240e-45c2-93e3-4746-48d4f566bd9f@ish.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2931240e-45c2-93e3-4746-48d4f566bd9f@ish.com.au> X-Rspamd-Queue-Id: 4B7NW2296Lz3SGY X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 07:47:11 -0000 Hi! > # uname -a > FreeBSD lash.internal 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64 See here: https://www.freebsd.org/security/advisories/FreeBSD-EN-20:09.igb.asc -- pi@opsec.eu +49 171 3101372 Now what ? From owner-freebsd-stable@freebsd.org Fri Jul 17 08:27:08 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 93E5A35D0E6; Fri, 17 Jul 2020 08:27:08 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7PP74Dn4z3VCH; Fri, 17 Jul 2020 08:27:07 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-pf1-x444.google.com with SMTP id a24so5059041pfc.10; Fri, 17 Jul 2020 01:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=NJ39Bj3xkKMaqeMwkxKT0FrGwcE0GsgKohqeABE8C8w=; b=MAEGoTxkLwJ1qJJZVqp+qv06X45EFjrsVszZBadPVA7QJGQ+HoKrBhgQJfHv9V2SL1 Z3bYH8SOkDx3G6zm/4fhCjcU1eMQWl2lZhXtfFghOMI2XlDGwsOKfQM2vERZivGCq9az MmeQt8FqH8gtcNmvPYNgrQaz4Zf8W5JRGG4lMF1kS/ALH6JD/iHXD55hWpQnYLcId6lQ vNPbq1GcA9zzQy9+7bhXUcwAdvb/XkvNsGVsEcjo0WPCy5R8AFmPdo34kvbMFYzMSER/ WLenZiL/tqUzIp66Iie9mG58DoUs6PZ6GDbg7Ja7mz7l9/SUaVl55lhiyPwalZFBU73L fz/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=NJ39Bj3xkKMaqeMwkxKT0FrGwcE0GsgKohqeABE8C8w=; b=QvWrGuZFIGGv/kzu5n9/rTa7tumjpMpLeGF+87pmRsLOVMGd0mRn+dgm1ntakWL2E3 e7EF3YjshKrvqpjct7X60KQyUf8iYkMBIRVjTalLI2JI8gADTWft57tkSNg2d2Qfojs/ 5i1tvLW8wImpvgEQTw9TnWr5mendpptYbH7dQqxWZmwJPaCIhP76N1W7ztiPeHf9flS1 jsH5d0iEVpvEa3/pAWE9Qhhtq8yZglmcU6imG68SUKFE5/545qbf/9UrLjrRW+UcFTQh P+U2d5zY0BZMsq5ZjVLEB4JccE7zew/i6P/BfotH56aPM8/B0/+iJu69RXPUWRTmLW/N uPEQ== X-Gm-Message-State: AOAM533evE23FyRbaLJDAJ6rR3P/7ukXsRAIB0XKXaLFVBTL/nq5d6t+ GecnN2gYDkhcH8erFyB1iNju5T0JQCM= X-Google-Smtp-Source: ABdhPJzboCyTRwO1yPgWqWoGo2khpHER3RI24XXNKvemH6S3g6y41oz/gzrdixdizS2fwN0lQvkHew== X-Received: by 2002:a62:f905:: with SMTP id o5mr7408170pfh.244.1594974425977; Fri, 17 Jul 2020 01:27:05 -0700 (PDT) Received: from [192.168.0.4] (71-223-3-53.phnx.qwest.net. [71.223.3.53]) by smtp.gmail.com with ESMTPSA id f29sm7089669pga.59.2020.07.17.01.27.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jul 2020 01:27:05 -0700 (PDT) Subject: Re: URGENT: Microsoft overwrites boot loader! To: Manish Jain , FreeBSD Mailing List , freebsd-stable@freebsd.org References: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> From: Don Wilde Message-ID: Date: Fri, 17 Jul 2020 01:27:03 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4B7PP74Dn4z3VCH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=MAEGoTxk; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2607:f8b0:4864:20::444 as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-3.32 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.38)[-0.379]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FREEMAIL_TO(0.00)[hotmail.com,freebsd.org]; RECEIVED_SPAMHAUS_PBL(0.00)[71.223.3.53:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.96)[-0.958]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::444:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 08:27:08 -0000 On 7/16/20 7:40 PM, Manish Jain wrote: > > > On 2020-07-17 01:49, Don Wilde wrote: >> The [deleted] ones in Redmond have done it again. My multi-OS GRUB2 >> boot loader is gone, and in its place is a 500M partition called >> 'Windows boot loader'. >> >> The purpose is to force us to look at MS' new version of Edge. All my >> old boot files are gone. >> >> It's taken me much of the morning to get underneath this, since on >> this unit my only OS (other than Doze 10) with a WM and GUI is Ubuntu. >> >> That's the last time I will allow this, and I'm calling those >> [deleted]s tomorrow to give them a piece of my mind. After that I >> will erase every vestige of that obscene OS from my disk. >> > > If I understand correctly, it's just that your Grub boot-loader is gone. > Yes, exactly. > That should not be much of a problem if your system is MBR+BIOS. > Unfortunately, it's GPT under EFI. I can access all my files through the F12 key on this Dell tower, be it Windows, Linux or FreeBSD, but if I allow it to boot with the Doze HDD in the system, it boots to that one. > If your system is MBR+BIOS, the following should work. > > Boot with your FreeBSD CD/DVD/memstick, and write out boot0 to all > your disks: > > boot0cfg -B /dev/ > boot0cfg -B /dev/ > boot0cfg -B /dev/ > > Next, boot with your Ubuntu CD/DVD/memstick, and write out Grub to > your Ubuntu / partition. If Ubuntu / is /dev/sdb2 : > > sudo mount /dev/sdb2 /mnt > sudo grub-install --force --root-directory=/mnt /dev/sdb2 > > Reboot. When booting Ubuntu the first time, first press 'e' at the > Grub loader menu to edit the configuration, delete the complete if..fi > block, check that your line beginning with 'linux' is accurate and > then press F10. Once the system  has booted, run 'sudo update-grub'. > I appreciate the good data, Manish. I'm going to make sure I've gotten all my files off the Doze partition and then wipe it completely. FreeBSD is going to be my primary host OS and I'll keep my other drive for whatever flavors of Linux I need to work with for work. Based on what I've hseen on these threads, MS is still saddled with a number of bad legacy architectural choices as well as poor management choices, and both of those contribute to the challenges the use of their OS brings. I simply won't accept any contract that requires me to work with Windows. I've survived well enough without that skill set and I see no problem going forward. -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** From owner-freebsd-stable@freebsd.org Fri Jul 17 09:05:55 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4B2C235E363; Fri, 17 Jul 2020 09:05:55 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-pj1-x1041.google.com (mail-pj1-x1041.google.com [IPv6:2607:f8b0:4864:20::1041]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7QFt4Qgqz3XWK; Fri, 17 Jul 2020 09:05:54 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-pj1-x1041.google.com with SMTP id b92so6080251pjc.4; Fri, 17 Jul 2020 02:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=EY1e1UjJfCw66VA/DM+1V1QKqpMW4WlvOmt/QmGk5cA=; b=jpy08KmJ/qK0kgr53v2/cBJzGmv9VI7bEJ2v1rvg++ScpAT2dZpiQ/Smkd8nfZNzSn dvghrhpqI4xIawXvSysemfNqlySlyGOw1T5hutaYhaRczp498syCOylRMxshkoM58swD iW8zofidgYqN4s8FNk2kLQfQhk4oRNxKSPt1RDx+RtqY2dmueaDx4SeUeH64tQfMMsve rAgVPyHJz352F7Z2rGmsYe3DoXh/ENVPX5p/nvKsh52Iv3uEUUvWdTxFnSwzZZz0UnYt fdVhuAr/jx7w5TYZc1cfBtonPxr5b1k8/8ZqbtWEK2ADI6RstLBXO7tb3TlOfHUoE5r6 S4aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=EY1e1UjJfCw66VA/DM+1V1QKqpMW4WlvOmt/QmGk5cA=; b=b4zmp8NuaaOHJokBo0HuQQ0LaBEC4REpAF/xBjQO+RiEJk4IIBu850RieMmwnbxHcc pZLsVRVi1n9mx7foP4yNFe6/KImJmuJZYiyIk9zUDWK9vqkESAOJYbR4Y0bPZ56oUDS6 2YMy2xCifYxZHOLb+UyxBKJF7LNo5fs5o3KBzcA68rWOf2TEQTrPtx51fAaD37NAtadk 8chUDszRRQ61ABuhEYSKi+pbAqeaHsaEImT+/xaSn4JEjzzBuvLapis+DAJauEmcUt24 RP+w1OlSDzEyu9SsCq1FUmW39eQ8x8/3saHXccwiqv90T0GiJQvlS6eD84rTjssBfz+f J5jg== X-Gm-Message-State: AOAM5307XysQKzrsnHLqncPDCGv0F71fIfSUNmUWr0S2DJRUmkrKuZex NMZt67v9xZ/5hnNez/1Gl0lJrMU2qQu7kA== X-Google-Smtp-Source: ABdhPJwKk2k7UwF/Fe8p7rwS0akCbCQCdxKh50b2cxZKRHGXwkrU8GeFOVxHoZGDqiUd0XP1mD+mpw== X-Received: by 2002:a17:90b:1b0a:: with SMTP id nu10mr8645491pjb.182.1594976752555; Fri, 17 Jul 2020 02:05:52 -0700 (PDT) Received: from [192.168.0.4] (71-223-3-53.phnx.qwest.net. [71.223.3.53]) by smtp.gmail.com with ESMTPSA id z11sm7129554pfk.46.2020.07.17.02.05.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jul 2020 02:05:51 -0700 (PDT) Subject: Re: URGENT: Microsoft overwrites boot loader! To: Polytropon Cc: FreeBSD Mailing List , freebsd-stable@freebsd.org References: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> <20200717085305.ffd5191c.freebsd@edvax.de> From: Don Wilde Message-ID: <8158aa31-493c-d316-9dbe-fcf35f569baf@gmail.com> Date: Fri, 17 Jul 2020 02:05:50 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200717085305.ffd5191c.freebsd@edvax.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4B7QFt4Qgqz3XWK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=jpy08KmJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2607:f8b0:4864:20::1041 as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-3.14 / 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:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.18)[-0.184]; SUBJECT_ENDS_EXCLAIM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[71.223.3.53:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.982]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.97)[-0.974]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1041:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 09:05:55 -0000 On 7/16/20 11:53 PM, Polytropon wrote: > On Thu, 16 Jul 2020 13:19:51 -0700, Don Wilde wrote: >> The [deleted] ones in Redmond have done it again. My multi-OS GRUB2 boot >> loader is gone, and in its place is a 500M partition called 'Windows >> boot loader'. > They do this all the time. The consensus here is to install > "Windows" first, always, restricted to the designated disk > space, and _then_ install Linux, FreeBSD, GRUB, or anything > else non-"Windows", in order to avoid the exact problem you > are describing. Even older versions of "Windows" were known > to destroy things like the FreeBSD boot manager when they > are installed as a 2nd choice. MICROS~1 always wants you to > treat it first class, with golden feet and glockenspiel. > > However, is my interpretation correct? Did this happen when > you _installed_ "Windows" on that machine for the first time, > or did it happen after you _booted_ an already installed > instance of "Windows", which then did attack "foreign data" > on the disk? This machine still maintains the original Windows installation, first with W7, and then (finally, bad mistake) upgraded to W10. >> The purpose is to force us to look at MS' new version of Edge. All my >> old boot files are gone. > Something like that should never happen. It's absolutely > normal that "Windows" installs software without user consent, > and then presents it prominently in user-configured areas > such as the desktop, the "Start" menu, or the bottom bar > (pun absolutely intended), but it should never exceed its > authority beyong the border of the "Windows" partition, > which clearly means: "Hands off of Grub partition!" Yes. The bastards also screwed up my 128GB backup drive -- again without asking -- when I left it plugged in during a Doze boot. > > Especially with "Windows 10", the PC is no longer a PC, > not a _personal_ computer belonging to the user; it's rather > a system remotely controlled by MICROS~1, and having installed > "Windows" and therefore agreed to the terms of usage (EULA), > there is probably nothing "wrong" with it, because you have > agreed that they can do whatever they want, and if something > goes wrong, it's your fault. Legal business as usual. Yes, agreed. They far outstrip the robber barons of the 1800s in their greed. Even Carnegie finally discovered a heart beating inside of himself, and gave us libraries and Napoleon Hill! > > Many years (or let's say, decades) I had a similar problem > with an OS/2 installation: It messed up the system's partition > table, a system where DOS (not that DOS, the other one) was > installed, and there was a data loss: Partition D: became C:, > E: became D:, F: became E:, and C: along with its content > seemed to be gone. But in the overall "disk space calculation" > it must still have been on disk, so I used the Norton Disk Editor > (DISKEDIT.EXE from Norton Utilities, a great product at that > time!), a handheld calculator and pen & paper to re-calculate > the correct values for the partition table, entered them, > rebooted, prayed unto the holy bringer of peace, Alpha-Omega, > and tadaa, C: was there again, with the correct content. I never had that wonderful luxury of being saddled with a "real" IBM machine or OS/2. One would note that they, too (along with MS, eventually), are being relegated to the dustbin of history where they belong. [snip] >> That's the last time I will allow this, and I'm calling those [deleted]s >> tomorrow to give them a piece of my mind. After that I will erase every >> vestige of that obscene OS from my disk. > They don't mind. They already have your money. And maybe they > even have your name, address, phone number, credit card number > or other banking information... I have a few last resort technologies they *don't* know about, though they are not worth any more of my time or psychic energy. :D -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** From owner-freebsd-stable@freebsd.org Fri Jul 17 09:28:47 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 36D2A35EDA0; Fri, 17 Jul 2020 09:28:47 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7QmG13sSz3YHy; Fri, 17 Jul 2020 09:28:45 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-pg1-x543.google.com with SMTP id l63so6399131pge.12; Fri, 17 Jul 2020 02:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=o2Nin7PsKR8zu96A4NFiIVq5ZT8hS6LBWdfj8WDNCJs=; b=lLcjovyoc5eCLxMtxLjVhbOGEtKr4D4kMEIL9CFHs+4ZwYYTXKMSEjyEA0B7+VOf0D QytBdTjtGJ5Y62zZMiGnhwxaDC9gn7lB5dTKnh1SPmPb5Sx++pVHIW9Q9WR1bx20sDHk 1OWRnb0clgRY6TnIXf7JqCcr3m683+J+g7+PXS+Tw7EzjpYbs1t/XtfnzKKUfHf+d07c bM0Z7U1GB/7TrjF1V1Ak/qgisOObaXY9UbQApa/6DXxCPRpJnrccAJ1PFmW6y52xqEto RDIyxkvDNNApPAQuCwzASgWWcWcMiZTvl1Aj7PVw4GgaSO0cfQ2NMa0bun3wvEzyQ1/U 6yvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=o2Nin7PsKR8zu96A4NFiIVq5ZT8hS6LBWdfj8WDNCJs=; b=MFwzzqHMMfmmCPzJJ+JA+STjYguOgnYPq6PFm3r4qRCpV33RWBnbRkGtRW8keSA2EZ vv4Yx14Ded/1FwikGwE5jgzW+5YPZI3TSDjm4s+ZCM/ezmAUoNNP742KxSYvghQnBRa0 vbei4+Th4WSru0mKiH34LlZ/LCZdJWpcDxLpVy14vrJaLCCobbnQW+b8K8N7iu9gUwuD m6gjsgWlOiXPsNTBi3QSqgNznUDbuDVClOLBdkyIIOg6+4F65gUM/t88Es1xFL2n7ypv wa3f7ekajUDQNe1L+pZXPExnGbLuJq9KCs7yGp/a138XH5LfmIDI65QuXcjh/HGuixSI 2VfA== X-Gm-Message-State: AOAM532yXcD8JQqMc4FkI8NX998uXqFID/zLVqDT3JKOG/OWtvQpeSHt W6/aq3Ej3zY8QD13wOofRHVn08X8nxAI8w== X-Google-Smtp-Source: ABdhPJw+ooEhAK6jNLCK7kfDz6R/+wGSHCi7ImsRylIQ7yxv50+xkq2QUsZEZcvkh84FmSbb9Gs5qw== X-Received: by 2002:a65:5b05:: with SMTP id y5mr7824597pgq.90.1594978124072; Fri, 17 Jul 2020 02:28:44 -0700 (PDT) Received: from [192.168.0.4] (71-223-3-53.phnx.qwest.net. [71.223.3.53]) by smtp.gmail.com with ESMTPSA id z66sm6932133pfb.162.2020.07.17.02.28.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jul 2020 02:28:43 -0700 (PDT) Subject: Re: URGENT: Microsoft overwrites boot loader! To: Manish Jain , FreeBSD Mailing List , freebsd-stable@freebsd.org References: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> From: Don Wilde Message-ID: Date: Fri, 17 Jul 2020 02:28:42 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4B7QmG13sSz3YHy X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=lLcjovyo; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2607:f8b0:4864:20::543 as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-3.27 / 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:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.33)[-0.327]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FREEMAIL_TO(0.00)[hotmail.com,freebsd.org]; RECEIVED_SPAMHAUS_PBL(0.00)[71.223.3.53:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.96)[-0.958]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::543:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 09:28:47 -0000 On 7/17/20 1:34 AM, Manish Jain wrote: > > > On 2020-07-17 13:57, Don Wilde wrote: >> >> On 7/16/20 7:40 PM, Manish Jain wrote: >>> >>> >>> On 2020-07-17 01:49, Don Wilde wrote: >>>> The [deleted] ones in Redmond have done it again. My multi-OS GRUB2 >>>> boot loader is gone, and in its place is a 500M partition called >>>> 'Windows boot loader'. >>>> >>>> The purpose is to force us to look at MS' new version of Edge. All >>>> my old boot files are gone. >>>> >>>> It's taken me much of the morning to get underneath this, since on >>>> this unit my only OS (other than Doze 10) with a WM and GUI is Ubuntu. >>>> >>>> That's the last time I will allow this, and I'm calling those >>>> [deleted]s tomorrow to give them a piece of my mind. After that I >>>> will erase every vestige of that obscene OS from my disk. >>>> >>> >>> If I understand correctly, it's just that your Grub boot-loader is >>> gone. >>> >> Yes, exactly. >> >> >>> That should not be much of a problem if your system is MBR+BIOS. >>> >> Unfortunately, it's GPT under EFI. I can access all my files through >> the F12 key on this Dell tower, be it Windows, Linux or FreeBSD, but >> if I allow it to boot with the Doze HDD in the system, it boots to >> that one. >>> If your system is MBR+BIOS, the following should work. >>> >>> Boot with your FreeBSD CD/DVD/memstick, and write out boot0 to all >>> your disks: >>> >>> boot0cfg -B /dev/ >>> boot0cfg -B /dev/ >>> boot0cfg -B /dev/ >>> >>> Next, boot with your Ubuntu CD/DVD/memstick, and write out Grub to >>> your Ubuntu / partition. If Ubuntu / is /dev/sdb2 : >>> >>> sudo mount /dev/sdb2 /mnt >>> sudo grub-install --force --root-directory=/mnt /dev/sdb2 >>> >>> Reboot. When booting Ubuntu the first time, first press 'e' at the >>> Grub loader menu to edit the configuration, delete the complete >>> if..fi block, check that your line beginning with 'linux' is >>> accurate and then press F10. Once the system  has booted, run 'sudo >>> update-grub'. >>> >> I appreciate the good data, Manish. I'm going to make sure I've >> gotten all my files off the Doze partition and then wipe it >> completely. FreeBSD is going to be my primary host OS and I'll keep >> my other drive for whatever flavors of Linux I need to work with for >> work. Based on what I've hseen on these threads, MS is still saddled >> with a number of bad legacy architectural choices as well as poor >> management choices, and both of those contribute to the challenges >> the use of their OS brings. >> >> I simply won't accept any contract that requires me to work with >> Windows. I've survived well enough without that skill set and I see >> no problem going forward. >> > > Hi Done, > > It is further my sincere suggestion to use MBR+BIOS. GPT+UEFI is > problem-prone, with one of the problems being that you won't be able > to boot FreeBSD. > I've already seen that one on my 'mule' machine. This tower (a 2007 machine) will boot FreeBSD directly even in UEFI-BIOS mode; I just need to set it up so that FreeBSD also hosts the boot-loader for the other OSen. To use one of my favorite phrases, "We'll get there!" :D -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * **************************************************** From owner-freebsd-stable@freebsd.org Fri Jul 17 09:49:21 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5275A35F678 for ; Fri, 17 Jul 2020 09:49:21 +0000 (UTC) (envelope-from NilsJohannsen@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7RD02j7Vz3Zqf for ; Fri, 17 Jul 2020 09:49:20 +0000 (UTC) (envelope-from NilsJohannsen@gmx.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1594979358; bh=T9LqssQVMIRvNa/1AIAZbI01xdtzXaohC/oFzWg3KD4=; h=X-UI-Sender-Class:From:To:Subject:Date; b=MvwdMynm+DiZ1h4J/8qRGVPiafDaL5VCpu27ASKRMQc6xxMC7R03PMtpPOluquTyL 9zj9bqfFPq4h98fLA6FW4n1gsZP+RUOA8hQ+PxKgFMaUZsakq1u8KirT2DGJMCkZTT wlsKOxjML7TQNNJPva+07QHlaGIp+sUav9C3K+AQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [87.153.209.60] ([87.153.209.60]) by web-mail.gmx.net (3c-app-gmx-bs05.server.lan [172.19.170.54]) (via HTTP); Fri, 17 Jul 2020 11:49:18 +0200 MIME-Version: 1.0 Message-ID: From: Nils Johannsen To: freebsd-stable@freebsd.org Subject: drm i915kms on 12.1-STABLE (r363237) Content-Type: text/plain; charset=UTF-8 Date: Fri, 17 Jul 2020 11:49:18 +0200 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K1:C6QbeduAzeFIwNQG2j7K4eurN2jPZrEFVvlAE0DqwKliWmLNNjhwZLmZbCCydzATuFCaP z+lqpaY2ZQknWXgHjC3tJRPWvSupjV5RboXgMpULQANpTIUUm8NBN/Zao0D9ZD17cuCk47cbT3rV 6T01HOUMNh+x5EIVA2O0tVxFcL+4kK6qNvNTyjTd5IP3WKoGkqLrlJ552NDICV8axTAGyIAZLm+/ 0CQ76rtNHBUOQU8HLALzDPr+L0CtELBCkZswRS22Uhd26kF5OUgzWezf77co8gjWB4NcVM9ao+/M h8= X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:AEH+s28yD0o=:rcy9QecYRs1LlgLWGICdIO X4c62lhdi/cyLKNqOOetUgbincRgNW3ZV6+s1yuIecX2h92YmoV4dH8s3FZQLbT0ahPZ6qwxl rz5K9bkr97zwySLtMVBSo9AUx0s/tzgvyap7fbdXof2/+z4Z24OqMzHOOhDdyuTt5hrwR27vj b1a9DbldooVZga351YC5SSNnZsfdpCp6EooRzKp+dFMWAyv+WM/lV6qhnT6Q3MrdeWF/IxypM xois05rr+ajOxO2QxCFt8zk1y+4wxGbQXvChiIEqWWQ3VO4dmUxww9L+tuS+A7WdMDf6ZjAwR q/8EcFX/RmteJdG+ZWIgLd2E9U3X4dMMs5/BT+ub6ecEQ6fWguQLyDbUeT3upLNArjHm0nyaX /RilfDHqCqRGX2PixCuPa4cUF1KyP2Cqx3zlTD8D1wDVgzk3JxJjzJ2Ap2f0piDB2UI1LMH8o fg3P8otOYZcklo0Q7P4L+rtUXXaKQhNEEAsjU2ew9AMxir83FCqW9Bdm7kyo2ul9AexXXLz3X Eb/ASenRWjYKPTdDOlJLj9jw9ui6kOQC7ml0hDCtQHj9FhjHXOXzu9lhSJbLzZIWKNMEs0XZ8 vz7d8ue7UaKq/2JYdupVp8lviQoMI4PFsR0abAhJET42OSUfp8z+j655opPOJcGH+nR4ZPa0J P0MIxrS0v3ZvwJe3lC6Oys3koeslIyaCvGjArw5mEei55n3hqQ9IHpq3RnJ1N2yRvwp0= X-Rspamd-Queue-Id: 4B7RD02j7Vz3Zqf X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=MvwdMynm; dmarc=none; spf=pass (mx1.freebsd.org: domain of NilsJohannsen@gmx.de designates 212.227.17.22 as permitted sender) smtp.mailfrom=NilsJohannsen@gmx.de X-Spamd-Result: default: False [-2.33 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.22:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmx.de]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gmx.de]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.98)[-0.985]; RECEIVED_SPAMHAUS_PBL(0.00)[87.153.209.60:received]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:212.227.17.0/27]; DKIM_TRACE(0.00)[gmx.net:+]; NEURAL_HAM_SHORT(-0.29)[-0.291]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-0.95)[-0.955]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmx.de]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.22:from] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 09:49:21 -0000 Hi all together, yesterday I installed 12.1-STABLE [1] with kernel version `uname -K` 1201519 on my ThinkPad E490 with 'Intel UHD Graphics 620' [2]. But if I install the 'drm-fbsd12.0-kmod' and load the driver `kldload /boot/modules/i915kms.ko` it will only show a black screen until I manually poweroff the notebook. See the `/var/log/messages` [3] below. The 'drm-fbsd12.0-kmod' from pkg [4] behaves the sames as if I build it manually from ports. On 12.1-RELEASE it worked just fine. Has anybody a hint for me, what might be wrong and how I should deal with it? Regards, Nils [1] FreeBSD-12.1-STABLE-amd64-20200702-r362880-memstick.img [2] pciconf -lv ``` vgapci0@pci0:0:2:0: class=0x030000 card=0x507217aa chip=0x3ea08086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'UHD Graphics 620 (Whiskey Lake)' class = display subclass = VGA ``` [3] /var/log/messages ``` Jul 17 09:13:23 NilsJ-TP kernel: drmn0: on vgapci0 Jul 17 09:13:23 NilsJ-TP kernel: vgapci0: child drmn0 requested pci_enable_io Jul 17 09:13:23 NilsJ-TP syslogd: last message repeated 1 times Jul 17 09:13:23 NilsJ-TP kernel: [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19). Jul 17 09:13:23 NilsJ-TP kernel: Successfully added WC MTRR for [0x90000000-0x9fffffff]: 0; Jul 17 09:13:23 NilsJ-TP kernel: [drm] Got stolen memory base 0x8a800000, size 0x2000000 Jul 17 09:13:23 NilsJ-TP kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Jul 17 09:13:23 NilsJ-TP kernel: [drm] Driver supports precise vblank timestamp query. Jul 17 09:13:23 NilsJ-TP kernel: [drm] Connector eDP-1: get mode from tunables: Jul 17 09:13:23 NilsJ-TP kernel: [drm] - kern.vt.fb.modes.eDP-1 Jul 17 09:13:23 NilsJ-TP kernel: [drm] - kern.vt.fb.default_mode Jul 17 09:14:24 NilsJ-TP syslogd: kernel boot file is /boot/kernel/kernel Jul 17 09:14:24 NilsJ-TP kernel: ---<>--- Jul 17 09:14:24 NilsJ-TP kernel: Copyright (c) 1992-2020 The FreeBSD Project. Jul 17 09:14:24 NilsJ-TP kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 17 09:14:24 NilsJ-TP kernel: The Regents of the University of California. All rights reserved. Jul 17 09:14:24 NilsJ-TP kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jul 17 09:14:24 NilsJ-TP kernel: FreeBSD 12.1-STABLE r363237 GENERIC amd64 ``` [4] pkg info drm-fbsd12.0-kmod ``` drm-fbsd12.0-kmod-4.16.g20200221 Name : drm-fbsd12.0-kmod Version : 4.16.g20200221 Installed on : Fri Jul 17 09:10:42 2020 UTC Origin : graphics/drm-fbsd12.0-kmod Architecture : FreeBSD:12:amd64 Prefix : /usr/local Categories : graphics kld Licenses : BSD2CLAUSE, MIT, GPLv2 Maintainer : x11@FreeBSD.org WWW : https://github.com/FreeBSDDesktop/kms-drm Comment : DRM modules for the linuxkpi-based KMS components Options : DEBUG : off Annotations : FreeBSD_version: 1201000 repo_type : binary repository : FreeBSD ``` From owner-freebsd-stable@freebsd.org Fri Jul 17 11:22:48 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 088B3361A46; Fri, 17 Jul 2020 11:22:48 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) (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 4B7THp4CCyz3gJ4; Fri, 17 Jul 2020 11:22:46 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 8018C5800D9; Fri, 17 Jul 2020 07:22:45 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 17 Jul 2020 07:22:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.dev; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=d XqBLJxQGt3LSBsTNjyCRS3FwbY8py83RWIVI9t0CbM=; b=ewwsWqtij3jf4ZzNM tzxU+Rxc0q2aB3maJjVLGWad9/Rp5ZFwzKCB5LcNWeNiMJ70NcR4nzCWEUGHqrgG u2nRJ9cVlAkcpy0IDrIPF/eGRhmGReF0+N3OErZaoa7Rr1S5Y/PWp435+ZiVQZDC HZkXONtM0tNdEvkMlcaH/Ha2GLLU8joUelVcsHS9Gac0V18DtnJ/YqCTKj0SLRzS 9kbSz3kwa58GYPFp8/4yj+GmJ2H4WT+K1SSzOuKbhDhTdyZn3ilUqZKAp8RUq/Ag td3IVHRhbKCI4CZop2AOiWJaPh9gHgm8fq0U0YRHatiELqJcOvm/5Vats82NUDGW 8caIg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=dXqBLJxQGt3LSBsTNjyCRS3FwbY8py83RWIVI9t0C bM=; b=nFNXM+9NGU4F/C+ngeAbbjIgGlaLLHVoNROYRwma5dsOfDDzkGwmAQ8uc evDFupVDLAMBhZq4BJw/rwseEd4svE9/IrxkJsHQlqox/pbf+vZDFnVqKte1czti znfiIawlZMx3lzr62BCTczLq8Y2/omFH6EEcBNAFaT5A1Abr24MAXDttU/YpmsWo j/O72EMWZfe36YsseSaKzVMvBpkNXY49G17ZoalxhrB14QcPCHxkZ70+pnHYxBRS ZrPAM2gnBQWS+ACa1hI20OqGwIGKkEE16uwaqKA1Y4AtCbKAPFl7sT6evmCeqbup /EeXUPm46dGnP6TB7zB3Dhz1zoHzw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfeeigdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpegjuhhrihcu rfgrnhhkohhvuceohihurhhiphhvseihuhhrihhpvhdruggvvheqnecuggftrfgrthhtvg hrnhepffehvdekgeeijeevledvfffgveeuvefggfejhfelueeuveetvddvvdfgieetffet necukfhppeeluddrvdegtddruddvgedrudefjeenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpeihuhhrihhpvheshihurhhiphhvrdguvghv X-ME-Proxy: Received: from [192.168.1.6] (unknown [91.240.124.137]) by mail.messagingengine.com (Postfix) with ESMTPA id 1EC81306005F; Fri, 17 Jul 2020 07:22:43 -0400 (EDT) Subject: Re: URGENT: Microsoft overwrites boot loader! To: Don Wilde , Polytropon Cc: FreeBSD Mailing List , freebsd-stable@freebsd.org References: <140a6398-f8ad-ecd6-2a6f-5ca28f570a64@gmail.com> <20200717085305.ffd5191c.freebsd@edvax.de> <8158aa31-493c-d316-9dbe-fcf35f569baf@gmail.com> From: Yuri Pankov Message-ID: <49db33f8-3d2d-d8e4-80e8-8226d5a8b717@yuripv.dev> Date: Fri, 17 Jul 2020 14:22:42 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <8158aa31-493c-d316-9dbe-fcf35f569baf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B7THp4CCyz3gJ4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yuripv.dev header.s=fm1 header.b=ewwsWqti; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=nFNXM+9N; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuripv@yuripv.dev designates 66.111.4.229 as permitted sender) smtp.mailfrom=yuripv@yuripv.dev X-Spamd-Result: default: False [-3.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yuripv.dev:s=fm1,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.01)[-1.009]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.229]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[yuripv.dev]; NEURAL_HAM_LONG(-1.01)[-1.009]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yuripv.dev:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.98)[-0.981]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,edvax.de]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[66.111.4.229:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.229:from] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 11:22:48 -0000 Don Wilde wrote: > > On 7/16/20 11:53 PM, Polytropon wrote: >> On Thu, 16 Jul 2020 13:19:51 -0700, Don Wilde wrote: >>> The [deleted] ones in Redmond have done it again. My multi-OS GRUB2 boot >>> loader is gone, and in its place is a 500M partition called 'Windows >>> boot loader'. >> They do this all the time. The consensus here is to install >> "Windows" first, always, restricted to the designated disk >> space, and _then_ install Linux, FreeBSD, GRUB, or anything >> else non-"Windows", in order to avoid the exact problem you >> are describing. Even older versions of "Windows" were known >> to destroy things like the FreeBSD boot manager when they >> are installed as a 2nd choice. MICROS~1 always wants you to >> treat it first class, with golden feet and glockenspiel. >> >> However, is my interpretation correct? Did this happen when >> you _installed_ "Windows" on that machine for the first time, >> or did it happen after you _booted_ an already installed >> instance of "Windows", which then did attack "foreign data" >> on the disk? > This machine still maintains the original Windows installation, first > with W7, and then (finally, bad mistake) upgraded to W10. >>> The purpose is to force us to look at MS' new version of Edge. All my >>> old boot files are gone. >> Something like that should never happen. It's absolutely >> normal that "Windows" installs software without user consent, >> and then presents it prominently in user-configured areas >> such as the desktop, the "Start" menu, or the bottom bar >> (pun absolutely intended), but it should never exceed its >> authority beyong the border of the "Windows" partition, >> which clearly means: "Hands off of Grub partition!" > > Yes. The bastards also screwed up my 128GB backup drive -- again without > asking -- when I left it plugged in during a Doze boot. Y'all must have the special edition of Win10 handed as a punishment to those who likes to hijack questions@ (and now stable@) with "the grass was greener" threads :-) I have never seen it do anything with removable media I have attached, be it FreeBSD, illumos installation usb sticks or hard drives, or simply some data disks. >> >> Especially with "Windows 10", the PC is no longer a PC, >> not a _personal_ computer belonging to the user; it's rather >> a system remotely controlled by MICROS~1, and having installed >> "Windows" and therefore agreed to the terms of usage (EULA), >> there is probably nothing "wrong" with it, because you have >> agreed that they can do whatever they want, and if something >> goes wrong, it's your fault. Legal business as usual. > Yes, agreed. They far outstrip the robber barons of the 1800s in their > greed. Even Carnegie finally discovered a heart beating inside of > himself, and gave us libraries and Napoleon Hill! >> >> Many years (or let's say, decades) I had a similar problem >> with an OS/2 installation: It messed up the system's partition >> table, a system where DOS (not that DOS, the other one) was >> installed, and there was a data loss: Partition D: became C:, >> E: became D:, F: became E:, and C: along with its content >> seemed to be gone. But in the overall "disk space calculation" >> it must still have been on disk, so I used the Norton Disk Editor >> (DISKEDIT.EXE from Norton Utilities, a great product at that >> time!), a handheld calculator and pen & paper to re-calculate >> the correct values for the partition table, entered them, >> rebooted, prayed unto the holy bringer of peace, Alpha-Omega, >> and tadaa, C: was there again, with the correct content. > > I never had that wonderful luxury of being saddled with a "real" IBM > machine or OS/2. One would note that they, too (along with MS, > eventually), are being relegated to the dustbin of history where they > belong. > > [snip] > >>> That's the last time I will allow this, and I'm calling those [deleted]s >>> tomorrow to give them a piece of my mind. After that I will erase every >>> vestige of that obscene OS from my disk. >> They don't mind. They already have your money. And maybe they >> even have your name, address, phone number, credit card number >> or other banking information... > I have a few last resort technologies they *don't* know about, though > they are not worth any more of my time or psychic energy. :D > From owner-freebsd-stable@freebsd.org Fri Jul 17 23:00:30 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0C54337164A for ; Fri, 17 Jul 2020 23:00:30 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7mms1r1Hz4gBK for ; Fri, 17 Jul 2020 23:00:29 +0000 (UTC) (envelope-from dwilde1@gmail.com) Received: by mail-pj1-x1029.google.com with SMTP id f16so7040563pjt.0 for ; Fri, 17 Jul 2020 16:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=e6CAlpmQPNSj2f1IiGlYfrHLYvk6usxkDZubiYdTAcA=; b=ifv3xb5P2CAd/Pl6e12TZZTRcgEQ1CAzErr+W+szm5hutr6qhUsRpvEuAmTKucN3su N2GlyWjbRFT05LzRFpnuR0f1q+RSawKb8S7XvrPlsilWPXms84XiLARGP11jSYoKxB8X B/Y86WM6YgTzjBJt1ruwz3rY03U64bdcELJLEZWG92cEfrRyqWuD9M7S3oeoWVwbvU3g gbsXAqEV2v4UI5SLCY3C/rkh6HbI2m+2/W5WoSJCi6Kdr8UQjvtUOg0+aX/nC3u0X7c7 k1AoihxTqT0OjrlsW9fV3IiSXZOGPYvvNZi1fZIz/3+71VDJYfboclRivaWGqJRT3Pq8 92Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=e6CAlpmQPNSj2f1IiGlYfrHLYvk6usxkDZubiYdTAcA=; b=sKNjlLexmnexz8kSdsvcctWgDs4P26FeKp1MaSJPcypC65QSa4k9l9rPsmyJfYP7O8 r1rCLDbjN9n8ZRj8lqvZsiBpvtnc6I4onx3hKZoGB2UcfeZBLf+hU1JlcXmwTLDEYAgs kUYQl7exKmQHpnyO8XM/Le7OKl1y2xGhvJVdMI5vBNJg/o5YdMhJaSaGEi/ZkDRHbRyT ObQ/+yjaDs0uYfBWsjqROJLcQW0uZJc6Y7/hypIOMTXDpcxdLHgiHr5S1Dfip2dXAHqk LGyFB6heqSLXs/Bh+lqnvjDZq+EUaOvLGhcqV9cdHqEhKEh73UUFO3DYmDs1gHIzN1Lw 66Sg== X-Gm-Message-State: AOAM53262Og9C+MPMZGFtgZCAo8agwJ2cv08tGIje5tJ9dEKEapxF//Q McGg3Co5WJPzc6UZEAmXe+LzDppF2h3pDA== X-Google-Smtp-Source: ABdhPJz3WhgqA6Z2OS2MNxJNMM6qvacVADiHCwy5varHnNNcYax9G/tqWfOforVwj3T1t64qaQWbyQ== X-Received: by 2002:a17:902:9b82:: with SMTP id y2mr9051824plp.314.1595026822224; Fri, 17 Jul 2020 16:00:22 -0700 (PDT) Received: from [192.168.0.4] (184-98-131-150.phnx.qwest.net. [184.98.131.150]) by smtp.gmail.com with ESMTPSA id 144sm8901831pfb.31.2020.07.17.16.00.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jul 2020 16:00:21 -0700 (PDT) To: FreeBSD From: Don Wilde Subject: old kernels disappearing? Message-ID: Date: Fri, 17 Jul 2020 16:00:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 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: 4B7mms1r1Hz4gBK X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=ifv3xb5P; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dwilde1@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) smtp.mailfrom=dwilde1@gmail.com X-Spamd-Result: default: False [-2.64 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.65)[-0.652]; RECEIVED_SPAMHAUS_PBL(0.00)[184.98.131.150:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.012]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.979]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1029:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 23:00:30 -0000 While dealing with the fallout from my MS heartburn, I've noticed something new. I can no longer keep old kernels in /boot/kernel/, at least not with the name kernel.* Is this new behavior or have I made a mistake in my loader.conf? -- Don Wilde **************************************************** * What is the Internet of Things but a system * * of systems including humans? * ****************************************************