libxcb1 install problem

[Hans-Werner Kneitinger]

Hello,
I'm Hans-Werner an running multiple PIs. After upgrading two of them
Raspbian from Buster to Bullseye one is good and the other is not so good.
Good is RPi 1 B, Minimal Installation.
Not so good is Raspberry Pi 2 Model B Rev 1.1, Rasbian Desktop

Problem:
dpkg: Fehler beim Bearbeiten des Archivs
/var/cache/apt/archive/libxcb1_1.14-3_armhf.deb (--unpack):
ci-Triggerdatei enthält unbekannte Anweisung »This«
"-> ci-triggerfile contains unknown instruction »This«"
Fehler traten auf beim Bearbeiten von:
/var/cache/apt/archives/libxcb1_1.14-3_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

How do I do the update:
1. Starting buster, apt update && apt upgrade -y, dpkg --audit, apt
autoremove -y && apt autoclean
2. Change /etc/apt/sources.list to deb
http://raspbian.raspberrypi.org/raspbian/ bullseye main contrib non-free rpi
3. Change /etc/apt/sources.list.d/raspi.list to deb
http://archive.raspberrypi.org/debian/ bullseye main
4. Did apt update, apt upgrade -y, apt full-upgrade -y

Upgrade on the 1s Pi runs without any problems. On the 2nd I have
multiple issues and solved the problem away with apt install -f, apt
upgrade -y/apt full-upgrade -y. It was always the ci-triggerfile
contains unknown instruction »This«" problem.

Some suggestions what I have done wrong and how to fix?
--
cu
hawe

[alister]

how did you 'Upgrade'
doing an in-place upgrade over an existing installation is not recommended
(which is a pain as creating a new SD card will overwrite your home
directory - not good)

best I have come up with so far is to backup /home/pi before recreating
the card & then copy it back (ensure you get all the hidden files)
you also need to re-install any extra software beyond the std install



--
Political speeches are like steer horns. A point here, a point there,
and a lot of bull in between.
-- Alfred E. Neuman

[Martin Gregorie]

On Thu, 11 Nov 2021 14:36:58 -0000 (UTC), alister wrote:

> how did you 'Upgrade'
> doing an in-place upgrade over an existing installation is not
> recommended (which is a pain as creating a new SD card will overwrite
> your home directory - not good)
>
> best I have come up with so far is to backup /home/pi before recreating
> the card & then copy it back (ensure you get all the hidden files)
> you also need to re-install any extra software beyond the std install

A trick that can make this easier is to:

While logged in as root:

1) cd /usr/
2) mv local /home
3) ln -s /home/local local
4) do a normal backup

In other words, move /usr/local to /home/local and set up /usr/local as a
symlink that points to /home/local and then make a backup that contains
the changes you just made.

This means that a normal backup that includes /home will include all the
stuff you've added to /usr/local/bin, /usr/local/man, /usr/local/etc
which are where you 'should' put lacally developed binaries and scripts
that you use from more than one login, together with the manpages and
config files used by your code.

