Probleme beim Upgrade auf 15.1 via Zypper

Deutsch (German) Installation/Administration
#1

Guten Abend,
während des Upgrade auf 15.1 gemäß dieser Anleitung
https://kamarada.github.io/en/2019/05/27/how-to-upgrade-from-opensuse-leap-150-to-151/#.XcBJhpwxm02
via zypper kommt es zu folgender Meldung:

File /usr/share/proj/world
from install of
proj-5... (Haupt-Repository)
conflicts with file from package
proj5-5.2... (0System) ...
Continue?

Ich wähle “Yes” und erhalte in rot die Fehlermeldung

"Installation of GeoIP-data-1......noarch failed:
Error: Subprocess failed Error: RPM failed: installing package ... nees 52 kB on the / (hard drive)"

Die Installation kann ich dann nicht mehr erfolgreich durchführen und muss abgebrochen werden.
Nach “reboot” erhalte ich nur einen schwarzen Bildschirm mit Mauszeiger. Ich nutze eine Nvidia-Grafikkarte.
Was ist das Problem und wie kann ich nun klug weiter machen?
Danke!

#2

Bitte die komplette Ausgabe posten und nicht irgendwo etwas abschneiden…

Denn dann kann man nur sagen:
Mach mal…

#3

Wie gesagt nutze ich diese Anleitung
https://kamarada.github.io/en/2019/05/27/how-to-upgrade-from-opensuse-leap-150-to-151/#.XcGskJwxm03
Dort unter Punkt 6 will ich das Upgrade durchführen
Nach

init 3

und


zypper --no-refresh dup

kommt schon folgende Meldung

Computing distribution upgrade ...
Problem: problem with installe package libvidstab2_2-2.2.0-10.4x86_64
 Solution 1: install libvistab1_1-1.1.0-lp151.1.1.x86_64 (with venor change)
 http://packman.links2linux.de --> openSUSE
Solution 2: keep obsolete libvistab1_1-1.1.0-10.4.x86_64
Choose from above solutions by number or cancel ...

Ist das normal?

Weder mit Solution 1 noch mit Solution 2 kam ich hier bislang ohne Abbruch durch die Installation.
Es kommt immer folgende Situation:

File /usr/share/proj/world
 from install of
  proj-4.9.3-lp151.2.3.x86_64 (Haupt-Repository (OSS))
conflicts with file from package
  proj5-5.2.0-1.1.x86_64 (0System)

File conflicts happen whe tow packages attempt to install files with the same name but different contents. If you continue, conflicting files will be replaced losing the previous content.
Continue? (yes/no) (no):

Wenn ich “Ja” wähle geht es nun doch weiter. Hoffentlich klappt es jetzt?
Warte …

#4

Problem: problem with installe package libvidstab2_2-2.2.0-10.4x86_64
Solution 1: install libvistab1_1-1.1.0-lp151.1.1.x86_64 (with venor change)
http://packman.links2linux.de → openSUSE
Solution 2: keep obsolete libvistab1_1-1.1.0-10.4.x86_64
Choose from above solutions by number or cancel …

Kleiner Tip von mir:
Seit Leap 15.0 haben die Leap Pakete ein lp150 für Leap 15.0 oder ein lp151 für Leap 15.1 in der Version bzw. vor der Release-Version.
Das ist bestimmt kein Leap 15.1 Paket:
libvidstab2_2-2.2.0-10.4x86_64
Dies hier auch nicht:
libvistab1_1-1.1.0-10.4.x86_64

Aber dies hier ist eines:
libvistab1_1-1.1.0-lp151.1.1.x86_64
Und da du ja ein Upgrade auf Leap 15.1 machst…

Damit wäre dann das erste deiner Probleme gelöst…

Weder mit Solution 1 noch mit Solution 2 kam ich hier bislang ohne Abbruch durch die Installation.
Es kommt immer folgende Situation:

yes eingeben, no ist voreingestellt.
Hier kommt auch wieder obiges zum tragen, schau mal auf die Pakete…

#5

Ansonsten mal angedacht, das Paket (welches übrigens aus dem Geo Repo kommt und somit nicht Teil der offiziellen Distribution ist) zu löschen:

zypper rm proj5
#6

PS:
Ich versuche immer, jemand auf den “richtigen” Weg zu bringen anstelle der Lösung.
Denn dann lernt man auch etwas.

#7

Upgrade hat funktioniert. Danke.
Nur meine Grafikkarte hat gefühlt noch nicht den richtigen Treiber, obwohl ich das alte NVIDIA-Paket für 15.1 angepasst und den Repositories nun hinzugefügt habe.
Was muss ich tun, um den passenden Treiber zu aktivieren?
Grafikkarte: G96CGL (Quadro FX 580)

#8

Den G03 Treiber installieren.

#9

Hallo, ich glaube, die Partition »/« ist voll. So interpretiere ich die RPM-Meldung, dass 52 KB benötigt werden.

