Upgrade 12.1->13.1 mit Dualboot erfolgreich, aber merkwürdige OS-Abfrage

Hallo Forum,
ich habe einen Upgrade von 12.1 (Dualboot OS-Win7) gleich auf 13.1 gemacht und alles funktionierte auf Anhieb.

Der Startvorgang nach dem Upgrade kommt mir etwas länger vor als unter 12.1, aber vielleicht ist das subjektiv.
Später habe ich gelesen, dass man beim Upgraden keine Verionen “überspringen” sollte…
Gibt es einen “Test”, der mir verrät, ob und wenn ja, warum der Ladevorgang etwas länger dauert?

Was weiterhin merkwürdig ist, im allerersten Schirm, wo nach dem OS gefragt wird taucht nun (von unten nach oben) folgende OS-Auswahl:

  • Win 7
  • opensuse 12.1 test
  • opensuse 12.1
  • opensuse 13.1 test
  • opensuse 13.1

Natürlich ist der Verweis auf die 12.1-Version “unschön” und suggeriert möglcihwerweise das Vorhanden sein von 3 OS…

Ich weiß, dass man die Datei mit dieser Abfrage editieren kann, um die 12.1 Einträge zu löschen.
Kann mir jemand sagen, wo ich diese Datei finde?

Dankbar für jeden Hinweis

Tom

Hi Tom,

  1. Analyse der Bootzeit:
    Du kannst via Zypper oder Yast das Tool “systemd-analyse” nachinstallieren. Nach einem Reboot kannst du dann mit dem Aufruf “systemd-analyse-plot” eine Vektorgrafik erstellen die dir aufzeigt welcher Service lange zum Booten benötigt. Diesen kannst du dann ggf. mit “systemctrl disable” aus deiner Bootfolge werfen.

  2. GRUB-Screen:
    Zuviele Einträge können manchmal vorkommen. Mach ein Backup der Datei “cp /boot/grub/grub.cfg ~/grub.cfg” und erzeuge mit “grub-mkconfig -o /boot/grub/grub.cfg” die Einträge für grub neu.
    Wenn das nicht reichen sollte, müsstest du selbst die Config bearbeiten. Ich habe nur die Erfahrung gemacht, dass ein Kernel-Update die Einstellungen wieder rückgängig macht. Das System läuft weiterhin einwandfrei, nur der Eintrag “opensuse 12.1” könnte ggf. zurückkehren.

Ich hoffe, das hilft
Simon

Das sollte wohl eher “systemd-analyze plot” lauten… :wink:
Oder du kannst mit “systemd-analyze blame” eine sortierte Liste der Startzeiten aller Dienste bekommen.

  1. GRUB-Screen:
    Zuviele Einträge können manchmal vorkommen. Mach ein Backup der Datei “cp /boot/grub/grub.cfg ~/grub.cfg” und erzeuge mit “grub-mkconfig -o /boot/grub/grub.cfg” die Einträge für grub neu.
    Wenn das nicht reichen sollte, müsstest du selbst die Config bearbeiten. Ich habe nur die Erfahrung gemacht, dass ein Kernel-Update die Einstellungen wieder rückgängig macht. Das System läuft weiterhin einwandfrei, nur der Eintrag “opensuse 12.1” könnte ggf. zurückkehren.

Die Liste sieht mir mehr nach grub1 (legacy) aus, was auch eher zu erwarten wäre, weil in 12.1 grub2 noch nicht verwendet wurde, und bei einem Upgrade der Bootloader nicht umgestellt wird.
Die zu ändernde Datei ist also /boot/grub/menu.lst .
Oder benutze einfach YaST->System->Bootloader, da kannst du Booteinträge hinzufügen, ändern und löschen.
Du kannst natürlich auch in YaST auf Grub2 umschalten, dann sollten die alten 12.1 Einträge auch weg sein… :wink:

Eine Vermutung meinerseits:
Du hast noch “acpid” installiert, das kann Verzögerungen beim Booten/Runterfahren mit sich bringen.
Systemd hat einige seiner Aufgaben übernommen, also deinstalliere das besser, da es bei falscher Konfiguration sogar zu Konflikten kommen kann.

Wow, das waren ja Superinfos! Danke euch. Mit diesem Support macht opensuse richtig Spass!

Ich habe den Eindruck, dass der Update von 12.1 auf 13.1 recht gut geklappt hat.
Bei meiner Tochter (ebenfalls doubleboot) werde ich 13.1 denke ich neu installieren.

Aber erst mal der zu euren Tipps Reihe nach:

Tatsächlich lief bei mir noch grub. Mittels Bootloader konnte ich die 12.1 Einträge löschen

