Fehler bei der Erzeugung des initramfs

[bluelupo]

Hallo zusammen,

habe seit einiger Zeit beim d-u einen Fehler, wenn ein update-initramfs ausgeführt wird. Der Fehler triff beim Zugriff auf das Swap-Device auf (Logical Volume LVswap). Bis jetzt habe ich noch keine negativen Auswirkungen mitbekommen.

Code Select Expand


[...]
liblvm2app2.2:amd64 (2.02.142-1) wird eingerichtet ...
liblvm2cmd2.02:amd64 (2.02.142-1) wird eingerichtet ...
dmeventd (2:1.02.116-1) wird eingerichtet ...
lvm2 (2.02.142-1) wird eingerichtet ...
update-initramfs: deferring update (trigger activated)
Trigger für libc-bin (2.21-9) werden verarbeitet ...
Trigger für initramfs-tools (0.123) werden verarbeitet ...
update-initramfs: Generating /boot/initrd.img-4.4.2-towo.1-siduction-amd64
/usr/sbin/mkinitramfs: 1: /etc/initramfs-tools/conf.d/resume: /dev/mapper/VGsys-LVswap: Permission denied
/usr/share/initramfs-tools/hooks/resume: 1: /etc/initramfs-tools/conf.d/resume: /dev/mapper/VGsys-LVswap: Permission denied


Die Ausgabe vom lvs Kommando ist okay.

Code Select Expand


  LV     VG    Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  LVhome VGsys -wi-ao---- 2,00g                                                   
  LVroot VGsys -wi-ao---- 7,00g                                                   
  LVswap VGsys -wi-ao---- 2,00g                                                   
  LVvar  VGsys -wi-ao---- 4,00g                                                   


Der Fehler wird vom Script /usr/share/initramfs-tools/hooks/resume gemeldet könnte also evtl. ein Bug sein. Hat jemand von euch den Fehler auch beobachtet?

[devil]

Ich habe letzthin diverse Probleme gehabt, die die Erzeugung einer Initrd auf einem UEFI-System betreffen. Da dort noch einige andere Dinge nicht richtig rund laufen, hab ich noch keinen genaueren Überblick, was da schief läuft.


greetz
devil

[bluelupo]

Ich hab' den gleichen Fehler jetzt in drei siduction VM's, also auf jeden Fall reproduzierbar.

Im Shellscript /usr/share/initramfs-tools/hooks/resume wird das Swap-Device ermittelt und das Ergebnis in /etc/initramfs-tools/conf.d/resume geschrieben. Der Pfad zum Swap-Device steht in dieser Datei, wie von mir erwartet.

An den Dateirechten kann's nicht liegen die sollten passen:

Code Select Expand


lrwxrwxrwx 1 root root 7 Feb 21 20:54 /dev/mapper/VGsys-LVswap -> ../dm-2
brw-rw---- 1 root disk 253, 2 Feb 21 20:54 /dev/dm-2


Aber wieso meckert dann mkinitramfs?

Code Select Expand


/usr/sbin/mkinitramfs: 1: /etc/initramfs-tools/conf.d/resume: /dev/mapper/VGsys-LVswap: Permission denied


/usr/sbin/mkinitramfs ist auch wieder ein Shellscript, allerdings reichlich kompliziert. Der Inhalt erschließt sich mir noch nicht ;-)

[der_bud]

Nur mal so ins Blaue - ich nutze hier nicht bewußt  Resume, und bei mit ist die /etc/initramfs-tools/conf.d/resume eine leere Datei. Kann es sein das getestet wird ob für Hibernate+Resume der Platz ausreicht um den Ram ins Swap zu sichern, vielleicht auch erst neuerdings? Ist die Swap groß genug dafür?

[bluelupo]

Hi der_bud,

bei mir ist das Swap LV (2GB) nie so groß wie tatsächliche RAM (8GB). Ich habe allerdings festgestellt das bei einer älteren Indiansummer-Installation die Datei resume die UUID des Swapdevices enthält und nicht wie hier in den drei VM's den Pfad zum Swapdevice.

[cryptosteve]

Moin,
ich bin heute über den gleichen Fehler gestolpert. Meine swap liegt ebenfalls im verschlüsselten lvm und ist ebenfalls nur 2GB groß (bei 32gb RAM-Größe). Die swap hat also eher nostalgische Gründe.

Mit Deinem Tip, die UUID in die /etc/initramfs-tools/conf.d/resume einzutragen, hat es dann aber funktioniert.

Und damit ich dann nach einem Reboot auch das Passwort eingeben bzw. die Anfrage dazu lesen konnte, musste ich noch das "splash" aus der Kernelzeile in /boot/grub/grub.conf entfernen - das kann aber auch an meinem System liegen und ist daher nicht allgemein gültig.