On 10/16/16 09:26, David Wolfskill wrote:
> And over the last year or so, it's worked pretty well:  I have the
> machine set up (as is usually my approach) to be able to boot from
> either of a couple of slices.  I use a "dump | restore" pipeline
> to copy the / and /usr file systems from the "active" slice to the
> "inactive" slice, adjust /etc/fstab on the inactive slice to reflect
> reality for when it's the boot slice, then (while the file systemms
> from the other slice are still mounted -- e.g., on /S2) run
> "freebsd-update -b /S2 fetch install", then reboot from the
> newly-updated slice.
> In the past, that's Just Worked.

Your usage probably worked because you were lucky for a few times in the
past.  (details below)

> This weekend, though, I was planning to update my other systems tfrom
> stable/10 to stable/11, so I figured I'd try freebsd-update on this
> machine first.
> root@sisboombah:/tmp # `which sshd` -d
> Undefined symbol "ssh_compat13" referenced from COPY relocation in 
> /usr/sbin/sshd
> Any clues?

I think this is not going to work (stable/10 -> releng/10.3) due to ABI
incompatibility in a downgrade.

Basically, freebsd-update is treating your stable/10 as a 10.3-RELEASE
installation and will fetch only changes from 10.3-RELEASE to the latest

Because of a SSH vulnerability that affects 10.3, freebsd-update would
patch libssh (shared library used by sshd and friends), however the
change does not affect the main binary.  This worked by replacing your
existing libssh with the one shipped by freebsd-update (effectively
downgraded the library) and that would break sshd.

I think upgrade -r 10.2-RELEASE (ideally, 11.0-RELEASE though as it
would eliminate the possibility of any potential incompatibility) would
work because that would result in a full rewrite of all files.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to