• libxcb1 install problem

    From Hans-Werner Kneitinger@3:770/3 to All on Wed Nov 10 07:47:51 2021
    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From alister@3:770/3 to Hans-Werner Kneitinger on Thu Nov 11 14:36:58 2021
    On Wed, 10 Nov 2021 07:47:51 +0100, Hans-Werner Kneitinger wrote:

    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?

    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to alister on Thu Nov 11 15:28:15 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to alister on Thu Nov 11 20:45:59 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Hans-Werner Kneitinger@3:770/3 to All on Fri Nov 12 09:28:50 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Hans-Werner Kneitinger@3:770/3 to All on Fri Nov 12 09:24:39 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to Hans-Werner Kneitinger on Fri Nov 12 10:12:23 2021
    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.


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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Hans-Werner Kneitinger on Fri Nov 12 17:25:15 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Hans-Werner Kneitinger@3:770/3 to All on Sat Nov 13 06:57:06 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Hans-Werner Kneitinger@3:770/3 to All on Sat Nov 13 06:58:50 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Richard Kettlewell@3:770/3 to Hans-Werner Kneitinger on Sat Nov 13 10:29:40 2021
    Hans-Werner Kneitinger <hans-werner.kneitinger@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/

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Hans-Werner Kneitinger on Sat Nov 13 13:05:33 2021
    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to druck on Sat Nov 13 21:34:32 2021
    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 | martin at
    Gregorie | gregorie dot org
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to Martin Gregorie on Sun Nov 14 01:21:17 2021
    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.


    --
    --
    Martin | martin at
    Gregorie | gregorie dot org
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Tauno Voipio@3:770/3 to Martin Gregorie on Sun Nov 14 16:40:01 2021
    On 14.11.21 3.21, Martin Gregorie wrote:
    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.


    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to Tauno Voipio on Sun Nov 14 18:18:06 2021
    On Sun, 14 Nov 2021 16:40:01 +0200, Tauno Voipio wrote:

    On 14.11.21 3.21, Martin Gregorie wrote:
    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.


    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.


    --
    --
    Martin | martin at
    Gregorie | gregorie dot org
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to All on Mon Nov 15 00:07:11 2021
    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.


    --
    --
    Martin | martin at
    Gregorie | gregorie dot org
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Sun Nov 14 18:54:30 2021
    On Sun, 14 Nov 2021 18:18:06 -0000 (UTC), Martin Gregorie <martin@mydomain.invalid> declaimed the following:



    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.


    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.


    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Hans-Werner Kneitinger@3:770/3 to All on Tue Nov 16 08:44:23 2021
    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
  • From Richard Kettlewell@3:770/3 to Hans-Werner Kneitinger on Tue Nov 16 09:38:16 2021
    Hans-Werner Kneitinger <hans-werner.kneitinger@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.

    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

    See my other posting for what you should try.

    --
    https://www.greenend.org.uk/rjk/
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)