dpkg: error processing package usrmerge (--configure):

[Andreas Kohlbach]

OS ist Debian testing (jaja... ;-).

aptitude bricht mit obiger Fehlermeldung ab. Google findet nichts
darüber. Komplett:

====

E: usrmerge failed.
dpkg: error processing package usrmerge (--configure):
installed usrmerge package post-installation script subprocess returned
error exit status 1
Errors were encountered while processing: usrmerge
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up usrmerge (31) ...

FATAL ERROR:
Both /sbin/dhcpcd and /usr/sbin/dhcpcd exist.

You can try correcting the errors reported and running again
/usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
Do not install or update other Debian packages until the program
has been run successfully.

====

(Debian will zudem Tonnen updaten, was nun nicht geht)

Auch zu:

Both /sbin/dhcpcd and /usr/sbin/dhcpcd exist.

findet Google nichts! (Nach dem Posting hier wohl schon...)

/sbin/dhcpcd ist ein Link auf /etc/alternatives/dhcpcd , und das auf
/sbin/dhcpcd3 , was ein Shell-Skript ist.

Ich könnte /sbin/dhcpcd einfach löschen, oderdhcpcd ganz entfernen
(brauche ich ggf. aber noch mal). Oder abwarten.

Was sollte ich tun?
--
Andreas

[Peter J. Holzer]

On 2022-09-24 21:08, Andreas Kohlbach <a...@spamfence.net> wrote:
> OS ist Debian testing (jaja... ;-).

Schon länger, or stellst du gerade erst um?

> aptitude bricht mit obiger Fehlermeldung ab. Google findet nichts
> darüber. Komplett:
>
>====
>
> E: usrmerge failed.
> dpkg: error processing package usrmerge (--configure):
> installed usrmerge package post-installation script subprocess returned
> error exit status 1
> Errors were encountered while processing: usrmerge
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Setting up usrmerge (31) ...
>
> FATAL ERROR:
> Both /sbin/dhcpcd and /usr/sbin/dhcpcd exist.
>

[...]

> /sbin/dhcpcd ist ein Link auf /etc/alternatives/dhcpcd , und das auf
> /sbin/dhcpcd3 , was ein Shell-Skript ist.

Und was ist /usr/sbin/dhcpd?

Wenn das nicht auch ein Symlink auf das gleiche Executable ist:
Hast Du da zwei verschiedene dhcpds installiert? Das ist vielleicht eine
Situation, mit der der Autor von usrmerge nicht gerechnet hat. Wäre
einen Bug-Report wert.

> Ich könnte /sbin/dhcpcd einfach löschen, oderdhcpcd ganz entfernen
> (brauche ich ggf. aber noch mal). Oder abwarten.
>
> Was sollte ich tun?

Pragmatisch: Das dhcpd-Paket oder die dhcpd-Pakete entfernen. Upgraden.
Erst wieder installieren, wenn Du es wirklich brauchst.

Wenn Du Debian helfen willst: Bug-Report einwerfen. Auf Nachfragen
geduldig und sorgfältig antworten.

hp

[Peter J. Holzer]

On 2022-09-24 23:05, Peter J. Holzer <hjp-u...@hjp.at> wrote:
> On 2022-09-24 21:08, Andreas Kohlbach <a...@spamfence.net> wrote:
>> /sbin/dhcpcd ist ein Link auf /etc/alternatives/dhcpcd , und das auf
>> /sbin/dhcpcd3 , was ein Shell-Skript ist.
>
> Und was ist /usr/sbin/dhcpd?

Ups. "dhcpcd" nicht "dhcpd". Da habe ich ein "c" überlesen. Bitte im
Rest des Postings überall einfügen :-), ändert aber inhaltlich nichts.

hp

[Kay Martinen]

Am 25.09.22 um 01:16 schrieb Peter J. Holzer:

> On 2022-09-24 23:05, Peter J. Holzer <hjp-u...@hjp.at> wrote:
>> On 2022-09-24 21:08, Andreas Kohlbach <a...@spamfence.net> wrote:
>>> /sbin/dhcpcd ist ein Link auf /etc/alternatives/dhcpcd , und das auf
>>> /sbin/dhcpcd3 , was ein Shell-Skript ist.

Der Zweck von usrmerge ist doch alles verteilt liegende in einen zweig
zu legen und stattdessen nur noch links dorthin zu haben/pflegen...

>> Und was ist /usr/sbin/dhcpd?
>
> Ups. "dhcpcd" nicht "dhcpd". Da habe ich ein "c" überlesen. Bitte im
> Rest des Postings überall einfügen :-), ändert aber inhaltlich nichts.

