Beiträge von Boreas

Zitat von CaNEworld

Als Notlösung denkbar, da es äußerst langsam ist wenn man einen Ordner mit mehr Dateien und Unterordnern durchsucht.

Hab' ich gerade mal probiert und gemessen: aus 10847 Dateien in div. Unterverzeichnissen wurden 1431 pdf-Dateien durchsucht. Dabei wurden insgesamt 135 Fundstellen gefunden. Zeit 50,5s. Langsam?

Nimm pdfgrep dafür. Ist im Standard-Repo enthalten.

Zitat von Alero

zypper lr -d

@Tamerlein
Du bist hier in einem Amateur openSUSE-Forum - praktisch alle Mitglieder sind keine Profis hier. Nur Profis können es sich leisten ein System, das rd. 1½ Jahre nicht mehr unterstützt wird, per upgrade wieder aktuell zu stellen.
I.d.R. versuchen die Teilnehmer, Ihre Probleme möglichst aussagekräftig, zu beschreiben. Über 3rd Party Software, die der Grund für die Maschine ist, kann hier vermutlich auch keiner zuverlässige Aussagen machen.

Zitat von Tamerlain

ich habe schon bei vielen Linux ein Major Release Update erfolgreich durchgeführt

Herzlichen Glückwunsch ich bin beeindruckt - was nicht viel heißen soll, denn ich bin dilettantischer Anfänger.

Zitat von Tamerlain

Was zum Henker also treibt der Zypper hier und mehr von Interesse wie kann man ihm das ein für allemal abgewöhnen?

Was man zypper so alles abgewöhnen kann - keine Ahnung davon steht nichts in den man-pages. Vielleicht können hier die zuständigen Entwickler helfen.
Entschuldigung aber, das Betriebssystem Doof, ist mir nicht bekannt - der Name suggeriert, das hier evtl. der Grund Deines Problems liegen könnten.
scnr.

Dies kleine how to soll zeigen wie NMEA-Signale unter openSUSE Leap 15.0 verfügbar gemacht werden, wenn
in einem DELL Notebook der Baureihen Latitude, Inspiron oder Precision eine WWAN-Karte mit der Bezeichnung
5811e verbaut ist. Die Karte wird bei DELL als Qualcomm® Snapdragon X7 LTE-A-Karte aufgeführt.
Der Befehl lsusb fördert so etwas wie:

Bus 002 Device 002: ID 413c:81b6 Dell Computer Corp.

zutage. Der verbaute Chip ist von Sierra Wireless. Neben einem LTE-A-fähigen Modem verfügt dieser über ein GNSS-Empfänger (global navigation satellite system receiver). Dieser bietet GPS-, GLONASS- und Beidou-Satellitensystemunterstützung. usb-devices zeigt, sofern keine gps-Signale verfügbar sind:

T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=413c ProdID=81b6 Rev=00.06
S:  Manufacturer=Sierra Wireless, Incorporated
S:  Product=DW5811e Snapdragon™ X7 LTE
S:  SerialNumber=0815blabla
C:  #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=504mA
I:  If#=12 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I:  If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim

Es wird also nur das KernelModul cdc_mbim geladen. (Der cdc_mbim-Treiber unterstützt USB-Geräte nach der "Universal
Serial Bus Communications Class Subclass Specification for Mobile Broadband Interface Model" und ist optimiert für mobile Breitband Geräte (3G/LTE-Geräte)). Es fehlt das Kernel-Modul, das die GNSS-Signale verfügbar macht. Im Falle des hier werkelnden Chips ist dies der qcserial-Treiber.
Es stellt sich die Frage, warum der qcserial-Treiber nicht geladen wird, wenn eine Unterstützung der Hardeware gegeben ist, wie der Blick in die Linux Kernel Driver DataBase zeigt. Das Problem offenbart sich schnell,
wenn überprüft wird, welche USB composition für das Gerät gewählt wurde (oder besser ausgedrückt voreingestellt ist.) (USB compositions legen fest, mit welchen Interfaces ein Gerät auf dem USB-Bus erscheinen soll.)
Glücklicherweise gibt es ein perl-script (Autor: Bjørn Mork), dass die gewünschte Aussage hinsichtlich der USB compositionen liefert.
Ein Aufruf mit perl swi_setusbcomp.pl führt zu Ausgabe von

...
Current USB composition: 9
USB compositions:
   0 - HIP  DM    NMEA  AT    MDM1  MDM2  MDM3  MS      NOT SUPPORTED
   1 - HIP  DM    NMEA  AT    MDM1  MS                  NOT SUPPORTED
   2 - HIP  DM    NMEA  AT    NIC1  MS                  NOT SUPPORTED
   3 - HIP  DM    NMEA  AT    MDM1  NIC1  MS            NOT SUPPORTED
   4 - HIP  DM    NMEA  AT    NIC1  NIC2  NIC3  MS      NOT SUPPORTED
   5 - HIP  DM    NMEA  AT    ECM1  MS                  NOT SUPPORTED
   6 - DM   NMEA  AT    QMI                             SUPPORTED
   7 - DM   NMEA  AT    RMNET1 RMNET2 RMNET3            NOT SUPPORTED
   8 - DM   NMEA  AT    MBIM                            SUPPORTED
*  9 - MBIM                                             SUPPORTED
  10 - NMEA MBIM                                        NOT SUPPORTED
  11 - DM   MBIM                                        NOT SUPPORTED
  12 - DM   NMEA  MBIM                                  NOT SUPPORTED
  13 - Config1: comp6    Config2: comp8                 NOT SUPPORTED
  14 - Config1: comp6    Config2: comp9                 NOT SUPPORTED
  15 - Config1: comp6    Config2: comp10                NOT SUPPORTED
  16 - Config1: comp6    Config2: comp11                NOT SUPPORTED
  17 - Config1: comp6    Config2: comp12                NOT SUPPORTED
  18 - Config1: comp7    Config2: comp8                 NOT SUPPORTED
  19 - Config1: comp7    Config2: comp9                 NOT SUPPORTED
  20 - Config1: comp7    Config2: comp10                NOT SUPPORTED
  21 - Config1: comp7    Config2: comp11                NOT SUPPORTED
  22 - Config1: comp7    Config2: comp12                NOT SUPPORTED
...

Die USB composition Nr. 9 lässt lediglich das MBIM-Interface auf dem USB-Bus erscheinen. Für die gewünschten GNSS-Signale brauchen wir aber das NMEA-Interface (National Marine Electronics Association).
(NMEA 0183 beschreibt einen Kommunikationstandard zwischen GNSS-Empfänger und auswertenden Geräten wie PCs oder anderen Endgeräten. Das NMEA-Interface arbeitet genau nach dieser Vorgabe.) Also wäre USB composition Nr. 8 die, die benötigt wird. Mit perl swi_setusbcomp.pl --usbcomp=8 wird dies erreicht. usb-devices zeigt nach dieser Änderung und Neustart, dass das Kernel-Modul qcserial nun geladen ist.

T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=413c ProdID=81b6 Rev=00.06
S:  Manufacturer=Sierra Wireless, Incorporated
S:  Product=DW5811e Snapdragon™ X7 LTE
S:  SerialNumber=0815blabla
C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=504mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
I:  If#=12 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I:  If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=qcserial
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=qcserial

Jetzt muss nur noch dafür Sorge getragen werden, dass die NMEA-Daten auf den USB-Bus gelegt werden.
Die Ausgabe obigen perl-scripts gibt über die Spaltennummer des Interfaces die Nummer des pseudo-UBS-Devices auf den die Daten des Interfaces gelegt werden an. Also werden die NMEA-Daten mit
echo "\$GPS_START" >/dev/ttyUSB1 explizites eingeschaltet. Die NMEA-Daten werden dann auf den USB-Bus gelegt.
Mit cat /dev/ttyUSB1 lassen sich die NMEA-Daten auf stout anschauen. Fertig.

Anm.: Unter Umständen wird die WWAN-Karte nicht korrekt vom System erkannt. Abhilfe schafft in einem solchen Fall eine eigene udev-Regel, die in eine Textdatei, z.B. mit dem Namen 99-dell5811e.rules im
Verzeichnis /etc/udev/rules.d/ abgelegt wird. Die Dateirechte sind 644 (oktal), Eigentümer und Gruppe auf root:root setzen.

# load qcserial module
SUBSYSTEM=="usb", \
        ATTR{idVendor}=="413c", ATTR{idProduct}=="81b6", \
        RUN+="/sbin/modprobe -b qcserial"


# force Dell WWAN 5811e (Snapdragon™ X7 LTE)to configuration #1
SUBSYSTEM=="usb", \
        ATTR{idVendor}=="413c", ATTR{idProduct}=="81b6", \
        ATTR{bConfigurationValue}="1"


# add the new id in the qcserial driver
SUBSYSTEM=="drivers", \
        ENV{DEVPATH}=="/bus/usb-serial/drivers/qcserial", \
        ATTR{new_id}="413c 81b6"

Sorry, aber ich habe damit kein Problem. Es ging und geht mir nur um die Frage, ob der Eintrag in der Datei
shadow:

...
root::12209:0:99999:7:-1:-1:1074970543
...

dazu führt, das sich root ohne Passwort am System anmelden kann oder die Anmerkung auf den manpages für ubuntu auch für openSUSE Leap 15.0 zutrift.

Ich fand die Sache mit dem vergessenen root-passwort interessant. Also habe ich gleich einmal versucht es nach dieser Anleitung
(Single user mode) zu probieren. Alles lief prima - nur die Anmeldung an der Konsole als root schlug fehl.
Nach Rücksichern der originalen shadow-Datei habe ich dann das gleiche nochmals versucht - aber vergebens.
Auf den manpages von ubuntu lass ich dann Folgendes:

Zitat

verschlüsseltes Passwort
Sie sollten in crypt(3) nachsehen, wenn Sie mehr über die Bedeutung dieser
Zeichenkette wissen wollen.

Wenn das Passwortfeld eine Zeichenkette enthält, die kein zulässiges Ergebnis von
crypt(3) ist, z.B. ! oder *, kann sich der Benutzer nicht mit einem Unix-Passwort
anmelden; eine Anmeldung auf anderem Wege wird dadurch nicht verhindert.

Dieses Feld kann leer bleiben. In diesem Fall kann sich der angegebene Benutzer ohne
Passwort anmelden. Möglicherweise verweigern Anwendungen, welche die Datei /etc/shadow
auswerten, dennoch den Zugang, wenn das Passwortfeld leer ist.

A password field which starts with an exclamation mark means that the password is
locked. The remaining characters on the line represent the password field before the
password was locked.

Alles anzeigen

Könnte es sein, dass auch bei openSUSE das Passwortfeld nicht leer sein darf? Ist evtl. aus Sicherheitserwägungen heraus auch sinnvoll.

Nur als Anmerkung: Soweit mir bekannt ist, verlangt Microsoft bei Win10 nicht zwingend den Schalter für Secure Boot. Die Win10 Sicherheitsanforderungen sind auch für Desktop PCs: UEFI mit aktivierten Secure Boot.
Aber egal.
Im Klartext, soweit ich Deine Info richtig verstehe, ist Deine Vorgehensweise nicht so, wie hier mehrfach empfohlen. Was soll das Spiegeln des/der OS? Wie hast Du das gemacht. Es benötigt kein Passwort für den Secure Boot. Ein gespiegeltes Win10 läuft nicht so einfach, wie Z_O_O_M schon gesagt hat. Du beschreibst einfach nicht sauber was Du wie und in welcher Reihenfolge getan hast. openSUSE nutzt einen Microsoft signierten EFI-Bootloader. Du solltest also im BIOS unter dem Punkt UEFI min. zwei zulässige Einträge sehen, openSUSE und Windows 10. Falls nicht, hast Du und nicht der Rechner irgendetwas vermurkst. Sind beide OS jetzt auf der m.2 SSD? Kannst Du den ursprünglichen Zustand, bevor Du begonnen hast, am System Veränderungen vorzunehmen, wieder herstellen? Wenn ja, dann mach dass. Reserviere auf der m.2 SSD rd. 20 GB unpartitionierten Speicherplatz. Installiere openSUSE in diesen Bereich (ext4 als Dateisystem), Für /home wählst Du die andere SSD. Mehr ist nicht zu tun.

Zitat von wacken

Ja werde ich versuchen, dies dauert aber ein bisschen länger und die Zeit habe ich momentan nicht. Kleinigkeiten kann ich jedoch schnell ausprobieren.

Gibt es hier schon Ergebnisse?

Manuelles kopieren des gesamten Inhaltes der Linux-EFI-Partition auf die EFI-Windows-Partition? Habe ich das so richtig verstanden? D. h. Du hast die Windows-EFI-Partition überschrieben!? Oder sprechen wir hier vom gesamten Verzeichnispfad /boot samt aller Dateien und Unterverzeichnissen. Ich hoffe, dass Du den vorherigen Zustand wieder herstellen kannst.
Ich verstehe Deine ursprüngliche Intension, dargelegt in Post #27, aber wie wäre es, wenn Du mal meinen Vorschlag aus Post #12 (2) beherzigst und schaust, ob das in gewünschter Weise funktioniert. Dann wäre zu nächst mal erreicht, dass Du ein funktionierendes Dualbootsystem hättest und damit zunächst auch "arbeitsfähig" wärst.