Re: 12-STABLE uname -a misses timestamp of the build
Jakub Lach wrote: > Is there a way to restore it? I liked the old behaviour better, it was useful > info for me. See 20180913 in UPDATING and WITHOUT_REPRODUCIBLE_BUILD in src.conf(5). signature.asc Description: OpenPGP digital signature
Re: 12-STABLE uname -a misses timestamp of the build
That was very helpful, thank you very much :) -- Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-stable-f3932046.html ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
bsdtar: xz threads support disabled
Is there any reason why bsdtar is built without XZ multi-threading support? It's not documented in the man page, so maybe it's an experimental feature. Can be tested with this command: tar -Jcf /dev/null --options xz:threads=4 $HOME After setting HAVE_LZMA_STREAM_ENCODER_MT, it works as expected: Index: lib/libarchive/Makefile === --- lib/libarchive/Makefile (revision 340812) +++ lib/libarchive/Makefile (working copy) @@ -7,7 +7,7 @@ LIB= archive LIBADD=z bz2 lzma bsdxml -CFLAGS+= -DHAVE_BZLIB_H=1 -DHAVE_LIBLZMA=1 -DHAVE_LZMA_H=1 +CFLAGS+= -DHAVE_BZLIB_H=1 -DHAVE_LIBLZMA=1 -DHAVE_LZMA_H=1 -DHAVE_LZMA_STREAM_ENCODER_MT=1 # FreeBSD SHLIB_MAJOR value is managed as part of the FreeBSD system. # It has no real relation to the libarchive version number. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
12-STABLE uname -a misses timestamp of the build
Is there a way to restore it? I liked the old behaviour better, it was useful info for me. -- Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-stable-f3932046.html ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12-STABLE uname -a misses timestamp of the build
WITHOUT_REPRODUCIBLE_BUILD should be default for now on stable/12, as releng/12.0 already branched. As I already proposed on -current ML, REPRODUCIBLE_BUILD should be enabled only for release/* and releng/*. https://lists.freebsd.org/pipermail/freebsd-current/2018-September/071151.html I didn't noticed as I have WITHOUT_REPRODUCIBLE_BUILD=yes in src.conf. On Sat, 24 Nov 2018 15:13:15 +0300 Yuri Pankov wrote: > Jakub Lach wrote: > > Is there a way to restore it? I liked the old behaviour better, it was > > useful > > info for me. > > See 20180913 in UPDATING and WITHOUT_REPRODUCIBLE_BUILD in src.conf(5). > -- Tomoaki AOKI ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
"sockstat: struct xinpgen size mismatch" in 11.2-p4 jail on 12-STABLE host
I updated a system yesterday to the latest 12-STABLE as part of the upcoming 12-RELEASE cycle. I've installed several BETA and at least one RC of 12 since updating from 11-STABLE as part of the 12 cycle and have had no problems up to now. Currently, I am at FreeBSD 12.0-PRERELEASE r340834 GENERIC amd64. Since the most recent update, I have been getting this error when I invoke "sockstat" in any of the jails running on the system: sockstat: struct xinpgen size mismatch The jails are managed via iocage and all are running 11.2-RELEASE-p4, which is the most up-to-date version of 11.2-RELEASE. Has anyone encountered this error? Unfortunately, it means that it breaks Salt, which is what I use to help manage the jails. Sockstat works fine on the host, just not in the jails. I am using a GENERIC kernel which includes "options COMPAT_FREEBSD11". I assumed this would allow FreeBSD 11 binaries to work on a FreeBSD 12 kernel, which it has done up to now. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SCSI and dmesg
Warner Losh wrote: > Greetings > > a few weeks ago I pointed people to the nycbug dmesg service. I said I was > looking at data to drive SCSI retirement. I've gatherd some preliminary > data, which I've uploaded to > https://github.com/bsdimp/device-data/blob/master/cam.md along with some > preliminary notions of disposition for the hardware. I'm still working out > the kinks in the dmesg parsing, but this is interesting data. > > If you've not recently submitted, please consider doing so. We'll be > finalizing the scsi SIMs that I'm going to propose retiring in 13 here in a > few weeks, and I'm going to base much of what list I come up with based on > what is submitted. The glitches with FreeBSD dmesgs have been cleared up as > well. > > http://dmesgd.nycbug.org/index.cgi > > or > > curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d > "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) $(kenv > smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@ > /var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi Got another system to submit, but continuously getting "500 Internal Server Error" using the curl one-liner. dmesg.boot attached in case it's the source of the problem. ---<>--- Copyright (c) 1992-2018 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 13.0-CURRENT r340744 GENERIC-NODEBUG amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) VT(efifb): resolution 3440x1440 CPU: Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz (3504.14-MHz K8-class CPU) Origin="GenuineIntel" Id=0x806e9 Family=0x6 Model=0x8e Stepping=9 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c67af Structured Extended Features3=0x9c00 XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16472522752 (15709 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads random: unblocking device. ioapic0 irqs 0-119 on motherboard Launching APs: 1 3 2 Timecounter "TSC-low" frequency 1752072050 Hz quality 1000 random: entropy device external interface [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0x8113f150, 0) error 19 kbd0 at kbdmux0 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" netmap: loaded module nexus0 efirtc0: on motherboard efirtc0: registered as a time-of-day clock, resolution 1.00s cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 2400 Hz quality 950 Event timer "HPET" frequency 2400 Hz quality 550 Event timer "HPET1" frequency 2400 Hz quality 440 Event timer "HPET2" frequency 2400 Hz quality 440 Event timer "HPET3" frequency 2400 Hz quality 440 Event timer "HPET4" frequency 2400 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf03f mem 0x2ffe00-0x2ffeff,0x2f-0x2f7fff at device 2.0 on pci0 vgapci0: Boot video device xhci0: mem 0x2fff01-0x2fff01 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 pci0: at device 22.0 (no driver attached) ahci0: port 0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xde424000-0xde425fff,0xde427000-0xde4270ff,0xde426000-0xde4267ff at device 23.0 on pci0 ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 pcib1: at device 28.0 on pci0 pcib1: [GIANT-LOCKED] pcib2: at device 28.5 on pci0 pci1: on pcib2 pci1: at device 0.0 (no driver attached) pcib3: at device 28.7 on pci0 pci2: on pcib3 pci2: at device 0.0 (no driver attached) pcib4: at device 29.0 on pci0 pci3: on pcib4 nvme0: mem 0xde10-0xde103fff at device 0.0 on pci3 isab0: at device 31.0 on pci0 isa0: on isab0 pci0: at device 31.2 (no driver attached) hdac0: mem 0x2fff02-0x2fff023fff,0x2fff00-0x2fff00 at device 31.3 on pci0 em0: mem 0xde40-0xde41 at device 31.6 on pci0
FreeBSD 12.0-RC2 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The second RC build of the 12.0-RELEASE release cycle is now available. Installation images are available for: o 12.0-RC2 amd64 GENERIC o 12.0-RC2 i386 GENERIC o 12.0-RC2 powerpc GENERIC o 12.0-RC2 powerpc64 GENERIC64 o 12.0-RC2 powerpcspe MPC85XXSPE o 12.0-RC2 sparc64 GENERIC o 12.0-RC2 armv6 RPI-B o 12.0-RC2 armv7 BANANAPI o 12.0-RC2 armv7 BEAGLEBONE o 12.0-RC2 armv7 CUBIEBOARD o 12.0-RC2 armv7 CUBIEBOARD2 o 12.0-RC2 armv7 CUBOX-HUMMINGBOARD o 12.0-RC2 armv7 PANDABOARD o 12.0-RC2 armv7 WANDBOARD o 12.0-RC2 armv7 GENERICSD o 12.0-RC2 aarch64 GENERIC o 12.0-RC2 aarch64 RPI3 o 12.0-RC2 aarch64 PINE64 o 12.0-RC2 aarch64 PINE64-LTS Note: The 12.0-RC2 armv7 RPI2 build failed, and the cause is being investigated. Also note, at present, freebsd-update(8) patch builds are still in progress. A followup email will be sent in reply to this announcement when they are available. Note regarding arm SD card images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.0/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "releng/12.0" branch. A summary of changes since 12.0-RC1 includes: o Kernel debugging support in various kernel configurations has been disabled, which was missed when branching releng/12.0 from stable/12. o Allow set ether/vlan PCP operation from the VNET jails. o Align IA32_ARCH_CAP MSR definitions and use with SDM rev. 068. o Several IFLIB-related fixes. o Regressions when using 'pciconf -l' were fixed. o Handle kernel superpage mappings in pmap_remove_l2(). (PR 233088) o Fix /etc/ntp permissions. o OpenSSL has been updated to version 1.1.1a. o Various fixes to libbe(3) and bectl(8). o A src.conf knob to build userland with retpoline was added (off by default). o Various other miscellaneous fixes. A list of changes since 11.2-RELEASE is available in the releng/12.0 release notes: https://www.freebsd.org/releases/12.0R/relnotes.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 12.0-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/12.0-RC2/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: ap-south-1 region: ami-0285a4b0c311d9e5e eu-west-3 region: ami-01989f54cc5fc3425 eu-west-2 region: ami-0058f626d39ade7dc eu-west-1 region: ami-07cca4933d62d5d22 ap-northeast-2 region: ami-084b8fc685e73d718 ap-northeast-1 region: ami-0fd072608bc5cc041 sa-east-1 region: ami-0df9e331ad6b563cd ca-central-1 region: ami-01360ca27677e8deb ap-southeast-1 region: ami-0dc6b473d0770bd29 ap-southeast-2 region: ami-0d83b7616da65ae6d eu-central-1 region: ami-0def9b7e1dfdbcb2a us-east-1 region: ami-0e1ca2c649ab4283e us-east-2 region: ami-044bc638def5a1bae us-west-1 region: ami-004ed88ea47546bfb us-west-2 region: ami-0edf97a8cbdffdaf9 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-12.0-RC2 % vagrant up === Upgrading === At present, freebsd-update(8) patch builds are still in progress.
[UPDATE] Re: FreeBSD 12.0-RC2 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The freebsd-update(8) binary upgrade patches are now available for 12.0-RC2. The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 12.0-RC2 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 11.x. Alternatively, the user can install misc/compat11x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install Regards, Glen -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAlv6J3YACgkQAxRYpUeP 4pMLwA/8Dm+j0l31l7LLY+N0SSZ/V87Gkp878to/v7IzJZtbFYNG1zYOq3zJeaXg 1fG71q0TnmpyUQq75MHJssTwzupUWMPI1QSzC5+NIk2VMlC67Td75JU4nW00022Y 0XTH7Q+FleuGRqM+3MYE0oEsHUgMnCVhVWtz5iuJhOBzGI2pR7nsujqka+SIvGuU bsqy66Zj1HdQmOW/2yDxdOI7iaTamz1I1aXaGB3+nnwGtHgmfx9fKZpHSkrmfQak SV1Aroowovg+QMHeprhZBGPx5AQO1WaxwFs0LgpE0JzrSJDgnu1iYqipGsuf66ab NObhRRy5xDDVfnVRs7w3oFM4KwElo2WZg4r/vorJpSyNIqirdIDoatmb2pcb0Ezz q3DG/mUUleb4HLqZizaKsYJYkkIPPNMTDdtbY+e5vQrdi4kYe3wzEgW+zZm5TT+m vHI1nErPEIRFIe3J1kAvlJX6T9xSbATBVifNWJUU7KQDsfNRaNAGmCyQBF9gNOBe IDli6gmavZD6q/popJLM8eIZfLjW6Jktsprl5cf45S4TMYdwWt+HsHE/g5WgSSXi wO19beXw2YcwmehpelrjMVe4MXP57UTSmyAP808htsNOe34osnt2fLMF755R4l1K 6hZPNNjxX9zxzWyLfnO2WE8Xq3Y6twVMYRs1coSW6TJ5AfxJOEo= =tHW5 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