Was sich ändert: er oder sein PC bekommt nach deinstallation keine IP
mehr dynamisch zugewiesen. Wenn der installiert ist sollte man annehmen
das der dhcpc auch benutzt wird.

Manuell in /etc/network/interfaces eine Feste IP konfigurieren ist seit
NM ja wohl auch ähm "Unmodern" geworden. Und dann scheint debian doch
jetzt netplan zu präferieren. K.A. wo der seine konfig haben will.

Da vermisse ich die Zeiten als sowas wirklich noch ALLES unter /etc lag.
Doch dann kam polly ähh systemd... [Nein, kein Bashing. Aber ist doch so!]

Jedenfalls würde ich für solche experimente kein Testing nehmen und wenn
dann nach der neuinstallation ERST usrmerge und dann weiteres
installieren. Das dürfte zumindest die chance auf solche Fehler
minimieren. Andererseits könnte man das auch Fehlervermeidung nennen und
wenn man Testing als Bughunter nutzt dann... Feuer Frei! :-)


Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Peter J. Holzer]

On 2022-09-25 00:38, Kay Martinen <use...@martinen.de> wrote:
> Am 25.09.22 um 01:16 schrieb Peter J. Holzer:
>> On 2022-09-24 23:05, Peter J. Holzer <hjp-u...@hjp.at> wrote:
>>> On 2022-09-24 21:08, Andreas Kohlbach <a...@spamfence.net> wrote:
>>>> /sbin/dhcpcd ist ein Link auf /etc/alternatives/dhcpcd , und das auf
>>>> /sbin/dhcpcd3 , was ein Shell-Skript ist.
>
> Der Zweck von usrmerge ist doch alles verteilt liegende in einen zweig
> zu legen und stattdessen nur noch links dorthin zu haben/pflegen...

Ja, eh. Und wenn das verteilt Liegende widersprüchlich ist, schlägt das
Zusammenlegen fehl.

>>> Und was ist /usr/sbin/dhcpd?
>>
>> Ups. "dhcpcd" nicht "dhcpd". Da habe ich ein "c" überlesen. Bitte im
>> Rest des Postings überall einfügen :-), ändert aber inhaltlich nichts.
>
> Was sich ändert: er oder sein PC bekommt nach deinstallation keine IP
> mehr dynamisch zugewiesen. Wenn der installiert ist sollte man annehmen
> das der dhcpc auch benutzt wird.

Andreas hat geschrieben "brauche ich vielleicht später wieder einmal".
Ich schließe daraus, dass er es derzeit nicht braucht. Kann natürlich
sein, dass er nur nicht weiß, dass er es braucht.

> Manuell in /etc/network/interfaces eine Feste IP konfigurieren ist seit
> NM ja wohl auch ähm "Unmodern" geworden. Und dann scheint debian doch
> jetzt netplan zu präferieren. K.A. wo der seine konfig haben will.

/etc/netplan.

> Da vermisse ich die Zeiten als sowas wirklich noch ALLES unter /etc lag.
> Doch dann kam polly ähh systemd... [Nein, kein Bashing. Aber ist doch so!]

Da liegt die Config auch unter /etc.

> Jedenfalls würde ich für solche experimente kein Testing nehmen und wenn
> dann nach der neuinstallation ERST usrmerge und dann weiteres
> installieren.

Deshalb meine Frage, ob das bei der Umstellung auf Testing passiert ist
oder bei einem Upgrade innerhalb von Testing. Wenn letzteres, dann gab
es keine Neuinstallation und Andreas hat vermutlich usrmerge gar nicht
gezielt installiert, sondern das ist über eine Dependency mitgekommen
(wenn ich mich recht entsinne, soll ja mit dem nächsten Release der
root-usr-Merge mandatory werden).

hp

[Kay Martinen]

Am 25.09.22 um 16:04 schrieb Peter J. Holzer:

> On 2022-09-25 00:38, Kay Martinen <use...@martinen.de> wrote:
>> Am 25.09.22 um 01:16 schrieb Peter J. Holzer:
>>> On 2022-09-24 23:05, Peter J. Holzer <hjp-u...@hjp.at> wrote:
>>>> On 2022-09-24 21:08, Andreas Kohlbach <a...@spamfence.net> wrote:
>>>>> /sbin/dhcpcd ist ein Link auf /etc/alternatives/dhcpcd , und das auf
>>>>> /sbin/dhcpcd3 , was ein Shell-Skript ist.
>>
>> Der Zweck von usrmerge ist doch alles verteilt liegende in einen zweig
>> zu legen und stattdessen nur noch links dorthin zu haben/pflegen...
>
> Ja, eh. Und wenn das verteilt Liegende widersprüchlich ist, schlägt das
> Zusammenlegen fehl.

