Servus,

ist jetzt schon 7 Monate her das ich gemerkt habe wo mein Problem liegt, aber jetzt habe ich endlich die Zeit mich damit zu befassen.

Problem: Egal ob kernel-update, reinstall oder dpkg-reconfigure, das Image für
die Ramdisk wird nicht erstellt.

/etc/initramfs-tools/update-initramfs.conf enthält update_initramfs=yes

Ich bin auch mal die postinst für den Kernel durchgegangen aber konnte keine Stelle finden an der die Datei gelesen würde, an den darin aufgerufenen Skripten in /etc/kernel/postinst.d wird dann auf $INITRD getestet, aber wo das her kommt konnte ich bislang auch nicht finden.

Alles was sich auf INITRD bezieht scheint in /usr zu systemd zu gehören, aber da denke ich nicht das es mit dem Problem zu tun haben sollte, da in den postinst nix davon zu lesen war.

So langsam gehen mir die Ideen aus.

--
MfG usw.

Werner Mahr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hallo Werner,

Welche Fehlermeldung?
Welches System (Bullseye?)
Partioniert? Wenn ja, wie?

Viele Grüße

Mechtilde



Am 03.12.21 um 15:44 schrieb Werner Mahr:

Servus,

ist jetzt schon 7 Monate her das ich gemerkt habe wo mein Problem liegt, aber jetzt habe ich endlich die Zeit mich damit zu befassen.

Problem: Egal ob kernel-update, reinstall oder dpkg-reconfigure, das Image für
die Ramdisk wird nicht erstellt.

/etc/initramfs-tools/update-initramfs.conf enthält update_initramfs=yes

Ich bin auch mal die postinst für den Kernel durchgegangen aber konnte keine Stelle finden an der die Datei gelesen würde, an den darin aufgerufenen Skripten in /etc/kernel/postinst.d wird dann auf $INITRD getestet, aber wo das
her kommt konnte ich bislang auch nicht finden.

Alles was sich auf INITRD bezieht scheint in /usr zu systemd zu gehören, aber
da denke ich nicht das es mit dem Problem zu tun haben sollte, da in den postinst nix davon zu lesen war.

So langsam gehen mir die Ideen aus.

--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Moin,

Am Fri, 03 Dec 2021 15:44:43 +0100 schrieb Werner Mahr <werner@vollstreckernet.de>:

Problem: Egal ob kernel-update, reinstall oder dpkg-reconfigure, das
Image für die Ramdisk wird nicht erstellt.

/etc/initramfs-tools/update-initramfs.conf enthält
update_initramfs=yes

root@localhost:~# ls -l /boot/initrd.img* /boot/vmlinuz*
-rw-r--r-- 1 root root 51277471 26. Sep 22:11 /boot/initrd.img-5.10.0-8-amd64 -rw-r--r-- 1 root root 51288535 9. Okt 13:45 /boot/initrd.img-5.10.0-9-amd64 -rw-r--r-- 1 root root 6820832 23. Sep 22:35 /boot/vmlinuz-5.10.0-8-amd64 -rw-r--r-- 1 root root 6833568 30. Sep 21:36 /boot/vmlinuz-5.10.0-9-amd64

root@localhost:~# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.10.0-9-amd64
update-initramfs: Generating /boot/initrd.img-5.10.0-8-amd64

root@localhost:~# ls -l /boot/initrd.img* /boot/vmlinuz*
-rw-r--r-- 1 root root 51277339 3. Dez 19:43 /boot/initrd.img-5.10.0-8-amd64 -rw-r--r-- 1 root root 51291623 3. Dez 19:43 /boot/initrd.img-5.10.0-9-amd64 -rw-r--r-- 1 root root 6820832 23. Sep 22:35 /boot/vmlinuz-5.10.0-8-amd64 -rw-r--r-- 1 root root 6833568 30. Sep 21:36 /boot/vmlinuz-5.10.0-9-amd64

Geht das?

Gruß
Christian

--
http://cknoke.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Freitag, 3. Dezember 2021, 19:48:59 CET schrieb Christian Knoke:

