[parisc-linux] nfsroot login problems on 720/50

[parisc-linux] nfsroot login problems on 720/50

[Albert Strasheim]

Good day,

This message was also sent to debian-hppa. I was wondering anyone on
this list had any ideas?

Regards,

Albert

----- Forwarded message from Albert Strasheim <fullung@ilink.nis.za> -----

From: Albert Strasheim <fullung@ilink.nis.za>
Subject: Re: Getting up and running (whoo!)
To: debian-hppa@lists.debian.org

Greetings,

It boots! Or something :-) After borrowing some terminators from my
friend, I have the following success to report:

I've managed to boot my 720/50 using Linux 2.4.9-pa20 (not -pa22 as I
stated in my original post)  over the LAN (with a make palo lifimage),
using a combination of rbootd (for the lifimage), bootpd (for the IP
address and such), and the userspace nfs daemon for the
baseplus-20010404.tar.gz NFS root.

The boot-up went as follows:

(c) Copyright.  Hewlett-Packard Company.  1991.
All rights reserved.

PDC ROM rev. 2.3
IODC ROM rev. 2.2
96 MB of memory configured and tested.


Selecting a system to boot.
To stop selection process, press and hold the ESCAPE key.

Selection process stopped.

Searching for Potential Boot Devices.
To terminate search, press and hold the ESCAPE key.

Search terminated.



b)    Boot from specified device
s)    Search for bootable devices
a)    Enter Boot Administration mode
x)    Exit and continue boot sequence
?)    Help

Select from menu: b lan

Trying lan.000000-000000.0.0
Boot path initialized.
Attempting to load IPL.


Hard booted.
palo ipl 0.94 fullung@dogbert Sun Sep 16 00:52:51 SAST 2001
0/vmlinux32 3149283 bytes @ 0x7800

Command line: 'HOME=/ TERM=linux root=/dev/nfs nfsroot=10.0.1.1 ip=bootp  console=ttyS0'

Kernel: partition 0 file /vmlinux
Warning: kernel name doesn't end with 32 or 64... Guessing 32
ELF32 executable
Entry 001000d0 first 00100000 n 5
Segment 0 load 00100000 size 1714304 mediaptr 0x1000
Segment 1 load 002a4000 size 281768 mediaptr 0x1a4000
Segment 2 load 002ec000 size 385024 mediaptr 0x1e9000
Segment 3 load 00350000 size 32768 mediaptr 0x247000
Segment 4 load 0038d684 size 88032 mediaptr 0x24f684
branching to kernel entry point 0x001000d0
Linux version 2.4.9-pa20 (fullung@dogbert) (gcc version 3.0.2 20010829 (prerelease)) #6 Sun Sep 16 13:45:08 SAST 2001
FP[0] enabled: Rev 3 Model 0
The 32-bit Kernel has started...
Determining PDC firmware type: Older Legacy Box
model	00002000 00000481 00000000 00000000 77544852 000011f4 00000004 0000000d 00000000
vers	00000003
CPUID	vers 0 rev 0
model	9000/720
Total Memory: 96 Mb
On node 0 totalpages: 24576
zone(0): 24576 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Searching for devices...
Found devices:
1. Coral SGC Graphics (10) at 0xf8000000, versions 0x4, 0x0, 0x77
2. Cobra Core BA (11) at 0xf082f000, versions 0x4, 0x0, 0x70
3. Cobra Core SCSI (10) at 0xf0825000, versions 0x4, 0x0, 0x71
4. Cobra Core LAN (802.3) (10) at 0xf0826000, versions 0x4, 0x0, 0x72
5. Cobra Core HIL (10) at 0xf0821000, versions 0x4, 0x0, 0x73
6. Cobra Core RS-232 (10) at 0xf0823000, versions 0x4, 0x0, 0x75
7. Cobra Core RS-232 (10) at 0xf0822000, versions 0x4, 0x0, 0x75
8. Cobra Core Centronics (10) at 0xf0824000, versions 0x4, 0x0, 0x74
9. Cobra (720) (0) at 0xfffbe000, versions 0x200, 0x0, 0x4
10. Cobra (1) at 0xfffbf000, versions 0x13, 0x0, 0x9
That's a total of 10 devices.
CPU(s): 1 x PA7000 (PCX-S) at 50.000000 MHz
Kernel command line: HOME=/ TERM=linux root=/dev/nfs nfsroot=10.0.1.1 ip=bootp  console=ttyS0
Console: colour dummy device 160x64
Calibrating delay loop... 49.76 BogoMIPS
Memory: 93884k available
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
POSIX conformance testing by UNIFIX
Asp version 1 at 0xf0800000 found.
LED (ASP-style) display at f0800020 registered
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
parport_init_chip: enhanced parport-modes not supported.
parport0: PC-style at 0xf0824800, irq 88 [PCSPP]
STI byte mode ROM at f8000000, hpa=f8000000
STI byte mode ROM, id 26d1488c-40a00499, conforms to spec rev. 8.02
STI device: HPA1924A
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at iomem 0xf0823800 (irq = 90) is a 16550A
ttyS01 at iomem 0xf0822800 (irq = 89) is a 16550A
Found HIL at 0xf0821000, IRQ 94
HIL: keyboard found at id 0
HIL: keymap loaded.
lp0: using parport0 (interrupt-driven).
Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)
block: 128 slots per queue, batch=16
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Found i82596 at 0xf0826000, IRQ 87
82596.c: MAC of HP700 LAN blindely read from the prom!
eth0: Couldn't get consistent shared memory
eth0: 82596 at 0xf0826000, 08 00 09 25 4B E1 IRQ 87.
82596.c $Revision: 1.22 $
SCSI subsystem driver Revision: 1.00
sim700: Configuring 53c700 (SCSI-ID 7) at f0825100, IRQ 86, options 1
scsi0: Revision 0x0
scsi0: test 1 completed ok.
scsi0 : LASI/Simple 53c7xx
sticonsole_init: searching for STI ROMs
Console: switching to colour STI console 160x64
md: linear personality registered
md: raid0 personality registered
md: raid1 personality registered
md: raid5 personality registered
raid5: measuring checksumming speed
   8regs     :    33.600 MB/sec
   8regs_prefetch:    40.800 MB/sec
   32regs    :    32.400 MB/sec
   32regs_prefetch:    41.600 MB/sec