Now, after a from-scratch install, al you need toi do is:
- restore /home from your latest backup. Delete the default /usr/local
structure (which is empty after a clean install, and replace it with a
symlink pointing to /home/local

Note: you should NOT add your own binaries to /cmds or /usr/cmds, put
their manpages in /usr/man or their config files in /etc because
nonstandard files in those places can be, and often are, deleted or
changed (if their names match new files in the distro). Instead. Put your
stuff in /usr/local/.... because it will be safe there

About the only self-developed stuff you ever need to put in /etc are cron
jobs and possible additions or changes in /etc/profile.d - and you should
keep copies on your working directory because its common for stuff in
/etc/cron* and/etc/profile.d to be changed by distro upgrades.

....sorry about the length of this post, but although older hands will
know this stuff, anybody whose first exposure to UNIX/Linux is via a
RaspberryPi almost certainly will not.


--
--
Martin | martin at
Gregorie | gregorie dot org

[druck]

On 11/11/2021 14:36, alister wrote:
> how did you 'Upgrade'
> doing an in-place upgrade over an existing installation is not recommended
> (which is a pain as creating a new SD card will overwrite your home
> directory - not good)

It might not be recommended, but it's never failed for me. I started on
the original 256MB Pi 1B, and have been through every OS release up to
the current one, not only that Pi 1B, but its been cloned to every other
model of Pi up to the 4B and those have all updated too.

> best I have come up with so far is to backup /home/pi before recreating
> the card & then copy it back (ensure you get all the hidden files)
> you also need to re-install any extra software beyond the std install

Low level the entire card so you have an exact backup, just in case,
then do the upgrade in place.

---druck

[Hans-Werner Kneitinger]

Am 11.11.21 um 21:45 schrieb druck:

> Low level the entire card so you have an exact backup, just in case,
> then do the upgrade in place.

I have done a image backup b4. After firs fail I have reloaded the Image
an done a 2nd try -> same result.
It seems something is wrong with my desktop installation, but don't know
what. Until now I have done 2 other updates in same way with the
buster-light version -> no problems.

--
cu
hawe

[Hans-Werner Kneitinger]

Am 11.11.21 um 15:36 schrieb alister:

> how did you 'Upgrade'
> doing an in-place upgrade over an existing installation is not recommended
> (which is a pain as creating a new SD card will overwrite your home
> directory - not good)

In place with monitor and keyboard attached, but from a terminal, not
from desktop. Desktop was not running, booting always in terminal mode.

> best I have come up with so far is to backup /home/pi before recreating
> the card & then copy it back (ensure you get all the hidden files)
> you also need to re-install any extra software beyond the std install

I have done a image backup b4. After first fail I have reloaded the

Image an done a 2nd try -> same result.
It seems something is wrong with my desktop installation, but don't know
what. Until now I have done 2 other updates in same way with the
buster-light version -> no problems.

Did you know which packages are for the desktop version? I would purge
them and maybe reinstall later. Desktop is not needed.

--
cu
hawe

[Martin Gregorie]

On Fri, 12 Nov 2021 09:28:50 +0100, Hans-Werner Kneitinger wrote:

> I have done a image backup b4. After first fail I have reloaded the
> Image an done a 2nd try -> same result.
> It seems something is wrong with my desktop installation, but don't know
> what. Until now I have done 2 other updates in same way with the
> buster-light version -> no problems.
>

Yes, but HOW exactly did you do the backup? Showing the commands you used
and the exact sequence you used them in, together with error messages
would give us something to analyse.

As it is we don't know:
- if you made the backup with dd, rsnapshot, rsync, gzip, or whatever
- what device the image is on
- how its partitioned
- why the backup failed, i.e. what error messages you saw.

[druck]

On 12/11/2021 08:24, Hans-Werner Kneitinger wrote:
> Am 11.11.21 um 21:45 schrieb druck:
>
>> Low level the entire card so you have an exact backup, just in case,
>> then do the upgrade in place.

Oops! That should read "low level copy" e.g. with dd

> I have done a image backup b4. After firs fail I have reloaded the Image
> an done a 2nd try -> same result.
> It seems something is wrong with my desktop installation, but don't know
> what. Until now I have done 2 other updates in same way with the
> buster-light version -> no problems.

Have you done a apt full-upgrade wit the current version before changing
apt.conf ?

---druck

[Hans-Werner Kneitinger]

Am 12.11.21 um 11:12 schrieb Martin Gregorie:

> As it is we don't know:
> - if you made the backup with dd, rsnapshot, rsync, gzip, or whatever
> - what device the image is on
> - how its partitioned
> - why the backup failed, i.e. what error messages you saw.

How do I do the update:
1. Starting buster, apt update && apt upgrade -y

1a.dpkg --audit, apt
1b autoremove -y && apt autoclean

2. Change /etc/apt/sources.list to deb

2a.http://raspbian.raspberrypi.org/raspbian/ bullseye main contrib
non-free rpi firmware

3. Change /etc/apt/sources.list.d/raspi.list to deb
http://archive.raspberrypi.org/debian/ bullseye main

4. Did apt update

4a apt upgrade -y
4b Some warnings did appear as I wrote above.
4c apt install -f
4d apt upgrade -y
4d have to repeat 4c and 4d view times until end

5 apt full-upgrade -y
5a Some warnings did appear as I wrote above.
5b apt install -f
5c apt full-upgrade -y
5d have to repeat 5b and 5c view times until end


Same procedure done on RPis (model1) without desktop. No issues, no need
to do 4b-4d and 5a-5c
--
cu
hawe

[Hans-Werner Kneitinger]

Am 12.11.21 um 18:25 schrieb druck:

> Have you done a apt full-upgrade wit the current version before changing
> apt.conf ?

no because Apt did not say that there are some packages hold or now or
have to be updated.

--

--
cu
hawe

[Richard Kettlewell]

Hans-Werner Kneitinger <hans-werner...@gmx.de> writes:
> I'm Hans-Werner an running multiple PIs. After upgrading two of them
> Raspbian from Buster to Bullseye one is good and the other is not so
> good.
> Good is RPi 1 B, Minimal Installation.
> Not so good is Raspberry Pi 2 Model B Rev 1.1, Rasbian Desktop
>
> Problem:
> dpkg: Fehler beim Bearbeiten des Archivs
> /var/cache/apt/archive/libxcb1_1.14-3_armhf.deb (--unpack):
> ci-Triggerdatei enthält unbekannte Anweisung »This«
> "-> ci-triggerfile contains unknown instruction »This«"
> Fehler traten auf beim Bearbeiten von:
> /var/cache/apt/archives/libxcb1_1.14-3_armhf.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Most likely, either libxcb1_1.14-3_armhf.deb or the installed triggers
file is corrupted.

Start by deleting /var/cache/apt/archive/libxcb1_1.14-3_armhf.deb and
trying again.

If that doesn’t work then the existing file is probably
/var/lib/dpkg/info/libxcb1:armhf.trigger
or possibly
/var/lib/dpkg/info/libxcb1.trigger

The contents should look something like this:

# Triggers added by dh_makeshlibs/13.3.2
activate-noawait ldconfig

If not, delete it and retry.

> Some suggestions what I have done wrong and how to fix?

I don’t know how one would get into this situation. Filesystem
corruption or a bug in dpkg, maybe.

BTW when quoting error messages it is much easier if you use an English
locale, rather than hand-translating them, because if the translation
isn’t an exact match to the English version in the source code then you
have to go via the *.po file anyway. Imagine some German text was
translated to English and back to German, and then someone asked you to
find the original.

--
https://www.greenend.org.uk/rjk/

[druck]

The only issues I've had upgrading on non-pi Linux systems (a Kbuntu
VM), is when the package system has been in unstable state.