root@localhost:~# update-initramfs -u -k all
Geht das?

Funktioniert wunderbar. Ich würde halt erwarten das das bei der Installation passiert, da der Kernel ohne initrd einfach nicht bootfähig ist.

--
MfG usw.

Werner Mahr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Nochmal an die Liste, die erste Antwort ging direkt *
Am Freitag, 3. Dezember 2021, 16:42:07 CET schrieb Mechtilde Stehmann:

Welche Fehlermeldung?

Keine, auch ein manuelles erstellen läuft Fehlerfrei, das einzige was man sieht ist das beim grub update nur das kernelimage gefunden wird:

root@htpc:/etc/kernel# dpkg-reconfigure linux-image-4.19.0-14-amd64 /etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.10.0-9-amd64
Found initrd image: /boot/initrd.img-5.10.0-9-amd64
Found linux image: /boot/vmlinuz-5.10.0-8-amd64
Found initrd image: /boot/initrd.img-5.10.0-8-amd64
Found linux image: /boot/vmlinuz-4.19.0-14-amd64
Found linux image: /boot/vmlinuz-4.19.0-5-amd64
Found initrd image: /boot/initrd.img-4.19.0-5-amd64
Adding boot menu entry for EFI firmware configuration
done
root@htpc:/etc/kernel#

Bei den anderen hab ich schon eine von Hand erstellen lassen, daher der alte Kernel, aber wie du siehst passiert einfach nix ungewöhnliches, daher ja meine
Frage.

Welches System (Bullseye?)

Bullseye, ging aber schon bei Buster los.

Partioniert? Wenn ja, wie?

Ich kann mir zwar nicht vorstellen was das damit zu tun hat, aber:

root@htpc:/etc/kernel# mount | grep /sd
/dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro)
/dev/sdb1 on /samba type ext4 (rw,relatime)
/dev/sdd1 on /samba/incoming type ext4 (rw,relatime)
/dev/sdc1 on /samba/Gesehenes type ext4 (rw,relatime)
/dev/sde1 on /samba/MP3 type ext4 (rw,relatime)
root@htpc:/etc/kernel#

Also kein extra boot oder so.

--
MfG usw.

Werner Mahr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Samstag, 4. Dezember 2021, 09:58:29 CET schrieb Martin Reising:

Hm, verwenden die Kernelpackete nicht /etc/kernel-img.conf, um das zu konfigurieren?

Auf einem System das das Gewünschte durchführt beinhaltet die Datei folgendes:

cat /etc/kernel-img.conf
# Kernel Image management overrides
# See kernel-img.conf(5) for details
do_initrd = Yes
do_symlinks = Yes

Stimmt, hatte ich vergessen zu erwähnen, da fällt mir auch direkt do_bootloader auf welcher brav aktualisiert wird obwohl da no steht.

Ansonten fällt mir nur auf das deine Eintäge groß und meine klein geschrieben sind, aber auch wenn ich das anpasse ändert sich nichts.

root@werner1:~# cat /etc/kernel-img.conf
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
do_bootloader = no
do_initrd = yes
link_in_boot = no
root@werner1:~#

Übrigens sind alle configs die ich bisher gecheckt habe identisch mit jenen auf
einem aktuellen testing. Da funktionert auch alles.

--
MfG usw.

Werner Mahr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Dec 03, 2021 at 03:44:43PM +0100, Werner Mahr wrote:

Servus,

ist jetzt schon 7 Monate her das ich gemerkt habe wo mein Problem liegt, aber
jetzt habe ich endlich die Zeit mich damit zu befassen.

Problem: Egal ob kernel-update, reinstall oder dpkg-reconfigure, das Image für
die Ramdisk wird nicht erstellt.

/etc/initramfs-tools/update-initramfs.conf enthält update_initramfs=yes

Ich bin auch mal die postinst für den Kernel durchgegangen aber konnte keine Stelle finden an der die Datei gelesen würde, an den darin aufgerufenen Skripten in /etc/kernel/postinst.d wird dann auf $INITRD getestet, aber wo das
her kommt konnte ich bislang auch nicht finden.

