For Cauldron (using Mageia beta3 installed from the KDE livecd): When changing the index of a usb sound device in MCC - Browse and configure hardware - set current driver options, these changes didn't have any effect. I confirmed the changed options were written to etc/modprobe.conf In cauldron, there is a etc/modprobe.d/ folder, containing a 00_modprobe.conf file. Copying the driver options MCC wrote to etc/modprobe.conf allowed these options to be used. It seems that MCC needs to write these changes to etc/modprobe.d/00_modprobe.conf instead of etc/modprobe.conf (which did work fine in Mageia 1).
>For Cauldron (using Mageia beta3 installed from the KDE livecd): valid also after installing the last udpate ?
Keywords: (none) => NEEDINFOSource RPM: (none) => draktools
ok I have a confirmation with another bug thanks, and sorry :/
Keywords: NEEDINFO => (none)Priority: Normal => release_blockerAssignee: bugsquad => thierry.vignaudSource RPM: draktools => drakxtools
*** Bug 5700 has been marked as a duplicate of this bug. ***
CC: (none) => simplew8
Thierry, any idea ?
CC: (none) => ennael1
CC: (none) => mageia
This must be a side effect of the late switch from module-init-tools to kmod. However, kmod is supposed to be backward compatible with m-i-t. So we could write conf in /etc/modprobe.d/ (eg: /etc/modprobe.d/mga-config.conf) but we'd better fix kmod compatibility so that it read the older conf file else other stuff might break.
CC: (none) => tmb
we could package in kmod a /etc/modprobe.d/modprobe.conf symlink on /etc/modprobe.conf
Looks like support for /etc/modprobe.conf was dropped between kmod-2 & -3. Adding a soft symlink or using a trigger to move /etc/modprobe.conf and adding a symling in /etc for compatibility should do it
Yeah, we should either patch kmod to read /etc/modprobe.conf or do the symlink and fix all tools for mga3 As for kmod being backward compatible with m-i-t, it is... sort of... Newer m-i-t already complained about /etc/modprobe.conf being deprecated so kmod dropped it completely
I personally think the symlink approach is best. However do any of our tools read the file, unlink it and then write it again (thus breaking a symlinked /etc/modprobe.conf file)? If so then move+symlink wouldn't work (and we'd be better keeping /etc/modprobe.conf as a file, and instead adding the symlink into the .d folder). We should however also check ordering precedence... i.e. we'd have to look at the code to see how to name/number the file inside /etc/modprobe.d/ to make it processed either first or last depending on what is correct.
kmod 7-6.mga2 now symlinks /etc/modprobe.conf to /etc/modprobe.d/01_mga-config.conf so kmod picks it up secondly. That way we keep the order m-i-t did for mga1
Status: NEW => RESOLVEDResolution: (none) => FIXED
Just to confirm, I removed the options I added to /etc/modprobe.d/00_modprobe.conf. /etc/modprobe.d/01_mga-config.conf shows the changes written to /etc/modprobe.conf, and a few reboots show that these options regarding my usb sound devices index are indeed being read. Thanks so much for the quick turn around with this bug!
*** Bug 5786 has been marked as a duplicate of this bug. ***
I have run harddrake2 to change the wifi card parameters and after i closed harddrak2 there were not any changes in /etc/modprobe.conf I did run harddraje2 again to see if the changes i made were there and they were gone, so werent saved anywhere.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
I've confirmed it works fine here. Don't know how you're managing to break it, but it definitely works. I tried setting position fix for my sound card and all is well.
I have cleaned the options that were in /etc/modprobe.conf: options rtl8192de ips=0 swlps=0 fwlps=0 then i run harddrake2 and did set the parameters (and with the log enabled), and it did not saved any anywhere. Now if i have the options in set in /etc/modprobe.conf and run harddrak2 i can see the parameters values and change them, and then in fact they are saved, but only if the parameters already exist, else harddrake2 does not save them. I have tested this 3 times.
I can even paste here the log so that you can see that there was no output saved into /etc/modprobe.conf or in some file at /etc/modprobe.d 17:36:43 harddrake2[24622]: ### Program is starting ### 17:36:46 harddrake2[24622]: modified file /etc/modprobe.preload 17:36:47 harddrake2[24622]: created directory /var/lock (and parents if necessary) 17:36:47 harddrake2[24622]: running: serial_probe 17:36:47 harddrake2[24622]: running: dmidecode 17:36:48 harddrake2[24622]: running: blkid -o udev -p /dev/sda 17:36:48 harddrake2[24622]: running: blkid -o udev -p /dev/sda 17:36:48 harddrake2[24622]: running: blkid -o udev -p /dev/sda1 17:36:48 harddrake2[24622]: running: blkid -o udev -p /dev/sda2 17:36:48 harddrake2[24622]: running: blkid -o udev -p /dev/sda5 17:36:48 harddrake2[24622]: running: blkid -o udev -p /dev/sda6 17:36:48 harddrake2[24622]: running: blkid -o udev -p /dev/sda7 17:36:48 harddrake2[24622]: running: blkid -o udev -p /dev/sda8 17:36:48 harddrake2[24622]: running: blkid -o udev -p /dev/sda9 17:36:48 harddrake2[24622]: running: udevadm settle 17:36:48 harddrake2[24622]: running: dmsetup table 17:36:48 harddrake2[24622]: running: blkid -o udev -p /dev/mapper/crypt_sda9 17:36:48 harddrake2[24622]: running: lvm2 pvs --noheadings --nosuffix -o vg_name /dev/dm-0 17:36:48 harddrake2[24622]: running: lvm2 vgs --noheadings --nosuffix --units s -o vg_extent_size insys 17:36:48 harddrake2[24622]: running: lvm2 vgs --noheadings --nosuffix --units s -o vg_size insys 17:36:48 harddrake2[24622]: running: lvm2 lvs --noheadings --nosuffix --units s -o lv_name insys 17:36:48 harddrake2[24622]: running: lvm2 lvs --noheadings --nosuffix --units s -o lv_size /dev/insys/home 17:36:48 harddrake2[24622]: running: blkid -o udev -p /dev/insys/home 17:36:48 harddrake2[24622]: running: lvm2 lvs --noheadings --nosuffix --units s -o lv_size /dev/insys/root 17:36:48 harddrake2[24622]: running: blkid -o udev -p /dev/insys/root 17:36:48 harddrake2[24622]: running: lvm2 lvs --noheadings --nosuffix --units s -o lv_size /dev/insys/swap 17:36:48 harddrake2[24622]: running: blkid -o udev -p /dev/insys/swap 17:36:48 harddrake2[24622]: running: /bin/rpm -q --qf %{name} 17:36:48 harddrake2[24622]: running: /bin/rpm -q --qf %{name} 17:36:52 harddrake2[24622]: running: /bin/rpm -q --qf %{name} 17:36:59 harddrake2[24622]: running: modinfo -p rtl8192ce 17:37:03 harddrake2[24622]: running: modinfo -p rtl8192ce 17:37:18 harddrake2[24622]: modified file /etc/sysconfig/harddrake2/ui.conf
OK, this is just a generic issue that putting a value of "0" into any field anywhere is basically ignored. This is technically a different issue to this bug (which was about the file name etc.) and seems to be a generic bug in harddrake. Can you open a new bug for that please so as not to cross-contaminate the issues. Please paste the link here tho'.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
Yes, this problem is different from the one reported here. The new bug report -> https://bugs.mageia.org/show_bug.cgi?id=5839