This command often shows up problems.

dpkg --configure -a

The debsums program is useful to find packages which may be corrupted or
have missing files, use:-

apt install debsums
debsums -c | xargs -rd '\n' -- dpkg -S | cut -d : -f 1 | sort -u

If you've got any problems this will fix it by reinstalling the packages

debsums -c | xargs -rd '\n' -- dpkg -S | cut -d : -f 1 | sort -u | xargs
-rd '\n' -- apt-get install --reinstall

---druck

[Martin Gregorie]

On Sat, 13 Nov 2021 13:05:33 +0000, druck wrote:

> On 13/11/2021 05:58, Hans-Werner Kneitinger wrote:
>> Am 12.11.21 um 18:25 schrieb druck:
>>
>>> Have you done a apt full-upgrade wit the current version before
>>> changing apt.conf ?
>>
>> no because Apt did not say that there are some packages hold or now or
>> have to be updated.
>
> The only issues I've had upgrading on non-pi Linux systems (a Kbuntu
> VM), is when the package system has been in unstable state.
>

I had to finesse an in-situ upgrade from buster to bullseye on my old
512MB Rpi B.

Tweaks:
=======
1) As before I changed the versin name from 'buster' to 'bullseye'
in /etc/apt/sources.list and /etc/apt/sources.list.d/raspi.list

2) "sudo apt-get update" wasn't happy until I added 'ui' to
/etc/apt/sources.list - formerly it only needed to be in
/etc/apt/sources.list.d/raspi.list

2) "sudo apt-get dist-upgrade" complained that:

Calculating upgrade... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6+rpi1 is to be
installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be
caused by held packages.

This was fixed by running:

"sudo apt install gcc-8-base"

which installed a lot of packages, submmarised as:
41 upgraded, 22 newly installed, 4 to remove and 1029 not upgraded.
Need to get 61.9 MB of archives.

Then, for fun I ran "cat /proc/version", which told me I was now
running this version:

Linux version 5.10.63+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8
(Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu)
2.34) #1459 Wed Oct 6 16:40:27 BST 2021

=======

At this point I ran "sudo apt-get dist-upgrade" which pulled down and
installed another 1188 packages.

Then it was sit and watch - about the only thing that could be improved.
Thats because there were about 4 places whenever the installer found a
customised config file, which caused it to stop and wait for me to tell
it what to do (keep the old config, replace, or edit it). It would be
nicer if it kept track of modified config files and to ask these
questions as the last set of actions, since that would mean it wasn't
necessary to sit and watch the process in case it found a config file
that might need changing.

That said:
==========
Although the Pi seems to come up OK, there's a problem: I normally run it
as a headless, keyboardless system, only accessed over SSH. However,
after a reboot, it is inaccessible over my LAN and running

nmap -Pn rpiname