Das ist schon klar. Aber dann muß man doch nur einmal raus lesen wohin
eigentlich verschoben werden soll und dann die datei löschen die NICHT
im Ziel liegt. Danach stelle ich mir vor das der durch laufen sollte.
Falls er nicht noch was findet.

>>> Ups. "dhcpcd" nicht "dhcpd". Da habe ich ein "c" überlesen.

>> er oder sein PC bekommt nach deinstallation keine IP
>> mehr dynamisch zugewiesen. Wenn der installiert ist sollte man annehmen
>> das der dhcpc auch benutzt wird.
>
> Andreas hat geschrieben "brauche ich vielleicht später wieder einmal".
> Ich schließe daraus, dass er es derzeit nicht braucht. Kann natürlich
> sein, dass er nur nicht weiß, dass er es braucht.

Der NM oder systemd machen's (noch) nicht, oder?

>> Da vermisse ich die Zeiten als sowas wirklich noch ALLES unter /etc lag.
>> Doch dann kam polly ähh systemd... [Nein, kein Bashing. Aber ist doch so!]
>
> Da liegt die Config auch unter /etc.

Da habe ich; auch bei resolvconf; IMHO schon was anderswo gefunden oder
es wurde von/nach dort verlinkt. Ich meine in /usr/lib oder gar unter
/var irgendwelche Templates, Stubs oder konfigs gesehen zu haben auf die
dann schlicht verlinkt wurde. Wenn man da jetzt ein filebackup von /etc
zur konfigsicherung macht was landet da drin, der link oder der inhalt
der verlinkten datei? Und was wenn das linkziel (z.b. beim rein schauen
auf anderem PC) nicht vorhanden ist? Das finde ich inkonsistent by
Design und sollte nicht vorkommen.

>> Jedenfalls würde ich für solche experimente kein Testing nehmen und wenn
>> dann nach der neuinstallation ERST usrmerge und dann weiteres
>> installieren.
>
> Deshalb meine Frage, ob das bei der Umstellung auf Testing passiert ist
> oder bei einem Upgrade innerhalb von Testing. Wenn letzteres, dann gab
> es keine Neuinstallation und Andreas hat vermutlich usrmerge gar nicht
> gezielt installiert, sondern das ist über eine Dependency mitgekommen

Ich weiß es auch nicht aber ich meine er ist; neben anderen; erst seit
kurzem mit Testing-Themen in den Gruppen unterwegs.

> (wenn ich mich recht entsinne, soll ja mit dem nächsten Release der
> root-usr-Merge mandatory werden).

Mein Linux Mint hat mir das neulich; etwas drängelnd; als "Zur
Beachtung" vorgelegt. Ich hab's erst mehrere male links liegen gelassen
aber dann neulich erst gemacht. Keine Probleme die mir auffielen.

Mit root-usr meinst du /sbin verlegungen? Ich meine die wären hier schon
mit dabei gewesen.

Andreas schreibt oben doch auch von /sbin Pfaden.

[Peter J. Holzer]

On 2022-09-25 17:43, Kay Martinen <use...@martinen.de> wrote:
> Am 25.09.22 um 16:04 schrieb Peter J. Holzer:
>> On 2022-09-25 00:38, Kay Martinen <use...@martinen.de> wrote:
>>> Am 25.09.22 um 01:16 schrieb Peter J. Holzer:
>>>> On 2022-09-24 23:05, Peter J. Holzer <hjp-u...@hjp.at> wrote:
>>>>> On 2022-09-24 21:08, Andreas Kohlbach <a...@spamfence.net> wrote:
>>>>>> /sbin/dhcpcd ist ein Link auf /etc/alternatives/dhcpcd , und das auf
>>>>>> /sbin/dhcpcd3 , was ein Shell-Skript ist.
>>>
>>> Der Zweck von usrmerge ist doch alles verteilt liegende in einen zweig
>>> zu legen und stattdessen nur noch links dorthin zu haben/pflegen...
>>
>> Ja, eh. Und wenn das verteilt Liegende widersprüchlich ist, schlägt das
>> Zusammenlegen fehl.
>
> Das ist schon klar. Aber dann muß man doch nur einmal raus lesen wohin
> eigentlich verschoben werden soll und dann die datei löschen die NICHT
> im Ziel liegt. Danach stelle ich mir vor das der durch laufen sollte.

