On Sunday 16 December 2012, 12:32 Dirk Meier
wrote: Hallo Carsten,
wie kann ich überprüfen ob ich eine neue initrd oder udev-Regeln brauche?
Grub ist in der Version 0.97 installiert.
War jetzt erst mal nur 'n Schuss ins Blaue: Neue Hardware -> neue initrd (wenn die Hardware beim Boot benötigt wird und der Treiber in der initrd geladen wird).
Ich hab ja keine Ahnung, wozu du die boot.local brauchst und woran du merkst, dass sie nicht mehr aufgerufen wird. War denn die Hardware-Erweiterung das einzige was seit dem letzten dokumentierten Lauf von boot.local verändert wurde? Hast du vielleicht systemd installiert oder sonstige Software-Änderungen durchgeführt?
Am Samstag, 15. Dezember 2012 schrieb Carsten Neumann:
On Friday 14 December 2012, 15:38 Dirk Meier
wrote: Hallo,
hat funktioniert. Das System läuft wieder.
Allerdings habe ich den Eindruck, dass
die /etc/init.d/boot.local
nicht
mehr aufgerufen wird.
Wie kann denn das sein?
Hallo, Dirk,
vielleicht musst du ja 'ne neue initrd bauen. Siehe: mkinitrd(8) Möglicherweise haben sich ja durch die neuen Geräte u.a. wichtige udev-Regeln verändert.
Gruß,
Carsten
On Tue, 11 Dec 2012 19:39:49 +0100, Dirk Meier
wrote: Hallo,
um eindeutige und dauerhafte Gerätekennungen in der /etc/fstab zu erhalten habe ich bei der Installation den Gerätepfad bei den Einhängeoptionen angegeben, da die Geräte-ID bei meinem RAID-Controller nicht ausgegeben wird. Hat bisher auch reibungslos funktioniert.
Das ist ein Fehler, denn das kann sich ändern, wie Du gemerkt hast. Verwende dafür eindeutige Bezeichner, indem DU einen der Symlinks unter /dev/disk verwendest. Standardmässig verwendet YaST hier /dev/disk/by-id.
Ich denke durch den zus. Controller hat sich der Gerätepfad verschoben.
Je nachdem, was Du als Gerätepfad bezeichnest, ja. Durch den Controller sind die ehemaligen sda sdb geworden oder so ähnlich.
Da mein System nun nicht mehr startet, weiß ich nun nicht wie ich an die neuen Gerätepfade komme. Hat hier jemand eine Idee?
Rettungssystem booten, im Bootlog nachsehen, welche Geräte erkannt wurden. Dann alle Geräte in der korrekten Reihenfolge manuelle mounten (also z.B. das Gerät für / unter /mnt, das für /boot unter /mnt/boot usw.) (das Einhängen von /dev, /sys und /proc in den gerade geschaffenen Dateibaum per bind mount nicht vergessen!) und
Die Hardwareerweiterung war das einzige was nach dem letzten Lauf der boot.local verändert wurde. Allerdings bedingte die Erweiterung, dass /etc/fstab und /boot/grub/menu.lst angepasst werden mussten. Die Festplatten werden mit Pfad angesprochen, daher musste nach der Installation des SAS Controllers die Nummer vom PCI-Device im Pfad der Festplatten um 1 erhöht werden. Das habe ich in /etc/fstab und in /boot/grub/menu.lst gemacht. Danach lief das System wieder, aber die boot.local wird wahrscheinlich ignoriert. Der Systemd läuft, aber auch schon vor der Veränderung. Er ist auch der Grund für die boot.local, da hylafax-Empfang, udrec, und eine hdparm-Einstellung nicht im systemd aktiviert werden. -- Dirk Am Montag, 17. Dezember 2012 schrieb Carsten Neumann: per
chroot
in dieses Dateisystem wechseln. Hier kannst Du nun sowohl /etc/fstab als auch /boot/grub/menu.lst anpassen.
Danach per exit zurück ins normale Dateisystem und alle manuell eingehängten Verzeichnisse aushängen. Beim Neustart sollte dann alles funktionieren.
hth Philipp
Außerdem bin ich mir nicht sicher ob die Änderung in der /etc/fstab ausreicht, oder ob der Gerätepfad der Platten noch an anderer Stelle im System anzupassen ist.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org