Issue with dpkg after upgrade to Testing (SOLVED)

[Mr. Lumbergh]

Yesterday I took my Buster install up to Testing/Bullseye and I'm now getting the following when trying to install a package:

Code: Select all

dpkg: warning: 'ldconfig' not found in PATH or not executable
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable
dpkg: error: 2 expected programs not found in PATH or not executable
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin

To be honest, I'm not sure if this was something that persisted across the upgrade or if something was broken/corrupted during the process. I've done some digging online and in various forums but the issues and solutions all seemed to be from a few years ago; on here most of what I found that was similar pointed to using

Code: Select all

su -

but I'm already logged in as root on the command line (I don't use sudo).
I tried following along with a thread from earlier http://forums.debian.net/viewtopic.php? ... th#p708711 but the solution wasn't clear to me.
Thanks in advance.

[Pakos]

show your path variable, should be similar to:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

[Mr. Lumbergh]

show your path variable, should be similar to:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Here's what came up:

Code: Select all

lumbergh@HAL9000:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

I also have Lutris installed on this system, could it have wiped the original bash profile?

[sunrat]

That's your user PATH. If you're trying to nail down an issue with dpkg, you need to check root PATH.

Code: Select all

$ su -
<enter root password>
# echo $PATH

[Mr. Lumbergh]

That's your user PATH. If you're trying to nail down an issue with dpkg, you need to check root PATH.

Code: Select all

$ su -
<enter root password>
# echo $PATH

Here it is:

Code: Select all

root@HAL9000-Deb:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

[sunrat]

ldconfig and start-stop-daemon both usually exist in /sbin/ so I was thinking your issue may have been that you didn't switch to root correctly, same as the linked thread in your first post. However /sbin/ appears in your root PATH and you stated that you switched to root correctly before running dpkg so I'm out of ideas.

Just double-check those programs exist (as root):

Code: Select all

which ldconfig
which start-stop-daemon

Your computer didn't happen to say "I'm sorry Dave, I'm afraid I can't do that"?

[Mr. Lumbergh]

ldconfig and start-stop-daemon both usually exist in /sbin/ so I was thinking your issue may have been that you didn't switch to root correctly, same as the linked thread in your first post. However /sbin/ appears in your root PATH and you stated that you switched to root correctly before running dpkg so I'm out of ideas.

Just double-check those programs exist (as root):

Code: Select all

which ldconfig
which start-stop-daemon

Your computer didn't happen to say "I'm sorry Dave, I'm afraid I can't do that"?

In a roundabout way, yes it did, unfortunately!
Here's the output of the which query:

Code: Select all

lumbergh@HAL9000-Deb:~$ su -
Password: 
root@HAL9000-Deb:~# which ldconfig
/usr/sbin/ldconfig
root@HAL9000-Deb:~# which start-stop-daemon
/usr/sbin/start-stop-daemon

Both of those daemons are in there. I'm not sure what I did wrong, perhaps the .deb was corrupted. I'll see if I can manually add the downloads from KXStudios as a repo with the program and install through Synaptic instead.
Thank you for your time.

[stevepusser]

The elephant in the room:

Exactly how did you do the upgrade, and was it for any particular package?

[Mr. Lumbergh]

The elephant in the room:

Exactly how did you do the upgrade, and was it for any particular package?

I followed the destructions outlined in this how-to: https://ultra-technology.org/linux_for_ ... ye-debian/. It was primarily to get a more recent Firefox from official channels; ESR 60 was a dog, especially on certain pages. I was also curious to see if some of the testing packages included a few things I was looking for that weren't in the Stable repos.

[sunrat]

I followed the destructions outlined in this how-to: https://ultra-technology.org/linux_for_ ... ye-debian/.

Strange it's in a section called "linux_for_beginners". Testing is not really for beginners.

It was primarily to get a more recent Firefox from official channels; ESR 60 was a dog, especially on certain pages. I was also curious to see if some of the testing packages included a few things I was looking for that weren't in the Stable repos.