Meine Empfehlung: Für jede physikalische SSD oder HDD eine einzige primäre ext4-Partition einrichten, evtl mit ein paar GB swap und einer EFI-Boot-Partition, falls benötigt. Die YaST-Empfehlung mit mehreren btrfs-Subvolumes ist nach dem, was ich hier im Forum während der letzten Jahre mitbekommen habe, unnötig komplex und riskant (Das btrfs-Projekt ist halt noch recht jung, und administrative Erfahrungen — »best practices« — mit btrfs entwickeln sich immer noch). Ich verwende ausschließlich ext4, kein swap aufgrund genug RAM, und auch kein EFI-Boot wegen MBR-Partitionierung und Legacy-Boot via MBR/GRUB2.

Eine ext4-Partition pro Datenträger hat viele Vorteile: leichte Austauschbarkeit, triviale Komplett-Backups (1× pro Monat bei mir), überslichtliche inkrementelle und differenzielle Backups ohne Komplikationen oder Verwechslungen »übersehener« Daten oder Platzmangel aufgrund Partitionsgrenzen, alter Snapshots bzw. diverser btrfs-Subvolumes. Im Betrieb ist ext4 auch viel genügsamer und besser einschätzbar: keine btrfs-Scrubber-Kernelprozesse oder sonstigen btrfs-Daemons, keine »verschwundenen« Daten oder beim boot abgehängte brtfs-Partitionen (all diese Szenarien wurden während der verganenen Wochen in diesem Forum geschildert). Solange man Features wie Snapshots oder logische Volumes nicht unbedingt braucht, würde ich von btrfs und Empfehlungen des YaST-Partitioners abraten. Immerhin geht es hier um eine Desktop-Installation.

Noch ein Knackpunkt: Mit einer einzigen großen ext4-Root-Partition liefert mir »df -hT« stets die exakte Menge an freiem Massenspeicher, der für Installationen und Upgrades verfügbar ist — anders als btrfs, das hier notorisch unverlässliche Angaben macht, was ich bei einem Filesystem inakzeptabel finde.

Zurück zum Problem: Ist die Partition voll?

#10

Noch ein Knackpunkt: Mit einer einzigen großen ext4-Root-Partition liefert mir »df -hT« stets die exakte Menge an freiem Massenspeicher, der für Installationen und Upgrades verfügbar ist — anders als btrfs, das hier notorisch unverlässliche Angaben macht, was ich bei einem Filesystem inakzeptabel finde.

Das funktioniert auch mit df nicht, siehe

man btrfs
#11 
xx@linux-vtw5:~> df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
devtmpfs        1,9G    8,0K  1,9G    1% /dev
tmpfs           1,9G     33M  1,9G    2% /dev/shm
tmpfs           1,9G    1,5M  1,9G    1% /run
tmpfs           1,9G       0  1,9G    0% /sys/fs/cgroup
/dev/sda2        20G     16G  3,0G   84% /
/dev/sda3       208G     97G  110G   47% /home
tmpfs           381M     20K  381M    1% /run/user/1000

Noch 3 GB Platz für root-Verzeichnis. Soll ich die root-Partition vergrößern?
Den G03 von NVIDIA habe ich erfolgreich installiert. Die Anzeige ist nun bestens.
Vielen Dank. :slight_smile:

#12

Da du ja bis jetzt anscheinend mit dem Platz für / auskommst, würde ich es so lassen, evtl. mal in /tmp schauen und löschen.

#13

Ich habe ein Tumbleweed auf btrfs umgestellt:

erlangen:~ # df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb5        60G  8.2G   51G  14% /
erlangen:~ # btrfs filesystem usage /
Overall:
    Device size:                  59.45GiB
   ** Device allocated:             10.04GiB**
    **Device unallocated:           49.42GiB**
    Device missing:                  0.00B
    Used:                          8.10GiB
    Free (estimated):             50.60GiB      (min: 50.60GiB)
    Data ratio:                       1.00
    Metadata ratio:                   1.00
    Global reserve:               22.98MiB      (used: 0.00B)

Data,single: Size:9.01GiB, Used:7.83GiB
   /dev/sdb5       9.01GiB

Metadata,single: Size:1.00GiB, Used:285.19MiB
   /dev/sdb5       1.00GiB

System,single: Size:32.00MiB, Used:16.00KiB
   /dev/sdb5      32.00MiB

Unallocated:
   /dev/sdb5      49.42GiB
erlangen:~ #

Damit kann ich leben.

#14

Ich könnte auch mit NTFS »leben«, aber ich mag halt nicht. Mal abgesehen von den 4 signifikanten Stellen, die btrfs liefert:

  • 10.04/49.42 =~ 20%;
  • 10.04/50.60 =~ 19%;
  • df liefert 14%.

Nein, danke. :wink: