On 08/25/2016 02:42 PM, Walter H. wrote:

On 25.08.2016 20:24, ken wrote:

...

On 08/25/2016 12:08 PM, Walter H. wrote:

...

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

'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.

On 08/26/2016 12:02 AM, Walter H. wrote:

On Thu, August 25, 2016 23:21, ken wrote:

...

On 08/25/2016 02:42 PM, Walter H. wrote:

...

On 25.08.2016 20:24, ken wrote:

...

On 08/25/2016 12:08 PM, Walter H. wrote:

...

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

'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.

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 ]

...

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.

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.