[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Double trouble - NFS don't work, and then 2.2.19 -> 2.4.18 woes



I'm on a ruffian (the 21164 ?UX or is it BX?/4MB one) , 'testing'
i.e.
deb ftp://ftp.fi.debian.org/debian/ testing main contrib non-free
deb http://non-us.debian.org/debian-non-US testing/non-US main non-free
deb http://security.debian.org/ testing/updates main contrib non-free

I've been on 2.2.19 for ages, and on a reboot NFS just suddenty stopped
working, so I thought I'd try the 2.4.18 that's been offered, and see if
that fixed things.

On installation of the kernel package I got some message about initrd, 
and telling me I needed to fiddle with LILO if my boot loader wasn't 
configured to cope with a initial ramdisk.
This posed me a few questions:
a) This dear thing will never see a LILO, as it's AlphaBIOS->MILO instead,
so what's it really refering to?
b) How do I know if my boot loader is configured to cope with an initrd?
(and c) why doesn't it know?)

Anyway I felt reassured that I'd be able to get the thing back on the old
kernel if I goofed, so I told it that I wanted to continue. I'd got to this
stage in the past, but backed out.

Later in the installation, it came up with another comment that I was
installing from scratch, and should it drop some file to do with initrd
somewhere, and I OK'd that. I noticed that it had created some files in /boot/

<<<
megaspaz:/# ls -al /boot
total 8229
drwxr-xr-x    2 root     root         1024 Oct 18 16:36 .
drwxr-xr-x   20 root     root         1024 Oct 18 16:38 ..
-rw-r--r--    1 root     root       333729 Jan 25  2053 System.map-2.2.18pre21-generic
-rw-r--r--    1 root     root       337811 Aug 26  2001 System.map-2.2.19
-rw-r--r--    1 root     root       527091 Apr 10  2002 System.map-2.4.18-generic
-rw-r--r--    1 root     root        88576 Nov 12  2001 bootlx
-rw-r--r--    1 root     root         4696 Jan 25  2053 config-2.2.18pre21-generic
-rw-r--r--    1 root     root        13676 Aug 25  2001 config-2.2.19
-rw-r--r--    1 root     root        33277 Apr  6  2002 config-2.4.18-generic
-rw-r--r--    1 root     root      3645440 Oct 18 16:36 initrd.img-2.4.18-generic
-rw-r--r--    1 root     root        31744 Nov 12  2001 net_aboot.nh
-rw-r--r--    1 root     root          512 Nov 12  2001 net_pad
-rw-r--r--    1 root     root      1206326 Jan 25  2053 vmlinuz-2.2.18pre21-generic
-rw-r--r--    1 root     root      1219208 Aug 26  2001 vmlinuz-2.2.19
-rw-r--r--    1 root     root       931163 Apr 10  2002 vmlinuz-2.4.18-generic
>>>

I looked at the 'initrd' manpage, which told me very little (I really don't
understand the boot sequence well enough)

All the devices in question are there:
<<<
brw-rw----    1 root     disk       1, 250 Nov 25  2000 /dev/initrd
brw-rw----    1 root     disk       1,   0 Aug  2 11:22 /dev/ram0
drwxr-xr-x    2 root     root         1024 Nov 25  2000 /initrd/
lrwxrwxrwx    1 root     root           31 Oct 18 16:38 /initrd.img ->
/boot/initrd.img-2.4.18-generic
>>>
but the /linuxrc _isn't_ there, it says it's optional - what should /linuxrc contain?

Anyway, I noticed the initrd= option in the initrd manpage, and guessed that
I should add it to the environment variable in the initial alphabios screen,
so I now have tried all three of
  boot sda3:/boot/vmlinuz-2.4.18-generic initrd=/inirtd.img root=/dev/sda3
  boot sda3:/boot/vmlinuz-2.4.18-generic initrd=/boot/inirtd.img-2.4.18-generic root=/dev/sda3
  boot sda3:/boot/vmlinuz-2.4.18-generic initrd=sda3:/boot/inirtd.img-2.4.18-generic
root=/dev/sda3
and they all do the same thing, which is a bit quick to describe in any
detail, bu here goes.
I get a 'this is a gzipped kernel' message, and about 3 rows of '#'s, 
then some line with two 64-bit hex addresses in - ' bootstrap complete,
kernal at %llx, sp = %lls ' or something 
Then there's some comment about something to do with a virtual something,
and then it reboots, back into MILO. 
I can repeat the boot command from the MILO prompt, and the cycle repeats,
always instantly back to the MILO prompt after the virtual whatever line.

I've tried to include all the info I can. I really don't know what is
relevant, and what isn't.

Anyway, I can fortunately get back into 2.2.19 (and 2.2.18pre21) from the
MILO console, so I'm able to at least have the machine alive enough to muck
about with. However, that leaves me with my original NFS proble, so I'll
gladly take advice on that too. My home directory is on the NFS server, 
and I'm _utterly_ lost without access to it. My NFS server is a x86 'stable' 
<<<
megaspaz:/# ping kilospaz
PING kilospaz.fatphil.org (62.236.152.52): 56 data bytes
64 bytes from 62.236.152.52: icmp_seq=0 ttl=255 time=0.4 ms

megaspaz:/# ypwhich       
kilospaz.fatphil.org

megaspaz:/# grep kilospaz /etc/fstab
kilospaz:/      /mnt/net/kilospaz       nfs user,exec,dev,rw,auto,rsize=8192,wsize=8192,bg,soft   
0 0

megaspaz:/# mount kilospaz:/
  mount: RPC: Unable to receive; errno = Connection refused
  mount: backgrounding "kilospaz:/"
>>>

Any ideas?
It (NFS) was working until today, which was my first reboot in about 6 months.

I've had similar problems before, but they kind of just fixed themselves
mysteriously. However, all the single-user modes, and reboots don't seem to
be fixing  it this time (I tried each once).
To be honest I know very little about RPC and NFS and all that jazz too, so
all I can do is flail randomly currently, which isn't exactly working.

I'm in a complete tizz, and I don't know what to do. I'm helpless without my
alpha (it's where I do all my develpment, as I abhor 32-bit CPUs) and my 
alpha's helpless without my home directory.

I'll get on my knees and beg if I have to  :-(

Phil



=====
First rule of Factor Club - you do not talk about Factor Club.
Second rule of Factor Club - you DO NOT talk about Factor Club.
Third rule of Factor Club - when the cofactor is prime, or you've trial-
divided up to the square root of the number, the factoring is over.

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com



Reply to: