Linus Torvalds at the Pearly Gates
Linus Torvalds is standing at the Pearly Gates as people are coming in. He asks the first person, What's your IQ? 150. I'd like your opinion on some things I've been thinking about in termsof tools to partially automate the process of porting a kernel to a new architecture. The two of them have a wonderful chat for a couple of hours, and then the man goes in. Linus asks the next person, What's your IQ? 110. So, how're the Mets doing? They chat for half an hour before the man goes in. There is nobody for a while, and Linus begins to get bored. Then, finally, another person comes. What's your IQ? 65. Aah, wonderful! Would you mind explaining to me a couple of things about Debian's apt-get hamm to slink upgrade? - I upgraded my laptop from 2.0.34 to 2.1 in order to have better chances with Blackdown's Java 2, and I am far from pleased with the results so far. I have discovered by now at least two major things that were working quite well and are now quite broken: 1: XFree86 was downgraded from 3.3.3 to 3.3.2.1. 3.3.3 supports my video card; 3.3.2.1 does not. This means that my X display is now (mal)functioning at 320x200 -- I can see the lower right quadrant of an xterm. The machine was also set to start xdm on boot; coming in with a rescue floppy was the only way I could figure out to get it to boot and give a text terminal (I did not have the boot scripts start xdm before). 2: /dev/eth0 no longer exists, and I cannot locate anything in the documentation telling how to regenerate that or some equivalent device. MAKEDEV, for instance, did not recognize eth0 as a parameter. Therefore, I have no network functionality, and am forced to do all my transfers by floppy. There are several dozen megabytes of software I want to download (Blackdown JDK and XFree86). This is really frustrating... I can see a plausible reason for the first to have happened (specifically, since I did not install 3.3.3 through dpkg, it thought that the files were its own), but that blindness can and should be avoidable. One mechanism I can think of OTOH would be for the database to keep checksums of the files for earlier versions, so that it can at least ask before clobbering something which does work and replacing it with something which doesn't work. If this behavior isn't changed, there should at least be an emphatically worded warning so that people don't lose their files. Can anybody help me? In particular, can anybody tell me what the major and minor numbers should be for /dev/eth0 (or, if that file has been replaced, what has replaced it)? I'd really like to have ethernet working, so that I can get XFree86 and (God willing) JDK loaded and working, and get back to my programming. -Jonathan
Re: Linus Torvalds at the Pearly Gates
Jonathan Hayward writes: The machine was also set to start xdm on boot; coming in with a rescue floppy was the only way I could figure out to get it to boot and give a text terminal (I did not have the boot scripts start xdm before). I agree that this a serious bug. The authorities don't agree, however. One mechanism I can think of OTOH would be for the database to keep checksums of the files for earlier versions, so that it can at least ask before clobbering something which does work and replacing it with something which doesn't work. Another is to do what everyone else does and install stuff that is outside the packaging system under /usr/local. /dev/eth0 no longer exists, and I cannot locate anything in the documentation telling how to regenerate that or some equivalent device. If you had a /dev/eth0, I don't know where you got it. Linux (and Unix in general) has no such thing. MAKEDEV, for instance, did not recognize eth0 as a parameter. Not surprising. Therefore, I have no network functionality, and am forced to do all my transfers by floppy. Did you select the appropriate driver when you compiled your kernel? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Linus Torvalds at the Pearly Gates
On Thu, 1 Apr 1999, Jonathan Hayward wrote: 1: XFree86 was downgraded from 3.3.3 to 3.3.2.1. 3.3.3 supports my video Apt will not downgrade any package, I don't believe. You mean that the X package overwrote your manually installed copy. (Not to nitpick, just trying to clarify so we are all on the same page.) 2: /dev/eth0 no longer exists, and I cannot locate anything in the documentation telling how to regenerate that or some equivalent device. MAKEDEV, for instance, did not recognize eth0 as a parameter. eth0 is not a /dev/ file, it's a network interface. It is brought up by scripts in /etc/init.d, specifically /etc/init.d/network. However, you must have support for your ethernet card in the kernel... Have a look at the ethernet HOWTO. This is really frustrating... I can see a plausible reason for the first to have happened (specifically, since I did not install 3.3.3 through dpkg, it thought that the files were its own), but that blindness can and should be avoidable. This is considered user error. If you want to install unpackaged software, you have to use /opt or /usr/local or the like. There is no way for Apt or dpkg to handle any random thing you install, so they don't try. Instead you are guaranteed that Debian packages will not alter /opt or /usr/local. Apt's internals require strict control over all dependencies; that's why it refuses to run if you have broken dependencies. One mechanism I can think of OTOH would be for the database to keep checksums of the files for earlier versions, so that it can at least ask before clobbering something which does work and replacing it with something which doesn't work. 90% of the time this would just be annoying (not to mention it would slow things down and fill disk space), and Debian has other means of handling it, see below... If this behavior isn't changed, there should at least be an emphatically worded warning so that people don't lose their files. Can't argue with that, documentation could be enhanced. However, you can get what you want without losing the power of Apt and dpkg. Checksums are kept for config files, which roughly means files you are allowed to change. So you can always change these safely. If you want to change any other file, you have to run dpkg-divert to redirect the packaged copy. You can find documentation on config files in the developer's corner on the web site, and dpkg-divert --help is helpful. In this particular case: you can get the latest video card support by simply replacing XF86_SVGA (or your server) with a newer binary available from www.xfree86.org. You can then dpkg-divert the package's version of the server binary, or simply remember not to upgrade X. I think the dpkg-divert command would be: dpkg-divert --add /usr/X11R6/bin/XF86_SVGA Later, when you upgrade your X package to one that supports your card, you will want to dpkg-divert --remove the same file. There are also newer unofficial X packages floating around somewhere, but I don't remember the URL. HTH, Havoc
Re: Linus Torvalds at the Pearly Gates
On Thu, Apr 01, 1999 at 07:48:27PM -0600, Jonathan Hayward wrote: 1: XFree86 was downgraded from 3.3.3 to 3.3.2.1. 3.3.3 supports my video card; 3.3.2.1 does not. This means that my X display is now (mal)functioning at 320x200 -- I can see the lower right quadrant of an xterm. The machine was also set to start xdm on boot; coming in with a rescue floppy was the only way I could figure out to get it to boot and give a text terminal (I did not have the boot scripts start xdm before). I seriously doubt you got downgraded to 3.3.2.1. For one thing, XFree86 3.3.2.1 did not ship with slink. XFree86 3.3.2.3 did. Also, XFree86 3.3.3 did not ship with hamm. What probably happened is that you installed XFree86 3.3.3 in a manner that bypassed the Debian packaging system, and did not use the equivs package, or dpkg-divert, or some other Debian-supported tool, to let the packaging system know that you had done it. There is not a reasonable way to determine whether or not a user has bypassed the packaging system without telling it. One (very poor) solution would be to ship pre-calculated md5sums of every file that ships with a given package, and check each each and every one against md5sums of the actual installed files at upgrade time. For packages the size of X, you would be very, very unhappy with this approach. So, dpkg either thought you didn't have X installed at all, or thought you had an older version installed (maybe the one that came with hamm). So as far as it new, there was a newer version of XFree86 available than you had installed. As for the xdm situation, this has been covered, covered, and covered again. Did you read the Release Notes for slink? Perhaps not. But... Does this prompt look familar? The xbase package is obsolete and may be removed (with dpkg --remove xbase). If you are upgrading from Debian 2.0 or earlier, you should read the /usr/doc/xbase/README.Debian file. Read this file now? (y/n) [y] Perhaps not, or perhaps you ignored it. Here is some of the information from that README file. Important things to note: 1) Now that it has been upgraded, the xbase package should be removed as soon as is convenient. Leaving it in place will make it necessary to use the --force-depends option to dpkg to remove any package that xbase depends on (like xdm and xfs, see below.) dpkg --remove xbase 2) xdm and xfs (among other programs) are now in their own packages. They will start automatically on boot if they are installed. If you do not desire this, remove the packages before your next reboot. dpkg --remove xdm dpkg --remove xfs -- G. Branden Robinson |Convictions are more dangerous enemies Debian GNU/Linux |of truth than lies. [EMAIL PROTECTED] |-- Friedrich Nietzsche cartoon.ecn.purdue.edu/~branden/ | pgpBKgywiliC9.pgp Description: PGP signature
