Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

diskless workstation

0 views
Skip to first unread message

Danny Braniss

unread,
Sep 18, 2000, 3:00:00 AM9/18/00
to
}In message <2000091012...@elvis.mu.org>you write:
}}Danny Braniss (da...@cs.huji.ac.il) wrote:

}}> BTW, is someone working in passing all this stuff via dhcp? im trying to co
}m
}}e}}> up with an almost zero admin diskless ws solution.
}}
}}Yes, this has been done in current for a while and was back ported to
}}-stable yesterday.
}}
}will tryout asap.
}

if by -stable you mean whatever i get when i do a 'cvs co -rRELENG_4' src/sys
then there are some things missing.
i386/i386/autoconf.c does not have the stuff for pxe.
if i compile a kernel with the BOOTP_ stuff, then i can mount nfsroot, but
[mount_]mfs is broken, i get 'bad address' when trying to
mount_mfs ... /conf/etc.

if i see (or think i see :-) a bug in the diskless stuff who do i inform?

danny

To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message

Koster, K.J.

unread,
Sep 18, 2000, 3:00:00 AM9/18/00
to
>
> if by -stable you mean whatever i get when i do a 'cvs co
> -rRELENG_4' src/sys
> then there are some things missing.
> i386/i386/autoconf.c does not have the stuff for pxe.
> if i compile a kernel with the BOOTP_ stuff, then i can mount
> nfsroot, but
> [mount_]mfs is broken, i get 'bad address' when trying to
> mount_mfs ... /conf/etc.
>
> if i see (or think i see :-) a bug in the diskless stuff who
> do i inform?
>
I think the "bad address" messages indicate that your kernel and your
"world" are out of sync. Do a make world and install a freshly compiled
kernel.

Kees Jan

================================================
You are only young once,
but you can stay immature all your life.

Paul Saab

unread,
Sep 18, 2000, 3:00:00 AM9/18/00
to
Danny Braniss (da...@cs.huji.ac.il) wrote:
> if by -stable you mean whatever i get when i do a 'cvs co -rRELENG_4' src/sys
> then there are some things missing.
> i386/i386/autoconf.c does not have the stuff for pxe.
> if i compile a kernel with the BOOTP_ stuff, then i can mount nfsroot, but
> [mount_]mfs is broken, i get 'bad address' when trying to
> mount_mfs ... /conf/etc.

That means your kernel and userland are out of sync.

--
Paul Saab
Technical Yahoo
pa...@mu.org - p...@yahoo-inc.com - p...@freebsd.org
Do You .. uhh .. Yahoo!?

Paul Saab

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
Chris Csanady (c...@ameslab.gov) wrote:
> Has this actually been merged to -stable yet? I can't find anything that
> actually reads the boot.nfsroot.* loader variables.

Yes.. it was done more than a week ago.

Chris Csanady

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
Mike Smith wrote:
>
> > ok, once i compiled a kernel with options BOOTP things got better ;-)
> > it worked several times, but now it boots ok, (pxe->dhcp->tftpboot->nfs)
> > but after it re-configures the ethernet, the ethernet stops working!
> >
> > ponters anyone?
>
> You can't run dhclient (DHCP in any of the ifconfig lines in /etc/
> rc.conf) if you have mounted / via NFS.
>
> If you're running -current or a very recent -stable, remove the 'BOOTP'
> options. The loader now passes all the DHCP information into the kernel.
> Then leave the interface configuration alone...

Has this actually been merged to -stable yet? I can't find anything that
actually reads the boot.nfsroot.* loader variables.

Chris

