mkinitrd, grub2 und neuer Kernel
Hallo, seit dem letzten Kernel-Update funktioniert mkinitrd nicht mehr richtig. Hier läuft eine openSUSE 12.3 mit den üblichen Repositories (oss, non-oss, packman, samba, source, update, update non-oss). Aktuell installiert sind die Kernel-Versionen 3.7.10-1.24-desktop und 3.7.10-1.28-desktop. Seit der Installation, erhalte ich beim/während des Ausführend von mkinitrd folgende Fehlermeldung(en): mkinitrd Kernel image: /boot/vmlinuz-3.7.10-1.24-desktop Initrd image: /boot/initrd-3.7.10-1.24-desktop Root device: /dev/disk/by-id/raid-pdc_fjjhaaib-part7 (/dev/dm-4) (mounted on / as ext4) Resume device: /dev/disk/by-id/raid-pdc_fjjhaaib-part6 (/dev/dm-3) Kernel Modules: thermal_sys thermal processor fan dm-mod dm-snapshot dm-log dm-region-hash dm-mirror scsi_dh scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh_alua xhci-hcd hid-logitech-dj Features: acpi dm block usb dmraid kpartx resume.userspace resume.kernel Kernel image: /boot/vmlinuz-3.7.10-1.28-desktop Initrd image: /boot/initrd-3.7.10-1.28-desktop Root device: /dev/disk/by-id/raid-pdc_fjjhaaib-part7 (/dev/dm-4) (mounted on / as ext4) Resume device: /dev/disk/by-id/raid-pdc_fjjhaaib-part6 (/dev/dm-3) Kernel Modules: thermal_sys thermal processor fan dm-mod dm-snapshot dm-log dm-region-hash dm-mirror scsi_dh scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh_alua xhci-hcd hid-logitech-dj Features: acpi dm block usb dmraid kpartx resume.userspace resume.kernel Perl-Bootloader: 2014-02-12 23:35:54 <3> pbl-0986.2 Core::RunCommand.1642: Error: Command '/usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe "(hd0)" >/var/log/YaST2 /y2log_bootloader 2>&1' failed with code 256 and output: Path `/boot/grub2' is not readable by GRUB on boot. Installation is impossible. Aborting. There was an error generating the initrd (1) Ich habe deshalb mit zypper rm --clean-deps zunächst die 4 Pakete für 3.7.10-1.28 deinstalliert. Danach erschien derselbe Fehler bei mkinitrd dann auch für den Kernel 3.7.10-1.24. Nach der Neuinstallation wird die Meldung wieder "nur" für 3.7.10-1.28 ausgegeben. Ich habe dann gesehen, dass offensichtlich auch grub2 aktualisiert wurde am Sonntag: rpm -qa --last grub\* grub2-efi-2.00-19.31.1.x86_64 Sun Feb 9 18:50:44 2014 grub2-2.00-19.31.1.x86_64 Sun Feb 9 18:50:40 2014 grub2-i386-pc-2.00-19.31.1.x86_64 Sun Feb 9 18:50:38 2014 grub2-x86_64-efi-2.00-19.31.1.x86_64 Sun Feb 9 18:47:59 2014 grub2-branding-openSUSE-12.3-6.38.1.noarch Thu Jul 18 13:54:43 2013 grub-0.97-188.1.1.x86_64 Tue Mar 19 20:52:51 2013 Ich traue mich nicht, das System neu zu starten, weil ich befürchte, es fährt nicht mehr hoch. Aus diesem Grund möchte ich auch nicht ohne weiteres grub2 von Hand installieren. Ich frage mich sowieso, warum das neu installiert werden muss bei einem Kernel-Update. Wo kann ich nach der Ursache suchen? Gruß, Alex -- 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
Hallo, On 12.02.2014 23:55, Alex Winzer wrote:
Hallo,
seit dem letzten Kernel-Update funktioniert mkinitrd nicht mehr richtig. Hier läuft eine openSUSE 12.3 mit den üblichen Repositories (oss, non-oss, packman, samba, source, update, update non-oss). Aktuell installiert sind die Kernel-Versionen 3.7.10-1.24-desktop und 3.7.10-1.28-desktop.
Seit der Installation, erhalte ich beim/während des Ausführend von mkinitrd folgende Fehlermeldung(en):
[...]
Perl-Bootloader: 2014-02-12 23:35:54 <3> pbl-0986.2 Core::RunCommand.1642: Error: Command '/usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe "(hd0)" >/var/log/YaST2 /y2log_bootloader 2>&1' failed with code 256 and output: Path `/boot/grub2' is not readable by GRUB on boot. Installation is impossible. Aborting.
There was an error generating the initrd (1)
[...]
Ich traue mich nicht, das System neu zu starten, weil ich befürchte, es fährt nicht mehr hoch. Aus diesem Grund möchte ich auch nicht ohne weiteres grub2 von Hand installieren. Ich frage mich sowieso, warum das neu installiert werden muss bei einem Kernel-Update.
Das Problem ist für mich ziemlich dringend. Da scheinbar keiner eine Antwort parat hat, habe ich jetzt einen Bugreport aufgemacht. Der Vollständigkeit der Liste halber, ist hier[1] der Link. Gruß, Alex [1] https://bugzilla.novell.com/show_bug.cgi?id=863851 -- 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
Am 13.02.2014 18:32, schrieb Alex Winzer:
Hallo,
On 12.02.2014 23:55, Alex Winzer wrote:
Hallo,
seit dem letzten Kernel-Update funktioniert mkinitrd nicht mehr richtig. Hier läuft eine openSUSE 12.3 mit den üblichen Repositories (oss, non-oss, packman, samba, source, update, update non-oss). Aktuell installiert sind die Kernel-Versionen 3.7.10-1.24-desktop und 3.7.10-1.28-desktop.
Seit der Installation, erhalte ich beim/während des Ausführend von mkinitrd folgende Fehlermeldung(en):
[...]
Perl-Bootloader: 2014-02-12 23:35:54 <3> pbl-0986.2 Core::RunCommand.1642: Error: Command '/usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe "(hd0)" >/var/log/YaST2 /y2log_bootloader 2>&1' failed with code 256 and output: Path `/boot/grub2' is not readable by GRUB on boot. Installation is impossible. Aborting.
There was an error generating the initrd (1)
[...]
Ich traue mich nicht, das System neu zu starten, weil ich befürchte, es fährt nicht mehr hoch. Aus diesem Grund möchte ich auch nicht ohne weiteres grub2 von Hand installieren. Ich frage mich sowieso, warum das neu installiert werden muss bei einem Kernel-Update.
Das Problem ist für mich ziemlich dringend. Da scheinbar keiner eine Antwort parat hat, habe ich jetzt einen Bugreport aufgemacht. Der Vollständigkeit der Liste halber, ist hier[1] der Link.
Gruß, Alex
Hallo Alex, man muss sich schon mindestens 24 Stunden auf eine Antwort gedulden, denn die Hilfestellung kommt sehr oft von freiwilligen Menschen aus der openSUSE-Community. Diese haben neben ihrem Privatleben auch ein Berufsleben. :-) Also, keine Panik, im Zweifel den Rechner einfach so lange weiter laufen lassen, bis eine angemessene Lösung kommt. Nun zu deinem Problem: Kannst du bitte etwas --verbose bzgl. Festplattenpartitionierung und dessen Größe beschreiben? Folgende Ausgaben wären interessant: # fdisk -l # df -h -- Gruß Sebastian - openSUSE Member (Freespacer) Webseite/Blog: http://www.sebastian-siebert.de Wichtiger Hinweis zur openSUSE Mailing Liste: http://de.opensuse.org/openSUSE:Mailinglisten_Netiquette -- 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
Hallo Sebastian, On 13.02.14 21:34, Sebastian Siebert wrote:
Am 13.02.2014 18:32, schrieb Alex Winzer:
Hallo, On 12.02.2014 23:55, Alex Winzer wrote:
Hallo,
[...]
Seit der Installation, erhalte ich beim/während des Ausführend von mkinitrd folgende Fehlermeldung(en):
[...]
Perl-Bootloader: 2014-02-12 23:35:54 <3> pbl-0986.2 Core::RunCommand.1642: Error: Command '/usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe "(hd0)" >/var/log/YaST2 /y2log_bootloader 2>&1' failed with code 256 and output: Path `/boot/grub2' is not readable by GRUB on boot. Installation is impossible. Aborting.
There was an error generating the initrd (1)
[...]
Das Problem ist für mich ziemlich dringend. Da scheinbar keiner eine Antwort parat hat, habe ich jetzt einen Bugreport aufgemacht. Der Vollständigkeit der Liste halber, ist hier[1] der Link.
Gruß, Alex
Hallo Alex,
man muss sich schon mindestens 24 Stunden auf eine Antwort gedulden,
Ja. Ich muss mich entschuldigen. Es fehlten noch 5,5 Stunden. Ich hatte aber ehrlich gesagt eigentlich kaum mehr mit einer Antwort gerechnet. Aus diesem Grunde habe ich auch nicht die Frage wiederholt oder eine neue aufgeworfen, sondern lediglich mir selbst geantwortet. Ich dachte, dass wäre OK. Offensichtlich habe ich mich damit verdacht.
denn die Hilfestellung kommt sehr oft von freiwilligen Menschen aus der openSUSE-Community. Diese haben neben ihrem Privatleben auch ein Berufsleben. :-)
Hier auch. Ich bin tagsüber RA, hatte dann aber Feierabend und das Problem wieder am Hals.
Also, keine Panik, im Zweifel den Rechner einfach so lange weiter laufen lassen, bis eine angemessene Lösung kommt.
Dass wird er hoffentlich tun. Wenn er mir abschmiert, habe ich erstmal ein Problem.
Nun zu deinem Problem: Kannst du bitte etwas --verbose bzgl. Festplattenpartitionierung und dessen Größe beschreiben?
Onboard-RAID oder fake-RAID, wie das auf Neudeutsch genannt wird. Damit hatte ich aber seit openSUSE 10.1 nie Probleme - ich schwöre! /, /boot und /home liegen jeweils auf separaten Partitionen. Dann der Rest als LVM und das wiederum in 3 Partitionen aufgeteilt.
Folgende Ausgaben wären interessant:
# fdisk -l
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00035827 Device Boot Start End Blocks Id System /dev/sda1 * 2048 1953124351 976561152 f W95 Ext'd (LBA) /dev/sda5 4096 354303 175104 83 Linux /dev/sda6 356352 4546559 2095104 82 Linux swap / Solaris /dev/sda7 4548608 56983551 26217472 83 Linux /dev/sda8 56985600 214274047 78644224 83 Linux /dev/sda9 214276096 1953101823 869412864 8e Linux LVM Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00035827 Device Boot Start End Blocks Id System /dev/sdb1 * 2048 1953124351 976561152 f W95 Ext'd (LBA) /dev/sdb5 4096 354303 175104 83 Linux /dev/sdb6 356352 4546559 2095104 82 Linux swap / Solaris /dev/sdb7 4548608 56983551 26217472 83 Linux /dev/sdb8 56985600 214274047 78644224 83 Linux /dev/sdb9 214276096 1953101823 869412864 8e Linux LVM Disk /dev/mapper/pdc_fjjhaaib: 1000.0 GB, 999999995904 bytes 255 heads, 63 sectors/track, 121576 cylinders, total 1953124992 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00035827 Device Boot Start End Blocks Id System /dev/mapper/pdc_fjjhaaib1 * 2048 1953124351 976561152 f W95 Ext'd (LBA) /dev/mapper/pdc_fjjhaaib5 4096 354303 175104 83 Linux /dev/mapper/pdc_fjjhaaib6 356352 4546559 2095104 82 Linux swap / Solaris /dev/mapper/pdc_fjjhaaib7 4548608 56983551 26217472 83 Linux /dev/mapper/pdc_fjjhaaib8 56985600 214274047 78644224 83 Linux /dev/mapper/pdc_fjjhaaib9 214276096 1953101823 869412864 8e Linux LVM
# df -h
Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 3.9G 40K 3.9G 1% /dev tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs tmpfs 3.9G 904K 3.9G 1% /run /dev/mapper/pdc_fjjhaaib-part7 ext4 25G 15G 8.6G 64% / tmpfs tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup tmpfs tmpfs 3.9G 904K 3.9G 1% /var/lock tmpfs tmpfs 3.9G 904K 3.9G 1% /var/run /dev/mapper/pdc_fjjhaaib-part5 ext4 166M 68M 90M 44% /boot /dev/mapper/pdc_fjjhaaib-part8 ext4 74G 46G 26G 65% /home /dev/mapper/Daten-EAkten ext4 376G 88G 269G 25% /home/EAkten /dev/mapper/Daten-Dateien ext4 65G 19G 43G 31% /home/Dateien /dev/mapper/Daten-Privat ext4 376G 274G 84G 77% /home/Privat Wenn ich am Wochenende an den Rechner selbst rankomme, schaue ich im Backup nach, was so in /boot und darunter, sowie bei /etc/sysconfig/bootloader steht. Ich gehe davon aus, dass es auch ein Problem mit grub ist. Ich denke, dass Linux sehr sauber mit den Ausgaben arbeitet. Und wenn dann von "grub" und _nicht_ von "grub2" die Rede ist, wird es hoffentlich auch nur grub(0.97) betreffen. Ich frage mich sowieso, warum beides installiert ist; so sagt es jedenfalls "rpm -qa --last | grep -i grub\*" Gruß, Alex P.S. Wegen der bösen Zeilenumbrüch habe ich die Ausgaben mal als Dateien angehängt.
Hallo Alex, Am 13.02.2014 22:43, schrieb Alex Winzer:
On 13.02.14 21:34, Sebastian Siebert wrote: [...]
Nun zu deinem Problem: Kannst du bitte etwas --verbose bzgl. Festplattenpartitionierung und dessen Größe beschreiben?
Onboard-RAID oder fake-RAID, wie das auf Neudeutsch genannt wird. Damit hatte ich aber seit openSUSE 10.1 nie Probleme - ich schwöre! /, /boot und /home liegen jeweils auf separaten Partitionen. Dann der Rest als LVM und das wiederum in 3 Partitionen aufgeteilt.
Folgende Ausgaben wären interessant:
# fdisk -l [...] Disk /dev/mapper/pdc_fjjhaaib: 1000.0 GB, 999999995904 bytes 255 heads, 63 sectors/track, 121576 cylinders, total 1953124992 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00035827
Device Boot Start End Blocks Id System /dev/mapper/pdc_fjjhaaib1 * 2048 1953124351 976561152 f W95 Ext'd (LBA) /dev/mapper/pdc_fjjhaaib5 4096 354303 175104 83 Linux /dev/mapper/pdc_fjjhaaib6 356352 4546559 2095104 82 Linux swap / Solaris /dev/mapper/pdc_fjjhaaib7 4548608 56983551 26217472 83 Linux /dev/mapper/pdc_fjjhaaib8 56985600 214274047 78644224 83 Linux /dev/mapper/pdc_fjjhaaib9 214276096 1953101823 869412864 8e Linux LVM
# df -h
Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 3.9G 40K 3.9G 1% /dev tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs tmpfs 3.9G 904K 3.9G 1% /run /dev/mapper/pdc_fjjhaaib-part7 ext4 25G 15G 8.6G 64% / tmpfs tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup tmpfs tmpfs 3.9G 904K 3.9G 1% /var/lock tmpfs tmpfs 3.9G 904K 3.9G 1% /var/run /dev/mapper/pdc_fjjhaaib-part5 ext4 166M 68M 90M 44% /boot /dev/mapper/pdc_fjjhaaib-part8 ext4 74G 46G 26G 65% /home /dev/mapper/Daten-EAkten ext4 376G 88G 269G 25% /home/EAkten /dev/mapper/Daten-Dateien ext4 65G 19G 43G 31% /home/Dateien /dev/mapper/Daten-Privat ext4 376G 274G 84G 77% /home/Privat
Wenn ich am Wochenende an den Rechner selbst rankomme, schaue ich im Backup nach, was so in /boot und darunter, sowie bei /etc/sysconfig/bootloader steht. Ich gehe davon aus, dass es auch ein Problem mit grub ist. Ich denke, dass Linux sehr sauber mit den Ausgaben arbeitet. Und wenn dann von "grub" und _nicht_ von "grub2" die Rede ist, wird es hoffentlich auch nur grub(0.97) betreffen. Ich frage mich sowieso, warum beides installiert ist; so sagt es jedenfalls "rpm -qa --last | grep -i grub\*"
Wenn grub und grub2 nebenher installiert ist, kommen sich beide trotzdem nicht ins Gehege. Da in der Konfiguration /etc/sysconfig/bootloader der Wert in LOADER_TYPE eine entscheidende Rolle spielt. Bei dir ist offensichtlich "grub2" eingestellt, aus der Annahme aus deiner vorhergehenden Fehlermeldung. Jetzt benötige ich noch 3 weitere Sachen von dir, um meinen Verdacht zu untermauern. Ich brauche einmal folgende Ausgabe: # cat /etc/fstab # mount # ll /boot -- Gruß Sebastian - openSUSE Member (Freespacer) Webseite/Blog: http://www.sebastian-siebert.de Wichtiger Hinweis zur openSUSE Mailing Liste: http://de.opensuse.org/openSUSE:Mailinglisten_Netiquette -- 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
Hallo Sebastian, Danke erstmal für Deine Mühen! On 13.02.14 23:50, Sebastian Siebert wrote:
Hallo Alex,
Am 13.02.2014 22:43, schrieb Alex Winzer:
On 13.02.14 21:34, Sebastian Siebert wrote: [...]
Nun zu deinem Problem: Kannst du bitte etwas --verbose bzgl. Festplattenpartitionierung und dessen Größe beschreiben?
Onboard-RAID oder fake-RAID, wie das auf Neudeutsch genannt wird. Damit hatte ich aber seit openSUSE 10.1 nie Probleme - ich schwöre! /, /boot und /home liegen jeweils auf separaten Partitionen. Dann der Rest als LVM und das wiederum in 3 Partitionen aufgeteilt.
Folgende Ausgaben wären interessant:
# fdisk -l [...] Disk /dev/mapper/pdc_fjjhaaib: 1000.0 GB, 999999995904 bytes 255 heads, 63 sectors/track, 121576 cylinders, total 1953124992 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00035827
Device Boot Start End Blocks Id System /dev/mapper/pdc_fjjhaaib1 * 2048 1953124351 976561152 f W95 Ext'd (LBA) /dev/mapper/pdc_fjjhaaib5 4096 354303 175104 83 Linux /dev/mapper/pdc_fjjhaaib6 356352 4546559 2095104 82 Linux swap / Solaris /dev/mapper/pdc_fjjhaaib7 4548608 56983551 26217472 83 Linux /dev/mapper/pdc_fjjhaaib8 56985600 214274047 78644224 83 Linux /dev/mapper/pdc_fjjhaaib9 214276096 1953101823 869412864 8e Linux LVM
# df -h
Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 3.9G 40K 3.9G 1% /dev tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs tmpfs 3.9G 904K 3.9G 1% /run /dev/mapper/pdc_fjjhaaib-part7 ext4 25G 15G 8.6G 64% / tmpfs tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup tmpfs tmpfs 3.9G 904K 3.9G 1% /var/lock tmpfs tmpfs 3.9G 904K 3.9G 1% /var/run /dev/mapper/pdc_fjjhaaib-part5 ext4 166M 68M 90M 44% /boot /dev/mapper/pdc_fjjhaaib-part8 ext4 74G 46G 26G 65% /home /dev/mapper/Daten-EAkten ext4 376G 88G 269G 25% /home/EAkten /dev/mapper/Daten-Dateien ext4 65G 19G 43G 31% /home/Dateien /dev/mapper/Daten-Privat ext4 376G 274G 84G 77% /home/Privat
Wenn ich am Wochenende an den Rechner selbst rankomme, schaue ich im Backup nach, was so in /boot und darunter, sowie bei /etc/sysconfig/bootloader steht. Ich gehe davon aus, dass es auch ein Problem mit grub ist. Ich denke, dass Linux sehr sauber mit den Ausgaben arbeitet. Und wenn dann von "grub" und _nicht_ von "grub2" die Rede ist, wird es hoffentlich auch nur grub(0.97) betreffen. Ich frage mich sowieso, warum beides installiert ist; so sagt es jedenfalls "rpm -qa --last | grep -i grub\*"
Wenn grub und grub2 nebenher installiert ist, kommen sich beide trotzdem nicht ins Gehege.
Ok. Wieder was dazugelernt. Aber warum werden beide zusammen installiert? Hat das irgend einen Sinn - außer den Benutzer zu verunsichern?
Da in der Konfiguration /etc/sysconfig/bootloader der Wert in LOADER_TYPE eine entscheidende Rolle spielt. Bei dir ist offensichtlich "grub2" eingestellt, aus der Annahme aus deiner vorhergehenden Fehlermeldung.
Diese Annahme stimmt.
Jetzt benötige ich noch 3 weitere Sachen von dir, um meinen Verdacht zu untermauern.
"Verdacht" hört sich vielversprechend an und macht mich - weil Du nichts Konkreteres schreibst - auch neugierig.
Ich brauche einmal folgende Ausgabe:
# cat /etc/fstab Kommt sofort:
#/dev/disk/by-id/raid-pdc_fjjhaaib-part6 swap swap defaults 0 0 /dev/disk/by-id/raid-pdc_fjjhaaib-part7 / ext4 acl,user_xattr 1 1 /dev/disk/by-id/raid-pdc_fjjhaaib-part5 /boot ext4 acl,user_xattr 1 2 /dev/disk/by-id/raid-pdc_fjjhaaib-part8 /home ext4 acl,user_xattr 1 2 /dev/Daten/Dateien /home/Dateien ext4 acl,user_xattr 1 2 /dev/Daten/EAkten /home/EAkten ext4 acl,user_xattr 1 2 /dev/Daten/Privat /home/Privat ext4 acl,user_xattr 1 2 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0
# mount
devtmpfs on /dev type devtmpfs (rw,relatime,size=3996424k,nr_inodes=999106,mode=755) tmpfs on /dev/shm type tmpfs (rw,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000) /dev/mapper/pdc_fjjhaaib-part7 on / type ext4 (rw,relatime,data=ordered) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) mqueue on /dev/mqueue type mqueue (rw,relatime) tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,relatime,mode=755) debugfs on /sys/kernel/debug type debugfs (rw,relatime) tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755) /dev/mapper/pdc_fjjhaaib-part5 on /boot type ext4 (rw,relatime,data=ordered) /dev/mapper/pdc_fjjhaaib-part8 on /home type ext4 (rw,relatime,data=ordered) /dev/mapper/Daten-EAkten on /home/EAkten type ext4 (rw,relatime,data=ordered) /dev/mapper/Daten-Dateien on /home/Dateien type ext4 (rw,relatime,data=ordered) /dev/mapper/Daten-Privat on /home/Privat type ext4 (rw,relatime,data=ordered) nfsd on /proc/fs/nfsd type nfsd (rw,relatime) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) none on /var/lib/ntp/proc type proc (ro,nosuid,nodev,relatime)
# ll /boot
total 54378 -rw-r--r-- 1 root root 2531960 Dec 5 10:44 System.map-3.7.10-1.24-desktop -rw-r--r-- 1 root root 2532218 Feb 4 00:04 System.map-3.7.10-1.28-desktop -rw------- 1 root root 512 Dec 21 2012 backup_mbr lrwxrwxrwx 1 root root 1 Mar 19 2013 boot -> . -rw-r--r-- 1 root root 1484 Feb 26 2013 boot.readme -rw-r--r-- 1 root root 136097 Dec 5 09:40 config-3.7.10-1.24-desktop -rw-r--r-- 1 root root 136097 Feb 3 22:49 config-3.7.10-1.28-desktop -rw-r--r-- 1 root root 0 Feb 12 23:34 do_purge_kernels drwxr-xr-x 2 root root 1024 Mar 19 2013 grub drwxr-xr-x 7 root root 1024 Feb 13 15:02 grub2 lrwxrwxrwx 1 root root 5 Mar 19 2013 grub2-efi -> grub2 lrwxrwxrwx 1 root root 26 Feb 13 18:12 initrd -> initrd-3.7.10-1.28-desktop -rw------- 1 root root 13012336 Feb 13 18:12 initrd-3.7.10-1.24-desktop -rw------- 1 root root 13011631 Feb 13 18:12 initrd-3.7.10-1.28-desktop drwx------ 2 root root 12288 Dec 21 2012 lost+found -rw-r--r-- 1 root root 176760 Jan 28 2013 memtest.bin -rw-r--r-- 1 root root 621056 Dec 15 15:40 message -rw-r--r-- 1 root root 691683 Dec 5 11:09 symtypes-3.7.10-1.24-desktop.gz -rw-r--r-- 1 root root 691701 Feb 4 00:28 symtypes-3.7.10-1.28-desktop.gz -rw-r--r-- 1 root root 241475 Dec 5 10:59 symvers-3.7.10-1.24-desktop.gz -rw-r--r-- 1 root root 241500 Feb 4 00:21 symvers-3.7.10-1.28-desktop.gz -rw-r--r-- 1 root root 516 Dec 5 10:59 sysctl.conf-3.7.10-1.24-desktop -rw-r--r-- 1 root root 516 Feb 4 00:21 sysctl.conf-3.7.10-1.28-desktop -rw-r--r-- 1 root root 5815992 Dec 5 10:58 vmlinux-3.7.10-1.24-desktop.gz -rw-r--r-- 1 root root 5815569 Feb 4 00:20 vmlinux-3.7.10-1.28-desktop.gz lrwxrwxrwx 1 root root 27 Feb 12 23:34 vmlinuz -> vmlinuz-3.7.10-1.28-desktop -rw-r--r-- 1 root root 5000568 Dec 5 12:22 vmlinuz-3.7.10-1.24-desktop -rw-r--r-- 1 root root 5000376 Feb 4 02:05 vmlinuz-3.7.10-1.28-desktop Und auch hier wie beim letzten Mal alles als Anhang. Gruß, Alex
Am 14.02.2014 08:19, schrieb Alex Winzer:
On 13.02.14 23:50, Sebastian Siebert wrote: [...]
Wenn grub und grub2 nebenher installiert ist, kommen sich beide trotzdem nicht ins Gehege.
Ok. Wieder was dazugelernt. Aber warum werden beide zusammen installiert? Hat das irgend einen Sinn - außer den Benutzer zu verunsichern?
Tja, das ist die Freiheit den gewünschten Bootloader zu wählen. :-)
Da in der Konfiguration /etc/sysconfig/bootloader der Wert in LOADER_TYPE eine entscheidende Rolle spielt. Bei dir ist offensichtlich "grub2" eingestellt, aus der Annahme aus deiner vorhergehenden Fehlermeldung.
Diese Annahme stimmt.
Jut.
Jetzt benötige ich noch 3 weitere Sachen von dir, um meinen Verdacht zu untermauern.
"Verdacht" hört sich vielversprechend an und macht mich - weil Du nichts Konkreteres schreibst - auch neugierig.
Mein Verdacht war gewesen, dass sich die Boot-Partition zum jetzigen Zeitpunkt nicht gemountet war. Was sich anhand deiner gelieferten Angaben nicht bestätigt.
Ich brauche einmal folgende Ausgabe:
# cat /etc/fstab [...] /dev/disk/by-id/raid-pdc_fjjhaaib-part5 /boot ext4 acl,user_xattr 1 2 [...] # mount [...] /dev/mapper/pdc_fjjhaaib-part5 on /boot type ext4 (rw,relatime,data=ordered) [...] # ll /boot [...]
Der Rest sieht gut aus. Eines macht mich schon stutzig. Du sagtest doch, dass du LVM nutzt. In den Ausgaben sehe ich nichts, was irgendwie nach einem LVM-mapper aussieht, sondern eher nur den Device-Mapper vom fake-Raid. # pvdisplay -v # vgdisplay -v # lvdisplay -v Zurück zum eigentlichen Problem: Eine andere Idee wäre es, wenn du die aktuellen grub2-Pakete reinstallierst und danach nochmal mkinitrd wie folgt ausführst: # mkinitrd -v Sollte wieder die besagte Fehlermeldung kommen, dann bitte auch nochmal die Logdatei /var/log/YaST2/y2log_bootloader zeigen. Wo ist der Bootloader-Code installiert worden? # grep LOADER_LOCATION /etc/sysconfig/bootloader # cat /boot/grub2/device.map -- Gruß Sebastian - openSUSE Member (Freespacer) Webseite/Blog: http://www.sebastian-siebert.de Wichtiger Hinweis zur openSUSE Mailing Liste: http://de.opensuse.org/openSUSE:Mailinglisten_Netiquette -- 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
Am 14.02.2014 21:31, schrieb Sebastian Siebert:
Am 14.02.2014 08:19, schrieb Alex Winzer:
On 13.02.14 23:50, Sebastian Siebert wrote: [...] Zurück zum eigentlichen Problem: Eine andere Idee wäre es, wenn du die aktuellen grub2-Pakete reinstallierst und danach nochmal mkinitrd wie folgt ausführst:
# mkinitrd -v
Sollte wieder die besagte Fehlermeldung kommen, dann bitte auch nochmal die Logdatei /var/log/YaST2/y2log_bootloader zeigen.
Wo ist der Bootloader-Code installiert worden?
# grep LOADER_LOCATION /etc/sysconfig/bootloader
# cat /boot/grub2/device.map
Noch was vergessen: Wie ist der Zustand deines fake-RAID? # dmraid -r -- Gruß Sebastian - openSUSE Member (Freespacer) Webseite/Blog: http://www.sebastian-siebert.de Wichtiger Hinweis zur openSUSE Mailing Liste: http://de.opensuse.org/openSUSE:Mailinglisten_Netiquette -- 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
On 14.02.14 22:34, Sebastian Siebert wrote:
Am 14.02.2014 21:31, schrieb Sebastian Siebert:
Am 14.02.2014 08:19, schrieb Alex Winzer:
On 13.02.14 23:50, Sebastian Siebert wrote: [...]
Noch was vergessen:
Wie ist der Zustand deines fake-RAID?
# dmraid -r
Ich wollte eigentlich noch dran denken und eine E-Mail daraus basteln. Aber so geht es den Menschen wie den Leuten: Beim Hochfahren hat er mir im BIOS erzählt, das RAID wäre vollständig intakt. Ich habe auch kein RAID über das Betriebssystem. Daher dürfte dmraid nicht wirklich sinnvolles ausgeben, oder? computer:/ # dmraid -r ERROR: ddf1: seeking device "/dev/dm-1" to 18446744073709421056 ERROR: hpt37x: seeking device "/dev/dm-1" to 4608 ERROR: hpt45x: seeking device "/dev/dm-1" to 18446744073709547008 ERROR: pdc: seeking device "/dev/dm-1" to 137438913024 ERROR: pdc: seeking device "/dev/dm-1" to 137438920192 ERROR: pdc: seeking device "/dev/dm-1" to 137438927360 ERROR: pdc: seeking device "/dev/dm-1" to 137438934528 ERROR: sil: seeking device "/dev/dm-1" to 18446744073709289984 /dev/sdb: pdc, "pdc_fjjhaaib", mirror, ok, 1953124992 sectors, data@ 0 /dev/sda: pdc, "pdc_fjjhaaib", mirror, ok, 1953124992 sectors, data@ 0 Mit den ersten Fehlern kann ich nichts anfangen. Aber am Ende steht im Grunde das, was mir das BIOS schon gesagt hatte: alles soweit OK. Ich weiß auch nicht, was dort bis letzte Woche gestanden hätte... -- 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
On 14.02.14 21:31, Sebastian Siebert wrote:
Am 14.02.2014 08:19, schrieb Alex Winzer:
On 13.02.14 23:50, Sebastian Siebert wrote: [...]
Wenn grub und grub2 nebenher installiert ist, kommen sich beide trotzdem nicht ins Gehege.
Ok. Wieder was dazugelernt. Aber warum werden beide zusammen installiert? Hat das irgend einen Sinn - außer den Benutzer zu verunsichern?
Tja, das ist die Freiheit den gewünschten Bootloader zu wählen. :-)
Freiheit finde ich sehr gut! Problematisch wird es aber, wenn nicht nur 2 Bootloader parallel installiert sind, sondern (sich) nacheinander starten. Das Problem hatte ich schonmal mit (m)einem Laptop.
[...]
Jetzt benötige ich noch 3 weitere Sachen von dir, um meinen Verdacht zu untermauern.
"Verdacht" hört sich vielversprechend an und macht mich - weil Du nichts Konkreteres schreibst - auch neugierig.
Mein Verdacht war gewesen, dass sich die Boot-Partition zum jetzigen Zeitpunkt nicht gemountet war. Was sich anhand deiner gelieferten Angaben nicht bestätigt.
Das wäre auch meine erste Vermutung gewesen.
Ich brauche einmal folgende Ausgabe:
# cat /etc/fstab [...] /dev/disk/by-id/raid-pdc_fjjhaaib-part5 /boot ext4 acl,user_xattr 1 2 [...] # mount [...] /dev/mapper/pdc_fjjhaaib-part5 on /boot type ext4 (rw,relatime,data=ordered) [...] # ll /boot [...]
Der Rest sieht gut aus. Eines macht mich schon stutzig. Du sagtest doch, dass du LVM nutzt. In den Ausgaben sehe ich nichts, was irgendwie nach einem LVM-mapper aussieht, sondern eher nur den Device-Mapper vom fake-Raid.
Doch, sieht man - wenn man die LVM-Bezeichnung kennt :-) Mein LVM heißt "Daten" und die Volumes heißen "EAkten", "Dateien" und "Privat". Und man sieht sie bei "df -h" z.B. als "/dev/mapper/Daten-EAkten"
# pvdisplay -v # vgdisplay -v # lvdisplay -v
Zurück zum eigentlichen Problem: Eine andere Idee wäre es, wenn du die aktuellen grub2-Pakete reinstallierst und danach nochmal mkinitrd wie folgt ausführst:
Wie mache ich das? So: "zypper in --force grub2-efi-2.00-19.31.1.x86_64 grub2-2.00-19.31.1.x86_64 grub2-i386-pc-2.00-19.31.1.x86_64 grub2-x86_64-efi-2.00-19.31.1.x86_64 grub2-branding-openSUSE-12.3-6.38.1.noarch" Wie reinstalliere auch die Abhängigkeiten neu? Nur für den Fall, dass die Fehler daher kamen.
# mkinitrd -v
Sollte wieder die besagte Fehlermeldung kommen, dann bitte auch nochmal die Logdatei /var/log/YaST2/y2log_bootloader zeigen.
Wo ist der Bootloader-Code installiert worden?
# grep LOADER_LOCATION /etc/sysconfig/bootloader
computer:/ # grep LOADER_LOCATION /etc/sysconfig/bootloader LOADER_LOCATION="" Der sollte eigentlich im MBR sein. So hatte ich es jedenfalls vor über einem Jahr bei der Installation - damals noch 12.2. Sollte also dort evtl. "MBR" oder sowas statt "" stehen?
# cat /boot/grub2/device.map computer:/ # cat /boot/grub2/device.map (hd0) /dev/disk/by-id/raid-pdc_fjjhaaib
Das sieht übrigens exakt genauso aus, wie in meinem Backup von vor 2,3,4 usw. Wochen. Nebenbei: Der Rechner war mir am Freitag wegen einer problematischen HDD (USB2, extern) abgeschmiert. Ich bin 3 Tode gestorben, aber der Rechner fuhr Gott sei Dank wieder hoch. Wenn ich weiß, wie ich grub2 (vollständig) neu installiere, dann probiere, dann melde ich mich wieder. Danke erstmal auch für die Geduld. Gruß, Alex -- 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
On 16.02.14 20:08, Alex Winzer wrote:
On 14.02.14 21:31, Sebastian Siebert wrote:
Am 14.02.2014 08:19, schrieb Alex Winzer:
On 13.02.14 23:50, Sebastian Siebert wrote:
[...] Zurück zum eigentlichen Problem: Eine andere Idee wäre es, wenn du die aktuellen grub2-Pakete reinstallierst und danach nochmal mkinitrd wie folgt ausführst:
Wie mache ich das? So: "zypper in --force grub2-efi-2.00-19.31.1.x86_64 grub2-2.00-19.31.1.x86_64 grub2-i386-pc-2.00-19.31.1.x86_64 grub2-x86_64-efi-2.00-19.31.1.x86_64 grub2-branding-openSUSE-12.3-6.38.1.noarch"
Also das bringt mir gleich dieselbe Fehlermeldung wie folgt: [...] Retrieving package grub2-efi-2.00-19.31.1.x86_64 (4/4), 19.1 KiB ( 878 B unpacked) Retrieving: grub2-efi-2.00-19.31.1.x86_64.rpm ..................................................................[done] (1/4) Installing: grub2-i386-pc-2.00-19.31.1 ..................................................................[done] (2/4) Installing: grub2-x86_64-efi-2.00-19.31.1 ..................................................................[done] (3/4) Installing: grub2-2.00-19.31.1 ..................................................................[done] Additional rpm output: Perl-Bootloader: 2014-02-16 21:30:53 <3> pbl-1379.2 Core::RunCommand.1642: Error: Command '/usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe "(hd0)"
/var/log/YaST2/y2log_bootloader 2>&1' failed with code 256 and output: Path `/boot/grub2' is not readable by GRUB on boot. Installation is impossible. Aborting.
(4/4) Installing: grub2-efi-2.00-19.31.1 ..................................................................[done]
Wie reinstalliere auch die Abhängigkeiten neu? Nur für den Fall, dass die Fehler daher kamen.
# mkinitrd -v
Sollte wieder die besagte Fehlermeldung kommen, dann bitte auch nochmal die Logdatei /var/log/YaST2/y2log_bootloader zeigen.
Wo ist der Bootloader-Code installiert worden?
# grep LOADER_LOCATION /etc/sysconfig/bootloader
computer:/ # grep LOADER_LOCATION /etc/sysconfig/bootloader LOADER_LOCATION=""
Der sollte eigentlich im MBR sein. So hatte ich es jedenfalls vor über einem Jahr bei der Installation - damals noch 12.2. Sollte also dort evtl. "MBR" oder sowas statt "" stehen?
OK. Ich habe nachgesehen. Dort steht "Default: mbr", was dasselbe Resultat bedeuten sollte. Auch das Eintragen von mbr von Hand hat den Fehler nicht beseitigt.
# cat /boot/grub2/device.map computer:/ # cat /boot/grub2/device.map (hd0) /dev/disk/by-id/raid-pdc_fjjhaaib
Das sieht übrigens exakt genauso aus, wie in meinem Backup von vor 2,3,4 usw. Wochen.
[...]
Ich habe noch auf 2 weiteren Rechnern openSUSE. Allerdings einmal mit 32bit (12.3) und dann eine 13.1 auf einem hornalten Rechner und dort seit ..irgendwas immer zypper dup auf den neuesten Stand gebracht. Keiner macht solche Fehler. Habe gerade mein wöchentliches Backup und anschließend ein reboot gemacht. Damit ist der Rechner trotz des Fehlers zum zweiten Mal problemlos hochgefahren. Ich habe jedenfalls keine einzige Fehlermeldung grub(2) betreffend beim Hochfahren gesehen. Werden denn grub0.97 und grub2 nacheinander ausgeführt? Ich hatte schon einmal die Überlegung geäußert, grub0.97 zu deinstallieren, habe aber Angst, dass dann das System nicht mehr hochfährt. Gruß, Alex -- 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
participants (2)
-
Alex Winzer -
Sebastian Siebert