Probleme beim Kernel-Upgrade auf 4.9.0-3

[jenzuslongus]

Hallo zusammen,

ich habe gestern ein

Code: Alles auswählen

apt-get upgrade

gemacht, weil ich u.a. den Kernel aktualisieren wollte. Die Installation blieb an folgender Stelle hängen:

Code: Alles auswählen

linux-image-4.9.0-3-amd64 (4.9.30-2+deb9u2) wird eingerichtet ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64

Nach langem Warten habe ich das abgebrochen, weil sich nichts mehr tat. Ich habe dann mehrfach versucht, mittels

Code: Alles auswählen

dpkg --configure -a

oder

Code: Alles auswählen

apt-get -f install

das Ganze wieder zum Laufen zu kriegen, der "Hänger" kam aber immer an der selben Stelle.

Ich habe dann ausprobiert, ob ich die initdrd manuell bauen kann:

Code: Alles auswählen

update-initramfs -u -t

Läuft ohne Probleme bis zum Ende durch, es wird eine initrd erzeugt und nach /boot/initrd.img-4.9.0-3-amd64 kopiert.
Wenn ich dann wieder apt-get -f install probiere, bleibt er wie oben beschrieben stehen. Genug Speicherplatz habe ich:

Code: Alles auswählen

root@xxx:/boot# df -h
Dateisystem             Größe Benutzt Verf. Verw% Eingehängt auf
[snip]
/dev/sda1                735M     43M  639M    7% /boot
[snip]

Das System ist ein Debian Stretch. Braucht ihr noch weitere Infos?

Hat einer eine Idee, woran das liegen kann? Ich traue mich momentan nicht, den Rechner neu zu booten, weil ich Sorge habe, dass das nicht funktionieren wird.

Viele Grüße
Jens

[rendegast]

Vielleicht

Code: Alles auswählen

df -m
free -m

watch -n 0.3 -d=cum 'df -m; free -m'

?
Bei mir geschieht das wohl nur im RAM, dort kurzfristig ca. 100MB.

Code: Alles auswählen

apt-get download linux-image-4.9........

resp. aus dem /var/cache/apt/archives/.
Dann kann das Paket auch mal purged werden (gegebenenfalls 'dpkg -P --force-all ...').

[jenzuslongus]

Ich verstehe ehrlich gesagt nicht ganz, was ich machen soll.
Am Arbeitsspeicher kann es nicht liegen, der Rechner hat 256 GB RAM.

Ich habe es mal mit apt-get download versucht und dann mittels

Code: Alles auswählen

jens@aragorn ~ $ sudo dpkg --configure -a                                                                                    
linux-image-4.9.0-3-amd64 (4.9.30-2+deb9u2) wird eingerichtet ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64

Leider mit demselben Ergebnis

[bitfreak]

Was mich überhaupt irritiert ist, dass es zu dem entsprechenden Debianpaket (4.9.30-2+deb9u2) keinen Changelog gibt. Auch auf der Startseite von Debian gibt es keine Hinweise dazu, dass Sicherheitsprobleme behoben wurden. Im Package Tracker zu linux steht nur, dass es ein entsprechendes Paket gibt. Aber noch nicht einmal wann und durch wen dieses hochgeladen wurde. Von daher habe ich das Update bis jetzt hinausgezögert, bis entsprechende Informationen vorhanden sind. Aber das war anscheinend bis jetzt nicht der Fall.

[rendegast]

@bitfreak

Code: Alles auswählen

$ zcat /usr/share/doc/linux-image-4.9.0-3-amd64/changelog.Debian.gz | head -n20
linux (4.9.30-2+deb9u2) stretch-security; urgency=high

  * Revert changes in version 4.9.30-2+deb9u1 (Closes: #865303)
  * mm: larger stack guard gap, between vmas (CVE-2017-1000364)
  * mm: fix new crash in unmapped_area_topdown()

 -- Ben Hutchings <ben@decadent.org.uk>  Mon, 26 Jun 2017 16:27:47 +0100

linux (4.9.30-2+deb9u1) stretch-security; urgency=high

  * mm: enlarge stack guard gap (CVE-2017-1000364)
  * mm: allow to configure stack gap size
  * mm, proc: cap the stack gap for unpopulated growing vmas
  * mm, proc: drop priv parameter from is_stack
  * mm: do not collapse stack gap into THP
  * fold me "mm: allow to configure stack gap size"

 -- Salvatore Bonaccorso <carnil@debian.org>  Sun, 18 Jun 2017 10:14:32 +0200

linux (4.9.30-2) unstable; urgency=high
...

packages.debian.org hängt halt manchmal hinterher.



@jenzuslongus

Code: Alles auswählen

update-initramfs -u -kall -v

?

Ich habe es mal mit apt-get download versucht und dann mittels
$ sudo dpkg --configure -a
...

Ich dachte eher daran, zuerst mal den kernel komplett zu entfernen
und dann neu hinzuzufügen.

Code: Alles auswählen

dpkg -P  [force-all]  linux-image-4.9......
rm /boot/*4.9*
rm /var/lib/initramfs-tools/*4.9*
dpkg -i /pfad/linux-image-4.9*.deb

[jenzuslongus]

Code: Alles auswählen

update-initramfs -u -kall -v
[snip]
Calling hook dmsetup
Calling hook klibc-utils
/usr/share/initramfs-tools/scripts/local-block/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-premount/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/local-top/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-bottom/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/local-premount/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/panic/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/local-bottom/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-top/ORDER ignored: not executable
Building cpio /boot/initrd.img-4.9.0-3-amd64.new initramfs
Execute: /usr/sbin/update-initramfs -u -k "4.9.0-3" -b /boot -v
/boot/initrd.img-4.9.0-3 does not exist. Cannot update.

Dann habe ich es mit dem purgen des Kernels versucht. Da gab es zuerst mal eine Warnung, dass ich den laufenden Kernel entferne. Ich habe dann mal trotzdem gesagt, dass er den Kernel entfernen soll. War wahrscheinlich ziemlich dämlich, oder?

Dann ist aber Folgendes passiert:

Code: Alles auswählen

jens@aragorn ~ $ sudo dpkg -P --force-all linux-image-4.9.0-3-amd64           
dpkg: linux-image-4.9.0-3-amd64: Abhängigkeitsprobleme, wird aber wie gefordert dennoch entfernt:
 linux-image-amd64 hängt ab von linux-image-4.9.0-3-amd64.                   
                                                                         
(Lese Datenbank ... 186123 Dateien und Verzeichnisse sind derzeit installiert.)
Entfernen von linux-image-4.9.0-3-amd64 (4.9.30-2+deb9u2) ...              
W: Removing the running kernel                                     
/etc/kernel/prerm.d/dkms:                                                
dkms: removing: aufs 4.9+20161219 (4.9.0-3-amd64) (x86_64)
                                                                               
-------- Uninstall Beginning --------                  
Module:  aufs                                                
Version: 4.9+20161219                                                  
Kernel:  4.9.0-3-amd64 (x86_64)            
-------------------------------------                    
                                                                           
Status: Before uninstall, this module version was ACTIVE on this kernel.
                                             
aufs.ko:                                                                  
 - Uninstallation                                                                         
   - Deleting from: /lib/modules/4.9.0-3-amd64/updates/dkms/               
 - Original module                  
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.
                                                                                                 
depmod...                                                            
                                                                  
DKMS: uninstall completed.                                       
                                                                               
------------------------------                                                            
Deleting module version: 4.9+20161219                                               
completely from the DKMS tree.                                   
------------------------------                                        
Done.                                                               
W: Last kernel image has been removed, so removing the default symlinks       
/etc/kernel/postrm.d/initramfs-tools:                           
update-initramfs: Deleting /boot/initrd.img-4.9.0-3-amd64

Und dann ist wieder Schluss, weil er hängen bleibt. Danach habe ich den Kernel wieder installieren wollen, auch ohne Erfolg:

Code: Alles auswählen

jens@aragorn ~ $ sudo apt-get install --reinstall linux-image-4.9.0-3-amd64                                                                                               
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 0 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Es müssen noch 0 B von 38,7 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
(Lese Datenbank ... 181891 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../linux-image-4.9.0-3-amd64_4.9.30-2+deb9u2_amd64.deb ...
Entpacken von linux-image-4.9.0-3-amd64 (4.9.30-2+deb9u2) über (4.9.30-2+deb9u2) ...
linux-image-4.9.0-3-amd64 (4.9.30-2+deb9u2) wird eingerichtet ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.9.0-3-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-4.9.0-3-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-4.9.0-3-amd64
I: /initrd.img is now a symlink to boot/initrd.img-4.9.0-3-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64

Kann ich noch was anderes ausprobieren?

[rendegast]

Ich habe dann mal trotzdem gesagt, dass er den Kernel entfernen soll. War wahrscheinlich ziemlich dämlich, oder?

Nein, sonst hätte ich es nicht vorgeschlagen.

Dann ist aber Folgendes passiert:
...
Und dann ist wieder Schluss, weil er hängen bleibt.

Danach habe ich den Kernel wieder installieren wollen, auch ohne Erfolg:

Das sollte nicht sein.
Der Normalfall (bei mir):
Kernel deinstalliert sich, und Installieren des *.deb stellt ihn wieder her.
(Nachzuarbeiten (bei mir): Die dkms-Module waren (wohl da nur 1 Kernel) 'removed' und mußten händisch per 'dkms install' neu hinzugefügt werden.)

Anmerkung,
Der Bezug auf 'dpkg install' eines vorher heruntergeladenes Paket linux-image-*.deb war,
um nicht das netzbasierte apt nutzen zu müssen.
Ausschalten einer potentiellen Fehlerquelle in dem dann doch heiklen Zustand.
Ein sicheres alternatives Vorgehen wäre die Installation eines Zweitkernels,
zBsp. des Vorgängerpakets linux-image-4.9.0-2-amd64

[jenzuslongus]

Das mit dem Vorgängerpaket hat nicht so geklappt, weil es das paket 4.9.0-2-amd64 nicht zu geben scheint. Ich habe stattdessen mal eine Version wie folgt installieren wollen (müsste der Vor-Vorgänger vom Kernel sein, der geupdated werden soll:

Code: Alles auswählen

sudo apt-get install linux-image-4.9.0-3-amd64=4.9.30-2

Leider wieder ohne Erfolg.

Dann habe ich aber bemerkt, dass sehr viele Prozesse

Code: Alles auswählen

root     17933  0.0  0.0   6336  1404 ?        S    Jun28   0:00 /bin/sh /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg
root     17955  0.0  0.0  25640  2336 ?        D    Jun28   0:00 /usr/sbin/grub-probe --device /dev/mapper/vg00-lvRoot --target=fs_uuid

noch "hängen". Das deutet doch darauf hin, dass er beim Ausführen von /etc/kernel/postinst.d/zz-update-grub hängen bleibt, oder? Ich habe mal versucht, die Prozesse zu killen, aber die grub-probe-Prozesse kann ich nicht einmal mit kill -9 abschießen. Ich befürchte, dass weitere Versuche nichts bringen, weil an dieser Stelle immer Ende ist.

Kann es sein, dass beim grub noch irgendein vorgelagertes Problem sein könnte?

Hast du noch eine Idee?

[KP97]

Der Kernel 4.9.0-2-amd64 beinhaltet den LT-Kernel 4.9.18-xxx und befindet sich im Archiv, wie übrigens alle Pakete aus den Repos:
http://snapshot.debian.org/package/linu ... 4_4.9.18-1

Den Kernel kannst Du herunterladen und das .deb Paket mit
dpkg -i <Paketname> installieren.
Sollte der Paketmanager schon beschädigt worden sein, hilft evtl. vorher ein apt -f install

Warum setzt Du immer ein sudo vor die Befehle? Hast Du bei der Installation kein root-Paßwort vergeben?
Bei Debian wird sudo eher nicht verwendet um root zu werden, das wird exzessiv nur bei *buntu so gehandhabt.

[jenzuslongus]

Mittlerweile denke ich, dass das Problem bereits bei grub irgendwo liegt. Ich habe mal versucht, grub-pc neu zu konfigurieren, das klappt auch nicht mehr. Ich hatte nämlich bemerkt, dass zig Prozesse in dieser Art als Zombie-Prozesse rumgeistern:

Code: Alles auswählen

jens@aragorn /usr/sbin $ ps  aux|grep grub
root       607  0.0  0.0  25640  3060 ?        D    Jul13   0:00 /usr/sbin/grub-probe --device /dev/mapper/vg00-lvRoot --target=fs_uuid
root      3265  0.0  0.0  25640  2140 ?        D    Jun28   0:00 /usr/sbin/grub-probe --device /dev/mapper/vg00-lvRoot --target=fs_uuid

Wie man sieht, auch schon seit langer Zeit teilweise. Ich vermute, dass das seit dem Upgrade von jessie auf stretch so ist, weil ich beim Upgrade einen Fehler bei grub hatte. Es kam so eine Fehlermeldung der Art, dass grub nicht installiert sei und wo ich wieder installieren wolle. Ich habe dann gesagt, dass es in den MBR der Platte /dev/sda installiert werden soll.

Jetzt habe ich versucht, grub neu zu installieren, aber das bleibt auch hängen:

Code: Alles auswählen

$ sudo grub-install /dev/sda                                                                                                   
i386-pc wird für Ihre Plattform installiert.

So langsam weiß ich auch nicht, wo ich anfangen soll zu suchen. Einen Neustart zu machen, kommt mir an der Stelle wie der sichere Weg in Richtung "Es wird gar nichts mehr laufen" vor.


Das mit dem sudo kommt wahrscheinlich daher, dass ich auf meinen Rechnern Ubuntu benutze, nur auf dem Server läuft Debian.

[KP97]

Ist das denn so alte Hardware, daß Du grub-pc installieren willst? Das verschweigst Du ja.
Mittlerweile haben die Boards doch standardmäßig EFI, da ist grub-efi-amd64 das richtige Paket.
Ob sich das im laufenden Betrieb noch reparieren läßt, glaube ich eher nicht.
Entweder Du gehst mittels eines Backups erstmal wieder auf Jessie (Du hast doch ganz bestimmt eines als Serverbetreiber, sonst sind die Daten ja nicht wichtig), machst Dich vorher schlau, was bei einem Upgrade zu beachten ist, und versuchst es noch einmal.
Oder Du startest eine Installations-CD im Rescuemode, installierst damit den richtigen Grub und evtl. auch einen Kernel.

Das mit den Snapshots hast Du verstanden? Und das man bei außerhalb der sources.list beschafften Paketen kein apt sondern immer dpkg verwendet?

[jenzuslongus]

Nein, der Rechner ist erst 5 Monate alt, die Hardware ist demnach neu. Allerdings war das System auf dem Server vorinstalliert, als wir es gekauft haben, so dass daher das Paket grub-pc kommt.

Was würde es aus deiner Sicht bringen, wenn ich auf jessie zurückgehe und dann das Upgrade nochmal mache? Ich hatte mir schon vorher angeschaut, was beim Upgrade zu beachten ist. In Sachen grub habe ich da aber nichts gefunden. Ich erwarte, dass das Upgrade an derselben Stelle wieder auf das Problem stößt mit dem grub. Ich müsste irgendwas an der Konfiguration ändern, damit sich das Upgrade anders verhält und da wüsste ich nicht, was das sein könnte.

Wenn ich dich richtig verstehe, kann ich das Paket grub-efi-amd64 nur über die Rescue-CD installieren. Das würde ich dann als Erstes mal versuchen.

Übrigens habe ich gestern bemerkt, dass auch ein Aufruf von

Code: Alles auswählen

root@aragorn:~# fdisk -l /dev/sda

hängen bleibt. Es wird immer kurioser.

Das mit den Snapshots habe ich jetzt verstanden, vielen Dank für die Erläuterungen.

[KP97]

Bevor wir jetzt weiter im Nebel stochern, mach mal vernünftige und ausführliche Angaben zu Deinem System und der Hardware.
Ist das ein vServer? Wer hat den denn aufgesetzt? Einen neuen Rechner ohne EFI zu installieren ist ja schon fast eine Kunst.
Also schreib erst mal, was genau Du da hast, auch die sources.list wäre interessant.
Evtl. meldet sich auch mal jemand der Experten hier, die einen Server betreiben.
Den habe ich nämlich nicht, ich habe einen Desktop mit Sid, das allerdings schon sehr lange.

Dein System scheint arg strubbelig zu sein, ich würde auf jeden Fall erst noch ein Restore auf Jessie machen, damit wieder ein sauberer Stand ist.
Dann kann man weitersehen.

[jenzuslongus]

Es ist kein vServer, sondern ein physikalischer Rechner, auf dem direkt Debian installiert wurde. Das Debian-System läuft nicht auf VMWare oder Ähnlichem.

Prozessor sind zwei Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz. Der Rechner hat 256 GB RAM.
Das Mainboard ist ein Intel S2600WTTR
Es ist ein RAID-Controller verbaut von Adaptec:

Code: Alles auswählen

$ lspci
[...]
RAID bus controller: Adaptec Series 8 12G SAS/PCIe 3 (rev 01)
[...]

Das RAID wird als Device /dev/sda im Debian angezeigt. /dev/sda1 ist nach /boot gemountet. /dev/sda2 ist einziges Physical Volume in der Volume Group vg00, die wiederum mehrere Logical Volumes beinhaltet.

/etc/apt/sources.list:

Code: Alles auswählen

deb http://ftp.de.debian.org/debian/ stretch main contrib
deb-src http://ftp.de.debian.org/debian/ stretch main contrib

deb http://security.debian.org/ stretch/updates main
deb-src http://security.debian.org/ stretch/updates main

deb http://ftp.de.debian.org/debian/ stretch-updates main
deb-src http://ftp.de.debian.org/debian/ stretch-updates main

Es werden noch drei weitere Dateien aus /etc/apt/sources.list.d angezogen, ich schreibe die mal hier alle untereinander:

Code: Alles auswählen

deb http://download.bareos.org/bareos/release/latest/Debian_8.0/ /
deb http://ftp.gwdg.de/pub/misc/cran/bin/linux/debian stretch-cran34/
deb http://download.virtualbox.org/virtualbox/debian stretch contrib

Brauchst du (oder jemand anderes) noch weitere oder detailliertere Informationen zur Hardware?

Wir haben den Rechner bei einem lokalen Systemhaus gekauft, Mitarbeiter von dort haben das System installiert. Warum die kein EFI installiert haben, kann ich leider nicht sagen.

[KP97]

Ich weiß gar nicht, warum ich Jessie im Kopf hatte, Du hast doch bereits ein Stretch....sorry für den falschen Schlenker...
Aber hier muß ich passen, wie schon geschrieben, mit RAID und Servern kenne ich mich nicht aus.
Gibt es wirklich kein /boot/efi/EFI auf dem System?

Was mir noch auffällt:
Die drei Einträge in der sources.list würde ich erstmal auskommentieren, speziell
deb http://download.bareos.org/bareos/relea ... ebian_8.0/ /
weist noch auf Jessie, keine gute Idee, dieser Mischmasch.

Falls sich kein anderer findet, der mehr zu Servern sagen kann, würde ich aber trotzdem mal den Rescuemode
versuchen. Ein Restore als letzte Möglichkeit geht ja immer noch.

[jenzuslongus]

Auf dem Rechner gibt es kein Verzeichnis bzw. keine Datei /boot/efi/EFI

Bei dem Eintrag von Bareos (Backup-Software) in den sources ist es so, dass die noch keine Pakete speziell für Stretch bereitstellen. Daher muss ich erst mal mit denen für Jessie weitermachen.

Vielen Dank aber schon mal für deinen Hilfe und die Hinweise.

[jenzuslongus]

Also, ich habe gestern Abend Folgendes gemacht (hat ein paar Stunden gedauert, ich kann mich nicht mehr an jedes Detail erinnern):

• Im BIOS auf EFI umgestellt, dort stand noch "Legacy"
• Per USB-Stick Debian Live gebootet
• chroot Umgebung eingerichtet und dorthin gewechselt (/mnt/aragorn ist der Mountpoint)
• apt wieder in geordneten Zustand gebracht über apt-get -f install
• Alle grub-Pakete per apt gelöscht
• /boot-Partition (/dev/sda1) als vfat "formatiert" und Partitionstyp auf EFI System geändert
• Aus chroot wieder raus und /dev/sda1 nach /mnt/aragorn/boot/efi gemountet. Dann wieder ins chroot rein
• grub-efi-amd64 (und abhängige Pakete) per apt installiert
• grub-install /dev/sda1 ausgeführt (jetzt gibt es auch das Verzeichnis /boot/efi/EFI)
• aktuellen Kernel installiert, lief jetzt reibungslos durch
• aus chroot raus und Rechner ohne Stick neu gebootet

Jetzt läuft wieder alles wie reibungslos, nur dass jetzt der grub-efi installiert ist.

Danke nochmal für eure Hilfe

[KP97]

Na, das freut mich für Dich, daß es jetzt funktioniert.
Da kann man mal sehen, was die "Experten" in den Systemhäusern so drauf haben und auch noch verkaufen für viel Geld. (Na ja, natürlich nicht alle...)

Noch ein Tipp:
Wenn Du eine Installations-CD (oder Stick) und den Rescuemode nutzt, kannst Du Dir das chrooten sparen.
Der Rescuemode bietet eine Shell und auch den Menüpunkt "Grub neu installieren". Auch wenn anfangs die gleichen Abfragen wie bei einer Installation erfolgen, wird dann nur in den Rettungsmodus gewechselt. Es passiert also nichts.
Das kann die Live-CD nicht.

[jenzuslongus]

Hallo zusammen,

ich muss das Thema leider nochmal aufwärmen. Beim letzten Kernel-Upgrade und beim jetzt anstehenden habe ich wieder das Problem, dass das Upgrade bei update-initramfs stecken bleibt.

Die Symptome sind wie beim ersten Mal, es hängen gerade u.a. diese zwei Prozesse:

Code: Alles auswählen

$ ps aux | grep grub
root       433  0.0  0.0   4288  1468 pts/33   S+   09:13   0:00 /bin/sh /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg
root       446  0.0  0.0  23604  3916 pts/33   D+   09:13   0:00 /usr/sbin/grub-probe --device /dev/mapper/vg00-lvRoot --target=fs_uuid

Da scheint irgendwie noch ein generelles Problem bei mir vorzuliegen, weil der untere Prozess in Status D verweilt. Hat einer eine Idee, wie man das Problem eingrenzen kann?

Wenn ich den Rechner neu starte und dann mit apt-get -f install "repariere", dann läuft der Rechner auch.

Grüße, Jens

[KP97]

Hallo Jens,

ist das nach der Installation von grub-efi-amd64 das erste Kernelupdate?
Du hast also die /dev/sda1 als EFI und /dev/sda2 als Datenpartition. Die /dev/sda1 blieb seither unberührt und hat nur die Ordner
/boot/efi/EFI/debian/grubx64.efi, ist das soweit richtig?
Du schreibst oben, Du hast den Grub in /dev/sda1 installiert, ist das ein Vertipper?
grub-install /dev/sda1 ausgeführt (jetzt gibt es auch das Verzeichnis /boot/efi/EFI)
Der Grub wird normalerweise nach /dev/sda2 installiert und nicht direkt in die EFI.

Warum der Prozeß hängt, dafür habe ich leider keine Erklärung.
Ein Neuschreiben der initrd.img mit update-initramfs bringt evtl. nichts, versuchen kann man es aber trotzdem mal.
Du könntest auch einen zusätzlichen Kernel entweder aus den Backports oder aus dem Archiv installieren, vielleicht sieht man dann mehr.

http://snapshot.debian.org/binary/linux ... 0-3-amd64/
http://snapshot.debian.org/binary/linux ... 0-1-amd64/
https://packages.debian.org/search?suit ... age-4.12.0

[jenzuslongus]

Hallo KP97,

nein, es ist das zweite Upgrade, aber beim ersten gab es dieselben Probleme. Ich bin dann wieder so vorgegangen wie im Workaround beschrieben.

Die /dev/sda1 ist nach /boot/efi gemountet:

Code: Alles auswählen

$ mount | grep sda1
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

Es gibt auf /dev/sda1, wie du schreibst, nur /boot/efi/EFI/debian/grubx64.efi.

/dev/sda2 ist "der ganze Rest", d.h. die Partition dient als Physical Volume in einem LVM.

Eine verkürzte Ausgabe der logical volumes sieht so aus:

Code: Alles auswählen

$ sudo lvdisplay | grep "LV Path"
  LV Path                /dev/vg00/lvSwap
  LV Path                /dev/vg00/lvRoot
  LV Path                /dev/vg00/lvTmp
  LV Path                /dev/vg00/lvHome

Müsste ich dann GRUB nach /dev/vg00/lvRoot installieren? Das wäre ja das Pendant zu /dev/sda2, wenn ich diese Partition direkt nutzen würde. Ich bin an der Stelle unsicher wegen des LVM.

[KP97]

Hallo Jens,
zu LVM kann ich leider nichts sagen, damit kenne ich mich nicht aus.
Evtl. installierst Du den Kernel mal nach /dev/vg00/lvRoot, einen Versuch wäre es wert, ändern kannst Du es ja immer noch.

In meinem Desktopsystem Sid habe ich die /dev/sda1 in der fstab auskommentiert.
Hintergrund war eine Meldung von systemd im Log:

boot-efi.mount: Directory /boot/efi to mount over is not empty, mounting anyway

Es soll wohl ein Bug sein, zumindest bei Fedora. An anderer Stelle hatte ich auch gelesen, daß es wohl Einfluß auf ein Kernelupgrade haben soll, den Hinweis finde ich aber nicht mehr wieder.
Ich habe keine negativen Auswirkungen durch das Auskommentieren feststellen können, vielleicht kannst Du das auch mal probieren. Wäre ja erstmal das Einfachste.


Leute, kann ihm denn da niemand mal weiterhelfen?
Es gibt hier doch eine ganze Menge Leute, die mit LVM fit sind und ganz sicher wissen, was er tun kann.
Ich kann es leider nicht, ich spekuliere hier nur rum und erzähle wahrscheinlich auch noch Quatsch obendrein.
Also, gebt euch mal einen Ruck....

[jenzuslongus]

Hallo zusammen,

ich habe den Rechner ohne Änderungen neu gestartet. Der Rechner fuhr normal hoch und läuft auch auf dem neuen Kernel. Mittels dpkg --configure -a und apt-get -f install war der Paketmanager auch wieder in einem sauberen Zustand.

Heute stand wieder ein Kernel-Update an. Das lief völlig ohne Probleme im ersten Anlauf durch. Das einzige "System", was ich erkennen kann, ist, dass das Kernel-Update nicht klappt, wenn der Rechner schon mehrere Wochen läuft. Darauf kann ich mir aber keinen Reim machen.

Viele Grüße, Jens

[wanne]

Hatte auf dem laptop das gleiche Problem defakto war es nur langsam.
Führe mal apt-get -f install und lasse ihn für eine weile alleine. Meiner hat sich nach ein paar Minuten augenscheinlichem nichts tun mit Erfolg zurückgemeldet.

[jenzuslongus]

Ich habe das mal für 11 Stunden hängen lassen, aber es tat sich nichts. Ich kann's ja beim nächsten Mal noch länger hängen lassen. Vielleicht hilft es ja.