System nach Kernel-Update kaputt? (/boot)
Hallo, Hilfe!!! Bevor ich einen Neustart versuche, kurze Frage, ob mein System nach dem letzten Kernel-Update kaputt ist. Falls ja, wie kann ich das prüfen und ggf. reparieren? Befürchtung: das Update ist unvollständig. df liefert: kw@venus1:/usr/local/bin> df Dateisystem 1K-blocks Benutzt Verfügbar Verw% Eingehängt auf /dev/sda2 51474044 7582568 41253704 16% / devtmpfs 3902212 48 3902164 1% /dev tmpfs 3915128 1004 3914124 1% /dev/shm tmpfs 3915128 4500 3910628 1% /run tmpfs 3915128 0 3915128 0% /sys/fs/cgroup tmpfs 3915128 4500 3910628 1% /var/run tmpfs 3915128 4500 3910628 1% /var/lock /dev/sda5 457897 51350 378387 12% /tmp /dev/sda6 154684396 28612812 124954220 19% /home /dev/sda1 116015 113619 0 100% /boot /dev/sda7 271501816 24922036 245459544 10% /home/as/dev /boot ist also voll! kw@venus1:/usr/local/bin> ls -altr /boot insgesamt 101781 -rw-r--r-- 1 root root 1484 18. Okt 2013 boot.readme -rw-r--r-- 1 root root 140360 1. Nov 2013 config-3.11.6-4-desktop -rw-r--r-- 1 root root 2697475 1. Nov 2013 System.map-3.11.6-4-desktop -rw-r--r-- 1 root root 6075542 1. Nov 2013 vmlinux-3.11.6-4-desktop.gz -rw-r--r-- 1 root root 516 1. Nov 2013 sysctl.conf-3.11.6-4-desktop -rw-r--r-- 1 root root 261933 1. Nov 2013 symvers-3.11.6-4-desktop.gz -rw-r--r-- 1 root root 5210216 1. Nov 2013 vmlinuz-3.11.6-4-desktop -rw-r--r-- 1 root root 620544 6. Nov 2013 message drwx------ 2 root root 12288 18. Jan 00:17 lost+found lrwxrwxrwx 1 root root 1 18. Jan 00:23 boot -> . drwxr-xr-x 2 root root 1024 18. Jan 00:23 grub -rw-r--r-- 1 root root 512 18. Jan 00:24 backup_mbr -rw-r--r-- 1 root root 140316 3. Feb 23:11 config-3.11.10-7-desktop -rw-r--r-- 1 root root 2681728 4. Feb 00:08 System.map-3.11.10-7-desktop -rw-r--r-- 1 root root 6039636 4. Feb 00:19 vmlinux-3.11.10-7-desktop.gz -rw-r--r-- 1 root root 516 4. Feb 00:19 sysctl.conf-3.11.10-7-desktop -rw-r--r-- 1 root root 262119 4. Feb 00:20 symvers-3.11.10-7-desktop.gz -rw-r--r-- 1 root root 5179304 4. Feb 01:52 vmlinuz-3.11.10-7-desktop -rw------- 1 root root 22923940 24. Apr 21:30 initrd-3.11.10-7-desktop -rw------- 1 root root 22923304 24. Apr 21:30 initrd-3.11.6-4-desktop drwxr-xr-x 7 root root 1024 24. Apr 21:30 grub2 -rw-r--r-- 1 root root 140329 12. Mai 16:09 config-3.11.10-11-desktop -rw-r--r-- 1 root root 2681971 12. Mai 17:07 System.map-3.11.10-11-desktop -rw-r--r-- 1 root root 6041992 12. Mai 17:20 vmlinux-3.11.10-11-desktop.gz -rw-r--r-- 1 root root 516 12. Mai 17:21 sysctl.conf-3.11.10-11-desktop -rw-r--r-- 1 root root 262177 12. Mai 17:21 symvers-3.11.10-11-desktop.gz -rw-r--r-- 1 root root 5181960 12. Mai 18:47 vmlinuz-3.11.10-11-desktop drwxr-xr-x 23 root root 4096 19. Mai 20:37 .. lrwxrwxrwx 1 root root 26 19. Mai 21:26 vmlinuz -> vmlinuz-3.11.10-11- desktop lrwxrwxrwx 1 root root 25 19. Mai 21:26 initrd -> initrd-3.11.10-11- desktop -rw-r--r-- 1 root root 0 19. Mai 21:26 do_purge_kernels -rw------- 1 root root 14295040 19. Mai 21:26 initrd-3.11.10-11-desktop drwxr-xr-x 5 root root 1024 19. Mai 21:26 . Die Datei initrd-3.11.10-11-desktop ist viel kleiner, als die alten Versionen. Meine Vermutung ist, dass damit kein Neustart mehr möglich ist.... Vielen Dank im Voraus für Eure Hilfe! Karl -- 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, Am Montag, 19. Mai 2014, 21:35:01 schrieb Karl Weber: [...]
df liefert:
kw@venus1:/usr/local/bin> df Dateisystem 1K-blocks Benutzt Verfügbar Verw% Eingehängt auf
[...]
/dev/sda1 116015 113619 0 100% /boot [...]
kw@venus1:/usr/local/bin> ls -altr /boot insgesamt 101781 -rw-r--r-- 1 root root 1484 18. Okt 2013 boot.readme -rw-r--r-- 1 root root 140360 1. Nov 2013 config-3.11.6-4-desktop -rw-r--r-- 1 root root 2697475 1. Nov 2013 System.map-3.11.6-4-desktop -rw-r--r-- 1 root root 6075542 1. Nov 2013 vmlinux-3.11.6-4-desktop.gz -rw-r--r-- 1 root root 516 1. Nov 2013 sysctl.conf-3.11.6-4-desktop -rw-r--r-- 1 root root 261933 1. Nov 2013 symvers-3.11.6-4-desktop.gz -rw-r--r-- 1 root root 5210216 1. Nov 2013 vmlinuz-3.11.6-4-desktop [...]
Ich habe die drei Dateien vmlinux-3.11.6-4-desktop.gz vmlinuz-3.11.6-4-desktop initrd-3.11.6-4-desktop weggemoved und die letzte Version des Kernel-Updates erneut installiert. Dann waren die Dateigrößen plausibel und ein Neustart erfolgreich. Kurios ist, dass nach kurzer Zeit die restlichen Dateien *3.11.6-4* durch irgendwas aus /boot gelöscht wurden. Fragen: Kann ich mit diesem Eingriff leben, oder muss ich mit Problemen rechnen? Falls ja, welche? Und was kann ich tun? Neu Partitionieren und das System neu installieren wäre aufwändig. Muss ich das jetzt bei jedem Kernel-Update durchführen? Warum werden die alten Versionen nicht gelöscht? Irgendwann wird damit jede /boot-Partition zu klein. Wer oder was hat die restlichen Dateien in /boot gelöscht? Warum? Nochmals Danke im Voraus. Karl -- 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 19.05.2014 22:15, schrieb Karl Weber:
Hallo,
Am Montag, 19. Mai 2014, 21:35:01 schrieb Karl Weber: [...]
df liefert:
kw@venus1:/usr/local/bin> df Dateisystem 1K-blocks Benutzt Verfügbar Verw% Eingehängt auf
[...]
/dev/sda1 116015 113619 0 100% /boot [...]
kw@venus1:/usr/local/bin> ls -altr /boot insgesamt 101781 -rw-r--r-- 1 root root 1484 18. Okt 2013 boot.readme -rw-r--r-- 1 root root 140360 1. Nov 2013 config-3.11.6-4-desktop -rw-r--r-- 1 root root 2697475 1. Nov 2013 System.map-3.11.6-4-desktop -rw-r--r-- 1 root root 6075542 1. Nov 2013 vmlinux-3.11.6-4-desktop.gz -rw-r--r-- 1 root root 516 1. Nov 2013 sysctl.conf-3.11.6-4-desktop -rw-r--r-- 1 root root 261933 1. Nov 2013 symvers-3.11.6-4-desktop.gz -rw-r--r-- 1 root root 5210216 1. Nov 2013 vmlinuz-3.11.6-4-desktop [...]
Ich habe die drei Dateien
vmlinux-3.11.6-4-desktop.gz vmlinuz-3.11.6-4-desktop initrd-3.11.6-4-desktop
weggemoved und die letzte Version des Kernel-Updates erneut installiert. Dann waren die Dateigrößen plausibel und ein Neustart erfolgreich.
Kurios ist, dass nach kurzer Zeit die restlichen Dateien *3.11.6-4* durch irgendwas aus /boot gelöscht wurden.
Fragen:
Kann ich mit diesem Eingriff leben, oder muss ich mit Problemen rechnen?
Falls ja, welche? Und was kann ich tun? Neu Partitionieren und das System neu installieren wäre aufwändig.
Muss ich das jetzt bei jedem Kernel-Update durchführen? Warum werden die alten Versionen nicht gelöscht? Irgendwann wird damit jede /boot-Partition zu klein.
Wer oder was hat die restlichen Dateien in /boot gelöscht? Warum?
Nochmals Danke im Voraus.
Karl
Sieh mal nach was in /etc/zypp/zypp.conf steht. Im Bereich um "multiversion.kernels=". Dort ist angeben wie viele Kernels immer parallel zur Verfügung stehen sollen. Neue Kernels werden einfach installiert und alte überflüssige Kernels werden dann etwas später automatisch deinstalliert. Es muß also immer etwas Reserveplatz vorhanden sein. Also wenn der Platz knapp ist, dann die Anzahl der alten Kernels reduzieren. Zur Sicherheit sollte aber min 1 alter Kernel gehalten werden. HTH Peter -- 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 Peter, Am Montag, 19. Mai 2014, 22:28:35 schrieb Peter Sikorski GTL:
Sieh mal nach was in /etc/zypp/zypp.conf steht. Im Bereich um "multiversion.kernels=".
Dort ist angeben wie viele Kernels immer parallel zur Verfügung stehen sollen. Neue Kernels werden einfach installiert und alte überflüssige Kernels werden dann etwas später automatisch deinstalliert. Es muß also immer etwas Reserveplatz vorhanden sein. Also wenn der Platz knapp ist, dann die Anzahl der alten Kernels reduzieren. Zur Sicherheit sollte aber min 1 alter Kernel gehalten werden.
Bei mir steht multiversion.kernels = latest,latest-1,running Ist folgende Aussage _beim_ Update von 3.11.10-7 auf 3.11.10-11 korrekt: 3.11.10-7 = running 3.11.10-11 = latest 3.11.10-7 = latest -1 Beim Neustart nach dem Update wäre dann: 3.11.10-11 = running 3.11.10-11 = latest 3.11.10-7 = latest -1 Damit würde also 3.11.6-4 nach dem Neustart gelöscht. Das passt zu meiner Beobachtung, dass die restlichen *3.11.6-4* Dateien gelöscht wurden. Das bedeutet aber, dass ich temporär Platz für drei Kernelversionen während des Updates haben muss. Dazu reicht meine /boot-Partition leider nicht mehr aus. Durch den manuellen Eingriff hatte ich aber immer einen alten Kernel, den 3.11.10-7. Hmmm.... Karl -- 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 19.05.2014 22:53, schrieb Karl Weber:
Hallo Peter,
Am Montag, 19. Mai 2014, 22:28:35 schrieb Peter Sikorski GTL:
Sieh mal nach was in /etc/zypp/zypp.conf steht. Im Bereich um "multiversion.kernels=".
Dort ist angeben wie viele Kernels immer parallel zur Verfügung stehen sollen. Neue Kernels werden einfach installiert und alte überflüssige Kernels werden dann etwas später automatisch deinstalliert. Es muß also immer etwas Reserveplatz vorhanden sein. Also wenn der Platz knapp ist, dann die Anzahl der alten Kernels reduzieren. Zur Sicherheit sollte aber min 1 alter Kernel gehalten werden.
Bei mir steht
multiversion.kernels = latest,latest-1,running
Ist folgende Aussage _beim_ Update von 3.11.10-7 auf 3.11.10-11 korrekt:
3.11.10-7 = running 3.11.10-11 = latest 3.11.10-7 = latest -1
wenn ich es richtig sehe, dann ist "running" der Kernel von dem aus du den Update durchführst. Das muß nicht zwangsläufig der höchste vorhandene sein, sondern ist deine willkürliche Wahl. "latest" ist während des Updates der höchste vorher vorhandene Kernel und "latest-1" dann analog
Beim Neustart nach dem Update wäre dann:
3.11.10-11 = running
wenn du diesen Kernel beim Start auswählst
3.11.10-11 = latest 3.11.10-7 = latest -1
richtig
Damit würde also 3.11.6-4 nach dem Neustart gelöscht. Das passt zu meiner Beobachtung, dass die restlichen *3.11.6-4* Dateien gelöscht wurden.
Das bedeutet aber, dass ich temporär Platz für drei Kernelversionen während des Updates haben muss. Dazu reicht meine /boot-Partition leider nicht mehr aus. Durch den manuellen Eingriff hatte ich aber immer einen alten Kernel, den 3.11.10-7. Notfalls könnte man vor dem Update des Kernels alle bis auf den "running" rauswerfen. Dann müßte nur Platz für2 Kernels vorhanden sein. Ist natürlich Aufwand und muß immer rechtzeitig dran denken. Besser wäre es sicherlich durch einen geeigneten Umbau die Boot-partition zu vergrößern. Irgendwo werden sich doch sicher noch einige freie Bits finden lassen. LG Peter
Hmmm....
Karl
-- 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 19/05/14 22:15, Karl Weber wrote:
Hallo,
Am Montag, 19. Mai 2014, 21:35:01 schrieb Karl Weber: [...]
df liefert:
kw@venus1:/usr/local/bin> df Dateisystem 1K-blocks Benutzt Verfügbar Verw% Eingehängt auf
[...]
/dev/sda1 116015 113619 0 100% /boot [...]
kw@venus1:/usr/local/bin> ls -altr /boot insgesamt 101781 -rw-r--r-- 1 root root 1484 18. Okt 2013 boot.readme -rw-r--r-- 1 root root 140360 1. Nov 2013 config-3.11.6-4-desktop -rw-r--r-- 1 root root 2697475 1. Nov 2013 System.map-3.11.6-4-desktop -rw-r--r-- 1 root root 6075542 1. Nov 2013 vmlinux-3.11.6-4-desktop.gz -rw-r--r-- 1 root root 516 1. Nov 2013 sysctl.conf-3.11.6-4-desktop -rw-r--r-- 1 root root 261933 1. Nov 2013 symvers-3.11.6-4-desktop.gz -rw-r--r-- 1 root root 5210216 1. Nov 2013 vmlinuz-3.11.6-4-desktop [...]
Ich habe die drei Dateien
vmlinux-3.11.6-4-desktop.gz vmlinuz-3.11.6-4-desktop initrd-3.11.6-4-desktop
weggemoved und die letzte Version des Kernel-Updates erneut installiert. Dann waren die Dateigrößen plausibel und ein Neustart erfolgreich.
Kurios ist, dass nach kurzer Zeit die restlichen Dateien *3.11.6-4* durch irgendwas aus /boot gelöscht wurden.
Ich kenne das so, dass Kernels durch andere ersetzt werden, dass man also nicht unterschiedliche desktop-, default- oder xen-Kernels parallel installiert haben kann - was mich übrigens schon manchmal geärgert hat. Offenbar wurde das geändert, dann sollten aber noch die entsprechenden Pakete installiert sein. Eine Deinstallation der Pakete wäre also dann der sauberste Weg.
Fragen:
Kann ich mit diesem Eingriff leben, oder muss ich mit Problemen rechnen?
Für mich sieht es so aus, dass Du genau das richtige getan hast.
Falls ja, welche? Und was kann ich tun? Neu Partitionieren und das System neu installieren wäre aufwändig.
Muss ich das jetzt bei jedem Kernel-Update durchführen? Warum werden die alten Versionen nicht gelöscht? Irgendwann wird damit jede /boot-Partition zu klein.
Dazu hatte Peter ja die passende Antwort.
Wer oder was hat die restlichen Dateien in /boot gelöscht? Warum?
Das würde mich allerdings auch interessieren.
Nochmals Danke im Voraus.
Karl
G, C* -- "Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr." (“Since the mathematicians have invaded the theory of relativity I do not understand it myself any more.”) - Albert Einstein
Am 19.05.2014 21:35, schrieb Karl Weber:
Hallo, Hilfe!!!
Bevor ich einen Neustart versuche, kurze Frage, ob mein System nach dem letzten Kernel-Update kaputt ist. Falls ja, wie kann ich das prüfen und ggf. reparieren?
Befürchtung: das Update ist unvollständig.
df liefert:
kw@venus1:/usr/local/bin> df Dateisystem 1K-blocks Benutzt Verfügbar Verw% Eingehängt auf /dev/sda2 51474044 7582568 41253704 16% / devtmpfs 3902212 48 3902164 1% /dev tmpfs 3915128 1004 3914124 1% /dev/shm tmpfs 3915128 4500 3910628 1% /run tmpfs 3915128 0 3915128 0% /sys/fs/cgroup tmpfs 3915128 4500 3910628 1% /var/run tmpfs 3915128 4500 3910628 1% /var/lock /dev/sda5 457897 51350 378387 12% /tmp /dev/sda6 154684396 28612812 124954220 19% /home /dev/sda1 116015 113619 0 100% /boot /dev/sda7 271501816 24922036 245459544 10% /home/as/dev
/boot ist also voll!
kw@venus1:/usr/local/bin> ls -altr /boot insgesamt 101781 -rw-r--r-- 1 root root 1484 18. Okt 2013 boot.readme -rw-r--r-- 1 root root 140360 1. Nov 2013 config-3.11.6-4-desktop -rw-r--r-- 1 root root 2697475 1. Nov 2013 System.map-3.11.6-4-desktop -rw-r--r-- 1 root root 6075542 1. Nov 2013 vmlinux-3.11.6-4-desktop.gz -rw-r--r-- 1 root root 516 1. Nov 2013 sysctl.conf-3.11.6-4-desktop -rw-r--r-- 1 root root 261933 1. Nov 2013 symvers-3.11.6-4-desktop.gz -rw-r--r-- 1 root root 5210216 1. Nov 2013 vmlinuz-3.11.6-4-desktop -rw-r--r-- 1 root root 620544 6. Nov 2013 message drwx------ 2 root root 12288 18. Jan 00:17 lost+found lrwxrwxrwx 1 root root 1 18. Jan 00:23 boot -> . drwxr-xr-x 2 root root 1024 18. Jan 00:23 grub -rw-r--r-- 1 root root 512 18. Jan 00:24 backup_mbr -rw-r--r-- 1 root root 140316 3. Feb 23:11 config-3.11.10-7-desktop -rw-r--r-- 1 root root 2681728 4. Feb 00:08 System.map-3.11.10-7-desktop -rw-r--r-- 1 root root 6039636 4. Feb 00:19 vmlinux-3.11.10-7-desktop.gz -rw-r--r-- 1 root root 516 4. Feb 00:19 sysctl.conf-3.11.10-7-desktop -rw-r--r-- 1 root root 262119 4. Feb 00:20 symvers-3.11.10-7-desktop.gz -rw-r--r-- 1 root root 5179304 4. Feb 01:52 vmlinuz-3.11.10-7-desktop -rw------- 1 root root 22923940 24. Apr 21:30 initrd-3.11.10-7-desktop -rw------- 1 root root 22923304 24. Apr 21:30 initrd-3.11.6-4-desktop drwxr-xr-x 7 root root 1024 24. Apr 21:30 grub2 -rw-r--r-- 1 root root 140329 12. Mai 16:09 config-3.11.10-11-desktop -rw-r--r-- 1 root root 2681971 12. Mai 17:07 System.map-3.11.10-11-desktop -rw-r--r-- 1 root root 6041992 12. Mai 17:20 vmlinux-3.11.10-11-desktop.gz -rw-r--r-- 1 root root 516 12. Mai 17:21 sysctl.conf-3.11.10-11-desktop -rw-r--r-- 1 root root 262177 12. Mai 17:21 symvers-3.11.10-11-desktop.gz -rw-r--r-- 1 root root 5181960 12. Mai 18:47 vmlinuz-3.11.10-11-desktop drwxr-xr-x 23 root root 4096 19. Mai 20:37 .. lrwxrwxrwx 1 root root 26 19. Mai 21:26 vmlinuz -> vmlinuz-3.11.10-11- desktop lrwxrwxrwx 1 root root 25 19. Mai 21:26 initrd -> initrd-3.11.10-11- desktop -rw-r--r-- 1 root root 0 19. Mai 21:26 do_purge_kernels -rw------- 1 root root 14295040 19. Mai 21:26 initrd-3.11.10-11-desktop drwxr-xr-x 5 root root 1024 19. Mai 21:26 .
Die Datei initrd-3.11.10-11-desktop ist viel kleiner, als die alten Versionen. Meine Vermutung ist, dass damit kein Neustart mehr möglich ist....
Deie /boot Partition ist voll. Abhilfe: Platz schaffen und danach noch einmal mkinitrd aufrufen Gruß Manfred -- 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 19/05/14 21:35, Karl Weber wrote:
Hallo, Hilfe!!!
Bevor ich einen Neustart versuche, kurze Frage, ob mein System nach dem letzten Kernel-Update kaputt ist. Falls ja, wie kann ich das prüfen und ggf. reparieren?
Befürchtung: das Update ist unvollständig.
df liefert:
kw@venus1:/usr/local/bin> df Dateisystem 1K-blocks Benutzt Verfügbar Verw% Eingehängt auf /dev/sda2 51474044 7582568 41253704 16% / devtmpfs 3902212 48 3902164 1% /dev tmpfs 3915128 1004 3914124 1% /dev/shm tmpfs 3915128 4500 3910628 1% /run tmpfs 3915128 0 3915128 0% /sys/fs/cgroup tmpfs 3915128 4500 3910628 1% /var/run tmpfs 3915128 4500 3910628 1% /var/lock /dev/sda5 457897 51350 378387 12% /tmp /dev/sda6 154684396 28612812 124954220 19% /home /dev/sda1 116015 113619 0 100% /boot /dev/sda7 271501816 24922036 245459544 10% /home/as/dev
/boot ist also voll!
kw@venus1:/usr/local/bin> ls -altr /boot insgesamt 101781 -rw-r--r-- 1 root root 1484 18. Okt 2013 boot.readme -rw-r--r-- 1 root root 140360 1. Nov 2013 config-3.11.6-4-desktop -rw-r--r-- 1 root root 2697475 1. Nov 2013 System.map-3.11.6-4-desktop -rw-r--r-- 1 root root 6075542 1. Nov 2013 vmlinux-3.11.6-4-desktop.gz -rw-r--r-- 1 root root 516 1. Nov 2013 sysctl.conf-3.11.6-4-desktop -rw-r--r-- 1 root root 261933 1. Nov 2013 symvers-3.11.6-4-desktop.gz -rw-r--r-- 1 root root 5210216 1. Nov 2013 vmlinuz-3.11.6-4-desktop -rw-r--r-- 1 root root 620544 6. Nov 2013 message drwx------ 2 root root 12288 18. Jan 00:17 lost+found lrwxrwxrwx 1 root root 1 18. Jan 00:23 boot -> . drwxr-xr-x 2 root root 1024 18. Jan 00:23 grub -rw-r--r-- 1 root root 512 18. Jan 00:24 backup_mbr -rw-r--r-- 1 root root 140316 3. Feb 23:11 config-3.11.10-7-desktop -rw-r--r-- 1 root root 2681728 4. Feb 00:08 System.map-3.11.10-7-desktop -rw-r--r-- 1 root root 6039636 4. Feb 00:19 vmlinux-3.11.10-7-desktop.gz -rw-r--r-- 1 root root 516 4. Feb 00:19 sysctl.conf-3.11.10-7-desktop -rw-r--r-- 1 root root 262119 4. Feb 00:20 symvers-3.11.10-7-desktop.gz -rw-r--r-- 1 root root 5179304 4. Feb 01:52 vmlinuz-3.11.10-7-desktop -rw------- 1 root root 22923940 24. Apr 21:30 initrd-3.11.10-7-desktop -rw------- 1 root root 22923304 24. Apr 21:30 initrd-3.11.6-4-desktop drwxr-xr-x 7 root root 1024 24. Apr 21:30 grub2 -rw-r--r-- 1 root root 140329 12. Mai 16:09 config-3.11.10-11-desktop -rw-r--r-- 1 root root 2681971 12. Mai 17:07 System.map-3.11.10-11-desktop -rw-r--r-- 1 root root 6041992 12. Mai 17:20 vmlinux-3.11.10-11-desktop.gz -rw-r--r-- 1 root root 516 12. Mai 17:21 sysctl.conf-3.11.10-11-desktop -rw-r--r-- 1 root root 262177 12. Mai 17:21 symvers-3.11.10-11-desktop.gz -rw-r--r-- 1 root root 5181960 12. Mai 18:47 vmlinuz-3.11.10-11-desktop drwxr-xr-x 23 root root 4096 19. Mai 20:37 .. lrwxrwxrwx 1 root root 26 19. Mai 21:26 vmlinuz -> vmlinuz-3.11.10-11- desktop lrwxrwxrwx 1 root root 25 19. Mai 21:26 initrd -> initrd-3.11.10-11- desktop -rw-r--r-- 1 root root 0 19. Mai 21:26 do_purge_kernels -rw------- 1 root root 14295040 19. Mai 21:26 initrd-3.11.10-11-desktop drwxr-xr-x 5 root root 1024 19. Mai 21:26 .
Die Datei initrd-3.11.10-11-desktop ist viel kleiner, als die alten Versionen. Meine Vermutung ist, dass damit kein Neustart mehr möglich ist....
Damit würde ich mich auch keinen Reboot trauen. Leider war (ist?) die Default-Größe der Boot-Partition bei SuSE vielzu klein gewählt. Ich ändere diese seit einiger Zeit bei jeder Installation auf 500MB. Damit komme ich auch mit mehreren Kernels (desktop, default, xen) recht gut klar. Was mich wundert: wieso wurdest Du nicht gewarnt, bevor die entsprechenden Pakete installiert wurden? Ich benutze für die Paketverwaltung yast2 und bekomme also zumindest vorher mit, wenn mir eine Partition zu überlaufen droht. Bei älteren Installationen (zu kleine Boot-Partition) habe ich dann "schweren Herzens" ein-zwei Kernel gelöscht und dann erneut probiert. Dass Du 3 unterschiedliche Desktop-Kernels installiert hast ist auch ungewöhnlich. Möglicherweise sind da noch Dateileichen (3.11.6-4), die garnicht mehr benötigt werden. Wenn der Kernel eh nicht mehr in GRUB aufgeführt wird, solltest Du die löschen können.
Vielen Dank im Voraus für Eure Hilfe!
Karl
-- "Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr." (“Since the mathematicians have invaded the theory of relativity I do not understand it myself any more.”) - Albert Einstein
Hallo Carsten, Am Montag, 19. Mai 2014, 22:29:40 schrieb Carsten Neumann:
Was mich wundert: wieso wurdest Du nicht gewarnt, bevor die entsprechenden Pakete installiert wurden? Ich benutze für die Paketverwaltung yast2 und bekomme also zumindest vorher mit, wenn mir eine Partition zu überlaufen droht.
Das ist eine gute Frage. Beim ersten Update gab es keinen Hinweis. Ich habe explizit danach gesucht aber keinen gefunden. Ich arbeite auch mit YaST2. Beim erneuten Aufruf von YaST2 gab es dann den Hinweis auf die _fast_ volle /boot (97% voll). Kurios, denn df meldete 100% voll. Zudem war die letzte Datei schon unvollständig. Beim erneuten Installieren gab es dann diesen Hinweis und der zweite Versuch ist abgebrochen..... Nach dem manuellen wegmoven einiger Dateien hat dann der dritte Versuch endlich geklappt.
Bei älteren Installationen (zu kleine Boot-Partition) habe ich dann "schweren Herzens" ein-zwei Kernel gelöscht und dann erneut probiert. Dass Du 3 unterschiedliche Desktop-Kernels installiert hast ist auch ungewöhnlich. Möglicherweise sind da noch Dateileichen (3.11.6-4), die garnicht mehr benötigt werden. Wenn der Kernel eh nicht mehr in GRUB aufgeführt wird, solltest Du die löschen können.
Wenn ich das richtig verstanden habe (siehe meine Antwort auf einen anderen Beitrag) braucht ich beim Installieren temporär bis zum nächsten Neustart Platz für drei Kernel. Bei der Installation habe ich den aktuell laufenden den letzten aufgehobenen den neu installierten. Erst beim nächsten Neustart wird der neu installierte zum aktuell laufenden der beim Update aktuelle zum letzten aufgehobenen der beim Update letzte aufgehobene gelöscht. Vielleicht habe ich das aber auch falsch verstanden. Karl -- 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 19/05/14 23:02, Karl Weber wrote:
Hallo Carsten,
Am Montag, 19. Mai 2014, 22:29:40 schrieb Carsten Neumann:
Was mich wundert: wieso wurdest Du nicht gewarnt, bevor die entsprechenden Pakete installiert wurden? Ich benutze für die Paketverwaltung yast2 und bekomme also zumindest vorher mit, wenn mir eine Partition zu überlaufen droht.
Das ist eine gute Frage. Beim ersten Update gab es keinen Hinweis. Ich habe explizit danach gesucht aber keinen gefunden. Ich arbeite auch mit YaST2. Beim erneuten Aufruf von YaST2 gab es dann den Hinweis auf die _fast_ volle /boot (97% voll). Kurios, denn df meldete 100% voll. Zudem war die letzte Datei schon unvollständig.
Beim erneuten Installieren gab es dann diesen Hinweis und der zweite Versuch ist abgebrochen.....
Nach dem manuellen wegmoven einiger Dateien hat dann der dritte Versuch endlich geklappt.
Bei älteren Installationen (zu kleine Boot-Partition) habe ich dann "schweren Herzens" ein-zwei Kernel gelöscht und dann erneut probiert. Dass Du 3 unterschiedliche Desktop-Kernels installiert hast ist auch ungewöhnlich. Möglicherweise sind da noch Dateileichen (3.11.6-4), die garnicht mehr benötigt werden. Wenn der Kernel eh nicht mehr in GRUB aufgeführt wird, solltest Du die löschen können.
Wenn ich das richtig verstanden habe (siehe meine Antwort auf einen anderen Beitrag) braucht ich beim Installieren temporär bis zum nächsten Neustart Platz für drei Kernel.
Bei der Installation habe ich
den aktuell laufenden den letzten aufgehobenen den neu installierten.
Erst beim nächsten Neustart wird
der neu installierte zum aktuell laufenden der beim Update aktuelle zum letzten aufgehobenen der beim Update letzte aufgehobene gelöscht.
Vielleicht habe ich das aber auch falsch verstanden.
Karl
Hallo Karl, jetzt habe ich mal in meine /etc/zypp/zypp.conf geschaut. Die "multiversion"-Zeilen sind allesamt auskommentiert. Ich wusste bis zu Peters Antwort noch nicht einmal, dass sich das konfigurieren lässt. Bei der "Mini"-Größe Deiner Boot-Partition sollte eine Kernel-Version genug sein. Somit sollte das Auskommentieren der entsprechenden Zeilen in Deiner /etc/zypp/zypp.conf (wahrscheinlich) immer nur die letzte Kernel-Version halten. G, C* -- "Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr." (“Since the mathematicians have invaded the theory of relativity I do not understand it myself any more.”) - Albert Einstein
On 19/05/14 23:02, Karl Weber wrote:
Hallo Carsten,
Am Montag, 19. Mai 2014, 22:29:40 schrieb Carsten Neumann:
Was mich wundert: wieso wurdest Du nicht gewarnt, bevor die entsprechenden Pakete installiert wurden? Ich benutze für die Paketverwaltung yast2 und bekomme also zumindest vorher mit, wenn mir eine Partition zu überlaufen droht.
Das ist eine gute Frage. Beim ersten Update gab es keinen Hinweis. Ich habe explizit danach gesucht aber keinen gefunden. Ich arbeite auch mit YaST2. Beim erneuten Aufruf von YaST2 gab es dann den Hinweis auf die _fast_ volle /boot (97% voll). Kurios, denn df meldete 100% voll. Zudem war die letzte Datei schon unvollständig.
Die unterschiedlichen Werte liegen daran, dass immer ein paar Prozent fürs System reserviert werden, siehe: tune2fs(8). Mit der -m Option kannst Du das festlegen, df(1) berücksichtigt das. Der Default-Wert ist 5%. Dass die letzte Datei unvollständig war, zeigt, dass das Dateisystem tatsächlich vollgelaufen war.
Beim erneuten Installieren gab es dann diesen Hinweis und der zweite Versuch ist abgebrochen.....
Nach dem manuellen wegmoven einiger Dateien hat dann der dritte Versuch endlich geklappt.
Bei älteren Installationen (zu kleine Boot-Partition) habe ich dann "schweren Herzens" ein-zwei Kernel gelöscht und dann erneut probiert. Dass Du 3 unterschiedliche Desktop-Kernels installiert hast ist auch ungewöhnlich. Möglicherweise sind da noch Dateileichen (3.11.6-4), die garnicht mehr benötigt werden. Wenn der Kernel eh nicht mehr in GRUB aufgeführt wird, solltest Du die löschen können.
Wenn ich das richtig verstanden habe (siehe meine Antwort auf einen anderen Beitrag) braucht ich beim Installieren temporär bis zum nächsten Neustart Platz für drei Kernel.
Bei der Installation habe ich
den aktuell laufenden den letzten aufgehobenen den neu installierten.
Erst beim nächsten Neustart wird
der neu installierte zum aktuell laufenden der beim Update aktuelle zum letzten aufgehobenen der beim Update letzte aufgehobene gelöscht.
Vielleicht habe ich das aber auch falsch verstanden.
Karl
-- "Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr." (“Since the mathematicians have invaded the theory of relativity I do not understand it myself any more.”) - Albert Einstein
participants (4)
-
Carsten Neumann -
Karl Weber -
Manfred Kreisl -
Peter Sikorski GTL