Hallo allerseits, so jetzt hab' ich das Problem gelöst (und beim googeln und vorgeschalgenen Lösungen ein neuen Begriff gelernt: "frankensteining", trifft's irgendwie :-) Falls also jemanden mal vergleichbares geschieht: Ursache: - Aus welchen Gründen auch immer wurden die raid1 Devices umbenannt, von /dev/md4 und md2 auf /dev/md126 und md127 - Das aber die initramfs "durcheinandergebracht", die Root-Partition wueder nicht mehr gefunden. Lösung: - Booten in einem Rettungsystem und dann: mount /dev/md126 /mnt; \ mount /dev/md127 /mnt/boot; \ mount --bind /proc /mnt/proc; \ mount --bind /dev /mnt/dev; \ mount -t sysfs sys /mnt/sys; \ chroot /mnt - Mittels lsblk und blkid Die uuid's und Devicenamen der von / und /boot Partionen herausfinden - In /etc/dracut.conf folgendes hinzufügen use_fstab="yes" mdadmconf="yes" persistent_policy="by-uuid" - In /etc/mdadm.conf die Angaben zu den RAID-Arrays korrigieren vorher: ARRAY /dev/md4 level=raid1 num-devices=2 devices=/dev/sda4,/dev/sdb4 # das ist bei mir / ARRAY /dev/md2 level=raid1 num-devices=2 devices=/dev/sda2,/dev/sdb2 # das ist bei mir /boot nachher: ARRAY /dev/md126 level=raid1 num-devices=2 devices=/dev/sda4,/dev/sdb4 ARRAY /dev/md127 level=raid1 num-devices=2 devices=/dev/sda2,/dev/sdb2 - In /etc/fstab die Einträge auf UUID (s. lsblk und blkid) umstellen: UUID=4d0c7398-879a-4e1f-a090-99e1abd9378c / ext4 errors=remount-ro 0 1 UUID=5fb2bd30-4a49-4939-b898-35e229ab9a70 /boot ext3 defaults 0 2 - Dann den Bootloader via yast neu erzeugen. - Prüfen ob in /boot/grub2/grub.cfg die root-Direktive ok ist, also z.B. linux ... root=/dev/md126 .... zu finden ist. Dann booten ... und hoffen .... Danke an die fliessigen (unbekannten) Schreiber von blog-Einträgen und Howtos, die ich gelesen habe .... Bye Jürgen Am Montag, 19. September 2022, 00:06:46 CEST schrieben Sie:

Hallo allerseits,

bei meinem "Problembären" handelt es sich um einen dedicated root-Server bei ionos/iund1.

Nachdem Upgrade von 15.3 auf 15.4 bootet mein System nicht mehr (vollständig)

Der erste Fehler nach der Installation war grub_disk_native_sectors not found booten im rescue system (debian/stable) und Neuinstallation von grup via yast bootete das System. Aber nur bis zu reached target basic system und dann nur noch dracut initqueue timeout suse .... nach einer Weile dann kommt ein root rescue login

Ich sehe allerdings folgendes: Es wird versucht von /dev/md126 zu booten, aber bisher war das / Verzeichnis als /dev/md4 (und boot /dev/md2)

Nun im Rescue-System (also nicht das SuSE-System) sehe ich die raid0 Partitionen als /dev/md126 welches ich auch dann zusammen mit /dev/md127 mounten kann. Dann kann ich chroot in suse 15.4 machen.

In /boot/grub2/grub.cfg finde ich

linux /vmlinuz-5.14.21-150400.22-default root=/dev/md126

Wenn ich das mittel vi auf /dev/md4 ändere ... hilft auch nicht, gleiche Meldungen nun eben mit /dev/md4

Aber grub.cfg wird ja anscheinend erzeugt - aber wo/wie?

Nur wo ändere ich nun in den grub, etc Konfigs so dass die raid0 Devices wieder auf /deb/ms2 bz2 md4 stehen?

journalctl vermeldet noch unknwon kernel command line parameters "domdadm BOOT_IMAGE=/vmlinuz....."

Bin für jeden Tip dankbar

Bye Jürgen

-- Dr.rer.nat. Jürgen Vollmer, Am Rennbuckel 21, D-76185 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de ------------------------------------------------------------------------------- Diese EMail ist elektronisch mittels GPG / PGP signiert. Diese elektronische Unterschrift ist in einem EMail-Anhang enthalten. Leider kann die Signatur ohne die Installation entsprechender Programme weder geprüft noch angezeigt werden. Mehr dazu unter: http://www.gnupg.org oder auch http://www.pgpi.org -------------------------------------------------------------------------------

Am 19.09.22 um 16:06 schrieb Dr. Juergen Vollmer:

Hallo allerseits,

so jetzt hab' ich das Problem gelöst (und beim googeln und vorgeschalgenen Lösungen ein neuen Begriff gelernt: "frankensteining", trifft's irgendwie :-)

Falls also jemanden mal vergleichbares geschieht:

Ursache: - Aus welchen Gründen auch immer wurden die raid1 Devices umbenannt, von /dev/md4 und md2 auf /dev/md126 und md127 - Das aber die initramfs "durcheinandergebracht", die Root-Partition wueder nicht mehr gefunden.

Lösung: - Booten in einem Rettungsystem und dann: (...) Danke an die fliessigen (unbekannten) Schreiber von blog-Einträgen und Howtos, die ich gelesen habe .... ... und meinen Dank an dich das du diese intensiv recherchierte und dokumentierte Lösung hier zur Verfügung stellst. Das kommt in mein HowTo. Ich hätte bei einem solchen Problem ziemlich dumm aus der Wäsche geschaut.

Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.