Re: Bug#2063: scsi driver sequence unreasonable
> The file drivers/scsi/hosts.c defines the sequence in which different SCSI > controller cards are identified. The AHA152X driver appears early in the list, > which is unreasonable if there is another, smarter, SCSI controller in the > system... since it will result in the 1510/1522/1522/etc card assuming the role > of the 0th SCSI channel. You are right, of course. I changed it in 1.3.47 and the DPT (has NOTHING to do with the AHA drivers) and the Buslogic are at the top. What other AHA-compatible do we have that should move? I a mopen for suggestions. Besides, with the nice support that Adaptec gives Linux users we should really re-locate the drivers to /dev/null anyway, but the Linux developer supporting these things IS a nice guy, so... Merry Christmas! 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
Bug#2065: single user isn't
Hi There, > This caused me considerable grief when one of the disks on my system was starting to fail, and I was desperately trying to extract a few critical files that had been updated since the last backup. The cycle was to boot, snag a few files before the disk warmed up and failed, then power down to let things cool off, then repeat. The insistence of the system on doing fsck's at every boot made this a much less productive process per unit time than it could/should have been. Re-booting from a floppy could have saved you some grief. A can of compressed air or highly purified alcohol in a spray bottle (and proper ventilation!) could have cooled the drive enough to do things a little quicker. An ice pack is something I used to use (Wrapped in some paper towels to absorm moisture). On your point, oc cource you are right! Single user mode should be as DO$ as we can get it. 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
tar-1.11.8-3
This release fixes the problem with specifying a null username when a remote tape is specified to the 'f' argument. Previously, unless the fully qualified form of [EMAIL PROTECTED]:/dev/tapename was used, a segmentation violation and core dump would result before anything else happened. It turns out that a null pointer was being dereferenced when the username was not specified. With this release, the user defaults to the current user, so the form host:/dev/tapename works fine. There were several essentially duplicate bug reports that this release allows me to close. I've made contact with the upstream maintainer, and his changelogs indicate that I may be able to close some other open Debian tar bugs once I get a fresh code snapshot to work from. We'll see. Bdale Date: 27 Dec 95 07:46 UT Source: tar Binary: tar Version: 1.11.8-3 Description: tar: GNU tar. Priority: Low Changes: fix problem with null username in remote tape path specification Files: -rw-r--r-- 1 root bdale 688876 Dec 27 00:41 tar-1.11.8-3.tar.gz -rw-rw-r-- 1 bdalebdale2850 Dec 27 00:42 tar-1.11.8-3.diff.gz -rw-r--r-- 1 root bdale 144332 Dec 27 00:40 tar-1.11.8-3.deb cce6ed804da368246270903bce6174dd tar-1.11.8-3.tar.gz 0bac95ca8e4fc91be3b043825739f46e tar-1.11.8-3.diff.gz 12e9daa8f03172b6bc6af7686c98e8a1 tar-1.11.8-3.deb
newbie comments
I just recently had the chance to install, and help a few Linux newbie's install Debian. My comments pertain to 0.93R6 available on FTP sites. Overall we liked it, better than Yggdrasil, and slightly better than Slackware (though I put that down to familiarity). The new users I help install Debian found the interface change between the main install script and the timezone and partition sections a bit disorienting. Perhaps they can be dressed up like Slackware? Also, we found the copy of curses, or ncurses, "ruined" dselect's screen, until we rebooted. Perhaps that can be automated. 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 --"
Re: binary-alpha and binary-sparc directories
Hello Ian, you might as well add binary-m68k since the first Debian/68k packages are starting to appear. These packages as well as the necessary source patches are currently stored at U-Mainz: ftp.uni-mainz.de:/pub/Linux/devel/debian/dontuse/m68k/ Curently the follwing packages are available for m68k: binutils-2.6.debgcc-aout-2.7.2.deb libgxx-2.7.1.deb gcc-2.7.2.deb gxx-2.7.2.deb ncurses-1.9.8a.deb And of course dpkg is available (only as nondebbin.tar.gz) There is already a debian-68k mailing-list in place at Pixar.com (as you might have noticed from the cc-line...) As for the Alpha stuff: i am still wrestling with the subtilities of bootstrapping Linux in an unsupported environment. Don't expect anything before mid-January ... Happy new year! Dominik BTW. Could somebody please put me on the debian-devel list? I would make it easier for me ...
Re: binary-alpha and binary-sparc directories
For those out there that are interested. I will make space available for these ports, and allow each group to maintain uploads for the subtree. Please contact me if you are in need of an account for this use. -- 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: Bug#2065: single user isn't
You (H.J. Lu) wrote: > Date: Tue, 26 Dec 1995 22:49:53 -0500 (EST) > From: "H.J. Lu" <[EMAIL PROTECTED]> > Subject: Re: Bug#2065: single user isn't > To: David Engel <[EMAIL PROTECTED]> > > > > Which brings up another question: in libc 5.2.18, struct utmp was changed. > > That may be my last emai for a while :-(. The change was made > in libc 5.2.10 and was documented in ChangeLog. Personally, > I think programs should use the interface provided in > to access struct utmp, just like stdio. I am using > rxvt and it works just fine. Okay, but init is a special case, that's why I asked. It does some more things with utmp, for example garbage cleanup. > The ut_id field in struct utmp was changed from 2 to 4 bytes. > Due to the padding, programs using the utmp interface do not > have any problems. I just checked, and sizeof(struct utmp) has indeed not changed. So there is no binary incompatibility. Sorry for the inconvinience, but I just thought I'd check first... init now supports 4 character ID fields, if compiled with libc5. There will be a release early next year... > H.J. -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
Re: Bug#2063: scsi driver sequence unreasonable
IMHO, the fewer changes between Debian's kernels and the upstream ones, the better... > You are right, of course. I changed it in 1.3.47 and the DPT (has > NOTHING to do with the AHA drivers) and the Buslogic are at the top. > What other AHA-compatible do we have that should move? I a mopen for > suggestions. 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. 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. 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. Remember: if you move probes around, earlier probes have a chance of putting hardware in an unusable state, preventing later probes from succeeding. > Besides, with the nice support that Adaptec gives Linux users we should > really re-locate the drivers to /dev/null anyway, but the Linux > developer supporting these things IS a nice guy, so... 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. :) Merry Christmas! Jeff
The new LILO not working?
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 |
Bug#2069: GNU last doesn't use ut_addr
Package: last Version: 5-12 The GNU version of last doesn't make use of the ut_addr utmp field which is supposed to contain the IP address for remote logins. The size of ut_host (16 chars) is too small and host names are often truncated. The IP address is the only reliable way to identify the remote host. The BSD-derived last from the current util-linux supports ut_addr. The remote address is stored in network byte order. It is currently not reliable either (login does a hostname lookup on the name passed after the -h flag) but I have a working patch for telnetd/rlogind to create an utmp entry for login (ut_addr filled in with the real remote IP address from getpeername, avoiding one hostname lookup). I will make this patch available soon, after some testing. BTW, it is probably too late to change "struct utmp" (more room for host namei, tty) - do we need the SVR4 utmpx thing? Marek
