Hallo,
nach einem System-Update der letzten Woche funktioniert mein Scanner Brother MFC 490 CW nicht mehr. Es ist ein Multifunktionsgerät, von dem ich nur den Scanner nutze.
Simple scan meldet sich mit "Scannen fehlgeschlagen -Verbindung zum Scanner konnte nicht hergestellt werden". Den proprietäre Treiber brscan3-0.2.13-1.x86_64.rpm wurde in yast nicht mehr angezeigt; ich habe erneut installiert, doch auch danach wird er nicht mehr angezeigt.
Ich verwende opensuse 42.2, kde3.5, und spiele die meisten Updates ein, die von yast vorgeschlagen werden, solange ich dazu nicht ein komplettes kde 4 oder 5 installieren muss.
Wie kann ich hier die Fehlersuche eingrenzen?
Peter Mulller
Peter Mulller schrieb:
Hallo,
nach einem System-Update der letzten Woche funktioniert mein Scanner Brother MFC 490 CW nicht mehr. Es ist ein Multifunktionsgerät, von dem ich nur den Scanner nutze.
Simple scan meldet sich mit "Scannen fehlgeschlagen -Verbindung zum Scanner konnte nicht hergestellt werden". Den proprietäre Treiber brscan3-0.2.13-1.x86_64.rpm wurde in yast nicht mehr angezeigt; ich habe erneut installiert, doch auch danach wird er nicht mehr angezeigt.
Ich verwende opensuse 42.2, kde3.5, und spiele die meisten Updates ein, die von yast vorgeschlagen werden, solange ich dazu nicht ein komplettes kde 4 oder 5 installieren muss.
Wie kann ich hier die Fehlersuche eingrenzen?
Peter Mulller
hallo Peter
Deinen Scanner gibt es bei Leap 42.2 nicht
Bernd
Am Sunday 09 April 2017 15:00:50 schrieb Bernd:
Peter Mulller schrieb:
Hallo,
nach einem System-Update der letzten Woche funktioniert mein Scanner Brother MFC 490 CW nicht mehr. Es ist ein Multifunktionsgerät, von dem ich nur den Scanner nutze.
Simple scan meldet sich mit "Scannen fehlgeschlagen -Verbindung zum Scanner konnte nicht hergestellt werden". Den proprietäre Treiber brscan3-0.2.13-1.x86_64.rpm wurde in yast nicht mehr angezeigt; ich habe erneut installiert, doch auch danach wird er nicht mehr angezeigt.
Ich verwende opensuse 42.2, kde3.5, und spiele die meisten Updates ein, die von yast vorgeschlagen werden, solange ich dazu nicht ein komplettes kde 4 oder 5 installieren muss.
Wie kann ich hier die Fehlersuche eingrenzen?
Peter Mulller
hallo Peter
Deinen Scanner gibt es bei Leap 42.2 nicht
Bernd
Hallo Bernd,
das stimmt, die 42.2 untersützt ihn nicht, man muss dazu die Treiber einspielen, die Brother zur Verfügung stellt; damit hatte ihn schon in Betrieb.
Vermutung: Durch irgendein Update scheint das nicht mehr zu funktionieren; nur kann ich es nicht eingrenzen, wo ich da nachsehen müsste. Irgendeine Idee?
Peter Mulller
Am Montag, 10. April 2017, 09:01:51 CEST schrieb Peter Mulller:
Am Sunday 09 April 2017 15:00:50 schrieb Bernd:
Peter Mulller schrieb:
Hallo,
nach einem System-Update der letzten Woche funktioniert mein Scanner Brother MFC 490 CW nicht mehr. Es ist ein Multifunktionsgerät, von dem ich nur den Scanner nutze.
Simple scan meldet sich mit "Scannen fehlgeschlagen -Verbindung zum Scanner konnte nicht hergestellt werden". Den proprietäre Treiber brscan3-0.2.13-1.x86_64.rpm wurde in yast nicht mehr angezeigt; ich habe erneut installiert, doch auch danach wird er nicht mehr angezeigt.
Ich verwende opensuse 42.2, kde3.5, und spiele die meisten Updates ein, die von yast vorgeschlagen werden, solange ich dazu nicht ein komplettes kde 4 oder 5 installieren muss.
Wie kann ich hier die Fehlersuche eingrenzen?
Peter Mulller
hallo Peter
Deinen Scanner gibt es bei Leap 42.2 nicht
Bernd
Hallo Bernd,
das stimmt, die 42.2 untersützt ihn nicht, man muss dazu die Treiber einspielen, die Brother zur Verfügung stellt; damit hatte ihn schon in Betrieb.
Vermutung: Durch irgendein Update scheint das nicht mehr zu funktionieren; nur kann ich es nicht eingrenzen, wo ich da nachsehen müsste. Irgendeine Idee?
Peter Mulller
Poste: zypper se -s brscan
Ausserdem: http://support.brother.com/g/b/downloadhowto.aspx? c=de&lang=de&prod=mfc490cw_all&os=127&dlid=dlf006644_000&flang=4&type3=564
also benutze: brsaneconfig3 -a name=(name your device) model=(model name) ip=xx.xx.xx.xx
und brsaneconfig3 -q | grep (name of your device)
Stephan
Am Monday 10 April 2017 09:17:11 schrieb Stephan Hemeier:
Poste: zypper se -s brscan
zypper se -s brscan Repository-Daten werden geladen... Installierte Pakete werden gelesen...
S | Name | Typ | Version | Architektur | Repository --+---------+---------+----------+-------------+--------------- i | brscan3 | package | 0.2.13-1 | x86_64 | (Systempakete)
Ausserdem: http://support.brother.com/g/b/downloadhowto.aspx? c=de&lang=de&prod=mfc490cw_all&os=127&dlid=dlf006644_000&flang=4&type3=564
Ich habe die Treiber erneut runtergeladen und laut Anweisung installiert.
also benutze: brsaneconfig3 -a name=(name your device) model=(model name) ip=xx.xx.xx.xx
Nicht durchgeführt, da ich USB verwende.
und brsaneconfig3 -q | grep (name of your device)
brsaneconfig3 -q | grep MFC-490CW 66 "MFC-490CW"
Korrektur: Ich verwende opensuse 42.1, nicht 42.2.
Verhalten unter Xsane:
Xsane ohnse USB-Verbindung meldet: Keine Geräte erreichbar
Xsane mit USB-Verbindung meldet: Fehler beim Öffnen des Geräts „brother3:bus4;dev2‘:Fehler während Geräte I/O.
Kann man da was raus lesen?
Peter Mulller
Hallo zusammen,
Peter Mulller meinte am Montag, den 10.04.2017 um 09:01 Uhr wegen:Brother Scanner funktioniert nach Update nicht mehr
Am Sunday 09 April 2017 15:00:50 schrieb Bernd:
Peter Mulller schrieb:
Hallo,
nach einem System-Update der letzten Woche funktioniert mein Scanner Brother MFC 490 CW nicht mehr. Es ist ein Multifunktionsgerät, von dem ich nur den Scanner nutze.
Simple scan meldet sich mit "Scannen fehlgeschlagen -Verbindung zum Scanner konnte nicht hergestellt werden". Den proprietäre Treiber brscan3-0.2.13-1.x86_64.rpm wurde in yast nicht mehr angezeigt; ich habe erneut installiert, doch auch danach wird er nicht mehr angezeigt.
Ich verwende opensuse 42.2, kde3.5, und spiele die meisten Updates ein, die von yast vorgeschlagen werden, solange ich dazu nicht ein komplettes kde 4 oder 5 installieren muss.
Wie kann ich hier die Fehlersuche eingrenzen?
Peter Mulller
hallo Peter
Deinen Scanner gibt es bei Leap 42.2 nicht
Bernd
Hallo Bernd,
das stimmt, die 42.2 untersützt ihn nicht, man muss dazu die Treiber einspielen, die Brother zur Verfügung stellt; damit hatte ihn schon in Betrieb.
Vermutung: Durch irgendein Update scheint das nicht mehr zu funktionieren; nur kann ich es nicht eingrenzen, wo ich da nachsehen müsste. Irgendeine Idee?
Peter Mulller
ivh denken, die Treiber von Brother installieren und ggf. udev-rules kontrollieren.
Hallo Christian,
Am Monday 10 April 2017 12:47:40 schrieb Christian Meseberg:
ivh denken, die Treiber von Brother installieren und ggf. udev-rules kontrollieren.
die Treiber waren installiert, der Tipp mit den udev-rules war zielführend, vielen Dank.
Die Vorgehensweise habe ich auf
http://support.brother.com/g/s/id/linux/en/instruction_scn1c.html?c=de&l...
gefunden. Sie ist dort zwar für openSUSE 11.2 geschrieben, funktioniert aber auch für 42.1:
openSUSE11.2 1. Open "/etc/udev/rules.d/55-libsane.rules" 2. Add the following 2 lines at the last of the device entry. (just before "# The following rule...") # Brother ATTR{idVendor}=="04f9", MODE="0664", GROUP="lp", ENV{libsane_matched}="yes" 3. Restart the OS.
Als ich die Datei /etc/udev/rules.d/55-libsane.rules aufrufen wollte, habe ich gesehen, dass vor ein paar Tagen zum Zeitpunkt der Systemaktualisierung eine Backupdatei angelegt wurde. Durch die Verwendung der alten Datei funktioniert der Scanner wieder (sie enthält die obigen Einträge). Vielen Dank an dich und Stephan Hemeier für die Hilfe.
Wie kann man denn bei künftigen Updates so ein Überschreiben vermeiden? Ich bringe yast da ein gewisses Vertrauen entgegen, da ich viele der zu aktualisierenden Programme gar nicht kenne bzw. nicht abschätzen kann, wo was geändert wird. Bis lang ging, zumindest bei kde 3.5, alles gut.
Peter Mulller
Am Montag, 10. April 2017, 17:26:21 CEST schrieb Peter Mulller:
Hallo Christian,
Am Monday 10 April 2017 12:47:40 schrieb Christian Meseberg:
ivh denken, die Treiber von Brother installieren und ggf. udev-rules kontrollieren.
die Treiber waren installiert, der Tipp mit den udev-rules war zielführend, vielen Dank.
Die Vorgehensweise habe ich auf
http://support.brother.com/g/s/id/linux/en/instruction_scn1c.html?c=de&l... de&prod=mfc490cw_all&redirect=on
gefunden. Sie ist dort zwar für openSUSE 11.2 geschrieben, funktioniert aber auch für 42.1:
openSUSE11.2
- Open "/etc/udev/rules.d/55-libsane.rules"
- Add the following 2 lines at the last of the device entry. (just before
"# The following rule...") # Brother ATTR{idVendor}=="04f9", MODE="0664", GROUP="lp", ENV{libsane_matched}="yes" 3. Restart the OS.
Als ich die Datei /etc/udev/rules.d/55-libsane.rules aufrufen wollte, habe ich gesehen, dass vor ein paar Tagen zum Zeitpunkt der Systemaktualisierung eine Backupdatei angelegt wurde. Durch die Verwendung der alten Datei funktioniert der Scanner wieder (sie enthält die obigen Einträge). Vielen Dank an dich und Stephan Hemeier für die Hilfe.
Wie kann man denn bei künftigen Updates so ein Überschreiben vermeiden? Ich bringe yast da ein gewisses Vertrauen entgegen, da ich viele der zu aktualisierenden Programme gar nicht kenne bzw. nicht abschätzen kann, wo was geändert wird. Bis lang ging, zumindest bei kde 3.5, alles gut.
Peter Mulller
Wird überschrieben durch ein Update von sane-backends
rpm -q --whatprovides /etc/udev/rules.d/55-libsane.rules sane-backends-1.0.25.git20170403-3.1.x86_64
Stephan
Hallo Stephan,
Am Monday 10 April 2017 17:46:39 schrieb Stephan Hemeier:
Wie kann man denn bei künftigen Updates so ein Überschreiben vermeiden? Ich bringe yast da ein gewisses Vertrauen entgegen, da ich viele der zu aktualisierenden Programme gar nicht kenne bzw. nicht abschätzen kann, wo was geändert wird. Bis lang ging, zumindest bei kde 3.5, alles gut.
Wird überschrieben durch ein Update von sane-backends
rpm -q --whatprovides /etc/udev/rules.d/55-libsane.rules sane-backends-1.0.25.git20170403-3.1.x86_64
super, auch für diesen Wink "whatprovides" ein herzliches Dankeschön, wieder was dazugelernt.
Peter Mulller
Am 10.04.2017 um 17:46 schrieb Stephan Hemeier:
Am Montag, 10. April 2017, 17:26:21 CEST schrieb Peter Mulller:
Hallo Christian,
Am Monday 10 April 2017 12:47:40 schrieb Christian Meseberg:
ivh denken, die Treiber von Brother installieren und ggf. udev-rules kontrollieren.
die Treiber waren installiert, der Tipp mit den udev-rules war zielführend, vielen Dank.
Die Vorgehensweise habe ich auf
http://support.brother.com/g/s/id/linux/en/instruction_scn1c.html?c=de&l... de&prod=mfc490cw_all&redirect=on
gefunden. Sie ist dort zwar für openSUSE 11.2 geschrieben, funktioniert aber auch für 42.1:
openSUSE11.2
- Open "/etc/udev/rules.d/55-libsane.rules"
- Add the following 2 lines at the last of the device entry. (just before
"# The following rule...") # Brother ATTR{idVendor}=="04f9", MODE="0664", GROUP="lp", ENV{libsane_matched}="yes" 3. Restart the OS.
Als ich die Datei /etc/udev/rules.d/55-libsane.rules aufrufen wollte, habe ich gesehen, dass vor ein paar Tagen zum Zeitpunkt der Systemaktualisierung eine Backupdatei angelegt wurde. Durch die Verwendung der alten Datei funktioniert der Scanner wieder (sie enthält die obigen Einträge). Vielen Dank an dich und Stephan Hemeier für die Hilfe.
Wie kann man denn bei künftigen Updates so ein Überschreiben vermeiden? Ich bringe yast da ein gewisses Vertrauen entgegen, da ich viele der zu aktualisierenden Programme gar nicht kenne bzw. nicht abschätzen kann, wo was geändert wird. Bis lang ging, zumindest bei kde 3.5, alles gut.
Peter Mulller
Wird überschrieben durch ein Update von sane-backends
rpm -q --whatprovides /etc/udev/rules.d/55-libsane.rules sane-backends-1.0.25.git20170403-3.1.x86_64
Da ist aber meiner Meinung nach dann das Paket Murks, das sollte niemals überschrieben werden, nachdem die Datei vom Benutzer verändert worden ist (was ja in vielen Fällen erforderlich ist)
Ich bin beim RPM Paketen leider nicht mehr mit meinem Wissen aktuell, aber bei Debian Paketen kann man definieren, welche (Konfigurations-)Dateien vor eventuellen Paketupdates geschützt werden sollen. Ich bin sicher, dass es diesen Mechanismus auch bei RPM Paketen gibt.
Gruß Manfred
Am Montag, 10. April 2017, 20:32:34 CEST schrieb Manfred Kreisl:
Am 10.04.2017 um 17:46 schrieb Stephan Hemeier:
Am Montag, 10. April 2017, 17:26:21 CEST schrieb Peter Mulller:
Hallo Christian,
Am Monday 10 April 2017 12:47:40 schrieb Christian Meseberg:
ivh denken, die Treiber von Brother installieren und ggf. udev-rules kontrollieren.
die Treiber waren installiert, der Tipp mit den udev-rules war zielführend, vielen Dank.
Die Vorgehensweise habe ich auf
http://support.brother.com/g/s/id/linux/en/instruction_scn1c.html?c=de&l... ng= de&prod=mfc490cw_all&redirect=on
gefunden. Sie ist dort zwar für openSUSE 11.2 geschrieben, funktioniert aber auch für 42.1:
openSUSE11.2
- Open "/etc/udev/rules.d/55-libsane.rules"
- Add the following 2 lines at the last of the device entry. (just
before "# The following rule...") # Brother ATTR{idVendor}=="04f9", MODE="0664", GROUP="lp", ENV{libsane_matched}="yes" 3. Restart the OS.
Als ich die Datei /etc/udev/rules.d/55-libsane.rules aufrufen wollte, habe ich gesehen, dass vor ein paar Tagen zum Zeitpunkt der Systemaktualisierung eine Backupdatei angelegt wurde. Durch die Verwendung der alten Datei funktioniert der Scanner wieder (sie enthält die obigen Einträge). Vielen Dank an dich und Stephan Hemeier für die Hilfe.
Wie kann man denn bei künftigen Updates so ein Überschreiben vermeiden? Ich bringe yast da ein gewisses Vertrauen entgegen, da ich viele der zu aktualisierenden Programme gar nicht kenne bzw. nicht abschätzen kann, wo was geändert wird. Bis lang ging, zumindest bei kde 3.5, alles gut.
Peter Mulller
Wird überschrieben durch ein Update von sane-backends
rpm -q --whatprovides /etc/udev/rules.d/55-libsane.rules sane-backends-1.0.25.git20170403-3.1.x86_64
Da ist aber meiner Meinung nach dann das Paket Murks, das sollte niemals überschrieben werden, nachdem die Datei vom Benutzer verändert worden ist (was ja in vielen Fällen erforderlich ist)
Ich bin beim RPM Paketen leider nicht mehr mit meinem Wissen aktuell, aber bei Debian Paketen kann man definieren, welche (Konfigurations-)Dateien vor eventuellen Paketupdates geschützt werden sollen. Ich bin sicher, dass es diesen Mechanismus auch bei RPM Paketen gibt.
Gruß Manfred
Dann solltest du das auch mal bei Debian anmerken, gerade sane installiert, Nach dieser Anleitung die Datei /lib/udev/rules.d/60-libsane.rules geändert, Neu gestartet, sane gelöscht und nichts ist mehr vorhanden.
http://support.brother.com/g/s/id/linux/en/instruction_scn1c.html? c=de&lang=de&prod=mfc490cw_all&redirect=on#d6
Auch nicht so Anfängerfreundlich.
Stephan
Hallo Stephan,
Am Tuesday 11 April 2017 08:52:34 schrieb Stephan Hemeier:
Dann solltest du das auch mal bei Debian anmerken, gerade sane installiert, Nach dieser Anleitung die Datei /lib/udev/rules.d/60-libsane.rules geändert, Neu gestartet, sane gelöscht und nichts ist mehr vorhanden.
http://support.brother.com/g/s/id/linux/en/instruction_scn1c.html? c=de&lang=de&prod=mfc490cw_all&redirect=on#d6
Auch nicht so Anfängerfreundlich.
das ist doch aber sogar sinnvoll, dass mit dem Löschen des Programms alle "Konfiguratinsdateien", also auch die udev-Regeln, gelöscht werden, oder?
Peter Mulller
Am 11.04.2017 um 13:44 schrieb Peter Mulller:
Hallo Stephan,
Am Tuesday 11 April 2017 08:52:34 schrieb Stephan Hemeier:
Dann solltest du das auch mal bei Debian anmerken, gerade sane installiert, Nach dieser Anleitung die Datei /lib/udev/rules.d/60-libsane.rules geändert, Neu gestartet, sane gelöscht und nichts ist mehr vorhanden.
http://support.brother.com/g/s/id/linux/en/instruction_scn1c.html? c=de&lang=de&prod=mfc490cw_all&redirect=on#d6
Auch nicht so Anfängerfreundlich.
das ist doch aber sogar sinnvoll, dass mit dem Löschen des Programms alle "Konfiguratinsdateien", also auch die udev-Regeln, gelöscht werden, oder?
Jein ;) Bei Debian gibt es zwei Arten um Pakete zu deinstalleren: 1) remove --> entfernt das Paket und behält Konfigurationsdateien 2) purge --> putzt alles von der Platte Funktioniert natürlich nur, wenn die Maintainer Skripte auch korrekt sind. Diesen Mechanismus gibt es bestimmt bei RPM's auch
Gruß Manfred
Am 11.04.2017 um 08:52 schrieb Stephan Hemeier:
Am Montag, 10. April 2017, 20:32:34 CEST schrieb Manfred Kreisl:
Am 10.04.2017 um 17:46 schrieb Stephan Hemeier:
Am Montag, 10. April 2017, 17:26:21 CEST schrieb Peter Mulller:
Hallo Christian,
Am Monday 10 April 2017 12:47:40 schrieb Christian Meseberg:
ivh denken, die Treiber von Brother installieren und ggf. udev-rules kontrollieren.
die Treiber waren installiert, der Tipp mit den udev-rules war zielführend, vielen Dank.
Die Vorgehensweise habe ich auf
http://support.brother.com/g/s/id/linux/en/instruction_scn1c.html?c=de&l... ng= de&prod=mfc490cw_all&redirect=on
gefunden. Sie ist dort zwar für openSUSE 11.2 geschrieben, funktioniert aber auch für 42.1:
openSUSE11.2
- Open "/etc/udev/rules.d/55-libsane.rules"
- Add the following 2 lines at the last of the device entry. (just
before "# The following rule...") # Brother ATTR{idVendor}=="04f9", MODE="0664", GROUP="lp", ENV{libsane_matched}="yes" 3. Restart the OS.
Als ich die Datei /etc/udev/rules.d/55-libsane.rules aufrufen wollte, habe ich gesehen, dass vor ein paar Tagen zum Zeitpunkt der Systemaktualisierung eine Backupdatei angelegt wurde. Durch die Verwendung der alten Datei funktioniert der Scanner wieder (sie enthält die obigen Einträge). Vielen Dank an dich und Stephan Hemeier für die Hilfe.
Wie kann man denn bei künftigen Updates so ein Überschreiben vermeiden? Ich bringe yast da ein gewisses Vertrauen entgegen, da ich viele der zu aktualisierenden Programme gar nicht kenne bzw. nicht abschätzen kann, wo was geändert wird. Bis lang ging, zumindest bei kde 3.5, alles gut.
Peter Mulller
Wird überschrieben durch ein Update von sane-backends
rpm -q --whatprovides /etc/udev/rules.d/55-libsane.rules sane-backends-1.0.25.git20170403-3.1.x86_64
Da ist aber meiner Meinung nach dann das Paket Murks, das sollte niemals überschrieben werden, nachdem die Datei vom Benutzer verändert worden ist (was ja in vielen Fällen erforderlich ist)
Ich bin beim RPM Paketen leider nicht mehr mit meinem Wissen aktuell, aber bei Debian Paketen kann man definieren, welche (Konfigurations-)Dateien vor eventuellen Paketupdates geschützt werden sollen. Ich bin sicher, dass es diesen Mechanismus auch bei RPM Paketen gibt.
Gruß Manfred
Dann solltest du das auch mal bei Debian anmerken, gerade sane installiert, Nach dieser Anleitung die Datei /lib/udev/rules.d/60-libsane.rules geändert, Neu gestartet, sane gelöscht und nichts ist mehr vorhanden.
http://support.brother.com/g/s/id/linux/en/instruction_scn1c.html? c=de&lang=de&prod=mfc490cw_all&redirect=on#d6
Auch nicht so Anfängerfreundlich.
Ich habe nie behauptet, dass Debian es richtig macht. Ich habe nur die korrekte Vorgehensweise aufgezeigt.
Gruß Manfred
Hallo Peter, hallo zusammen,
Am Montag, 10. April 2017, 17:26:21 CEST schrieb Peter Mulller: ...
Als ich die Datei /etc/udev/rules.d/55-libsane.rules aufrufen wollte, habe ich gesehen, dass vor ein paar Tagen zum Zeitpunkt der Systemaktualisierung eine Backupdatei angelegt wurde. Durch die Verwendung der alten Datei funktioniert der Scanner wieder (sie enthält die obigen Einträge). Vielen Dank an dich und Stephan Hemeier für die Hilfe.
Wie kann man denn bei künftigen Updates so ein Überschreiben vermeiden? Ich bringe yast da ein gewisses Vertrauen entgegen, da ich viele der zu aktualisierenden Programme gar nicht kenne bzw. nicht abschätzen kann, wo was geändert wird. Bis lang ging, zumindest bei kde 3.5, alles gut.
Ich gehe mal davon aus, dass die Backupdatei den Namen *.rpmsave oder *.rpmorig hatte - das ist dann der übliche Mechanismus. (Es gibt auch *.rpmnew, wenn die Datei im RPM als "config noreplace" markiert ist - *.rpmnew ist dann die Version aus dem neuen RPM.)
In diesem Fall ist die Lösung noch einfacher ;-)
Soweit ich weiß, liest udev alle *.rules-Dateien in diesem Verzeichnis. Du kannst also einfach eine Datei /etc/udev/rules.d/55-mein-scanner.rules anlegen und die Zeilen für Deinen Scanner da reinschreiben ;-) Da dieser Dateiname in keinem RPM vorkommt, sollte die Datei Updates problemlos überleben.
BTW: Die Zahl 55 ist auch nicht vorgeschrieben, die entscheidet "nur" darüber, in welcher Reihenfolge die Dateien gelesen werden.
Gruß
Christian Boltz
Hallo Christian,
Am Monday 10 April 2017 22:57:38 schrieb Christian Boltz:
Hallo Peter, hallo zusammen,
Am Montag, 10. April 2017, 17:26:21 CEST schrieb Peter Mulller: ...
Als ich die Datei /etc/udev/rules.d/55-libsane.rules aufrufen wollte, habe ich gesehen, dass vor ein paar Tagen zum Zeitpunkt der Systemaktualisierung eine Backupdatei angelegt wurde. Durch die Verwendung der alten Datei funktioniert der Scanner wieder (sie enthält die obigen Einträge). Vielen Dank an dich und Stephan Hemeier für die Hilfe.
Wie kann man denn bei künftigen Updates so ein Überschreiben vermeiden? Ich bringe yast da ein gewisses Vertrauen entgegen, da ich viele der zu aktualisierenden Programme gar nicht kenne bzw. nicht abschätzen kann, wo was geändert wird. Bis lang ging, zumindest bei kde 3.5, alles gut.
Ich gehe mal davon aus, dass die Backupdatei den Namen *.rpmsave oder *.rpmorig hatte - das ist dann der übliche Mechanismus. (Es gibt auch *.rpmnew, wenn die Datei im RPM als "config noreplace" markiert ist - *.rpmnew ist dann die Version aus dem neuen RPM.)
In diesem Fall ist die Lösung noch einfacher ;-)
die Backupdatei von /etc/udev/rules.d/55-libsane.rules hatte einfach eine vorangestellte Tilde.
Soweit ich weiß, liest udev alle *.rules-Dateien in diesem Verzeichnis. Du kannst also einfach eine Datei /etc/udev/rules.d/55-mein-scanner.rules anlegen und die Zeilen für Deinen Scanner da reinschreiben ;-)
Genau das hatte ich ja bei meiner ursprünglichen erfolgreichen Installation gemacht, und genau diese Datei wurde durch ein Update von sane-backends überschrieben.
Da dieser Dateiname in keinem RPM vorkommt, sollte die Datei Updates problemlos überleben.
Nein, leider nicht.
BTW: Die Zahl 55 ist auch nicht vorgeschrieben, die entscheidet "nur" darüber, in welcher Reihenfolge die Dateien gelesen werden.
Ah, danke, ich hatte mich schon immer über diese Zahlen gewundert.
Peter Mulller
-
Bernd -
Christian Boltz -
Christian Meseberg -
Manfred Kreisl -
Peter Mulller -
Stephan Hemeier