[erledigt] Trixie / Sid : Seltsame Meldung von update-initramfs

[thunder11]

Seit einiger Zeit kommt immer folgende Meldung (Trixie und Sid), wobei sich "cp: warning" diverse Male wiederholt:

Code: Alles auswählen

update-initramfs: Generating /boot/initrd.img-6.6.11-amd64
cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead
....
....

Fehler kann ich im Nachhinein nicht feststellen.
Ich habe nicht die geringste Ahnung, was die Warnung zu bedeuten hat, und was

Code: Alles auswählen

use --update=none

zu bedeuten hat. Das waren ganz normale Updates mit apt full-upgrade

Kann mich jemand erhellen ?

[JTH]

Das hatten wir vor einer kurzen Weile schonmal. Die Optionen von cp und anderen coreutils haben sich etwas verändert. Die Warnungen stören, sind aber nicht gefährlich.

[thunder11]

Schön und gut - aber Frage nicht beantwortet, da da auch keine Lösung steht.

in der /etc/initramfs-tools/update-initramfs.conf steht:

Code: Alles auswählen

#

# Configuration file for update-initramfs(8)
#

#
# update_initramfs [ yes | all | no ]
#
# Default is yes
# If set to all update-initramfs will update all initramfs
# If set to no disables any update to initramfs beside kernel upgrade

update_initramfs=yes

#
# backup_initramfs [ yes | no ]
#
# Default is no
# If set to no leaves no .bak backup files.

backup_initramfs=no

Glaube nicht, dass ich da was ändern sollte.

Was aber hat dann der Kommentar (jetzt ja erweitert)

Code: Alles auswählen

use --update=none instead

zu bedeuten, und wohin damit, falls es irgendwas zu bedeuten hat, und kein Bug ist ?

[towo]

der Kommentar kommt von cp und wenn du die Warnung weg haben willst, wirst du wohl den Code von initramfs-tools anpassen müssen, weil dort wiird cp -n irgendwo benutzt.

[JTH]

Schön und gut - aber Frage nicht beantwortet, da da auch keine Lösung steht.

Na, wenn du so willst … nach ner Lösung hast du nicht gefragt

Ich habe nicht die geringste Ahnung, was die Warnung zu bedeuten hat […] Kann mich jemand erhellen ?

Eine Lösung deinerseits ist, wie towo auch schreibt, nicht notwendig. Die Warnungen verschwinden irgendwann wieder, wenn die Maintainer sich drum gekümmert haben.

[thunder11]

Die Warnungen verschwinden irgendwann wieder, wenn die Maintainer sich drum gekümmert haben.

Na gut ich gebe mich damit zufrieden, da ich den Quellcode nicht anpassen kann. Und selbst wenn ich es könnte,
keinen Ahnung hätte, was sich da sonst noch tun würde.

Hab mal man cp zu Rate gezogen dort steht (unten) (--no-clobber = -n)

Die angegebene AKTUALISIERUNG steuert, welche im Ziel vorhandenen Dateien ersetzt werden.
»all« ist die Standardaktion, wenn keine --update-Option angegeben ist, und führt dazu,
dass alle im Ziel vorhandenen Dateien ersetzt werden. »none« ist ähnlich zur Option
--no-clobber, in der einerseits keine Dateien im Ziel ersetzt werden, aber übersprungene
Dateien auch keinen Fehler verursachen. »older« ist die Standardaktion, wenn --update an‐
gegeben ist, und führt dazu, dass Dateien ersetzt werden, sofern diese älter sind als die
entsprechende Quelldatei.

[JTH]

Noch als Nachtrag: Die Warnungen loszuwerden, ist sehr wahrscheinlich eine triviale (einzeilige) Änderung – wenn man die passende Stelle gefunden hat (in den zwei naheliegendsten Dateien war die Stelle auf den ersten Blick nicht).

Das ist’s in meinen Augen aber nicht wert, dafür in den initramfs-tools herumzufummeln. Eine Gefahr geht von den Warnungen ja nicht aus.

[KP97]

Ich habe thunder11' Beitrag nochmal zum Anlaß genommen, um eine zugegebenermaßen etwas unkonventionelle Lösung anzubieten.
Es gibt ja nun mittlerweile einen Bugreport 1061612, aber nach einer zeitnahen Lösung klingt das absolut nicht.
Wen das aber auch so stört wie mich, kann Folgendes tun:
Im Paket coreutils 9.1-1 aus Bookworm ist dieser Fehler im Programm cp noch nicht enthalten. Ich habe also aus dem Paket cp entpackt und einfach nach /bin kopiert, vorher aber natürlich ein bak vom Originalprogramm erstellt. Das ist eigentlich alles. Zur Sicherheit noch ein bak für das cp aus Bookworm anlegen, damit bei einem evtl. Update "ohne die Fehlerbehebung" nichts überschrieben wird.
Und schon ist Ruhe, wie man sehen kann:

