большая часть этих драйверов _в_принципе_ неработоспособна на ix86 - не бывает у них gpio разъемов (если и бывает такая экзотика то драйвера от одноплатников точно там не подойдут)

и драйвер ipod'а давно пора выкинуть. И аналоговых джойстиков сто лет как не делают.

Актуальных модулей (не драйверов) оказалось штук сорок. Остальные низачем не нужны и только увеличивают attack surface до вселенских размеров. Попутно, кстати, набрел на частичное решение своего давнего вопроса - какого хрена линукс вообще неотключаемо загружает что попало.
делай раз: sysctl dev.tty.ldisc_autoload=0 # досвиданья бесконечные руты прямо из pty
делай два:
CONFIG_STATIC_USERMODEHELPER=y
CONFIG_STATIC_USERMODEHELPER_PATH="/sbin/request-key"
(это заодно сломает е6yчий докер, туда ему и дорога. request-key - деталька от kerberos/dfs cifs mount, он нужный)

> И для всего остального - пожалуйте на винду

в которой драйвер несуществующего в твоей системе устройства вообще отсутствует у тебя на диске, даже в отключенном и неработающем виде, и ставится только по требованию.

(да и как будто раньше кто-то что-то проверял кроме правильного написания colour?)

ну и кстати, вот, заняло сильно больше 15 минут. Можешь перепроверять.

What CVE-2024-42102 actually is: an integer-overflow class bug in the
  dirty-page throttling logic (mm/page-writeback.c). The code assumes dirty
  limits expressed in PAGE_SIZE units fit in 32 bits so the various
  multiplications stay inside 64 bits. If they don't, you get overflows and
  potential divide-by-zero.
[skip, там еще и кожановые дважды налажали в попытках исправить то что исправлять вообще не надо]
Is the real fix needed here? The vulnerable shape is genuinely present —
  4.15's domain_dirty_limits() has no clamp, and the fix doesn't apply (forward
  or reverse) because the surrounding code has drifted seven years.

  But the author states the trigger outright: "This is root-only triggerable
  problem which occurs when the operator sets dirty limits to >16 TB." Two ways
  to get there, and neither exists on this fleet:

  - Root writes an absurd value to vm.dirty_bytes / vm.dirty_background_bytes —
  root-only sysctls, and root can already do far worse
  - vm.dirty_ratio is a percentage capped at 100, so reaching a 16 TB limit that
  way needs >16 TB of available memory.

и заметь - это CVE 2024 го года, кожанновые принесли бред во имя луны без всякой помощи ЫЫ.

Который вот потыкал в очередную лужицу и сейчас моргает глазом, ждет что я ему подтвержу "not needed", и поехали следующий.

Т.е. есть _высокий_ шанс что из тех 1815 большая часть - сильно более полезны чем такое вот.