Danny Braniss

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
In message <39C673DB...@ameslab.gov>you write:
}Mike Smith wrote:
}>
}> > ok, once i compiled a kernel with options BOOTP things got better ;-)
}> > it worked several times, but now it boots ok, (pxe->dhcp->tftpboot->nfs)
}> > but after it re-configures the ethernet, the ethernet stops working!
}> >
}> > ponters anyone?
}>
}> You can't run dhclient (DHCP in any of the ifconfig lines in /etc/
}> rc.conf) if you have mounted / via NFS.
}>
}> If you're running -current or a very recent -stable, remove the 'BOOTP'
}> options. The loader now passes all the DHCP information into the kernel.
}> Then leave the interface configuration alone...
}
}Has this actually been merged to -stable yet? I can't find anything that
}actually reads the boot.nfsroot.* loader variables.
}
no, last time i checked it's in SNPNG or something, but not stable.
i tried some retrofitting (made the changes to autoconfig.c) got past mountroot
but got stopped at 'nfs send error 65' :-(

danny

Paul Saab

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
Paul Saab (pa...@mu.org) wrote:

> Chris Csanady (c...@ameslab.gov) wrote:
> > Has this actually been merged to -stable yet? I can't find anything that
> > actually reads the boot.nfsroot.* loader variables.
>
> Yes.. it was done more than a week ago.

Ugh.. I could have sworn I MFC'd this a week ago, but it turns out I
did everything but the last part. *sigh*. I just MFC'd it.

--
Paul Saab
Technical Yahoo
pa...@mu.org - p...@yahoo-inc.com - p...@freebsd.org
Do You .. uhh .. Yahoo!?

Mike Smith

unread,
Sep 20, 2000, 3:00:00 AM9/20/00
to
> Mike Smith wrote:
> >
> > > ok, once i compiled a kernel with options BOOTP things got better ;-)
> > > it worked several times, but now it boots ok, (pxe->dhcp->tftpboot->nfs)
> > > but after it re-configures the ethernet, the ethernet stops working!
> > >
> > > ponters anyone?
> >
> > You can't run dhclient (DHCP in any of the ifconfig lines in /etc/
> > rc.conf) if you have mounted / via NFS.
> >
> > If you're running -current or a very recent -stable, remove the 'BOOTP'
> > options. The loader now passes all the DHCP information into the kernel.
> > Then leave the interface configuration alone...
>
> Has this actually been merged to -stable yet? I can't find anything that
> actually reads the boot.nfsroot.* loader variables.

Supposedly; Paul Saab did the merge.

--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]

Danny Braniss

unread,
Sep 20, 2000, 3:00:00 AM9/20/00
to
bug report:
in lib/libstand/bootp.c:

if (IN_CLASSA(myip.s_addr))
nmask = htonl(IN_CLASSA_NET);
else if (IN_CLASSB(myip.s_addr))
nmask = htonl(IN_CLASSB_NET);
else
nmask = htonl(IN_CLASSC_NET);
should be:

if (IN_CLASSA(ntohl(myip.s_addr)))
nmask = htonl(IN_CLASSA_NET);
else if (IN_CLASSB(ntohl(myip.s_addr)))
nmask = htonl(IN_CLASSB_NET);
else
nmask = htonl(IN_CLASSC_NET);

which explains why gateway was zero, even if it was provided by dhcp.
it also explains why it hung trying to mount via nfs.

danny

In message <2000091916...@elvis.mu.org>you write:
}Danny Braniss (da...@cs.huji.ac.il) wrote:

}> In message <2000091902...@elvis.mu.org>you write:
}>
}> }set this in your dhcpd.conf, but yes, I will fix it.
}> i know it should be in dhcpd.conf but what? :-) btw, i tried router but zilc
}h.
}
}option routers ip;
}
}> }
}> }> 2- if i set different hosts for dhcpd, tftpd, root and swap i get into
}> }> all sort of problems. the most anoying one is that the bios-pxe boot w
}ill
}> }> try and tftpboot from the wrong server. so im using 'option swap-serve
}r'
}> }
}> }I dont follow.
}> }
}>
}> if i set:
}> option root-path "132.65.16.6:/vol1/roots/fbsd-4.1S";
}> then the ip gets chunked, and it will try to mount from the tftp server -
}> bummer
}
}Yeah.. I have not wanted to do this. I'll look at this in a little while.
}
}> if i set
}> option next-server myrootserver
}> the pxe-bios will use it for the tftpd - bummer
}
}please read the PXE specs to see how to tell it to grab the tftp loader
}from a different server.
}
}> so, at the moment i use
}> option swap-server myrootserver;
}> and it works. but it should be less blackmagic. also, what if i want a
}> different
}> root and swap server?
}
}I'll fix it if I get time.

