[kernel-xen] firmware conflict rtl8107e

Glenn Enright glenn at rimuhosting.com
Fri Aug 14 12:57:43 AEST 2015 

HI there

I'm still trying to figure out a way to help debug this. I'm confident 
adding the KRELEASE bit would work fine (thats how other distros do it), 
but without actually testing it I cant confirm for sure.

Turns out we dont have any hardware at present that needs firmware blobs 
loaded, that I can test on.

Meantime do you have another build that may actually install on the 
latest c6? Or could you make one?

Regards, Glenn
http://ri.mu - Startups start here.
Hosting. DNS. Web Programming. Email. Backups. Monitoring.

On 08/13/15 14:19, Steven Haigh wrote:
> On 13/08/15 10:56, Glenn Enright wrote:
>> I'll do that testing shortly.
>>
>> fwiw the latest 3.18.20-1 (from stable branch) reports this, so
>> something is still not right
>>
>> file /lib/firmware/cxgb4/t4fw.bin from install of
>> kernel-xen-firmware-3.18.20-1.el6xen.x86_64 conflicts with file from
>> package kernel-firmware-2.6.32-573.1.1.el6.noarch
>
> Chances are that the mirror that the buildroot probably hasn't been
> updated with the latest firmware package from the distro.
>
> I agree that if  we can get away with firmware in
> /lib/firmware/${%KRELEASE}/ then that would be the preferred solution.
>
> If you want to get picky, a kernel update for the stock stable kernel
> shouldn't be implementing new firmware - but hey - what do I know? ;)
>
>> Regards, Glenn
>> http://ri.mu - Startups start here.
>> Hosting. DNS. Web Programming. Email. Backups. Monitoring.
>>
>> On 08/13/15 11:45, Steven Haigh wrote:
>>> On 13/08/15 09:22, Glenn Enright wrote:
>>>> The docs seem to indicate that the release folder is actually checked
>>>> first, before the top level folder. So it should be safe to do that?
>>>> Happy to test it for you :)
>>>>
>>>> https://kernel.org/doc/Documentation/firmware_class/README
>>>
>>> I hadn't come across that as yet. Good find.
>>>
>>> If you can test it by moving all firmware to /lib/firmware/%{KRELEASE}/
>>> then that would be a great help.
>>>
>>> I currently only have one system that I *know* will break if
>>> request_firmware fails to load firmware. As it breaks the ethernet cards
>>> *and* its a live system, I'm not too keen on risking killing that system
>>> as a test ;)
>>>
>>>>
>>>> Regards, Glenn
>>>> http://rimuhosting.com
>>>> See more on our other services at http://ri.mu
>>>>
>>>> On 12/08/15 20:36, Steven Haigh wrote:
>>>>> On 12/08/15 16:22, Glenn Enright wrote:
>>>>>> HI there
>>>>>>
>>>>>> The issue is that we actually want the stock kernel installed still.
>>>>>> Along-side the kernel-xen package. As is, they block each other. Which
>>>>>> means we have to mess with our deployment scripts to make things work
>>>>>> temporarily.
>>>>>
>>>>> The stock kernel being present doesn't actually fix this problem.
>>>>> kernel-xen-firmware depends on kernel-firmware - which is why we do a
>>>>> bit of a dance. When kernel-xen-firmware is built, we automatically
>>>>> remove firmware that exists in kernel-firmware.
>>>>>
>>>>>>
>>>>>> Is there any reason the kernel-xen firmware package cant be
>>>>>> installed to
>>>>>> a version based location like the kernel modules (ie
>>>>>> /lib/firmware/%{KRELEASE})? This would save downstreams having to wait
>>>>>> on package releases to fix conflicts, and would also ease the
>>>>>> hassle on
>>>>>> package building?
>>>>>
>>>>> This would require some testing. I'm not sure exactly how the firmware
>>>>> loader works within the kernel - and if it requires things to be in a
>>>>> certain path or not. If you have an ethernet adapter that requires a
>>>>> firmware file to be uploaded (ie the bnx2 firmware), I would be
>>>>> interested to see if it still found the firmware files if they are
>>>>> moved
>>>>> to somewhere like /lib/firmware/%{KRELEASE}/blah
>>>>>
>>>>> The risk here (even on testing) is that the system may come back up
>>>>> without any ethernet adapters.
>>>>>
>>>>>>
>>>>>> Regards, Glenn
>>>>>> http://ri.mu - Startups start here.
>>>>>> Hosting. DNS. Web Programming. Email. Backups. Monitoring.
>>>>>>
>>>>>> On 08/12/15 17:33, Steven Haigh wrote:
>>>>>>> As long as this firmware file goes into the upstream packages, it
>>>>>>> should
>>>>>>> automatically be removed from the kernel-xen-firmware package when
>>>>>>> the
>>>>>>> next build comes out.
>>>>>>>
>>>>>>> Part of the build process gets *all* of the linux-firmware binaries,
>>>>>>> then removes ones that are provided by any package included in the
>>>>>>> stock
>>>>>>> distro repositories.
>>>>>>>
>>>>>>> In a nutshell, you can probably ignore the kernel-firmware package
>>>>>>> update for now, and the error should go away when the next build of
>>>>>>> kernel-xen-firmware comes along.
>>>>>>>
>>>>>>> On 12/08/15 12:56, Glenn Enright wrote:
>>>>>>>> Hi Steven, all
>>>>>>>>
>>>>>>>> Seeing a conflict with the latest centos kernel and firmware in
>>>>>>>> kernel-xen packages. Included below.
>>>>>>>>
>>>>>>>> Similar issue with the 3.14 kernels from stable. The -573 kernel
>>>>>>>> from
>>>>>>>> centos is new, so I guess this has just been introduced.
>>>>>>>>
>>>>>>>> Regards, Glenn
>>>>>>>> http://ri.mu - Startups start here.
>>>>>>>> Hosting. DNS. Web Programming. Email. Backups. Monitoring.
>>>>>>>>
>>>>>>>> file /lib/firmware/rtl_nic/rtl8107e-1.fw conflicts between attempted
>>>>>>>> installs of kernel-xen-firmware-3.18.14-1.el6xen.x86_64 and
>>>>>>>> kernel-firmware-2.6.32-573.1.1.el6.noarch
>>>>>>>>      file /lib/firmware/rtl_nic/rtl8107e-2.fw conflicts between
>>>>>>>> attempted
>>>>>>>> installs of kernel-xen-firmware-3.18.14-1.el6xen.x86_64 and
>>>>>>>> kernel-firmware-2.6.32-573.1.1.el6.noarch
>>>>>>>>      file /lib/firmware/rtl_nic/rtl8168h-1.fw conflicts between
>>>>>>>> attempted
>>>>>>>> installs of kernel-xen-firmware-3.18.14-1.el6xen.x86_64 and
>>>>>>>> kernel-firmware-2.6.32-573.1.1.el6.noarch
>>>>>>>>      file /lib/firmware/rtl_nic/rtl8168h-2.fw conflicts between
>>>>>>>> attempted
>>>>>>>> installs of kernel-xen-firmware-3.18.14-1.el6xen.x86_64 and
>>>>>>>> kernel-firmware-2.6.32-573.1.1.el6.noarch
>>>>>>>> _______________________________________________
>>>>>>>> kernel-xen mailing list
>>>>>>>> kernel-xen at lists.wireless.org.au
>>>>>>>> https://lists.wireless.org.au/mailman/listinfo/kernel-xen
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> kernel-xen mailing list
>>>>>>> kernel-xen at lists.wireless.org.au
>>>>>>> https://lists.wireless.org.au/mailman/listinfo/kernel-xen
>>>>>>>
>>>>>> _______________________________________________
>>>>>> kernel-xen mailing list
>>>>>> kernel-xen at lists.wireless.org.au
>>>>>> https://lists.wireless.org.au/mailman/listinfo/kernel-xen
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> kernel-xen mailing list
>>>>> kernel-xen at lists.wireless.org.au
>>>>> https://lists.wireless.org.au/mailman/listinfo/kernel-xen
>>>>>
>>>> _______________________________________________
>>>> kernel-xen mailing list
>>>> kernel-xen at lists.wireless.org.au
>>>> https://lists.wireless.org.au/mailman/listinfo/kernel-xen
>>>
>>>
>>>
>>> _______________________________________________
>>> kernel-xen mailing list
>>> kernel-xen at lists.wireless.org.au
>>> https://lists.wireless.org.au/mailman/listinfo/kernel-xen
>>>
>> _______________________________________________
>> kernel-xen mailing list
>> kernel-xen at lists.wireless.org.au
>> https://lists.wireless.org.au/mailman/listinfo/kernel-xen
>
>
>
> _______________________________________________
> kernel-xen mailing list
> kernel-xen at lists.wireless.org.au
> https://lists.wireless.org.au/mailman/listinfo/kernel-xen
>

More information about the kernel-xen mailing list