Re: hotplug blacklists
Anyway, I implemented support for /etc/hotplug/blacklist.d/ in modprobe... N.B. Currently a module that is blacklisted for hotplug (i.e. its name is listed in /etc/hotplug/blacklist or in a file in /etc/hotplug/blacklist.d/) can still be loaded on boot by adding its name to /etc/modules. For backward compatibility that behavior should probably be preserved. When a final decision has been made about how hot plug blacklisting will be implemented in the future, please file a bug report against alsa-base explaining what changes need to be made, if any. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hotplug blacklists
On Sep 30, Thomas Hood [EMAIL PROTECTED] wrote: N.B. Currently a module that is blacklisted for hotplug (i.e. its name is listed in /etc/hotplug/blacklist or in a file in /etc/hotplug/blacklist.d/) can still be loaded on boot by adding its name to /etc/modules. For backward compatibility that behavior should probably be preserved. modprobe blacklists are only applied to targets of alias expansion, so nothing has been changed. When a final decision has been made about how hot plug blacklisting will be implemented in the future, please file a bug report against alsa-base explaining what changes need to be made, if any. The final decision has been made long ago, and it is to use blacklist statements in a file in /etc/modprobe.d/. -- ciao, Marco signature.asc Description: Digital signature
Re: hotplug blacklists
Quoting Marco d'Itri ([EMAIL PROTECTED]): Everybody who has apt-listchanges installed, for a start. And if they don't, too bad for them. Well, I agree that people using unstable really should install apt-listchanges. However, what about testing and future stable users? Our installer does not install apt-listchanges by default so we can't just assume that announcing potential transition problems in NEWS.Debian is enough*if these transition affect testing and future upgrades from sarge* This is maybe not relevant to this discussion but this has to be said: as long as we do not install apt-listchanges by default we can't expect all our users to get information from there only. debconf notes could be better suited in some cases. I'm the first fighting useless debconf notes as debconf abuse but they also exist with a real purpose and using them in some cases could be the best solution if we have something important to say to users. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hotplug blacklists
On Sep 19 18:25+0200, Marco d'Itri wrote: On Sep 19, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: snip It's arguable how much drivers blacklisting is critical. I've had a fair amount of trouble with hotplug loading modules that cause a kernel panic (esp. on laptops). In this case, what would you recommend as a replacement for blacklisting? It's uncommon for users to do it, and as long as they read the NEWS.Debian email before rebooting nothing bad will happen anyway. How many people really read those, anyway? ;) -- Eldon Koyle -- Our swords shall play the orators for us. -- Christopher Marlowe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hotplug blacklists
On Sep 27, Eldon Koyle [EMAIL PROTECTED] wrote: I've had a fair amount of trouble with hotplug loading modules that cause a kernel panic (esp. on laptops). In this case, what would you recommend as a replacement for blacklisting? module-init-tools blacklisting. Anyway, I implemented support for /etc/hotplug/blacklist.d/ in modprobe, and in one or two days I will upload the new udev which fully replaces hotplug. It's uncommon for users to do it, and as long as they read the NEWS.Debian email before rebooting nothing bad will happen anyway. How many people really read those, anyway? ;) Everybody who has apt-listchanges installed, for a start. And if they don't, too bad for them. -- ciao, Marco signature.asc Description: Digital signature
Re: hotplug blacklists
On Sep 21, Nathanael Nerode [EMAIL PROTECTED] wrote: The absolute minimum functional upgrade path is to Conflict: with all package versions providing old-style blacklists, and to abort early in preinst with a loud warning if any user-specified blacklists are present on the system (much akin to the way libc6 installation aborts on all kinds of dangerous conditions). That's a trivial enough patch that I assume you don't need an actual .diff file to apply it. You missed the part of the thread about the /etc/hotplug/blacklist conffile provided by the hotplug package. It would apply to other conflicted packages too, so no file would automatically be removed. -- ciao, Marco signature.asc Description: Digital signature
Re: hotplug blacklists
* sean finney [Mon, 19 Sep 2005 06:13:30 -0400]: echo # user defined blacklists converted from hotplug $tmpfile cat $blacklist_files | grep -vE '^[[:space:]]*#' | \ sed -ne 's/^\(.*\)/install \1 /bin/true' $tmpfile ucf $tmpfile /etc/modprobe.d/hotplug-blacklists Doesn't modprobe have a 'blacklist' keyword? -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 You've come to the right place. At debian-devel we are always willing to argue over the meanings of words. -- seen on [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hotplug blacklists
Marco D'Itri wrote: It's arguable how much drivers blacklisting is critical. It's uncommon for users to do it, and as long as they read the NEWS.Debian email before rebooting nothing bad will happen anyway. Almost every time a user does it, it's because it's critical. You cannot expect users to read the NEWS.Debian in every package they upgrade before every reboot. The absolute minimum functional upgrade path is to Conflict: with all package versions providing old-style blacklists, and to abort early in preinst with a loud warning if any user-specified blacklists are present on the system (much akin to the way libc6 installation aborts on all kinds of dangerous conditions). That's a trivial enough patch that I assume you don't need an actual .diff file to apply it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hotplug blacklists
On Sep 19, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: What about user-installed blacklists? Will the new packages at least try to convert these from blacklist format to modprobe format? No (but feel free to send code to do it). -- ciao, Marco signature.asc Description: Digital signature
Re: hotplug blacklists
On Mon, Sep 19, 2005 at 09:29:13AM +0200, Marco d'Itri wrote: What about user-installed blacklists? Will the new packages at least try to convert these from blacklist format to modprobe format? No (but feel free to send code to do it). is it really that complicated? unless i'm missing something, wouldn't it be as simple as echo # user defined blacklists converted from hotplug $tmpfile cat $blacklist_files | grep -vE '^[[:space:]]*#' | \ sed -ne 's/^\(.*\)/install \1 /bin/true' $tmpfile ucf $tmpfile /etc/modprobe.d/hotplug-blacklists (of course provided for proper handling of tmpfile generation and a debconf prompt, i guess). I think if you're going to discontinue support for such a feature, it would be very beneficial to the user community as a whole that they are informed of this during the upgrade, if not provided an easy upgrade path... as otherwise it will break everything from sound to networking to who knows what else for many people. sean signature.asc Description: Digital signature
Re: hotplug blacklists
On Sep 19, sean finney [EMAIL PROTECTED] wrote: is it really that complicated? unless i'm missing something, wouldn't it be as simple as For a start, only user-written files should be converted. (of course provided for proper handling of tmpfile generation and a debconf prompt, i guess). I think if you're going to discontinue support for such a feature, it would be very beneficial to the user community as a whole that they are informed of this during the upgrade, if not provided an easy upgrade path... as otherwise it will break everything from sound to networking to who knows what else for many people. This is the NEWS.Debian entry. Is there anything missing? udev (0.070-3) unstable; urgency=low * hotplug and coldplug support has been merged in the udev package, which will load all the drivers needed as the beginning of the boot process and handle hotplug events later. The hotplug package has been disabled and should be manually purged. This makes the following configuration files obsolete: + /etc/hotplug/*.rc and *.agent: the old hotplug files are not used anymore. udev rules may be used to selectively disable coldplugging. + /etc/hotplug/usb/*.usermap: must be replaced by udev rules. + /etc/hotplug/blacklist*: must be replaced by modprobe configuration directives. -- Marco d'Itri [EMAIL PROTECTED] Sun, 18 Sep 2005 00:27:31 +0200 -- ciao, Marco signature.asc Description: Digital signature
Re: hotplug blacklists
On Mon, 19 Sep 2005, Marco d'Itri wrote: is it really that complicated? unless i'm missing something, wouldn't it be as simple as For a start, only user-written files should be converted. Easily done. Conflict with all packages providing blacklist entries by themselves, and convert everything else. This will keep things safe for sid/etch users at low cost (a few conflicts you have already tracked down anyway), and order the sarge-etch upgrade properly. Please correct me if I am wrong, but the script conversion will be necessary for a proper upgrade path from sarge to etch anyway, and thus such stuff is *non-optional*. udev (0.070-3) unstable; urgency=low * hotplug and coldplug support has been merged in the udev package, which [...] -- Marco d'Itri [EMAIL PROTECTED] Sun, 18 Sep 2005 00:27:31 +0200 All nice and dandy, but it isn't enough to simply document it. At the very least you have to abort on preinst if the above fixes are not in place to avoid breakage, if you are going to tell the user to 'fix it himself'. IMHO udev is becoming critical service structure, and must be handled as such. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hotplug blacklists
On Sep 19, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: Easily done. Conflict with all packages providing blacklist entries by themselves, and convert everything else. This will keep things safe for sid/etch users at low cost (a few conflicts you have already tracked down anyway), and order the sarge-etch upgrade properly. Send a patch. There is also the problem of /etc/hotplug/blacklist, which will not be removed until hotplug will be manually purged and may have been modified locally (and what you see from one side as an automatic upgrade procedure I see from the other side as silently dropping configuration debris which may cause unexpected behaviours in the future). Please correct me if I am wrong, but the script conversion will be necessary for a proper upgrade path from sarge to etch anyway, and thus such stuff is *non-optional*. It's arguable how much drivers blacklisting is critical. It's uncommon for users to do it, and as long as they read the NEWS.Debian email before rebooting nothing bad will happen anyway. -- ciao, Marco signature.asc Description: Digital signature
Re: hotplug blacklists
Marco d'Itri wrote: udev (0.070-3) unstable; urgency=low * hotplug and coldplug support has been merged in the udev package, which will load all the drivers needed as the beginning of the boot process and handle hotplug events later. The hotplug package has been disabled and should be manually purged. This makes the following configuration files obsolete: + /etc/hotplug/*.rc and *.agent: the old hotplug files are not used anymore. udev rules may be used to selectively disable coldplugging. + /etc/hotplug/usb/*.usermap: must be replaced by udev rules. + /etc/hotplug/blacklist*: must be replaced by modprobe configuration directives. *urgs*, I really hope that this does not mean to get rid of the hotplug package! There are people who like a static /dev and still want hotplug to properly load the modules. HS -- Mein GPG-Key ist auf meiner Homepage verfügbar: http://www.hendrik-sattler.de oder über pgp.net PingoS - Linux-User helfen Schulen: http://www.pingos.org pgp0VN7BURM5S.pgp Description: PGP signature
Re: hotplug blacklists
On Sep 19, Hendrik Sattler [EMAIL PROTECTED] wrote: *urgs*, I really hope that this does not mean to get rid of the hotplug package! No, but I expect that more and more packages in the future will require udev. There are people who like a static /dev and still want hotplug to properly load the modules. This may appear weird, but you can have a static /dev with udev too. -- ciao, Marco signature.asc Description: Digital signature
Re: hotplug blacklists
On Mon, Sep 19, 2005 at 06:25:39PM +0200, Marco d'Itri wrote: Please correct me if I am wrong, but the script conversion will be necessary for a proper upgrade path from sarge to etch anyway, and thus such stuff is *non-optional*. It's arguable how much drivers blacklisting is critical. It's uncommon for users to do it, and as long as they read the NEWS.Debian email before rebooting nothing bad will happen anyway. I have at least two computers that I've had to use hotplug blacklist entries on at various points, including one where the blacklist entry is still needed in 2.6.12. Given that reboots are not always under control of the admin, I don't think read NEWS.Debian before rebooting is much protection. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: hotplug blacklists
On Sun, 18 Sep 2005, Marco d'Itri wrote: The new hotplug subsystem cannot handle blacklisting anymore, and now delegates it to modprobe. modprobe uses a different syntax, so the old /etc/hotplug/blacklist* files are not supported anymore. What about user-installed blacklists? Will the new packages at least try to convert these from blacklist format to modprobe format? Otherwise you are likely to cause severe headaches to a lot of people whose system crashes when a given module (that hotplug likes) is loaded, etc. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