Ich will ja dem Andreas nicht vorschreiben, wie er seine Systeme
betreiben soll (dir auch nicht), aber wenn ich auf einem meiner Systeme
eine Situation vorfinde, die offenbar nicht vorgesehen ist (hier: Es
existieren sowohl /sbin/dhcpcd als auch /usr/sbin/dhcpcd), dann betreibe
ich nicht Symptombekämpfung, sondern versuche herauszufinden, wie das
zustandegekommen ist. Wenn ich die Ursache gefunden und behoben habe
(und vielleicht noch einen Bug-Report geschrieben habe, sofern es ein
Bug war und nicht ein Versehen meinerseits), dann fühle ich mich
wesentlich wohler als wenn ich einfach blindlings irgendein File
gelöscht habe und hoffe, dass es das richtige war.

>>> Da vermisse ich die Zeiten als sowas wirklich noch ALLES unter /etc lag.
>>> Doch dann kam polly ähh systemd... [Nein, kein Bashing. Aber ist doch so!]
>>
>> Da liegt die Config auch unter /etc.
>
> Da habe ich; auch bei resolvconf; IMHO schon was anderswo gefunden oder
> es wurde von/nach dort verlinkt. Ich meine in /usr/lib

In /usr/lib liegen (bei systemd und möglicherweise auch anderen
Programmen) *defaults*. Die sollte man nicht dort ändern (sonst sind sie
beim nächsten apt update u.U. wieder weg) sondern in /etc.

> oder gar unter /var

Resolvconf erzeugt zur Laufzeit ein resolv.conf in /run (früher in
/var/run). Das ist allerdings kein Konfigurationsfile in dem Sinne, dass
man dort als User etwas konfigurieren könnte. Das wird einfach dynamisch
aus anderen Quellen (/etc/network/interfaces, DHCP, Netplan,
Network-Manager, ...) zusammengestoppelt. Kann sich jederzeit ändern,
spätestens beim nächsten Reboot.

> irgendwelche Templates, Stubs oder konfigs gesehen zu haben auf die
> dann schlicht verlinkt wurde.

> Wenn man da jetzt ein filebackup von /etc
> zur konfigsicherung macht was landet da drin, der link oder der inhalt
> der verlinkten datei?

Hängt natürlich von Deinem Backup up, aber prinzipiell hat z.B. der
Inhalt von /run/resolvconf/resolv.conf in einem Backup der Konfiguration
nichts verloren. Da stehen halt Informationen drin, die der Rechner über
DHCP bekommen hat, u.U. gemischt mit lokal (anderswo) konfigurierten
Informationen. Lässt sich jedenfalls vollständig wiederherstellen und
das passiert auch bei jedem Reboot (/run ist typischerweise ein tmpfs).
Ebenso (aber in der anderen Richtung) Info unter /usr: Das steht unter
Kontrolle des Package-Maintainers. Der Inhalt lässt sich über ein apt
install wieder herstellen, und muss/soll daher nicht in das Backup von
/etc.

hp

[Peter J. Holzer]

On 2022-09-25 21:53, Andreas Kohlbach <a...@spamfence.net> wrote:

> On Sun, 25 Sep 2022 01:05:17 +0200, Peter J. Holzer wrote:
>> On 2022-09-24 21:08, Andreas Kohlbach <a...@spamfence.net> wrote:
>>> OS ist Debian testing (jaja... ;-).
>>
>> Schon länger, or stellst du gerade erst um?
>

> Schon "immer"; vor ca. 10-14 Jahren Debian testing installiert.

>
>>> FATAL ERROR:
>>> Both /sbin/dhcpcd and /usr/sbin/dhcpcd exist.
>>>
>> [...]
>>
>>> /sbin/dhcpcd ist ein Link auf /etc/alternatives/dhcpcd , und das auf
>>> /sbin/dhcpcd3 , was ein Shell-Skript ist.
>>
>> Und was ist /usr/sbin/dhcpd?
>

> Wollte ich angeben; hatte ich aber vergessen. Sorry.
>
> ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically
> linked...

>
>> Wenn das nicht auch ein Symlink auf das gleiche Executable ist:
>> Hast Du da zwei verschiedene dhcpds installiert? Das ist vielleicht eine
>> Situation, mit der der Autor von usrmerge nicht gerechnet hat. Wäre
>> einen Bug-Report wert.
>

> Nur einen, wenn ich das durch "apropos" bestimmen kann:
>
> ~$ apropos dhcpcd
> dhcpcd (8) - a DHCP client
> dhcpcd-bin (8) - an RFC 2131 compliant DHCP client
> dhcpcd-run-hooks (8) - DHCP client configuration script
> dhcpcd.conf (5) - dhcpcd configuration file
> dhcpcd3 (8) - a wrapper for the DHCP client daemon.

