Getting entirely too excited about tftp.server, I've convererted a rather hefty Jumpstart setup over to using dhcp and doing tftp/root nfs/install nfs all off the filer. Its working beautifully, and just generally rocks.
The one problem I'm having though is going booting from a snapmirrored volume. The client is always denied write access via mount options, so write operations always fail. .... However, when the volume is in ro snapmirrored state, the boot will hang after physical device probes. If I break the mirror, things work perfectly (w/o changes export options, etc).
I was going to take this up w/ Sun and did in further myself, but I thought I'd run it by the list to see if anyone knew how filesystem semantics change when a volume is snapmirrored.
..kg..
This is too funny because we were experiencing the same problem. It appears to be a NetApp bug. When we set the bootparams to do rootopts=:vers=2 the jumpstart works. I have an open case with NetApp and they say that this is fixed in 6.1.3.
Try that vers=2 for NFS Version 2 and see if it works for you. We are doing exactly what you are doing off a mirrored volume. The base volume in TX works great but the mirror we have in CA hangs. Once the root mount happens at version 2 it works. C-
On Thu, Mar 14, 2002 at 04:59:40PM -0800, kevin graham wrote:
Getting entirely too excited about tftp.server, I've convererted a rather hefty Jumpstart setup over to using dhcp and doing tftp/root nfs/install nfs all off the filer. Its working beautifully, and just generally rocks.
The one problem I'm having though is going booting from a snapmirrored volume. The client is always denied write access via mount options, so write operations always fail. .... However, when the volume is in ro snapmirrored state, the boot will hang after physical device probes. If I break the mirror, things work perfectly (w/o changes export options, etc).
I was going to take this up w/ Sun and did in further myself, but I thought I'd run it by the list to see if anyone knew how filesystem semantics change when a volume is snapmirrored.
..kg..
This is too funny because we were experiencing the same problem. It appears to be a NetApp bug. When we set the bootparams to do rootopts=:vers=2 the jumpstart works.
Yep, including that in DHCP vendor option 1 (equivalent to bootparam rootopts) did the magic trick. Makes sense where it dies too, as it is immediately after the kernel takes over responsibility for the NFS mount (doing v3) from the bootstrap (doing v2).
I have an open case with NetApp and they say that this is fixed in 6.1.3.
Good deal.
Try that vers=2 for NFS Version 2 and see if it works for you. We are doing exactly what you are doing off a mirrored volume. The base volume in TX works great but the mirror we have in CA hangs.
I was doing some cross-country jumpstarts (nfs root filesystems 3000mi away suck) today before I sent that mail and got your response -- needless to say it was a big help, thanks.
..kg..
-
Chris Blackmor -
kevin graham