Ich habe dann auch auf grub2 “umgeschaltet”. Dort keine Einträge von OS12.1
Mit grub2 konnte ich problemlos linux opensuse 13.1 aufrufen.

ich habe acpid tatsächlich noch drin gehabt und das gemäß Ratschlag deinstalliert.

Ich habe von der Konsole aus systemd-analyze plot aufgerufen, konnte aber mit dem Ergebnis nicht viel anfangen. Wo wird ein Plot ausgegeben?

Da war systemd-analyze blame schon “intuitiver”, ich erhielt folgende Liste:

systemd-analyze blame
41.525s network.service
19.854s network@wlan0.service
19.850s network@eth0.service
2.289s cycle.service
2.227s systemd-udev-root-symlink.service
1.973s dev-hugepages.mount
1.970s sys-kernel-debug.mount
1.970s dev-mqueue.mount
1.969s kmod-static-nodes.service
1.586s windows-C.mount
1.241s systemd-vconsole-setup.service
1.148s systemd-modules-load.service
1.146s systemd-remount-fs.service
812ms systemd-readahead-collect.service
811ms NetworkManager.service
799ms systemd-readahead-replay.service
511ms ModemManager.service
502ms systemd-fsck@dev-disk-by\x2did-ata\x2dWDC_WD3200BEVT\x2d60A23T0_WD\x2dWX71A41W5802\x2dpart7.service
430ms console-kit-log-system-start.service
419ms ntp.service
413ms rsyslog.service
387ms avahi-daemon.service
346ms apparmor.service
202ms wpa_supplicant.service
176ms systemd-tmpfiles-setup.service
173ms dev-disk-by\x2did-ata\x2dWDC_WD3200BEVT\x2d60A23T0_WD\x2dWX71A41W5802\x2dpart5.swap
170ms home.mount
151ms user@1000.service
143ms user@0.service
103ms plymouth-read-write.service
98ms systemd-backlight@acpi_video0.service
97ms systemd-tmpfiles-clean.service
92ms systemd-random-seed.service

Das Hochfahren dauert bei mir also rund 41,5 s und davon scheint Network.service die meiste Zeit zu “fressen”.
Ist das “normal” oder gibt es “Tricks” den Ladevorgang zu beschleunigen?

Das Hochfahren dauert bei mir also rund 41,5 s und davon scheint Network.service die meiste Zeit zu “fressen”.
Ist das “normal” oder gibt es “Tricks” den Ladevorgang zu beschleunigen?

Da bist Du nicht allein, allerdings sind es bei mir nur 15 Sekunden.

2013-11-25T19:58:12.925386+01:00 linux64 kernel:     0.006397] Initializing cgroup subsys net_cls
2013-11-25T19:58:12.926645+01:00 linux64 kernel:     1.095551] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
2013-11-25T19:58:12.926648+01:00 linux64 kernel:     1.095799] audit: initializing netlink socket (disabled)
2013-11-25T19:58:12.928131+01:00 linux64 kernel:     7.169905] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
2013-11-25T19:58:13.055273+01:00 linux64 systemd[1]: Starting LSB: Configure network interfaces and set up routing...
2013-11-25T19:58:13.441288+01:00 linux64 network[814]: Setting up network interfaces:
2013-11-25T19:58:13.644570+01:00 linux64 network[814]: lo
2013-11-25T19:58:13.728258+01:00 linux64 network[814]: lo        IP address: 127.0.0.1/8
2013-11-25T19:58:13.877921+01:00 linux64 systemd[1]: Starting system-network.slice.
2013-11-25T19:58:13.878552+01:00 linux64 systemd[1]: Created slice system-network.slice.
2013-11-25T19:58:13.879208+01:00 linux64 systemd[1]: Starting ifup managed network interface enp2s0...
2013-11-25T19:58:13.985643+01:00 linux64 ifup[1252]: enp2s0    device: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09)
2013-11-25T19:58:13.987016+01:00 linux64 ifup[1252]:     enp2s0    device: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09)
2013-11-25T19:58:28.734206+01:00 linux64 systemd[1]: Started ifup managed network interface enp2s0.
2013-11-25T19:58:28.761167+01:00 linux64 network[814]: ..done..doneSetting up service network  .  .  .  .  .  .  .  .  .  .  .  .  ...done
2013-11-25T19:58:28.762662+01:00 linux64 systemd[1]: Started LSB: Configure network interfaces and set up routing.
2013-11-25T19:58:28.854420+01:00 linux64 ntp[1434]: Starting network time protocol daemon (NTPD)..done
2013-11-25T20:00:17.442761+01:00 linux64 kernel:   135.461303] Bluetooth: BNEP (Ethernet Emulation) ver 1.3

