Re: The new LILO not working?
NFS is a module under debian, I've used it plenty of times when installing debian. Andrew (Note my reply address is corrupt. Mail to [EMAIL PROTECTED]) __ Reply Separator _ Subject: The new LILO not working? Author: karl@[EMAIL PROTECTED]@MAILGW at DECPostmaster Date:28/12/95 11:16 AM Hi All... I remember seeing the new version of LILO coming out and it was marked that it had to be with ELF etc etc. I also noticed the mbr pacakge in the base area for 1.0 - having an ELF system her I just upgraded to the latest of everything, so effectively saying that all the relivent packages I need I've installed the latest of. Having said that: I had a power failure about an hour ago. The machine hung at the bootup with LI so it had to be a problem with lilo. Thank my lucky stars I have another machine here with normal a.out that is a mirror of ftp.debian.org (1.0 as well) otherwise I don't know what I'd do. Ok, got the newest bootdisk from the development tree onto a disk, booted it fine, I then wanted to mount via NFS my hard drive on the other machine containg the mirror - to my SHOCK there was *NO* NFS support in the kernel. Ok, so I ftp'd the package (the old lilo from the stable tree) de-installed mbr and then installed the lilo package on top of the new one. I then was able to reboot fine after saying Yes to add a boot block. I'm not sure if I was actually doing anything wrong, but I did have the latest of everything installed and it broke on the reoobt as I said above (hence this email) Don't get me wrong, I upgraded Debian from an install of .93R5, and when I tried to use both the custom bootdisk and normal bootdisk, I wasnt able to mount any filesystems which was rather annoying (probobly because of the newer versions of fsck etc) but if I didnt have my other computer here I would've surely been doomed to all eternity and might've had to re-install R5 over the top. I wondered why NFS support wasnt in the bootdisk (is it meant to be?) otherwise how are we to install over nfs? Also might be handy to compile iso9660 for some CDROMS that have debian on the for a cdrom install perhaps. In any case is anyone else seeing the problem with the new lilo/mbr packages from the development trre under base that I've just got? -- Karl Ferguson [EMAIL PROTECTED] Network Supervisor - Tower Internet Services. | Internet Providers and | Tel: +61-9-316-3036 Fax: +61-9-381-3909| Networking Solutions |
Re: newbie comments
bash has 'type' which equivalent to which. Why can't you export /usr? I believe there was talk of doing things for NFS mounting but it seems difficult and/or kludgy to me. Andrew (note my reply address is corrupt, mail to [EMAIL PROTECTED]) __ Reply Separator _ Subject: newbie comments Author: akumria%sally@[EMAIL PROTECTED]@MAILGW at DECPostmaster Date:28/12/95 11:11 AM We were also wondering in what package which/where are in? Since I (and thus them) mainly use bash and it isn't part of the installed base. On that topic, perhaps there could be an interface via the WWW so you could type in the name of a program (say unzip), and see what package you need to download to install it. Lastly, I had been reading the FSSTND and was wondering how the members of the Debian team were interpreting it. Are you/will you be making available packages that reside in /usr/local/ ? Although the FSSTND says that no distribution should put anything there initially, it does not specify what can/should happen post installation. I, personally, would like things in /usr/local/ so I could NFS export/mount that particular tree to numerous machines. Cheers, Anand. -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on --
Bug#2066: error opening terminal : linux
Hi, Can you (provides you still have thisproblem :-), try and identify which executable does that? (strace may help...) Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
libgr
I thought debian used to have libgr but I can't find it anywhere. I just grabbed the latest version from ftp.ctd.comsat.com and it looks fine so far. I could really use this for the netpbm package I'll be uploading soon. So, I'm going to build a debian package and upload it, it shouldn't take long. The correct thing to do with shared libs is to do ldconfig in postinst but not in postrm, right? Darren [EMAIL PROTECTED] http://www.daft.com/~torin/[EMAIL PROTECTED] [EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996 @ Do you have your clothes on? I probably don't. Take yours off. Feel better. @ @ Sysadmin, webweaver, postmaster for hire. C and Perl programmer and tutor. @
Re: Bug#2063: scsi driver sequence unreasonable
Hi Jeff, IMHO, the fewer changes between Debian's kernels and the upstream ones, the better... You are right. I introduce almost no changes at all, except as I feel necessary or very beneficial. Even then, I restrict changes to common and available patches. Linus has a focus and a set of goals in releasing 1.3 patches, which I fully support (most of the time, anyway :-). We need to support a more ``bread butter'' user community and this is where I may introduce few things. If they break anything, please let me know and I will fix them or back off the change. I don't see why we should move any of them. They're arranged in the order they are in for two reasons: 1) to prevent probing problems (i.e. BusLogic must come before Adaptec 154x), and 2) to allow the more popular and/or problematic cards to come first. I think many of us understand why the SCSi drivers are arranged as they are. The logic is correct but the listing order is not always so. The BusLogic case is a good example. In moving the eata_dma, for example, I followed a slightly differet logic (?): Since it is a unique driver, it really does not matter where in hosts.c it is defined. The reason to move it was that most users, when having a smart/expensive controller want to have it used for booting and for the root file system. I think the real solution lies elsewhere; I am developing a configuration tool which will allow us to choose the order of the devices without editing hosts.c. It may take some time to surface and you may beat me to it, but that's OK. It doesn't really matter if a 152X gets detected before a high-power whiz-bang SCSI-matic 2010 PCI adapter, because you can still put root on any SCSI controller you like. You are right. My own machine had root on /dev/sde2 for the longest time. I moved it as many users, during first installation do not realize it. If it is very opjectionable, I could be convinced to move it back, but then i will have to ship an untested kernel. I hate to do that! If there is a _really_ good reason to change the probe order, we should discuss it on the kernel and scsi channels, and get it changed in the upstream source. You are right. I am collecting opinions on what the order should be and once my office move is over, will start the action as you suggest it. Adaptec provides free programming information on the 154X and 174X series, as well as the AIC-6X60 chips (152X), so be nice... I'm not thrilled with their policy on current products, but they're still excellent products. :) I think they have not made up their mind as to what they want to do when they grow up. An OEM chip vendor or a PC card vendor. They created so much noise and confision with so many incompatible cards and products. I have a 2940W in ``as new'' condition. Any offers? They are excellent cards :-) Happy new year P.S. Lets not turn it into a flaming war of my card is better than your card. Besides, thereis a company (in Colorado? Forgot their name) which makes a FCAL card. Does about 85 MB/Sec and can take up to 256 drives. Now try beat that! Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
libgr
pgpyjSIsQ7TTe.pgp Description: PGP message
Bug#2070: /etc/issue and /etc/issue.net
Package: (base) The default /etc/issue and /etc/issue.net files contain the copyright notice. The /etc/motd file contains another copyright notice. I know copyrights are very important, but I think only one (/etc/motd) should be enough for most users :-). It would be more useful to put the OS/hostname/tty in /etc/issue* and put the copyright notices only in /etc/motd. This is what other Unices seem to do, as set up by default. Below is an example of how /etc/issue.net might look like (/etc/issue is similar but uses different escape characters). Note that the name Debian GNU/Linux (or Linux-based GNU system) isn't fair - a lot of code is from MIT (X11) and BSD (most networking programs) and they deserve some credit, too (or simply call it Debian Linux, everyone will know it is really GNU/MIT/BSD/Linux anyway). == Debian GNU/MIT/BSD/Linux 2.0R9 (%h) (%t) == Sorry for being picky about such details, after all everyone can put whatever they like in their /etc/issue* and /etc/motd... One real problem that would be nice to fix while we are at it: change the getty /etc/issue escape characters to match those used in /etc/issue.net, and change telnetd to display /etc/issue if /etc/issue.net is not present. Currently /etc/issue.net is a link to /etc/issue, but they are not really compatible because of different escape characters. Happy New Year to everyone! Marek
Re: Bug#2063: scsi driver sequence unreasonable
In article [EMAIL PROTECTED] you wrote: : It doesn't really matter if a 152X gets detected before a high-power : whiz-bang SCSI-matic 2010 PCI adapter, because you can still put root : on any SCSI controller you like. You are correct, of course, Jeff, but the problem with having a card like a 15[12]X recognized first is that if you have machines like mine, which all have one fast controller that's always there and has the root on it, and you then stick 1510's in from time to time when you need to temporarily hang an external disk chassis on, or put a tape drive on, or something else that is transitory, you have to go through contortions to boot because what normally would be the 0th SCSI controller isn't any more, though it may be again shortly. This seems unfortunate. The other OS's I've had experience with (and there are many on the list) always made it possible to either nail down hard where the root disk was going to be, physically, or they sequenced driver discovery correctly to handle this case. None have been perfect for all cases, but all treated my needs better than Linux currently does. I'm not going to get upset no matter what Simon decides to do, because I suspect I'll be building custom kernels for most of my machines no matter what, but I wanted to make sure that the silliness of the current approach in my eyes got registered someewhere and fed back upstream. Bdale
Bug#2033: efax installation problems
Hi, this comes belated as I was away for Xmas... Carl Streeter writes: Carl No! It is a conffile because /usr/bin/fax, a bash script, was the only place to set your local fax settings as serial port, modem capabilities, INIT strings, phone number, prinyer what have you. Carl If this is still the case, then /usr/bin/fax should be a symlink Carl into /etc, and the script should reside there. /usr should be Carl considered read-only... It is no longer the case. I proposed to the upstream author the sourcing of /etc/efax.rc which he gladly accepted. It will be part of the next upstream release. The Debian releases since revsion 2 already contain it. Being a lousy script programmer, I introduced (and then fixed) some bugs during the conversion from the original to the current state. For your perusal, here's my Debian.ChangeLog: Sun Dec 17 16:34:41 1995 Dirk Eddelbuettel [EMAIL PROTECTED] * efax-07a-4 release * debian.rules: include missing debian.preinst (bug#2041) and really create the directories in /var/spool/fax * debian.postinst: quoted strings (bug#2041) Sat Dec 16 14:26:19 1995 Dirk Eddelbuettel [EMAIL PROTECTED] * efax-07a-3 release * efax.rc: (no real change) FAXINDIR, FAXOUTDIR, FAXLOGDIR use /var/spool/* and not /usr/spool/* as this looks better (bug#2033) * debian.rules: creates directories recvq, sendq and log in /var/spool/fax with mode 2775 and group dialout (bug#2033) * debian.postinst, debian.control: suggests /etc/efax.rc for local changes instead of /usr/bin/fax (bug#2033) * debian.postinst, debian.preinst: save existing fax script and deal with it; /usr/bin/fax is no longer a conffile (bug#2033) Mon Dec 11 20:27:42 1995 Dirk Eddelbuettel [EMAIL PROTECTED] * efax-07a-2 release * efax.c: version string reflects Debian upon author's request * efax.c and fax patched with qfax patches from ftp.renaissoft.com This version of efax can now be used with the qfax program suite that adds an e-mail-to-fax gateway to efax, a phonebook database system, automated cover page generation, and fax spooling for delayed transmission of faxes. * fax: now sources /etc/efax.rc and/or ~/.efaxrc, manpage updated * debian.postinst: warn if no user in group dialout * debian.control: ELF release, depends on libc5 Tue Sep 26 13:50:50 1995 Dirk Eddelbuettel [EMAIL PROTECTED] * efax-07a-1 release * debian.control: Changes Depends: gs to Suggests: gs and reworded the description to explain that only ascii text can be faxed without ghostscript Thu Sep 7 23:05:53 1995 Dirk Eddelbuettel [EMAIL PROTECTED] * efax-07a-0: Initial Debian release, added package maintenance files, edited Makefile and /usr/bin/fax slightly to Debian standards -- Dirk Eddelb|ttelhttp://qed.econ.queensu.ca/~edd
Re: bind-4.9.3BETA26-3 uploaded
On Sat, 23 Dec 1995, Robert Leslie wrote: I haven't yet made any changes to let BIND do cacheing nameservice by default. I'd also like to think about making libresolv into a shared library, and possibly splitting up the package into several smaller packages: bind (nameservice daemon, sample zone files, /etc/named.boot, /etc/init.d/bind, misc docs), resolv (runtime resolver shared library, /etc/resolv.conf), resolv-dev (resolver include files and .so link, docs), dns-utils (nslookup, dig, etc.) I'm going to put my foot dangerously close to my mouth here, as I'm away from my debian system, but... I think that nslookup will work on a system with only /etc/hostname lookup, right? If so, I think that the DNS utils should probably get folded in with the runtime package that has the resolver library and /etc/resolv.conf. Otherwise, it's a great idea, and the implementation details are of secondary concern ;) Carl Streeter | I'll forgive even GNU emacs as long [EMAIL PROTECTED] | as gcc is available --Linus Torvalds Just another Perl hacker | You've got a body in the garage, minus Ask me about Debian/GNU Linux.| a head. Take me to it. --The Wolf
Re: bind-4.9.3BETA26-3 uploaded
On Thu, 28 Dec 1995, Carl Streeter wrote: On Sat, 23 Dec 1995, Robert Leslie wrote: Just another side note beta 32 is out. And in a few days a 4.9.3-REL will be available for public consumption. just another FYI -- Matthew S. Bailey 107 Emmons Hall Central Michigan University Mt. Pleasant, MI 48858 [EMAIL PROTECTED] ... Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.)
Re: Unanswered problem reports by maintainer
On Tue, 26 Dec 1995, Raul Miller wrote: The US debian-bugs mirror seems to be fairing worse than normal... Aw, c'mon... ;) URL: http://www.cps.cmich.edu/~streeter/debian-bugs/ http://www.debian.org/Bugs. Ian.. Could you update this? Carl Streeter | I'll forgive even GNU emacs as long [EMAIL PROTECTED] | as gcc is available --Linus Torvalds Just another Perl hacker | You've got a body in the garage, minus Ask me about Debian/GNU Linux.| a head. Take me to it. --The Wolf
Bug#2071: ftp.debian.org/debian/debian-0.93/Contents changes daily
The Contents (and Contents.gz) files at ftp.debian.org/debian/debian-0.93 change daily. On comparing the files from two days, the only difference was the line: (Last updated on Wed Dec 27 23:23:54 EST 1995) Is this intentional? It must be causing extra mirroring traffic every day. -- ...RickM...
Re: Default organization: is there a site config file?
Hi, Sorry for digging up an old topic, but I've been away on vacation. Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Manoj Srivastava writes (Default organization: is there a site Ian config file?): Manoj It seems to me that this information is not news specific (mailers Manoj could utilize it too), so should this file be installed instead in Manoj /etc, also, which package should take responsibility? Ian Mailers do (should) not usually add Organization headers. I Ian think it should stay in /etc/news. Should is a matter of opinion. (My mailer has been configured to add organization lines, so at least I prefer that my mailer do so: doubtless, there are others. Moreover, in my _opinion_, the distinction between news and mail is getting blurred. But this is neither here or there.) The issue is that we have at least two non-news related packages (viz. dist and mailagent) that interact with mail, and provide an organization header. In the future, there maybe other packages that do the same, and the question is how should we handle this? We could set up post install scripts to check for /etc/news/organization, and create it if that file does not exist, if the opinion is that /etc/news/organization should be the location for this information (currently I create an /etc/organization file, but I could change that). comments? manoj -- If builders built buildings the way programmers write programs, Jolt Cola would be a Fortune-500 company. If builders built buildings the way programmers write programs, you'd be able to buy a nice little colonial split-level at Babbages for $34.95. If programmers wrote programs the way builders build buildings, we'd still be using autocoder and running compile decks. Peter da Silva and Karl Lehenbauer, a different perspective Manoj Srivastava Systems Research Programmer, Project Pilgrim, Phone: (413) 545-3918A143B Lederle Graduate Research Center, Fax: (413) 545-1249 University of Massachusetts, Amherst, MA 01003 [EMAIL PROTECTED] URL:http://www.pilgrim.umass.edu/%7Esrivasta/
