in Ordnung,
habe ich schon gemacht. Ich verstehe nicht, warum der Zugriff auf die Community Repositories anscheinend von opensuse eingestellt wurde. Aus Gründen des Viren- oder Datenschutzes oder ist die nur vorübergehend?
in Ordnung,
habe ich schon gemacht. Ich verstehe nicht, warum der Zugriff auf die Community Repositories anscheinend von opensuse eingestellt wurde. Aus Gründen des Viren- oder Datenschutzes oder ist die nur vorübergehend?
Hallo,
in Yast2 können die community repositories nicht mehr heruntergeladen werden. Wenn ich in Yast2 - Software Repositories -Hinzufügen - Community-Repositories - Weiter eingebe erscheint die Meldung
Warnung
Die Liste der Repositorys konnte nicht heruntergeladen werden
oder es sind keine Repositorys definiert.
Diese Meldung wird bei opensuse 15.5, opensuse 15.4, opensuse 15.2 auf einem Computer und opensuse 15.5 auf zwei Notebooks angezeigt.
Am 10. November erschien diese Meldung nicht, als ich auf einer externen Festplatte opensuse 15.5 zu Testzwecken installiert habe. In Yast wurden die Community Repositories angezeigt.
Da ich auf den Notebooks sowie opensuse 15.4 und opensuse 15.2 im November keine Pakete installiert oder entfernt habe, kann diese Meldung nicht von Änderungen in der Software abhängen.
Wurden die Community Repositories unter Yast entfernt oder sind zusätzliche Einstellungen seit dem 10. November erforderlich?
ich habe opensuse nur auf der externen Festplatte installiert, um den Fehler bei grub2 zu suchen.
Ich werde dann die neue opensuse Leap 15.6 demnächst testweise auf einer externen Festplatte installieren, um zu sehen, ob alle Programme, die ich verwende. auch laufen.
Unter den Programmen sind auch einige ältere Programme, die bei den aktuelleren opensuse Versionen nicht mehr vorhanden sind.
da es mir keine Ruhe gelassen hat, habe ich nochmals einen ausführlichen Test auf einer externen SSD durchgeführt.
Nach einer Grundinstallation von openSUSE Leap 15.5 ohne online Repositories, habe ich die online Repositories von opensuse aktiviert und aktualisiert.
Installiert wurden bei der Grundinstallation grub2, grub2-i386-pc, grub2-snapper-plugin und grub2-systemd-sleep-plugin in der Version 2.06-150500.27.4-x86_64.
Alle grub2 Pakete habe ich nacheinander installiert und jeweils die grub.cfg verglichen.
Diese waren bis zur Version 2.06-150500.29.31.1 richtig ohne error Meldung von grub2 und das System konnte problemlos gebootet werden.
Bei Installation der neuesten Version von grub2 Pakete 2.06-150500.29.34.2 kam die error Meldung in Yast2
Fehler beim Ausführen des Befehls "[["/usr/bin/grub2-editenv", "list"]]".
Abbruch-Code: 1
Fehlerausgabe: /usr/bin/grub2-editenv: Fehler: ../grub-core/fs/minix.c:578:Ist kein Verzeichnis.
Die grub.cfg war wieder unvollständig und das Betriebssystem wurde nur im emergency mode gebootet.
Danach habe ich die Grundinstallation ohne online Repositories wieder durchgeführt. Nach Aktivierung und Aktualisierung der opensuse Repositories habe ich die grub2 Pakete in der Version 2.06-150500.29.31.1 installiert und gelockt. Danach konnte ich problemlos den Kernel und alle anderen Pakete aktualisieren.
In den Sourcecodes von grub2-2.06-150500.29.334.2 und grub2-2.06-150500.29.34.2 habe ich nur den patch 0001-tpm-Skip-loopback-image-measurement.patch als Unterschied zwischen den beiden Versionen gefunden.
Dieser patch soll ein Überlaufen des memory beim loopback image verhindern.
Kann es sein, dass dieser patch den error bei grub2 in einer Installation ohne efi verursacht?
Bei UEFI-Installationen mit efi-Partition ist der error bei grub2 in der Version 2.06-150500.19.34.2 weder auf den Notebooks noch auf einer externen Festplatte aufgetaucht und alle Aktualisierungen der kernels liefen problemlos mit anschließenden Bootvorgängen.
Sorry, dass mir heute morgen die Antwort leider sehr verrutscht ist. Ich war aus privaten Gründen nicht ganz bei der Sache.
Der Pfad bei der Fehlermeldung kommt von der internen Festplatte und der externen Festplatte. Der Fehler ist erst nach dem 8 Oktober aufgetaucht. Am 8 Oktober habe ich
kernel-default-6.11.1-lp155.4.1.gaf74485.x86_64
kernel-default-devel-6.11.1-lp155.4.1.gaf74485.x86_64
kernel-syms-6.11.1-lp155.4.1.gaf74485.x86_64
kernel-devel-6.11.1-lp155.4.1.gaf74485.noarch
kernel-firmware-20241001-lp155.2.1.noarch
kernel-macros-6.11.1-lp155.4.1.gaf74485.noarch
kernel-source-6.11.1-lp155.4.1.gaf74485.noarch
dwarves-1.27-lp155.4.1.x86_64
dwarves-devel-1.27-lp155.4.1.x86_64
dwarves-devel-1.27-lp155.4.1.x86_64
von http://download.opensuse.org/r…stable:/Backport/standard und
mplayer vom packman Repository installiert.
Nach dieser Installation erschien noch keine Fehlermeldung. Der Fehler kam erst am 16. Oktober als ich in Yast das Bootloadermodul geöffnet habe.
Im BIOS habe ich seit langer Zeit (mehr als 3 Jahre) nichts geändert.
Mich irritiert, dass auf opensuse Leap 15.4 kein Fehler bei grub2 erscheint, jedoch auf der externen SSD nach einer reinen Grundinstallation mit Update ausschließlich von den offiziellen Repositories von opensuse.
Anbei das Output von grub2-probe auf der internen Festplatte im Anhang als Text-Datei
und das output von grub2-probe auf opensuse leap 15.4 im Anhang.
Opensuse Leap 15.4 ist ohne efi mit swap, btrfs und ext4 Partition installiert und ich konnte stets ohne grub2 error grub2 und kernel updaten.
Folgende Test habe ich noch durchgeführt:
Im Bios habe ich die Einstellungen im Boot Menu geändert
Launch CSM enabled
Boot Device Control UEFI and Legacy OPROM
Boot from Network Device Legacy only
Boot from Storage Device Legacy only
Boot from PCI-E/PCI Expansion Device Legacy only
Danach habe ich eine Grundinstallation ohne online Repositories über DVD auf einer externen SSD durchgeführt und anschließend ein Update ausgeführt. Die Partitionen habe ich bei der Grundinstallation gelöscht und die swap Partition, btrfs Partition für das Betriebssystem und die ext4 Partition für home neu angelegt.
Grub2 meldet nach dem Update wieder denselben Fehler in Yast2.
Fehler beim Ausführen des Befehls "[["/usr/bin/grub2-editenv", "list"]]".
Abbruch-Code: 1
Fehlerausgabe: /usr/bin/grub2-editenv: Fehler: ../grub-core/fs/minix.c:578:Ist kein Verzeichnis.
Auch bei anderen Einstellungen im Boot Menu von Bios
Boot Device Control Legacy OPROM
Boot from Network Device Legacy only
Boot from Storage Device Legacy only
Boot from PCI-E/PCI Expansion Device Legacy only
und
Boot Device Control UEFI and Legacy OPROM
Boot from Network Device Legacy only
Boot from Storage Device UEFI only
Boot from PCI-E/PCI Expansion Device Legacy only
konnte der Fehler reproduziert werden.
Was die Ursache für diesen Fehler ist, ist mir bislang unklar.
Nur eine UEFI Installation auf einer externen SSD lief vollständig fehlerfrei.
nein,
im Bios ist seit Anfang Folgendes eingestellt:
Launch CSM enabled
Boot Device Control UEFI and Legacy OPROM
Boot from Network Device UEFI only
Boot from Storage Device UEFI only
Boot from PCI-E/PCI Expansion Device UEFI only
Bei anderen Einstellungen wurden die Betriebssysteme nicht mehr gebootet und ich konnte stets von DVD ohne UEFI installieren und Alles updaten.
Hallo,
nachdem die grub2-Version von 2.31 auf 2.34 nur noch mit dem Fehler grub2 error: ../grub-core/fs/minix.c:578:not a directory installiert werden konnte und die grub.cfg falsch generiert wurde, habe ich auf einer externen SSD mehrere Grundinstallationen von opensuse Leap15.5 durchgeführt.
Nach einer Grundinstallation mit anschließendem Update über eine DVD wurde der gleiche Fehler erzeugt. Ebenso wenn die Grundinstallation über einen USB-Stick ohne efi durchgeführt wurde.
Erst nach einer UEFI-Installation über einen USB-Stick war eine Update von grub2 von Version 2.31 auf 2.34 problemlos ohne Grub2 error möglich. EineUpdate des Kernels konnte auch fehlerfrei installiert werden.
Allerdings ist es mir ein Rätsel, warum nur ein UEFI Installation mit Updates fehlerfrei läuft.
Da System des Rechners:
Der Rechner hat eine Mainboard ASUS Prime Z 390-A, Intel Core i9-9900kf, 2x 16 GB Kingston Hyperx 3200 MT7S Memory. 2 Samsung SATA-SSD 1 TB, 1 Crucial SATA-SSD und eine Samsung NVME 860 EVO 2 TB. An den Bioseinstellungen habe ich seit 3 Jahren nichts geändert.
Die Installationen von opensuse Leap 15.2, 15.3, 15.4 und 15.5 liefen bis zum 8. Oktober über DVD ohne efi-Installation mit allen Updates völlig problemlos. Auch als Test auf externen Festplatten.
Warum dies jetzt anders ist und für grub2 anscheinend eine efi-Partition zwingend ist, weiß ich nicht.
Daher werde ich künftig auf UEFI-Installationen wechseln, damit die Systeme problemlos geupdatet werden können.
Was ist mit den PARTTYPE und PARTUUID von sda und nvem0n1? Da ich auf der Festplatte nvem0n1 bin der code von fstab der sda über ein mount zu sda3.
cat /run/media/root/3d5f2996-f23a-41c4-a322-ef572eee143c/etc/fstab
UUID=3d5f2996-f23a-41c4-a322-ef572eee143c / btrfs defaults 0 0
UUID=3d5f2996-f23a-41c4-a322-ef572eee143c /var btrfs subvol=/@/var 0 0
UUID=3d5f2996-f23a-41c4-a322-ef572eee143c /usr/local btrfs subvol=/@/usr/local 0 0
UUID=3d5f2996-f23a-41c4-a322-ef572eee143c /tmp btrfs subvol=/@/tmp 0 0
UUID=3d5f2996-f23a-41c4-a322-ef572eee143c /srv btrfs subvol=/@/srv 0 0
UUID=3d5f2996-f23a-41c4-a322-ef572eee143c /root btrfs subvol=/@/root 0 0
UUID=3d5f2996-f23a-41c4-a322-ef572eee143c /opt btrfs subvol=/@/opt 0 0
UUID=392ca1b0-922c-4c8a-9e31-7b595ea42a1b /home ext4 data=ordered 0 2
UUID=3d5f2996-f23a-41c4-a322-ef572eee143c /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
UUID=3d5f2996-f23a-41c4-a322-ef572eee143c /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
UUID=b87c6704-6848-448d-8efe-f89e5f1d1ffd swap swap defaults 0 0
Alles anzeigen