There are ways to run the latest Firefox on Stable.

[Head_on_a_Stick]

Strange it's in a section called "linux_for_beginners".

I think it's a typo: should be "linux_by_beginners"

I followed the destructions

lol

[Mr. Lumbergh]

Strange it's in a section called "linux_for_beginners".

I think it's a typo: should be "linux_by_beginners"

Is the method outlined in the link problematic? It seems to have gotten the job done; when I updated GRUB after, both distros identified it as Bullseye/Sid, and dpkg is pulling from the Bullseye repos. Thus far, the system is remaining stable.

I followed the destructions

lol

It seems to me to be the most apropos way to describe those how-tos. Sometimes they're great, sometimes... Not so much.

Anywho, thanks again to everyone who chipped in their time with helping me get this sorted. I was able to get what I needed by manually enabling their ftp site as repo and installing through Synaptic. I think there may have been something up with the deb file.

[stevepusser]

I wonder if "destructions" was a Freudian slip, since that seems to be what happened.

Perhaps I could backport the stable Firefox on Buster from source, like mozilla.debian.net used to do...but I'm kind of busy with MX 19 stuff ATM.

[Head_on_a_Stick]

Is the method outlined in the link problematic?

A development branch can break occasionally, is that really what you want from an operating system? Debian stable doesn't tend to break at all and newer software versions can be added fairly easily (and safely) with a variety of well-documented methods.

And testing is the worst branch of all for security support, check the status for the recently-announced sudo vulnerability: https://security-tracker.debian.org/tra ... 2019-14287

Debian bullseye will be the last version to be marked "fixed" and it may take a while...

[Mr. Lumbergh]

I wonder if "destructions" was a Freudian slip, since that seems to be what happened.

I think it may have been the particular deb I was trying to install. They have a pretty clean ftp site that Synaptic had no trouble with after I manually enabled it.

I wonder if "destructions" was a Freudian slip, since that seems to be what happened.

Perhaps I could backport the stable Firefox on Buster from source, like mozilla.debian.net used to do...but I'm kind of busy with MX 19 stuff ATM.[/quote]
That would be helpful when you can, not a huge rush. ESR 69 is a Quantum release and is better than the ESR 60 that was the latest in Stable. The one page that wasn't playing well is still slow to load, but better than before and I can use Chromium for now if need be.

[Mr. Lumbergh]

Is the method outlined in the link problematic?

A development branch can break occasionally, is that really what you want from an operating system? Debian stable doesn't tend to break at all and newer software versions can be added fairly easily (and safely) with a variety of well-documented methods.

And testing is the worst branch of all for security support, check the status for the recently-announced sudo vulnerability: https://security-tracker.debian.org/tra ... 2019-14287

Debian bullseye will be the last version to be marked "fixed" and it may take a while...

I've been using Debian for about a month and half or so now, but my understanding was that Testing was still pretty solid and was available as a way to suss out and report any final bugs before the freeze in the next major revision but with the advantage of newer packages, sort of a happy medium between Stable and Unstable. I don't mind a bit of tweaking and fixing here and there, but the last time I tried a bleeding-edge setup with Arch, it was more trouble than it was worth. I love the concept of the AUR, but Arch was a bit of a PITA when it came to things breaking. The last issue I had before wiping it was an update that killed compatibility with my wireless card, then froze because it could no longer fetch packages and after wouldn't boot. Nah.
As for sudo, I don't really use it. I'm used to logging in as root to do what I need as that's how the other distro I have installed does things. I did install it here when I was in the process of getting it up and running but wound up removing my user account from sudoers. Would that bug still be a worry? If so I'll run an apt-purge on it.

[sunrat]

With Firefox, it's always been possible to just download the tarball, extract it to a directory in your home folder, and run it manually from there.
https://www.mozilla.org/en-US/firefox/a ... op-release

[stevepusser]

