While it sounds like a good idea to extract the RFC1048 data from PXE, in the
end it is not and it is causing lots of issues. Our pxeloader might need
options which are incompatible with other pxe servers (for example iPXE, but
not only).
Our pxe loaders are also now settings their own user class, so it is useful to
issue our own pxe request at startup
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D10953
All the code are now only issueing one single dhcp request at startup of the
loader meaning we can always request a the PXE informations from the
dhcp server.
Previous code lost that information, meaning no option 55 anymore (meaning not
working with the kea dhcp server) and no request for rootpath etc, no user class
Remove the flags from the bootp function which is not needed anymore
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D10952
Rather that previous attempts to add tftpfs support at the same time as NFS
support. This time decide on a proper URI parser rather than hacks.
root-path can now be define the following way:
For tftpfs:
tftp://ip/path
tftp:/path (this one will consider the tftp server is the same as the one where
the pxeboot file was fetched from)
For nfs:
nfs:/path
nfs://ip/path
The historical
ip:/path
/path
are kept on NFS
Reviewed by: tsoom, rgrimes
Differential Revision: https://reviews.freebsd.org/D10947
The current read from network is working from up to down - we have some
protocol needing the data from the network, so we build the buffer space
for that protocol, add the extra space for headers and pass this buffer
down to be filled by nif get call in hope, we have guessed the incoming
packet size right. Amazingly enough this approach mostly does work, but
not always...
So, this update does work from down to up - we allocate buffer (based
on MTU or frame size info), fill it up, and pass on for upper layers.
The obvious problem is that when we should free the buffer - if at all.
In the current implementation the upper layer will free the packet on error
or when the packet is no longer needed.
While working on the issue, the additional issue did pop up - the bios
implementation does not have generic get/put interface but is using pxe
udpsend/udpreceive instead. So the udp calls are gone and undi interface
is implemented instead. Which in turn means slight other changes as we
do not need to have duplicated pxe implementation and can just use dev_net.
To align packet content, the actual read from nic is using shifted buffer by
ETHER_ALIGN (2).
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D10232
Don't use DHCP 150 option to decide which protocol use to netboot. When
root-path includes ip address - go thru NFS, if ip address not exists in
root-path - go thru TFTP from server which ip address is in next-server. But
there is one limitation - only one tftp server in network to provide loader and
everything else. Does enybody use more than only one?
Submitted by: kczekirda
Sponsored by: Oktawave
MFC after: 3 weeks
Relnote: Yes
Differential Revision: https://reviews.freebsd.org/D8740
Since the uset can set dhcp.interface-mtu, we need to try to validate the
value. So we verify if the conversion to int is successful and we will not
allow to set value greater than max IPv4 packet size.
Also use snprintf for safety.
Reviewed by: allanjude, bapt
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D8492
lsdev command does walk over devsw list, prints list element name and
will use dv_print() callback to print the device list.
Unfortunately this approach will add unneeded noise when there are no
particular devices detected.
To remove "empty" device section headers, the dv_print() callback
should print the header instead.
In addition, fixed dv_print callback for md module.
Reviewed by: imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D8551
This change does modify devsw dv_print() to return the int value,
enabling walkers to interrupt the walk on non zero value from dv_print().
This will allow the pager_print actually to stop displaying data on
user input, and additionally pager is used in various *dev_print callbacks,
where it was missing.
For test, lsdev [-v] command should display data by screenfuls and should
stop when the key 'q' is pressed on pager prompt.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D5461
dev_net.c code.
The NETIF_OPEN_CLOSE_ONCE flag was added in r201932 to prevent that behaviour
on some architectures (sparc64 and powerpc64) the default was left to always
open and close the device for each open and close of a file by the loader
because it was necessary for u-boot on arm.
Since it has been added, the flag was turned on for every arches including the
u-boot loader for arm.
This also fixes netbooting on RPi3 (tested by gonzo@)
For the loader.efi it greatly speeds up netbooting
Reviewed by: emaste, gonzo, tsoome
Approved by: gonzo
MFC after: 1 month
Sponsored by: Gandi.net
Differential Revision: https://reviews.freebsd.org/D8230
Add a new 'netproto' variable which can be set for now to
NET_TFTP or NET_NFS (default to NET_NONE)
From the dhcp options if one sets the root-path option to:
"ip:path", the loader will consider it is booting over NFS
(meaning same behaviour as the default current behaviour)
if the dhcp option "tftp server address" is set (option 150)
the loader will consider it is booting over tftpfs, it will then
consider the root-path options with 2 possible case
1. "path" then the IP of the tftp server will be the one passed by
the option 150, and the files will be retrieved under "path" on the tftp
server
2. "ip:path" then the IP of the tftp server will be the one passed in
the option "overwritting the IP from the option 150.
We could not "abuse" the rootpath option in the form or tftp://ip:path because
this is already used for other purpose by iPXE preventing any chainload from
iPXE to the FreeBSD loader.
Given at each open(), the loader loops over all available filesystems and keep
the "best" error, we needed to prevent tftpfs to fallback on nfs and vice versa.
the tftpfs and nfs implementation in libstand now return EINVAL early if
'netproto' for that purpose.
Reviewed by: tsoome
Relnotes: yes
Sponsored by: Gandi.net
Differential Revision: https://reviews.freebsd.org/D7628
Allow netbooting on efi without having to setup any NFS server by rebuilding the
loader with LOADER_TFTP_SUPPORT like for the i386 pxeloader
Sponsored by: Gandi.net
to the boot.netif.mtu env var, which will be picked up by pre-existing code
in nfs_mountroot() and used to configure the interface accordingly.
This should bring the same functionality when the bootp/dhcp work is done
by loader(8) as r297150 does for the in-kernel BOOTP case.
ubldr.
The changes are mostly dealing with removing unnecessary casts from the U-Boot
API (we're passing only pointers, no obvious reason to cast them to uint32_t),
cleaning up some compiler warnings and using the proper printf format
specifiers in order to be able to compile cleanly for both 32-bit and 64-bit
MIPS targets.
Reviewed by: imp
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5312
than bootp and rarp.
The code which splits a serverip:/rootpath string into rootip and a plain
pathname is now a separate net_parse_rootpath() function that can be
called by others. The code that sets the kernel env vars needed for
nfs_diskless is moved into net_open() so that the variables get set no
matter where the params came from.
There was already code in net_open() that allowed for the possibility that
some other entity has set up the network-related global variables. It uses
the rootip variable as the key, assuming that if it is set all the other
required variables are set too. These changes don't alter the existing
behavior, they just make it easier to actually write some new code to get
the params from another source (such as the U-Boot environment).
by keeping it opened after the first open and closing it via the
cleanup handler when NETIF_OPEN_CLOSE_ONCE is defined in order to
avoid the open-close-dance on every file access which with firmware
that for example performs an auto-negotiation on every open causes
netbooting to take horribly long. Basically the behavior with this
knob enabled resembles the one employed between r60506 and r177108
(and for sparc64 also again since r182919) with the addition that
the network device now is closed eventually before entering the
kernel and before rebooting. Actually I think this should be the
desired MI behavior, however the U-Boot loader actually requires
net_close() to be called after every transaction in order for some
local shutdown operations to be performed (and which I think thus
will break on concurrent opens, i.e. when netdev_opens is > 1, like
the loader does at least for disks when LOADER_GZIP_SUPPORT is
enabled).
- Use NETIF_OPEN_CLOSE_ONCE to replace the hack, which artificially
increased netdev_opens for sparc64 in order to keep the network
device opened forever, as at least some firmware versions require
the network device to be closed eventually before entering the
kernel or otherwise will DMA received packets to stale memory.
The powerpc OFW loader probably wants NETIF_OPEN_CLOSE_ONCE to be
set as well for the same reasons.
isn't fixed to only open the network device once and not do a open
and close dance on every file access; the firmwares of newer sparc64
machines perform an auto-negotiation with every open which in turn
causes netbooting to take horribly long if we open and close the
device over and over again.
This was introduced as a workaround long time ago for some Alpha firmware
(which is now gone), and actually prevented net_close() to ever be
called.
Certain firmwares (U-Boot) need local shutdown operations to be performed on a
network controller upon transaction end: such platform-specific hooks are
supposed to be called via netif_close() (from within net_close()).
This change effectively reverts the following CVS commit:
sys/boot/common/dev_net.c
revision 1.7
date: 2000/05/13 15:40:46; author: dfr; state: Exp; lines: +2 -1
Only probe network settings on the first open of the network device.
The alpha firmware takes a seriously long time to open the network device
the first time.
Also suppress excessive output while netbooting via loader, unless debugging.
While there, make sys/boot/uboot more style(9) compliant.
Reviewed by: imp
Approved by: cognet (mentor)
bootp -> BOOTP
bootp.nfsroot -> BOOTP_NFSROOT
bootp.nfsv3 -> BOOTP_NFSV3
bootp.compat -> BOOTP_COMPAT
bootp.wired_to -> BOOTP_WIRED_TO
- i.e. back out the previous commit. It's already possible to
pxeboot(8) with a GENERIC kernel.
Pointed out by: dwmalone
BOOTP -> bootp
BOOTP_NFSROOT -> bootp.nfsroot
BOOTP_NFSV3 -> bootp.nfsv3
BOOTP_COMPAT -> bootp.compat
BOOTP_WIRED_TO -> bootp.wired_to
This lets you PXE boot with a GENERIC kernel by putting this sort of thing
in loader.conf:
bootp="YES"
bootp.nfsroot="YES"
bootp.nfsv3="YES"
bootp.wired_to="bge1"
or even setting the variables manually from the OK prompt.
the root path. This is reported to make non-PXE netbooting, such as
is used on sparc64 systems, work correctly when the TFTP server is
not the same as the root server.
PR: kern/57328
Submitted by: Per Kristian Hove <Per.Hove@math.ntnu.no>
identifier to the DHCP server. Now you can check for this string
in your dhcp configuration to decide whether you will hand out a
lease to the client or not.
* Make it possible to type a filename to boot1 so that it is possible to
recover from fatally broken versions of /boot/loader.
* Make a start at a CD boot program (not yet functional).
* Make the network code in the bootstrap more chatty (helps debugging)
* Add nfs root stuff to cpu_rootconf(). I also added a check to make sure
it really was netbooting which allows the use of the same kernel for local
and network boots.
* Tweak the de driver so that it takes the speed setting from the console
for the alpha (some PWSs have broken de chipsets). This is the same
behaviour as NetBSD/alpha.
Submitted by: Andrew Gallatin <gallatin@cs.duke.edu>
'three-stage' bootstrap.
There are a number of caveats with the code in its current state:
- The i386 bootstrap only supports booting from a floppy.
- The kernel and kld do not yet know how to deal with the extended
information and module summary passed in.
- PnP-based autodetection and demand loading of modules is not implemented.
- i386 ELF kernel loading is not ready yet.
- The i386 bootstrap is loaded via an ugly blockmap.
On the alpha, both net- and disk-booting (SRM console machines only) is
supported. No blockmaps are used by this code.
Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
