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.
There may be thousands of drivers you don't need, and it would be pointless to warn about every one of them - so why does it warn about these two in particular? If we can fix it and prevent the unnecessary warning, users will no longer have to go searching online to understand the warning and determine if it's a problem.
@CgCgCgCgCg you're not really addressing this excellent point. Don't you think it's annoying to hit every arch user on earth with this warning when only a tiny fraction actually need the firmware? Why not warn that every other irrelevant piece of firmware on earth has also not been installed, if this irrelevant warning appears? What makes it different? Maybe it is impossible to detect if this hardware is actually present until this firmware is installed?
Imagine if gcc spat out some totally irrelevant warning every time you compiled a program. Wouldn't you want that to be fixed? It's just annoying...
There may be thousands of drivers you don't need, and it would be pointless to warn about every one of them - so why does it warn about these two in particular? If we can fix it and prevent the unnecessary warning, users will no longer have to go searching online to understand the warning and determine if it's a problem.
@CgCgCgCgCg you're not really addressing this excellent point. Don't you think it's annoying to hit every arch user on earth with this warning when only a tiny fraction actually need the firmware? Why not warn that every other irrelevant piece of firmware on earth has also not been installed, if this irrelevant warning appears? What makes it different? Maybe it is impossible to detect if this hardware is actually present until this firmware is installed?
Imagine if gcc spat out some totally irrelevant warning every time you compiled a program. Wouldn't you want that to be fixed? It's just annoying...
You answered yourself (some of us did too above).
Feel free to ask Kernel developers for more information.
Here are some useful links:
https://www.kernel.org/category/contact-us.html
https://kernelnewbies.org/
There should at least be an option in mkinitcpio to ignore specific firmware warnings... That way, the first time a user sees the warning, they can search the Arch Wiki and then once they know they don't need that firmware, they can change mkinitcpio.conf to suppress those specific warnings.
@codydg Obviously you read nothing about those specific warnings above.
You "might" need those old SAS/SCSI Disk Controllers firmwares if you plan to use an old server.
The inevitable "Warnings" are there for the rest of us.
You like risking something not working in your system?
Sure, go ahead, install the firmwares, just to justify your OCD.
I fear that this may be trivializing serious mental challenges that people in this community and externally to it legitimately struggle with that we as a community with standards must be sensitive to if we truly seek to be inclusive, which is a goal of all technical communities, fora, other associated resources and the communities that are the means by which they operate.
Arch Linux itself states in the code of conduct we should attempt to treat others as we wish to be treated and I definitely don't want my own personal struggles that are unrelated to matters such as warnings from running pacman to be slung around as stigmatizing terms of abuse or means of supplying negative emphasis as is seemingly being done here to those who have to deal with the actual condition and the hardship it imposes on them. I suspect that is true of all of us.
Some individuals who struggle with OCD, a very real challenge that affects people of all sorts, are among those communities and I for one would like to be sure not alienate them though recognize your comment was intended to do so, in fact your sentiment I have actually come around to myself.
I am certainly guilty of using such terms so lightly in the past, but through reflection on these matters and seeing the ways that people struggle with challenges such as this as well as a litany of others, I have come to a crossroad where I think its best if we all, as a community, try to overcome this flourishes in our technical discussions that should remain as impartial as possible.
Nonetheless, I ask on behalf of all who struggle with mental health challenges, both within this community and external to it, that we all do our best to refrain for using a medical condition as describing behavior you seen as extraneous.
Additionally, here are some links about the condition in children, in general and in diagnosis that were informative and certainly deepened my empathy on the subject, helping me to further my empathy for those who struggle with it.
Edit: splitting it up a bit, making it easier to appreciate the sentiment at a glance. Added some links
There should at least be an option in mkinitcpio to ignore specific firmware warnings... That way, the first time a user sees the warning, they can search the Arch Wiki and then once they know they don't need that firmware, they can change mkinitcpio.conf to suppress those specific warnings.
This seems the practical and applicable approach I have seen thus far suggested.
If this problem lingers much longer, which it seems it just might, I will be going down the C rabbit holes of interest to it in the near enough future, I might just have to deal with myself (or with whom ever else simply wants this very real issue corrected)
As I see it, warnings that can then be disabled, individually or perhaps collectively (though that's less optimal) would be a reasonable means of achieving the goals of those who have joined the chorus of irritated users while not excluding the ever shrinking group that would find these warnings helpful from receiving them and taking appropriate action.
Being that silencing output is a regular option affixed to many programs, I can't imagine finding some means of doing so outside of the scope of the programming that has generated them and would enhance the overall professional appearance of Arch Linux, which it seems is a common goal to all camps and a motivating factor on both sides of this spirited discussion.
i have been ignoring these messages like texts from my ex since 2018, but now there's another warning i am seeing about some xhci_usb firmware missing, turns out it was because of a commit that introduced support for some udpXXXXX ranesas devices.
So does it mean every time support for some peculiar device is added, the rest of are going to have to deal with the warnings?Nay!
I announce 20 busty brown country side fed cows for the one who suppresses the error messages.
i have been ignoring these messages like texts from my ex since 2018, but now there's another warning i am seeing about some xhci_usb firmware missing, turns out it was because of a commit that introduced support for some udpXXXXX ranesas devices.
So does it mean every time support for some peculiar device is added, the rest of are going to have to deal with the warnings?Nay!
I announce 20 busty brown country side fed cows for the one who suppresses the error messages.
Quite a reward, for the bounty that is livestock surely we can find someone willing!
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/
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
No worries, I'm not aggressive, just in point.
These specific warnings are well known, and documented a lot in various places.
Of course, if you get a new warning, you should ask/discuss about it.
The reason -as mentioned above in the comments- is some servers need such SCSI firmwares to operate, while most of us don't use such SCSI hardware.
See this comment:
https://gist.github.com/imrvelj/c65cd5ca7f5505a65e59204f5a3f7a6d#gistcomment-2801492