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 patchlevel. 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. Cheers,
signature.asc
Description: OpenPGP digital signature