Immerhin hast Du da einen dhcpcd und einen dhcpcd3. Das korreliert mit
/usr/sbin/dhcpcd und /sbin/dhcpcd3.

dpkg -S /path/to/file

sollte ausspucken, aus welchem Paket das File stammt (das funktioniert
leider nur bei Files, die tatsächlich in einem Paket vorkommen, nicht
bei Files oder Symlinks, die über ein Post-Install-Script angelegt
wurden).

Alternativ kann man auf https://www.debian.org/distrib/packages suchen,
aber dort findet man nur halbwegs neue Distributionen und keine
Third-Party-Packages. Wenn Dein /sbin/dhcpcd3 aus Debian-Urzeiten
stammt, dann findest Du es dort nicht (mehr).

>> Wenn Du Debian helfen willst: Bug-Report einwerfen. Auf Nachfragen
>> geduldig und sorgfältig antworten.
>

> Glaube nicht, dass das ein Bug ist, sondern es doch auf meiner Seite
> liegt. Denn solch ein gravierender Bug wäre auch Euch hier, und vor allem
> Google bekannt. Ist es aber nicht.

Wenn es z.B. zwei verschiedene Pakete mit einem dhcpcd gibt, und Debian
zulässt, dass man beide installiert, aber usrmerge mit der Situation
nicht zurechtkommt, würde ich das als Bug ansehen, auch wenn mir kein
vernünftiger Grund einfällt, warum man beide Pakete installieren sollte.

Wenn eines der Pakete hingegen von Debian Testing von vor 10 Jahren
übriggeblieben ist, dann war das vielleicht einmal ein Bug (das Paket
hätte vielleicht automatisch deinstalliert werden müssen), aber den kann
man kaum dem usrmerge-Maintainer umhängen. Der muss schauen, dass bei
einem Update von einer stable auf die nächste alles funkioniert und
sollte Pakete die aktuell in Testing sind, berücksichtigen, aber für
das Gerümpel, das sich auf einem System, das man 10-14 Jahre mit Testing
betreibt, so ansammelt, ist der User selber verantwortlich. (Gilt IMHO
teileise auch für Stable - da hatte ich auch schon Probleme, weil ich
noch Pakete von einer Stable-Version von vor 8 Jahren installiert hatte
(die dann gar nicht mehr so leicht loszuwerden waren).)

hp

[Andreas Kohlbach]

On Mon, 26 Sep 2022 17:41:00 +0200, Peter J. Holzer wrote:
>
> On 2022-09-25 21:53, Andreas Kohlbach <a...@spamfence.net> wrote:
>>
>> ~$ apropos dhcpcd
>> dhcpcd (8) - a DHCP client
>> dhcpcd-bin (8) - an RFC 2131 compliant DHCP client
>> dhcpcd-run-hooks (8) - DHCP client configuration script
>> dhcpcd.conf (5) - dhcpcd configuration file
>> dhcpcd3 (8) - a wrapper for the DHCP client daemon.
>
> Immerhin hast Du da einen dhcpcd und einen dhcpcd3. Das korreliert mit
> /usr/sbin/dhcpcd und /sbin/dhcpcd3.

Habe nun einfach den Link /sbin/dhcpcd selbst entfernt, und die
Installation lief durch.

Zur Sicherheit der Kiste vorher noch eine fixe IP verpasst. Trotzdem
später mal schauen, ob die automatische Zuweisung (in einem öffentlichen
WIFI oder so) auch klappt.

Danke an alle.
--
Andreas

[Peter J. Holzer]

On 2022-09-26 17:46, Andreas Kohlbach <a...@spamfence.net> wrote:

> On Mon, 26 Sep 2022 17:41:00 +0200, Peter J. Holzer wrote:
>> Immerhin hast Du da einen dhcpcd und einen dhcpcd3. Das korreliert mit
>> /usr/sbin/dhcpcd und /sbin/dhcpcd3.
>>
>> dpkg -S /path/to/file
>>
>> sollte ausspucken, aus welchem Paket das File stammt (das funktioniert
>> leider nur bei Files, die tatsächlich in einem Paket vorkommen, nicht
>> bei Files oder Symlinks, die über ein Post-Install-Script angelegt
>> wurden).
>

> Bekomme auch nichts.
>
> ~$ dpkg -S /usr/sbin/dhcpcd
> dpkg-query: no path found matching pattern /usr/sbin/dhcpcd
>
> ~$ dpkg -S /sbin/dhcpcd3
> dpkg-query: no path found matching pattern /sbin/dhcpcd3

