[opensuse-factory] Broken /boot/initrd file after latest upgrade (Tumbleweed 20160519)
After latest Tumbleweed update (20160519) the initrd generation is somehow broken on my computer. The Kernel 4.5.4-1-default still boots (only to text mode, but graphics mode can be selected manually). But the initrd file is mysterious: 1) It is not compressed: file /boot/initrd-`uname -r` /boot/initrd-4.5.4-1-default: ASCII cpio archive (SVR4 with no CRC) 2) It contains only two files and some directories: # cpio --extract --make-directories --verbose < /boot/initrd-`uname -r` . early_cpio kernel kernel/x86 kernel/x86/microcode kernel/x86/microcode/GenuineIntel.bin 16 blocks 3) It is bigger than the content: # du -h 12K ./kernel/x86/microcode 16K ./kernel/x86 20K ./kernel 28K . # ls -lh /boot/initrd-`uname -r` -rw-r--r-- 1 root root 7.2M May 21 13:20 /boot/initrd-4.5.4-1-default The dracut log file /var/log/YaST2/mkinitrd.log looks OK on the first view: I: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.5.4-1-default 4.5.4-1-default I: *** Including module: bash *** I: *** Including module: systemd *** I: *** Including module: warpclock *** I: *** Including module: systemd-initrd *** I: *** Including module: i18n *** I: *** Including module: kernel-modules *** I: *** Including module: resume *** I: *** Including module: rootfs-block *** I: *** Including module: terminfo *** I: *** Including module: udev-rules *** I: Skipping udev rule: 40-redhat.rules I: Skipping udev rule: 50-firmware.rules I: Skipping udev rule: 50-udev.rules I: Skipping udev rule: 91-permissions.rules I: Skipping udev rule: 80-drivers-modprobe.rules I: *** Including module: dracut-systemd *** I: *** Including module: haveged *** I: *** Including module: usrmount *** I: *** Including module: base *** I: *** Including module: fs-lib *** I: *** Including module: shutdown *** I: *** Including module: suse *** I: *** Including modules done *** I: *** Installing kernel module dependencies and firmware *** I: *** Installing kernel module dependencies and firmware done *** I: *** Resolving executable dependencies *** I: *** Resolving executable dependencies done*** I: *** Hardlinking files *** I: *** Hardlinking files done *** I: *** Stripping files *** I: *** Stripping files done *** I: *** Generating early-microcode cpio image *** I: *** Constructing GenuineIntel.bin **** I: *** Store current command line parameters *** I: Stored kernel commandline: I: resume=UUID=93313bb7-d7cd-4978-9882-079d4a803b72 resume=UUID=7c287338-bb71-41e1-a5cf-789f6fea25d3 I: root=UUID=2d968229-cc2f-4813-b299-2b989a76006a rootfstype=ext4 rootflags=rw,relatime,errors=remount-ro,data=ordered I: *** Creating image file '/boot/initrd-4.5.4-1-default' *** I: *** Creating initramfs image file '/boot/initrd-4.5.4-1-default' done *** What is going on here? How can I recover a valid initrd file (it's not in my backups)? Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2016-05-21 13:38, Bjoern Voigt wrote:
1) It is not compressed:
file /boot/initrd-`uname -r` /boot/initrd-4.5.4-1-default: ASCII cpio archive (SVR4 with no CRC)
file is not able to handle chained cpio archives. What it reports is correct though: the first part is a cpu firmware (on some machines), followed by the - not reported - second compressed part.
2) It contains only two files and some directories:
# cpio --extract --make-directories --verbose < /boot/initrd-`uname -r`
cpio is unable to handle chained cpio archives.
. early_cpio kernel kernel/x86 kernel/x86/microcode kernel/x86/microcode/GenuineIntel.bin 16 blocks
3) It is bigger than the content:
# du -h 12K ./kernel/x86/microcode 16K ./kernel/x86 20K ./kernel 28K .
All normal given the above. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
On Saturday 2016-05-21 13:38, Bjoern Voigt wrote:
1) It is not compressed:
file /boot/initrd-`uname -r` /boot/initrd-4.5.4-1-default: ASCII cpio archive (SVR4 with no CRC) file is not able to handle chained cpio archives. What it reports is correct though: the first part is a cpu firmware (on some machines), followed by the - not reported - second compressed part.
2) It contains only two files and some directories:
# cpio --extract --make-directories --verbose < /boot/initrd-`uname -r` cpio is unable to handle chained cpio archives.
. early_cpio kernel kernel/x86 kernel/x86/microcode kernel/x86/microcode/GenuineIntel.bin 16 blocks
3) It is bigger than the content:
# du -h 12K ./kernel/x86/microcode 16K ./kernel/x86 20K ./kernel 28K . All normal given the above. Ok, thank, Jan.
This must be a modern way or SUSE way to create initrd files. Unfortunately most Internet blogs still show the old way to analyze initrd files (first: gunzip the initrd file; second: extract the cpio file). It there a documentation for analyzing the initrd files in the modern format? I read something, that I have to skip some blocks in the header to get the embedded "lzma" compressed file. Here is a script with should do this (not tested): http://forum.xda-developers.com/wiki/Extract_initramfs_from_zImage_compresse... Unfortunately one of my two problems is still unsolved. The first problem (system only boots to text mode with Kernel 4.5.4-1-default) does not occur anymore. The second problem still persists after calling "mkinitrd" and "grub2-mkconfig -o /boot/grub2/grub.cfg" again and again: Because Kernel 4.6 (e.g. from kernel_stable repo) is currently incompatible with NVidia driver, I currently want to stay on the 4.5.x kernel series. I manually patched the Kernel sources kernel-source-4.5.4-1.1.noarch.rpm from Tumbleweed with the 4.5.4 to 4.5.5 vanilla Kernel patch (https://cdn.kernel.org/pub/linux/kernel/v4.x/incr/patch-4.5.4-5.xz) without conflicts and compiled and installed the Kernel with "make binrpm-pkg" and "rpm -ivh ...". I deselected the Kernel options "CONFIG_DEBUG_KERNEL" and "CONFIG_EXPERT" because otherwise the Kernel RPM files get 10x bigger than normal. The Kernel 4.5.5-mykernel worked until today. Today I updated the system to the latest Tumbleweed snapshot 20160519. But now I have the following problem with the 4.5.5-mykernel: 1) I select the Kernel in Grub2: openSUSE, with Linux 4.5.5-mykernel 2) Then I see Loading Linux 4.5.5-mykernel .... Loading initial ramdisk ... 3) The screen clears and the system stops booting with uncompression error -- System halted Maybe the initrd is incorrectly at least for my Kernel or my Kernel is incapable of decompressing the used initrd format. Could deselection of CONFIG_EXPERT caused the problem? But the Kernel worked yesterday. Any ideas? Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On samedi, 21 mai 2016 14.33:32 h CEST Bjoern Voigt wrote:
Jan Engelhardt wrote:
On Saturday 2016-05-21 13:38, Bjoern Voigt wrote:
1) It is not compressed:
file /boot/initrd-`uname -r` /boot/initrd-4.5.4-1-default: ASCII cpio archive (SVR4 with no CRC) file is not able to handle chained cpio archives. What it reports is correct though: the first part is a cpu firmware (on some machines), followed by the - not reported - second compressed part.
2) It contains only two files and some directories:
# cpio --extract --make-directories --verbose < /boot/initrd-`uname -r` cpio is unable to handle chained cpio archives.
. early_cpio kernel kernel/x86 kernel/x86/microcode kernel/x86/microcode/GenuineIntel.bin 16 blocks
3) It is bigger than the content:
# du -h 12K ./kernel/x86/microcode 16K ./kernel/x86 20K ./kernel 28K . All normal given the above. Ok, thank, Jan.
This must be a modern way or SUSE way to create initrd files. Unfortunately most Internet blogs still show the old way to analyze initrd files (first: gunzip the initrd file; second: extract the cpio file). It there a documentation for analyzing the initrd files in the modern format? I read something, that I have to skip some blocks in the header to get the embedded "lzma" compressed file. Here is a script with should do this (not tested): http://forum.xda-developers.com/wiki/Extract_initramfs_from_zImage_compresse...
Unfortunately one of my two problems is still unsolved.
The first problem (system only boots to text mode with Kernel 4.5.4-1-default) does not occur anymore.
The second problem still persists after calling "mkinitrd" and "grub2-mkconfig -o /boot/grub2/grub.cfg" again and again: Because Kernel 4.6 (e.g. from kernel_stable repo) is currently incompatible with NVidia driver, I currently want to stay on the 4.5.x kernel series. I manually patched the Kernel sources kernel-source-4.5.4-1.1.noarch.rpm from Tumbleweed with the 4.5.4 to 4.5.5 vanilla Kernel patch (https://cdn.kernel.org/pub/linux/kernel/v4.x/incr/patch-4.5.4-5.xz) without conflicts and compiled and installed the Kernel with "make binrpm-pkg" and "rpm -ivh ...". I deselected the Kernel options "CONFIG_DEBUG_KERNEL" and "CONFIG_EXPERT" because otherwise the Kernel RPM files get 10x bigger than normal.
The Kernel 4.5.5-mykernel worked until today. Today I updated the system to the latest Tumbleweed snapshot 20160519.
But now I have the following problem with the 4.5.5-mykernel:
1) I select the Kernel in Grub2:
openSUSE, with Linux 4.5.5-mykernel
2) Then I see
Loading Linux 4.5.5-mykernel .... Loading initial ramdisk ...
3) The screen clears and the system stops booting with
uncompression error
-- System halted
Maybe the initrd is incorrectly at least for my Kernel or my Kernel is incapable of decompressing the used initrd format. Could deselection of CONFIG_EXPERT caused the problem? But the Kernel worked yesterday.
Any ideas?
Greetings, Björn
What kind of cpu and nvidia did you have. I've a Xeon E3-1535M Skylake + Quadro M2000M and both of them work quite well. First on 4.5.4 kernel without trouble. But I desactivate the intel gpu so no optimus. Actually 4.5.4 initrd is directly an xz (But I guess I don't need direct patches for the cpu since last bios update made by dell 2 weeks ago) There's a newer NVIDIA-Linux-x86_64-367.18.run drivers release few day ago. And for the previous one NVIDIA-Linux-x86_64-364.19.run you can apply the attached patch, it has worked for me for 4.5 and 4.6 kernel I've stopped using 4.6 due to really deviant comportement with udev (not find LABEL disk etc). Even if last version will have long awaited fixes for dell_laptop module. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot
Bjoern Voigt wrote:
This must be a modern way or SUSE way to create initrd files.
It's dracut.
Unfortunately most Internet blogs still show the old way to analyze initrd files (first: gunzip the initrd file; second: extract the cpio file). It there a documentation for analyzing the initrd files in the modern format?
To start with, "lsinitrd" for listing the contents.
I read something, that I have to skip some blocks in the header to get the embedded "lzma" compressed file.
Something like that. I think I've done it, but I can't remember the exact steps. -- Per Jessen, Zürich (22.0°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Samstag, 21. Mai 2016 15:35:04 CEST Per Jessen wrote:
Bjoern Voigt wrote:
This must be a modern way or SUSE way to create initrd files.
It's dracut.
Unfortunately most Internet blogs still show the old way to analyze initrd files (first: gunzip the initrd file; second: extract the cpio file). It there a documentation for analyzing the initrd files in the modern format?
To start with, "lsinitrd" for listing the contents.
I read something, that I have to skip some blocks in the header to get the embedded "lzma" compressed file.
Something like that. I think I've done it, but I can't remember the exact steps.
*if* you really want to do it manually: $> cpio -vt < /boot/initrd-4.5.2-1-default drwxr-xr-x 1 root root 0 May 20 02:31 . -rw-r--r-- 1 root root 2 May 20 02:31 early_cpio drwxr-xr-x 1 root root 0 May 20 02:31 kernel drwxr-xr-x 1 root root 0 May 20 02:31 kernel/x86 drwxr-xr-x 1 root root 0 May 20 02:31 kernel/x86/microcode -rw-r--r-- 1 root root 20480 May 20 02:31 kernel/x86/microcode/ GenuineIntel.bin 42 blocks tail -c +$((512*42 + 1)) /boot/initrd-4.5.2-1-default | xzcat | cpio -t . bin bin/bash bin/cat bin/chown ... Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, May 21, 2016 at 04:44:10PM +0200, Stefan Bruens wrote: [...]
*if* you really want to do it manually:
$> cpio -vt < /boot/initrd-4.5.2-1-default drwxr-xr-x 1 root root 0 May 20 02:31 . -rw-r--r-- 1 root root 2 May 20 02:31 early_cpio drwxr-xr-x 1 root root 0 May 20 02:31 kernel drwxr-xr-x 1 root root 0 May 20 02:31 kernel/x86 drwxr-xr-x 1 root root 0 May 20 02:31 kernel/x86/microcode -rw-r--r-- 1 root root 20480 May 20 02:31 kernel/x86/microcode/ GenuineIntel.bin 42 blocks
tail -c +$((512*42 + 1)) /boot/initrd-4.5.2-1-default | xzcat | cpio -t . bin bin/bash bin/cat bin/chown ...
There's also a tool for this: /usr/lib/dracut/skipcpio e.g. /usr/lib/dracut/skipcpio initrd-4.5.4-1-default > initrd.xz xz -d initrd.xz cpio -idv < initrd -- ======================== Roger Whittaker roger@disruptive.org.uk http://disruptive.org.uk ======================== -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Roger Whittaker wrote:
On Sat, May 21, 2016 at 04:44:10PM +0200, Stefan Bruens wrote:
[...]
*if* you really want to do it manually:
$> cpio -vt < /boot/initrd-4.5.2-1-default drwxr-xr-x 1 root root 0 May 20 02:31 . -rw-r--r-- 1 root root 2 May 20 02:31 early_cpio drwxr-xr-x 1 root root 0 May 20 02:31 kernel drwxr-xr-x 1 root root 0 May 20 02:31 kernel/x86 drwxr-xr-x 1 root root 0 May 20 02:31 kernel/x86/microcode -rw-r--r-- 1 root root 20480 May 20 02:31 kernel/x86/microcode/ GenuineIntel.bin 42 blocks
tail -c +$((512*42 + 1)) /boot/initrd-4.5.2-1-default | xzcat | cpio -t . bin bin/bash bin/cat bin/chown ... There's also a tool for this:
/usr/lib/dracut/skipcpio
e.g.
/usr/lib/dracut/skipcpio initrd-4.5.4-1-default > initrd.xz
xz -d initrd.xz
cpio -idv < initrd Ok, thanks for the "skipcpio" and "lsinitrd" commands.
The second problem (my own Kernel 4.5.5 stopped with an "uncompression error") is now solved too. My /boot filesystem is on an USB stick. I made a "fsck -f" filesystem check there. After reinstalling the kernel-default-4.5.4-1.1.x86_64 kernel, this Kernel could boot again. Now I reinstalled my own Kernel 4.5.5-mykernel from RPM. This Kernel now also boots. I compared the MD5 checksums before and after reinstalling my Kernel in RPM format. The MD5 checksum of /boot/vmlinuz-4.5.5-mykernel changed. So I am relatively sure, that all the problems came from an Ext4 filesystem corruption on my USB stick. You may ask, why I do not use /boot on hard-disk and why I do not use NVidia 364.19 driver with the Kernel 4.6 patch: 1. UEFI on my Intel DH55TC mainboard is incomplete. Partitioning the hard disk and SSD with GPT and booting from USB solved my UEFI problems. 2. Last time I tested the NVidia 364 driver series I had the problem, that VDPAU deinterlacing modules didn't worked in MythTV. So I like to wait until the NVidia 364 drivers are production ready. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Carlos E. R. wrote:
On 2016-05-21 13:38, Bjoern Voigt wrote:
What is going on here? How can I recover a valid initrd file (it's not in my backups)? It should be "mkinitrd". Of course I already tried this. But "mkinitrd" produces the same "initrd" files.
Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-05-21 13:58, Bjoern Voigt wrote:
Carlos E. R. wrote:
On 2016-05-21 13:38, Bjoern Voigt wrote:
What is going on here? How can I recover a valid initrd file (it's not in my backups)? It should be "mkinitrd". Of course I already tried this. But "mkinitrd" produces the same "initrd" files.
Well, Jan has explained the new format for this archive. The issue is whether your machine boots correctly or not. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
participants (7)
-
Bjoern Voigt -
Bruno Friedmann -
Carlos E. R. -
Jan Engelhardt -
Per Jessen -
Roger Whittaker -
Stefan Bruens