odd result for sudo dpkg -V

[Gene Heskett]

Greetings all;

Does it work on debian arm?

Thanks!

Cheers, Gene Heskett.

[Markus Weyermann]

I ran it on RPi4B RaspberryPi  OS aarch64 Buster and got

:~ $ sudo dpkg -V
??5?????? c /etc/skel/.bashrc
??5?????? c /etc/elasticsearch/elasticsearch.yml
??5??????   /usr/lib/systemd/system/elasticsearch.service
??5?????? c /etc/init.d/elasticsearch
??5?????? c /etc/php/7.4/mods-available/apcu.ini
??5?????? c /etc/php/7.4/fpm/pool.d/www.conf
??5?????? c /etc/fail2ban/jail.d/defaults-debian.conf
??5?????? c /etc/apache2/apache2.conf
??5?????? c /etc/rsyslog.conf
??5?????? c /etc/sudoers.d/010_pi-nopasswd
??5?????? c /etc/redis/redis.conf
??5?????? c /etc/mail.rc
??5?????? c /etc/cron.d/certbot
??5?????? c /etc/default/useradd
??5?????? c /etc/email-addresses
??5?????? c /etc/exim4/passwd.client
??5?????? c /etc/dphys-swapfile
??5?????? c /etc/default/rpi-eeprom-update
??5?????? c /etc/login.defs

cheers
markus

Post by Gene Heskett
Greetings all;
Does it work on debian arm?
Thanks!
Cheers, Gene Heskett.

[Gene Heskett]

Post by Markus Weyermann
I ran it on RPi4B RaspberryPi  OS aarch64 Buster and got
:~ $ sudo dpkg -V
??5?????? c /etc/skel/.bashrc
??5?????? c /etc/elasticsearch/elasticsearch.yml
??5??????   /usr/lib/systemd/system/elasticsearch.service
??5?????? c /etc/init.d/elasticsearch
??5?????? c /etc/php/7.4/mods-available/apcu.ini
??5?????? c /etc/php/7.4/fpm/pool.d/www.conf
??5?????? c /etc/fail2ban/jail.d/defaults-debian.conf
??5?????? c /etc/apache2/apache2.conf
??5?????? c /etc/rsyslog.conf
??5?????? c /etc/sudoers.d/010_pi-nopasswd
??5?????? c /etc/redis/redis.conf
??5?????? c /etc/mail.rc
??5?????? c /etc/cron.d/certbot
??5?????? c /etc/default/useradd
??5?????? c /etc/email-addresses
??5?????? c /etc/exim4/passwd.client
??5?????? c /etc/dphys-swapfile
??5?????? c /etc/default/rpi-eeprom-update
??5?????? c /etc/login.defs

Thats exactly what I got, around 200 of them. And its quasi-random, I
ran it again on my raspian pi4b with a |wc -l and only got 87 next time.

I think the armhf and arm64 versions have a bug. The machine is otherwise
fine and could be carveing steel 2 or 3 minutes after I got to it.
Takes that long to properly chuck up a workpiece.

That is not a commonly used option, but I used it because dpkg reported
an incomplete quite a few packages update this morning and I was looking
for the cause. But a sudo -E synaptic said its all fine, no errors, no
fix-brokens etc.

So that -V option, and the dh dependency checker both need a wee bit of
TLC.

The dependency checker missed some python stuff needed to build linuxcnc
from github, but I found all that 3 or 4 months back. That particular
rpi4 is a full blown armhf development system with a realtime kernel in
addition to running a 70 yo sheldon lathe with linuxcnc.

Post by Markus Weyermann
cheers
markus

Thanks Markus.

Take care & stay well now.

Cheers, Gene Heskett.

[David Pottage]

Post by Markus Weyermann
I ran it on RPi4B RaspberryPi  OS aarch64 Buster and got

Please do note that we (Debian) do not control how dpkg works on
RaspberryPi OS -- It is a Debian derivative, but it deviates quite a
bit from us.
I suggest you bring this issue up on the Raspberry Pi Foundation's
tracker, as it does not seem to be related to Debian.

I got similar results on my RockPro64, It is running Armbain rather than
pure Debian, but as far as I am aware only the kernel comes from
Armbain, and the rest of userspace is from Debian. In other words it is
probably a Debian bug, and I don't think we can blame RaspberryPi OS for it.

Also, I run etckeeper on my box, so I have git history for all the files
reported. When I ran dpkg -V I got back a list of 31 files.  Of those
the git history shows that I had modified about half of them, but the
rest where original from when I setup the box, or installed when I
upgraded to Bullseye last week.

[Phil Endecott]

Post by David Pottage
I got similar results on my RockPro64, It is running
Armbain rather than pure Debian, but as far as I am
aware only the kernel comes from Armbain, and the rest
of userspace is from Debian. In other words it is probably
a Debian bug, and I don't think we can blame RaspberryPi OS
for it.

