Re: Boot floppies 2.2.11 report (failure)
On 19 Apr 2000, Chris Baker wrote:
> Bjoern Brill <brill@samson.math.uni-frankfurt.de> writes:
>
> > On Fri, 14 Apr 2000, Christian T. Steigies wrote:
> >
> > > > - Now comes up a funny dialog box stating "NFS install detected. Copying
> > > > mac/images-1.44/rescue.bin to local before processing...".
> > > > That's ridiculous because there's nothing local to copy to and maybe
> > > > the cause for the trouble that follows. [But most probably not m68k
> > > > specific.]
> > > I never did an NFS install... I installed into my old swap partition, could
> > > you try that as well? Its ~100MB, good enough for a base install.
> > >
> > My swap alone isn't large enough, but I used it as root partition,
> > some others NFS below, and tried again. Success! And without new major
> > problems (some NFS stuff but that doesn't belong here). I can confirm now
> > that it is possible and even rather easy to install Debian with the 2.2.11
> > floppies on a networked Macintosh Quadra 700 as long as one avoids
> > NFS on / and /var .
> ^^^^
>
> I'm guessing you didn't mount /var with the `nolocks' option? Or
> maybe it's a different problem....
It is this problem. dbootstrap doesn't mount /var with the "nolocks"
option (I can of course change fstab manually before booting
the new system, but dbootstrap should really take care about that).
The problem then is that locking fails on /var and, consequently, apt and
dselect fail when the new system is booted the first time to complete
the installation.
NFS mounted partitions served by the Linux user space NFS server can't
use real NFS locks at all, so dbootstrap should include the "nolocks"
option into fstab. NFS mounted partitions served by the Kernel NFS server
or other Unices can use NFS locking, but AFAIK only if nfs-common (namely
rpc.statd) goes into base; this isn't the case at the moment.
A possible solution would be:
dbootstrap just puts nolocks in fstab for every NFS mount.
A better solution would be:
nfs-common goes into base and on the boot-floppies (it's really small).
When the user tries to mount a NFS share, dbootstrap creates a temporary
file on the share and tries to (NFS) lock it. If this succeds, we have
a server that supports NFS locking and don't use "nolocks" in fstab.
Otherwise, we put "nolocks" in fstab.
Warning: the combination rpc.statd running and /var NFS mounted
without "nolocks" but from a server that doesn't support the locking
protocols (like the user space server) bombed my console with so many
error messages I couldn't even use a text editor and also broke the
shutdown scripts.
Regards,
Bjoern Brill
--
Bj"orn Brill <brill@fs.math.uni-frankfurt.de>
Frankfurt am Main, Germany
Reply to: