The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 10.1-RELEASE. This is the second release of the stable/10 branch, which improves on the stability of FreeBSD 10.0-RELEASE and introduces some new features.

Some of the highlights:

• The new console driver, vt(4), has been added.
  
• Support for FreeBSD/i386 guests has been added to bhyve(4).
  
• The bhyve(4) hypervisor now supports booting from a zfs(8) filesystem.
  
• Support for SMP was added to the armv6 kernels and enabled by default in the configuration files for all platforms that contain multi-core CPUs.
  
• Initial support for UEFI boot has been added for the FreeBSD/amd64 architecture.
  
• Support has been added to cache geli(8) passphrases during system boot.
  
• Support for the UDP-Lite protocol (RFC 3828) has been added to the IPv4 and IPv6 stacks.
  
• The new filesystem automount facility, autofs(5), has been added.
  
• The sshd(8) rc.d(8) startup script now generates ED25519 sshd(8) host keys if keys do not already exist when ssh_keygen_alg() is invoked.
  
• OpenSSH has been updated to version 6.6p1.
  
• The nc(1) utility has been updated to match the version in OpenBSD 5.5.
  
• Sendmail has been updated to 8.14.9.
  
• The unbound(8) caching resolver and ldns have been updated to version 1.4.22.
  
• OpenPAM has been updated to Ourouparia (20140912).
  
• OpenSSL has been updated to version 1.0.1j.
  
• The pkg(8) package management utility has been updated to version 1.3.8.

For a complete list of new features and known problems, please see the online release notes and errata list, available at:

https://www.FreeBSD.org/releases/10.1R/relnotes.html

https://www.FreeBSD.org/releases/10.1R/errata.html

For more information about FreeBSD release engineering activities, please see:

https://www.FreeBSD.org/releng/

Another stellar release from the good people at FreeBSD. Installing 10.1 at the moment.

Already installed it last night and built Xorg through ports rather than install the binary package.

Probably going to build Xfce desktop and other utilities next week as I have time.

1 members found this post helpful.

I'm very fond of Gnome2 on FreeBSD. Gnome2 up and running. Love that!

The only gripe I've had is dealing with USB drives needing to be manually mounted due to the lack of udisks, but I have thought about just using a command added to /etc/profile to autohandle the drive.

Running freebsd-upgrade -r 10.1-RELEASE upgrade as I type...

I have been very happy upgrading ports and packages to this point, but this will be my first minor-version upgrade with FreeBSD.

Performed a few other housekeeping tasks with it today and read the release notes... upgrade fetch now in progress - I'll be back when it completes.

=========
About 2 hours later... now running FreeBSD 10.1-RELEASE!

Although it appears that I need to rebuild a few ports, kind of expected that. And I am getting an ntpd message about being unable to open a socket... both of which will have to wait until later.

With Slackware I rarely perform such monolithic updates, and I admit it makes me nervous on FreeBSD as well, but this has been mostly about extending my BSD comfort zone and to that end it has been very successful!

OOPS!

My continuing upgrade to FreeBSD 10.1 (from FreeBSD 10.0 p9).

As mentioned in my previous post, I normally do not perform large automated monolithic updates on my systems. My freebsd-update to 10.1 had gone very well and I had completed everything except rebuilding affected ports (although I had installed the new shared libs and was having no issues.)

So after reading much in the Handbook and man pages I decided to give portmaster -abg a try (189 ports needed updating).

I got through the initial config stage (had to exclude tex-texmf) and told it to proceed...

I am about 1-1/2 hours into that process when this happened:

So now portmaster has bailed out, but still with many spawned fetchs running in the background. I reinstalled the previous version of libevent2 from backup package, but now I find myself in that wonderful position of not really knowing what to do next!

I guess I just needed a refresher in all the reasons for not running those large automated processes!

My plan at the moment is to simply allow the spawned fetches to run their course, I see no point in interrupting them because I have no idea of their current states (another reason not to...). But a winter storm is approaching too - we call that a race condition!

I am not seriously concerned that my system is permanently borked, presumably I can sort my way back through the list and continue later (or even restart portmaster and see if I can complete it that way). I just really hate to end up in these indeterminate states!