No, Armbian has changes to assorted things in /etc which will
be reported by dpkg --verify. I have previously asked how to
reduce Armbian to just a custom kernel with vanilla Debian
everywhere else but didn't make much progress; the Armbian
people think their changes are improvements or bug fixes. (I
would be surprised if you see hundreds of files though.)

Here are my results for assorted ARM systems running variants
of Debian bullseye:

AWS cloud instance: 4 files in /etc, all modified by me.

QEMU vm: 1 file in /etc, modified by me.

32-bit ODROID NAS running Armbian: 19 files in /etc, about
5 modified by me, the others modified by Armbian.

ODROID C2 originally installed with "odrobian" but modified
by me to approach vanilla Debian with the odrobian kernel:
10 files in /etc, nearly all modified by me.

Nvidia Jetson Xavier NX with "Jetpack" installed over Debian:
20 files, about 3 modified by me.


I don't see any evidence that there is a problem with dpkg in
Debian; all of these derivatives make changes to configuration
files and similar which dpkg --verify correctly reports.


Cheers, Phil.

[Gene Heskett]

Post by Phil Endecott

Post by David Pottage
I got similar results on my RockPro64, It is running
Armbain rather than pure Debian, but as far as I am
aware only the kernel comes from Armbain, and the rest
of userspace is from Debian. In other words it is probably
a Debian bug, and I don't think we can blame RaspberryPi OS
for it.

No, Armbian has changes to assorted things in /etc which will
be reported by dpkg --verify. I have previously asked how to
reduce Armbian to just a custom kernel with vanilla Debian
everywhere else but didn't make much progress; the Armbian
people think their changes are improvements or bug fixes. (I
would be surprised if you see hundreds of files though.)
Here are my results for assorted ARM systems running variants
AWS cloud instance: 4 files in /etc, all modified by me.
QEMU vm: 1 file in /etc, modified by me.
32-bit ODROID NAS running Armbian: 19 files in /etc, about
5 modified by me, the others modified by Armbian.
ODROID C2 originally installed with "odrobian" but modified
10 files in /etc, nearly all modified by me.
20 files, about 3 modified by me.
I don't see any evidence that there is a problem with dpkg in
Debian; all of these derivatives make changes to configuration
files and similar which dpkg --verify correctly reports.
Cheers, Phil.

Note that I as the OP was using dpkg -V, not --verify. Might their be a
difference?

Cheers, Gene Heskett.

[deloptes]

Post by Gene Heskett
Note that I as the OP was using dpkg -V, not --verify. Might their be a
difference?
Cheers, Gene Heskett.

Gene always check the -h vs --help or man page

dpkg --help
-V|--verify [<package>...] Verify the integrity of package(s).

package is optional and if not provided would check all packages installed
but it seems this is broken

BR

[Gene Heskett]

Post by deloptes

Post by Gene Heskett
Note that I as the OP was using dpkg -V, not --verify. Might their
be a difference?
Cheers, Gene Heskett.

Gene always check the -h vs --help or man page
dpkg --help
-V|--verify [<package>...] Verify the integrity of package(s).
package is optional and if not provided would check all packages
installed but it seems this is broken
BR

well, I'm getting an almost sensible listing from the wintel boxes,
although the attributes reported are garbage in all cases of an error.
an ls -l shows the attributes correctly. And it may be timing or buffer
related as it goes down if the "|wc -l" is added, the errors are less.
And still somewhat randomized, 80 something on the pi yesterday and 74
today and only 4 pkgs have been updated in the meantime. All instances
were as sudo of coarse.

So I believe the --verify or -V, option needs some tlc in all 6 cases
here. 5 wintel boxes and a rpi4b, all heavily customized, with old but
realtime kernels. but not the same kernels as the pi is totally home
brewed including the install method which on a u-boot system is totally
undocumented so I had to invent my own method. I put it up on my web
page so I might not be the only one using it. Certainly less than 5
users on this whole ball of rock and water. And totaly against armbian
policy, I am blacklisted from their forum because of it. The NIH
syndrome's finest example.

It seems to really get an upset tummy if the file perms are 0600 like
some of amanda's stuff that can only be read by amanda, so even root
can't see them. Which is correct but the error msg isn't exactly
accurate, and in every case on 6 machines here, the attributes reported
are all wrong and identical, pulled out of of very thin air.

Cheers, Gene Heskett.

[Daniel Serpell]

Hi,

Post by Gene Heskett

Post by deloptes

Post by Gene Heskett
Note that I as the OP was using dpkg -V, not --verify. Might their
be a difference?
Cheers, Gene Heskett.

Gene always check the -h vs --help or man page
dpkg --help
-V|--verify [<package>...] Verify the integrity of package(s).
package is optional and if not provided would check all packages
installed but it seems this is broken
BR