Das ist seltsam. Zumindest für installierte Pakete sollte das schon
funktionieren. Hast Du Dir irgendwann den Inhalt von /var/lib/dpkg/info
zerschossen?

>> Alternativ kann man auf https://www.debian.org/distrib/packages suchen,
>

> Die findet, dass dhcpcd selbst ein Paket ist; zumindest aus den Security
> Information deutend.

Und das Paket heißt dhcpcd5, was die Vermutung nahelegt, dass es
irgendwann mal ein dhcpcd3 gab.

>> aber dort findet man nur halbwegs neue Distributionen und keine
>> Third-Party-Packages. Wenn Dein /sbin/dhcpcd3 aus Debian-Urzeiten
>> stammt, dann findest Du es dort nicht (mehr).
>

> Also falls sich Paket-Namen änderten? Aber dann, warum sollten sie das?

Neue Version, verschiedene Programme mit gleicher Funktionalität (so wie
es Dutzemde Webserver gibt, gibt es auch mehrere DHCP-Client-
Implementationen), etc.

hp

[Christoph 'Mehdorn' Weber]

Hallo!

* Andreas Kohlbach <a...@spamfence.net>:

> Bleibt halt seltsam, warum das passierte. Vielleicht ist meine
> Installation zu alt (älter als zehn Jahre), dass es zu nicht erwarteten
> Alterserscheinungen führte.

Vielleicht raeumst du auch nur zu selten auf. Du kannst mal
"aptitude purge ~o" und "aptitude purge ~c" versuchen. Das erste
listet Pakete, die aktuell keine Installationsquelle mehr haben,
und bietet an, sie zu deinstallieren. Das zweite entsorgt
stehengebliebene Konfig-Files von deinstallierten Paketen. Beides
kann gelegentlich fuer Ueberraschungen sorgen.

Normalerweise macht man so eine Bereinigung nach jedem
Dist-Upgrade bei Stable, aber bei Testing ergibt sich das
eben nicht.

Christoph

--
Kino ohne Popcorn ist wie Salz ohne Suppe.
(Volker Birk)

[Andreas Kohlbach]

On Tue, 25 Oct 2022 16:43:49 +0200, Christoph 'Mehdorn' Weber wrote:
>
> * Andreas Kohlbach <a...@spamfence.net>:
>
>> Bleibt halt seltsam, warum das passierte. Vielleicht ist meine
>> Installation zu alt (älter als zehn Jahre), dass es zu nicht erwarteten
>> Alterserscheinungen führte.
>
> Vielleicht raeumst du auch nur zu selten auf. Du kannst mal
> "aptitude purge ~o" und "aptitude purge ~c" versuchen. Das erste
> listet Pakete, die aktuell keine Installationsquelle mehr haben,
> und bietet an, sie zu deinstallieren. Das zweite entsorgt
> stehengebliebene Konfig-Files von deinstallierten Paketen. Beides
> kann gelegentlich fuer Ueberraschungen sorgen.

0 packages upgraded, 0 newly installed, 896 to remove and 2 not upgraded.
^^^
Need to get 0 B of archives. After unpacking 5,838 MB will be freed.
Do you want to continue? [Y/n/?]

Habe ich abgebrochen. Auch Dank der Tatsache, dass man auf einer TTY
nicht mehr hoch-scrollen darf. Klar, ich hätte das auch in einem Xterm
machen können...

> Normalerweise macht man so eine Bereinigung nach jedem
> Dist-Upgrade bei Stable, aber bei Testing ergibt sich das
> eben nicht.

Hmm. Eigentlich hatte ich in Erinnerung, dass testing zumindest alte
Kernels (alle außer dem Aktuellen und dem davor) automatisch wegräumt,
das stable hier aber nicht. Und wollte daher schon fragen, wie ich auch
ihm das beibringen könnte.

Ich sehe aber im unteren Teil der Liste nach Deinem purge-Kommando, dass
[bei testing] auch noch alte Kernels aufgeführt sind. Vielleicht hatte
ich das falsch in Erinnerung?

So finde ich unter anderem

/etc/apt/apt.conf.d/01autoremove

und

/etc/apt/apt.conf.d/01autoremove-kernels

die aber bei testing und stable gleich aussehen. Und auch nicht aussehen,
als sollte man die Dateien editieren.

In Letzterer noch der Hinweis auf /etc/kernel/postinst.d/apt-auto-removal,
wo auch

// DO NOT EDIT!

drin steht. Da lasse ich also die Finger von.

Aber wie auch immer; das eigentlich Problem mit dem "usermerge" hat sich
von selbst erledigt.
--
Andreas

