openSUSE Slowroll - erste Schritte

[sedot]

Du überstehst, dass die ISO in sich der zur Zeit der Erstellung aktuelle Stand ist: Zumindest wenn man es offline installiert, ist es in sich konsistent.

Nein, übersehe ich nicht, trotzdem kann es Änderungen jedweder Art geben mit möglichen Folgen. Oder eben auch nicht. Wie du damit umgehen möchtest kannst du selbst entscheiden.

Ich werde niemals irgendjemanden Snapshots und diesen bekloppten @-Kram einrichten, oder auch nur beschreiben wie man das macht! - NIEMALS!

Ich verstehe deinen emotionalen Ausbruch bei dem Thema nicht. Mach wie du denkst. Für andere die Snapshots nicht mit Backups verwechseln ist es eine gute Option. Findet sich so auch bei anderen Distributionen, sogar mit automatischem Rollback auf den zuletzt funktionierenden Zustand falls es Upgrade Probleme gab. 🤷‍♀️

Mehr habe ich nicht geändert.

Interessant, jetzt frage ich mich warum dein Xfce mehr Platz auf der Festplatte braucht als meines (mit Slowroll). Hast du so Zeug wie LibreOffice dabei?

 

[Caramon2]

Nein, übersehe ich nicht, trotzdem kann es Änderungen jedweder Art geben mit möglichen Folgen. Oder eben auch nicht. Wie du damit umgehen möchtest kannst du selbst entscheiden.

Diese Änderungen gibt es aber auch, wenn ich es jetzt installiere und regelmäßig aktualisiere.

Genau darum geht es doch:

Installiere ich es jetzt vom Mai'25-ISO und halte es aktuell (ändere ansonsten aber nichts), habe ich z. B. in zwei Jahren einen bestimmen Stand.

Installiere ich es vom Mai'25-ISO dagegen erst in zwei Jahren und aktualisiere es, habe ich trotzdem den gleichen Stand.

Es gibt keine neue Version, auf die man upgraden muss.

Ich verstehe deinen emotionalen Ausbruch bei dem Thema nicht.

Emotional war das nicht (darüber rege ich mich schon lange nicht mehr auf). Ich wollte nur verdeutlichen, dass Snapshots und @-Kram für mich ein no go sind, weil das, wie schon oft geschrieben, falsche Sicherheit vermittelt und Fehler provoziert.

Mach wie du denkst. Für andere die Snapshots nicht mit Backups verwechseln ist es eine gute Option. Findet sich so auch bei anderen Distributionen, sogar mit automatischem Rollback auf den zuletzt funktionierenden Zustand falls es Upgrade Probleme gab. 🤷‍♀️

Nochmal: Damit ärgere ich mich nicht mehr herum. Wer es unbedingt nutzen will, soll selbst sehen wie er damit zurecht kommt. Mir ist das aus den genannten Gründen zu heikel.

Interessant, jetzt frage ich mich warum dein Xfce mehr Platz auf der Festplatte braucht als meines (mit Slowroll). Hast du so Zeug wie LibreOffice dabei?

Das war einfach die Standard-Installation, nur eben auf xfs und ohne Swap.

Was dort installiert wird, habe ich nicht kontrolliert. Mir ging es nur um die Dauer und wie viel anschließend belegt ist. Dann habe ich die zRAM-Disk löschen lassen (s. Skript in #31):

[…]
echo -e "\nDie zRAM-Disk wird gelöscht:\n"
sudo umount -l /tmp/zram$id/ && rm -vrf /tmp/zram$id
echo $id|sudo tee /sys/class/zram-control/hot_remove > /dev/null

Ergänzung (Dienstag um 11:29)

Findet sich so auch bei anderen Distributionen, sogar mit automatischem Rollback auf den zuletzt funktionierenden Zustand falls es Upgrade Probleme gab. 🤷‍♀️

Aber was ist, wenn dieses automatische Rollback oder Tools wie Snapper mal nicht funktionieren? - Weißt du, wie man dann manuell zum vorherigen Snapshot zurück kommt?

Und wie erklärst du das einem Fremden, der vielleicht mehrere hundert km von dir entfernt wohnt und sich "unter der Haube" nicht auskennt (und auch nicht auskennen will), der es nach deiner Anleitung installiert hast und dem das passiert?

Edit: Ich meine das für den Fall, dass das System nicht mehr bootet und man es von "außen" (einem gebooteten Livesystem) aus machen muss.

Meine mit rsync gemachten Sicherungen spielt man dann einfach wieder zurück:

sudo rsync -vaxH --del [Quelle] [Ziel]

Das bekommt jeder hin, der Anweisungen sinngemäß umsetzten und Copy&Paste kann.

 

[sedot]

Es gibt keine neue Version, auf die man upgraden muss.

Ja. Es gibt keine neue Version (auf deinem PC) auf die du upgraden mußt. Genau. Kannst alles so lassen. Bei einem Upgrade in der Zukunft kann es dann womöglich zu Problemen kommen, oder auch nicht. Je nach dem ob es grundlegende Veränderungen gab.
Ich glaube wir missverstehen uns grundlegend bei dem Thema. Seis drum, ich würde den Ausflug jetzt nicht weiter diskutieren wollen.

Das war einfach die Standard-Installation, nur eben auf xfs und ohne Swap.

Dann war es keine Standard-Installation. 😅
Aber gut, die Software-Auswahl hast du nicht verändert, nun kann ich nachvollziehen was vermutlich alles Teil der Installation war.

Weißt du, wie man dann manuell zum vorherigen Snapshot zurück kommt?

Ja, in etwa, vorausgesetzt GRUB ist installiert. Dort im entsprechenden Menü den zuletzt funktionierenden Snapshot (nach Datum sortiert) booten, Terminal öffen, snapper rollback eintippen, enter, reboot, OS wie gewohnt starten. Andere Wege müsste ich jetzt nachschlagen.

Disclaimer; es kann sein, dass mein Wissenstand veraltet ist, da ich bisher snapper noch nicht nutzen musste und nur virtuell herumgetestet hatte in der Vergangenheit.
Konsultiere bitte die (SUSE) Dokumentation für Details und/oder hol dir noch eine Bestätigung anderswo, Kanäle mit kompetenten Menschen gibt es einige.

Und wie erklärst du das einem Fremden, der vielleicht mehrere hundert km von dir entfernt wohnt und sich "unter der Haube" nicht auskennt (und auch nicht auskennen will), der es nach deiner Anleitung installiert hast und dem das passiert?

Ganz grundlegend – im Freundeskreis, Familie oder Bekannten empfehle ich kein Linux wenn ich weiß das Willen zu Selbsthilfe nicht möglich ist. Den Rattenschwanz „Spontan-Support“ binde ich mir nicht (mehr) freiwillig ans Bein. Gibt schöneres und auch (kommerzielle) Anbieter die genau das Spektrum abdecken.

Da ich weiß wie (zeitlich) umfangreich es ist gute Dokumentation zu schreiben, bin ich sehr zurückhaltend diesbezüglich. Eher ergänze ich Dinge in z.B. bestehenden Wikis etc. oder gebe eben erfahrungsbasierte Hinweise in Social Media wie hier.

Eine vollständige gute allgemein verständliche Anleitung in leichter Sprache für die Installation eines beliebigen Betriebssystem schreiben kann (und will) ich allein nicht leisten. Hut ab vor denjenigen die sich das zur Aufgabe machen.

edit
die einzelnen Schritte zum rollback als Bild, aktuelles Slowroll. Einen hatte ich vergessen.

Danach wie geschrieben – Terminalsession in der Desktop-Umgebung öffnen, sudo snapper rollback eintippen, nach Beendigung des Befehls sudo reboot now oder eben via GUI neustarten, Slowroll wie gewohnt starten. Fertig.

 

[Caramon2]

vorab: Ich habe das Skript in #31 für Linux-only geändert, da es bzgl. Hardware-Kompatibilität mit Win11 sowieso nicht funktionieren würde und das VirtIO-Treiberdisketten-Image ja auch niemand sonst hat. - Weitere Infos dazu hier.

@sedot: Du hast es dir etwas zu einfach gemacht.

Die Vorgaben waren:

• wenn dieses automatische Rollback oder Tools wie Snapper mal nicht funktionieren
• dass das System nicht mehr bootet
• man es von "außen" (einem gebooteten Livesystem) aus machen muss

Ohne diesen @-Kram und Snapshots ist das trivial:

1. Irgendein halbwegs aktuelles Linux-Livesystem booten (egal von welcher Distribution)
2. Terminal öffnen und dort sudo rsync -vaxH --del einfügen (wichtig ist das Leerzeichen am Ende)
3. das Backuplaufwerk öffnen, ins Verzeichnis mit der letzen Sicherung wechseln und den Pfad aus der Adresszeile hinter den Befehl kopieren + ein Leerzeichen
4. die Zielpartition öffnen und auch den Pfad hinter die Befehlzeile kopieren + [Enter]
5. dann die ca. 20-30 Sek. warten (bei SSDs), bis es durchgelaufen ist und fertig.

Bei einem ehem. Arbeitskollegen habe ich auch dafür ein Skript geschrieben, das vom Sicherungsskript zum jeweiligen Backup kopiert wird.

Wenn er eine Sicherung wiederherstellen will, bootet er das Livesystem, öffnet die Zielpartitionen (System und Home) und das Backuplaufwerk und startet das Wiederherstellungsskript aus dem Verzeichnis der Sicherung, die er wiederherstellen möchte. Das läuft durch und fertig.

Übrigens musste ich an den Skripten nichts ändern, nachdem ich ihn von LinuxMint-Xfce auf Solus-Budgie umgestellt hatte: Die Pfade für die Sicherung des laufenden Systems waren relativ (also egal ob ext. Laufwerke in /media]… oder in /run/… eingehängt wurde) und für die Wiederherstellung hat er das LinuxMint-Livesystem weiter genutzt (also /media/mint/…). - Die Linux-Partiton hieß weiterhin "Linux", die Home-Partition "Home" und seinen Benutzernamen hat er auch behalten.

…

Bzgl. der bei Xfce standardmäßig installierten Software habe ich die ersten drei Bildschirmseiten nach Größe sortierten angehängt (das ist noch der Installer - ich habe es nicht etwas dafür installiert): Ich lasse auch die nicht ausgewählten Pakete anzeigen, damit man sieht was weggelassen wird.

 

[sedot]

Du hast es dir etwas zu einfach gemacht.

Warum auch nicht. Zum Rest, bitte lies die Dokumentation und du wirst verstehen wie Snapper funktioniert und wo die Grenzen sind.

Das läuft durch und fertig.

Wäre ich zu ungeduldig für, ganz ehrlich.

Bzgl. der bei Xfce standardmäßig installierten Software habe ich die ersten drei Bildschirmseiten nach Größe sortierten angehängt

Du kannst auch mit zypper search pattern quick and dirty vorhandene Schemata (verfügbare und installierte) nach der Installation via Terminal ausgeben lassen. Die installierten sind mit i bzw. mit i+ gekennzeichnet in der tabellarischen Übersicht. Ist imo übersichtlicher als YaST und lässt sich einfacher darstellen bzw. teilen.
Das auf den Bildern kann ich nicht so richtig zuordnen, scheint nur ein Teil von irgendwas zu sein. Spekulieren würde ich Richtung patterns-xfce-xfce_basis, da libreoffice nicht vorausgewählt ist, andererseits sehe ich keine xfce Komponente und kein yast spontan. 🤷‍♀️
Vermutet hätte ich beim Installer patterns-xfce bzw. eben auch die in der .spec file gelistete Software. Naja, ist auch nicht sooo wichtig.

 

[Caramon2]

Ich habe es jetzt auf mein SoS (siehe hier) installiert und dabei auf Firefox und anderes größeres verzichtet):

Da LMDE den Bootloader stellt, musste ich dort Grub aktualisieren (bei openSUSE hatte ich bei der Installation deaktiviert, dass Grub auf andere OS prüft, da das ja unnötig wäre):

So sieht das Bootmenü jetzt aus:

Dann habe ich erst mal ein Sicherungsskript dafür erstellt (einfach das für LMDE kopiert, "LMDE_" durch "openSUSE_" ersetzt und --link-dest=../Artix_{0,1}/ hinzugefügt - vielleicht gibt es ja identisches):

#!/bin/bash
zs=4 # Zahl der Sicherungsstufen
if [ ! -d Sicherungen ];then mkdir Sicherungen || exit;fi
cd Sicherungen/
espeak-ng -vde -a50 "Bitte Passwort." & sudo sync -f .
mv openSUSE_$zs openSUSE_bak 2>/dev/null
for ((z=$zs;z>=0;z--));do mv openSUSE_$z openSUSE_$((z+1)) 2>/dev/null;done
if [ ! -d openSUSE_bak ];then mkdir openSUSE_0;else mv openSUSE_bak openSUSE_0;fi
echo
time sudo rsync -vaxH --del --link-dest=../openSUSE_1/ --link-dest=../Artix_{0,1}/ --exclude '.cache/*' --exclude '/tmp/*' --exclude '/var/tmp/*' --exclude '/var/log/*' --exclude '*.log' --exclude '*.old' --exclude '*_old' ../../openSUSE/ openSUSE_0/
sudo touch openSUSE_0
espeak-ng -vde -a50 "Datensicherung abgeschlossen." & read -p [Enter]

und eine Sicherung durchgeführt, falls bei der Aktualisierungen etwas schief läuft):

sent 3.748.512.941 bytes  received 1.890.912 bytes  78.955.870,59 bytes/sec
total size is 4.552.603.962  speedup is 1,21

real    0m47,571s
user    0m0,520s
sys    0m2,062s

Es konnten von Artix sogar 21% als Hardlinks übernommen werden! - Ich wäre schon überrascht gewesen, wenn es nur 3-5% gewesen wären!

Wichtig: 47,5 Sekunden für eine vollständige, richtige Sicherung auf einen anderen Datenträger!

Dann habe ich es gebootet und aktualisiert (der Einfachheit halber in einer VM - aber ich kann es natürlich auch direkt mit dem PC booten, wie auch alle anderen Installationen auf der SSD) und dazu das Terminal mit F11 auf Vollbild gestellt:

Ab hier nur noch die VM:

Das mit zypper ps -s musste ich natürlich ausprobieren:

Also nochmal mit sudo , wofür ich dann eine höhere Auflösung brauchte:

Dann musste ich wieder das LMDE-Grub aktualisieren, damit der neue Kernel dort aufgenommen wird:

Wobei ich mich frage ob open SUS ältere Kernel irgendwann automatisch entfernt, oder das mit der Zeit immer mehr werden, solange man nicht selbst ausmistet.

Anschließend wieder gesichert, wobei diesmal natürlich sehr viel von der vorherigen Sicherung übernommen werden konnte und es nur noch 17,4 Sek. gedauert hat:

sent 719.668.248 bytes  received 202.445 bytes  38.911.929,35 bytes/sec
total size is 5.007.581.179  speedup is 6,96

real    0m17,369s
user    0m0,077s
sys    0m0,274s

Wichtig: Das ist wieder eine für sich alleine vollständige Sicherung. - Nichts mit inkrementelle, oder so.

Ergänzung (Dienstag um 22:53)

der Einfachheit halber in einer VM - aber ich kann es natürlich auch direkt mit dem PC booten, wie auch alle anderen Installationen auf der SSD

Oder auch nicht: Es bleibt sofort mit schwarzem Schirm und oben links blinkenden Cusor hängen. - Keine Meldung, kein gar nichts.

Das ist die erste Linux-Distribution, mit der das nicht auf Anhieb funktioniert. - Sogar Windows 10 und 11 haben damit keine Probleme!

Aber darum kümmere ich mich heute nicht mehr: Ich habe seit dem Frühstück noch nichts gegessen und langsam wirklich hunger…

 

[Caramon2]

Das Problem ist erkannt:

Wenn ich es im Recovery-Modus boote, bleibt es nach der USB-Erkennung hängen, aber als ich etwas länger gewartet habe, lief nach 2 Minuten ein dracut timeout script ca. eine Minute immer wieder durch und endete so:

Dass er die UUID nicht findet, obwohl es die richtige ist:

kenne ich schon von Arch (so viel zu "Das ist die erste Linux-Distribution, mit der das nicht auf Anhieb funktioniert" ):

Das kann ich dann im Fallback-Modus booten (den es bei openSUSE leider nicht gibt) und es liegt daran, dass es im normalen initramfs nur das SATA-Blockgerät (weil ich es eben in der VM auf virtuellem SATA installiert habe) aufgenommen hat. Aber eben kein USB, so dass es die ext. SSD beim direkten booten nicht erkennen kann.

Im Fallback-initramfs stecken dagegen (u. a.) alle Blockgeräte-Treiber, so dass die USB-SSD erkannt und die UUID gefunden werden kann.

Gelöst habe ich das, indem ich einfach in der /etc/mkinitcpio.conf "block" vor "autodetect" gesetzt habe:

HOOKS=(base udev block autodetect keyboard keymap)

so dass auch ins normale initramfs alle Blockgeräte-Treiber aufgenommen werden.

Meine Frage ist also: Wie macht man das bei dracut?

Eine /etc/dracut.conf gibt es zwar, die ist aber wenig hilfreich (auch in /etc/dracut.conf.d/ war nichts hilfreiches):

# PUT YOUR CONFIG IN separate files
# in /etc/dracut.conf.d named "<name>.conf"
# SEE man dracut.conf(5) for options

In der Manpage gibt es weder "block" noch "usb" und in /usr/lib/dracut/modules.d/ wo die hinzuzufügenden Module sind, wird nichts zu "usb" gefunden und in 95rootfs-block/ gibt es nur fünf Skripte, die ich nicht verstehe: s. angehängtes Archiv

Zum Vergleich: Die Standard-mkinitcpio.conf bei meinem Arch-Derivat ist gut dokumentiert:

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES=(usbhid xhci_hcd)
MODULES=()

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=()

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=()

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
##   This setup specifies all modules in the MODULES setting above.
##   No RAID, lvm2, or encrypted root is needed.
#    HOOKS=(base)
#
##   This setup will autodetect all modules for your system and should
##   work as a sane default
#    HOOKS=(base udev autodetect modconf block filesystems fsck)
#
##   This setup will generate a 'full' image which supports most systems.
##   No autodetection is done.
#    HOOKS=(base udev modconf block filesystems fsck)
#
##   This setup assembles a mdadm array with an encrypted root file system.
##   Note: See 'mkinitcpio -H mdadm_udev' for more information on RAID devices.
#    HOOKS=(base udev modconf keyboard keymap consolefont block mdadm_udev encrypt filesystems fsck)
#
##   This setup loads an lvm2 volume group.
#    HOOKS=(base udev modconf block lvm2 filesystems fsck)
#
##   This will create a systemd based initramfs which loads an encrypted root filesystem.
#    HOOKS=(base systemd autodetect modconf kms keyboard sd-vconsole sd-encrypt block filesystems fsck)
#
##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr and fsck hooks.
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block filesystems fsck)

# COMPRESSION
# Use this to compress the initramfs image. By default, zstd compression
# is used for Linux ≥ 5.9 and gzip compression is used for Linux < 5.9.
# Use 'cat' to create an uncompressed image.
#COMPRESSION="zstd"
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"

# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()

# MODULES_DECOMPRESS
# Decompress loadable kernel modules and their firmware during initramfs
# creation. Switch (yes/no).
# Enable to allow further decreasing image size when using high compression
# (e.g. xz -9e or zstd --long --ultra -22) at the expense of increased RAM usage
# at early boot.
# Note that any compressed files will be placed in the uncompressed early CPIO
# to avoid double compression.
#MODULES_DECOMPRESS="no"

 

[Caramon2]

Daran müsste es eigentlich liegen (aus der dracut-Manpage):

If you want to create lighter, smaller initramfs images, you may want to specify the --hostonly or -H option. Using this option, the resulting image will contain only those dracut modules, kernel modules and filesystems, which are needed to boot this specific machine.
This has the drawback, that you can’t put the disk on another controller or machine, and that you can’t switch to another root filesystem, without recreating the initramfs image. The usage of the --hostonly option is only for experts and you will have to keep the broken pieces.

Trotzdem nutzt openSUSE das standardmäßig und das sogar ohne die empfohlene Fallback-Möglichkeit:

At least keep a copy of a general purpose image (and corresponding kernel) as a fallback to rescue your system.

Aber selbst wenn ich eine /etc/dracut.conf.d/50-generic.conf erstelle (aus der offizellen Dokumentation):

# generic
hostonly="no"
hostonly_cmdline="no"

wird das /boot/initrd-6.14.4-1.0.6.sr20250402-default zwar mehr als doppelt so groß, aber es bootet trotzdem nicht. - Mit dem Unterschied, dass nach 2 Min. nicht mal mehr Fehlermeldungen erscheinen: Der Bootvorgang bleibt einfach hängen und auch nach einer 1/4h passierte nichts.

openSUSE hat meine ursprüngliche Meinung also doch bestätigt. - Schade dass ich fast meinen halben monatlichen Traffic dafür geopfert habe.

Wenn das einem schon bei sowas grundsätzlichen solche Stöcke zwischen die Beine wirft, wie soll das erst werden, wenn man es ernsthaft nutzen möchte?

Wer es nur auf seinem PC einsetzt, mag damit zufrieden sein, aber man sollte bedenken: Sobald man gravierendes an der Hardware ändert (neues Board, von SATA auf NVMe, evtl. auch eine neue GraKa, oder etwas in der Art), hat man offenbar verloren und "darf" es neu installieren.

Ich habe übrigens ein reines, alles andere als nagelneues AMD-System (CPU, GraKa und Board): Von Linux wird es vollständig unterstützt und brauche keine proprietären Treiber! Gleiches gilt für die VM, so dass es z. B. keinen nVidia-Treiber gibt, der vielleicht dazwischengefunkt hat.

Damit ist das hier für mich erledigt und aus der geplanten Anleitung wird nichts: Unter diesen Umständen hätte ich das Gefühl, andere ins offene Messer laufen zu lassen. Das will ich nicht verantworten.

 

[sedot]

Der dracut-initqueue 403 Fehler kann mehrere Gründe haben, wie ich gelesen habe, unabhängig von der Distribution. Falls du auf Fehlersuche gehen möchtest, die Links finde ich vielleicht wieder. Erinnern kann ich mich an, PARTUUID anstatt UUID, längeres Zeitfenster für dracut damit es nicht zum timeout kommt, Kernelparameter die ich mir nicht gemerkt habe. Quelle war red hat Doku und gentoo Forum.

Daran haben meinem Eindruck nach schon einige geknabbert in ähnlichen Szenarien. Da ich mich selbst mit dracut nicht so auskenne (und dein SoS nicht eben leicht verständlich ist) würde ich testen müssen was funktioniert, unter der Vorraussetzung ich kann den Fehler nachstellen.
Gut möglich, dass du im openSUSE Forum schneller zum Ziel kommst.

Wer es nur auf seinem PC einsetzt, mag damit zufrieden sein, aber man sollte bedenken: Sobald man gravierendes an der Hardware ändert (neues Board, von SATA auf NVMe, evtl. auch eine neue GraKa, oder etwas in der Art), hat man offenbar verloren und "darf" es neu installieren.

Ich weiß nicht wie es mit dem experimentellen Slowroll ist, bei meiner Tumbleweed Installation habe ich schon Hardware getauscht ohne Neuinstallation. Gut, zugegeben, ist auch ganz schnöde nah der best practice installiert.

 

[Caramon2]

Falls du auf Fehlersuche gehen möchtest, die Links finde ich vielleicht wieder. Erinnern kann ich mich an, PARTUUID anstatt UUID, längeres Zeitfenster für dracut damit es nicht zum timeout kommt, Kernelparameter die ich mir nicht gemerkt habe. Quelle war red hat Doku und gentoo Forum.

Ich hatte zuerst überlegt es noch etwas zu behalten, falls sich noch eine Lösungsmöglichkeit ergibt, aber es dann als Zeitverschwendung eingestuft, da das Flickschusterei wäre und selbst wenn bei meinen System funktioniert, es nicht sicher ist, ob es nach bestimmten Updates nicht wieder passiert, oder ob der Worksround bei anderen überhaupt funktioniert.

Also habe ich openSUSE komplett entfernt: Installation, Sicherungen und ISO. - Einzig die UEFI-Windows-Installation, an der ich beschreiben wollte (genauer als beim Schnellschuss neulich) wie man es parallel dazu installiert, habe ich behalten, da ich das auch gut für LMDE nutzen kann.

Daran haben meinem Eindruck nach schon einige geknabbert in ähnlichen Szenarien. Da ich mich selbst mit dracut nicht so auskenne (und dein SoS nicht eben leicht verständlich ist) würde ich testen müssen was funktioniert, unter der Vorraussetzung ich kann den Fehler nachstellen.

Da die Konfigurationsdatei bei Artix (dem von mir seit Anf. 2020 als Produktivsystem genutzt Arch-Derivat) sehr gut dokumentiert war, hatte ich die Idee mir dessen dracut-Paket zu laden und dort reinzusehen (geht mit einer normalen Archivverwaltung - ich habe Zarchiver auf dem Handy genutzt, da der PC aus war/ist): https://archive.artixlinux.org/packages/d/dracut/dracut-106-1-x86_64.pkg.tar.zst

Dort gibt es u. a. die usr/lib/dracut/dracut.conf.d/suse.conf.example und in der steht, dass SUSE generell das initrd möglichst klein halten will. Daher hatte ich die beiden hostonly-Einträge:

# SUSE specific dracut settings
#
# SUSE by default always builds as small as possible initrd for performance
# and resource reasons.
# If you like to build a generic initrd which works on other platforms than
# on the one dracut got called comment out below setting(s).
hostonly="yes"
hostonly_cmdline="yes"

compress="zstd -3 -T0 -q"

