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)