Paul Saab

unread,
Sep 21, 2000, 3:00:00 AM9/21/00
to
Umm.. I'm using the netboot just fine here for the ports cluster and
it is using the code in the tree w/ zero modifications. It boots via
nfs and comes up with ip, netmask, and gateway.

paul

--

Paul Saab
Technical Yahoo
pa...@mu.org - p...@yahoo-inc.com - p...@freebsd.org
Do You .. uhh .. Yahoo!?

Danny Braniss

unread,
Sep 21, 2000, 3:00:00 AM9/21/00
to
In message <2000092011...@elvis.mu.org>you write:
}Matt Dillon (dil...@earth.backplane.com) wrote:
}> A quick review of the code seems to indicate that this is indeed a bug.
}> As far as I can tell, the IN_CLASS*() macros assume host order. e.g.
}> from /usr/include/netinet/in.h:
}>
}> #define IN_CLASSA(i) (((u_int32_t)(i) & 0x80000000) == 0)
}>
}> Since s_addr is in network byte order, the conversion is necessary. If
}> this fixes Danny's problems, and doesn't break anyone else (Paul?), I'd
}> say it should be committed.
}
}After playing with it somemore, I agree.. It doesn't break for small
}networks, which is what I was testing on. I'll commit the fix.
}
i still think that this part of code is useless.
why overwride the info supplied by dhcp? if it's wrong then the dhcpd.conf
should be fixed or some message printed. at the moment, bootp silently ignores
some info it conciders wrong - wrongly :-)

danny

}paul

Paul Saab

unread,
Sep 21, 2000, 3:00:00 AM9/21/00
to
Danny Braniss (da...@cs.huji.ac.il) wrote:
> i still think that this part of code is useless. why overwride the
> info supplied by dhcp? if it's wrong then the dhcpd.conf should be
> fixed or some message printed. at the moment, bootp silently ignores
> some info it conciders wrong - wrongly :-)

This is required if no netmask is passed. Atleast that is the way I am
reading it.

--
Paul Saab
Technical Yahoo
pa...@mu.org - p...@yahoo-inc.com - p...@freebsd.org
Do You .. uhh .. Yahoo!?

Matt Dillon

unread,
Sep 21, 2000, 3:00:00 AM9/21/00
to
A quick review of the code seems to indicate that this is indeed a bug.
As far as I can tell, the IN_CLASS*() macros assume host order. e.g.
from /usr/include/netinet/in.h:

#define IN_CLASSA(i) (((u_int32_t)(i) & 0x80000000) == 0)

Since s_addr is in network byte order, the conversion is necessary. If
this fixes Danny's problems, and doesn't break anyone else (Paul?), I'd
say it should be committed.

-Matt

:Umm.. I'm using the netboot just fine here for the ports cluster and


:it is using the code in the tree w/ zero modifications. It boots via
:nfs and comes up with ip, netmask, and gateway.
:
:paul
:
:Danny Braniss (da...@cs.huji.ac.il) wrote:
:> bug report:
:> in lib/libstand/bootp.c:
:>
:> if (IN_CLASSA(myip.s_addr))
:> nmask = htonl(IN_CLASSA_NET);
:> else if (IN_CLASSB(myip.s_addr))
:> nmask = htonl(IN_CLASSB_NET);
:> else
:> nmask = htonl(IN_CLASSC_NET);
:> should be:
:>
:> if (IN_CLASSA(ntohl(myip.s_addr)))
:> nmask = htonl(IN_CLASSA_NET);
:> else if (IN_CLASSB(ntohl(myip.s_addr)))
:> nmask = htonl(IN_CLASSB_NET);
:> else
:> nmask = htonl(IN_CLASSC_NET);
:>
:> which explains why gateway was zero, even if it was provided by dhcp.
:> it also explains why it hung trying to mount via nfs.
:>
:> danny

