Re: testing early microcode loading
On 9/10/18 5:41 PM, Mark Johnston wrote: > On Mon, Sep 10, 2018 at 12:48:56PM -0700, Pete Wright wrote: >> >> On 9/10/18 11:26 AM, Mark Johnston wrote: >>> Hi, >>> >>> Support for boot-time loading of Intel microcode updates has landed in >>> the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. >>> I'd like to solicit some testing of the feature ahead of 12.0. >> Hey there Mark, >> So I've just tested this on a kabylake system running a kernel/world >> from Sept 7th which I believe is recent enough. >> >> After updating /boot/loader.conf as per your email I am not sure if any >> microcode updates are being applied. I'm not seeing any messages >> regarding firmware updates being applied in the dmesg buffer. > Right, we currently print something only if an update was configured > but failed to apply. We should probably print something either way, > perhaps only if the kernel is booted with -v. i could certainly as being helpful for debugging. >> running x86info results in the following: >> >> $ sudo kldload -n cpuctl && sudo x86info -a | grep Micro >> Microcode version: 0x008e >> >> this is after rebooting with the updated loader.conf as well as running >> the rc script by hand. i didn't think to compare the output of x86info >> before running the rc script, i can do that later today. > Thanks. If the boot-time update succeeded, the rc script should have > been a no-op. Can you check for "updating cpu /dev/cpuctl..." messages > in /var/log/messages? That would indicate that the rc script applied an > update, which would imply that the boot-time update failed somehow. when i ran the rc script after boot i saw the CPU related messages in dmesg on the console (CPU count, type, features, etc). i did not see anything in /var/log/messages of interest either. i'll re-test tomorrow when i get back into the office and let you know if i see anything of interest. my plan is to: - boot with the /boot/loader.conf additions for applying microcode and save the output from x86info - boot with loader.conf settings uncommented, view output of x86conf - then run rc script and get output of x86conf -pete -- Pete Wright p...@nomadlogic.org 310.309.9298 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: testing early microcode loading
On Mon, Sep 10, 2018 at 12:48:56PM -0700, Pete Wright wrote: > > > On 9/10/18 11:26 AM, Mark Johnston wrote: > > Hi, > > > > Support for boot-time loading of Intel microcode updates has landed in > > the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. > > I'd like to solicit some testing of the feature ahead of 12.0. > > Hey there Mark, > So I've just tested this on a kabylake system running a kernel/world > from Sept 7th which I believe is recent enough. > > After updating /boot/loader.conf as per your email I am not sure if any > microcode updates are being applied. I'm not seeing any messages > regarding firmware updates being applied in the dmesg buffer. Right, we currently print something only if an update was configured but failed to apply. We should probably print something either way, perhaps only if the kernel is booted with -v. > running x86info results in the following: > > $ sudo kldload -n cpuctl && sudo x86info -a | grep Micro > Microcode version: 0x008e > > this is after rebooting with the updated loader.conf as well as running > the rc script by hand. i didn't think to compare the output of x86info > before running the rc script, i can do that later today. Thanks. If the boot-time update succeeded, the rc script should have been a no-op. Can you check for "updating cpu /dev/cpuctl..." messages in /var/log/messages? That would indicate that the rc script applied an update, which would imply that the boot-time update failed somehow. > for reference here is my dmesg: > https://gist.github.com/nomadlogic/bfc54315b97d374a7818d29bfc93223e ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Request for Review: Generate /etc/services from the IANA registry
On 9/10/18 12:04 PM, Eric van Gyzen wrote: Would anyone like to review this change to generate /etc/services from the IANA registry? https://reviews.freebsd.org/D17106 If that review made your browser unhappy, try this one instead: https://reviews.freebsd.org/D17115 Eric ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
On 9/10/18 10:55 AM, Rodney W. Grimes wrote: >> On 9/10/18 9:51 AM, Rodney W. Grimes wrote: The FreeBSD base system is a reproducible build[1] with a minor exception: the build metadata (timestamps, user, hostname, etc.) included in the kernel and loader. With the default, non-reproducible build the kernel ident looks like: FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 user@hostname:/path/to/freebsd/src and the loader ident: FreeBSD/amd64 EFI loader, Revision 1.1 (Mon Jan 1 10:11:12 EDT 2018 user@hostname) With reproducible builds enabled the kernel ident looks like: FreeBSD 12.0-ALPHA5 r338195 and the loader ident: FreeBSD/amd64 EFI loader, Revision 1.1 I would like to enable the REPRODUCIBLE_BUILD knob by default for the 12.0 release, and propose we do this by adding a step to switch the default to the list of changes[2] that re@ commits to the branch as part of the release process. >>> >>> Why not just turn this on and leave it on? >> >> For kernels not built against a pristine tree the extra info is useful to >> have. For better or worse, kgdb also parses the path to try to find >> kernel.full (used by e.g. 'kgdb -n last'), so if you remove the path it >> won't be able to find the matching kernel using its current logic. > > So this means stable/12 users would have hassles getting kgdb to work? No, this means that if you turn this option on in HEAD and leave it always on (as I read your mail to say), then it would be a hassle for developers on head. On stable branches it would be nice to keep the info if people are building kernels that aren't stock kernels (meaning modified source trees). For release kernels, crashinfo should work fine though even with the extra information stripped. For release builds the information is not really useful, it's only ever useful if someone is building their own kernel for some reason (and even in some of those cases it isn't all that useful). -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: testing early microcode loading
On 9/10/18 11:26 AM, Mark Johnston wrote: Hi, Support for boot-time loading of Intel microcode updates has landed in the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. I'd like to solicit some testing of the feature ahead of 12.0. The port has been modified to install /boot/firmware/intel-ucode.bin. This file contains a copy of every Intel microcode update supplied by the port. Per the pkg-message, one can enable early loading of this file by specifying: cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin" in loader.conf. The update will be applied upon a subsequent reboot. Testing consists of enabling early loading and verifying that the CPUs report an updated microcode version. If early loading fails, a message is printed to the dmesg. If your system is capable of successful ACPI suspend/resume, it is useful to also verify that the microcode remains updated following a resume. To fetch the current microcode version, use sysutils/x86info: # kldload -n cpuctl && x86info -a | grep Micro Microcode version: 0x0020 Compare with the version installed by the microcode_update rc script at run-time: # service microcode_update onestart Updating CPU Microcode... Done. # kldload -n cpuctl && x86info -a | grep Micro Microcode version: 0x0020 If your testing indicates that the boot-time loading method doesn't work, please include the dmesg in your reply. Thanks in advance. Hey there Mark, So I've just tested this on a kabylake system running a kernel/world from Sept 7th which I believe is recent enough. After updating /boot/loader.conf as per your email I am not sure if any microcode updates are being applied. I'm not seeing any messages regarding firmware updates being applied in the dmesg buffer. running x86info results in the following: $ sudo kldload -n cpuctl && sudo x86info -a | grep Micro Microcode version: 0x008e this is after rebooting with the updated loader.conf as well as running the rc script by hand. i didn't think to compare the output of x86info before running the rc script, i can do that later today. for reference here is my dmesg: https://gist.github.com/nomadlogic/bfc54315b97d374a7818d29bfc93223e Cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
On 10 September 2018 at 14:52, Ed Maste wrote: > > I brought this up on -arch in 2015... That said, the kgdb -n issue was brought up in the old thread and it seems I did forget about it. I don't think we should cater too much to the needs of the deprecated in-tree kgdb, but we should make sure that this works with kgdb from the port. There are now standardized ways to specify this information that we should migrate to, rather than the current approach. Note that here I'm really only interested in what we do for FreeBSD binary releases, and the path for kgdb -n etc. isn't really relevant in this case. Src tree defaults are in scope only because release settings and src tree defaults are coupled. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
On 10 September 2018 at 13:57, Rodney W. Grimes wrote: >> >> I know a number of developers want to keep the metadata for their own >> builds at least. > > And we do not really know what the users position is on this... If users are building FreeBSD from source they can set the knob however they like. Users of our prebuilt binares/releases are the ones who benefit from reproducible builds, and they're the ones unable to set it. > I think there is more discussion to be had before we flip > this knob anyplace. I brought this up on -arch in 2015, and gave presentations on reproducible builds in FreeBSD at BSDCan 2016 and AsiaBSDCon 2017. I believe we've had ample opportunity to discuss this in the context of what makes sense in a binary release, but there are still reasonable open questions about defaults in HEAD. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
testing early microcode loading
Hi, Support for boot-time loading of Intel microcode updates has landed in the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. I'd like to solicit some testing of the feature ahead of 12.0. The port has been modified to install /boot/firmware/intel-ucode.bin. This file contains a copy of every Intel microcode update supplied by the port. Per the pkg-message, one can enable early loading of this file by specifying: cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin" in loader.conf. The update will be applied upon a subsequent reboot. Testing consists of enabling early loading and verifying that the CPUs report an updated microcode version. If early loading fails, a message is printed to the dmesg. If your system is capable of successful ACPI suspend/resume, it is useful to also verify that the microcode remains updated following a resume. To fetch the current microcode version, use sysutils/x86info: # kldload -n cpuctl && x86info -a | grep Micro Microcode version: 0x0020 Compare with the version installed by the microcode_update rc script at run-time: # service microcode_update onestart Updating CPU Microcode... Done. # kldload -n cpuctl && x86info -a | grep Micro Microcode version: 0x0020 If your testing indicates that the boot-time loading method doesn't work, please include the dmesg in your reply. Thanks in advance. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
> On 10 September 2018 at 12:51, Rodney W. Grimes > wrote: > > > > Why not just turn this on and leave it on? > > I know a number of developers want to keep the metadata for their own > builds at least. And we do not really know what the users position is on this... and developers also run on stable/X, they may not like this flipped there, though IMHO we should not be catering so much to developers, while shooting users. > > We have essentially three different levels of metadata that are > arguably sensible: > > 1. Major/minor version, release/branch name, architecture > 2. Version control information > 3. Path, user, date, time, host > > And three kinds of working trees: > > 1. Non-versioned with/without modifications (e.g., a src tarball) > 2. git/svn/other checkout, without modifications > 3. git/svn/other checkout, with modifications > > What I'm proposing for 12.0 gives us 1+2 always (regardless of the > state of the tree). > > I think there's more discussion to be had on the mapping between the > tree type/state and amount of metadata to include. If we come to a > consensus I'll handle it, but don't want to hold up a change destined > for 12.0 with a broader discussion. I think there is more discussion to be had before we flip this knob anyplace. -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
> On 9/10/18 9:51 AM, Rodney W. Grimes wrote: > >> The FreeBSD base system is a reproducible build[1] with a minor > >> exception: the build metadata (timestamps, user, hostname, etc.) > >> included in the kernel and loader. > >> > >> With the default, non-reproducible build the kernel ident looks like: > >> > >> FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 > >>user@hostname:/path/to/freebsd/src > >> > >> and the loader ident: > >> > >> FreeBSD/amd64 EFI loader, Revision 1.1 > >> (Mon Jan 1 10:11:12 EDT 2018 user@hostname) > >> > >> With reproducible builds enabled the kernel ident looks like: > >> > >> FreeBSD 12.0-ALPHA5 r338195 > >> > >> and the loader ident: > >> > >> FreeBSD/amd64 EFI loader, Revision 1.1 > >> > >> I would like to enable the REPRODUCIBLE_BUILD knob by default for the > >> 12.0 release, and propose we do this by adding a step to switch the > >> default to the list of changes[2] that re@ commits to the branch as > >> part of the release process. > > > > Why not just turn this on and leave it on? > > For kernels not built against a pristine tree the extra info is useful to > have. For better or worse, kgdb also parses the path to try to find > kernel.full (used by e.g. 'kgdb -n last'), so if you remove the path it > won't be able to find the matching kernel using its current logic. So this means stable/12 users would have hassles getting kgdb to work? > crashinfo uses different logic so will still work fine (crashinfo looks > for all the things matching /boot/*/kernel and tries them all until it finds > a match). > > -- > John Baldwin > > > -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
On 10 September 2018 at 12:51, Rodney W. Grimes wrote: > > Why not just turn this on and leave it on? I know a number of developers want to keep the metadata for their own builds at least. We have essentially three different levels of metadata that are arguably sensible: 1. Major/minor version, release/branch name, architecture 2. Version control information 3. Path, user, date, time, host And three kinds of working trees: 1. Non-versioned with/without modifications (e.g., a src tarball) 2. git/svn/other checkout, without modifications 3. git/svn/other checkout, with modifications What I'm proposing for 12.0 gives us 1+2 always (regardless of the state of the tree). I think there's more discussion to be had on the mapping between the tree type/state and amount of metadata to include. If we come to a consensus I'll handle it, but don't want to hold up a change destined for 12.0 with a broader discussion. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'
On 9/8/18 1:44 PM, Michael Butler wrote: > On 9/8/18 3:43 PM, Konstantin Belousov wrote: >> On Sat, Sep 08, 2018 at 02:07:41PM -0400, Michael Butler wrote: >>> On 8/31/18 1:28 AM, Konstantin Belousov wrote: On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote: >>> >>> [ .. snip .. ] >>> > I see another problem after using Ian's workaround of moving the #ifdef > SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) > machine with only 512MB of RAM: > > Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed > Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed > Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed > Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed > Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed > Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed What is the kernel revision for "now". What was the previous revision where the kstack allocation failures did not happen. Also, what is the workload ? >>> >>> Sorry for the delay. Any version at or after SVN r338360 would either a) >>> not boot at all or b) crash shortly after boot with a swarm of messages >>> as above. It was stable before that. >>> >>> Unfortunately, this machine is remote and, being as old as it is, has no >>> remote console facility. 'nextboot' has been my savior ;-) >>> >>> It is a 700MHz Pentium-III with 512MB of RAM and has 3 used interfaces, >>> local ethernet (FXP), GIF for an IPv6 tunnel to HE and TAP for an >>> OpenVPN endpoint. It has IPFW compiled into the kernel and acts as a >>> router/firewall with few actual applications running. >>> >>> As another data point, I manually reversed both SVN r338360 and r338415 >>> (a related change) and it is now stable running at SVN r338520, >> >> It is very unprobable. I do not see how could r338360 affect KVA allocation. >> Double-check that you booted right kernels. >> > > FreeBSD sarah.protected-networks.net 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #14 > r338520M: Thu Sep 6 21:35:31 EDT 2018 > > 'svn diff' reports the only changes being the two reversals I noted above, Can you get the output of 'x num_io_irqs' at the DDB prompt after the panic? -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
On 9/10/18 9:51 AM, Rodney W. Grimes wrote: >> The FreeBSD base system is a reproducible build[1] with a minor >> exception: the build metadata (timestamps, user, hostname, etc.) >> included in the kernel and loader. >> >> With the default, non-reproducible build the kernel ident looks like: >> >> FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 >>user@hostname:/path/to/freebsd/src >> >> and the loader ident: >> >> FreeBSD/amd64 EFI loader, Revision 1.1 >> (Mon Jan 1 10:11:12 EDT 2018 user@hostname) >> >> With reproducible builds enabled the kernel ident looks like: >> >> FreeBSD 12.0-ALPHA5 r338195 >> >> and the loader ident: >> >> FreeBSD/amd64 EFI loader, Revision 1.1 >> >> I would like to enable the REPRODUCIBLE_BUILD knob by default for the >> 12.0 release, and propose we do this by adding a step to switch the >> default to the list of changes[2] that re@ commits to the branch as >> part of the release process. > > Why not just turn this on and leave it on? For kernels not built against a pristine tree the extra info is useful to have. For better or worse, kgdb also parses the path to try to find kernel.full (used by e.g. 'kgdb -n last'), so if you remove the path it won't be able to find the matching kernel using its current logic. crashinfo uses different logic so will still work fine (crashinfo looks for all the things matching /boot/*/kernel and tries them all until it finds a match). -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Request for Review: Generate /etc/services from the IANA registry
Would anyone like to review this change to generate /etc/services from the IANA registry? https://reviews.freebsd.org/D17106 Thanks, Eric ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
> The FreeBSD base system is a reproducible build[1] with a minor > exception: the build metadata (timestamps, user, hostname, etc.) > included in the kernel and loader. > > With the default, non-reproducible build the kernel ident looks like: > > FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 >user@hostname:/path/to/freebsd/src > > and the loader ident: > > FreeBSD/amd64 EFI loader, Revision 1.1 > (Mon Jan 1 10:11:12 EDT 2018 user@hostname) > > With reproducible builds enabled the kernel ident looks like: > > FreeBSD 12.0-ALPHA5 r338195 > > and the loader ident: > > FreeBSD/amd64 EFI loader, Revision 1.1 > > I would like to enable the REPRODUCIBLE_BUILD knob by default for the > 12.0 release, and propose we do this by adding a step to switch the > default to the list of changes[2] that re@ commits to the branch as > part of the release process. Why not just turn this on and leave it on? > > [1] https://reproducible-builds.org > [2] > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-releng/releng-head.html -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
a little secret info on AZURE VMs..
Apparently if you publish an Azure image to their marketplace, they blindly store billing information at location 65536 of the VHD file.. so you need to ensure that your first partitions start after that. if you use a layout with your first partition starting at 64 sectors in, this location falls in the middle of your boot code. So it fails to boot. I haven't found any documentation of this yet.. Julian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make packages fails recent -current
2018-09-10 17:45 GMT+02:00 Andreas Nilsson : > Hello, > > I have for about a week been trying to get new (base)packages built. make > buildworld/buildkernel works as expected, however make packages has been > failing: > > ===> Creating FreeBSD-runtime-12.0.s20180910124534 > pkg: duplicate directory listing: /boot, ignoring > pkg: duplicate directory listing: /etc, ignoring > ... > pkg: duplicate directory listing: /etc/syslog.d, ignoring > pkg: duplicate directory listing: /root, ignoring > pkg: duplicate directory listing: /root, ignoring > pkg: duplicate directory listing: /root, ignoring > pkg: Plist error, @config /root/.cshrc: not a regular file > pkg: Plist error, @config /root/.profile: not a regular file > pkg: duplicate file listing: /usr/bin/zstdegrep, ignoring > pkg: duplicate directory listing: /usr/lib, ignoring > pkg: duplicate directory listing: /usr/lib/dtrace, ignoring > pkg: duplicate directory listing: /usr/lib/dtrace, ignoring > pkg: duplicate directory listing: /usr/lib32, ignoring > ... > > Is anyone else seeing this? This is on git 4e22ee37542 . I use metamode for > building. I'm currently building from scratch just to rule out metamode. > See https://lists.freebsd.org/pipermail/freebsd-pkgbase/2018-September/000383.html ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
make packages fails recent -current
Hello, I have for about a week been trying to get new (base)packages built. make buildworld/buildkernel works as expected, however make packages has been failing: ===> Creating FreeBSD-runtime-12.0.s20180910124534 pkg: duplicate directory listing: /boot, ignoring pkg: duplicate directory listing: /etc, ignoring ... pkg: duplicate directory listing: /etc/syslog.d, ignoring pkg: duplicate directory listing: /root, ignoring pkg: duplicate directory listing: /root, ignoring pkg: duplicate directory listing: /root, ignoring pkg: Plist error, @config /root/.cshrc: not a regular file pkg: Plist error, @config /root/.profile: not a regular file pkg: duplicate file listing: /usr/bin/zstdegrep, ignoring pkg: duplicate directory listing: /usr/lib, ignoring pkg: duplicate directory listing: /usr/lib/dtrace, ignoring pkg: duplicate directory listing: /usr/lib/dtrace, ignoring pkg: duplicate directory listing: /usr/lib32, ignoring ... Is anyone else seeing this? This is on git 4e22ee37542 . I use metamode for building. I'm currently building from scratch just to rule out metamode. Best regards Andreas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
Hi Ed, I think that sounds great. In the future, could we go even further and, by default, only emit date/user/path if the source tree is “dirty” with respect to SVN? If the build really is reproducible, that data should only be informative when building something that doesn’t match a FreeBSD SVN revision (e.g., a Git commit in a local repo or a tree with local changes). Cheers, Jon -- jonat...@freebsd.org On 10 Sep 2018, at 12:26, Ed Maste wrote: The FreeBSD base system is a reproducible build[1] with a minor exception: the build metadata (timestamps, user, hostname, etc.) included in the kernel and loader. With the default, non-reproducible build the kernel ident looks like: FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 user@hostname:/path/to/freebsd/src and the loader ident: FreeBSD/amd64 EFI loader, Revision 1.1 (Mon Jan 1 10:11:12 EDT 2018 user@hostname) With reproducible builds enabled the kernel ident looks like: FreeBSD 12.0-ALPHA5 r338195 and the loader ident: FreeBSD/amd64 EFI loader, Revision 1.1 I would like to enable the REPRODUCIBLE_BUILD knob by default for the 12.0 release, and propose we do this by adding a step to switch the default to the list of changes[2] that re@ commits to the branch as part of the release process. [1] https://reproducible-builds.org [2] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-releng/releng-head.html ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
On 10 September 2018 at 11:11, Jonathan Anderson wrote: > Hi Ed, > > I think that sounds great. In the future, could we go even further and, by > default, only emit date/user/path if the source tree is “dirty” with respect > to SVN? If the build really is reproducible, that data should only be > informative when building something that doesn’t match a FreeBSD SVN > revision (e.g., a Git commit in a local repo or a tree with local changes). Indeed, and I already have that support in newvers.sh: -r means build reproducibly and -R means build reproducibly if the source tree represents an unmodified checkout from a version control system. It's currently not hooked up to a src.conf knob, and we don't really have a great way to handle options with more than two states. We could have REPRODUCIBLE_BUILD always on by default, using the -R mode - something to revisit after we're done with the 12.0 process. Also, note that the build will currently not be reproducible between svn/git/tarball because the version control info is included in the ident strings. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
On Mon, Sep 10, 2018 at 8:58 AM Ed Maste wrote: > The FreeBSD base system is a reproducible build[1] with a minor > exception: the build metadata (timestamps, user, hostname, etc.) > included in the kernel and loader. > > With the default, non-reproducible build the kernel ident looks like: > > FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 >user@hostname:/path/to/freebsd/src > > and the loader ident: > > FreeBSD/amd64 EFI loader, Revision 1.1 > (Mon Jan 1 10:11:12 EDT 2018 user@hostname) > > With reproducible builds enabled the kernel ident looks like: > > FreeBSD 12.0-ALPHA5 r338195 > > and the loader ident: > > FreeBSD/amd64 EFI loader, Revision 1.1 > > I would like to enable the REPRODUCIBLE_BUILD knob by default for the > 12.0 release, and propose we do this by adding a step to switch the > default to the list of changes[2] that re@ commits to the branch as > part of the release process. > > [1] https://reproducible-builds.org > [2] > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-releng/releng-head.html Turning it on, like we turn off WITNESS, for stable branches, I think this is a good idea. The loader doesn't really need the extra stuff to function properly, so dropping it is OK. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
The FreeBSD base system is a reproducible build[1] with a minor exception: the build metadata (timestamps, user, hostname, etc.) included in the kernel and loader. With the default, non-reproducible build the kernel ident looks like: FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018 user@hostname:/path/to/freebsd/src and the loader ident: FreeBSD/amd64 EFI loader, Revision 1.1 (Mon Jan 1 10:11:12 EDT 2018 user@hostname) With reproducible builds enabled the kernel ident looks like: FreeBSD 12.0-ALPHA5 r338195 and the loader ident: FreeBSD/amd64 EFI loader, Revision 1.1 I would like to enable the REPRODUCIBLE_BUILD knob by default for the 12.0 release, and propose we do this by adding a step to switch the default to the list of changes[2] that re@ commits to the branch as part of the release process. [1] https://reproducible-builds.org [2] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-releng/releng-head.html ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
