10.3->11.0 (after upgrade cannot use sudo and pkg)

somebody mentioned pkg upgrade -f earlier but that only works if all options are default. If not, you need poudriere or synth, as also previously mentioned. (synth can mix custom option ports + packages, but poudriere requires all to be built)
 
I'm having the exact same problem upgrading from 10.2 -> 11.0

  1. First did a 'freebsd-update fetch install' which allowed me to do 'freebsd-update upgrade -r 11.0-RELEASE' and 'freebsd-update install'
  2. All went fine without issues, after reboot, did the second 'freebsd-update install', and got a warning I need to rebuild all contrib software - which I wouldn't know how to do since I'm _ONLY_ using pkg and never even cloned the ports tree.
  3. After a subsequent - and useless - 'freebsd-update install' I was unable to run pkg anymore:
    Code: 
    Shared object "libssl.so.7" not found, required by "pkg"
    . The same was true for sudo:
    Code:
Code: 
sudo: error in /usr/local/etc/sudo.conf, line 0 while loading plugin `sudoers_policy'
sudo: unable to load /usr/local/libexec/sudo/sudoers.so: Shared object "libpam.so.5" not found, required by "sudoers.so"
sudo: fatal error, unable to load plugins

So the documented upgrade process is broken. I actually was under the impression that 11.0 would have the base system under pkg, so this would not have been a problem. In fact, I started my BSD experience with 10.2, and have only used 'pkg'.

Should we raise a PR for this? Apparently upgrading today from a 10.x pkg-based system to 11.0 leads to a broken system?
 
Resolved thanks to previous comments by doing:

  1. su - (become root)
  2. pkg-static delete -f pkg
  3. pkg
  4. pkg upgrade -f
Should be documented maybe in the release notes for those like me upgrading from a pkg-only system.
 
ced said:
All went fine without issues, after reboot, did the second 'freebsd-update install', and got a warning I need to rebuild all contrib software - which I wouldn't know how to do since I'm _ONLY_ using pkg and never even cloned the ports tree.
Click to expand...

You don't need to "rebuild" them, you only need to reinstall the packages using versions for the new release.

Here's a step-by-step guide on how to quickly replace all packages only using pkg(8):
https://www.dragonflybsd.org/docs/howtos/HowToDPorts/#index4h1

Should we raise a PR for this? Apparently upgrading today from a 10.x pkg-based system to 11.0 leads to a broken system?
Click to expand...

I would say "no", this is a user error. pkg(8) is itself a package and you didn't replace it, nor did you run the pkg-bootstrap program that would replace it.
 
  • Thanks
Reactions: ced
I've encoutered the problem twice in several dozen upgrades.
Yes, pkg-static install -f pkg resolves the issue.
 
marino@ said:
I would say "no", this is a user error. pkg(8) is itself a package and you didn't replace it, nor did you run the pkg-bootstrap program that would replace it.
Click to expand...

I agree it's a user error. But it's a user error caused by unclear documentation. The fact you have to recite DragonFly BSD documentation shows that as well. I don't know if it requires a PR - I'm too new to BSD in general - but I feel the release notes depicting the how to upgrade from 10.3 or older, can benefit from these few steps.
 
You should avoid using sudo as it's not part of the base system. FreeBSD is not Linux so login as root or use su command when doing maintenance or upgrades.
 
ced said:
The fact you have to recite DragonFly BSD documentation shows that as well.
Click to expand...

I didn't "have" to. There are 100 ways to skin a cat. I prefer to start from scratch so I wrote a HowTo and I felt that HowTo could help you. It could be considered "overkill" but it's also bullet-proof; it always works.
 
marino@ said:
I didn't "have" to. There are 100 ways to skin a cat. I prefer to start from scratch so I wrote a HowTo and I felt that HowTo could help you. It could be considered "overkill" but it's also bullet-proof; it always works.
Click to expand...
Don't get me wrong.. I like it. Just saying that release notes and the handbook could have that explanation as well. Apparently it's common knowledge, but for me - never having had to upgrade between major versions - it's undocumented. Maybe it'll be my first patch I submit against doc.. ;-)
 
There is something in the handbook. At the end of the section
Code: 
23.2.3. Performing Major and Minor Version Upgrades
is
Code: 
The upgrade is now complete. If this was a major version upgrade, reinstall all ports and packages as described in Section 23.2.3.2, “Upgrading Packages After a Major Version Upgrade”.
where the procedure is documented.
 
  • Thanks
Reactions: ced
Until reading this thread, I was unaware of ports-mgmt/synth. I've now installed it and used it to rebuild my ports, and will continue to use it to maintain my system. Many thanks to Marino@ for this wonderful utility!
 
I appear to have a similar problem, but the suggested solutions are not working for me. At the moment, both pkg and sudo are broken. The problems began during a "routine" pkg upgrade. I had updated from 9.1 to 10.0-RELEASE in August 2014, and have been running the system (and updating) without incident since then. I don't remember all the steps I took when switched over to pkg, or when I did so, but I believe it was after the update to 10.0.

Now, when I run either sudo or pkg I get the following error:
Code: 
sudo su
/lib/libc.so.7: version FBSD_1.4 required by /usr/local/bin/sudo not found
pkg
/lib/libc.so.7: version FBSD_1.4 required by /usr/local/lib/libpkg.so.3 not found
Per suggestions above I've used pkg-static to upgrade pkg:

Code: 
pkg-static install -f pkg
# Probably identical, but I also tried:
pkg-static delete -f pkg
pkg

Both appear to run without issue, but pkg is still non-functional afterwards (same complaint about libc.so). I've also run:

Code: 
pkg-static upgrade -f

... which ran without apparent incident (once I realized that I should answer "no" to questions about "no direct installation candidate" for a ruby package). I had hoped that it would somehow resolve the issues with libc, but no luck so far.

Any advice would be much appreciated!

Code: 
uname -a
FreeBSD citadel 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Tue Jul  8 06:37:44 UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
 
Hi, I cannot do anything anymore on my server because of this, as my only access is by ssh-ing to the account of a sudoer, and sudo doesn't work anymore.
How can I avoid this problem next time I upgrade my server to a new release?
 
japoc said:
Hi, I cannot do anything anymore on my server because of this, as my only access is by ssh-ing to the account of a sudoer, and sudo doesn't work anymore.
Click to expand...

This should still work:
Code: 
su -
 
ASX said:
As far as I know this is also true for sudo,
Click to expand...
It's not. Not by default at least. But it can definitely be configured that way, if I recall correctly it's even mentioned as an example in the sudoers file.
 
  • Thanks
Reactions: ASX
ASX said:
This should still work:
Code: 
su -
Click to expand...
No this doesn't work. I get:
$ su -
su: Sorry.

I don't have a root password anyway. If I remember well, I had disabled it in order to make sure only my passwordless ssh-ing sudoer can do any administrative work (using sudo) and no user can use "su". I think the only thing I can do now is reinstall the server.
My question is rather how to avoid this problem in the future.
I'd like to make sure that `sudo` always work even after running `sudo freebsd-update install`.
 
ASX said:
I guess you need to rely on what is available in system, and not on what is in ports/pkgs (like sudo)
Click to expand...

You mean the best way to manage a FreeBSD server would be to ssh into the root account ? (I don't have physical access to the machine). This is what people do?
 
japoc said:
You mean the best way to manage a FreeBSD server would be to ssh into the root account ? (I don't have physical access to the machine). This is what people do?
Click to expand...
May be not ssh to root directly, but setting the user in the wheel group would do. (and using su).
And yes, that's what I do.
 
Yep, me too. I have one user account (mine) in the wheel group and I have the root password. Normally I use sudo(8) as does everybody else. But my account could also be used in a pinch. We also have various KVM/IPMI solutions, so we always have remote access to the console.
 
You must log in or register to reply here.
Back
Top