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.
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
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
blockhook simply runs over the entiredrivers/scsikernel 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
blockwhen it is run.