Love the new jessie artwork (lines theme)
I'm not sure if this is the right forum for this, but I just wanted to drop a quick note to say that I love the new artwork for jessie (lines theme). It reminds me of the orbits of stars around our galaxy's central supermassive black hole. See, for example, https://www.youtube.com/watch?v=J9JE51X7ul4 -- .''`. Stephen Powellzlinux...@wowway.com : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1717633048.67548377.1420495845868.javamail.zim...@wowway.com
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
On Sat, 29 Mar 2014 01:34:27 -0400 (EDT), Andrei POPESCU wrote: Or connman. Frankly, I think that the claim that ifupdown is dysfunctional is an exaggeration at best and untrue at worst. I am not claiming that it is bug free; but in my experience, it works just fine; and I see no compelling reason to replace it. My two cents worth. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/966103792.557666.1396101912817.javamail.r...@md01.wow.synacor.com
Re: Bug #739874 - procps doesn't build on i386
On Mon, 24 Feb 2014 15:16:23 -0500 (EST), Cyril Brulebois wrote: #739874 should have been called a failure to build from source (FTBFS), and could have linked to [1], but anyhow. 1. https://buildd.debian.org/status/package.php?p=procpssuite=sid I apologize, Mr. Brulebois, if I did not use correct terminology in my bug report. I am neither a DD, nor a DM, just an ordinary Debian user. I reported the symptoms as observed by an ordinary user. Besides, I was able to build the package binaries myself using dpkg-buildpackage on an i386 machine, once I managed to get the 1:3.3.9-3 source code downloaded and extracted with dpkg-source. In other words, on my machine at least, I did not get a FTBFS error. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/416886484.16131.1393295228447.javamail.r...@md01.wow.synacor.com
Re: Feedback
On Tue, 25 Dec 2012 07:50:57 -0500 (EST), Mistikos Nik wrote: Debian documentation is a joke. It constantly refers to Debian versions by their nick names, and not their versions. If I am new to Debian and go to read the manual and I see 'Squeeze', do you think I am going to know what the [expletive deleted] that means? No, but if Debian actually used the official name, then it would fall in line with conistency [sic]. I.E documentation for 'Debian 6'. People outside the development circle arn't [sic] going to know what [sic] Debian jargon. This is a classic case of computer nerds lacking social skills. If you don't have good documentation, then the product isn't going to get used. Debian use to be really popular. Now only old people use it. Why because new comers will choose a well documented distro over one that doesn't make sense. Life is too short to [expletive deleted] around. Merry Christmas! I am not a Debian developer, per se; so perhaps I shouldn't even respond. I follow this list, but do not normally post to it. Then again, since I have written some Debian documentation (albeit none of it is official), perhaps I should. (1) Official Debian version numbers are not normally assigned until the release becomes the stable release. Until then, the only way to refer to a specific testing release (other than by the generic name testing, which is regularly reassigned to the next release once the previous testing release becomes stable) is by using the release code name, such as wheezy, which is the current testing release at the time of this writing. (2) The correspondence between release code names and official version numbers can be found in the Debian FAQ, point 6.2, entitled What are all those names like etch, lenny, etc.?. Here is a link to this item in the on-line version of the Debian FAQ: http://www.debian.org/doc/manuals/debian-faq/ch-ftparchives.en.html#s-codenames As you can see, squeeze is the last code name which has an assigned version number, which is 6.0. That is due to the fact that squeeze is the current stable release. The current testing release, wheezy, and the one after that, jessie, do not yet have official version numbers assigned. They can only be referred to by their code names at this point. And documentation for squeeze that was written before squeeze became the stable release could only refer to squeeze by its code name. Are you saying that no documentation should ever be written until a release becomes the stable release? I think not. It is best to ask questions rather than criticize something you don't understand. Incidentally, most other distributions use release code names too. (3) Watch your mouth. The use of foul language on Debian mailing lists is prohibited in the Debian mailing list code of conduct, available here: http://www.debian.org/MailingLists/#codeofconduct (4) Someone who can't spell, or who doesn't bother to proof-read his work, is on thin ice criticizing someone else's writing. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1810453357.431938.1356450913271.javamail.r...@md01.wow.synacor.com
Re: Feedback
On Tue, 25 Dec 2012 11:39:39 -0500 (EST), Adam D. Barratt wrote: On 25.12.2012 15:55, Stephen Powell wrote: (1) Official Debian version numbers are not normally assigned until the release becomes the stable release. I haven't checked when previous release numbers were announced, but wheezy's assigned version was public information some time ago - see URL:https://lists.debian.org/debian-devel-announce/2010/09/msg0.html. Evidently the historical practice has changed recently. I stand corrected. Thanks. The /etc/debian_version file, however, does not give a release number, and probably won't, until wheezy becomes the stable release. It currently simply says, wheezy/sid. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2094611219.433418.1356460611459.javamail.r...@md01.wow.synacor.com
Re: this bug .. bugs me
On Tue, 05 Jun 2012 11:52:52 -0400 (EDT), Joey Hess wrote: ... This bug is a textbook example of making the perfect the enemy of the good. It's disconcerting that we, or our users, are willing to put up with this. Unfortunately, this is not an isolated case. Another example is GNU parted. I contributed an enhancement to upstream GNU parted several years ago that adds support for CMS minidisks, as well as a number of related enhancements. This has significant benefit for users of the s390 and s390x ports, especially in the Debian installer environment. The contribution was accepted and is included in the upstream code in version 2.4. But the Debian package is still using version 2.3. I had hoped that the Debian package would upgrade to version 2.4 or later before the Squeeze freeze, but that did not happen. Three upstream versions later (2.4, 3.0, and now 3.1) the Debian package is still using version 2.3. It now appears that my enhancement will not appear in the Wheezy version of the package either. This is very disappointing. I'm not questioning anyone's competency, but parted is way out of date; and no-one seems to be doing anything about it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1560597686.1629135.1339112833174.javamail.r...@md01.wow.synacor.com
Symbolic links to kernel image files and initial RAM file system image files
It's hard to believe that it's been over a year since we discussed this topic. (See http://lists.debian.org/debian-kernel/2010/06/msg01049.html.) Time flies when you're having fun, I guess. ;-) Anyway, back when the boot loader hook script policy was being formulated, shortly before the Squeeze freeze, I brought up the subject of symbolic links to kernel image files and initial RAM file system image files, their maintenance, and their use by boot loader configuration files. This subject is not really addressed in the current hook script policy for boot loaders. Nevertheless, traditional boot loaders, such as lilo and zipl, particularly the way their configuration files are set up by the Debian installer, do use these symbolic links. The last time I checked, the do_symlinks = yes setting in /etc/kernel-img.conf was still honored by the maintainer scripts for official stock Debian kernel image packages; therefore, as long as the user runs only official Debian stock kernel image packages he can keep current by setting do_symlinks = yes in /etc/kernel-img.conf (along with companion options such as link_in_boot and relative_links). However, the last time I checked, do_symlinks = yes in /etc/kernel-img.conf is not honored by the maintainer scripts that are packaged with a kernel image package created by current versions of make-kpkg or make deb-pkg. Consequently, for custom kernel image packages at least, we have a chink in the armor for boot loaders to get out of sync with installed kernel images. Boot loader hook scripts are not currently required to maintain symbolic links, and none of the boot loader hook scripts that I have looked at do so. But neither do the hook scripts provided by these traditional boot loaders edit the configuration file (similar to the update-grub command of grub version 1) to reference the kernel image files and their initial RAM file system image files directly, so that symbolic links are not needed. Thus we have the situation where the boot loader is implicitly assuming that the symbolic links are going to be maintained somehow, someway, and, for custom kernels, no official part of the Debian system is maintaining them. For my own use on my own systems, I have written hook scripts which maintain the symbolic links; and if anyone wants them, they are available for download on my web site. But obviously they are not part of the official Debian system. While we still have plenty of time before the Wheezy freeze, I would like to discuss what, if anything, should be done about this situation. I see several alternatives: o Require boot loader hook scripts to either edit their configuration files or maintain the symbolic links o Provide hook scripts in some other package (base-files? initramfs-tools?) that maintain symbolic links o Eliminate symbolic links entirely and require boot loader hook scripts to edit their configuration files o Bury our heads in the sand and ignore the problem (Obviously I don't care for that last one or I wouldn't have started this thread!) The second option would seem to be the quickest solution, but the quickest solution is not always the best solution. Perhaps there are other alternatives that I haven't thought of. What are your thoughts? P.S. For this initial post I have CC-ed debian-boot and debian-devel, as there may be interested parties on that list that are not subscribed to debian-kernel, but it is my intention that the discussion take place on debian-kernel. So please excuse this initial cross-post. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1702198171.779349.139811090.javamail.r...@md01.wow.synacor.com
Re: maintainer ignores bug
On Sat, 26 Feb 2011 21:05:19 -0500 (EST), Osamu Aoki wrote: On Sat, Feb 26, 2011 at 07:41:18PM +0100, Jakub Wilk wrote: Yes, ideally one should also be omniscient... I am not sure what is omniscient. ... I hope this does not sound too patronizing, Osamu; but since English is not your first language, I will tell you that omniscient means knowing everything, a term which, in it's strictest sense, applies only to God himself. I believe that this was Mr. Wilk's way of saying that he would have to know everything in order to know which package he should file the bug report against. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1361907891.1091567.1298776386245.javamail.r...@md01.wow.synacor.com
Squeeze Release Coincides with Toy Story Marathon
Congratulations to all the Debian developers on the Squeeze release over the weekend. You all deserve a big round of applause. On the very day that Squeeze was going production, Saturday, February 5, 2011, The Disney Channel was running a Toy Story Marathon in which all three of the Toy Story movies were being shown back-to-back-to-back. Isn't that an amazing co-incidence? Or was it? ;-) Thank you very much. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1574427890.656047.1297132384086.javamail.r...@md01.wow.synacor.com
Re: Bug#603767: gdm: starts on v8 instead of vt7
This appears to be a duplicate of 596700. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1758119783.480227.1290049344906.javamail.r...@md01.wow.synacor.com
Re: Re: searching inside files with find, cat and grep as a oneliner ...
On Sat, 18 Sep 2010 08:40:31 -0400 (EDT), Adam Borowski wrote:
On Sat, Sep 18, 2010 at 12:01:17PM +0100, Clive Standbridge wrote:
Stephen Powell wrote:
Search all files under the home directory (recursively) with an
extension of .txt
for the keyword xorg:
grep -r xorg ~/*.txt
That looks like a misunderstanding. That command actually causes grep
to search
(a) files matching *.txt in the home directory.
(b) files of ANY name, contained in subdirectories named *.txt in the
home directory.
To search all files under the home directory (recursively) with an
extension of .txt, you will need to use find .. | xargs or find
.. -exec ... {} + as discussed previously,
I guess you're looking for:
grep -r --include='*.txt' xorg ~
Clive, you are quite correct. I didn't think that through carefully
enough. Thanks for pointing that out. And thanks to you, Adam, for
the corrected version.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1732889826.116729.1284988319814.javamail.r...@md01.wow.synacor.com
Re: The number of popcon.debian.org-submissions is falling
On Wed, 21 Jul 2010 00:56:29 -0400 (EDT), Christian PERRIER wrote: There is nothing more we can do to have as many popcon submissions as possible, really. If the number is decrasing, this is because the number of Debian users who choose to install popcon is decreasing. Very probably because the number of people who use Debian is decreasing. Period. I haven't been following this thread closely; so if this idea has been mentioned before, please excuse the duplicate. I actually tried to enable popcon on my servers, but IIRC it requires an MTA configured for external e-mail in order to work. The MTA (exim4) on all my machines is configured for local mail only. If the delivery mechanism were, say, a batch ftp transfer, I could probably enable popcon. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1437377800.3635.1279717463068.javamail.r...@md01.wow.synacor.com
Re: The number of popcon.debian.org-submissions is falling
On Wed, 21 Jul 2010 09:10:56 -0400 (EDT), Petter Reinholdtsen wrote: Stephen Powell wrote: I haven't been following this thread closely; so if this idea has been mentioned before, please excuse the duplicate. I actually tried to enable popcon on my servers, but IIRC it requires an MTA configured for external e-mail in order to work. The MTA (exim4) on all my machines is configured for local mail only. If the delivery mechanism were, say, a batch ftp transfer, I could probably enable popcon. Support for using HTTP to submit reports were added in popularty-contest version 1.30 uploaded 2005-07-07. So, you can safely enable popcon. :) Apparently this is not the default behavior. But I will check that out. Thanks! -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1424021856.4025.1279718173337.javamail.r...@md01.wow.synacor.com
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
On Wed, 21 Jul 2010 07:42:51 -0400 (EDT), Steffen Möller wrote: The computing world have become such complex, that we are all mere users somewhere. So yes, we should think more about our users. I suspect that the primary reasons desktop users choose another distribution over Debian is threefold: o Ease of installation o Ease of configuration o Automatic inclusion of popular non-free software, such as proprietary hardware drivers, Adobe flash, Sun Java, etc. The Debian installer has made great strides over the years, and Debian is now fairly easy to install. But the other two points are where the other distros have the advantage. For the third point, I don't see how we can compete without a fundamental redefinition of who we are and what our principles are. Debian isn't for everyone. If our primary goal is to get as big as possible, we may as well joint M$. * Metaphorical speaking: we should give Debian a phone number. And I mean full-time or at least half-time employees. With so many people unemployed these days, I even feel we have the duty to think about creating jobs. That's an interesting idea. But where is the money going to come from? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/566700884.5143.1279719969516.javamail.r...@md01.wow.synacor.com
Re: [RFC] removing xserver-xorg-video-nv from squeeze
On Tue, 13 Jul 2010 04:31:56 -0400 (EDT), Cyril Brulebois wrote: Care to share a reference to the bug you reported? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589452 -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1557363364.62018.1279405519348.javamail.r...@md01.wow.synacor.com
Re: [RFC] removing xserver-xorg-video-nv from squeeze
On Tue, 13 Jul 2010 11:36:10 -0400 (EDT), Cyril Brulebois wrote: Cyril Brulebois wrote: ... I didn't ask for an UMS-related bug reference. For some reason I was under the impression that KMS drivers were limited to modes which can be set by the video BIOS. I stand corrected. A bug report will be forth-coming. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2044848160.193276.1279129700306.javamail.r...@md01.wow.synacor.com
Re: [RFC] removing xserver-xorg-video-nv from squeeze
Cyril Brulebois wrote: Care to share a reference to the bug you reported? Ben Hutchings wrote: I assume you've filed a bug requesting support for custom modes, as requested by the X maintainers? As Sven Joachim has pointed out, this would be an exercise in futility. Upstream deliberately removed support for UMS a while ago. From their point of view, this is not a bug, this is a feature. And that's why I use the nv driver. Is KMS supposed to work with custom video modes? Is the nouveau driver supposed to work with custom video modes? If so, then perhaps it would be worthwhile to file a bug report. Otherwise, it's a waste of time. Stephen Powell wrote: The intel driver supports both KMS and UMS. Cyril Brulebois wrote: That's no longer correct. http://ikibiki.org/blog/2010/07/04/We_need_you_redux/ Ben Hutchings wrote: Not any more. As of xserver-xorg-video-intel 2:2.9.1-4, which is current in Squeeze, and for the i915G chipset, I can still pass modeset=0 to the i915 module and the X driver will still work. Are you saying that this is going to be taken away from me too? Oh joy! Ben Hutchings wrote: Because UMS is a nasty hack that makes various features impossible, and it is too much work to maintain both models. I'm beginning to see what I'm up against. I'm not trying to stand in the way of progress. I wish I could, however, stand in the way of regress. When you take away features that used to work and now don't anymore, that's not progress. Whether the actual mode setting takes place in kernel space or in user space is not my issue. I see the advantages of doing it in kernel space. The problem is two-fold, as I see it. (1) The kernel wants to set the mode once and leave it there, including when switching to a text console. It doesn't switch the card into a true hardware text mode. (2) It appears to me that the kernel (or video driver) may only support video modes that can be set by the video BIOS. Correct me if I'm wrong. (It wouldn't be the first time!) But no-one is listening. And if I stand in the way of regress, I'll get run over. (Sigh.) Of course, this is not a Debian-specific issue. Debian is just reacting to what is going on upstream. Keeping the nv driver is just delaying the inevitable, apparently. So I suppose I'll just have to throw out my monitor and use another one, even though there's nothing wrong with my existing monitor, because the video BIOS didn't anticipate my monitor's needs. Progress. (If you're a hardware vendor.) Cyril Brulebois wrote: Mraw, KiBi. If this is supposed to mean something, perhaps you'll be kind enough to share it with me. A search of Internet slang did not yield any results that made sense to me in this context. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/765392348.156870.1279033877304.javamail.r...@md01.wow.synacor.com
Re: [RFC] removing xserver-xorg-video-nv from squeeze
On Mon, 12 Jul 2010 14:33:15 -0400 (EDT), Julien Cristau wrote: We're considering the removal of xserver-xorg-video-nv (the free X driver for nvidia hardware) from sid and squeeze. I'm replying to both debian-x and debian-devel, but I am only subscribed to debian-devel. If you post only to debian-x, please CC me. If nouveau set KMS by default, as the intel driver does, but did not *require* KMS, I would agree. But the last time I checked, using the nouveau driver *forces* KMS. I don't like that. I still use, and prefer, hardware text mode virtual consoles (1-6). Because of that, I still use nv. That's the *only* reason that I still use nv. There is no bug number here because I'm sure that upstream would consider this a feature and not a bug. In other words, they would consider operation of the driver with KMS off an enhancement request. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2007940949.133394.1278961763880.javamail.r...@md01.wow.synacor.com
Re: [RFC] removing xserver-xorg-video-nv from squeeze
On Mon, 12 Jul 2010 15:24:56 -0400 (EDT), Sven Joachim wrote: On 2010-07-12 21:09 +0200, Stephen Powell wrote: If nouveau set KMS by default, as the intel driver does, but did not *require* KMS, I would agree. But the last time I checked, using the nouveau driver *forces* KMS. I don't like that. I still use, and prefer, hardware text mode virtual consoles (1-6). May I ask why? If the reason is that the default font is too small, you can easily choose a bigger one, e.g. by dpkg-reconfigure console-setup. And speed shouldn't really be an issue either, unlike with vesafb. For a number of reasons. First, hardware text video modes seem to scroll faster in vi, less, etc. The frame buffer overhead is not as bad as it used to be, but hardware text modes still beat it. Second, I can't seem to get an 80-column virtual console with KMS. Yes, I can change the font size, but the traditional 80-column display doesn't seem to present itself. Maybe I just haven't tried hard enough. But frankly, I have little incentive to try very hard when I can just use hardware text modes with the nv driver. Because of that, I still use nv. That's the *only* reason that I still use nv. I take that back. There is a second reason. But it's related. nouveau ignores my custom video mode and insists on driving my CRT monitor at 1024x768 resolution (which is what I want) and at 60 Hz vertical refresh (which is *not* what I want). 60 Hz vertical refresh produces noticeable flicker and really irritates my eyes after only a few minutes. The only VESA standard video modes supported by my monitor for 1024x768 resolution are 1024x768 @ 60 Hz and 1024x768 @ 87 Hz Interlaced. The 87 Hz Interlaced mode produces far less perceived flicker and eye irritation than the 60 Hz mode, but I designed a custom video mode for 1024x768 @ 100 Hz Interlaced that is even better. (100 Hz is the maximum vertical refresh rate of the monitor). This mode is still within the video bandwidth of the monitor (maximum supported pixel clock rate). I'm very happy with it. But I can't get the nouveau driver to use my custom 100 Hz Interlaced mode, or even the VESA standard 87 Hz Interlaced mode. It insists on running the monitor at 60 Hz non-interlaced. And my eyes just won't take that for very long. At 100 Hz interlaced, I can look at the screen all day long with no eye strain. But at 60 Hz non-interlaced, my eyes are tired after 30 minutes or so. I assume that that is due to no support for UMS. There is no bug number here because I'm sure that upstream would consider this a feature and not a bug. In other words, they would consider operation of the driver with KMS off an enhancement request. Indeed you would be wasting your time, upstream deliberately removed all UMS support from the nouveau X driver some months ago. That really annoys me. I was down on the nv driver because Nvidia decided not to add support for newer GPUs to it. But at least it supports UMS for older cards like mine. If you get rid of the nv driver, it looks like I will have to get another monitor or another video card, even though there is nothing wrong with either of them. The intel driver supports both KMS and UMS. I see no reason why the nouveau people should decide to RAM KMS down our throats, whether we want it or not. And with my present hardware, nv appears to be my only viable solution. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1009225337.144806.1278988270516.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
the default value is yes, they should issue the warning message unless do_bootloader is *explicitly* set to no. 6. The installer must not define do_bootloader, postinst_hook or postrm_hook in /etc/kernel-img.conf. Doesn't this conflict with point 4 (a)? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1266213194.8135.1277738218774.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 28 Jun 2010 12:45:10 -0400 (EDT), maximilian attems wrote:
On Mon, 28 Jun 2010 03:02:35 +0100 Ben Hutchings wrote:
The arguments given to all kernel hook scripts are the kernel ABI
version (the string that uname -r reports) and the absolute path to the
kernel image.
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
Currently, hook scripts invoked by a stock kernel maintainer script
or a maintainer script from a kernel image package created by make-kpkg
pass these exact same arguments.
no.
From a Squeeze system running a custom kernel created by make-kpkg:
-
debian3:~# dpkg-reconfigure linux-image-2.6.32-custom5b-s390x
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/S30initramfs 2.6.32-custom5b-s390x
/boot/vmlinuz-2.6.32-custom5b-s390x
^ ^
+-- 1st argument
+-- 2nd argument
-
From a Squeeze system running a stock kernel image:
-
r...@testdebian:~# dpkg-reconfigure linux-image-2.6.32-3-686
Running depmod.
Running update-initramfs: Generating /boot/initrd.img-2.6.32-3-686
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/S30initramfs 2.6.32-3-686
/boot/vmlinuz-2.6.32-3-686
^^
|+-- 2nd
argument
+-- 1st argument
-
Q.E.D.
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
But a maintainer script for a kernel
image package created by make deb-pkg passes only the first argument.
no.
The actual text of /etc/kernel/postinst.d/initramfs-tools:
-
#!/bin/sh
version=$1
bootopt=
# passing the kernel version is required
[ -z ${version} ] exit 0
# kernel-package passes an extra arg
if [ -n $2 ]; then
if [ -n ${KERNEL_PACKAGE_VERSION} ]; then
bootdir=$(dirname $2)
bootopt=-b ${bootdir}
else
# official Debian linux-images take care themself
exit 0
fi
fi
# avoid running multiple times
if [ -n $DEB_MAINT_PARAMS ]; then
eval set -- $DEB_MAINT_PARAMS
if [ -z $1 ] || [ $1 != configure ]; then
exit 0
fi
fi
# we're good - create initramfs. update runs do_bootloader
update-initramfs -c -t -k ${version} ${bootopt}
-
I admit that I have never personally used make deb-pkg, but
clearly the source code speaks for itself. This hook script is
expecting only one argument when invoked by make deb-pkg.
Q.E.D.
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
Existing hook scripts rely on that difference to determine whether or
not to take action. For example, the initramfs hook script provided by
the initramfs-tools package tests the number of arguments and exits
without doing anything if more than one argument is supplied. In other
words, this hook script is designed to create the initial RAM file system
for a kernel image created by make deb-pkg, and only for a kernel
image created by make deb-pkg. It does nothing otherwise. Are you
proposing to change this behavior?
please get your facts right before spamming the world.
OK, you're partly right on this one. Execution tracing shows that it
does nothing when invoked by a stock kernel maintainer script but
does create an initial RAM file system when invoked by a maintainer
script from a kernel image package created by make-kpkg. (By the way,
since this script is running under debconf, output from update-initramfs
should be redirected to standard error via 2.) I don't remember the
kernel-package logic being present in this script the last time I looked
at it.
(1) As far as I am able to determine, my original statements are correct,
with the exception of the correction made in the above paragraph.
If you can prove me wrong, please do so.
(2) This was not spam. Spam is unsolicited advertising.
This was a response to an RFC, to which I was explicitly
included as an adressee.
(3) All the addressees of my e-mail were legitimate stake-holders
in this process. This is not the world.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1137353821.16101.1277752206454.javamail.r...@md01.wow.synacor.com
Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
On Tue, 08 Jun 2010 07:39:58 -0400 (EDT), Vincent Danjean wrote:
On 07/06/2010 17:37, Stephen Powell wrote:
But for a kernel install or reconfigure, it is the responsibility of the
kernel maintainer scripts to invoke the bootloader. See also, for example,
linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
on line 38. This really is an open and shut case, if only I can the kernel
people to actually look at it! Please look at it!
If I recall correctly, kernel maintainers have introduced
/etc/kernel/post{inst,rm}.d/ in order to avoid to hardcode each possible
bootloader in their script.
Can't lilo provide a script here ?
do_bootloader = yes
in /etc/kernel-img.conf means run the historic boot loader for this platform.
For the i386 platform (and amd64) the historic boot loader is lilo. For
the s390 platform, that boot loader is zipl. The kernel maintainer scripts
for the s390 platform still specify zipl as the boot loader
my $loader= zipl; # lilo, silo, quik, palo, vmelilo, nettrom,
arcboot, or delo
so that
do_bootloader = yes
in /etc/kernel-img.conf will work. The kernel maintainer scripts for i386 and
amd64
for Lenny and beyond specify a null string. That is inconsistent. It should
specify
my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom,
arcboot, or delo
for consistency between platforms. For non-historic boot loaders, the method
used is to set
do_bootloader = no
in /etc/kernel-img.conf and supply a hook script of some kind, if needed. For
example,
grub version 1 in Lenny invokes it's hook scripts via
do_bootloader = no
postinst_hook = update-grub
postrm_hook = update-grub
in /etc/kernel-img.conf. Grub version 2 does not need a hook script; so it
simply sets
do_bootloader = no
in /etc/kernel-img.conf. In Squeeze and later, there is an alternate method
for running
hook scripts (so that more than one hook script can be invoked). Simply
install the
script in /etc/kernel/preinst.d, /etc/kernel/prerm.d, /etc/kernel/postinst.d, or
/etc/kernel/postrm.d. But even in Squeeze/Sid, the historic boot loader can
still be run
by setting
do_bootloader = yes
in /etc/kernel-img.conf. That still works for zipl on the s390 platform. But
it's
been broken since Lenny on the i386 and amd64 platforms for lilo.
initramfs-tools also examines this variable and runs the historic boot loader
when
update-initramfs -u
is invoked. That still works, even on the i386 and amd64 platforms, provided
that
do_bootloader = yes
is specified in /etc/kernel-img.conf. But
update-initramfs -c
does not invoke the boot loader. Running the historic boot loader during
installation,
reconfiguration, or upgrade of a kernel is still the responsibility of the
kernel
maintainer scripts. And it cannot do so unless my $loader is set to the name
of
the historic boot loader. On s390, that variable is set properly. On i386 and
amd64,
it is not.
The kernel maintainer scripts provided by kernel image packages created by
make-kpkg
on Squeeze and later are another story. They no longer do *any*
post-installation
actions unless user-provided hook scripts cause it to happen. But the
maintainer
scripts for official stock Debian kernel images still support these historic
post-installation activities.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1661542040.41185.1276004599156.javamail.r...@md01.wow.synacor.com
new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
On Mon, 07 Jun 2010 03:22:46 -0400 (EDT), sean finney wrote: On Mon, Jun 07, 2010 at 01:44:05AM +0400, William Pitcock wrote: Have fun. When you have a release that actually has merit, it can be reconsidered for inclusion in Debian. In the meantime, the original plan continues. actually, i don't think you have any say about what software can and can not be in debian, that is the sole privilege of ftp-master. your options are (a) to claim you still want to maintain the package and continue to do so, or (b) ask for its removal by ftp-master. given your comments here i think if you were to claim (a) there would be a decent case for someone to take to the tech-ctte. ftp-master, if they're aware of this argument, may just say why not orphan it instead?. but regardless, if someone else is interested they can just follow that removal with a new upload using their name as Maintainer, and then again it's up to ftp-master to accept or deny it. given that there may be an active upstream and maintainer, and the software is otherwise DFSG-compatible, i don't see why they would deny such a new upload. of course, it would be a lot nicer if you could just hand over the reins of the current package to those who have been asking for them, to avoid some un-needed overhead... sean Perhaps I can offer a solution here. Since William obviously doesn't wish to maintain this package any longer, I am willing to take over his responsibilities as a Debian package maintainer for lilo under two conditions: (1) The kernel team fixes bug number 505609, and (2) Debian ceases its attempts to remove lilo from the distribution. What do you say, William? Do you have any objections? Does anyone else have any objections? If so, speak now, or forever hold your peace. Keep in mind that I have never been a Debian package maintainer before. This will be my first package. Please be patient with me as I learn the ropes, so to speak. As for whether or not lilo continues to be offered as an alternate boot loader by the Debian installer, that is entirely up to them. I would think that the path of least resistance would be to maintain the status quo, but if they want to remove lilo from the Debian installer menu that's their call, as far as I am concerned. I just don't want to see lilo removed from the distribution. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1196418916.5745.1275918400688.javamail.r...@md01.wow.synacor.com
Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
On Mon, 07 Jun 2010 10:33:52 -0400 (EDT), Holger Levsen wrote: Hi Stephen, thanks for stepping up maintaining lilo in Debian! I hope you'll manage this well. Um, thanks; but I don't understand the reassignment of bug number 505609 to package initramfs-tools. If you read my previous posts to the bug log, it is clear that this problem started with a change to the maintainer scripts between Etch and Lenny. Please read my posts again carefully. Then consider whether this is really a bug in initramfs-tools or a bug in the kernel maintainer scripts. initramfs-tools only gets involved when update-initramfs -u is issued. And it *does* invoke the boot loader under these conditions, if do_bootloader = yes is present in /etc/kernel-img.conf and lilo is installed. But for a kernel install or reconfigure, it is the responsibility of the kernel maintainer scripts to invoke the bootloader. See also, for example, linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader on line 38. This really is an open and shut case, if only I can the kernel people to actually look at it! Please look at it! -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/120369280.10411.1275925077969.javamail.r...@md01.wow.synacor.com
Re: Re (2): lilo removal in squeeze / new lilo upstream
On Sun, 06 Jun 2010 09:39:59 -0400 (EDT), Joachim Wiedorn wrote: I see that more people than thought still want to have or need LiLO. Now I have decided to start and reanimate the upstream development. Everyone is invited to join in this development. I'm working on LiLO version 23. Shortly with more informations ... Fondest regards, Joachim Wiedorn That's great news, Joachim! If it weren't for my complete ignorance of x86 assembly language, I might have been tempted to try it myself. But perhaps I may be able to help out in some way. We lilo users are very grateful to you for your willingness to take over. By the way, did anyone ever find out what happened to John Coffman? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1978551454.33.1275845120737.javamail.r...@md01.wow.synacor.com
Re: Re (2): lilo removal in squeeze / new lilo upstream
On: Sun, 06 Jun 2010 17:44:05 -0400 (EDT), William Pitcock wrote: Joachim Wiedorn ad_deb...@joonet.de wrote: I see that more people than thought still want to have or need LiLO. Now I have decided to start and reanimate the upstream development. Everyone is invited to join in this development. I'm working on LiLO version 23. Shortly with more informations ... Have fun. When you have a release that actually has merit, it can be reconsidered for inclusion in Debian. What is your definition of merit, William? And why does the current release not have it? In the meantime, the original plan continues. The original plan was based on false assumptions. Why would you continue with a plan based on false assumptions? We now have a release of lilo with (a) an active upstream maintainer, and (b) no release critical bugs. If you simply don't want to be a Debian package maintainer for lilo anymore, why not ask for volunteers to take over for you? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1545549194.342558.1275871054568.javamail.r...@md01.wow.synacor.com
[SOLVED] Unbootable after kernel upgrade: Lilo can't load kernel
This is not a lilo bug. The problem is that lilo's map installer did not get run during the kernel upgrade process. The fact that the user was able to boot his old de-installed kernel is proof of this. The /boot/map file still pointed to the blocks in the file system which formerly contained the old kernel and its initial RAM file system image. And since, fortunately, those blocks had not yet been reused, the data was still there. Modules which were loaded from the initial RAM file system image loaded OK. But once the switch was made from the initial RAM file system to the permanent root file system, further module loads could not be done, since the modules had been erased. When the user manually ran lilo's map installer at the command line, the problem disappeared. The real question is, Why didn't the map installer get run during the kernel upgrade? There is not sufficient data in the bug log to determine the answer to that question, but I have observed that do_bootloader = yes in /etc/kernel-img.conf no longer causes lilo to be run when a new kernel is installed. I believe that this change in behavior was caused by changes to the kernel maintainer scripts made around the time of the switch to grub version 1 as the default boot loader. do_bootloader = yes in /etc/kernel-img.conf still causes zipl to be run on the s390 port, a port that neither version of grub supports. do_bootloader = yes should still be specified in /etc/kernel-img.conf, however, so that update-initramfs -u will cause lilo's map installer to be run when an initial RAM file system is updated (but not when it is initially created). So is this a bug in the kernel maintainer scripts? Or is it a feature? I don't know. I'll leave that up to the kernel maintainers to decide. A full discussion of how to make sure that lilo's map installer gets run during the installation of a new kernel, taking into account all types of kernels (official stock Debian kernels, custom kernels created by make-kpkg, custom kernels created by make deb-pkg, etc., is beyond the scope of this bug log. Interested readers may wish to look at my web page on kernel building, particularly step 10, for further information. http://www.wowway.com/~zlinuxman/Kernel.htm The instructions for customizing the Lenny environment will work in Squeeze or Sid also, provided that you use only official stock Debian kernels. If you use custom kernels in Squeeze or later, you *must* use hook scripts to ensure that any post-installation activities, such as the creation of an initial RAM file system, updating symlinks, or running a boot loader, take place. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2000712474.159302.1275230137351.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Fri, 28 May 2010 16:44:11 -0400 (EDT), Peter Samuelson wrote: Stephen Powell wrote: It *does* recognize lilo and has special logic to patch lilo after the restore so that the machine will boot. So can this software be fooled into thinking it is dealing with lilo? Would it be sufficient to rename /boot/extlinux/extlinux.sys to /boot/maps or something? I wasn't going to post to this thread on debian-devel anymore, since it is evident that they really don't want to hear about it. But for the sake of answering a specific question I will respond. I'm afraid that won't work. In the first place, renaming /boot/extlinux/extlinux.sys to something else would interfere with the correct operation of extlinux. Second, this is the second stage loader for extlinux. It does not use a map file, as lilo does. Third, the boot sector for extlinux has a different signature than the lilo boot sector. And there are probably more reasons as well. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/254055006.148047.1275142053121.javamail.r...@md01.wow.synacor.com
Re: Re (2): lilo removal in squeeze (or, please test grub2)
On Sat, 29 May 2010 10:51:10 -0400 (EDT), Marc Haber wrote: On Tue, 25 May 2010 11:42:34 -0400 (EDT), Stephen Powell wrote: You're missing the point. The main selling point to management is that Linux is free. If they have to buy new backup software in order to accommodate Linux' backup requirements, that will kill it on the spot. Whatever boot loader I use must not require new backup software or impose special backup requirements. From what I guess, your backup scheme is highly hardware dependent since lilo uses block lists in the MBR to find its later stages on disk. Strictly speaking, the MBR points to the partition boot sector, the partition boot sector points to the second stage loader, the second stage loader points to the map file (/boot/map) and the map file points to the kernel image blocks and the initial RAM file system image blocks. But yes, this is location-dependent information. So your restored system will only boot if you restore to a disk with the exactly same geometry. Not if the restore software understands the format of the boot loader files and knows how to patch them. Fortunately it does. But only for lilo. And only under certain conditions. I would change the restore process to manually reinstall the boot loader after the backup software finished with its restore job anyway, or you might be surprised with an unbootable restored system if you had to restore to different hardware. That is not an option. When the restore completes it automatically reboots the machine. Besides, the restore software runs under DOS, not under Linux. The boot loader installation program won't run under DOS. If patching the boot loader files was not successful, the machine won't boot. Manual intervention is necessary (i.e. boot from a rescue CD, chroot into the root file system, mount the /boot partition, and re-run the boot loader installation program). The only way around this problem (other than using smarter software) is to create an image (sector by sector) backup and do an image restore. That works with any boot loader. But that has two major drawbacks. (1) The technician has to remember to do it that way, and (2) it prevents restoring individual files. You either restore the whole server or nothing. As I've stated in other posts, we are aware of the deficiencies of our backup software and are looking at alternatives. But right now, this is what we're stuck with. Thanks for the suggestions, though. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/225990742.152441.1275162416466.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Sat, 29 May 2010 14:40:41 -0400 (EDT), Andreas Barth wrote: Stephen Powell wrote: On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote: After some discussion about lilo on #debian-devel in IRC, it has pretty much been determined that kernel sizes have crossed the line past where lilo can reliably determine the payload size. We're speaking about #505609 I assume? I hope not. Strictly speaking, 505609 is not a lilo bug. The key is that he was still able to boot his old kernel that had been de-installed. That's a sure sign that lilo's map installer did not get run during the kernel upgrade process. It used to be that if do_bootloader = yes was specified in /etc/kernel-img.conf that installing a new kernel would cause lilo to be run. That is no longer the case. update-initramfs -u ... will cause lilo to be run if this option is set; but update-initramfs -c ... (or mkinitramfs ...) which is what is run during installation of a new kernel, will not. I have created my own hook script to fix that problem on my system. Strangely, though, do_bootloader = yes in /etc/kernel-img.conf still causes zipl to be run during kernel installation on the s390 platform. Something must have changed in the kernel maintainer script or in update-initramfs that causes the lilo map installer to not be run anymore under conditions that used to cause it to be run. Look carefully at the console log. There is no output from the map installer until he manually runs lilo. He apparently thinks that running lilo from the command line simply lists the installed kernels. No. Running lilo from the command line is what fixed the problem. If there's a bug here, it's somewhere else in the kernel installation process, not in lilo itself. If this so-called bug in lilo is what prompted the decision to drop lilo, then the decision was based on bad data. lilo, at least in this case, is working as designed. The problem is that the lilo map installer did not get run during the kernel installation process. I've helped a number of people on debian-user with problems like this, and in every case so far running lilo at the command line fixed the problem. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/267435255.153128.1275165812236.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Tue, 25 May 2010 13:12:27 -0400 (EDT), Stephen Powell wrote: Boyd Stephen Smith Jr. wrote: No software is entirely without cost ... volunteers work on whatever they like ... your specific requirements may differ from their goals ... volunteers are rarely concerned with market share ... All excellent points, Boyd. Fortunately in this case, extlinux appears to be a viable solution. I'll soon know ... Unfortunately, logical backups of a Linux machine using the extlinux boot loader do not work with our backup/restore software. The master boot record and partition boot sector are restored correctly, but /boot/extlinux/extlinux.sys will probably not be restored to the exact same sectors from which it was backed up, and the restore software has no special logic to remedy that situation. Therefore, after restore, the machine will not boot. It *does* recognize lilo and has special logic to patch lilo after the restore so that the machine will boot. The problem can be circumvented by taking an image backup instead of a logical backup, but that gets into special backup requirements. Until we get newer backup software I must either use lilo or ask for special backup procedures for my Linux servers. I choose the former. Logical (file by file) backups have many advantages, one of which is to avoid giving the Windows advocates an excuse to oppose further deployment of Linux servers. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1739612780.129666.1275057918173.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Wed, 26 May 2010 00:23:04 -0400 (EDT), Daniel Baumann wrote: On 05/26/2010 03:36 AM, Stephen Powell wrote: ... That works for now; but if a package upgrade for extlinux is ever downloaded, I'm afraid that new versions of the hook scripts will be copied into these directories which are marked executable, and my hand-made configuration file will get wiped out. ... as of current git, you can now use EXTLINUX_UPDATE=false in /etc/default/extlinux to prevent having update-extlinux do anything. That's good to know, thanks. I'm looking forward to that feature migrating into squeeze. Second, it is important that any script run as a hook script not produce any output at all to standard output. I found that out the hard way when I was writing my own hook scripts for use with lilo. That's because they run under debconf, which has redirected standard output for its own purposes. Thus, anything written to standard output is (1) never seen by the user and (2) has a good chance of messing up debconf, which is examining the output. The invocation of update-extlinux should have a redirection on it to redirect output to standard error. For example, update-extlinux 2 none of the hooks is doing this (initramfs-tools, grub, etc), might needs further convincing. It is a little-known requirement, and often you can get away with it, but not always. I'm going from memory here, but I believe that debconf redirects standard output, then calls the maintainer script for the kernel, which calls the run-parts utility, which then calls the hook script. If the standard output produced by the hook script matches something that debconf is looking for it can mess things up. Sometimes the failure will occur for one type of call, such as a purge, but not for another type of call, such as a configure or a remove. Manoj Srivastava, author and Debian package maintainer of the kernel-package package, mentions it in the man page for kernel-img.conf, and I have personally been burned by it with one of my own hook scripts that I wrote for use with lilo. The hook script failed with a non-zero return code, which caused the kernel installation process to fail. I could not figure out for the life of me what was wrong. The script ran fine when invoked stand-alone, but not as a hook script. Redirecting lilo output to standard error solved the problem. It ran perfectly after that. But even if the stuff written to standard output does not mess up debconf, the user still won't see it. The safe (and informative) thing to do is for all hook scripts to write all output to standard error. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/375009335.66290.1274880285294.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
Ferenc Wagner wrote: Stephen Powell zlinux...@wowway.com writes: Both grub-legacy and grub-pc use sectors on the hard disk outside of the master boot record and outside of a partition ... You may want to try extlinux, it works much like LILO in this respect. Well, I tried extlinux last night, and I am hopeful that this is going to be a solution, at least for me. extlinux seems to combine the best parts of grub-pc and lilo. Like grub-pc, extlinux understands the file system, and can read the configuration file, kernel, and the initial RAM file system image from the file system without needing a list of specific blocks to read. Thus, the boot loader does not need to be re-run every time a kernel is installed or updated or an initial RAM file system image is installed or updated. The number of file systems it supports is limited, but that's OK. A separate /boot partition of the file system type supported by the boot loader is acceptable. But like lilo it stays out of unallocated (and therefore not backed up) sectors. The boot block of extlinux is installed in the boot sector of a partition, and the second stage loader occupies a file within the partition. It does not use the master boot record. It relies on a master boot record program to chain load it from the partition boot sector. (I use the mbr package for that.) It *does* support the specification of an initial text video mode (vga option), though this is not specifically documented. Speaking of documentation, that seems to be its main weakness. Documentation is sketchy and spread out over a number of different files. I would have had a hard time configuring it if it weren't for correct guesses based on my knowledge of how lilo is configured, which newer users won't have. It installs hook scripts that I don't want (and that have bugs). But after manual configuration and tweaking, it works just fine. Now, if it passes the backup / low-level-format / restore test, I'll be good to go. Stay tuned ... -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1078928757.35141.1274793733671.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Tue, 25 May 2010 07:08:20 -0400 (EDT), Mihamina Rakotomandimby wrote: William Pitcock neno...@dereferenced.org wrote: This bug *can* be fixed, but not without a significant rewrite of the way that lilo's stage2 loader code works. Given that there is no active upstream and that the Debian lilo package carries many patches for bug fixes that are alleviated by standardizing on grub2, this seems like the best option for Debian. Agreed: dead (and buggy) softwares must be out of the distribution. Whatever happens. If LILO regains upstream coders, its return to the distribution is quite easy. By that standard, grub-pc should be removed from the distribution. It may have upstream support, but based on other posts I've seen, it effectively has no maintainer. Which is worse, a package with effectively no upstream support or a package with effectively no maintainer? And grub-pc is buggier than lilo. I understand the need to remove packages with no upstream support. But asking users to test a package with umpteen known release-critical bugs, most of which have apparently been fixed upstream, but have not been fixed in Debian because there is no maintainer to download a new upstream version, is not a reasonable request in my humble opinion. Get a maintainer for it, fix the known bugs, and *then* ask the users to test it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1927842586.35924.1274795074336.javamail.r...@md01.wow.synacor.com
Re: Re (2): lilo removal in squeeze (or, please test grub2)
On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote: Stephen Powell wrote: (3) The need for special backup requirements will be used by the opponents of Linux at my place of employment to oppose further deployments of Linux, ... What about the carrot approach? Find an even better backup method, compatible with Grub 2 and appealing to your management for its efficiency. You're missing the point. The main selling point to management is that Linux is free. If they have to buy new backup software in order to accommodate Linux' backup requirements, that will kill it on the spot. Whatever boot loader I use must not require new backup software or impose special backup requirements. And its not just money. As a rule, people like what they know. The backup people are Windows people, and they'd love an excuse to complain to management about the backup requirements of my Linux servers. grub-legacy and grub-pc are non-starters for me for that reason. Until now, only lilo, as far as I knew, met all my requirements. It now appears that extlinux may also work. I'll soon know. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/351821928.39974.1274802154546.javamail.r...@md01.wow.synacor.com
Re: Re (2): lilo removal in squeeze (or, please test grub2)
On Tue, 25 May 2010 11:51:11 -0400 (EDT), Mark mamar...@gmail.com On Tue, May 25, 2010 at 8:42 AM, Stephen Powell zlinux...@wowway.comwrote: On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote: Stephen Powell wrote: (3) The need for special backup requirements will be used by the opponents of Linux at my place of employment to oppose further deployments of Linux, ... What about the carrot approach? Find an even better backup method, compatible with Grub 2 and appealing to your management for its efficiency. You're missing the point. The main selling point to management is that Linux is free. ... Clonezilla is free, and when using the saveparts option to save an image of one partition and not the full hard drive, it includes the MBR and associated data. You can then drop that partition image onto a new/blank disk, that does not have anything in the MBR, and once Clonezilla restores the image to the new partition, will put the MBR in place and the machine boots on its own the next time, with no extra work (I just did this last week with a new hard drive). This has been my experience with using Clonezilla and Lenny, at least. So it may help in your case. Perhaps so. But it's not what the backup people know. They're very comfortable with the backup software that they know and love for backing up their Windows servers, which was purchased with Windows servers in mind. Do you think they're going to redo their whole backup architecture just for a few Linux servers? If I want to play in their sandbox, I have to play by their rules. That's the political reality. At our shop, Linux has a small beachhead on a vast continent controlled by Windows. Over time, the role of Linux may expand to the point where Linux is actually thought about and planned for when decisions are made. But that day is not today. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/479605722.42620.1274806845480.javamail.r...@md01.wow.synacor.com
Re: Re (2): lilo removal in squeeze (or, please test grub2)
On Tue, 25 May 2010 12:03:17 -0400 (EDT), Boyd Stephen Smith Jr. wrote: Stephen Powell wrote: You're missing the point. The main selling point to management is that Linux is free. No software is entirely without cost. Free Software is no exception. There are usually no up-front licening fees, sure. However, volunteers work on whatever they like, and if no one volunteers to maintain and support your software you may have to pay for that. Even with volunteers providing maintenance and support, your specific requirements may differ from their goals and that will require effort to resolve. ... Also, volunteers are rarely concerned with market share, losing your management as users is not necessarily a concern to them. If it is a concern for you, you may have to put forward some additional effort to address your management's issues. All excellent points, Boyd. Fortunately in this case, extlinux appears to be a viable solution. I'll soon know. The guy I need to see about setting a test server to test the backup and restore scenario has been off work with a sick child for the past couple of days, but when he gets back I'll try to prove that it is 100% compatible with our backup software. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1557806589.43087.1274807547943.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Tue, 25 May 2010 11:10:38 -0400 (EDT), Ferenc Wagner wrote: Stephen Powell wrote: ... I installed the mbr package ... The extlinux package itself also contains an mbr.bin, which you can use (it's strong point is probably EBIOS support). So it does. Well, I've now installed extlinux' version of mbr.bin to the master boot record and purged the mbr package. extlinux' built-in version of a master boot record boot loader works great. Speaking of documentation, that seems to be its main weakness. Documentation is sketchy and spread out over a number of different files. /usr/share/doc/extlinux.txt.gz references syslinux.txt, which is fairly comprehensive according to my standards, at least as far as the core is concerned. What did you miss? Some modules may be less well documented. Yes, I found those two files. Reference documentation for each specific boot loader option is there, but what is lacking is tutorial-type stuff. For example, there is a global options section at the beginning that applies to all bootable images, and there are options which are specific to each boot image. I guessed at that mainly based on how /etc/lilo.conf works, but I'm not sure it was directly stated anywhere. It may be hinted at in the description of some individual configuration option but not explained up front. Also, there's no example configuration file. There are little pieces of configuration files but no complete typical configuration file. A picture is worth a thousand words. It installs hook scripts that I don't want (and that have bugs). I hope we can fix them soon (they are Debian specific additions). Remember, I'm used to using lilo. And based on analogies with lilo, I built a /boot/extlinux/extlinux.conf file that looks like this: - DEFAULT Linux APPEND root=/dev/sda2 ro vga=779 TIMEOUT 50 PROMPT 1 LABEL Linux KERNEL ../vmlinuz INITRD ../initrd.img LABEL LinuxOLD KERNEL ../vmlinuz.old INITRD ../initrd.img.old - The kernel and initial RAM disk images are specified via the traditional symlinks. As long as the symlinks are maintained properly, my config file never needs updating, just like lilo's. Consequently, I really don't want the extlinux hook scripts to execute at all when I install or remove a kernel. I solved that temporarily by issuing chmod -x /etc/kernel/postinst.d/extlinux chmod -x /etc/kernel/postrm.d/extlinux That works for now; but if a package upgrade for extlinux is ever downloaded, I'm afraid that new versions of the hook scripts will be copied into these directories which are marked executable, and my hand-made configuration file will get wiped out. I would suggest testing the existence of some flag file. If the flag file exists, then invoking update-extlinux should be bypassed. Thus, if the user doesn't want his hand-made /boot/extlinux/extlinux.conf file to be tampered with, he can create that flag file via touch and the hook script will not run update-extlinux. Strictly speaking, this is an enhancement request. Second, it is important that any script run as a hook script not produce any output at all to standard output. I found that out the hard way when I was writing my own hook scripts for use with lilo. That's because they run under debconf, which has redirected standard output for its own purposes. Thus, anything written to standard output is (1) never seen by the user and (2) has a good chance of messing up debconf, which is examining the output. The invocation of update-extlinux should have a redirection on it to redirect output to standard error. For example, update-extlinux 2 This is a bona-fide bug. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/630546796.56099.1274837814099.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Mon, 24 May 2010 05:36:32 -0400 (EDT), Ferenc Wagner wrote: Kurt Roeckx k...@roeckx.be wrote: On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote: William Pitcock neno...@dereferenced.org (22/05/2010): This means that users should *test grub2 extensively* before Squeeze is released so that any issues can be resolved now. There should also be some folks fixing the discovered issues. grub2 currently seems to be having 18 RC bugs, plus a whole bunch of merged bugs, while lilo only has 1 RC bug. I chatted about this with the grub upstream a couple of days ago. According to Vladimir, most of those bugs are already fixed, but there's nobody around to do a new upload. Both grub maintainers (Felix Zielke and Robert Millan) unexpectedly disappeared some time ago. What about Jordi Mallach and Colin Watson? The package page for grub-pc http://packages.debian.org/squeeze/grub-pc lists them as maintainers too. Have they disappeared as well? Or are they no longer maintainers for this package? In which case their names should be removed from the web page. Somehow I feel a dip in motivation. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1054400013.5379.1274709588267.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote: Stephen Powell zlinux...@wowway.com writes: Both grub-legacy and grub-pc use sectors on the hard disk outside of the master boot record [...] This breaks the design of the backup software that my employer uses. This backup software backs up the master boot record and all partitions; but since the extra sectors used by grub-legacy and grub-pc are outside the master boot record and are not part of any partition, they don't get backed up. Consequently, if we have a hard drive failure and restore from a backup, we have an unbootable machine. Lilo uses only the master boot record. A lilo-booted machine can be backed up and restored with our existing backup software just fine. You may want to try extlinux, it works much like LILO in this respect. It lacks a convenient configuration system, but that of grub-legacy would be easy to adapt, and I actually plan to work on this. Thanks for the tip. That may be an option. I looked at the documentation online, and there does not appear to be an option equivalent to lilo's vga option, though, which I use a lot, especially since svgatextmode has already been pulled from squeeze. As of right now, if lilo was pulled from the distribution, I think I'd be inclined to build my own lilo package from source before switching to any other bootloader. To the best of my knowledge, it is the *only* bootloader which supports setting an initial text video mode *and* does not use any sectors outside the master boot record and outside of a partition. If I'm wrong about that, someone please correct me. As for a convenient configuration system, editing a plain text file is plenty good enough for me. Your time is yours to use as you see fit; but if you have the requisite skills to become the equivalent of lilo upstream, I think there's a lot of people who would rather that you do that, myself included. I'd do it myself if I had the necessary skills and knowledge. But I don't. Thanks again for the tip. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1012155825.7010.1274712448896.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Mon, 24 May 2010 13:01:30 -0400 (EDT), Edward Allcutt wrote: On Mon, 24 May 2010, Stephen Powell wrote: To the best of my knowledge, lilo is the *only* bootloader which supports setting an initial text video mode *and* does not use any sectors outside the master boot record and outside of a partition. If I'm wrong about that, someone please correct me. grub2 supports loading its core.img from a dedicated partition instead of embedding it in the first cylinder. This does require switching to the GPT partitioning scheme which may or may not be acceptable to you. No, the backup software assumes the traditional MS-DOS hard disk partitioning scheme. One can get around this by requiring an image backup, but that has three substantial drawbacks: (1) The entire disk, including free space and extended partition free space, must be backed up. This takes a lot more time. (2) A restore can only be done to a disk of the exact same size as the one backed up. Often, a larger disk must be used because the model that failed is no longer available on the market. (3) The need for special backup requirements will be used by the opponents of Linux at my place of employment to oppose further deployments of Linux, which I wish to avoid at all costs. But thanks for the info anyway. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1081731293.13454.1274723918397.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Mon, 24 May 2010 13:38:55 -0400 (EDT), Ferenc Wagner wrote: Stephen Powell zlinux...@wowway.com writes: On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote: Stephen Powell zlinux...@wowway.com writes: Both grub-legacy and grub-pc use sectors on the hard disk outside of the master boot record [...] You may want to try extlinux, it works much like LILO in this respect. Thanks for the tip. That may be an option. I looked at the documentation online, and there does not appear to be an option equivalent to lilo's vga option, though, which I use a lot, especially since svgatextmode has already been pulled from squeeze. I'm not sure what you're after, I haven't used LILO for ages. But typing vmlinuz-2.6.32 vga=0xf07 at the pxelinux boot prompt gives me a 80x60 console. The other variants use the same code. Interesting. At one point, the kernel itself had de-supported the vga boot option, relying on the boot loader to set the video mode before transferring control to the kernel. And now you're saying it's back. Hmm. According to Documentation/svga.txt in the kernel source tree: This small document describes the Video Mode Selection feature which allows the use of various special video modes supported by the video BIOS. Due to usage of the BIOS, the selection is limited to boot time (before the kernel decompression starts) and works only on 80X86 machines. Note the wording before the kernel decompression starts. That to me implies done by the bootloader, because the bootloader decompresses the kernel (if it is compressed) before transferring control to it, does it not? The vga option is a separate option in lilo. You can't include it in the append variable without lilo generating an error. You've got my curiosity up now. I'll have to try this. I do have a spare computer with which to test. I'm going to have to try installing Squeeze using extlinux as the boot loader. (No doubt I'll have to change bootloaders after installation, as the Debian Installer won't offer that option.) Then I'll see if I can pass it the vga option and have it work. And if that works, then I'll try the backup, nuke, and restore scenario. And if that works, then I may have a viable alternative to lilo. I'll let you know how it goes. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/158609809.14709.1274725819037.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote: After some discussion about lilo on #debian-devel in IRC, it has pretty much been determined that kernel sizes have crossed the line past where lilo can reliably determine the payload size. This bug *can* be fixed, but not without a significant rewrite of the way that lilo's stage2 loader code works. Given that there is no active upstream and that the Debian lilo package carries many patches for bug fixes that are alleviated by standardizing on grub2, this seems like the best option for Debian. This means that users should *test grub2 extensively* before Squeeze is released so that any issues can be resolved now. As for removal, the following things need to be done: (1) The release notes need to be updated to reflect that lilo is no longer a bootloader option; (2) The debian-installer team needs to remove the lilo-installer udeb; (3) The ftpmasters need to remove lilo from unstable (which will be done using the appropriate bug filing once the above steps are made); (4) Users need to test grub2 now. First of all, forgive me for cross-posting, which is generally a no-no. But if you can cross-post, I can cross-reply. Second, unless you reply to debian-user, to which I am subscribed, please CC me. I am not subscribed to any of the other lists. I am not a Debian package maintainer or a Debian developer. I am just an ordinary system administrator. So I'm sure that my opinion will not count for much. But I am opposed to the removal of lilo. Both grub-legacy and grub-pc use sectors on the hard disk outside of the master boot record (cylinder 0, head 0, sector 1). In other words they use cylinder 0, head 0, sector 2 and possibly subsequent sectors on cylinder 0 head 0. This breaks the design of the backup software that my employer uses. This backup software backs up the master boot record and all partitions; but since the extra sectors used by grub-legacy and grub-pc are outside the master boot record and are not part of any partition, they don't get backed up. Consequently, if we have a hard drive failure and restore from a backup, we have an unbootable machine. Lilo uses only the master boot record. A lilo-booted machine can be backed up and restored with our existing backup software just fine. Given these requirements, I wouldn't use grub-pc even if it were bug free and well documented. (But neither is the case!) As for the claims that kernels are too big now, I find that hard to believe, especially now that we have the large-memory option available. The standard stock Debian kernel image file that I use for Squeeze, vmlinuz-2.6.32-3-686, is currently 2234080 bytes. Are you trying to tell me that there's no room for a 2M kernel below the start of the EBDA? I am able to load *both* the kernel *and* the initial RAM filesystem below the EBDA (i.e. the large-memory option is not used) if I use MODULES=dep instead of MODULES=most in the initial RAM filesystem under Lenny. I'll bet I can do it with Squeeze too. I realize that lilo doesn't work for everyone, and I'm not suggesting that it be the default bootloader; but to get rid of it entirely is unacceptable. As far as I know, it's the only bootloader that meets all of my requirements, and I will not voluntarily give it up. No doubt you will tell me that I am welcome to maintain it myself. Unfortunately, I do not have the requisite skills to do so. All I can do is to appeal in the name of reason that it not be dropped. Also, please excuse my ignorance, but what exactly is this payload size to which you refer? Is that the same thing as the size of the kernel? Or is it something else? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/698259750.358730.1274641482395.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Sun, 23 May 2010 16:11:30 -0400 (EDT), William Pitcock wrote: Stephen Powell zlinux...@wowway.com wrote: (blah blah blah blah) Nobody cares if you are opposed to it. Unless you are offering to become lilo upstream, it's going away. William I do understand why a Debian package maintainer does not wish to become upstream. And I hope that someone who is both willing and able to do so steps up to the plate. But withdrawing it from the distribution seems like overkill to me, especially since you want to withdraw it from Squeeze and not Squeeze+1. Lilo, as it exists today, works just fine for my purposes. And apparently it works just fine for a lot of other people too. The Lord bless you, William. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1170680188.363342.1274662130640.javamail.r...@md01.wow.synacor.com
Re: Mouse configuration during installation needs improvement
Well shut my mouth! I did some testing this past weekend, as I said I would, and results are better than expected. First, leaving things the way I had them configured (X pointing to /dev/gpmdata and gpm pointing to /dev/psaux, I unplugged the PS/2 mouse from the mouse port. The mouse became dead in both X and gpm (duh!). I then plugged it back in again. It worked again, both in X and in gpm! Then I configured X and gpm both to use /dev/input/mice and turned off gpm's repeater function. After restarting both daemons and verifying that both X and gpm could use the mouse, I again unplugged the mouse. Again it was dead in both X and gpm (duh!). And again I plugged it back in and it started working again, both in X and in gpm, with no action on my part. I didn't have to restart the gpm daemon, I didn't have to restart X, I didn't have to unload and reload a kernel module, etc. This is better than I expected. Of course, this is on a different machine (a Dell Dimension 4400) than I last tried this on (an IBM Thinkpad 600). But I'm impressed. Theoretically, one is not supposed to be able to hot swap a PS/2 mouse. But it works. Kudos to the kernel folks. The repeater function of gpm now appears to be obsolete, as you say. I would still like to see gpm installed by the Debian installer whenever a mouse is detected on the system in order to allow copy and paste in a virtual console. But I'm not going to flog a dead horse. The powers that be obviously don't like that idea. Thanks to all contributors to this thread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mouse configuration during installation needs improvement
Since my initial post I have done some research on the subject of mouse support in the Linux kernel. I can see now why my suggestion was met with such strong opposition: it goes counter to the direction the kernel has been going since 2.5. With such a sweeping redesign of mouse support since 2.4, I think I need to do some experimentation to see if gpm still provides one of the key benefits that it once provided, namely the ability to resurrect a dead PS/2 mouse after unplugging and replugging. On older kernels, I could issue the following command which nearly always regained the use of the mouse in a virtual console: /etc/init.d/gpm restart And if X was set up to use /dev/gpmdata, this would of course also resurrect the mouse in X too. Thomas Hood, in his web page for Debian GNU Linux on an IBM Thinkpad 600, specifically recommends this (http://panopticon.csustan.edu/thood/tp600lnx.htm). However, this information appears to have been written when he was running a 2.4 kernel. On my system, gpm is currently configured to use the legacy mouse port /dev/psaux, but it appears from what I've read that this device no longer gives the direct access to the physical port that it once did. I wouldn't be surprised if gpm has thereby lost its ability to resurrect the mouse. I'll do some testing over the weekend and let you know what I find out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Mouse configuration during installation needs improvement
With current kernels, if you use /dev/input/mice, the port can be shared by gpm and X at the same time, and all mice you connect (no matter what) show up in that device. Thanks for the update on mouse sharing in newer kernels. I didn't realize that this support had been added. That does take away part of my supporting argument for configuring X to use gpm. Of course PS/2 mice can not be connected while the system is on, since the hardware simply is not designed for that ... I realize that PS/2 mice were not intended to be hot swapped, but stuff happens. Sometimes the connector is loose and falls out, sometimes a mischievous co-worker unplugs it as a practical joke, sometimes the mouse fails, sometimes someone trips over the cord, sometimes the dog chews on it, sometimes an inquisitive toddler unplugs it, etc. Being able to recover from these things without requiring a reboot (or at least restarting the X server) is a nice feature, one that gpm provides. gpm also leads to a number of complications for some users, as seen in the BTS. Well, as Scotty of Star Trek fame says, The more they overtink the plumbing, the easier it is to stop up the drain. (Star Trek III: The Search for Spock) But then again, you could make that argument for the new kernel support for mouse sharing too. Yes, adding another layer of software also adds another thing that can go wrong. The key is to make the benefits greater than the cost. I can only say that I have used gpm on several different machines under several different releases of Linux, and I have never had a bit of trouble with it. In some cases I seem to remember it allowing the mouse to work when X couldn't drive it directly (the fups2 protocol came to the rescue). And it has saved my hindquarters when the mouse got unplugged somehow. Given most people don't use the console ever, installing a service that is only for console use by default is simply wrong. I'm not sure how one would know that most people don't use the console. I, for one, use it a lot. But even it it's true, I don't see why a device driver for a device that is present on the system shouldn't be installed. Should you not install serial port support because most people don't use the serial port? It won't HARM people who DON'T use the console, will it? We're talking about basic hardware support here, something that many applications can use -- not an application. Please reconsider. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Mouse configuration during installation needs improvement
Per the suggestion of Jérémy Bobbio when he closed Bug # 481514 against installation-reports, I am posting this item to the debian-devel mailing list. The Debian installer needs some improvement when it comes to mouse configuration. Currently, if the user requests a standard system and a desktop environment in the Debian installer, the X Window System will be installed in such a way that it drives the mouse directly, rather than going through gpm; and gpm is not installed. I recommend that gpm be installed whenever a mouse is detected on the system; and if the X server is also installed, it should always be configured to get mouse events from the gpm daemon rather than drive the mouse directly. This will allow the use of the mouse both in a virtual console and in X. Not only that, but hot swapping the mouse will be far less disruptive for X users. When the X server drives a standard PS/2 mouse directly, if the user unplugs the mouse and plugs in another one while the system is running, he must stop and restart the X server, losing all of his X applications in the process, in order to regain the use of the mouse. But when using gpm, all he must do is stop and re-start the gpm daemon to make the mouse work again. The X server is unaffected and the X applications are unaffected. With this recommendation, you should also move gpm to CD-ROM number 1. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