Hm, verwenden die Kernelpackete nicht /etc/kernel-img.conf, um das zu konfigurieren?

Auf einem System das das Gewünschte durchführt beinhaltet die Datei
folgendes:

cat /etc/kernel-img.conf
# Kernel Image management overrides
# See kernel-img.conf(5) for details
do_initrd = Yes
do_symlinks = Yes

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Samstag, 4. Dezember 2021, 13:25:19 CET schrieb Christian Knoke:

dpkg-reconfigure linux-image-5.10.0-9-amd64
...
Das klappt also nicht?

Genau.

Ohne Fehlermeldung?

Richtig.

root@htpc:/etc/kernel# dpkg-reconfigure linux-image-5.10.0-8-amd64 /etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.10.0-9-amd64
Found initrd image: /boot/initrd.img-5.10.0-9-amd64
Found linux image: /boot/vmlinuz-5.10.0-8-amd64
Found linux image: /boot/vmlinuz-4.19.0-14-amd64
Found linux image: /boot/vmlinuz-4.19.0-5-amd64
Found initrd image: /boot/initrd.img-4.19.0-5-amd64
Adding boot menu entry for EFI firmware configuration
done
root@htpc:/etc/kernel#

Ich hab mal ein "env" in /etc/kernel/postinst.d/initramfs-tools
geschrieben, INITRD ist nicht gesetzt.

Wundert mich nicht, kann sein das ich da falsch liege, aber das postinst sollte eigentlich das erste Skript sein das läuft, zumindest wenn man mal dpkg selbst aussen vor lässt, aber das sollte ja nichts Paketspezifisches tun. Vom postinst werden dann die Skripte in /etc/kernel/postinst.d/ aufgerufen, aber keines davon (obwohl die untereinander nicht interagieren sollten) greift in irgendeiner Weise auf die bisher genannten Dateien zu. Ich hab mir noch nicht die Mühe gemacht update-initrd direkt zu tracen, da die Informationen ja eigentlich vor dem Aufruf benötigt werden müssten.

--
MfG usw.

Werner Mahr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Fri, 03 Dec 2021 15:44:43 +0100 schrieb Werner Mahr <werner@vollstreckernet.de>:

Problem: Egal ob kernel-update, reinstall oder dpkg-reconfigure, das
Image für die Ramdisk wird nicht erstellt.

/etc/initramfs-tools/update-initramfs.conf enthält
update_initramfs=yes

Ich bin auch mal die postinst für den Kernel durchgegangen aber
konnte keine Stelle finden an der die Datei gelesen würde, an den
darin aufgerufenen Skripten in /etc/kernel/postinst.d wird dann auf
$INITRD getestet, aber wo das her kommt konnte ich bislang auch nicht
finden.

root@localhost:~# dpkg-reconfigure linux-image-5.10.0-9-amd64 /etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 5.10.0-9-amd64:. /etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.10.0-9-amd64 /etc/kernel/postinst.d/zz-update-grub:
Including Xen overrides from /etc/default/grub.d/xen.cfg
*snip*

Das klappt also nicht?

Ohne Fehlermeldung?

Ich hab mal ein "env" in /etc/kernel/postinst.d/initramfs-tools
geschrieben, INITRD ist nicht gesetzt.

Alles was sich auf INITRD bezieht scheint in /usr zu systemd zu
gehören, aber da denke ich nicht das es mit dem Problem zu tun haben
sollte, da in den postinst nix davon zu lesen war.

So langsam gehen mir die Ideen aus.

--
http://cknoke.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Servus,

erstmal Danke an alle die helfen wollten, ich habe es gerade gefunden. Fragt mich nicht warum, aber abgesehen von dem Grub-skript waren alle anderen in / etc/kernel/postinst.d/ ohne executable-bit. Ich bin davon ausgegangen das das postinst die Dateien sourced, daher wäre das ja auch nicht nötig.

Merkwürdigerweise hat selbst ein reinstall nichts an den Rechten verändert. Noch merkwürdiger: Der reinstall hat von v133... auf v140 aktualisiert, apt hat aber nie irgendwas davon erwähnt.

