Your message dated Mon, 08 Sep 2014 09:57:48 +0200
with message-id <540d617c.5030...@debian.org>
and subject line Re: Bug#760765: Acknowledgement (intel-microcode: breaks 
initrd for newer kernels)
has caused the Debian Bug report #760765,
regarding intel-microcode: breaks initrd for newer kernels
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
760765: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760765
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: intel-microcode
Version: 2.20140624.1
Severity: critical
Justification: breaks the whole system

hi

I have installed a small wheezy system, and then promptly
upgraded it to jessie. This system has rootfs crypted
with cryptsetup (altogh I am not sure this is relevant).

I have two kernel currently in /boot, 3.14-2-amd64 and 3.2.0-4-amd64,
I can boot the system with the latter, but not with the former.

When I try to boot using 3.14-2-amd64 , the scripts in initrd
complain that it cannot find the rootfs.

I tried to investigate the problem, and found this startling
fact. Usually initrd.img is a CPIO archive, compressed
with GZIP. Instead, initrd.img-3.14-2-amd64 is a CPIO file
but not compressed, and it seems to contain only this file

$ cpio -t < /boot/initrd.img-3.14-2-amd64
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/GenuineIntel.bin

(even if initrd.img-3.14-2-amd64  is itself quite large, roughly 14MB).

After some fiddling, I noted that if I delete the file
 /usr/share/initramfs-tools/hooks/intel_microcode
and regenerate initrd.img-3.14-2-amd64
then it is fine. Unfortunately I cannot understand
why it is broken.

You may find the broken initrd in
  http://mennucc1.debian.net/tmp/initrd.img-3.14-2-amd64

I attach 3 files, that are the output of
 $ update-initramfs -v -u  -k 3.14-2-amd64

3.14~no~microcode : the output when 
/usr/share/initramfs-tools/hooks/intel_microcode is deleted

3.14~with~microcode : the output when 
/usr/share/initramfs-tools/hooks/intel_microcode is present

3.14~with~microcode~xz : the output when I add 'set -zx' to  
/usr/share/initramfs-tools/hooks/intel_microcode

a.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages intel-microcode depends on:
ii  iucode-tool  1.0.3-1

Versions of packages intel-microcode recommends:
ii  initramfs-tools  0.116

intel-microcode suggests no packages.

-- no debconf information

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)

Attachment: 3.14~no~microcode.gz
Description: application/gzip

Attachment: 3.14~with~microcode.gz
Description: application/gzip

Attachment: 3.14~with~microcode~xz.gz
Description: application/gzip

Attachment: signature.asc
Description: Digital signature


--- End Message ---
--- Begin Message ---
hi

after fiddling with it for a while, my host would not boot with any
kernel, regardless of the presence of intel-microcode, or not!

So I eventually noted that there was a typo in the UUID for the crypted
root in /etc/crypttab    :->

Also I did not know about 'hybrid initramfs' (is there any documentation
around? could not find any); I also found bug
http://bugs.debian.org/717805 , it is really a pity.

So it seems that intel-microcode was not at fault.

Sorry for the noise.

a.


Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---

Reply via email to