Am 19.09.2022 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: 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
Mit diesem Mist werde ich auch schon seit Jahren konfrontiert (Debian 10 aber in diesem Fall) Eigentlich sollte das mdadm Gewürge das automatisch korrigieren, tut es aber nicht. In meiner aktuellen mdadm.conf steht als Device /dev/md/md_data, was wiederum ein Softlink auf /dev/md127 ist. Das sieht ja halbwegs vernünftig aus. Auf nem anderen Debian 10 Server hingegen sieht's voll chaotisch aus. Wie der da überhaupt das Raid zusammenbekommt ist mir ein völliges Rätsel Beide Server sind hier übrigens vollverschlüsselt Manfred