Je zegt "(Een scriptje op je bureaublad zetten met daarin "gksudo 'modprobe -r <lijst van kernel-modules die niet nodig zijn>'" is nu ook niet echt de aangewezen oplossing toch...)"
Je zou dat scriptje in het bestand /etc/rc.local kunnen opnemen.
Ik begrijp wat je wil voorstellen, maar ik ben eerder een oorzaak-bestrijder dan een symptoom-bestrijder. (Ja, soms doe ik al eens lastig
) Het zou inderdaad ervoor kunnen zorgen dat ze niet meer geladen zijn zodra ik op mijn desktop aankom, maar dan blijft het nog altijd wel zo, dat telkens ik wat hardware eenmalig test, ik manueel dat lijstje moet aanvullen. Ik zou liever begrijpen waarom die modules worden onthouden (is het een bug of een feature) en of daar iets aan te doen valt. Maar het zou er in ieder geval ervoor zorgen dat het script automatisch aangesproken wordt, i.p.v. dat ik het manueel zou moeten aanklikken, dat is zeker waar.
Daarnaast vond ik nog dit artikel (maar helaas nog geen kerneld voor Ubuntu gevonden);
EDIT; ik zie nu dat dit uit 2000 stamt. Dat zal wel achterhaald zijn inmiddels....
http://articles.techrepublic.com.com/5100-10878_11-1047765.html
kerneld is a daemon (a memory-resident program) that notices when a program requests a feature that isn’t available in the kernel. The daemon will run modprobe, which loads the required module. That’s nice, but what’s especially great about kerneld is its ability to remove unused modules from the kernel after a specified period of inactivity (usually one minute). With this feature enabled, your kernel runs as effectively as possible, and it takes on the extra burden of module code only when the code is required. Most Linux distributions install kerneld by default; it’s probably running on your system already.
Inderdaad wel een leuk artikel, zeker om kernel modules en dergelijke conceptueel te begrijpen. Maar zoals je zelf al doorhad, zijn sommige aangehaalde process- en bestandsverwijzingen door de ouderdom van het artikel niet praktisch toepasbaar in de huidige context.
modules blacklisten enerzijds (dat is in /etc/modprobe.d/blacklist.conf)
Indeed, maar dat is zo weer symptoom v.s. oorzaakbestrijding.
anderzijds is er ook ergens een lijstje met "te laden modules".. in /etc/modules of zo...
Yup, die had ik ondertussen ook gevonden, en was toen ook aan het hopen dat het daar te vinden zou zijn, maar daar staan enkel de "lp"-module in en de "coretemp"-module in die ik zelf had toegevoegd omdat mijn temperatuur sensoren niet automatisch gedetecteerd werden.
Ik denk dat je het bij udev moet zoeken.
Waarschijnlijk staan er nog een aantal apparaten in /etc/udev/rules.d/70-persistent-net.rules ofzo.
Bingo, totaal niet aan gedacht om daar te zoeken en heb zelf ook nog maar weinig kennis over udev zelf. In '/etc/udev/rules.d/70-persistent-net.rules' staat inderdaad de geteste hardware.
Ondertussen ook '/lib/udev/rules.d/75-persistent-net-generator.rules' gevonden, waarschijnlijk de oorzaak van dit alles. Deze genereert een udev-rule telkens als er een nieuw netwerk-device wordt aangesloten en voegt die regel toe aan '/etc/udev/rules.d/70-persistent-net.rules'. Bij elke boot wordt dat laatste bestand doorlopen en worden de desbetreffende modules ingeladen. Verklaart perfect de ervaren symptomen.
Daarnaast begrijp ik nu ook waarom ze dit doen.
# these rules generate rules for persistent network device naming
Zo kan er een 'vaste' associatie gelegd worden tussen wlan# en een hardware-device. Terwijl je anders niet wist welk apparaat je aan het gebruiken bent als je met bv. wlan0 bezig bent. Lijkt zo'n beetje dezelfde reden waarom ze UUID's willen gebruiken voor de HDD/SSD. Op dit moment is (was?) de toekenning van /dev/sd[a-z] afhankelijk van wie als eerste gedetecteerd wordt, terwijl het mogelijks logischer zou zijn dat /dev/sda altijd dezelfde schijf voorstelt. (bv. de schijf waarvan je boot)
Maar dit geeft natuurlijk wel een probleem met de huidige aanpak van '/etc/udev/rules.d/70-persistent-net.rules'. Wat als de desbetreffende hardware niet aanwezig is? Op dit moment worden dus de modules gewoon ingeladen, zonder te testen of de desbetreffende hardware aanwezig is. Zou het niet beter/correcter zijn dat enkel de "rules" van de aanwezige hardware wordt uitgevoerd? Zo behoud je de consistente naamgeving (elke "rule" heeft zijn eigen Name="wlan#" => interfaces schuifen niet op als er eentje tussenuit valt) en zit geen probleem-creërende modules in te laden.
Of sla ik hier de bal compleet mis?
