Bug#317332: Having udev disable itself on reboot is not acceptable
On Mon, Jul 11, 2005 at 09:53:42AM +0200, Marco d'Itri wrote: On Jul 11, Manoj Srivastava [EMAIL PROTECTED] wrote: Having udev disable itself on reboot and leaving the system non-functional is not an acceptable solution. Most systems have I disagree, this is what udev has done since last year and so far nobody ever complained, so it's obviously not such a bad solution. The current (sarge) udev only disables itself for 2.6.x kernel versions that were never in a stable release of Debian. 2.6.8 IS in a stable release of Debian which makes a huge difference. (P.S. your disabling code apparently forgets to disable udev when running on kernel 0.x or 1.x, but this is truly minor and not worth a bug number). The solution, of course, is blindingly simple: do what lvm has done for ages. Ship the old and the new versions of udev; and select the version to run based on the running kernel image. Cool! I will wait for your simple patch then. Just to clarify: It appears that differences in configuration files and inter-package APIs makes it impractical to have both 0.05x and 0.06x udev on the same system thus ruling out my suggestion (which was just a suggestion), that a dual-personality package could be easier to maintain than other solutions. And the need to permit the presence of 2 or more kernel versions in the lilo/grub/whatever config makes it extremely hard to try to prevent installing udev 0.06x on systems also containing kernel 2.6.8 tucked away somewhere - At least if one wants a smooth and reliable upgrade process from sarge to etch. So this leaves the option of dealing with the bugs that prevent udev 0.060 from working on top of a 2.6.8 kernel. Either upstream or as Debian patches. Which is obviously not going to be a simple patch and far beyond my kernel knowledge. -Jakob Oh and I have been looking up Marco on the net, he seems a really cool guy. -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317332: Having udev disable itself on reboot is not acceptable
On Jul 12, Jakob Bohm [EMAIL PROTECTED] wrote: (P.S. your disabling code apparently forgets to disable udev when running on kernel 0.x or 1.x, but this is truly minor and not worth a bug number). The current libc does not even support 2.0, so this is not relevant. And the need to permit the presence of 2 or more kernel versions in the lilo/grub/whatever config makes it extremely hard to try to prevent installing udev 0.06x on systems also containing kernel 2.6.8 tucked away somewhere - At least if one wants a smooth and reliable upgrade process from sarge to etch. Yes. If it will prove to be actually needed I have a backup plan more or less ready for a limited dual-personality package, BUT the old personality would only provide limited functionalities and would not be intented to be configured by users. IOW, it would only work until the end of the upgrade but switching back and forth between kernel versions would not be fully supported and probably many features would not be available. So this leaves the option of dealing with the bugs that prevent udev 0.060 from working on top of a 2.6.8 kernel. Either upstream or as Debian patches. Which is obviously not going to be a simple patch and far beyond my kernel knowledge. These are not bugs, but rather fundamental design features. -- ciao, Marco signature.asc Description: Digital signature
Bug#317332: Having udev disable itself on reboot is not acceptable
On Jul 11, Manoj Srivastava [EMAIL PROTECTED] wrote: Having udev disable itself on reboot and leaving the system non-functional is not an acceptable solution. Most systems have I disagree, this is what udev has done since last year and so far nobody ever complained, so it's obviously not such a bad solution. The solution, of course, is blindingly simple: do what lvm has done for ages. Ship the old and the new versions of udev; and select the version to run based on the running kernel image. Cool! I will wait for your simple patch then. -- ciao, Marco signature.asc Description: Digital signature
Bug#317332: Having udev disable itself on reboot is not acceptable
On Jul 11, md wrote: Having udev disable itself on reboot and leaving the system non-functional is not an acceptable solution. Most systems have I disagree, this is what udev has done since last year and so far nobody ever complained, so it's obviously not such a bad solution. I need to clarify that I had not seen #317720 yet. The package was supposed to refuse to be installed too if an older version of udev is already running. -- ciao, Marco signature.asc Description: Digital signature
Bug#317332: Having udev disable itself on reboot is not acceptable
Hi, Having udev disable itself on reboot and leaving the system non-functional is not an acceptable solution. Most systems have multiple kernel images installed, having only some of them working, and breaking the whole system if the system boots some other image (I have unstable, stable, old, and new images; having only my unstable image bootable is not acceptable). Especially considering a machine booting remotely into older kernel versions be default. The solution, of course, is blindingly simple: do what lvm has done for ages. Ship the old and the new versions of udev; and select the version to run based on the running kernel image. I should not have to remind people that partial upgrades from Sarge also should be supported -- even partial upgrades for udev. So, even after 2.6.12 is installed, this bug shall remain critical, unless a solution is put into place. manoj -- Elliptic paraboloids for sale. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
