Leap42.2: Startverhalten ist mau && Networkmanager

Hinweis: In dem Thema Leap42.2: Startverhalten ist mau && Networkmanager gibt es 69 Antworten auf 7 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Eines zum Schluss noch: Ich habe mir zwar nicht alles durch gelesen, aber hier mein Kommentar, zu dem was ich aufgeschnappt habe:
    Dass die neueren Versionen von openSUSE langsamger starten, liegt nicht am 4er Kernel, sondern daran, dass Systemd mittlerweile nur noch schlecht ist. Die Entwickler von RedHat wollten zu viel. Ab ich denke Fedora 17 gings mit Systemd bergab. Systemd ist mittlerweile nur noch ein Paradebeispiel von zu viel Parallelisierung. Das große Pro Systemd und Kontra SysVInit war, dass Systemd den Betriebssystemstart parallelisiert, während SysVInit alles nacheinander startet. Hört sich erstmal gut an, und es war auch echt geil, ein Live Fedora 17 innerhalb 10 Sekunden starten zu sehen auf einen älteren Büro-PC (Dual Core AMD Athlon mit 2,5 GHz, onboard Graka und mechanischen Festplatten). Wie gesagt, war, leider. In diversen Interessensgruppen habe ich aufgeschnappt, dass das alte SysVInit nun doch wieder schneller ist als Systemd (nachgemessen laut dem Autor an Debian 8, der sich mit dem Beitrag lautstark über Systemd beschwerte).


    Also wenn Du einen schnellen Bootvorgang haben willst, dann stelle wieder auf das alte SysVInit um oder schaue Dir mal upstart an. Just my 2 Cents...

    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 107361 haftet ausdrücklich der jeweilige Autor: derwunner

  • Es nervt gewaltig und ist für Nachlesende einfach nur schädlich, wenn irgendwelche unreflektierten Haste-nich-gesehen Gerüchte verbreitet und völlig absurde Ratschläge gegeben werden.


    Diese unleidige Debatte SysV init vs. systemd ist ähnlich hirnrissig, wie die das ewige "Pulseaudio ist doof" Gelalle.
    Heute lästert keiner mehr über Pulseaudio.


    Und auch systemd wird Standard bleiben. Es ist ein moderner Ansatz, der einfach schneller ist, als es SysV init sein könnte. Mal einfach kurz nachdenken, würde jedem zu diesem Standpunkt helfen:
    Warum ist ein System mit einer festen Anzahl an zu erledigenden Jobs schneller, wenn es die Aufgaben paralliesiert quasi gleichzeitig ausführen kann, als ein System, dass alle Jobs schön der Reihe nach ausführt?


    Natürlich gibt es bei Neuerungen anfangs Ärger. Besonders bei so komplexen Dingen, wie es bei systemd nun mal ist. Aber ebenso, wie bei Pulseaudio, wird das schon. Und ist schon ziemlich geworden.


    Bei den allermeisten Problemen, die derzeit auftreten, würde ein Umstieg auf SysV init auch nichts nützen.
    Das wäre dann höchstens noch langsamer.


    Zudem dürfte wohl kein Anwender genügend Wissen haben, um sein System sauber auf SysV init zurückzuportieren.


    Lasst die Finger von solchen Rattenfängerdummheiten.


    Ich habe diese unsägliche Debatte schon geraume Zeit verfolgt,
    kenne also wirklich die Argumente der Systemdgegner.
    Ich finde systemd geil.
    Und die Debatte schwachsinnig.


    Die unterschwellige Lüge, dass systemd mittlerweile wieder langsamer wäre, ist unverschämt und völlig sachstandsfrei.
    Da hätte ich gerne ein fundiertes Beispiel, statt nachgeplapperten Unsinn.
    Das wird wohl keiner wirklich nennen können, weil es das schlicht nicht geben wird.


    Just my four dollars.

  • SORRY FÜR ALLES!!!
    Muss mich entschuldigen und einen Fehler eingestehen, gleichzeitig Leap42.2 in Schutz nehmen.


    Hab festgestellt als ich die SSD gewechselt hatte und immer noch dasselbe Grub Menu vor mir gesehen hatte - schwante mir es - dass die Installation anstelle auf SSD auf meiner zusätzlich eingebauten HDD stattgefunden hat. Warum sich jetzt aber die Bootreihenfolge der Platten geändert hat kann ich momentan nicht nachvollziehen da die SSD(s) normalerweise als 1.Platte eingehängt sind und auch als sda im System landen, dennoch wird/wurde plötzlich von der 2.Platte gebootet.


    Die 'maue' Startzeit bezog sich also auf die HDD, nach einer Neuinstallation auf meine SSD2 ist das was ich als Bootzeit bezeichne, also GrubMenu -> Return und bis zum Login Screen wieder bei 5-7sec.


    also alles in Butter mit openSuse und Leap42.2


    Grüße - SORRY

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    Für den Inhalt des Beitrages 107392 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • Toll.
    Kaum sind über 60 Posts mit allerlei unsinnigen Theorien und Geplänkel vertan,
    schon sind wir wieder bei dem, was in der Regel der Grund ist:
    Das Problem sitzt vor der Tastatur.


    Es ist schon lange ein Mechanismus implementiert, der verhindert, dass der Einbau von Festplatten die Bezeichnung der Bootdevices durcheinanderbringt.
    Schon sehr lange.


    Das ist also völlig normal.


    Hätte man schon längst gelernt haben können.


    Aber es ist ja alles mögliche Schuld.
    Vor allem das, was man nicht belegt, oder belegen kann.

  • Das Problem liegt mal wieder zwischen den Ohren.
    Normalerweise schalte ich die Festplatten die ich nicht benötige bei der Installation auch stromlos, was ich mit einigen auch gemacht habe. Bei der Verbliebenen war mir nicht klar dass die eigentlich angeschlossen war oder ich habe es übersehen/vergessen.


    Es ist schon lange ein Mechanismus implementiert, der verhindert, dass der Einbau von Festplatten die Bezeichnung der Bootdevices durcheinanderbringt.
    Schon sehr lange.

    ist mir nicht ganz klar was damit gemeint ist? UUID?


    gut, ich scheine nicht aufgepasst zu haben und auf sdb installiert zu haben und auch von dort zu booten. Wenn ich aber meine alte SSD1 einschiebe an Controller Platz1 also als sda. Warum wird dennoch von sdb gebootet per MBR obwohl auf sda ebenso ein Grub 'im MBR' vorhanden sein sollte.


    Habe in einem anderen Thread was gelesen, dass bei der Installation das (UEFI) BIOS modifiziert werden kann in Bezug auf die Bootreihenfolge(?)
    Was ist da dran?

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    Für den Inhalt des Beitrages 107397 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • Jetzt verhacktstückst du schon wieder völlig verschiedene Dinge.


    Erst mal prinzipiell:
    Es genügt einen einzigen Grub auf irgendeiner Platte zu haben.
    Der kann dann alle Betriebssysteme je nach Erfordernis im Chainloadverfahren oder eben direkt starten.


    Zweitens:
    Seit geraumer Zeit ist das Problem gelöst, dass man in Bootmenus rumfrickeln muss, wenn man Platten um- oder einstöpselt. Das kommt einfach nicht mehr vor, falls der User brav ist. Dafür gibt es die UUIDs.
    Im Prinzip wird jede Partition einfach mit einer UUID versehen.
    Auf Platten mit dem herkömmlichen Partitionierungsschema. Auf modernen GPT ist das sogar ein wesentlicher Teil der Spezifikation (daher der Name GloballyUniqueIdentifierPartitionTable).
    Das sind zwei paar Schuhe, die aber dem gleichen Herrn dienen und auch vomselben angezogen werden.


    Der Unterschied zwischen beiden (G)UUIDs ist, dass bei herkömmlichen Platten das als Label in der MBR Struktur steht, bei einer GPT aber die UUID per defnitionem selbst der "Name der Partition" ist.
    (Kann jetzt Otto-Normal-Linuxer völlig egal sein; das interessiert nur Leute, die sowas wie fdisk oder btrfs verbrechen)


    Und völlig ab davon kann man streng genommen kein (U)EFI BIOS modifizieren.
    Schlicht, weil es das strenggenommen gar nicht gibt.
    Es ist eine längst eingeschliffene vererbte Ungenauigkeit.
    BIOS meint eigentlich ein Programm samt Konfigurationsdaten, die in bestimmten nicht flüchtigen Speicherchips abgelegt sind. Nämlich das BasicInputOutputSystem.
    UEFI ist also nichts anderes, als dieses alte BIOS. Es ist sogar ein UniversalExtenableFirmwareInterface.
    Was nichts anderes sagt, als dass es eben nicht mehr (komplett) in einem Chip geschrieben steht, sondern Teile davon auch auf einer Festplatte liegen können.
    Bei Linuxdistris ist das regelmäßig der Fall.
    Es gehört zur Spezifikation von UEFI, dass ein solcher Speicherbereich erreichbar ist.
    Dort lagern die signierten eigentlichen Bootloader oder OS-loader. Je nach Gusto.


    Ich denke, du wurdest vom Signieren dieser von UEFI zu booten erlaubten Loadern verwirrt.
    Die Keys dafür liegen meist in einem TP Modul (TrustedPlatform Chip).Will man ein weiteres OS direkt laden, dann muss dessen Prüfsumme samt Schlüssel in diesen Chip eingetragen werden.


    Fast jede Linux Distri verwendet aber Shim als primären Loader. Der wurde von M$ signiert und kann seinerseits nun jedes Linux nach Gusto laden. Man braucht das also nicht.
    Ein Biosupdate könne da irgendwas richten, ist also schlicht falsch.
    Es sei denn natürlich der Boardhersteller bietet Firmware Updates, die Fehler bereinigen. Aber das ist wieder eine ganz andere Baustelle.


    Und vorgesagtes gilt nur für den "Secureboot". Es gibt Boards, die man ohne Secureboot laufen lassen kann.
    Da braucht es gar nix.


    openSUSE selbst verwendet auch den Shimloader und kann ganz gut mit Secureboot laufen.
    Es gibt also auch hier keinen Grund für irgendein Update.
    Das wird mit Sicherheit nur Ärger bringen.
    Zwar nicht garantiert, aber sehr wahrscheinlich.

  • zunächst danke für die ausführliche Erklärung zu Bios/Uefi
    Meine Bios Kenntnisse liegen weiter zurück, als UEFI nur ein Apple Thema war. 'damals' gab es am PC nur BIOS, zumindest für mich. Mein aktueller PC ist von 2013 hat ein grafisches BIOS ( so steht es darin vermerkt ) was wohl ein UEFI System ist, wenn ich das so formulieren kann/darf.
    Da ich seit 2010 meinen Mac bevorzuge und das Bios zur Installation in 2013 nicht angefasst habe sind meine Kenntnisse bzgl BIOS/UEFI gering.


    Bestückt ist dieser PC mit HDD und SSD1/SSD2 wechselweise, dh die HDD ist fest eingebaut während die SSDs als Wechselplatte eingeschoben werden, entweder SSD1 oder SSD2.


    Da SSD1 richtig mit Linux installiert war ist dort auch darauf Grub (#1) installiert, die HDD war damals zusätzliche Backupplatte.
    Dann habe ich (SSD1 entnommen, SSD2 eingeschoben ) fälschlicherweise auf die HDD Linux installiert mit neuem Grub (#2), ( SSD2 blieb unberücksichtigt )


    Schiebe ich jetzt zu meiner HDD mit Grub#2 meine SSD1 mit Grub#1 in den primären 'slot' also als erste Wechselplatte in das System hatte/habe ich die Situation dass nicht zunächst von SSD1 via Grub#1 gebootet wird sondern von HDD/Grub#2 obwohl am 2.Controller angehängt.


    irgendwie verständlich?


    Diese Situation war allerdings nicht immer so. Bevor ich fälschlicherweise meine 2.Linuxinstallation auf die HDD vorgenommen habe wurde von SSD1 am primären Controller gebootet, war ja auch kein anderes Bootmedium vorhanden.


    Meine Erwartung wäre, wenn nur die HDD am Controller2 im Rechner ist, (evtl mit 'leerer' SSD2) dann wird von dieser HDD gebootet.
    Schiebe ich allerdings zusätzlich meine SSD1 als Wechselmedium ein sollte, da an Controller1, auch zunächst von dieser gebootet werden.
    Und dies ist nicht (mehr) der Fall.


    (Inzwischen ist die HDD stromlos im PC und ich habe auf SSD2 im primären Slot/Controller neu installiert -> Grub#3)
    SSD1 soll als Fallback System mit der darauf befindlichen Installation zur Seite gelegt werden um im Falle darauf zurückgreifen zu können, so der Plan.


    ---
    ansonsten verwende ich seit geraumer Zeit nur UUID anstelle von /dev/sdX .. und wie Leap42.2 installiert und welche Einträge es vornimmt ist ohne meinen Einfluss

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    Für den Inhalt des Beitrages 107414 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • wer den Schaden hat ...


    ... kommt drauf an was die Axt anrichten soll. TFTs trifft man nicht mehr so leicht wie die Röhren von früher ;):smilie_pc_012:

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    Einmal editiert, zuletzt von TuxSv748 ()

    Für den Inhalt des Beitrages 107430 haftet ausdrücklich der jeweilige Autor: TuxSv748