/boot, opS 13.1 (x86_64) sind auf sda
SWAP, w7, opS Leap (x86_64) sind auf sdb
NEU: kommt eine sdc (moderner 
als sda) hinzu. (opS = openSUSE, alle drei sind HDD)
auf sdc möchte ich
eine neue, grössere /boot-Partition anlegen (welche danach /boot auf sda1 ablösen soll)
**und **
bestehende <SW-Paket-Liste.xml> der opS 13.1 (von sda auf sdc) rüber-/einspielen lassen (wobei ich zugleich NEU die logische /tmp-Partition in einer anderen Grösse haben möchte und noch eine logische Partition für /usr/local anlegen lassen will)
YaST2 <SW-Paket-Liste.xml> gespeichert = vorbereitet
<vmlinuz.>, <initrd.>, <grub.cfg> und restl. Dateien für künftiges /boot-Verzeichnis gespeichert = vorbereitet
(opS 13.1 auf sdc soll dann ca. vmlinuz-3.16.xxx-x.xx nutzen, was ich dann in Bootloader config eingeben kann)
Sollte ich eine Neuinst. (opS 13.1 oder opS Leap habe ich je als Distri-Version auf DVDs verfügbar) auf sdc ausführen?
Kann man einer Neuinst. mitteilen “SW-Auswahl der Neuinst. abwählen/nicht inst.” und anstelle dessen bitte die <SW-Paket-Liste.xml> direkt einspielen (evtl. ab separatem Datenträger)? Geht das überhaupt?
oder sollte ich zuerst eine Neuinst. auf sdc machen, dann diese Inst. zuerst mal laufen lassen (von wegen UUIDs, Kernel usw. damit überhaupt ein erster Systemstart funktionieren wird), danach /boot-Verzeichnis mit gewünschtem Kernel usw. anpassen und die SW-Paket-Liste im YaST importieren?
Kann ich (in YaST2) beim Importieren einer <SW-Paket-Liste.xml> gleich alle anderen SW-Pakete (nämlich diejenigen, welche durch die Neuinst. installiert wurden) ersetzen/deinstallieren lassen? (habe keine Erfahrung damit, noch nie probiert)
Welche Vorgehensweise ist richtig oder sinnvoll? Wie macht man sowas?
Für Hinweise und Tipps, besten Dank.
vorab:
Inst.-Medien sind opS12.3-DVD (und opSLeap) und nicht wie erwähnt opS13.1
Wahrscheinlich oder ziemlich sicher kann openSUSE auch klonen. Wie das geht muss ich noch nicht wissen, denn neu legte ich /usr/local auf eine sep. logische Partition (was auf sda noch in der /-Partition liegt). SystemWiederherstellung mittels Sicherung würde evtl. ebenso Probleme haben, keine Ahnung.
Ist-Zustand:
-
opS12.3 Basisinst. auf sdc "gelungen"
!
(BIOS wollte optischeDD unter Systemstart-Optionen nicht mehr anzeigen, mit CSM Legacy wollte es dann wieder, danach meldete opS12.3-DVD nach starten des linuxrc v4.1.5 “auf dieser DVD keine Repos” ich aber sicher, dass DVD i.O., mangels Kenntnisse und Auswahl klingte die Option “Firmware testen” noch interessant [Indel-Copyright-SW 2007, MB und Prozessor ca. 2013] und tatsächlich “Installation” [findet neu die Repos auf der DVD] scheint zu gelingen [alles schön selektiert/partitioniert], mit der Inst.-Bestätigung schaffte ich, die opS12.3-DVD und mein PC erstmals ein Kernel-Panic zu fabrizieren :), cool bleiben, nochmals probieren, yes! Erster Systemstart)
-
Kernel 3.16.xx-Dateien in /boot hineinkopiert*]grub.cfg angepasst*]Neustart (kann opS12.3/opS13.1/opSLeap und w7 starten, kein Datenverlust)*]Kontrolle (in opS12.3) uname -a (Kernel 3.16.xx, yes!)
Jetzt jedoch noch Problem
gilt nur für opS12.3 mit Kernel 3.16.xx, Ziel ist opS12.3 Dartmouth auf opS13.1 Bottle anzuheben):
- wie vorgesehen, wollte ich gleich aktuelle Repos von opS13.1 hinzufügen (YaST will aber sofort Repo-URL Online verifizieren und sonst verweigert mir YaST das manuelle Hinzufügen von Repos)]kein “e1000e” Modul geladen (somit kein Internet, dem Kernel fehlt ein Module
, /etc/sysconfig/kernel, insmod und YaST; habe das Modul manuell eingetragen)]Neustart (laden des Moduls fehlgeschlagen, ich lese mittels systemctl -b und suche in /var/log/boot.log nach weiteren Infos)*]evtl. kann der Kernel ein paar “libs/lib” nicht finden Path-Problem?, ist die neue sep. /usr/local-Partition Verursacherin? Wo sind die libs? Wo sollten diese sein?
P.S. das Importieren einer SysPaketList.xml in YaST ersetzt (meine ich, sieht so aus) die vorhandenen Pakete
AUSZUG /var/log/boot.log
OK ] Started Replay Read-Ahead Data.
Starting Load Kernel Modules…
Starting Setup Virtual Console…
Starting Remount Root and Kernel File Systems…
[FAILED] Failed to start Load Kernel Modules.
See ‘systemctl status systemd-modules-load.service’ for details.
Starting Apply Kernel Variables…
OK ] Started Apply Kernel Variables.
SOMIT gehe zu: /usr/lib,/usr/lib64,/usr/local/lib,/usr/local/lib64
> dort nach systemd und Ähnlichem suchen
/usr/local/lib = 0 Dateien
/usr/local/lib64 = 0 Dateien
/usr/lib64 = nichts mit “systemd” oder ähnlich
/usr/lib = diverses
/usr/lib/sysctl.d = 0 Dateien
/usr/lib/modules-load.d = 0 Dateien
WEITER in: /usr/lib/systemd/ (dort noch evtl. relevant):
> /usr/lib/systemd/ cat systemd-sysctl = unlesbares Zeugs, rot
> /usr/lib/systemd/ cat systemd-initctl = idem
> /usr/lib/systemd/ cat systemd-modules-load = idem
> /usr/lib/systemd/ cat systemd = unlesbares Zeugs, s/w
> /usr/lib/systemd/system/ = etliche Inst-Dateien und Links der DVD aus dem Jahre 2013, z.B.
lrwxrwxrwx 1 root root 9 6. Mär 2013 swap.service -> /dev/null
-rw-r–r-- 1 root root 353 22. Feb 2013 swap.target
lrwxrwxrwx 1 root root 22 6. Mär 2013 sysctl.service -> systemd-sysctl.service
dort finde ich nichts neueren Datums, somit Problem wohl anderswo
NOCH in: /usr/lib/module-init-tools/
/usr/lib/module-init-tools/ cat weak-modules = irgendwas “only use if uninstall SLE10 to SLE11+”, > use weak-modules2
Erklärungs-Intro von: /usr/lib/module-init-tools/ cat weak-modules2
#! /bin/bash
##############################################################################
How it works:
* Kernels install modules below /lib/modules/$krel/kernel/.
* KMPs install modules below /lib/modules/$krel/updates/ or …/extra/.
* Symbolic links to modules of compatible KMPs are created under
/lib/modules/$krel/weak-updates/{updates,extra}/… (the original path
below /lib/modules/$other_krel is used).
* Depmod searches the directories in this order: updates/, extra/,
weak-updates/, kernel/ (see /etd/depmod.conf or
/etc/depmod.d/00-system.conf for details).
* Compatibility of a kernel with a KMP is defined as: The KMP is built
for the same flavor as the kernel and after adding the KMP modules to
the kernel, depmod -e -E Module.symvers reports no errors about
missing symbols or different symbol checksums. See the
has_unresolved_symbols() function for details.
* At KMP install time (function add_kmp()), we create symbolic links
for all kernels that this KMP is compatible with. We skip kernels that
already contain symbolic links to a newer KMP of the same name,
contain the KMP itself or another version in updates/ or extra/ or
have overlapping module names with other KMPs in the respective
kernel (this should not happen).
* At kernel install time (functions add_kernel()), we create symbolic
links for each compatible KMP, unless the KMP or a different one with
overlapping module names is present in updates/ or extra/ (KMP build
against $krel can be installed before a kernel with that version).
When multiple KMPs of the same name are compatbile, we chose the one
with the highest version number. This is repeated when subsequent
subpackages (main or -extra) of that kernel are installed.
* At KMP removal time (function remove_kmp()), the modules and their
symlinks are removed and, where possible, replaced by symlinks to the
newest of the remaining compatible version of that KMP.
ich lese: “we skip Kernels that already contain symbolic links to a newer KMP”
für mich relevant (“Fehler-Einkreisung”) oder Holzweg?
etwas bei der auto-Produktion @boot-up von “symlinks” fehlerhaft?
Passwort:
linux-bopi:~ # uname -r
3.16.7-38.gba87edb-desktop
linux-bopi:~ # modprobe -l|grep e1000e
FATAL: Could not load /lib/modules/3.16.7-38.gba87edb-desktop/modules.dep: No such file or directory
linux-bopi:~ # modinfo e1000e
ERROR: modinfo: could not open /lib/modules/3.16.7-38.gba87edb-desktop/modules.dep
somit habe ich mal ein Ordner für 3.16.7-xx in /lib/modules/ angelegt
und weil etwas von modules.dep (dependenz) gesucht wird
noch “modules.dep” und “modules.dep.bin” einfach vom Kernel 3.7.10-xx kopiert 
“modules.builtin” und “modules.builtin.bin” klingt auch noch gut/vielversprechend > auch kopiert
den Ordner “vdso” ebenso
und zuguter letzt, den Ordner “Kernel” samt seinem Inhalt (ca. 150MB) gleich auch noch
in “modules.softdep” steht:
Soft dependencies extracted from modules themselves.
Copy, with a .conf extension, to /etc/modprobe.d to use it with modprobe.
und in “modules.alias” ca. idem:
Aliases extracted from modules themselves.
alias devname:cpu/microcode microcode
alias char-major-10-184 microcode
alias x86cpu:vendor:0002:family::model::feature:* microcode
usw.
noch in /etc/modprobe.d/ reinschauen:
linux-bopi:~ # cd /etc/modprobe.d/
linux-bopi:/etc/modprobe.d # dir
total 60
-rw-r–r-- 1 root root 3613 Jan 26 2013 00-system.conf
-rw-r–r-- 1 root root 532 Nov 14 2012 10-unsupported-modules.conf
-rw-r–r-- 1 root root 181 Feb 4 2013 50-alsa.conf
-rw-r–r-- 1 root root 5921 Mar 4 2013 50-blacklist.conf
-rw-r–r-- 1 root root 128 Jan 29 2013 50-bluetooth.conf
-rw-r–r-- 1 root root 33 Feb 15 2013 50-ipw2200.conf
-rw-r–r-- 1 root root 34 Feb 15 2013 50-iwl3945.conf
-rw-r–r-- 1 root root 30 Feb 15 2013 50-iwlagn.conf
-rw-r–r-- 1 root root 86 Feb 21 2013 50-nvidia.conf
-rw-r–r-- 1 root root 18 Feb 15 2013 50-prism54.conf
-rw-r–r-- 1 root root 183 Jul 30 12:42 50-sound.conf
-rw-r–r-- 1 root root 0 Jul 30 12:42 50-sound.conf.YaST2save
-rw-r–r-- 1 root root 0 Jul 30 12:42 50-tv.conf
-rw-r–r-- 1 root root 3 Jul 30 22:49 50-yast.conf
-rw-r–r-- 1 root root 2 Jul 30 22:41 50-yast.conf.YaST2save
-rw-r–r-- 1 root root 47 Nov 22 2011 99-local.conf
linux-bopi:/etc/modprobe.d # cat 10-unsupported-modules.conf
Every kernel module has a flag ‘supported’. If this flag is not set loading
this module will taint your kernel. You will not get much help with a kernel
problem if your kernel is marked as tainted. In this case you firstly have
to avoid loading of unsupported modules.
Setting allow_unsupported_modules 1 enables loading of unsupported modules
by modprobe, setting allow_unsupported_modules 0 disables it. This can
be overriden using the --allow-unsupported-modules commandline switch.
allow_unsupported_modules 1
linux-bopi:/etc/modprobe.d # cat 00-system.conf
Copyright (c) 1996-2002 SuSE Linux AG Nuernberg, Germany.
All rights reserved.
Author: Hubert Mantel <mantel@suse.de>, 1996-2002
Configuration file for loadable modules; used by modprobe
Please don’t edit this file. Place your settings into
/etc/modprobe.d/99-local.conf instead.
und
linux-bopi:/etc/modprobe.d # cat 99-local.conf
please add local extensions to this file
ich fühl mich wie ein SW-Messi!
das Zeugs heisst inzwischen:
- openSUSE 12.3 Dartmouth, x86_64*]KDE 4.10.00 “release 1”*]Kernel eben 3.16.7-xx
Für jeden Hinweis, Besten Dank
das Vorangehende > war vieles Holzweg
jedoch, anstelle des
- Ordner für 3.16.7xx erstellen in /lib/modules und*]Reinkopieren von Dateien des 3.7.1xx Kernel-Zeugs
fragte ich mich: Weshalb nicht gleich den gesamten “Ordner 3.16.7xx” vom funktionierenden opS13.1 aus dessen “/lib/modules/” holen?
gesagt getan
- kopiere das Zeugs als root, auf gemeinsam (bei opS12.3 sowie opS13.1) eingebundene primäre Partition*]Neustart*]starte opS12.3*]hole von dort und kopiere in das /lib/modules/ Verzeichnis*]Neustart
jetzt startet (boot.log fehlerfrei) zwar noch kein DisplayManager (das kriege ich schon noch hin), hingegen wollte ich wissen-prüfen:
modprobe -l | grep e1000e
YES, loaded!
ich denke, ich habe Glück und der Rest wird mir auch noch gelingen. Selbstverständlich, hätte man [wenn man weiss wie] alles viel einfacher machen können.
openSusi ist einfach geil!
geschafft!
weshalb einfach, wenn es auch kompliziert geht? > Lerneffekt (für mich riesig, fühle mich einiges sicherer)
YaST und YaST2 haben mir kräftig geholfen.
einfacher (insb. bequemer und schneller) wäre wohl gewesen:
- download eine Distri openSUSE 13.1*]spiele persönliche YaST-SysPaketList ein (hat den Effekt, dass zuerst einiges downgraded wird, inkl. Kernel usw.)*]alles wieder upgraden und updaten
Etwas nicht wissen/Unwissenheit bereitet mir kein Problem; hingegen mahnt es mich zur Vorsicht. > safen