After quite a bit of effort uploading many packages to the OBS, I may have 69.0.2 from Sid getting backported from source when all this shakes out: https://build.opensuse.org/project/show ... -backports

I'll find out what happened to it tomorrow.

You can also install the MX Firefox debs on any version of Debian, since they just rebundle the Mozilla binaries into a deb, along with a desktop file and other niceties. http://mxrepo.com/mx/repo/pool/main/f/firefox/

Getting the latest Firefox on Stable is asked and answered quite frequently, too--too bad there isn't a FAQ sticky here.

[Head_on_a_Stick]

my understanding was that Testing was still pretty solid and was available as a way to suss out and report any final bugs before the freeze in the next major revision but with the advantage of newer packages, sort of a happy medium between Stable and Unstable.

No, not at all. That belongs here.

There is a mandatory transition delay for packages going from sid to testing so if something is broken in testing it could stay broken for a while whereas sid will get the fixes from upstream as soon as the maintainer notices them.

There is a FAQ covering this: https://www.debian.org/doc/manuals/debi ... .html#s3.1

tl;dr: use stable and backport newer software to that release if needed.

I don't mind a bit of tweaking and fixing here and there, but the last time I tried a bleeding-edge setup with Arch, it was more trouble than it was worth. I love the concept of the AUR, but Arch was a bit of a PITA when it came to things breaking.

I've used both Arch Linux and Debian sid and Arch is more consistently reliable in my experience, even with [testing] enabled. Arch is a rolling release but sid is a development branch, there is a difference.

As for sudo, I don't really use it. I'm used to logging in as root to do what I need as that's how the other distro I have installed does things. I did install it here when I was in the process of getting it up and running but wound up removing my user account from sudoers. Would that bug still be a worry? If so I'll run an apt-purge on it.

You're missing my point — the sudo vulnerability was just an example meant to illustrate a general principle: testing is not as secure as sid or stable.

[Mr. Lumbergh]

my understanding was that Testing was still pretty solid and was available as a way to suss out and report any final bugs before the freeze in the next major revision but with the advantage of newer packages, sort of a happy medium between Stable and Unstable.

No, not at all. That belongs here.

There is a mandatory transition delay for packages going from sid to testing so if something is broken in testing it could stay broken for a while whereas sid will get the fixes from upstream as soon as the maintainer notices them.

There is a FAQ covering this: https://www.debian.org/doc/manuals/debi ... .html#s3.1

tl;dr: use stable and backport newer software to that release if needed.

I've updated the apt/preferences file in the following way to allow fetching of newer packages from sid if it's more secure and installed debsecan.

Code: Select all

Package: *
Pin: release a=testing
Pin-Priority: 500

Package: *
Pin: release a=unstable
Pin-Priority: 200

I don't mind a bit of tweaking and fixing here and there, but the last time I tried a bleeding-edge setup with Arch, it was more trouble than it was worth. I love the concept of the AUR, but Arch was a bit of a PITA when it came to things breaking.

I've used both Arch Linux and Debian sid and Arch is more consistently reliable in my experience, even with [testing] enabled. Arch is a rolling release but sid is a development branch, there is a difference.

As I said, that wasn't at all my experience. Especially after that issue with the network card I decided it just wasn't worth it. The other distro I have installed is also rolling-release, and using it more or less since 2005 has only caused me two major issues.
Maybe I'm just not an Arch guy. ¯\_(ツ)_/¯

As for sudo, I don't really use it. I'm used to logging in as root to do what I need as that's how the other distro I have installed does things. I did install it here when I was in the process of getting it up and running but wound up removing my user account from sudoers. Would that bug still be a worry? If so I'll run an apt-purge on it.

You're missing my point — the sudo vulnerability was just an example meant to illustrate a general principle: testing is not as secure as sid or stable.

Ok, granted. But what about my question, does that mitigate the issue?
As far as I can tell, I can't revert back without a full reinstall, so for now I'll make the best of it.