Paul Saab

unread,
Sep 21, 2000, 3:00:00 AM9/21/00
to
Matt Dillon (dil...@earth.backplane.com) wrote:
> A quick review of the code seems to indicate that this is indeed a bug.
> As far as I can tell, the IN_CLASS*() macros assume host order. e.g.
> from /usr/include/netinet/in.h:
>
> #define IN_CLASSA(i) (((u_int32_t)(i) & 0x80000000) == 0)
>
> Since s_addr is in network byte order, the conversion is necessary. If
> this fixes Danny's problems, and doesn't break anyone else (Paul?), I'd
> say it should be committed.

After playing with it somemore, I agree.. It doesn't break for small


networks, which is what I was testing on. I'll commit the fix.

paul

Danny Braniss

unread,
Sep 21, 2000, 3:00:00 AM9/21/00
to
In message <2000092106...@mass.osd.bsdi.com>you write:
}
}I think this is correct, actually. Danny, can you confirm that you're
}using one of the class A address spaces (eg. 10.*.*.*?)
}
my net is class B. 132.65.0.0

}Actually, IMO the code around this is entirely wrong; we should always
}respect the mask supplied by the server, and only use the canonical mask
}if we don't get one at all.
}
my man!

im cleaning up bootp and will let you know.


}> bug report:
}> in lib/libstand/bootp.c:
}>
}> if (IN_CLASSA(myip.s_addr))
}> nmask = htonl(IN_CLASSA_NET);
}> else if (IN_CLASSB(myip.s_addr))
}> nmask = htonl(IN_CLASSB_NET);
}> else
}> nmask = htonl(IN_CLASSC_NET);
}> should be:
}>
}> if (IN_CLASSA(ntohl(myip.s_addr)))
}> nmask = htonl(IN_CLASSA_NET);
}> else if (IN_CLASSB(ntohl(myip.s_addr)))
}> nmask = htonl(IN_CLASSB_NET);
}> else
}> nmask = htonl(IN_CLASSC_NET);
}>
}> which explains why gateway was zero, even if it was provided by dhcp.
}> it also explains why it hung trying to mount via nfs.
}>
}> danny
}>

}... every activity meets with opposition, everyone who acts has his
}rivals and unfortunately opponents also. But not because people want
}to be opponents, rather because the tasks and relationships force
}people to take different points of view. [Dr. Fritz Todt]
}
}

Danny Braniss

unread,
Sep 21, 2000, 3:00:00 AM9/21/00
to
In message <2000092106...@mass.osd.bsdi.com>you write:
}> In message <2000092106...@mass.osd.bsdi.com>you write:
}> }
}> }I think this is correct, actually. Danny, can you confirm that you're
}> }using one of the class A address spaces (eg. 10.*.*.*?)
}> }
}> my net is class B. 132.65.0.0
}
}Gotcha. What's your netmask? I bet it disagrees one way or the other
}with the "canonical" netmask this code assumes.
it's the host part 132.65.80.247, the 247 is 0xF7 and hence class C :-)
my netmask is 255.255.0.0 for the time being till we go vlan.

}
}> }Actually, IMO the code around this is entirely wrong; we should always
}> }respect the mask supplied by the server, and only use the canonical mask
}> }if we don't get one at all.
}> }
}> my man!
}>
}> im cleaning up bootp and will let you know.
}

}You could make yourself *really* popular and teach it about DHCP, you
}know. 8)
}
what have you in mind? it already knows some DHCP, the leasing stuff is
yet a gray area with me (i dislike it totaly, but then i own a class B ;-)
i've added hostname though. suggestions?

on a different subject, but related:
on my nfsroot client, im now stuck - again -, ls -ls /dev/null shows
strange minor/major: 0, 0x00020002 instead od 2,2
which of course ruins rc.diskless.
the same filesystem when accessed by another fbsd4.1S (no nfsrooted) is ok.
hints?

danny

0 new messages