odd result for sudo dpkg -V

[Gene Heskett]

Greetings all;

Does it work on debian arm?

Thanks!

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[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


Am 05.11.21 um 13:56 schrieb Gene Heskett:

[Gene Heskett]

On Friday 05 November 2021 10:22:11 Markus Weyermann wrote:

> 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.

> cheers
> markus

Thanks Markus.

Take care & stay well now.

[Gunnar Wolf]

Gene Heskett dijo [Fri, Nov 05, 2021 at 12:32:44PM -0400]:

> On Friday 05 November 2021 10:22:11 Markus Weyermann wrote:
>
> > 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.

> 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.

Ugh, that is even worse! :-(

I ran it on a clean Debian, on my Raspberry p400 (using one of the
Bullseye images from https://raspi.debian.net/), and got:

root@rpi-p400:~# dpkg -V
??5?????? c /etc/fuse.conf
??5?????? c /etc/default/raspi-firmware
root@rpi-p400:~#

Both are conffiles, and while I don't remember (but don't rule out)
having modified the first one, I'm sure I have touched the second one.

I rebooted the system and ran it again, and got the exact same
results.

> 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.

I suggest you bring this issue up on the Raspberry Pi Foundation's
tracker, as it does not seem to be related to Debian.

[David Pottage]

On 05/11/2021 18:19, Gunnar Wolf wrote:
> Gene Heskett dijo [Fri, Nov 05, 2021 at 12:32:44PM -0400]:
>> On Friday 05 November 2021 10:22:11 Markus Weyermann wrote:
>>
>>> 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.

--

David Pottage

[deloptes]

Gunnar Wolf wrote:

> I ran it on a clean Debian, on my Raspberry p400 (using one of the
> Bullseye images from https://raspi.debian.net/), and got:
>
> root@rpi-p400:~# dpkg -V
> ??5?????? c /etc/fuse.conf
> ??5?????? c /etc/default/raspi-firmware
> root@rpi-p400:~#

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

--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

[Phil Endecott]

David Pottage wrote:
> 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]

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

[deloptes]

>
> 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]

On Sunday 07 November 2021 03:19:09 deloptes wrote:

> > 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.

[Daniel Serpell]

Hi,

El Sun, Nov 07, 2021 at 03:54:50PM -0500, Gene Heskett escribio:

> On Sunday 07 November 2021 03:19:09 deloptes wrote:
>
> > > 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]

On Monday 08 November 2021 11:19:12 Daniel Serpell wrote:

> Hi,
>
> El Sun, Nov 07, 2021 at 03:54:50PM -0500, Gene Heskett escribio:
> > On Sunday 07 November 2021 03:19:09 deloptes wrote:
> > > > 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.

> 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.

> 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!