root@MB:/home/MB/Temp# dpkg -i linux-image-6.1.77_6.1.77-1_amd64.deb
Vormals nicht ausgewähltes Paket linux-image-6.1.77 wird gewählt.
(Lese Datenbank ... 94613 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von linux-image-6.1.77_6.1.77-1_amd64.deb ...
Entpacken von linux-image-6.1.77 (6.1.77-1) ...
linux-image-6.1.77 (6.1.77-1) wird eingerichtet ...
update-initramfs: Generating /boot/initrd.img-6.1.77
Updating kernel version 6.1.77 in systemd-boot...
Installing kernel version 6.1.77 in systemd-boot...
root@MB:/home/MB/Temp#

Man kann also auch in initramfs-tools alle Einstellungen so belassen und alles ist wieder wie es sein soll.

[cosinus]

Noch als Nachtrag: Die Warnungen loszuwerden, ist sehr wahrscheinlich eine triviale (einzeilige) Änderung – wenn man die passende Stelle gefunden hat (in den zwei naheliegendsten Dateien war die Stelle auf den ersten Blick nicht).

IIch glaube ich habe die Stelle über https://groups.google.com/g/linux.debia ... wU0SG1J3Wk gefunden. Da steckt im Script klibc-utils tatsächlich ein -n in einem Parameter, bei mir in Zeile 31:

Code: Alles auswählen

/usr/share/initramfs-tools/hooks/klibc-utils:31:			cp -pnL "$src" "${DESTDIR}/bin"

[QT]

1055694

[cosinus]

Also bei den vielen Bugreports komm ich langsam durcheinander

[schorsch_76]

Trixie = testing

Testing may break.... Das vergessen viele. Hier ist es nur eine kleine Meldung.

[cosinus]

Trixie = testing

Testing may break.... Das vergessen viele.

Naja, ich habs immer noch im Hinterkopf, auch wenn erstaunlich wenig/selten nach einem Update was kaputtgeht bei testing oder sid.

[cosinus]

Also ich hab jetzt mal alle Scripte, die was mit was mit update-initramfs zu tun haben, durchforstet. In keinem kommt ein cp mit dem Parameter n vor. Ist das irgendwo hart einkodiert? Oder wird beim update-initramfs noch an anderes Script aufgerufen, das widerum ein cp macht?

[KP97]

Die Bugreports habe ich auch gesehen, die Maintainer sind sich ja auch nicht einig, wer denn nun was machen sollte.
Ich bin auch nicht sicher, ob es überhaupt bei initramfs-tools zu suchen ist, da ja die Versionen bei stable, testing und sid gleich sind, diese Meldungen aber bei stable _nicht_ auftreten.
Das Paket coreutils mit dem Programm cp hat aber unterschiedliche Versionen, daher bin ich der Meinung, daß hier eher zu suchen ist.
Ich habs mir einfach gemacht und das Programm getauscht, und halte nun im Auge, was weiter passiert.

[towo]

initramfs-tools benutzt den Befehl cp falsch, ergo mus das auch in initramfs-tools gefixt werden.

[JTH]

Also ich hab jetzt mal alle Scripte, die was mit was mit update-initramfs zu tun haben, durchforstet. In keinem kommt ein cp mit dem Parameter n vor. Ist das irgendwo hart einkodiert? Oder wird beim update-initramfs noch an anderes Script aufgerufen, das widerum ein cp macht?

Hmm, wonach suchst du denn noch? Die trigonometrische Funktion hatte doch die Stelle oben gefunden/zitiert :

Code: Alles auswählen

/usr/share/initramfs-tools/hooks/klibc-utils:31:			cp -pnL "$src" "${DESTDIR}/bin"

/usr/share/initramfs-tools/hooks/klibc-utils stammt, wie der Name andeutet aus klibc-utils. Das ist ein Skript, was im Rahmen von update-initramfs/mkinitramfs mit aufgerufen wird.

So wie cp -n dort

Code: Alles auswählen

		if ! [ -e "${DESTDIR}/sbin/$command" ]; then
			cp -pnL "$src" "${DESTDIR}/bin"
		fi

verwendet wird, könnte man dieselbe Funktionalität auch durch einen einfachen, zusätzlichen Test im umgebenden Shellskript erreichen, wenn man -n oder --update=none vermeiden möchte. Aber anscheinend gibts in den verschiedenen Bugreports noch ne gewisse Uneinigkeit, was die sinnvollste Lösung ist (u.a. zwei identische triviale Änderungsvorschläge 13 und 14 und einen etwas darüber hinausgehenden 12).

[cosinus]

Jo, das hatte ich gefunden, auch wenn ich nicht der erste war
Ich hatte vergessen zu erwähnen, dass ich testweise dieses Script editiert hatte. Also das n weggemacht und dafür ein

Code: Alles auswählen

--update-none

reingekritzelt. Der Warnung von cp kam danach bei einem manuell update-iniramfs trotzdem...