i18n_vars="/etc/sysconfig/language:RC_LANG-LANG,RC_LC_ALL-LC_ALL /etc/sysconfig/console:CONSOLE_UNICODEMAP-FONT_UNIMAP,CONSOLE_FONT-FONT,CONSOLE_SCREENMAP-FONT_MAP /etc/sysconfig/keyboard:KEYTABLE-KEYMAP"
omit_drivers+=" i2o_scsi "

Kompression und Lokalisierung hatte ich nicht übernommen.

…

Mein SoS ist eigentlich sogar ziemlich einfach aufgebaut:

Zuerst habe ich die SSD partitionieren: MBR *), 50 GB ntfs, Rest f2fs, damit der Windows-Installer nicht auf die Idee kommt, weitere Partitionen zu erstellen.

Dann habe ich Windows 11 auf die ntfs-Partition installiert

Anschließend habe ich die f2fs-Partition gelöscht und nach Bedarf mehrere Linux-Distributionen dort so installiert, das letztendlich das Grub von LMDE im MBR ist und darüber alle Installationen gebootet werden.

Mit dem Bootproblem von openSUSE hat das aber nichts zu tun. Das liegt am vermeintlichen Hardware-Wechsel von in der VM auf direkt mit dem selben PC booten.

*) da Windows im UEFI-Modus nicht von USB bootet und das auch bei Linux von USB immer wieder Probleme macht und repariert werden muss, verzichte ich aus UEFI wo immer es geht

Ich weiß nicht wie es mit dem experimentellen Slowroll ist, bei meiner Tumbleweed Installation habe ich schon Hardware getauscht ohne Neuinstallation. Gut, zugegeben, ist auch ganz schnöde nah der best practice installiert.

So wie die es beschreiben, ist es ein Tumblweed und das einzige experimentelle daran sind die Slowroll-Quellen. Es heißt auch nicht "openSUSE Slowroll", sondern "openSUSE Tumbleweed Slowroll" - zumindest hat sich das installierte System immer so gemeldet.

Mit der Bootfähigkeit wird das nichts zu tun haben, da die sicherlich nicht für jede Ausgabe (Leap, Tumbleweed, usw.) das "Rad" neu erfinden. - Da wurde einfach nicht richtig nachgedacht und das initramfs zu sehr abgespeckt: Man hätte ja nur der Empfehlung der dracut-Manpage folgen brauchen (RTFM! ) und zusätzlich ein generisches als Fallback bereitstellen brauchen. - Deren abgespecktes ließ sich ja noch nicht mal im recovery-Modus booten: Wirklich effektiv…

Das hängt lt. Manpage davon ab, ob ein anderer Treiber benötigen wird: von SATA auf SATA ist kein Problem, da es keinen anderen Treiber im im initramfs benötigt, genauso wie von AMD auf AMD, usw.

Aber wenn du es z. B. intern auf eine SATA-SSD installiert hast und die dann ausbaust, um sie in einem USB-Gehäuse oder per SATA-USB-Adapter am selben PC zu booten (also es muss nicht mal eine VM involviert sein), hättest du das gleiche Problem.

…

Ich finde das wirklich schade, wo es doch so gut anfing: Ich war richtig begeistert von meinen erstens Eindrücken.

Da du sehr hilfsbereit warst und bist, habe ich dir gegenüber ein etwas schlechtes Gewissen, das jetzt einfach abzuwürgen. Aber wenn es schon so grundlegende Probleme gibt und offensichtliche Lösungen nicht helfen, kann es nur schlimmer werden: Mit sowas habe ich schon genug schlechte Erfahrungen.

Der Thread darf natürlich gerne weitergeführt werden:

Ich habe den Titel bewusst möglichst allgemeingültig gehalten und wenn man Distributionen nicht so flexibel einsetzen können möchten wie ich, mag es ja eine gute Wahl sein.

Ergänzung (Donnerstag um 12:14)

Aber eines war wirklich positiv:

Trotz aller meiner vergeblichen Reparaturversuche und dass mir bei mehreren Boot-Hängern nur noch Griff zum Hardreset blieb, ließ es sich immer problemlos weiterhin in der VM booten!

Also so gesehe ist sogar das "experimentelle" openSUSE Slowroll ein sehr solides System!

 

[sedot]

Also habe ich openSUSE komplett entfernt: Installation, Sicherungen und ISO.

Ah, rage quit, hatte ich auch schon in anderen Zusammenhängen. Kann ich nachvollziehen, passiert. 😄

Kompression und Lokalisierung hatte ich nicht übernommen.

Die Datei sieht bei Slowroll und Tumbleweed identisch aus, aus Interesse hab ich mal direkt bei dracut geschaut was die Historie so hergibt – compress="zstd -3 -T0 -q" ist eine SUSE spezifische Konfiguration seit 2022, Anpassungen gibt es seit 2010. Warum und wieso hab ich jetzt nicht weiterverfolgt, womöglich liegt hier das Problem. Kann ich nicht einschätzen, weil fehlender Sachverstand.

Fallback

Vielleicht verstehe ich dich hier falsch, unter Advanced Option for (…) (Grub) kommst du doch in den Recovery Modus für in deinem Fall Slowroll?

Aber wenn du es z. B. intern auf eine SATA-SSD installiert hast und die dann ausbaust, um sie in einem USB-Gehäuse oder per SATA-USB-Adapter am selben PC zu booten (also es muss nicht mal eine VM involviert sein), hättest du das gleiche Problem.

Kann ich leider nicht nachstellen, weil kein SATA-USB vorhanden ist. Aber ja, auch wenn ungewöhnliche Konstellation wäre die Funktion zumindest wünschenswert.

Da du sehr hilfsbereit warst und bist, habe ich dir gegenüber ein etwas schlechtes Gewissen, das jetzt einfach abzuwürgen.

Musst du nicht, manches klappt eben nicht wie geplant. So ist das Leben.

btw, so verbastelt wie meine Tumbleweed Installation inzwischen ist bin ich immer wieder überrascht, dass das OS problemfrei startet und augenscheinlich reibungsarm funktioniert. Eigentlich sollte es ja nur ein kurzes Experiment werden. 😅🫠

 

[Caramon2]

Ah, rage quit, hatte ich auch schon in anderen Zusammenhängen. Kann ich nachvollziehen, passiert. 😄

Eher Selbstschutz: Wenn es komplett weg ist, komme ich nicht mehr in Versuchung weitere Zeit damit zu verschwenden.

So weit, dass ich wirklich total die Schnauze voll davon habe, lasse ich es schon seit (wegen!) Vista nicht mehr kommen: Jeder, der sich sowas freiwillig installiert, gehört IMO erschlagen!
Mein Nachtrag Jahre später:

Boah, was hatte ich damals die Schnauze voll!
Mit "freiwillig" wollte ich übrigens die ausschließen, die Vista (z. B. wegen DirectX 10) nutzen mussten.

Das hat lesenswertes Feedback gegeben: s. obiger Link

Die Datei sieht bei Slowroll und Tumbleweed identisch aus, aus Interesse hab ich mal direkt bei dracut geschaut was die Historie so hergibt – compress="zstd -3 -T0 -q" ist eine SUSE spezifische Konfiguration seit 2022, Anpassungen gibt es seit 2010. Warum und wieso hab ich jetzt nicht weiterverfolgt, womöglich liegt hier das Problem. Kann ich nicht einschätzen, weil fehlender Sachverstand.

Das ist einfach: Die Parameter gehören zu zstd und das wird erst seit ~'22 vom Kernel unterstützt. Vorher wurde afaik xz genutzt.

-3 bedeutet Kompressionsstufe 3 (da sowieso der Standard, praktisch überflüssig), -T0 ist die Thread-Anzahl (0=autodetect) und -q steht für "Klappe halten!" , eine Ausgabe gibt es bei dracut aber auch nicht, wenn man es weglässt.

Ich bevorzuge bei Artix übrigens COMPRESSION_OPTIONS=(-12T0), also Stufe 12 mit autodetect, da das auch noch ziemlich schnell, aber deutlich besser komprimiert und dadurch bei jedem booten schneller geladen und entpackt wird.

Vielleicht verstehe ich dich hier falsch, unter Advanced Option for (…) (Grub) kommst du doch in den Recovery Modus für in deinem Fall Slowroll?

Ähh:

Wenn ich es im Recovery-Modus boote, bleibt es nach der USB-Erkennung hängen, aber als ich etwas länger gewartet habe, lief nach 2 Minuten ein dracut timeout script ca. eine Minute immer wieder durch und endete so

Deren abgespecktes ließ sich ja noch nicht mal im recovery-Modus booten

Brille: Fielmann.

Kann ich leider nicht nachstellen, weil kein SATA-USB vorhanden ist. Aber ja, auch wenn ungewöhnliche Konstellation wäre die Funktion zumindest wünschenswert.

So ungewöhnlich ist das gar nicht:

Als ich damals im Arch-Forum davon berichtet habe und dachte es wäre was ganz tolles BSe aus einer VM heraus zu installieren, kamen Antworten wie "So mache ich das auch immer.", oder "Es wäre ja auch Blödsinn extra dafür zu rebooten", usw. - War schon etwas enttäuschend…

btw, so verbastelt wie meine Tumbleweed Installation inzwischen ist bin ich immer wieder überrascht, dass das OS problemfrei startet und augenscheinlich reibungsarm funktioniert. Eigentlich sollte es ja nur ein kurzes Experiment werden. 😅🫠

So war es bei mir mit Artix:

Ich wollte es erstmal nur kennen lernen und habe wahllos alles ausprobiert, weil ich es sowieso nochmal in Ruhe installieren wollte, wenn ich weiß, was ich zu beachten habe, aber es ging und ging nicht kaputt, so dass ich die "saubere" Neuinstallation immer wieder vor mir her geschoben habe, weil der "Leidensdruck" fehlte, da selbst wenn ich es doch mal angegangen bin, die frische Installation nicht mal schneller als die "zugemüllte", so dass ich keine Lust mehr hatte weiterzumachen und bei der alten geblieben bin. - Erst nach 3 Jahren habe ich mich dann doch endlich dazu aufgerafft, aber wirklich nötig, oder dass ich gar einen spürbaren Vorteil davon hatte, war es nicht.

---

Das ISO auf dem Ventoy-Stick hatte ich beim "Kahlschlag" übersehen und es vorhin umgekehrt herum getestet:

Also openSUSE vom direkt mit dem PC (statt in der VM) gebooteten ISO auf eine leere, an SATA angeschlossene SSD mit den gleichen Einstellungen wie gestern installiert und das dann gebootet:

Direkt mit dem PC funktionierte diesmal natürlich, dafür (wie erwartet) mit der gleichen Fehlermeldung nicht in der VM:

Wieder weil das abgespeckte initramfs für die "neue" Hardware keinen passenden Treiber hatte, da die UUID natürlich richtig war:

Also wieder direkt mit dem PC von SATA gebootet und der Einfachheit halber die "no-hostonly"'s als Parameter übergeben (die initrd's zum Gröémvergleich):

-rw------- 1 root root 22M 15. Mai 11:53 /boot/initrd-6.14.4-1-default
sudo dracut --no-hostonly{,-cmdline} --force
-rw------- 1 root root 59M 15. Mai 12:23 /boot/initrd-6.14.4-1-default

Anschließend funktionierte der booten in der VM!

Dort habe ich dracut dann nochmal durchlaufen lassen, wobei das neue initrd nur knapp 167k größer wurde:

-rw------- 1 root root 61427199 15. Mai 12:23 /boot/initrd-6.14.4-1-default
sudo dracut --no-hostonly{,-cmdline} --force
-rw------- 1 root root 61442756 15. Mai 12:32 /boot/initrd-6.14.4-1-default

Dann habe ich versucht es wieder direkt mit dem PC zu booten, aber entgegen meiner Erwartung, hat auch das funktioniert!

Vielleicht weil die SSD immer noch an SATA angeschlossen war.

Also habe ich den PC kurz runter gefahren, die SSD ins USB-Gehäuse gepackt und dann versucht direkt davon zu booten, aber selbst das hat diesmal funktioniert!

Das könnte zwei mögliche Ursachen haben:

• da ich es direkt mit dem PC installiert hatte, kannte es schon alle Hardware (gestern nur die, die die VM hatte), was für mich am plausibelsten ist
• diesmal habe ich es nicht aktualisiert, da mir das nochmal ~400 MB Traffic nicht wert war: Es hat mich schon genug gekostet und dass fehlerbereinigte Versionen (es gab keine großen Versionssprünge) Fehler verursachen ist eher unwahrscheinlich.

Ganz koscher war das aber nicht mehr, da die Partitionen der beiden internen SSDs doppelt angezeigt wurden (auch nach einem reboot):

und wenn ich versuchte das "falsche" zu öffnen, gab es eine Fehlermeldung (die ntfs-Partition, weil fast leer und nichts wichtiges drauf ist):

In "Laufwerke" ist mir dann aufgefallen, dass sie nicht mehr als /dev/sdc usw. angezeigt wurden:

Und so sah das "unter der Haube" aus:

NAME                                  FSTYPE       FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                   mpath_member                                                                  
├─sda1                                btrfs              Artix  fb01a4fd-8f22-4481-aa43-bb6af7762cd9                
├─sda2                                xfs                Home   db0bf1df-6c20-4890-b3a3-6d31f3e52e11                
└─CT250MX500SSD1_1919E201E172                                                                                       
  ├─CT250MX500SSD1_1919E201E172-part1 btrfs              Artix  fb01a4fd-8f22-4481-aa43-bb6af7762cd9                
  └─CT250MX500SSD1_1919E201E172-part2 xfs                Home   db0bf1df-6c20-4890-b3a3-6d31f3e52e11                
sdb                                   mpath_member                                                                  
├─sdb1                                ntfs               DVB    B0484C93484C59EC                                    
├─sdb2                                btrfs              Backup b1c3b76f-9957-421d-8bf5-20e47f3f5970                
└─CT500MX500SSD1_2414E8A4A278                                                                                       
  ├─CT500MX500SSD1_2414E8A4A278-part1 ntfs               DVB    B0484C93484C59EC                                    
  └─CT500MX500SSD1_2414E8A4A278-part2 btrfs              Backup b1c3b76f-9957-421d-8bf5-20e47f3f5970                
sdc                                                                                                                 
├─sdc1                                xfs                Linux  e0d9f661-202d-4b0c-9033-6b812603fa06   11,7G    27% /
└─sdc2                                xfs                Home   fef9c329-d70f-4189-a0e0-f20b63cdf4dc   31,3G     2% /home

Nicht gerade vertrauenerweckend…

Also für meine Art, Betriebssysteme beliebig nutzen zu können, ist openSUSE offensichtlich nichts.

 

[Caramon2]

Hier schneidet Tumbleweed überraschend am schlechtesten ab und das kommende Debian 13 hat bei 116 Benchmarks mehr erste Plätze, als alle anderen getesten Distributionen zusammen:

Performance On Framework Laptop 13 With AMD Strix Point

Ich hätte eher das konservative Debian an letzter Stelle erwartet.

 

[sedot]

Eher Selbstschutz: Wenn es komplett weg ist, komme ich nicht mehr in Versuchung weitere Zeit damit zu verschwenden.

Auch nachvollziehbar. 😄

Vista hatte ich übersprungen tatsächlich, der IT-Freundeskreis hatte mich davor eindringlich genug gewarnt.

Brille: Fielmann.

Vielleicht bald – jetzt wo du mich darauf hinweist, ja, mein Fehler.

So ungewöhnlich ist das gar nicht: (…)

Ich formuliere mal um in „für mich ungewöhnlich“ – hast Recht.

Erst nach 3 Jahren habe ich mich dann doch endlich dazu aufgerafft, aber wirklich nötig, oder dass ich gar einen spürbaren Vorteil davon hatte, war es nicht.

Ist eben auch die Prognose für meine Installation, am Ende hab ich keinen wirklichen Mehrwert von Neuinstallation. Vielleicht im Herbst oder Winter bei großer Langeweile. 😅

Also habe ich den PC kurz runter gefahren, die SSD ins USB-Gehäuse gepackt und dann versucht direkt davon zu booten, aber selbst das hat diesmal funktioniert!

Tja, siehste mal.
Nein, ehrlich, ich hatte bzw. habe auch eine wilde Kuriosität mit vermutlich libimobiledevice bei der ich einfach aufgegeben habe. Manchmal klappt mounten sichtbar, manchmal nicht vollständig aber doch irgendwie, oder eben wie bei dir mehrere mountpoints sind in Thunar sichtbar aber nicht in anderen Dateimanagern oder einer anderen Desktop-Umgebung. Oder ganz anders. Und oder nach Reboot ist alles anders. Hängt vielleicht von der Innenraumtemperatur und den Lichtverhältnissen ab, möglicherweise auch Sonnenstand, oder so. Ich hab keine Ahnung. Technik ist manchmal seltsam.

Hier schneidet Tumbleweed überraschend am schlechtesten ab und das kommende Debian 13 hat bei 116 Benchmarks mehr erste Plätze, als alle anderen getesten Distributionen zusammen:

Ich weiß ehrlich nicht was da genau getestet wird und was mir das Ergebnis bringt. Da das so ist bin ich offensichtlich nicht die Zielgruppe die sich über einen spontanen Wechsel zu Debian Gedanken machen muss. :^)

 

[Caramon2]

Manchmal klappt mounten sichtbar, manchmal nicht vollständig aber doch irgendwie, oder eben wie bei dir mehrere mountpoints sind in Thunar sichtbar aber nicht in anderen Dateimanagern oder einer anderen Desktop-Umgebung.

Was gibt bei dir sudo lsblk -f aus? - Das Terminalfenster vorher deutlich breiter ziehen, damit die Ausgabe nicht gekappt wird.

Tipp: Da die Standard 80 Zeichen Breite fast immer zu klein ist, setze ich in Einstellungen immer 144x24 Zeichen: 12*12 x 12+12 (ich mag Zahlenspielereien )

Ich weiß ehrlich nicht was da genau getestet wird und was mir das Ergebnis bringt.

Dto.

Das einzige rechenaufwändige, das mich interessieren, ist Videoencoding als x264-Vorbis-mkv mit AVIdemux mit meinen optimierten Einstellungen und das benche ich selbst.

Mir ist sowieso wichtiger, dass ich mit dem System vernünftigen arbeiten kann, als das es in irgendwelchen Benchmarks ein paar % schneller ist, die mich vielleicht überhaupt nicht betreffen, falls es überhaupt auffällt.

 

[sedot]

Was gibt bei dir sudo lsblk -f aus?

Danke für das Hilfsangebot. Mount an sich ist kein Problem, die verbundenen Geräte identifizieren sich korrekt, aber je nach Desktop Umgebung oder eben Dateimanager habe ich nicht immer zwingend Zugriff auf deren freigegebenes(!) Dateisystem bzw. alle Daten in der Struktur via GUI. Meine Hypothese ist, irgendwas funktioniert mit dem Aushandlungsprozess mit iOS nicht. (Was mich nicht wundern würde)
Ich hab schon länger nicht mehr getestet, womöglich besteht das Problem auch nicht mehr und ich schwaffel gerade Quatsch. Für lokalen Datenaustausch zwischen den Geräten nutze ich einfach (W)LAN, falls nötig. Gibt ja für alles Apps.

 

[Caramon2]

Danke für das Hilfsangebot.

Die Ausgabe würde mich trotzdem interessieren, um zu sehen ob es Unterschiede zw. den Systemen gibt.

Habe mir gerade mal Slowroll mit dem Agama Installer in einer VM angeschaut bzw. installiert.
Im Vergleich zu YaST ist Agama ja schon ziemlich minimalistisch modern, fand ich trotzdem gut gemacht insgesamt.