Also Problem gelöst, Ursache offensichtlich, Herkunft unbekannt.

--
MfG usw.

Werner Mahr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Merkwürdigerweise hat selbst ein reinstall nichts an den Rechten
verändert.

Das ist zu erwarten.
Dateien in /etc sind in der Regel conffiles [1]. Sprich, Modifikationen
daran werden bewahrt und Dateiberechtigungen gehören dazu, oder z.B. auch
wenn man conffiles löschst.
Wenn du also ein apt install --reinstall foo machst,
werden fehlende oder modifizierte conffiles nicht ersetzt.

Du müsstest das Paket komplett purgen und dann nochmal neu installieren, um die Original-Dateien zu bekommen.

Eine weniger brutale Methode um die Original-Datei des Pakets zu bekommen
ist folgender Weg:
- Löschen der Datei, z.B. rm /etc/foo.conf
- apt download foo; dpkg --force-confew foo_...deb

Das ersetzt dann fehlende conffiles mit denen aus dem Paket.

Gruß,
Michael

[1] https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files


-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmG0gj8ACgkQauHfDWCP Ity2jg/9Frv9+UTtLvgokzr26ZnPWgzuuPhvYCgkv72qjxzQOzm2UOpadtDZ16KN 3ZNstbwmQaKeK+Z2c0LYQ+4kc92q+q4ifTxIhIBnNI0xt4CKTlzLMLCA1za2mmie EZBGvH5aSruOuyWWPmEz7+x+w1Jde9GAoKQ8dimqlFf4E4nYh04A2rZFOzdNj2Tp uZJ+FXqpv/9nIfKkHf4AYcoM1089y17ZIoO2nX7jSy13ZnRoNv3l8gcaTBdZDIKP IFWhpYVAr1F79ffYPvgK1YL6YzHphzY7nJRiz63crpcaFXkOgi5ktOuXcTBXehEP hCmoXVDiZxOchdT7BmjtthyLIVGukzwq2KrDpGj6qZmt44jn4CCJV2SwX47dL5Wv /B5HdSBnjXHguxYlANt54RWfJ31orPtAAMyRwfcMT484nEaAMQn0O9nuL3VH4K94 a8+AzDyzeoqIDkRWPM2xdzfn6IkDj29W+l0kQrrwgjnn+d6dI0K7V8WGkYHlvqUI 8jX54qfZUUii6ICbbsnyhdbeGSmbuFFCmoKOJZSYVrHKLLnfZFBOraJDpwWAlv0L 02K5I9k1HsKuUT7geZrJgLrSqO7lPQVrHPgaViveubOeiiOI9C9DCwxV1AS/un52 cYUUBACgL5qkj8e+c1qiP85elDaBscro4eq6NZpB5ySnD6rNp0E=
=wqVS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Samstag, 11. Dezember 2021, 11:49:35 CET schrieb Michael Biebl:

Merkwürdigerweise hat selbst ein reinstall nichts an den Rechten
verändert.

Das ist zu erwarten.
Dateien in /etc sind in der Regel conffiles [1].

In der Regel, ja. Bei den betreffenden Skripten, nein. Dein Link erwähnt zwar:

In general, any script that embeds configuration information

Aber da die Skripte ja nur Optionen auswerten, würde keine der Definitionen für
conffiles zutreffen. Erster Eindruck: Die gehören eigentlich nicht dort hin.

Was mir aber derzeit wirklich helfen würde wäre ein tool zum prüfen. Bei den configs kann ich zwar meisten die dpkg-old/new suchen, aber ich habe da meinen letzten Hardwarewechsel im Verdacht und rechne mit wesentlich mehr falschen Rechten. Sowas wie debsums für Rechte wäre genial, aber alles was mir einfällt wäre alle installierten nochmal runter zu laden (ja, im Cache sind scheinbar nicht alle), zu entpacken und dann zu vergleichen. Wäre zwar gut zu scripten, aber irgendwie nicht sehr elegant.

Was mich nach wie vor am meisten wundert ist die Tatsache das der reinstall eine neuere Version installiert hat, obwol apt niemals was davon erwähnt hat, selbst wenn es hold gesetzt wäre müsste da ja zumindest der Hinweis auf nicht aktualisierte Pakete kommen.