from a laptop reports that all ports on the PRi are 'filtered', i.e not
visible from outside.

Any suggestions for a fast way to re-establish access it via SSH would be
appreciated. Its so long since I enabled SSH access in the first place
that I've forgotten how I did that.


Grrrr. I'd really expect that the one thing an OS upgrade would NOT do is
to change

> This command often shows up problems.
>
> dpkg --configure -a
>
> The debsums program is useful to find packages which may be corrupted or
> have missing files, use:-
>
> apt install debsums debsums -c | xargs -rd '\n' -- dpkg -S | cut -d : -f
> 1 | sort -u
>
> If you've got any problems this will fix it by reinstalling the packages
>
> debsums -c | xargs -rd '\n' -- dpkg -S | cut -d : -f 1 | sort -u | xargs
> -rd '\n' -- apt-get install --reinstall
>
> ---druck

I had to finesse an in-situ upgrade from buster to bullseye on my old
512MB Rpi B.

Tweaks:
=======
1) As before I changed the versin name from 'buster' to 'bullseye'
in /etc/apt/sources.list and /etc/apt/sources.list.d/raspi.list

2) "sudo apt-get update" wasn't happy until I added 'ui' to
/etc/apt/sources.list - formerly it only needed to be in
/etc/apt/sources.list.d/raspi.list

3) "sudo apt-get dist-upgrade" complained:

Calculating upgrade... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6+rpi1 is to be
installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be
caused by held packages.

This was fixed by running:

"sudo apt install gcc-8-base"

which installed a lot of packages, submmarised as:
41 upgraded, 22 newly installed, 4 to remove and 1029 not upgraded.
Need to get 61.9 MB of archives.

Then, for fun I ran "cat /proc/version", which told me I was now
running this version:

Linux version 5.10.63+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8
(Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu)
2.34) #1459 Wed Oct 6 16:40:27 BST 2021

=======

At this point I ran "sudo apt-get dist-upgrade" which pulled down and
installed another 1188 packages.

Then it was sit and watch - about the only thing that could be improved.
Thats because there were about 4 places whenever the installer found a
customised config file, which caused it to stop and wait for me to tell
it what to do (keep the old config, replace, or edit it). It would be
nicer if it kept track of modified config files and to ask these
questions as the last set of actions, since that would mean it wasn't
necessary to sit and watch the process in case it found a config file
that might need changing.

That said:
==========
Although the Pi seems to come up OK, there's a problem: I normally run it
as a headless, keyboardless system, only accessed over SSH. However,
after a reboot, it is inaccessible over my LAN and running

nmap -Pn rpiname

from a laptop reports that all ports on the PRi are 'filtered', i.e not
visible from outside.

Any suggestions for a fast way to re-establish access it via SSH would be
appreciated. Its so long since I enabled SSH access in the first place
that I've forgotten how I did that.

Grrrr. I'd really expect that the one thing an OS upgrade would NOT do is
to change access to network ports.

[Martin Gregorie]

On Sat, 13 Nov 2021 21:34:32 -0000 (UTC), Martin Gregorie wrote:

> Any suggestions for a fast way to re-establish access it via SSH would
> be appreciated. Its so long since I enabled SSH access in the first
> place that I've forgotten how I did that.
>
> Grrrr. I'd really expect that the one thing an OS upgrade would NOT do

> is to mess with SSH access
>

LATER....

I'm now assuming that somehow I've managed to disable the sshd.service,
so have spent most of this evening trying unsuccessfully to find out
where systemd stores service-level information, such as whether
sshd.service is enabled, with the aim of sticking the RPi's SD card into
my Fedora-based laptop and editing it to set any flags needed to mark the
sshd.service as 'enabled', etc.

Unfortunately, I don't have a USB keyboard, though I do have a Benq
screen with HDMI input, which is why I'm looking at ways of editing the
SD card contents to resurrect SSH logins.

The main problem is that I can't find any documentation that says where
such service-level configuration data is kept. I'd hoped that

https://www.freedesktop.org/software/systemd/man/systemd.path.html

would help here, but while its good on telling you how to use systemd
tools to do things, its not all useful for describing where systemd
stores its configuration data, which is what I need.

Any pointers to better, comprehensive systemd documentation, particularly
anything describing where it keeps added control data such as whether a
service is enabled and/or running would be most welcome.

