Info Wanted About Meaning Of Boot Messages …

Home » CentOS » Info Wanted About Meaning Of Boot Messages …
CentOS 6 Comments

Hello,

I’ve got CentOS 6.8 x64, updated today to the latest by ‘yum update’
this installed a new kernel: 2.6.32-642.4.2.el6.x86_64

in /var/log/boot.log I found these 3 lines …

No kdump initial ramdisk found. [WARNING]
Rebuilding /boot/initrd-2.6.32-642.4.2.el6.x86_64kdump.img cp: cannot stat `/lib/firmware/i915/bxt_dmc_ver1.bin’: No such file or directory

the first two are logic to me, but the 3rd line, did there something fail at the update?

Thanks, Walter

6 thoughts on - Info Wanted About Meaning Of Boot Messages …

  • ‘stat’ is a command. It’s like ‘ls’, but gives more info. Try it. The message is saying simply that the file can’t be found. It looks like the install script was trying to ‘cp’ that file.

  • the directory from above shows with ‘ls -al /lib/firmware/i915/’ this:

    total 156
    drwxr-xr-x. 2 root root 4096 Aug 25 10:08 . drwxr-xr-x. 46 root root 12288 Aug 23 17:28 ..
    -rw-r–r–. 1 root root 8824 Aug 23 21:14 skl_dmc_ver1.bin
    -rw-r–r–. 1 root root 128320 Aug 23 21:14 skl_guc_ver4.bin

    means, that the file from above message isn’t there …

    when I do ‘cat /etc/rc.d/init.d/* | grep “bxt”‘ there is nothing shown;
    from where did this cp come from above’s error message?

    Thanks Walter

  • Walter, it would seem then that one of the boot scripts is calling another script […] which is then calling another script which is yielding the boot message. I gave you the […] because there could be several layers of such wrappers. So it might well take a bit of drilling down and poking around to find the source of that boot message from that end.

    You might also try ‘rpm -qf /lib/firmware/i915’ to see if that narrows down the sought executable to a specific rpm. Then do ‘rpm -ql
    [package_name]’ to get a listing of the files in that package.

    In some cases you can use ‘trace’, but I’m almost always found this to be a source of too much information.

    If at this point you’re saying, “there’s gotta be an easier way”, well, you’re right. Maybe in the sequel to Linux there will be.

    Have fun.

  • As it seems this has been a one time thing; I restartet the box again this morning and now /etc/log/boot.log looks fine:

    the part were the error of above was shown …

    Mounting filesystems: [ OK ]
    Starting acpi daemon: [ OK ]
    Starting HAL daemon: [ OK ]
    Retrigger failed udev events [ OK ]
    Starting kdump: [ OK ]
    Starting radvd: [ OK ]
    Starting sshd: [ OK ]

    I guess this would be impossible now, because of a one time thing …

    Greetings, Walter

  • Not impossible, but if the problem seems to be gone, then the purpose of a non-developer pursuing it would come into question.