Created attachment 530796 [details] /var/log/dracut.log Description of problem: Firmware missing - cannot ship it or if it is not required ? /var/log/dracut.log: ... I: Possible missing firmware "ct2fw.bin" for kernel module "bfa.ko" I: Possible missing firmware "ctfw.bin" for kernel module "bfa.ko" I: Possible missing firmware "cbfw.bin" for kernel module "bfa.ko" ... I: Possible missing firmware "isci/isci_firmware.bin" for kernel module "isci.ko" ... I: Possible missing firmware "ql2400_fw.bin" for kernel module "qla2xxx.ko" I: Possible missing firmware "ql2322_fw.bin" for kernel module "qla2xxx.ko" I: Possible missing firmware "ql2300_fw.bin" for kernel module "qla2xxx.ko" I: Possible missing firmware "ql2200_fw.bin" for kernel module "qla2xxx.ko" I: Possible missing firmware "ql2100_fw.bin" for kernel module "qla2xxx.ko" ... Version-Release number of selected component (if applicable): dracut-013-16.fc16.noarch How reproducible: Run live-cd. Steps to Reproduce: 1. as above 2. 3. Actual results: Expected results: Additional info:
It might be required for certain... the info, which files are used is encoded in the kernel modules, but we do not ship these firmwares for those modules.
This isn't a kernel problem. I doubt it's really a bug at all, given the limited space on the live images. The ql2xxx files are provided by the ql2400-firmware, ql23xx-firmware, ql2200-firmware, and ql2100-firmware packages. The ct*.bin files are provided by the bfa-firmware package. Reassigning to the spins component, where they can discuss the target machines vs. space of the LXDE live images.
With regard to: I: Possible missing firmware "isci/isci_firmware.bin" for kernel module "isci.ko" This is a different problem. http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=tree;f=firmware;hb=HEAD If I understand it correctly, this bin should be a part of linux-firmware package. But it is not. If so, then its maintainer should be asked to fix it. Right ? JB
So, looks like this would add about 500k or so to all the live media if we added those firmwares. I'm not sure this is a good use of space there however. How many qlogic using folks are going to install from a live media? I guess I don't feel too strongly about it either way, but some of the spins are very close to the max size, so adding this might mean something actually useful couldn't be shipped. ;(
(In reply to comment #4) > So, looks like this would add about 500k or so to all the live media if we > added those firmwares. > > I'm not sure this is a good use of space there however. > How many qlogic using folks are going to install from a live media? > > I guess I don't feel too strongly about it either way, but some of the spins > are very close to the max size, so adding this might mean something actually > useful couldn't be shipped. ;( I look at it fundamentally. Firmware is equivalent to a driver - if we enable a driver in a kernel then by definition its associated firmware should be available at any time the driver may be activated (loaded), regardless of the type of iso (live-cd/dvd/usb stick, net, full distro). Having a device driver enabled in a kernel and its firmware missing at time of e.g. a system boot is kind of silly. This is even more so if the firmware is still a part of the kernel itself as in case of isci_firmware.bin . Together, at any time, they determine if the particular hardware is available to the user. This is fundamentally more important than a presence of e.g. OpenOffice app on a particular distro medium. JB
If you want to discriminate between drivers/firmware based on their more or less wide use, and still consider it a primary criteria for completness, and to accommodate desires for as wide as possible user space/apps representation in live-cd offerings, but consider it a secondary criteria, then approach it by offering two sets of kernels and associated init ram images, one smaller (by excluding less widely used drivers and firmware) and one bigger (containing all possible drivers and firmware). Note: this can be extended to more or less widely used fs as well. This approach is already practised by some distros (CentOS, for example, with its CentOSPlus repo). That way you can have an open-ended and flexible system of handling hardware support requirements, and the iso sets. JB
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.