Still, if all else fails, I do have an up-to-date backup of the RPi.
Everything I need off it is in /home/* and /usr/local/* - that is, if
doing a clean install Bullseye install will leave SSH logins enabled by
default so I can SSH into the RPi and restore the contents of /home* and /
usr/local/* from the backup.

[Tauno Voipio]

Set up a zero-length file with the name 'ssh' on the /boot partition.
The partition can be accessed on the card from Mac OS or Windows, as
well as from any Linux, as the partition is in FAT format.

--

-TV

[Martin Gregorie]

I found that too, when I searched this morning, but thanks anyway.

However, it is only a very partial solution, because where nmap
previously thought the RPi doesn't exist, now it agrees that the RPi is
on my LAN, but says all the 1000 ports that it scanned are masked, i.e.
none are open. And, of course, I still can't ssh into it.

I've sent a message about this to raspberrypi.org, politely asking
whether putting 'ssh' in the boot partition should be sufficient to
enable SSH logins after first boot on a headless system.

IOW, have they tested it for SSH logins immediately after the first boot
into bullseye: it is the sort of thing that's easy to miss.

FWIW, although the majority of non-standard stuff I use is installed
locally under my login, so can be easily reinstalled using only ftp,
there are a few things that aren't, e.g. rsync, postfix, xinet and lynx
that would make a clean install's aftermath a somewhat more painful than
a version-upgrade.

[Martin Gregorie]

> Silly question perhaps... Presuming the R-Pi in question is using WiFi,
> could your WiFi/router be blocking it?
>
No, and not a silly question. the RPi doesn't have wi-fi. It is a 512MB
Pi 2B, running off a 16GB SD card and with a wired connection to my wired-
only LAN.

[Hans-Werner Kneitinger]

Am 13.11.21 um 14:05 schrieb druck:

> This command often shows up problems.
>
> dpkg --configure -a

Done, No messages.

> The debsums program is useful to find packages which may be corrupted or
> have missing files, use:-
>
> apt install debsums
> debsums -c | xargs -rd '\n' -- dpkg -S | cut -d : -f 1 | sort -u
>
> If you've got any problems this will fix it by reinstalling the packages

Done, rkhunter was reported.

> debsums -c | xargs -rd '\n' -- dpkg -S | cut -d : -f 1 | sort -u | xargs
> -rd '\n' -- apt-get install --reinstall

Done, seems to be repaired. No erros reorted when doing the command above.

Doing apt update && apt ugrade -y
---
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
1 package can be upgraded. Run 'apt list --upgradable' to see it.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
libxcb1
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/136 kB of archives.
After this operation, 10.2 kB of additional disk space will be used.
(Reading database ... 213580 files and directories currently installed.)
Preparing to unpack .../libxcb1_1.14-3_armhf.deb ...
dpkg: error processing archive
/var/cache/apt/archives/libxcb1_1.14-3_armhf.deb (--unpack):
triggers ci file contains unknown directive 'This'
Errors were encountered while processing:

/var/cache/apt/archives/libxcb1_1.14-3_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

---

My workaround for now is setting libxcb1 1.13.1-2 on hold with aptitude.
Thanx for helping

--
cu
hawe

[Richard Kettlewell]

Hans-Werner Kneitinger <hans-werner...@gmx.de> writes:
> Am 13.11.21 um 14:05 schrieb druck:
>> This command often shows up problems.
>>
>> dpkg --configure -a
>
> Done, No messages.
>
>> The debsums program is useful to find packages which may be
>> corrupted or have missing files, use:-
>>
>> apt install debsums
>> debsums -c | xargs -rd '\n' -- dpkg -S | cut -d : -f 1 | sort -u
>>
>> If you've got any problems this will fix it by reinstalling the packages
> Done, rkhunter was reported.
>
>> debsums -c | xargs -rd '\n' -- dpkg -S | cut -d : -f 1 | sort -u |
>> xargs -rd '\n' -- apt-get install --reinstall
> Done, seems to be repaired. No erros reorted when doing the command above.

None of this will help, because your problem is a corrupted triggers
file.

See my other posting for what you should try.

--
https://www.greenend.org.uk/rjk/

[Hans-Werner Kneitinger]

Am 13.11.21 um 11:29 schrieb Richard Kettlewell:

> If not, delete it and retry.

Thanx, that solved the issue.
Sorry, I can't try it yesterday because of lack of time.
--
cu
hawe

[Richard Kettlewell]

Hans-Werner Kneitinger <hans-werner...@gmx.de> writes:
> Am 13.11.21 um 11:29 schrieb Richard Kettlewell:
>
>> If not, delete it and retry.
>
> Thanx, that solved the issue.

Glad to hear it!

--
https://www.greenend.org.uk/rjk/