I guess I also need to try to figure out why libevent2 conflicts with libevent...

Thanks for reading along, not really asking a question - but helpful advice and encouragement still appreciated if offered.

============================
Update - as expected, the fetch processes worked their way through and left no loose ends.

I had wondered whether portmaster had full aborted or dropped me to a new shell from whcih I could exit/return to where I was - it had aborted.

I attempted to resume with -x libevent2 but it simply dropped out as before.

I rebuilt a few others individually as I normally would have, tweaked a few configs and all is right with the world until I find a fix for libevent2.

I added the new vt console driver to loader.conf, but I get a too-big font and screen resolution that loses a couple of characters on the left side, so have returned to previous state for that as well.

So, the good news is that portmaster, even when interrupted, is robust enough to recover gracefully. I kind of expected that but good to know my way through it hands on!

Yes. I have encountered that situation many times on FreeBSD. Ports is an amazing package management system when it correctly resolves dependencies. I only use the pkg system on my FreeBSD VM. I'm not condemning ports I just don't have the times to track down and resolve odd occurrences. FreeBSD 10.1 is fantastic.

My habits with Slackware/SBo are all geared toward never ending up in an indeterminate state and serve me very well. I have tried to cultivate similar methods with FreeBSD and find ports to be a pretty good fit, but I still don't know the tools and options well enough to have that same degree of certainty. Portmaster may yet be useful, but it invokes far too many parallel processes for my nerves at this time! I'll stick with the basic ports make options for now - my brain can mostly follow that!

I have a few other questions that I'll put into another thread - but I agree, 10.1 looks very good!

For completeness - I have resolved the libevent2 install error.

Reviewing the /usr/ports/UPDATING document...

DUH! I missed that one long ago... it just came back to bite me!

So I deleted libevent and the previous libevent2, then rebuilt and installed the current libevent2.

I have decided to allow portmaster to complete my ports updates just so that I build better familiarity with it... runniing as I type...

I often just rebuild the ports myself using my own setups and use portmaster to control things. Pkg is nice, but a bit generic.

Yea, as mentioned, I rarely use automated processes for system functions. I started following Slackware -current with one machine at 14.0 using slackpkg and have been a little surprised that I am able to manage that at a comfortable level of granularity once I figured out what to blacklist - and I never do it unattended. But I still use that machine as a buffer/filter and local repo for manual updates of all my others so that "almost nothing ever breaks"... and I have gotten totally spoiled to that over the past few years!

Overall, the FreeBSD ports system is a very good fit into my way of doing things, except that the tools do not as easily allow the fine grained control that is so natural with the Slackware package tools.

I use Pkg only as an information source for installed packages, and to manage some of the ports builds, but never to install pre-built packages, so far.

Portmaster is, to me, a run-away-steam-locomotive waiting to happen! That may be largely due to my own unfamiliarity with it, so I am not 100% sure what it is actually going to do when invoked! That said, even though it was a frightening ride for me the past few days, it stayed on the rails and never resulted in a train wreck!

Following the upgrade path from, 10.0 to 10.1 was intended to be a learning experience to build that familiarity - and it was that - but it has also been a bit of a roller-coaster or wild-mouse ride! But I rode it all the way to the end tonight and now have a 100% FreeBSD 10.1 upgraded system, including ports, without having to resort to any mystery methods or bulk reinstalls (mostly).

The "mostly" exception is that somewhere along the way my Xorg broke. Once everything reported as up to date, Xorg reported an incorrect ABI version for the drivers. I manually deinstalled/reinstalled the server and (I thought) drivers without result. Researching it I found the fix to be to run 'portmaster xf86-' which worked, but I am not really sure why, or why it was necessary... so still a loose end.

My BIG lesson from it all has been to READ /usr/ports/UPDATING and faithfully stay up to date! The majority of my surprises were the result of things ignored during previous ports updates!

But - I was able to get into trouble and recover from it with the available tools and my accumulated Unix-y skills without ever considering a reinstall, and I count it a production machine, so I count it as a success!

Ports do require some TLC during install so you don't get build errors, however, if an error does occur the stop error always lists to port that failed, so you can easily track it down, reconfigure the port, and retry it.