Hätte man wahrscheinlich auch dazuschreiben sollen, ja.
Der Plot wird als SVG auf den Standard Output (also normalerweise das Terminal) geschrieben, das müsstest du doch gesehen haben, oder? :wink:
Umleiten in eine Datei kannst du das wie üblich: “systemd-analyze plot >mein_boot_plot.svg”
Die .svg Datei kannst du dann z.B. mit Firefox betrachten.

Der Plot ist aber schon etwas “unübersichtlicher”, weil er auch anzeigt, welche Services von welchen andern abhängig sind.

Da war systemd-analyze blame schon “intuitiver”, ich erhielt folgende Liste:

systemd-analyze blame
41.525s network.service
19.854s network@wlan0.service
19.850s network@eth0.service

Das Hochfahren dauert bei mir also rund 41,5 s und davon scheint Network.service die meiste Zeit zu “fressen”.
Ist das “normal” oder gibt es “Tricks” den Ladevorgang zu beschleunigen?

Ja.
Als “normal” würd ich das nicht ansehen, bei mir daurt das nicht so lange:

# systemd-analyze blame
...
          5.546s NetworkManager.service

Und ja, ich hab auch eth0 (da hängt aber kein Kabel dran) und wlan0.
Scheinbar benutzt du aber nicht den NetworkManager sondern ifup, wegen den beiden Services network@wlan0.service und network@eth0.dervice.
Was sagt denn:

systemctl status network.service

Evtl. würd umschalten auf NetworkManager helfen?
(YaST->Netzwerkgeräte->Netzwerkeinstellungen->Globale Optionen)
Du musst dann aber wahrscheinlich die WLAN-Verbindung neu einrichten. Das NetworkManager-Applet sollte das aber einfach machen. (Ich hab’s übrigens als “System-Verbindung” (“für alle Benutzer einrichten” oder so in GNOME) eingerichtet, damit sie auch aufgebaut wird, wenn ich mich als root im Textmodus einlogge… :wink:
Noch ein Hinweis falls du das probierst und KDE verwendest:
Schau vorher, ob das Paket “plasmoid-networkmanagement” installiert ist. Falls es nicht im Systemabschnitt der Kontrollleiste auftaucht, musst du es erst aktivieren: rechts-klick auf den kleinen Pfeil-nach-oben am rechten Rand, gleich links von der Uhr, und “Einstellungen für Systemabschnitt der Kontrollleiste” aufrufen. Dort dann ein Häkchen be “Netzwerkverwaltung” machen.

Hallo wolfi323,

sorry war etwas länger weg in Hong Kong und konnte mich nicht sofort um diene Tipps kümmern.

Also das mit dem Umschalten von ifup auf Knetworkmanager scheint ziemlich was gebracht zu haben beim Startvorgang!
Nun beobachte ich etwas seltsames: Die WLAN-Verbindung wird sofort aufgebaut, allerdings wird diese periodisch unterbrochen und automatisch wieder aufgebaut. Auf der Suche nach der Ursache fand ich beim Knetworkmanager folgende verdächtige Ausgaben:
IPv6-Adresse: Fehler in der IP-Anzeige
IPv6-Gateway: kein Gateway

Hat das was mit derm Umschalten auf den Knetworkmanager zu tun oder sollte ich für dieses “Aussetzen” der Wlan-Verbindung doch einen neuen Thread beginnen?

Gruß

Tom

Ein neuer Thread wäre vermutlich nicht schlecht. Und du solltest dann auch gleich dazuschreiben, was für eine WLAN-Karte das ist. (“lspci -nnk” bzw. “lsusb”)

Nur mal soviel: Ich habe dieses Problem nicht, also sollte es kein genereller Fehler im NetworkManager sein.
Da du dich auf IPv6 beziehst, kannst du ja mal probieren das auszuschalten.
Evtl. würde aber auch die Installation eines anderen Treibers helfen.

Ups der Spuk ist weg!

Ich habe mit dem Networkmanager “rumgespielt” dann aber (glaube ich) alles so belassen wie es war. Neu gebootet und beim nächsten Start baute sich eine stabile wlan-Verbindung auf :wink:

Nochmals herzlichen dank an alle, die mir geholfen haben diesen etwas unglücklichen Update über zwei Versionen hinweg (12.1 → 13.1) zu reparieren. Bei meiner Tochter (ebenfalls Doubleboot Win+Suse) werde ich vor Installation von 13.1 erst mal 12.1 “beseitigen”. Diese “Ungereimheiten” überfordern einen Unbedarften wie mich… bin ich froh, dass es so ein Forum gibt!