FreeBSD 10.1-RC4 Now Available

[Glen Barber]

On Mon, Nov 03, 2014 at 11:21:04PM -0800, Kevin Oberman wrote:
> On Mon, Nov 3, 2014 at 12:32 AM, Glen Barber <gjb at freebsd.org> wrote:
> 
> > On Sun, Nov 02, 2014 at 04:37:26PM -0800, Kevin Oberman wrote:
> > > On Sun, Nov 2, 2014 at 11:43 AM, Glen Barber <gjb at freebsd.org> wrote:
> > > I hit a problem right out at the start:
> > >    # freebsd-update upgrade -r 10.1-RC4
> > >    Looking up update.FreeBSD.org mirrors... 5 mirrors found.
> > >    Fetching metadata signature for 10.0-RC3 from update2.freebsd.org...
> > > done.
> > >    Fetching metadata index... done.
> > >    Fetching 1 metadata patches. done.
> > >    Applying metadata patches... done.
> > >    Fetching 1 metadata files... done.
> > >    Inspecting system... done.
> > >
> > >    The following components of FreeBSD seem to be installed:
> > >    kernel/generic src/src world/base world/doc world/games
> > >
> > >    The following components of FreeBSD do not seem to be installed:
> > >    world/lib32
> > >
> > >    Does this look reasonable (y/n)? n
> > >
> > > But I do have lib32 installed and have had since the initial
> > > installation.No prior upgrade failed. I have no time to look at how
> > > freebsd-update tests for components, but something went haywire.
> >
> > I am unable to reproduce this, and prior to sending the 10.1-RC4
> > announcement email, did test the upgrade path from 10.1-RC2 and
> > 10.1-RC3.  I've just double-checked on a clean install of 10.1-RC3, and
> > only see (as expected on this install) src/src component not installed
> > locally.
> >
> 
> Ahh. I found a rather nasty oops. It is NOT a problem with RC4. It was a
> typo when I intended to go to RC3. Seems I went to 10.0-RC3-p1. I may take
> me a while to clean up the mess! Any explanation of how this could have
> caused me to lose /usr/lib32 contents would be appreciated
> 
> Sorry for the noise.

My suspicion is that 'freebsd-update install' was run twice without
a reboot between.

freebsd-update(8) uses uname(1) to determine the running userland and
kernel to determine the upgrade path, specifically the current running
version to the version intended to be run.  It uses 'uname -r' for this,
so if you do this, you can end up with a very interesting running
userland after the reboot.

    # # fetch update bits for next RC
    # freebsd-update -r 10.1-RC4 upgrade

    # # install kernel for next RC(*)
    # freebsd-update install

    # # install userland for next RC
    # freebsd-update install

(*) This is important.  While you have technically installed the new
kernel, it is not the *active* kernel, and freebsd-update(8) (nor any
other utility using 'uname -r') cannot tell the difference without
a reboot.

For example, on my laptop:

    # uname -ri
    11.0-CURRENT NUCLEUS

    # env UNAME_r=12.0-EVILBSD UNAME_i=NOTGENERIC uname -ri
    12.0-EVILBSD NOTGENERIC

While it is purely conjecture this is the situation in your case,
"disappearing" /usr/lib32 is certainly an effect of this I have
never personally seen before.

Was /usr/lib32 in fact gone, or are you basing that on the output of
freebsd-update(8)?

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20141104/24cf6f7d/attachment.sig>