Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64
On 10 Jan 2018, at 18:53, Baptiste Daroussin wrote: > > I need to figure out a mechanism to make this simpler to handle to upgrade of > base system while keeping this safety belt for users. > > Any idea is welcome I believe the apt approach to this is to have a different verb (distupgrade vs upgrade) to perform complete version upgrades. Ideally, the proper fix would probably be to depend on a base package version, rather than OSVERSION, and if the base packages are not being used to synthesise a phantom set of base package metadata based on OSVERSION. David ___ 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: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64
On Wed, 2018-01-10 at 19:53 +0100, Baptiste Daroussin wrote: > On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote: > > > > Hi All, > > > > I use self built base packages. Seems that I have a problem with pkg. > > Today I've got this: > > === > > % sudo pkg update -f > > Updating FreeBSD-base repository catalogue... > > Fetching meta.txz: 100%268 B 0.3kB/s00:01 > > Fetching packagesite.txz: 100% 29 KiB 29.4kB/s00:01 > > Processing entries: 0% > > pkg: Newer FreeBSD version for package FreeBSD-libulog: > > - package: 1200055 > > - running kernel: 1200054 > > pkg: repository FreeBSD-base contains packages for wrong OS version: > > FreeBSD:12:amd64 > > Processing entries: 100% > > Unable to update repository FreeBSD-base > > [...] > > > > % uname -aKU > > FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327719: Tue Jan > > 9 14:32:13 MSK 2018 > > bsam@builder.bsnet:/usr/obj/usr/src/amd64.amd64/sys/PKG64X amd64 > > 1200054 1200054 > > > > % pkg -v > > 1.10.4 > > > hum > > pkg now has a mechanism to protect from installing too new package (aka > packages > built on a more recent system than the system you are running on. > > While this is great for ports this is a bit painful for upgrading base > packages > when building on current > > One has to specify pkg -o OSVERSION=1200055 to allow packages built on 1200055 > to install on 1200054. > > I need to figure out a mechanism to make this simpler to handle to upgrade of > base system while keeping this safety belt for users. > > Any idea is welcome > > Best regards, > Bapt Is this new mechanism disabled if installing into something other than the live system, such as when using -c or -r (and maybe -j)? -- Ian ___ 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: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64
On Thu, Jan 11, 2018 at 08:57:34AM -0700, Ian Lepore wrote: > On Wed, 2018-01-10 at 19:53 +0100, Baptiste Daroussin wrote: > > On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote: > > > > > > Hi All, > > > > > > I use self built base packages. Seems that I have a problem with pkg. > > > Today I've got this: > > > === > > > % sudo pkg update -f > > > Updating FreeBSD-base repository catalogue... > > > Fetching meta.txz: 100%268 B 0.3kB/s00:01 > > > Fetching packagesite.txz: 100% 29 KiB 29.4kB/s00:01 > > > Processing entries: 0% > > > pkg: Newer FreeBSD version for package FreeBSD-libulog: > > > - package: 1200055 > > > - running kernel: 1200054 > > > pkg: repository FreeBSD-base contains packages for wrong OS version: > > > FreeBSD:12:amd64 > > > Processing entries: 100% > > > Unable to update repository FreeBSD-base > > > [...] > > > > > > % uname -aKU > > > FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327719: Tue Jan > > > 9 14:32:13 MSK 2018 > > > bsam@builder.bsnet:/usr/obj/usr/src/amd64.amd64/sys/PKG64X amd64 > > > 1200054 1200054 > > > > > > % pkg -v > > > 1.10.4 > > > > > hum > > > > pkg now has a mechanism to protect from installing too new package (aka > > packages > > built on a more recent system than the system you are running on. > > > > While this is great for ports this is a bit painful for upgrading base > > packages > > when building on current > > > > One has to specify pkg -o OSVERSION=1200055 to allow packages built on > > 1200055 > > to install on 1200054. > > > > I need to figure out a mechanism to make this simpler to handle to upgrade > > of > > base system while keeping this safety belt for users. > > > > Any idea is welcome > > > > Best regards, > > Bapt > > Is this new mechanism disabled if installing into something other than > the live system, such as when using -c or -r (and maybe -j)? > The new mechanism grab the information from the files in the userland, meaning, -c, -r and -j will discover the OSVERSION of the target binaries Bapt signature.asc Description: PGP signature
[CFT] AMD cpu microcode update port sysutils/devcpu-data D13832
https://reviews.freebsd.org/D13832 <--- test this update I'd like to get some feedback from AMD cpu users on this update. I've restructured and undone a few things that may have been keeping folks using this port from getting their runtime cpu microcode updates. After installing the port, grab your microcode version via sysutils/x86info. If you don't see an update, that only means there is no update available for your system. x86info -a | grep Microcode Run the microcode_update and repeat. Check /var/log/messages for a notification that the code was updated. You should be able to get something like the following for your system if it executed an update: root@lab:/home/sbruno # x86info -a | grep "CPU Model" CPU Model (x86info's best guess): AMD FX Series Processor (OR-B2) root@lab:/home/sbruno # x86info -a | grep Microcode Microcode patch level: 0x6000629 root@lab:/home/sbruno # /usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Done. root@lab:/home/sbruno # x86info -a | grep Microcode Microcode patch level: 0x600063d root@lab:/home/sbruno # grep microcode_update /var/log/messages Jan 10 16:52:26 lab microcode_update: /usr/local/share/cpucontrol/microcode_amd_fam15h.bin: updating cpu /dev/cpuctl0 to revision 0x600063d... done. signature.asc Description: OpenPGP digital signature
FINAL CALL for 2017Q4 quarterly status reports
Dear FreeBSD Community, This is the last call for submissions for the 2017Q4 FreeBSD Quarterly Status Update. The deadline for submissions is January 14, 2018, for work done in October through December. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at mont...@freebsd.org . (Do be sure, though, to save the form output and not the form itself! In particular, the Google Chrome "save as" function does not save the generated output for some reason.) There is also an XML template [2] that can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We look forward to seeing your 2017Q4 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2017-07-2017-09.html [5] https://www.FreeBSD.org/news/status/report-2017-04-2017-06.html signature.asc Description: PGP signature
Re: Intel CPU design flaw - FreeBSD affected? [AMD family Zen/17h status]
On 2018-Jan-6, at 2:02 PM, Mark Millard wrote: > On 2018-Jan-4, at 7:32 PM, Mark Millard wrote: > >> Darren Reed darrenr at freebsd.org wrote on >> Thu Jan 4 11:56:29 UTC 2018 : >> >>> Most people are only talking about meltdown which doesn't hit AMD. >>> spectre impacts *both* Intel and AMD. >>> >>> SuSE are making available a microcode patch for AMD 17h processors that >>> disables branch prediction: >>> >>> >>> https://lists.opensuse.org/opensuse-security-announce/2018-01/msg4.html >> >> https://www.amd.com/en/corporate/speculative-execution >> >> reports. . . >> >> For the Bounds Check Bypass Spectre variant (#1): >> >> Resolved by software / OS updates to be made available >> by system vendors and manufacturers. Negligible performance >> impact expected. >> >> For the Branch Target Injection Spectre variant (#2): >> >> Differences in AMD architecture mean there is a near zero >> risk of exploitation of this variant. Vulnerability to >> Variant 2 has not been demonstrated on AMD processors to >> date. >> >> For the Rogue Data Cache Load Meltdown variant (#3): >> >> Zero AMD vulnerability due to AMD architecture differences. >> >> >> >> How long #2 will have a "has not been demonstrated" status >> is yet to be seen. > > https://www.phoronix.com/scan.php?page=news_item&px=AMD-Branch-Prediction-Still > > reports that SUSE's microcode update for AMD's Zen/17h does > not disable branch prediction, despite SUSE's existing > description: > > QUOTE > I reached out to AMD and on Friday heard back. They wrote in an email > to Phoronix that this Zen/17h microcode update does not disable branch > prediction. They'll be working with SUSE to re-clarify this microcode > update description... But as far as what this microcode update does in > the wake of SPECTRE they have yet to clarify or why this microcode > binary has yet to make it to other Linux distributions. If/when I hear > anything more, I'll certainly post about it but doesn't appear to be > anything as dramatic as disabling branch prediction, which could have > slaughtered their CPU performance. > END QUOTE https://www.amd.com/en/corporate/speculative-execution has been updated and amd no longer claims that #2 has not been demonstrated. They state there will be microcode updates for it: QUOTE AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks. END QUOTE === Mark Millard markmi at dsl-only.net ___ 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"
/usr/bin/ld: error: cannot open crt1.o: No such file or directory
When building just checked out sources of Revision: 327866 and try to buildworld with WITH_LLD_IS_LD and/(or not) set WITH_LLD_BOOTSTRAP AND with make -j X, X>1, the build process fails on several CURRENT systems right now with musterious errors regarding crt1.o missing or not linkable: [...] /usr/bin/ld: error: cannot open crt1.o: No such file or directory --- _bootstrap-tools-usr.bin/fortune/strfile --- cc: error: linker command failed with exit code 1 (use -v to see invocation) I tried to compile with "make buildworld" (not parallel builds) and it seems, that the buildworld process is proceeding. Kind regards, oh ___ 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"
