Netbooting Sparc64

Didrik Madheden didrik at
Fri Apr 27 13:45:58 UTC 2007

So, here's another report.
As far as I can tell, I've now managed to configure raepd, tftp and
dhcpd correctly. My last problem seems to be NFS.
I've managed to get to the loader prompt (As opposed to the OPB
prompt) It actually lets me load a kernel over tftp, but appearantly I
had to begin the file path with / for load but not for more. ("more
text.txt" works, but I needed to write "load /kernel" rather than
"load kernel", which took a while to understand.)
So, after the kernel has loaded, I'm stuck at this prompt:
nfs_diskless: no NFS handle

Manual root filesystem specification:
  <fstype>:<device>  Mount <device> using filesystem <fstype>
                       eg. ufs:/dev/da0a
  ?                  List valid disk boot devices
  <empty line>       Abort manual input

panic: Root mount failed, startup aborted.
cpuid = 0
Uptime: 18m15s
Cannot dump. No dump device defined.
Automatic reboot in 15 seconds - press a key on the console to abort
The last lines is what happens if I just enter an empty line.

I've tried different configurations for NFS, but none of them seems to
give even the slightest indication that NFS is working.
Right now, this line is my exports file:
/ -alldirs -maproot=0 -network -mask
I know it's wrong to give root RW access to my whole file system, but
I'm in a "chmod 777" mood right now. (And I'm firewalled and not
expecting intruders)
This is my rc.conf:

Do I need an inetd.conf entry for NFS perhaps?
I'm feeling frustration. (I'm getting the feeling that if I'd try to
boot from cdrom now, it'd work just fine, just to give irony a chance
to spit me in the face)

I also saw this message in the boot log:
>atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug
> expect reduced performance
This may be a problem since my disk is 400 GB big. Is this bug FBSD
specific? Is there a workaround for using DMA without bugs?

/Didrik Madheden

On 4/25/07, Miles Nordin <carton at> wrote:
> >>>>> "dm" == Didrik Madheden <didrik at> writes:
>     dm> panic: arp: no response for
> I don't know.  What you did looks right to me.  I think /boot/loader
> ought to print out more things, such as it's own IP, subnet mask, and
> router, but I guess ours doesn't.
> 1. make sure you are specifying a subnet mask and a default router in
>    your subnet stanza.  Here's mine:
>         subnet netmask {
>                 option routers;
>                 server-identifier;
>                 option subnet-mask;
>                 option broadcast-address;
>         }
> 2. if that doesn't work, add a 'next-server' to
>    sune.lan's host stanza.  It shouldn't be needed---next-server is
>    for TFTP, not NFS.  but, I know /boot/loader will try to load the
>    rest of itself and the kernel over either TFTP or NFS (using NFS
>    seems more self-documenting to me), so maybe it's panicing on the
>    TFTP part because of a wrong exception path, instead of falling
>    through to the NFS part.

-----BEGIN 2ROT13 MESSAGE-----
Low Bitrate Netlabel: <>
Electronic music forum:
Sätt på ett par flipflops, vippa på rumpan
och gör det här till en minnesvärd sommar!
-----END 2ROT13 MESSAGE-----

More information about the freebsd-sparc64 mailing list