On Sun, Oct 16, 2016 at 10:29:00AM -0700, Xin Li wrote:
> ... 
> 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.

I seem to have failed to commnunicate clearly:  The machine in question
does not, and has not, run "stable".  It runs releng.

At the moment (on the "old" slice), it reports:

sisboombah(10.3-RELEASE-p7)[1] uname -a
FreeBSD sisboombah.catwhisker.org 10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: 
Thu Aug 11 18:38:15 UTC 2016     
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

> 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
> patchlevel.

I can see that... if the machine were running stable.

> 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.

As a reality check:
sisboombah(10.3-RELEASE-p7)[4] sudo mount /S2
sisboombah(10.3-RELEASE-p7)[5] sudo mount /S2/usr
sisboombah(10.3-RELEASE-p7)[6] ls -lT {,/S2}/usr/lib/private/libssh.so.*
-r--r--r--  1 root  wheel  634232 Oct 16 11:57:32 2016 
-r--r--r--  1 root  wheel  569864 Jun  5 13:37:52 2016 
sisboombah(10.3-RELEASE-p7)[7] ls -lT {,/S2}/usr/sbin/ssh*
-r-xr-xr-x  1 root  wheel  297736 Jun  5 13:38:35 2016 /S2/usr/sbin/sshd
-r-xr-xr-x  1 root  wheel  297736 Jun  5 13:38:35 2016 /usr/sbin/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.

Well, I had seen reports of folks having "issues" with attempts to
use freebsd-update to get to releng/11 from systems that weren't
as up-to-date as they might be; I was actually trying to avoid a
problem.... :-}

David H. Wolfskill                              da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.

Attachment: signature.asc
Description: PGP signature

Reply via email to