Re: [vox-tech] NFS mount "RPC: Timed out" error
On Mon, Jul 14, 2003 at 04:36:13PM -0700, Peter Jay Salzman wrote: > On Mon 14 Jul 03, 4:05 PM, Ted Deppner <[EMAIL PROTECTED]> said: > > portmap: 192.168.0.0/255.255.255.0 > > mountd: 192.168.0.0/255.255.255.0 > > [EMAIL PROTECTED] ldd /usr/sbin/rpc.nfsd > [no libwrap] > [EMAIL PROTECTED] ldd /sbin/portmap > libwrap.so.0 => /lib/libwrap.so.0 (0x4002a000) > > ted, it looks like portmap is linked against wrappers but nfsd isn't. > at least on my system. Yup, same here. Now, look at rpc.mountd, the thing responsible for doing the mounts, aka mountd. [EMAIL PROTECTED]:~$ ldd /usr/sbin/rpc.mountd libwrap.so.0 => /lib/libwrap.so.0 (0x40022000) > if it's not linked against libwrap, then it must be explicitly stated in > in inetd.conf type config file. > > at least, that's my understanding... Yes, that's true. For the archive, and those less well versed, "explicitly stated in inetd.conf" would mean a line that contains "/usr/sbin/tcpd" in the "server program" field of inetd.conf... in other words, it's either linked against tcpwrappers libwrap, or you've specified tcpd as part of the invocation command line. -- Ted Deppner http://www.deppner.us/ ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] emacs delete key-binding
Micah J. Cowan wrote: On Mon, Jul 14, 2003 at 12:34:46PM -0700, Jonathan Stickel wrote: The default setup of emacs for Red Hat causes the "backspace" key to delete backward 1 character, the "delete" key to delete forward 1 character, and "C-w" to kill a high-lighted region. I would like to have the "delete" key assigned to kill a highlighted region in addition to deleting 1 character forward. This is common behavior of most gui text editors and word processors. >> >>... >> >> Is there a correct way to do this? I am new to elisp (obviously). (global-set-key [delete] (lambda () (interactive) (if mark-active (kill-region (point) (mark)) (delete-char might work: but I don't think that the region is always hilited: this might call kill-region sometimes when you don't want it to. I frequently use emacs in console-mode, where I don't see any hiliting during a marked region, so I wouldn't prefer such a binding. HTH, Micah Thanks for your suggestion, although it didn't quite work. It killed the region fine, but I got this error with no region selected: wrong number of arguments: #, 0 After a little research I tried: (global-set-key [delete] (lambda () (interactive) (if mark-active (kill-region (point) (mark)) (delete-char (point-min) This seems to do exactly what I want.:-) BTW, I also have my .emacs: ;; Visual feedback on selections (setq-default transient-mark-mode t) I think this prevents the mark from being set unless there is a selection visually high-lighted. Jonathan ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] NFS mount "RPC: Timed out" error
On Mon 14 Jul 03, 4:34 PM, Bill Kendrick <[EMAIL PROTECTED]> said: > On Mon, Jul 14, 2003 at 03:06:46PM -0700, Ken Herron wrote: > > > > Err, isn't hosts.allow the TCP wrappers config file? NFS usually runs > > over udp in a lan environment; I don't see how TCP wrappers could be > > involved. > > I was just following the HOWTO :^) > > > > > It'd be helpful to to know exactly what rpc program/version the client is > > trying to invoke when it times out. Could you snoop the network during a > > mount attempt? If it's trying to talk to nfsd, then the question is why > > nfsd is ignoring the client. If the client is trying to talk to lockd, > > then the question is why lockd isn't running. > > I've never 'snooped' a network before. ;^) Any good HOWTO pointers? here's how to be snoopy: tcpdump -i eth0 tcpdump -i eth0 udp tcpdump -i eth0 tcp tcpdump -i eth0 tcp port 119 tcpdump -i eth0 udp port 119 you can get port numbers from /etc/services or google. i think i got all this right. when you look at man tcpdump, you realize that it's an incredibly complicated tool... pete -- GPG Instructions: http://www.dirac.org/linux/gpg GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] NFS mount "RPC: Timed out" error
On Mon 14 Jul 03, 4:05 PM, Ted Deppner <[EMAIL PROTECTED]> said: > On Mon, Jul 14, 2003 at 03:06:46PM -0700, Ken Herron wrote: > > Err, isn't hosts.allow the TCP wrappers config file? NFS usually runs > > over udp in a lan environment; I don't see how TCP wrappers could be > > involved. > > True, but many programs compile against the tcpwrappers library and honor > it, as linux nfs does. Note that portmap and mountd are usually > separated, each requiring it's own allow. > > eg: > > portmap: 192.168.0.0/255.255.255.0 > mountd: 192.168.0.0/255.255.255.0 [EMAIL PROTECTED] locate nfsd | grep bin /usr/sbin/rpc.nfsd [EMAIL PROTECTED] ldd /usr/sbin/rpc.nfsd /usr/lib/libtrash/libtrash.so => /usr/lib/libtrash/libtrash.so (0x40012000) libc.so.6 => /lib/libc.so.6 (0x4002a000) libdl.so.2 => /lib/libdl.so.2 (0x4013a000) libm.so.6 => /lib/libm.so.6 (0x4013d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) [EMAIL PROTECTED] locate portmap | grep bin /sbin/portmap [EMAIL PROTECTED] ldd /sbin/portmap /usr/lib/libtrash/libtrash.so => /usr/lib/libtrash/libtrash.so (0x40012000) libwrap.so.0 => /lib/libwrap.so.0 (0x4002a000) libnsl.so.1 => /lib/libnsl.so.1 (0x40032000) libc.so.6 => /lib/libc.so.6 (0x40045000) libdl.so.2 => /lib/libdl.so.2 (0x40155000) libm.so.6 => /lib/libm.so.6 (0x40158000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) ted, it looks like portmap is linked against wrappers but nfsd isn't. at least on my system. if it's not linked against libwrap, then it must be explicitly stated in in inetd.conf type config file. at least, that's my understanding... pete -- GPG Instructions: http://www.dirac.org/linux/gpg GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] NFS mount "RPC: Timed out" error
On Mon, Jul 14, 2003 at 03:06:46PM -0700, Ken Herron wrote: > > Err, isn't hosts.allow the TCP wrappers config file? NFS usually runs > over udp in a lan environment; I don't see how TCP wrappers could be > involved. I was just following the HOWTO :^) > It'd be helpful to to know exactly what rpc program/version the client is > trying to invoke when it times out. Could you snoop the network during a > mount attempt? If it's trying to talk to nfsd, then the question is why > nfsd is ignoring the client. If the client is trying to talk to lockd, > then the question is why lockd isn't running. I've never 'snooped' a network before. ;^) Any good HOWTO pointers? Thx! -bill! -- [EMAIL PROTECTED] Got kids? Get Tux Paint! http://newbreedsoftware.com/bill/ http://newbreedsoftware.com/tuxpaint/ ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] NFS mount "RPC: Timed out" error
On Mon, Jul 14, 2003 at 03:06:46PM -0700, Ken Herron wrote: > Err, isn't hosts.allow the TCP wrappers config file? NFS usually runs > over udp in a lan environment; I don't see how TCP wrappers could be > involved. True, but many programs compile against the tcpwrappers library and honor it, as linux nfs does. Note that portmap and mountd are usually separated, each requiring it's own allow. eg: portmap: 192.168.0.0/255.255.255.0 mountd: 192.168.0.0/255.255.255.0 -- Ted Deppner http://www.deppner.us/ ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] NFS mount "RPC: Timed out" error
On Mon 14 Jul 03, 3:06 PM, Ken Herron <[EMAIL PROTECTED]> said: > --On Monday, July 14, 2003 13:35:20 -0700 Bill Kendrick <[EMAIL PROTECTED]> > wrote: > > >>Shouldn't nfsd be in there? > > > >*shrug* Sure?! Why not? ;) Like I said, it worked previously, and I > >know I didn't mess with hosts.allow between the time it /was/ working > >and now, but I'll try it anyway... > > Err, isn't hosts.allow the TCP wrappers config file? NFS usually runs > over udp in a lan environment; I don't see how TCP wrappers could be > involved. yep. but portmapper should listen to both tcp and udp ports though... > >For the host in question, I get back: > > > > program vers proto port > >102 tcp111 portmapper > >102 udp111 portmapper > >132 udp 2049 nfs > >132 tcp 2049 nfs > >151 udp630 mountd > >152 udp630 mountd > >151 tcp633 mountd > >152 tcp633 mountd > > Hmm, you should have entries for lockd and statd (I think) in there. The > timeout could be from the client trying to contact lockd on the server, > but I don't know if that happens at mount time. > > It'd be helpful to to know exactly what rpc program/version the client is > trying to invoke when it times out. Could you snoop the network during a > mount attempt? If it's trying to talk to nfsd, then the question is why > nfsd is ignoring the client. If the client is trying to talk to lockd, > then the question is why lockd isn't running. i was going to suggest that myself. bill, do this: # tcpdump -i eth0 udp port 2048 and try to mount. you should see a communication attempt. this should narrow down the culprit a bit. > >Before I go much further... is there any chance at all that this could > >be a kernel issue on mountING system? (The one trying to make the NFS > >connection to the mountED server) > > Shrug, anything's possible. It'd be nice to know exactly what is failing > before leaping for the kernel, though. if you didn't update the kernel, there's no reason to expect the kernel is the culprit. when was the last time you apt-got anything? have you checked daemon.log? messages? can you run nfsd and portmap with some kind of debug switches? pete -- GPG Instructions: http://www.dirac.org/linux/gpg GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] NFS mount "RPC: Timed out" error
--On Monday, July 14, 2003 13:35:20 -0700 Bill Kendrick <[EMAIL PROTECTED]> wrote: Shouldn't nfsd be in there? *shrug* Sure?! Why not? ;) Like I said, it worked previously, and I know I didn't mess with hosts.allow between the time it /was/ working and now, but I'll try it anyway... Err, isn't hosts.allow the TCP wrappers config file? NFS usually runs over udp in a lan environment; I don't see how TCP wrappers could be involved. For the host in question, I get back: program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 132 udp 2049 nfs 132 tcp 2049 nfs 151 udp630 mountd 152 udp630 mountd 151 tcp633 mountd 152 tcp633 mountd Hmm, you should have entries for lockd and statd (I think) in there. The timeout could be from the client trying to contact lockd on the server, but I don't know if that happens at mount time. It'd be helpful to to know exactly what rpc program/version the client is trying to invoke when it times out. Could you snoop the network during a mount attempt? If it's trying to talk to nfsd, then the question is why nfsd is ignoring the client. If the client is trying to talk to lockd, then the question is why lockd isn't running. Before I go much further... is there any chance at all that this could be a kernel issue on mountING system? (The one trying to make the NFS connection to the mountED server) Shrug, anything's possible. It'd be nice to know exactly what is failing before leaping for the kernel, though. -- Kenneth Herron [EMAIL PROTECTED] 916-366-7338 ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] emacs delete key-binding
On Mon, Jul 14, 2003 at 12:34:46PM -0700, Jonathan Stickel wrote: > The default setup of emacs for Red Hat causes the "backspace" key to > delete backward 1 character, the "delete" key to delete forward 1 > character, and "C-w" to kill a high-lighted region. > > I would like to have the "delete" key assigned to kill a highlighted > region in addition to deleting 1 character forward. This is common > behavior of most gui text editors and word processors. I tried the > following in my .emacs file: > > (global-set-key [delete] 'kill-region) > > This does assign "delete" to kill-region, but no longer works to delete > forward 1 character. If I the add the following to .emacs: > > (global-set-key [delete] 'delete-char) > > whichever assignment comes last (delete-char or kill-region) takes > precedence. If I have the following: > > (global-set-key [delete] 'kill-region 'delete-char) > > I get errors on emacs startup (see below), but both delete-char and > kill-region are in fact assigned to "delete"! Is there a correct way to > do this? I am new to elisp (obviously). (global-set-key [delete] (lambda () (interactive) (if mark-active (kill-region (point) (mark)) (delete-char might work: but I don't think that the region is always hilited: this might call kill-region sometimes when you don't want it to. I frequently use emacs in console-mode, where I don't see any hiliting during a marked region, so I wouldn't prefer such a binding. HTH, Micah ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] NFS mount "RPC: Timed out" error
On Mon, Jul 14, 2003 at 06:25:39AM -0700, Ken Herron wrote:
> --On Monday, July 14, 2003 03:53:20 AM -0700 Bill Kendrick
> <[EMAIL PROTECTED]> wrote:
>
> >The LAN IP of the mountING system is listed in the mountED system's
> >/etc/hosts.allow, with access to:
> >
> > portmap
> > lockd
> > rquotad
> > mountd
> > statd
>
> Shouldn't nfsd be in there?
*shrug* Sure?! Why not? ;) Like I said, it worked previously, and I know I didn't
mess with hosts.allow between the time it /was/ working and now, but I'll try it
anyway...
[ tries it ]
Hrm... I added it, and then restarted both "nfs-user-server" and "inetd"
(in /etc/init.d/ under Debian). Still getting the timeout...
> If necessary, use rpcinfo to make sure the server bits are actually
> functioning properly. "rpcinfo -p host" will query the portmapper for the
> registered services;
For the host in question, I get back:
program vers proto port
102 tcp111 portmapper
102 udp111 portmapper
132 udp 2049 nfs
132 tcp 2049 nfs
151 udp630 mountd
152 udp630 mountd
151 tcp633 mountd
152 tcp633 mountd
> "rpcinfo -u host progname" will send a null query to
> a particular service.
$ rpcinfo -u the_host nfs
program 13 version 2 ready and waiting
("nfsd" was reported as an "unknown service"; looking at that, I tried guessing that
maybe
hosts.allow should have "nfs", not "nfsd". So, I tried it; still no luck.)
Before I go much further... is there any chance at all that this could be a kernel
issue on mountING system? (The one trying to make the NFS connection to the mountED
server)
Thx for your help!
-bill!
--
[EMAIL PROTECTED] Got kids? Get Tux Paint!
http://newbreedsoftware.com/bill/ http://newbreedsoftware.com/tuxpaint/
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] emacs delete key-binding
The default setup of emacs for Red Hat causes the "backspace" key to delete backward 1 character, the "delete" key to delete forward 1 character, and "C-w" to kill a high-lighted region. I would like to have the "delete" key assigned to kill a highlighted region in addition to deleting 1 character forward. This is common behavior of most gui text editors and word processors. I tried the following in my .emacs file: (global-set-key [delete] 'kill-region) This does assign "delete" to kill-region, but no longer works to delete forward 1 character. If I the add the following to .emacs: (global-set-key [delete] 'delete-char) whichever assignment comes last (delete-char or kill-region) takes precedence. If I have the following: (global-set-key [delete] 'kill-region 'delete-char) I get errors on emacs startup (see below), but both delete-char and kill-region are in fact assigned to "delete"! Is there a correct way to do this? I am new to elisp (obviously). Thanks, Jonathan An error has occurred while loading `/home/jjstickel/.emacs': Wrong number of arguments: #[(key command) "\302!\204 ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] RE: ATA/100 Controllers on Linux?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 14 July 2003 10:45 am, Michael Dunham wrote: > Ryan said- > Mike, try installing with a small (20 oe 30 megs or so is what I use) > partition at the begining of the drive, and place /boot there. Your kernel > may be able to address the whole drive without any problems. A quick way to > tell if this will work is to try a boot disk (CD or floppy) and see if it > can > access the whole drive. > --- > > Actually, because the BIOS will not recognize the cylinder configuration, > it will not boot from that drive. The bios brings the machine to a full > stop when it tries to load the disk - no disk error, just a hard freeze. > That is why I am interested in these boards because they can be used as an > alternate boot. The only thing I don't know is if they will be properly > read after the boot without a Linux specific driver. Perhapse you could define your hard drive geometry, instead of letting it try to auto-detect? Your 13GB drive probably has an 8GB cap jumper on it that you could try using. - -- PGP/GPG Fingerprint: 3B30 C6BE B1C6 9526 7A90 34E7 11DF 44F3 7217 7BC7 On pgp.mit.edu, import with `gpg --keyserver pgp.mit.edu --recv-key 72177BC7` Also available at http://www.cal.net/~ryan/ryan_at_mother_dot_com.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Eu8MEd9E83IXe8cRAquhAKCLG44GLktivmz6CiFETrk7TTJWvACfR56P w09PBPFLnAFH+CM4Q7dS3Dw= =9Wbv -END PGP SIGNATURE- ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] RE: ATA/100 Controllers on Linux?
Ryan said- Mike, try installing with a small (20 oe 30 megs or so is what I use) partition at the begining of the drive, and place /boot there. Your kernel may be able to address the whole drive without any problems. A quick way to tell if this will work is to try a boot disk (CD or floppy) and see if it can access the whole drive. --- Actually, because the BIOS will not recognize the cylinder configuration, it will not boot from that drive. The bios brings the machine to a full stop when it tries to load the disk - no disk error, just a hard freeze. That is why I am interested in these boards because they can be used as an alternate boot. The only thing I don't know is if they will be properly read after the boot without a Linux specific driver. Mike > -Original Message- > From: Michael Dunham [mailto:[EMAIL PROTECTED] > Sent: Monday, July 14, 2003 7:42 AM > To: [EMAIL PROTECTED] > Subject: ATA/100 Controllers on Linux? > > > I am reviving an old Pentium II machine to use as my desktop at > home. I got an old copy of Mandrake up on it and I am making > good headway getting the hardware organized into something that I > can then upgrade to either a more current version of Linux or > FreeBSD. My current problem is the BIOS doesn't read larger hard > drives. I have a 13gb that would work fine as the root disk but > for now I am restricted to the original disk at 1.9gb which is > just plain too small. And so on... ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] ATA/100 Controllers on Linux?
On Mon 14 Jul 03, 9:09 AM, Ryan Castellucci <[EMAIL PROTECTED]> said: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Monday 14 July 2003 07:42 am, Michael Dunham wrote: > > I am reviving an old Pentium II machine to use as my desktop at home. I > > got an old copy of Mandrake up on it and I am making good headway getting > > the hardware organized into something that I can then upgrade to either a > > more current version of Linux or FreeBSD. My current problem is the BIOS > > doesn't read larger hard drives. I have a 13gb that would work fine as the > > root disk but for now I am restricted to the original disk at 1.9gb which > > is just plain too small. > > > > I tried upgrading the BIOS but it is an ASUS and they haven't issued any > > upgrades for this board since 1998. The upgrade they have didn't address > > drive sizes. Ugh. There is a 2 channel ATA/100 board from Startech > > (http://www.startech.com/ststore/itemdetail.cfm?ProductID=PCI2IDE100&topbar > >= topbario.htm) that some of the online outlets list as a "Linux compatible" > > (Startech doesn't mention it) but I haven't been able to find any evidence > > that anyone has actually used one for a Linux installation. My concern is > > that some boards require drivers and they are only available for Windoze > > generally ;-( > > > > Does anyone have any experience with this or other add-on controller boards > > on a Linux installation as a workaround for larger disks? It seems like it > > should be a normal thing to do... > > Mike, try installing with a small (20 oe 30 megs or so is what I use) > partition at the begining of the drive, and place /boot there. Your kernel > may be able to address the whole drive without any problems. A quick way to > tell if this will work is to try a boot disk (CD or floppy) and see if it can > access the whole drive. another good resource is the "large disk HOWTO" which should be with all the other HOWTO's. you may be able to solve this without splitting off a boot partition. it's been (at this point) many *years* since i've needed to read it, but i recall that if your BIOS is incapable of accessing the part of your drive that holds the kernel, you might want to put either "lba32" or "linear" in /etc/lilo.conf. IIRC, the problem is that the size of the data type that holds the number of X on your disk (where X is something like cylinders or sectors) is too small. these two directives instruct the boot loader to make assumptions about the geometry of your disks, regardless of what size BIOS thinks they are. like i said, it's been many years since i've needed to do this, but this is what i seem to recall. of course, to do this, you'll need to boot a rescue disk (debian install disks are good for this sort of thing), mount the root partition, make the change to /etc/lilo.conf and run lilo. note that if you run lilo with root mounted under, say, /mnt, you'll need to tell lilo where the actual root partition is (because it's really under, say, /mnt). i think it's -r, but i need to use the man page everytime i do this... this is all hazy for me. corrections welcomed... hth, pete -- GPG Instructions: http://www.dirac.org/linux/gpg GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] Mandatory Access Controls
Hello, I have a very basic question regarding mandatory access controls(MACs). Using the following diagram: - - |Subject || Object | - - |Clearance ||Classification | | Ex - Top Secret || Ex - Top Secret | |||| - - In the MAC model the "need-to-know" flag, restricts the subject to access the object. Is this flag, part of the subject's attributes or the object's attributes? OR is "need-to-know" a seperate element, like subject and object, in the MAC model? Thank you in advance. -- Subba Rao -- Old American Wild West saying: God created men but Colt made them equal. Today: Linus created Linux and Linux made IT companies equal. ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] ATA/100 Controllers on Linux?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 14 July 2003 07:42 am, Michael Dunham wrote: > I am reviving an old Pentium II machine to use as my desktop at home. I > got an old copy of Mandrake up on it and I am making good headway getting > the hardware organized into something that I can then upgrade to either a > more current version of Linux or FreeBSD. My current problem is the BIOS > doesn't read larger hard drives. I have a 13gb that would work fine as the > root disk but for now I am restricted to the original disk at 1.9gb which > is just plain too small. > > I tried upgrading the BIOS but it is an ASUS and they haven't issued any > upgrades for this board since 1998. The upgrade they have didn't address > drive sizes. Ugh. There is a 2 channel ATA/100 board from Startech > (http://www.startech.com/ststore/itemdetail.cfm?ProductID=PCI2IDE100&topbar >= topbario.htm) that some of the online outlets list as a "Linux compatible" > (Startech doesn't mention it) but I haven't been able to find any evidence > that anyone has actually used one for a Linux installation. My concern is > that some boards require drivers and they are only available for Windoze > generally ;-( > > Does anyone have any experience with this or other add-on controller boards > on a Linux installation as a workaround for larger disks? It seems like it > should be a normal thing to do... Mike, try installing with a small (20 oe 30 megs or so is what I use) partition at the begining of the drive, and place /boot there. Your kernel may be able to address the whole drive without any problems. A quick way to tell if this will work is to try a boot disk (CD or floppy) and see if it can access the whole drive. - -- PGP/GPG Fingerprint: 3B30 C6BE B1C6 9526 7A90 34E7 11DF 44F3 7217 7BC7 On pgp.mit.edu, import with `gpg --keyserver pgp.mit.edu --recv-key 72177BC7` Also available at http://www.cal.net/~ryan/ryan_at_mother_dot_com.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/EtXhEd9E83IXe8cRAh4eAJwJSH2RJ59YICKEKz8M+YGppejjbgCfSRw8 SJVCy1YCRRX/3L9oNldGEu0= =ES93 -END PGP SIGNATURE- ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] ATA/100 Controllers on Linux?
I am reviving an old Pentium II machine to use as my desktop at home. I got an old copy of Mandrake up on it and I am making good headway getting the hardware organized into something that I can then upgrade to either a more current version of Linux or FreeBSD. My current problem is the BIOS doesn't read larger hard drives. I have a 13gb that would work fine as the root disk but for now I am restricted to the original disk at 1.9gb which is just plain too small. I tried upgrading the BIOS but it is an ASUS and they haven't issued any upgrades for this board since 1998. The upgrade they have didn't address drive sizes. Ugh. There is a 2 channel ATA/100 board from Startech (http://www.startech.com/ststore/itemdetail.cfm?ProductID=PCI2IDE100&topbar= topbario.htm) that some of the online outlets list as a "Linux compatible" (Startech doesn't mention it) but I haven't been able to find any evidence that anyone has actually used one for a Linux installation. My concern is that some boards require drivers and they are only available for Windoze generally ;-( Does anyone have any experience with this or other add-on controller boards on a Linux installation as a workaround for larger disks? It seems like it should be a normal thing to do... Regards in advance Mike ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] NFS mount "RPC: Timed out" error
--On Monday, July 14, 2003 03:53:20 AM -0700 Bill Kendrick <[EMAIL PROTECTED]> wrote: The LAN IP of the mountING system is listed in the mountED system's /etc/hosts.allow, with access to: portmap lockd rquotad mountd statd Shouldn't nfsd be in there? If necessary, use rpcinfo to make sure the server bits are actually functioning properly. "rpcinfo -p host" will query the portmapper for the registered services; "rpcinfo -u host progname" will send a null query to a particular service. -- Ken Herron ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] NFS mount "RPC: Timed out" error
I'm not sure if I broke something, but suddenly the NFS mount I set up recently stopped working. Here's a paraphrase of what the mount line looks like in the mountING system's /etc/fstab: remote_host:/path/to/dir /home/username/mountpoint nfs rsize=8192,wsize=8192,timeo=14,intr,user,noauto On the mountED system, I have an entry like this in /etc/exports: /home/username other_host(rw,map_static=/etc/nfs/my.map) and this line in the /etc/nfs/my.map static map file: uid 1002 1000# username(1002)@otherhost = otheruser(1000)@remote_host The LAN IP of the mountING system is listed in the mountED system's /etc/hosts.allow, with access to: portmap lockd rquotad mountd statd It did work once upon a time. Then I futzed with the mountING system (kernel changes, which I backed out of and settled back on Debian's 2.4.18 kernel image package), and I think it's since then that it stopped working. Did I miss something? Thx! -bill! (NFS newbie) -- [EMAIL PROTECTED] Got kids? Get Tux Paint! http://newbreedsoftware.com/bill/ http://newbreedsoftware.com/tuxpaint/ ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