[Christoph 'Mehdorn' Weber]

Hallo!

* Andreas Kohlbach <a...@spamfence.net>:

> On Tue, 25 Oct 2022 16:43:49 +0200, Christoph 'Mehdorn' Weber wrote:

>> Vielleicht raeumst du auch nur zu selten auf. Du kannst mal
>> "aptitude purge ~o" und "aptitude purge ~c" versuchen. Das erste
>> listet Pakete, die aktuell keine Installationsquelle mehr haben,
>> und bietet an, sie zu deinstallieren. Das zweite entsorgt
>> stehengebliebene Konfig-Files von deinstallierten Paketen. Beides
>> kann gelegentlich fuer Ueberraschungen sorgen.
>
> 0 packages upgraded, 0 newly installed, 896 to remove and 2 not upgraded.
> ^^^
> Need to get 0 B of archives. After unpacking 5,838 MB will be freed.
> Do you want to continue? [Y/n/?]
>
> Habe ich abgebrochen.

Ich nehme an, du hast mit "~o" angefangen. Wenn du einige Pakete
auf dem System hast, wo es keine Quelle mehr gibt, und die
entsprechende Abhängigkeiten haben, kann das schon viel werden.

Du kannst erst mal mit "~c" anfangen, da dürfte nicht so viel
passieren.

> Hmm. Eigentlich hatte ich in Erinnerung, dass testing zumindest alte
> Kernels (alle außer dem Aktuellen und dem davor) automatisch wegräumt,
> das stable hier aber nicht. Und wollte daher schon fragen, wie ich auch
> ihm das beibringen könnte.

Gefühlt hat das bei mir nie funktioniert, aber ich verwende
meist aptitude interaktiv für Paket-Operationen, einschließlich
Upgrades. "apt autoremove" rufe ich praktisch nie auf.

Es ist eher so, daß mir die alten Kernel spätestens beim
übernächsten neuen Kernel dann auffallen, oder mich im Bootloader
stören. Meist starte ich eh nicht sofort nach dem Update neu,
sondern verlege das in die Nachtstunden oder nutze andere passende
Gelegenheiten. Und dann ist beim nächsten Login das Kernel-Update
meist vergessen und ich gucke gar nicht danach …

Christoph

--
Die Royal Canadian Mounted Police hat Carrier Pidgeons. --
Zum Reiten?!?
(Felix von Leitner, Alexander Zangerl)

[Jens Schüßler]

* Andreas Kohlbach <a...@spamfence.net> [05-12-22 21:24]:

> On Mon, 5 Dec 2022 16:15:24 +0100, Christoph 'Mehdorn' Weber wrote:
>>
>> Hallo!
>>
>> * Andreas Kohlbach <a...@spamfence.net>:
>>> On Tue, 25 Oct 2022 16:43:49 +0200, Christoph 'Mehdorn' Weber wrote:
>>
>>>> Vielleicht raeumst du auch nur zu selten auf. Du kannst mal
>>>> "aptitude purge ~o" und "aptitude purge ~c" versuchen. Das erste
>>>> listet Pakete, die aktuell keine Installationsquelle mehr haben,
>>>> und bietet an, sie zu deinstallieren. Das zweite entsorgt
>>>> stehengebliebene Konfig-Files von deinstallierten Paketen. Beides
>>>> kann gelegentlich fuer Ueberraschungen sorgen.
>>>
>>> 0 packages upgraded, 0 newly installed, 896 to remove and 2 not upgraded.
>>> ^^^
>>> Need to get 0 B of archives. After unpacking 5,838 MB will be freed.
>>> Do you want to continue? [Y/n/?]
>>>
>>> Habe ich abgebrochen.
>>
>> Ich nehme an, du hast mit "~o" angefangen. Wenn du einige Pakete
>> auf dem System hast, wo es keine Quelle mehr gibt, und die
>> entsprechende Abhängigkeiten haben, kann das schon viel werden.
>>
>> Du kannst erst mal mit "~c" anfangen, da dürfte nicht so viel
>> passieren.
>

> "Nur" noch 366. Das Ergebnis passt wieder nicht in die TTY - und Scrollen
> wurde (wie länglich diskutiert) verboten. Ich lasse das bleiben.

Meine Fresse, dann ruf doch doch einfach aptitude auf, suche in der CLI
nach '~o' oder '~c' und scrolle gemächlich durch die Ergebnisse.
Das geht sogar wenn man sich morgendlich die Hose mit einer Kneifzange
anzieht weil xterm böse ist und alles auf wie 1980 auf einem tty
geschehen soll.

[Ulli Horlacher]

Andreas Kohlbach <a...@spamfence.net> wrote:
> "Nur" noch 366. Das Ergebnis passt wieder nicht in die TTY - und Scrollen
> wurde (wie länglich diskutiert) verboten. Ich lasse das bleiben.

Und wer hat dir verboten |less zu verwenden?


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Marco Moock]

Am 06.12.2022 um 15:17:36 Uhr schrieb Ulli Horlacher:

> Und wer hat dir verboten |less zu verwenden?

Nicht jedes System hat less. more ist aber in jedem UNIX/UNIX-like
verfügbar.

:-)

[Claus Reibenstein]

Christoph 'Mehdorn' Weber schrieb am 05.12.2022 um 16:15:

> Ich nehme an, du hast mit "~o" angefangen. [...]
>
> Du kannst erst mal mit "~c" anfangen, [...]

Wo hast Du das mit ~o und ~c her? In den man-Pages finde ich nichts dazu.

Gruß
Claus

[Paul Muster]

Dort gibt es einen Verweis auf das Reference Manual, wo sich der
genannte Abschnitt "Search Patterns" findet. Bei mir auf der Platte
unter /usr/share/doc/aptitude/README oder auch online:

https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html

Darin z.B.

~c Select packages that were removed but not purged.
~o Match installed packages that cannot be downloaded.


mfG Paul

[Christian Garbs]

Mahlzeit!

Jens Schüßler <j.sc...@nurfuerspam.de> wrote:
> * Andreas Kohlbach <a...@spamfence.net> [05-12-22 21:24]:

>> "Nur" noch 366. Das Ergebnis passt wieder nicht in die TTY - und Scrollen
>> wurde (wie länglich diskutiert) verboten. Ich lasse das bleiben.
>
> Meine Fresse, dann ruf doch doch einfach aptitude auf, suche in der CLI
> nach '~o' oder '~c' und scrolle gemächlich durch die Ergebnisse.

Die Funktion wurde leider aus dem Kernel entfernt.

SCNR
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Quidquid latine dictum sit, altum viditur.
(Whatever is said in Latin sounds profound.)

[Claus Reibenstein]

Paul Muster schrieb am 06.12.2022 um 19:35:

> On 06.12.22 17:55, Claus Reibenstein wrote:
>
>> Wo hast Du das mit ~o und ~c her? In den man-Pages finde ich nichts dazu.
>
> Dort gibt es einen Verweis auf das Reference Manual, wo sich der
> genannte Abschnitt "Search Patterns" findet. Bei mir auf der Platte
> unter /usr/share/doc/aptitude/README oder auch online:
>
> https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html

Das sieht doch schon mal sehr gut aus. Vielen Dank :-)

Gruß
Claus

[Andreas Kohlbach]

On Tue, 6 Dec 2022 15:17:36 +0000 (UTC), Ulli Horlacher wrote:
>
> Andreas Kohlbach <a...@spamfence.net> wrote:
>> "Nur" noch 366. Das Ergebnis passt wieder nicht in die TTY - und Scrollen
>> wurde (wie länglich diskutiert) verboten. Ich lasse das bleiben.
>
> Und wer hat dir verboten |less zu verwenden?

Vergesse ich immer. :-/

Sind zu viele Dinge bei (python-minimal, ecmas32-nox, bluemon, fuse,...),
die ich vermutlich nicht entfernen sollte.

Ich lasse das besser (diesmal aus Unsicherheit/Unwissenheit)...
--
Andreas

[Ulli Horlacher]

Andreas Kohlbach <a...@spamfence.net> wrote:
> On Tue, 6 Dec 2022 15:17:36 +0000 (UTC), Ulli Horlacher wrote:
>>
>> Andreas Kohlbach <a...@spamfence.net> wrote:
>>> "Nur" noch 366. Das Ergebnis passt wieder nicht in die TTY - und Scrollen
>>> wurde (wie länglich diskutiert) verboten. Ich lasse das bleiben.
>>
>> Und wer hat dir verboten |less zu verwenden?
>
> Vergesse ich immer. :-/

Und wer hat dir verboten was zu merken?
Ich empfehlen in solchen Faellen immer meinen Studenten: AUFSCHREIBEN!

... was sie dann meistens ignorieren :-}

[Marco Moock]

Am 07.12.2022 um 11:59:52 Uhr schrieb Ulli Horlacher:

> Ich empfehlen in solchen Faellen immer meinen Studenten: AUFSCHREIBEN!

Lehrst du auch an der Uni?
Ich dachte immer, du wärst da nur Mitarbeiter in der IT.

[Ulli Horlacher]

Ich mach beides: Country UND Western.