well, I'm getting an almost sensible listing from the wintel boxes,
although the attributes reported are garbage in all cases of an error.
an ls -l shows the attributes correctly.

Please, read the manual.

The reported codes are not the file attributes, those are the status of the
performed checks. DPKG only has support for verifying the MD5, so the result
is always "??.??????" for a passed check and "??5??????" for a failed check.

And the reported failed checks on Armbian are because the "armbian-config"
package modifies configuration files of other packages.

Here, in a minimal Armbian install, I got:

??5?????? c /etc/skel/.bashrc
??5?????? c /etc/logrotate.d/apt
??5?????? c /etc/systemd/journald.conf
??5?????? c /etc/NetworkManager/NetworkManager.conf
??5?????? c /etc/default/rng-tools-debian
??5?????? c /etc/logrotate.d/alternatives
??5?????? c /etc/logrotate.d/dpkg
??5?????? c /etc/logrotate.d/aptitude
??5?????? c /etc/sysctl.conf
??5?????? c /etc/logcheck/violations.ignore.d/rng-tools
??5?????? c /etc/logcheck/ignore.d.server/rng-tools
??5?????? c /etc/default/rng-tools
??5?????? /etc/armbian-release
??5?????? /etc/default/armbian-ramlog.dpkg-dist
??5?????? /etc/default/armbian-zram-config.dpkg-dist
??5?????? c /etc/issue
??5?????? c /etc/issue.net
??5?????? c /etc/update-motd.d/10-uname
??5?????? c /etc/initramfs-tools/initramfs.conf
??5?????? c /etc/lightdm/lightdm-gtk-greeter.conf

As you see, all are configuration files modified by Armbian.

In the same hardware, a SID install reports all checks OK.

Have Fun!

[Gene Heskett]

Post by Daniel Serpell
Hi,

Post by Gene Heskett

Post by deloptes

Post by Gene Heskett
Note that I as the OP was using dpkg -V, not --verify. Might
their be a difference?
Cheers, Gene Heskett.

Gene always check the -h vs --help or man page
dpkg --help
-V|--verify [<package>...] Verify the integrity of
package(s).
package is optional and if not provided would check all packages
installed but it seems this is broken
BR

well, I'm getting an almost sensible listing from the wintel boxes,
although the attributes reported are garbage in all cases of an
error. an ls -l shows the attributes correctly.

Please, read the manual.

I have, but it rambles. So I did not note that. This is a much better
explanation in that it actualy explains the results. Thanks a bunch.

Post by Daniel Serpell
The reported codes are not the file attributes, those are the status
of the performed checks. DPKG only has support for verifying the MD5,
so the result is always "??.??????" for a passed check and "??5??????"
for a failed check.
And the reported failed checks on Armbian are because the
"armbian-config" package modifies configuration files of other
packages.

Should that not result in a more consistent number? I got nearly 90 the
first time.
I got 74 the last time I ran it on the pi, since nothing was been changed
since, I am running it again. This pi has lots more stuff installed as
its a full development system for LinuxCNC. Humm, after almost an hour,
I got 74 again. There is always the possibility I didn't use a sudo the
first time.

Thanks Daniel.

Post by Daniel Serpell
??5?????? c /etc/skel/.bashrc
??5?????? c /etc/logrotate.d/apt
??5?????? c /etc/systemd/journald.conf
??5?????? c /etc/NetworkManager/NetworkManager.conf
??5?????? c /etc/default/rng-tools-debian
??5?????? c /etc/logrotate.d/alternatives
??5?????? c /etc/logrotate.d/dpkg
??5?????? c /etc/logrotate.d/aptitude
??5?????? c /etc/sysctl.conf
??5?????? c /etc/logcheck/violations.ignore.d/rng-tools
??5?????? c /etc/logcheck/ignore.d.server/rng-tools
??5?????? c /etc/default/rng-tools
??5?????? /etc/armbian-release
??5?????? /etc/default/armbian-ramlog.dpkg-dist
??5?????? /etc/default/armbian-zram-config.dpkg-dist
??5?????? c /etc/issue
??5?????? c /etc/issue.net
??5?????? c /etc/update-motd.d/10-uname
??5?????? c /etc/initramfs-tools/initramfs.conf
??5?????? c /etc/lightdm/lightdm-gtk-greeter.conf
As you see, all are configuration files modified by Armbian.
In the same hardware, a SID install reports all checks OK.
Have Fun!

Cheers, Gene Heskett.

[deloptes]

I ran it on a clean Debian, on my Raspberry p400 (using one of the
??5?????? c /etc/fuse.conf
??5?????? c /etc/default/raspi-firmware

I do not think it has to do with RPI. It is behaving the same in Debian (I
tested on Buster)
IMO this is somewhere buffer overflowing