To get closer to a definitive answer for this, we need to see which files are causing the mount: / is busy
error. You could do this with:
lsof / | awk 'NR==1 || $4~/[0-9][uw]/'
See my answer to the OP's other question - lsof: show files open as read-write - for the caveats to this. It may be that you need to put this into a separate script and the put the script into the apt hook in order to see something.
My suspicion is that files under /etc
remain open once the services are started. Some programs/daemons update their configuration dynamically. NetworkManager
and cupsd
are two examples. Updates to cups
which cause cupsd
to scan for new printers (as opposed to a dpkg
configuration script) may well be what is causing your issue. I recommend that you put /etc
on a writeable file system, even if it is not the source of your problem.
Another possibility is that the filesystem buffer is still in the process of being flushed to disk when you try to do the remount. I'm not sure what the behaviour for mount
is here, whether it is to block until IO is complete or to fail and report the disk as busy. The first seems more likely, but I see no sync
calls in the output of strace
(although possibly the mount
system call does this). Anyway, it may work to do a sync
before the remount if the lsof
above doesn't show anything, eg:
DPkg::Post-Invoke { "sync; mount -o remount /"; };
If you switch back to stable by replacing “testing” with “stable”, you won’t get any errors, but you’ll pretty much stay stuck with whatever versions of the packages you have currently, at least those which were upgraded to “testing” versions: they are all newer than the corresponding versions in Debian 9, and apt
won’t downgrade by default.
(Note that you should specify “stretch” in your sources.list
, rather than “stable”; otherwise you’ll end up upgrading to Debian 10 as soon as it’s released, rather than when you choose to do so.)
If you want to fully revert to Debian 9, you’ll need to downgrade your packages. You can do that manually, by investigating the packages which were upgraded:
apt list --installed | grep /testing
or
apt list --installed | grep /now
will tell you what they are. (The /testing
variant will work if your sources.list
still include “testing”, the /now
variant will work otherwise.)
Or you can do it “automatically”, by pinning “stretch” to 1001; add the following to /etc/apt/preferences
, creating it if necessary:
Package: *
Pin: release n=stretch
Pin-Priority: 1001
Then apt dist-upgrade
will attempt to downgrade all appropriate packages to their Debian 9 version. Note that this is untested and unsupported (downgrades aren’t supported as a general rule), so do pay close attention to what apt
is going to do before letting it proceed.
You can reduce the amount of work involved in all this by adding Stretch backports, since that has versions of some packages which are closer to those in testing; add
deb http://http.debian.net/debian stretch-backports main
to your sources.list
.
Best Answer
There are a two things which could cause this. You can find out which by using:
Line
(1)
and(2)
are equivalent today, but they won't always be. One day,stable
will point tobullseye
. When that happens, your machine will automatically change too. If you want control, then use codenamebuster
. Check for thetesting
suite. That switched frombuster
tobullseye
on 6 July 2019.If you have something like what's above, then Debian may see several versions of each package. The latest version of a package will be selected unless you've set
APT::Default-Release
in/etc/apt/apt.conf
or explicitly pinned priorities in/etc/apt/preferences.d/
.The next question is why did your
sources.list
have a strange entry? It could be that you've added a line because you wanted the latest version of a package which was only available in bullseye. In that case you may have added the line,apt update
thenapt install -t testing some-package
. But the problem is that unless you delete that line and do anotherapt update
, or add aAPT::Default-Release
, you are primed for an upgrade totesting
,Another option is 3rd party software. It's common for software which doesn't exist in Debian's official archive to give you a
*.deb
installer. I've seen*.deb
archives include a custom/etc/apt/sources.list.d/*.list
so that you get updates. It wouldn't be hard for them to say "well I need version X of this dependency, and I know it exists in bullseye, so I'll create a line to add a bullseye repo". It would by sloppy of them, but not impossible.So how to recover? There are three options at this point:
1: Complete the upgrade - Easiest/quickest
2: Downgrade - Hardest/Least likely to succeed
3: Re-install - Most reliable/Most downtime
To Complete the upgrade, first obviously fix the strange line in your
/etc/apt/sources.list[.d/]
. Then:Toggle between
upgrade
,dist-upgrade
,--fix-broken install
andautoremove
untilapt
finishes successfully everywhere.To downgrade (and this is likely to fail, I can't stress that enough):
First back everything up. Then, create
/etc/apt/preferences.d/buster
:Then upgrade like we did in step 1
Toggle between
upgrade
,dist-upgrade
,--fix-broken install
andautoremove
untilapt
finishes successfully everywhere.When you are happy, delete
/etc/apt/preferences.d/buster