raid5: using function: 32regs_prefetch (41.600 MB/sec)
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
eth0: link ok.
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 10.0.1.1, my address is 10.0.1.2
IP-Config: Complete:
      device=eth0, addr=10.0.1.2, mask=255.255.255.0, gw=255.255.255.255,
     host=bob, domain=, nis-domain=(none),
     bootserver=10.0.1.1, rootserver=10.0.1.1, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 10.0.1.1
Looking up port of RPC 100005/1 on 10.0.1.1
VFS: Mounted root (nfs filesystem) readonly.
INIT: version 2.78 booting
rcS(13): unaligned access to 0x0007dca3 at ip=0x0005d807
Not-handled unaligned insn 0x0cd31200
Unaligned handler failed, ret = -1 INIT: Entering runlevel: 2
<4>rc(16): unaligned access to 0x0007dca3 at ip=0x0005d807
Not-handled unaligned insn 0x0cd31200
Unaligned handler failed, ret = -1 <4>rc(17): unaligned access to 0x0007dca9 at ip=0x0005db23
Not-handled unaligned insn 0x0f131200
Unaligned handler failed, ret = -1 
Debian GNU/Linux testing/unstable
pehc base tarball 2001-04-04 see /home/demo/README for more info
bob login: 

Logging in as root or demo (I modified /etc/passwd to empty passwords)
just sits there, until you hit Ctrl-C 3 or 4 times, after which it
returns to the login prompt.

So this is where I'm stuck at the moment. The unaligned stuff also makes
me wonder... perhaps it is unable to execute bash?

What's next?

Regards,

Albert

P.S. There aren't currently any SCSI devices attached, but I doubt that
makes a difference...?

----- End forwarded message -----

Re: [parisc-linux] nfsroot login problems on 720/50

[Carlos O'Donell Jr.]

> Good day,
> 
> This message was also sent to debian-hppa. I was wondering anyone on
> this list had any ideas?
> 
> Regards,
> 
> Albert
> 
> 
> I've managed to boot my 720/50 using Linux 2.4.9-pa20 (not -pa22 as I
> stated in my original post)  over the LAN (with a make palo lifimage),
> using a combination of rbootd (for the lifimage), bootpd (for the IP
> address and such), and the userspace nfs daemon for the
> baseplus-20010404.tar.gz NFS root.
>

The rbootd is good.
The lifimage is good.
The bootp server is good.

The baseplus root tarball is bad.

Coming from a similar situation, I had to manually change the
permissions on the baseplus tarball to get it to work. 
Though I clearly can't remember what else I had to do... it was
quite some time ago. I'm now using apt-get and the latest ISO to
install machines.

Questions:

- Are you using devfs?
- Tried just letting the login prompt sit for a while after attempting
  to login? (Usually the error might come after a _long_ time).

On another note, you should try the cdrom installer, since it's
much better and people have put a lot of work into it.

Cheers,
Carlos. 

Re: [parisc-linux] nfsroot login problems on 720/50

[Albert Strasheim]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

Hello,

On Fri, 21 Sep 2001, Carlos O'Donell Jr. wrote:

> The rbootd is good.
> The lifimage is good.
> The bootp server is good.
> 
> The baseplus root tarball is bad.

Should I try the base tarball (same date... :-( ) or is that known to be
bad too?
 
> Coming from a similar situation, I had to manually change the
> permissions on the baseplus tarball to get it to work. 
> Though I clearly can't remember what else I had to do... it was
> quite some time ago. I'm now using apt-get and the latest ISO to
> install machines.
> 
> Questions:
> 
> - Are you using devfs?

I have not modified anything in the nfsroot to use devfs, and I don't
think it's in the make oldconfig kernel I'm using, so I'd guess not.

> - Tried just letting the login prompt sit for a while after attempting
>   to login? (Usually the error might come after a _long_ time).

Yes, it's been sitting for many hours without any luck.

> On another note, you should try the cdrom installer, since it's
> much better and people have put a lot of work into it.

I have tried the CD-ROM installer (0.9.2), but kernel on there wouldn't
let me get past where init starts (more of this unaligned trap
goodness, according to the debian-hppa folks); init was running in some
kind of loop or something.

Should I perhaps try to boot 2.4.9-pa22, and modify the PALO arguments
to boot from this CD-ROM?

Regards,

Albert

P.S. Are there any 720/50's out there that actually work? :-)

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [parisc-linux] nfsroot login problems on 720/50

[Albert Strasheim]

Hello,

On Sat, 22 Sep 2001, Carlos O'Donell Jr. wrote:

> > 
> > Should I try the base tarball (same date... :-( ) or is that known to be
> > bad too?
> >  
> 
> In reality all those tarballs are old, glibc is old... it's all old.
> Usually the problem lies in a bad telnetd that was on those tarballs.
> I think I remember xcompiling telnetd and sticking it into the nfsroot.
> Remember that mounting an nfs root will cause the root to be a readonly
> fs. This raises some large issues, but should still allow you to login.

What if it is a rw,no_root_squash export? Or does the Debian initscript
not support remounting the nfsroot rw? Or is it a limitation of the
Linux kernel?
 
> > I have not modified anything in the nfsroot to use devfs, and I don't
> > think it's in the make oldconfig kernel I'm using, so I'd guess not.
> The nfsroot doesn't care about devfs. Though the kernel does.
> Try make menuconfig and enable devfs. Compile a new kernel, stick it
> in your tftp directory and reboot.

Okay, will do. I've enabled CONFIG_DEVFS_FS and CONFIG_DEVFS_MOUNT.
 
> > I have tried the CD-ROM installer (0.9.2), but kernel on there wouldn't
> > let me get past where init starts (more of this unaligned trap
> > goodness, according to the debian-hppa folks); init was running in some
> > kind of loop or something.
> > 
> 
> Same here with 712/60, 715/50, and 715/33 (though I haven't tested
> it fully since I had a root tarball that was serving the purpose).
> If you can get the system to a semi-running state, you can use apt
> to dist-upgrade to the latest everything. Which is what I've done.
> 
> Though I'm looking at fai.
> 
> > P.S. Are there any 720/50's out there that actually work? :-)
> 
> Check the site. See the hardware list. Find some 720/50 owners and
> email them :)

When booting with the old baseplus, I got the following messages:

INIT: version 2.78 booting
rcS(13): unaligned access to 0x0007dca3 at ip=0x0005d807
Not-handled unaligned insn 0x0cd31200
Unaligned handler failed, ret = -1 INIT: Entering runlevel: 2
<4>rc(16): unaligned access to 0x0007dca3 at ip=0x0005d807
Not-handled unaligned insn 0x0cd31200
Unaligned handler failed, ret = -1 <4>rc(17): unaligned access to
0x0007dca9 at 
ip=0x0005db23
Not-handled unaligned insn 0x0f131200
Unaligned handler failed, ret = -1 
Debian GNU/Linux testing/unstable
pehc base tarball 2001-04-04 see /home/demo/README for more info
bob login: 

Should these concern me, or not?

I'm going to try building a new nfsroot tarball with the latest debs.
Hopefully that will do the trick.

Regards,

Albert

Re: [parisc-linux] nfsroot login problems on 720/50

[Carlos O'Donell Jr.]

> 
> What if it is a rw,no_root_squash export? Or does the Debian initscript
> not support remounting the nfsroot rw? Or is it a limitation of the
> Linux kernel?
>  

Think about it ... rw nfsroot... multiple machines booting from that nfsroot.
Guess what happens?

Normally, when setting up a diskless system, each node will have their
own special area to write logs and setup temporary files.

> rcS(13): unaligned access to 0x0007dca3 at ip=0x0005d807
> Unaligned handler failed, ret = -1 INIT: Entering runlevel: 2
> <4>rc(16): unaligned access to 0x0007dca3 at ip=0x0005d807
> Not-handled unaligned insn 0x0cd31200
> Unaligned handler failed, ret = -1 <4>rc(17): unaligned access to
> 0x0007dca9 at 
> ip=0x0005db23
> Not-handled unaligned insn 0x0f131200
> Unaligned handler failed, ret = -1

I'm not sure how you are going to go about updating that root tarball.
(Rebuild it by hand?)

Though, the unaligned problems seem to be a big cause of your problems.
The 712's and 715's don't spew unaligned errors. I'm not sure what
processor the 720 has, and what might be the special cases.

Someone else on the list might better answer this.
Actually... the website has an HCL.

"Currently, most of the unlettered 700-series workstations (eg 712/715/735)"

Doesn't list the 720. Wonder why?

c. 

Re: [parisc-linux] nfsroot login problems on 720/50

[Albert Strasheim]

[-- Attachment #1: Type: text/plain, Size: 2731 bytes --]

Hello,

I've tried compiling a kernel with devfs, but I'm not having any luck.
I'm using xc-latest from about a week ago, and make palo dies with the
following message:

fs/fs.o: In function `devfs_alloc_major':
fs/fs.o(.text.devfs_alloc_major+0x5c): undefined reference to `__set_bit'
hppa-linux-ld: fs/fs.o(.text.devfs_alloc_major+0x5c): cannot find stub entry 00000571___set_bit+0
hppa-linux-ld: fs/fs.o(.text.devfs_alloc_major+0x5c): cannot handle R_PARISC_PCREL17F for __set_bit
fs/fs.o: In function `devfs_dealloc_major':
fs/fs.o(.text.devfs_dealloc_major+0x20): undefined reference to `__test_and_clear_bit'
hppa-linux-ld: fs/fs.o(.text.devfs_dealloc_major+0x20): cannot find stub entry 00000571___test_and_clear_bit+0
hppa-linux-ld: fs/fs.o(.text.devfs_dealloc_major+0x20): cannot handle R_PARISC_PCREL17F for __test_and_clear_bit
fs/fs.o: In function `L854':
fs/fs.o(.text.devfs_alloc_devnum+0x114): undefined reference to `__set_bit'
hppa-linux-ld: fs/fs.o(.text.devfs_alloc_devnum+0x114): cannot find stub entry 00000571___set_bit+0
hppa-linux-ld: fs/fs.o(.text.devfs_alloc_devnum+0x114): cannot handle R_PARISC_PCREL17F for __set_bit
fs/fs.o: In function `L913':
fs/fs.o(.text.devfs_alloc_devnum+0x1d8): undefined reference to `__set_bit'
hppa-linux-ld: fs/fs.o(.text.devfs_alloc_devnum+0x1d8): cannot find stub entry 00000571___set_bit+0
hppa-linux-ld: fs/fs.o(.text.devfs_alloc_devnum+0x1d8): cannot handle R_PARISC_PCREL17F for __set_bit
fs/fs.o: In function `L941':
fs/fs.o(.text.devfs_dealloc_devnum+0xdc): undefined reference to `__test_and_clear_bit'
hppa-linux-ld: fs/fs.o(.text.devfs_dealloc_devnum+0xdc): cannot find stub entry 00000571___test_and_clear_bit+0
hppa-linux-ld: fs/fs.o(.text.devfs_dealloc_devnum+0xdc): cannot handle R_PARISC_PCREL17F for __test_and_clear_bit
fs/fs.o: In function `L948':
fs/fs.o(.text.devfs_alloc_unique_number+0xa8): undefined reference to `__set_bit'
hppa-linux-ld: fs/fs.o(.text.devfs_alloc_unique_number+0xa8): cannot find stub entry 00000571___set_bit+0
hppa-linux-ld: fs/fs.o(.text.devfs_alloc_unique_number+0xa8): cannot handle R_PARISC_PCREL17F for __set_bit
fs/fs.o: In function `L990':
fs/fs.o(.text.devfs_dealloc_unique_number+0x48): undefined reference to `__test_and_clear_bit'
hppa-linux-ld: fs/fs.o(.text.devfs_dealloc_unique_number+0x48): cannot find stub entry 00000571___test_and_clear_bit+0
hppa-linux-ld: fs/fs.o(.text.devfs_dealloc_unique_number+0x48): cannot handle R_PARISC_PCREL17F for __test_and_clear_bit
make: *** [vmlinux] Error 1

I'm using debootstrap on my i386 system to build a new root tarball.
Naturally the post-install scripts and such inside the chroot aren't
going to run, but I hope to get it along far enough to boot.

Regards,

Albert

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[parisc-linux] 720/50 - Out of options

[Carlos O'Donell Jr.]

> Hello,
> 
> I've tried compiling a kernel with devfs, but I'm not having any luck.
> I'm using xc-latest from about a week ago, and make palo dies with the
> following message:
>

True. I just tried it on my xcompile box, and I get the same thing :)

Seems to be an issue with __set_bit and __test_and_clear_bit,
maybe I'll look into that tonight.

I used to be able to compile with devfs, guess it needs some work
to get up to speed with the recent changes.

I'm out of simple suggestions for you 720/50 :)

I'll see where those unaligned errors come from ...

c. 

Don't Use base tarballs (was Re: [parisc-linux] nfsroot login problems on 720/50)

[Matt Taggart]

Albert Strasheim writes...

> Should I try the base tarball (same date... :-( ) or is that known to be
> bad too?

Neither are "bad" just out of date. As soon as we had a real installer 
everyone switched over to using that. They were left there for historical 
reasons.

I have moved them to an old directory to prevent confusion. No one should be 
using these any more. If, for some good reason, you can't use the normal 
installer process then I think the proper way to generate base tarballs now is 
to use the debootstrap tool. If there's enough demand then we could generate 
them and put them on the ftp site again.

-- 
Matt Taggart        Linux Development Lab
taggart@fc.hp.com   HP Linux Systems Operation

Re: Don't Use base tarballs (was Re: [parisc-linux] nfsroot login problems on 720/50)

[Albert Strasheim]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

Hello,

On Mon, 24 Sep 2001, Matt Taggart wrote:

> Albert Strasheim writes...
> 
> > Should I try the base tarball (same date... :-( ) or is that known to be
> > bad too?
> 
> Neither are "bad" just out of date. As soon as we had a real installer 
> everyone switched over to using that. They were left there for historical 
> reasons.
> 
> I have moved them to an old directory to prevent confusion. No one should be 
> using these any more. If, for some good reason, you can't use the normal 
> installer process then I think the proper way to generate base tarballs now is 
> to use the debootstrap tool. If there's enough demand then we could generate 
> them and put them on the ftp site again.

I'd gotten as far as debootstrapping woody up to the point where all the
packages were installed. As you might imagine, running binaries in the
chroot on my i386 didn't work too well :-)

If it is at all possible, could you please generate new tarballs? I'm
not sure if it is possible to complete the installation on my 720/50, so
the tarball will really go a long way to getting some userland apps
running so that I can perhaps provide better information for the real
hackers who are figuring out the unaligned trap stuff.

Regards,

Albert

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]