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.