Ich habe mir eben überlegt, dass ich openSUSE doch noch nicht ganz abschreibe: Wenn das Agama Installer ausgereift ist und zum Standard wird, versuche ich es nochmal.

Da es ja jetzt schon gravierende Unterschiede beim installierten System gibt, kommt es dann vielleicht besser mit den Anforderungen meiner Konfigurationen zurecht.

 

[sedot]

Die Ausgabe würde mich trotzdem interessieren, um zu sehen ob es Unterschiede zw. den Systemen gibt.

Für deinen Wissensdurst, in kurz.
sudo lsblk -f zeigt einfach nur meine internen Datenträger, mit den vorhersehbaren Informationen. Da ist nix besonderes zu sehen.

sudo lsblk -f
NAME FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda  btrfs        Daten2 a1b902a4-f79b-4a4e-af5a-6e4b444338e3  624,1G    33% /mnt/Daten2
sdb                                                                        
├─sdb1
│    vfat   FAT32        1D03-F677                             510,6M     0% /boot/efi
└─sdb2
     btrfs               c2d6758a-8c47-4aa4-8b46-9c1e1000b701   85,2G    63% /var
                                                                             /usr/local
                                                                             /root
                                                                             /srv
                                                                             /opt
                                                                             /home
                                                                             /boot/grub2/x86_64-efi
                                                                             /boot/grub2/i386-pc
                                                                             /.snapshots
                                                                             /
…

ideviceinfo identifiziert das angestöpselte Gerät inklusive Gerätedaten korrekt.
Auf den internen Speicher (documents, media) wie auch network des Gerätes habe ich Zugriff. Allerdings nur wenn ich Gnome (Nautilus) starte. Xfce (Thunar, Nemo, Nautilus) zeigt scheinbar zufällig entweder documents oder media an, aber immer auch network.
Zur Einordnung – documents beinhaltet die Apps bzw. freigegebene Unterordner dieser, media eben Ordner mit Bildern/Videos sortiert nach Aufnahmedatum, die mit der Kamera des Gerätes aufgenommen wurden.
Zusammengefasst, ifuse und libimobiledevice funktionieren prinzipiell irgendwie. 😅

Ergänzung (Gestern um 20:31)

Ich habe mir eben überlegt, dass ich openSUSE doch noch nicht ganz abschreibe (…)

Find ich gut.

 

[Caramon2]

Auf den internen Speicher (documents, media) wie auch network des Gerätes habe ich Zugriff. Allerdings nur wenn ich Gnome (Nautilus) starte. Xfce (Thunar, Nemo, Nautilus) zeigt scheinbar zufällig entweder documents oder media an, aber immer auch network.

Darauf kann ich mir keinen Reim machen. Sowas hatte ich noch nicht.

Mich irritiert an deiner lsblk-Ausgabe /boot/grub2/i386-pc, da das für booten im BIOS-Modus ist, wozu dir aber die bios_grub-Partition fehlt.

Ich hatte mein System mal so konfiguriert, dass es sich beliebig im BIOS- und UEFI-Modus booten ließ und das hier mit Screenshot beschrieben:

Ich habe die ESP bei meinem Produktivsystem nur mit 0,75 MiB erstellt und es sind sogar noch über 2/3 frei:

https://www.computerbase.de/forum/attachments/esp-png.1586293/

Standardmäßig boote ich im BIOS-Mode (deshalb die "bios_grub"-Partition - beide im 1 MiB vor der ersten regulären Partition, damit das nicht nutzlos bleibt). Den UEFI-Modus habe ich zum Spaß eingerichtet und um ggfs. "efibootmgr" darüber nutzen zu können.

Der unpartitionierte Bereich hinten ist z. B. für Experimente.

Inzwischen habe ich den UEFI-Modus aber wieder entfernt, weil der, als ich das nächste Mal per UEFI booten wollte, mal wieder nicht funktioniert hat. - Beim internen Laufwerk!

Will man an unterschiedlichen PCs von USB booten, macht UEFI noch viel mehr Ärger: IMO merkt man deutlich, dass MS dabei seine Finger mit im Spiel hatte…

Find ich gut.

Auf jeden Fall wieder Slowroll, da es als rolling release durchgehend aktuell gehalten wird, aber nur Sicherheitspatches und Bugfixes gleich bekommt, während es die großen Updates, nur besser geprüft alle 1-2 Monate geben soll.

Btw:

Wieso änderst du dein Tumbleweed nicht auf Slowroll? Nach dem Portal:Slowroll braucht man dazu nur die Repos anpassen und kann jederzeit wieder zurück, da beides ein Tumbleweed ist.

Dann könntest du hier in 1-2 Monat berichten, welchen Unterschied das in der Praxis macht und was dir auf welchen Grund besser gefällt.

Wenn man nicht immer sofort von allem die neuste Version (einschließlich möglicher Kinderkrankheiten) braucht, müsste Slowroll doch angenehmer sein: In der Ruhe liegt die Macht.

Und: Möge die Macht mit dir sein. - Slowroll ist sozusagen die Jedi-Edition.

 

[sedot]

Darauf kann ich mir keinen Reim machen. Sowas hatte ich noch nicht.

Ist etwas wild mit angesteckter Apple Hardware, scheint mir. Ich weiß es auch nicht. Mein Telefon exponiert nur media, ein älteres ebenso. Ist letztlich egal für meine Anwendungsfälle.

Mich irritiert an deiner lsblk-Ausgabe /boot/grub2/i386-pc, da das für booten im BIOS-Modus ist, wozu dir aber die bios_grub-Partition fehlt.

Kann ich dir nicht beantworten. Initial war Tumbleweed im Legacy Modus (des Mainboards) installiert, bei der zweiten Installation dann im UEFI only Modus. Die Partitionierung etc hatte ich im Experten-Modus durchgeführt aber auf den Vorgaben belassen, bis auf (abgewähltes) swap.

Wieso änderst du dein Tumbleweed nicht auf Slowroll?

Weil Tumbleweed mit ähnlich langen oder längeren Zeiträumen zwischen Upgrades bei mir auch problemlos funktioniert hat bisher. Es ist eine nahezu perfekte Situation, Upgrades oder neueste Software dann wann ich will.

Dann könntest du hier in 1-2 Monat berichten, welchen Unterschied das in der Praxis macht und was dir auf welchen Grund besser gefällt.

Ich glaube nicht, dass es viel zu berichten gäbe, zumindest wenn es ähnlich Tumbleweed funktioniert perspektivisch. Noch dazu mit Xfce. Läuft einfach so wie konfiguriert, völlig langweilig. 😅