--
MfG usw.

Werner Mahr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sat, 11 Dec 2021 12:28:40 +0100 schrieb Werner Mahr <werner@vollstreckernet.de>:

Am Samstag, 11. Dezember 2021, 11:49:35 CET schrieb Michael Biebl:

Merkwürdigerweise hat selbst ein reinstall nichts an den Rechten verändert.

Aber da die Skripte ja nur Optionen auswerten, würde keine der
Definitionen für conffiles zutreffen. Erster Eindruck: Die gehören
eigentlich nicht dort hin.

Die wesentliche Frage ist, wie die da hingekommen sind.

Falls du die Scriptdateien noch irgendwo hast (im Backup), kannst du das prüfen, mit apt-file oder auf debian.org, mit dem Pfadnamen den
Paketnamen ermitteln. Aus dem Paket nimmst du dann die Prüfsummen, und
die Dateirechte stehen da auch. Könnten ja auch old(old)stable Pakete
sein.

Dann weisst du, ob sie verändert wurden.

Gruß
Christian

--
http://cknoke.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Samstag, 11. Dezember 2021, 15:35:00 CET schrieb Christian Knoke:

Aber da die Skripte ja nur Optionen auswerten, würde keine der
Definitionen für conffiles zutreffen. Erster Eindruck: Die gehören eigentlich nicht dort hin.

Die wesentliche Frage ist, wie die da hingekommen sind.

/etc/kernel/postinst.d/initramfs-tools z.B. stammt aus https://packages.debian.org/bullseye/all/initramfs-tools/filelist

Die Rechte dazu hatte ich dann ja aus dem Paket gelesen, die anderen wären zz- update-grub, dkms und apt-auto-removal, die gehören da angeblich auch alle hin.

--
MfG usw.

Werner Mahr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sat, 11 Dec 2021 16:14:16 +0100 schrieb Werner Mahr <werner@vollstreckernet.de>:

Am Samstag, 11. Dezember 2021, 15:35:00 CET schrieb Christian Knoke:

Aber da die Skripte ja nur Optionen auswerten, würde keine der Definitionen für conffiles zutreffen. Erster Eindruck: Die gehören eigentlich nicht dort hin.

Die wesentliche Frage ist, wie die da hingekommen sind.

/etc/kernel/postinst.d/initramfs-tools z.B. stammt aus https://packages.debian.org/bullseye/all/initramfs-tools/filelist

Die Rechte dazu hatte ich dann ja aus dem Paket gelesen, die anderen
wären zz- update-grub, dkms und apt-auto-removal, die gehören da
angeblich auch alle hin.

Hast du die Dateien bzw. deren Prüfsummen verglichen?

--
http://cknoke.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Samstag, 11. Dezember 2021, 17:20:48 CET schrieb Christian Knoke:

Am Sat, 11 Dec 2021 16:14:16 +0100 schrieb Werner Mahr

<werner@vollstreckernet.de>:

Am Samstag, 11. Dezember 2021, 15:35:00 CET schrieb Christian Knoke:

Aber da die Skripte ja nur Optionen auswerten, würde keine der Definitionen für conffiles zutreffen. Erster Eindruck: Die gehören eigentlich nicht dort hin.

Die wesentliche Frage ist, wie die da hingekommen sind.

/etc/kernel/postinst.d/initramfs-tools z.B. stammt aus https://packages.debian.org/bullseye/all/initramfs-tools/filelist

Die Rechte dazu hatte ich dann ja aus dem Paket gelesen, die anderen
wären zz- update-grub, dkms und apt-auto-removal, die gehören da
angeblich auch alle hin.

Hast du die Dateien bzw. deren Prüfsummen verglichen?

Ich hab jetzt mal debsums --all drüber gejagt. Wie zu erwarten ein paar configs, und weniger zu erwarten ein paar fehlende Dateien, aber nichts aus den
Bereichen die die Probleme hatten. Geiches gilt für die Backups des laufenden Jahres (ein paar Checksummen wegen updates, aber ansonsten keine Abweichungen zum aktuellen System).

--
MfG usw.

Werner Mahr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Samstag, 11. Dezember 2021, 11:49:35 CET schrieb Michael Biebl:

Merkwürdigerweise hat selbst ein reinstall nichts an den Rechten verändert.

Das ist zu erwarten.
Dateien in /etc sind in der Regel conffiles [1].

In der Regel, ja. Bei den betreffenden Skripten, nein.

Sind sie halt eben doch. Siehe

# cat /var/lib/dpkg/info/initramfs-tools.conffiles /etc/initramfs-tools/update-initramfs.conf /etc/kernel/postinst.d/initramfs-tools
/etc/kernel/postrm.d/initramfs-tools


-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmG2gfkACgkQauHfDWCP ItzGVw//XJBqtn+dO5pKV30uVzuHxdT0B9CjsihDQY4eK4VXlCcuvSn38MEsrMMU 7zJJtP/s2HiAXNPvS5xom0JBHrO0wHF1SdLSVwe9EgY8yf2R2vly1r/DF8YBH+/j 1qL+cOBEA5Md1GjHnj1gfNiJENcnmYwMFwGtwbkS9Z+AglC53twNDYTpEH86PAVM 8CyavTPgUQtVLNyVlJNArv1Gqa1BLEBGN77b7pG7kKHYcuGZotUyWE1ItN4bI8LQ ESkUidHhPefk+q6ZxKts11M4We1JGiiAfxVX1yeCMNn2RadVnX+SieEC6Tq9DqdM VfW/1IIKCq6MwfmPpCBsQvAZGdjcK8gTfbOSXqBgWOzXShYs8ydLVyPz2mPodg4X BSYUnrecqE80/rQo+TKHu6VYbK1wyM6AqztnOt2cmrZb4DJsMa4TDx3oE4W8VHFQ cNqFihZusbCgNtFlqEGLTB6KkOAi+7S90C7jWgs/dZOaxczyXajV1tQOarZfrFVn 0J2OWufCYT+R0OmoU1NWOj41+SlbfT/A4Aw0UB8Ltgj3QNMmnjy1gyS0s8+Vk15N cF+2wZMSqQt90x36+WfPGNSdQVnBYfYv2LbdSKS9ARSNWeBre3sTlYPa/7IHkcOw u0t3TSXHmSBy0L/Hhe1m+B8TMllBJjF5nISYOWvtMFW6b9NkA1c=
=Ziv3
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Aber da die Skripte ja nur Optionen auswerten, würde keine der
Definitionen für
conffiles zutreffen. Erster Eindruck: Die gehören eigentlich nicht dort
hin.

Da stimme ich prinzipiell zu. Eigentlich gehören solche Skripte, die von Paketen bereitgestellt werden, nach /usr/lib/kernel/foo.d/

/etc sollte idealerweise nur lokale Modifikationen beinhalten.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmG2hEEACgkQauHfDWCP ItwVzQ//fDvqocGEf7JufyAGgLSxC5HVVpfxw1phLBwXflUhNvIH3eM9Z++c3nvv 7kbbFN2W5KIlt9XaF/qv3GBI6hBcCb6Nh/MXwXcQEb/IBSw9rK/atJSG9GK5qrxI ARcGmINOpUVWemJNlII4hDC/OXndomWO4RfzezG7eaAPatAo/MG+YKts79rmwLyd QeELGmyvx4ejNo31yrRg/wBhkZIJkKYHcb7gjbHIHmMRnmmMr6gwRxfcVhppbnUn 6ni1fUMfRDt1IvNdvI3rYRGIcor4jdaX2o6zR1ofjIb8LXp0KsTxTMWPP0FIZ7Gp 1+PpKSrpSDVMagyp7zasq5Wzznpj8jIp+IQWOH2rHAYQjyrH7VXSwCYRGXIlAvV3 WGGSc//sjZs8874kx3kUExw1SpxwzIJZwLBcm2u4X9EQsCkgyW9/qCF0Wxm5bm2l LQSu3rEy1KpJUhiBdl+BpCd1VJGG6eHHkfBd43paHBRi6E+GaL561NO0rfo6cvHV mwEC1xbzXZcbmCxr23qCSVrhM6YzQuo/9/g0mHPL8diE0SOV1AwIfEb4ug5s2Ux6 gzhzxLNZe0tOkANsDN+h99VkcSO5qBqAySrWMf/twoRExbtoDprWoyLubvca5Bbt WrzWPw4uUFTS528GJ5+Fg8dWECsYOBL/7iPkTAk++0LVyEN9HlA=
=cvfy
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Montag, 13. Dezember 2021, 00:12:56 CET schrieb Michael Biebl:

Am Samstag, 11. Dezember 2021, 11:49:35 CET schrieb Michael Biebl:

Merkwürdigerweise hat selbst ein reinstall nichts an den Rechten verändert.

Das ist zu erwarten.
Dateien in /etc sind in der Regel conffiles [1].

In der Regel, ja. Bei den betreffenden Skripten, nein.

Sind sie halt eben doch. Siehe

Das Nein bezog sich auch darauf, das sie es eigentlich nicht sein sollten (wie du ja noch nachgeschoben hast). Ich denke mal in der nächsten Woche nehme ich mir die Zeit und guck da mal komplett durch, vielleicht gibt's ja einen plausiblen Grund als Antwort auf einen Bugreport, dank debsums habe ich da schon einige Kandidaten. z.B. fehlt die README von sudo auf meinem System komplett, selbst mit einem reinstall wird sie aber nicht wiederhergestellt. Nicht lebenswichtig aber irgendwie nervig.

--
MfG usw.

Werner Mahr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 13 Dec 2021 00:22:41 +0100, Michael Biebl <biebl@debian.org>
wrote:

Aber da die Skripte ja nur Optionen auswerten, würde keine der
Definitionen für
conffiles zutreffen. Erster Eindruck: Die gehören eigentlich nicht dort
hin.

Da stimme ich prinzipiell zu. Eigentlich gehören solche Skripte, die von >Paketen bereitgestellt werden, nach /usr/lib/kernel/foo.d/

/etc sollte idealerweise nur lokale Modifikationen beinhalten.

Leider gibt es durchaus haufenweise Pakete, gerne welche aus dem Red
Hat Universum, die sich um die dort vorherrschende Unfähigkeit im
Umgang mit Conffiles herummogeln, indem sie elaborierte und hoch
komplexe Override-Mechanismen bereitstellen.

Da liefert das Paket die Defaultkonfiguration in
/usr/lib/foo/bar.conf, wenn man sie komplett überschreiben möchte,
mache man eine Kopie in /etc/foo/bar.conf und führt dort seine
Änderungen durch¹, und wenn man nur einzelne Änderungen will, lege man /etc/foo/bar.conf.d/bla.conf an, was dann ebenfalls in einem
elaborierten und komplexen Verfahren entweder mit /etc/foo/bar.conf
ode /usr/lib/foo/bar.conf zusammengemischt wird, was wiederum direkt
zu einer neuen Instanz von ¹ führt.

Zusätzlich gibt es, vermutlich weil da niemand mehr durchsteigt,
eigene Tools, die einem diese Bearbeitungsschritte abnimmt und auch
hilfsweise die Konfiguration so anzeigt, wie sie nach dem oben
beschriebenen Verfahren nun wirklich bei der Software ankommt.

Und das alles in einer Distribution, die das Conffile-Problem
eigentlich seit 1997 angemessen, flexibel, sicher und
bedienerfreundlich gelöst hat.

¹ was bedeutet, dass man bei Paketupdates Änderungen in
/usr/lib/foo/bar.conf nicht bemerkt und auch nicht angeboten bekommt

Ich hätte mir echt gewünscht, dass man an dieser Stelle den Mut gehabt hätte, die Red Hat Würgarounds auszubauen und die mit dem Paket
kommenden Konfigurationsdateien direkt als dpkg-conffiles in /etc/foo ausgeliefert hätte.

Dem geneigten Leser darf überlassen bleiben, welches Paket / welches Ökosystem ich hier meine ;-)

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)