OK, so basically this is due to the usrmerge change, that appears to be
driven by Redhat who recommend reinstalls for each new major version. It
was adopted by Debian and hence Uyuni and you haven't got a reliable way
to apply the merge during the in-place upgrades that you historically
supported;
Ah, I now see what you mean by the usrmerge. However I think that just
reinforces my comments above. It doesn't make any sense for the
installed package file to be installed in /sbin if /sbin is a symlink to
/usr/sbin. if /usr/sbin is the canonical directory, and /sbin is an
alias/symlink, then the
Actually I just re-read and saw that you indicated /sbin was the
symlink, which seems really strange because dpkg -L shows
/sbin/apparmor_parser as a file in the apparmor package, but not
/usr/sbin.
ndco-admin@CARMD-EV-ALBLD7:~$ dpkg -L apparmor
/.
/etc
/etc/apparmor
/etc/apparmor/parser.conf
/etc
Also
~$ dpkg -S /usr/sbin/apparmor_parser
dpkg-query: no path found matching pattern /usr/sbin/apparmor_parser
~$ dpkg -S /sbin/apparmor_parser
apparmor: /sbin/apparmor_parser
so it seems pretty messed up to me that the package file list would
include the symbolic link but not the actual file. Som
The /usr/sbin file not a symlink when it's causing an error. I'm
guessing that it's a hard link but that the package upgrade is somehow
deleting the /sbin directory entry (because it's the only one listed in
the dpkg -L output) and building a new inode for the new file contents,
but leaving the /us
That's a good question. I'm not sure of the exact history of these
systems, but I'm under the impression that they've gone through dist-
upgrades from as least one older LTS and more likely at least 2 (i.e.
from 16.04 to 18.04, to 20.04), but that predates my involvement. That
said, when I looked a
Public bug reported:
There appears to be two copies of apparmor_parser installed by previous
versions of the apparmor package, in /sbin and /usr/sbin. When updating
the apparmor package to apparmor-2.13.3-7ubuntu5.2, only the
/sbin/apparmor_parser executable is updated and the /usr/sbin copy is
le
Public bug reported:
We have an Ubuntu 18 installation using xfs file systems
user@hostname:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 19896400 1989640 0% /dev
tmpfs 404008 848403160 1% /run
/dev/sda19754624 308337
8 matches
Mail list logo
