In Arch Linux
mkinitcpio -p linux
shows
Possibly missing firmware for module: aic94xx
Possibly missing firmware for module: wd719x
git clone https://aur.archlinux.org/aic94xx-firmware.git
cd aic94xx-firmware
makepkg -sri
git clone https://aur.archlinux.org/wd719x-firmware.git
cd wd719x-firmware
makepkg -sri
and then mkinitcpio -p linux again.
Installing random binary blobs from the internet for hardware that you don't use has to be among the worst solutions for supressing a useless warning.
I have explained my point of view in above comments, but since I had a message about my vulgar (sic) ways, peeps with OCD issues can now relax.
mkinitcpio-firmware mentioned above installs the unnecessary firmware needed only by mkinitcpio to suppress the warnings.
Sorry, but I won't be commenting any more about it.
We've already discussed why this thread exists. Thousands of pieces of firmware exist. You could warn about them all, but that would make the warning useless, and it might as well be removed. So the question is: why does it warn about these 3? What if pacman warned you about random programs you don't have installed every time you used it?
Warnings are supposed to alert of possible errors, and ignoring them regularly leads to issues. If people want to keep the warning, I'd suggest stating in the warning what hardware the firmware is for so you don't have to scrape the internet to figure out if each one applies to you. But the warning seems irrelevant to me.
We've already discussed why this thread exists. Thousands of pieces of firmware exist. You could warn about them all, but that would make the warning useless, and it might as well be removed. So the question is: why does it warn about these 3? What if pacman warned you about random programs you don't have installed every time you used it?
Warnings are supposed to alert of possible errors, and ignoring them regularly leads to issues. If people want to keep the warning, I'd suggest stating in the warning what hardware the firmware is for so you don't have to scrape the internet to figure out if each one applies to you. But the warning seems irrelevant to me.
Couldn't agree more.
It seems utterly random and irrelevant.
Remove the warning OR at least add a link or an explaining text message.
So to my understanding, warnings are that- just warnings. Okey got it. And if we don't like it, take it to the kernel developers (or at least do some research because github isn't the best forum to complain or give suggestions, and to not waste anyone's busy time).
mkinitcpio-firmware
Optional firmware for the default linux kernel to get rid of the annoying 'WARNING: Possibly missing firmware for module:' messages
https://aur.archlinux.org/packages/mkinitcpio-firmware/
You went out of your way to create a package that installs the very firmware that the people in this thread are expressing concern about for the sole purpose of offering it up as a passive-aggressive 'remedy' to those concerns?
How about doing something constructive, such as making a package that easily removes firmware for non-present hardware entirely, warning messages and all?
I don't think that installing firmware for hardware that one doesn't have is an appropriate solution to this. I looked into this to find a better solution.
The logic is written in Bash. If you plan to never use SCSI, then copy “/usr/lib/initcpio/install/block” as “/etc/initcpio/install/block” and in the copy, change lines 6–9 from the following:
map add_module sd_mod? sr_mod? usb_storage? mmc_block? firewire-sbp2? virtio_blk?
# pata, sata, scsi, nvme
for filter in 'scsi/.*ata' '/(block|scsi|fusion|nvme)/' 'ata/[ps]ata_' \to the following:
map add_module usb_storage? mmc_block? firewire-sbp2? virtio_blk?
# pata, sata, nvme
for filter in '/(block|fusion|nvme)/' 'ata/[ps]ata_' \Feel free to reflect these changes in the help function in that file.
A custom hook (i.e. a hook in “/etc/initcpio/”) with the same name as a system hook (i.e. a hook in “/usr/lib/initcpio/”) overrides that system hook. If you want to use a different name for the custom hook, then you'll need to change the copy's file name and reflect that change in “/etc/mkinitcpio.conf”.
After running $ mkinitcpio --allpresets and rebooting my system, all seems to be in working order.
I don't think that installing firmware for hardware that one doesn't have is an appropriate solution to this. I looked into this to find a better solution.
The logic is written in Bash. If you plan to never use SCSI, then copy “/usr/lib/initcpio/install/block” as “/etc/initcpio/install/block” and in the copy, change lines 6–9 from the following:
map add_module sd_mod? sr_mod? usb_storage? mmc_block? firewire-sbp2? virtio_blk? # pata, sata, scsi, nvme for filter in 'scsi/.*ata' '/(block|scsi|fusion|nvme)/' 'ata/[ps]ata_' \to the following:
map add_module usb_storage? mmc_block? firewire-sbp2? virtio_blk? # pata, sata, nvme for filter in '/(block|fusion|nvme)/' 'ata/[ps]ata_' \Feel free to reflect these changes in the
helpfunction in that file.A custom hook (i.e. a hook in “/etc/initcpio/”) with the same name as a system hook (i.e. a hook in “/usr/lib/initcpio/”) overrides that system hook. If you want to use a different name for the custom hook, then you'll need to change the copy's file name and reflect that change in “/etc/mkinitcpio.conf”.
After running
$ mkinitcpio --allpresetsand rebooting my system, all seems to be in working order.
Finally - an answer instead of infighting. Will be trying this soon.
I get a little irritated with the warnings too. And I don't subscribe to the premise that we should ignore it either. Whenever someone takes to the arch forums with a problem, the first thing the elitists carry on about is that we don't pay close enough attention to the warnings and information printed out in the terminal. I don't understand why there isn't an option to blacklist modules from the image the same (or opposite as it were) as we add modules to the mkinitcpio.conf
Warning: Risk of decompression sickness when exiting a submarine 200 meters below sealevel and ascending too fast -- Graffiti on a trainstation in inner Mongolia).
For real though, it's a useless warning and shouldn't happen. It should detect we don't have the hardware in question and not even consider warning us about it. It shouldn't be suppressed or worked around by installing useless firmware, it just shouldnn't happen in the first place. Call it OCD, but when people see big fat orange letters in their package-manager output when updating their system, they get worried. In this case unnecessarily.
Thanks a bunch to @tylercrompton for the explanation and the solution provided (see https://gist.github.com/imrvelj/c65cd5ca7f5505a65e59204f5a3f7a6d#gistcomment-3827257).
I agree with everybody saying that it shall be possible to suppress those warnings, without having to install any packages for hardware actually not present in the system.
Currently, the problem seems to be that the logic in the block hook simply runs over the entire drivers/scsi kernel modules directory, thus including all modules present there.
A possibility to at least exclude single modules from this search would be desirable, perhaps by introducing some kind of blacklist to be checked by block when it is run.
Oh thanks! @CgCgCgCgCg and thanks @tylercrompton for bringing my brain salvation. and @ZarathustraDK for the laugh.
I can sleep again at night ❤️
https://gist.github.com/imrvelj/c65cd5ca7f5505a65e59204f5a3f7a6d?permalink_comment_id=3827257#gistcomment-3827257 @tylercrompton
Your workaround works wonder against those scsi controller warnings.
Any idea how to suppress xhci_pci line?
Hey, I agree with some of the commenters that a rough tone and elitist hand waving are not really the right approaches to a healthy community. I find these quite destructive attitudes. Sure, if there is no way to know if a driver is needed without having it installed (because you can't talk to the hardware) then the warning might be unavoidable. Either way, it's very confusing to many users and might be a red herring if you're actually investigating issues with your system (like I was with wakeup from suspend issues).
I find it surprising that despite all the aggressive handwaving of obviously knowledgeable users, noone actually mentions that one can simply check if a firmware is needed by running sudo dmesg | grep firmware_that_might_be_missing and fill in the appropriate name. If that command turns up blank, then you can ignore the warning. I found that method in another thread.
From a standpoint of a warning that is unavoidable and how to make it more newbie (or little time to research) friendly, maybe just including a method of investigating further might be useful directly in the warning text itself. The Rust compiler accompanies errors or warning with ways to fix them when possible. I like that approach. The Rust community does a lot right, also when setting an inclusive tone.
Either way, maybe the dmesg method is actually not viable, too, for some reason: Then please let us know. But either way, I would appreciate a collaborative and constructive tone.
Hey, I agree with some of the commenters that a rough tone and elitist hand waving are not really the right approaches to a healthy community. I find these quite destructive attitudes. Sure, if there is no way to know if a driver is needed without having it installed (because you can't talk to the hardware) then the warning might be unavoidable. Either way, it's very confusing to many users and might be a red herring if you're actually investigating issues with your system (like I was with wakeup from suspend issues).
I find it surprising that despite all the aggressive handwaving of obviously knowledgeable users, noone actually mentions that one can simply check if a firmware is needed by running
sudo dmesg | grep firmware_that_might_be_missingand fill in the appropriate name. If that command turns up blank, then you can ignore the warning. I found that method in another thread.From a standpoint of a warning that is unavoidable and how to make it more newbie (or little time to research) friendly, maybe just including a method of investigating further might be useful directly in the warning text itself. The Rust compiler accompanies errors or warning with ways to fix them when possible. I like that approach. The Rust community does a lot right, also when setting an inclusive tone.
Either way, maybe the dmesg method is actually not viable, too, for some reason: Then please let us know. But either way, I would appreciate a collaborative and constructive tone.
I really dig you're take on this. And thanks for the dmesg advice
mkinitcpio-firmware
Optional firmware for the default linux kernel to get rid of the annoying 'WARNING: Possibly missing firmware for module:' messages
https://aur.archlinux.org/packages/mkinitcpio-firmware/