libxcb1 install problem

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.

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.

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

---druck

Am 11.11.21 um 21:45 schrieb druck:

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.

Am 11.11.21 um 15:36 schrieb alister:

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

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.

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.

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

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

---druck

Am 12.11.21 um 11:12 schrieb Martin Gregorie:

How do I do the update:

1. Starting buster, apt update && apt upgrade -y

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

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

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

1. Change /etc/apt/sources.list.d/raspi.list to deb
   formatting link
   bullseye main

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

Am 12.11.21 um 18:25 schrieb druck:

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

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.

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.

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

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

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.

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

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.

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.

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.

On Sun, 14 Nov 2021 18:18:06 -0000 (UTC), Martin Gregorie snipped-for-privacy@mydomain.invalid declaimed the following:

Silly question perhaps... Presuming the R-Pi in question is using WiFi, could your WiFi/router be blocking it?

I know some routers default to not allowing LAN access to WiFi devices, limiting then to just WAN side. Mostly the routers used in "public" WiFi areas.

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.

Am 13.11.21 um 14:05 schrieb druck:

Done, No messages.

Done, rkhunter was reported.

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

Doing apt update && apt ugrade -y

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

See my other posting for what you should try.