[REVISED] Re: FreeBSD 11.0-RC1 Now Available
On Sat, Aug 13, 2016 at 01:30:56AM +, Glen Barber wrote: > o OpenSSH DSA keys have been disabled by default. Users upgrading from > prior FreeBSD versions are urged to update their SSH keys to DSA or > ECDSA keys before upgrading to 11.0-RC1. > Note, this should have suggested to update SSH keys to RSA or ECDSA, not DSA or ECDSA. Apologies for any confusion. Glen signature.asc Description: PGP signature
FreeBSD 11.0-RC1 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The first RC build of the 11.0-RELEASE release cycle is now available. Installation images are available for: o 11.0-RC1 amd64 GENERIC o 11.0-RC1 i386 GENERIC o 11.0-RC1 powerpc GENERIC o 11.0-RC1 powerpc64 GENERIC64 o 11.0-RC1 sparc64 GENERIC o 11.0-RC1 armv6 BANANAPI o 11.0-RC1 armv6 BEAGLEBONE o 11.0-RC1 armv6 CUBIEBOARD o 11.0-RC1 armv6 CUBIEBOARD2 o 11.0-RC1 armv6 CUBOX-HUMMINGBOARD o 11.0-RC1 armv6 GUMSTIX o 11.0-RC1 armv6 RPI-B o 11.0-RC1 armv6 RPI2 o 11.0-RC1 armv6 PANDABOARD o 11.0-RC1 armv6 WANDBOARD o 11.0-RC1 aarch64 GENERIC Note regarding arm/armv6 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, which 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: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/11.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/11.0" branch. A summary of changes since BETA4 includes: o A NULL pointer dereference in IPSEC has been fixed. o Support for SSH Protocol 1 has been removed. o OpenSSH DSA keys have been disabled by default. Users upgrading from prior FreeBSD versions are urged to update their SSH keys to DSA or ECDSA keys before upgrading to 11.0-RC1. o PCI-e hotplug on bridges with power controllers has been disabled. o A loader tunable (hw.pci.enable_pcie_hp) to disable PCI-e HotPlug has been added. o A VESA panic on suspend has been fixed. o Google Compute Engine image publication has been fixed. o An AES-ICM heap corruption typo bug has been fixed. o A regression in pf.conf while parsing the 'interval' keyword has been fixed. o A ZFS/VFS deadlock has been fixed. A list of changes since 10.0-RELEASE are available on the releng/11.0 release notes: https://www.freebsd.org/releases/11.0R/relnotes.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 11.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): ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/11.0-RC1/ 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: us-east-1 region: ami-1f128b08 us-west-1 region: ami-73baf913 us-west-2 region: ami-9062a9f0 sa-east-1 region: ami-daaf39b6 eu-west-1 region: ami-424d2731 eu-central-1 region: ami-ca7284a5 ap-northeast-1 region: ami-3ae6255b ap-northeast-2 region: ami-dc5c96b2 ap-southeast-1 region: ami-0f875e6c ap-southeast-2 region: ami-c3d6e2a0 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-11.0-RC1 % vagrant up === Upgrading === 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 11.0-RC1 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 componen
Re: unionfs bugs, a partial patch and some comments [Was: Re: 1-BETA3 Panic: __lockmgr_args: downgrade a recursed lockmgr nfs @ /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/unionfs/union_vnops.c
On Thu, Aug 11, 2016 at 10:53:03PM +, Rick Macklem wrote: > Harry Schmalzbauer wrote: > Bez??glich Mark Johnston's Nachricht vom 09.08.2016 08:02 (localtime): > ??? > >> > >> Just for anybody else needing unionfs: > >> https://people.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch > >> > >> This patch still applies and I'm successfully using this (unmodified) up > >> to FreeBSD-10.3 and never had any panic in all these years. > > > > Having spent some time looking at unionfs, I'm a bit skeptical that this > > patch will address the panic you reported earlier, though I'd be > > interested to know if it does. > [stuff snipped for brevity] > I took a look at this. (I know nothing about unionfs, but a little w.r.t. the > VFS). > I can confirm that this function (unionfs_nodeget()) is weird and appears to > be broken to me. > > The function calls insmntque() before it initializes the vnode, which seems > racey, especially if it isn't LK_EXCLUSIVE locked. > Also, line#s 278-281: > if (uppervp != NULLVP) > vp->v_vnlock = uppervp->v_vnlock; > else > vp->v_vnlock = lowervp->v_vnlock; > so your patch isn't locking the vnode lock that it actually uses. > I think the vp argument to insmntque() is required to be LK_EXCLUSIVE > locked mostly so other threads won't fiddle with the vnode until this > function is done with it, but I am not sure? > > I think a more correct version of this (not saying it would be correct[], > would call insmntque() later in the function, after it has been initialized. > (This means that the cleanup if it fails is more involved, but...) Yes. > > I've attached a patch (untested) that does this. Maybe you could try it? > > rick > ps: I've cc'd Kostik, in case he has some insight w.r.t. how this should be > handled? > insmnque() performs the cleanup on its own, and that default cleanup is not suitable for the situation. I think that insmntque1() would better fit your requirements, your need to move the common code into a helper. It seems that unionfs_ins_cached_vnode() cleanup could reuse it. ___ 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: lots of security advisories rehashed
On 08/12/16 12:23, Kurt Jaeger wrote: > Hi! > >> I subscribe to the RSS feed of FreeBSD security advisories >> (http://vuxml.freebsd.org/freebsd/rss.xml). Today, it told me that there >> were forty-something advisories. I went to the VuXML site and saw that a >> stack of old entries have been updated to have today as their "Entry" >> date. What's the reason? Is it something to be worried about? > > No, as far as I know. > > Mark Feld added some VuXML entries to ancient bugs, for completeness. > Note that these are capturing the last several years worth of security advisories for the base system into VuXML. This allows you to say, for instance: pkg audit FreeBSD-10.3_2 which will tell you about a number of security advisories which have come out since 10.3-RELEASE-p2. This is in anticipation of the base system being packaged, which is due to come in with 11.1-RELEASE. See Mark Felder's announcement on questions@: https://lists.freebsd.org/pipermail/freebsd-questions/2016-August/273034.html As Mark says, this is not guaranteed to be either accurate or complete, but it should be helpful in managing system upgrades. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: lots of security advisories rehashed
Hi! > I subscribe to the RSS feed of FreeBSD security advisories > (http://vuxml.freebsd.org/freebsd/rss.xml). Today, it told me that there > were forty-something advisories. I went to the VuXML site and saw that a > stack of old entries have been updated to have today as their "Entry" > date. What's the reason? Is it something to be worried about? No, as far as I know. Mark Feld added some VuXML entries to ancient bugs, for completeness. -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ 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"
lots of security advisories rehashed
I subscribe to the RSS feed of FreeBSD security advisories (http://vuxml.freebsd.org/freebsd/rss.xml). Today, it told me that there were forty-something advisories. I went to the VuXML site and saw that a stack of old entries have been updated to have today as their "Entry" date. What's the reason? Is it something to be worried about? Thanks, Graham ___ 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: unionfs bugs, a partial patch and some comments [Was: Re: 1-BETA3 Panic: __lockmgr_args: downgrade a recursed lockmgr nfs @ /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/unionfs/union_vnops.c
Harry Schmalzbauer wrote: Bezüglich Mark Johnston's Nachricht vom 09.08.2016 08:02 (localtime): … >> >> Just for anybody else needing unionfs: >> https://people.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch >> >> This patch still applies and I'm successfully using this (unmodified) up >> to FreeBSD-10.3 and never had any panic in all these years. > > Having spent some time looking at unionfs, I'm a bit skeptical that this > patch will address the panic you reported earlier, though I'd be > interested to know if it does. [stuff snipped for brevity] I took a look at this. (I know nothing about unionfs, but a little w.r.t. the VFS). I can confirm that this function (unionfs_nodeget()) is weird and appears to be broken to me. The function calls insmntque() before it initializes the vnode, which seems racey, especially if it isn't LK_EXCLUSIVE locked. Also, line#s 278-281: if (uppervp != NULLVP) vp->v_vnlock = uppervp->v_vnlock; else vp->v_vnlock = lowervp->v_vnlock; so your patch isn't locking the vnode lock that it actually uses. I think the vp argument to insmntque() is required to be LK_EXCLUSIVE locked mostly so other threads won't fiddle with the vnode until this function is done with it, but I am not sure? I think a more correct version of this (not saying it would be correct[😉], would call insmntque() later in the function, after it has been initialized. (This means that the cleanup if it fails is more involved, but...) I've attached a patch (untested) that does this. Maybe you could try it? rick ps: I've cc'd Kostik, in case he has some insight w.r.t. how this should be handled? unionfs-newvnode.patch Description: unionfs-newvnode.patch ___ 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"
