Sat, 28 Jan 2017 00:17:40 +0100 Sven-Volker Nowarra <[email protected]>
> I am netbooting many systems, and last recently stepped on the issue, that I
> had an amd64 and an i386 client in the same network. I wanted to boot them
> into a "full" OpenBSD (not ramdisk kernel). That is not possible with the
> default installation, cause pxeboot can not distinguish between these
> Intel/AMD systems.

Hi Sven-Volker, Jiri,

I am also booting over network many systems in the same network, including
i386 and amd64 systems.  It is in fact quite possible to achieve this with
the default installation, with the help of the DHCP next-server statement.

> DHCP server can distinguish by MAC address, but then when
> pxeboot is loaded, the kernel is per default "bsd". This must clash either
> with i386 or amd64 architecture, whatever was dropped into tftpboot direcotry.

Quoting dhcpd.conf(5), please see here:  http://man.openbsd.org/dhcpd.conf

        next-server server-name;

  The next-server statement is used to specify the host address of the
  server from which the initial boot file (specified in the filename
  statement) is to be loaded. server-name should be a numeric IP address
  or a domain name. If no next-server parameter applies to a given
  client, the DHCP server's IP address is used.

Sample excerpts from host specific DHCP server config, for i386 and amd64:

        next-server 10.0.0.32;
        filename "auto_upgrade";

        next-server 10.0.0.64;
        filename "auto_upgrade";

Quoting autoinstall(8) for netbooting:  http://man.openbsd.org/autoinstall 

  On architectures where the filename statement is used to provide the
  name of the file to netboot it is necessary to create symbolic links
  called auto_install and auto_upgrade that point to the expected boot
  program and to change the value of the filename statement in the
  dhcpd.conf(5) file to be auto_install or auto_upgrade.

        # ln -s /tftpboot/i386/pxeboot  /tftpboot/i386/auto_upgrade
        # ln -s /tftpboot/amd64/pxeboot /tftpboot/amd64/auto_upgrade

Needless to say, you need to populate the /tftpboot/{i386,amd64} locations
with the system installation packages from the local mirror / compilation.

It is also quite easy to combine both the DHCP server and two instances of
tftpd(8), started independently listening on 2 IP address aliases, serving
pxeboot(8) respectively for i386 and amd64 systems stand alone each other.

See rcctl(8) to run a second copy of a daemon http://man.openbsd.org/rcctl

  The recommended way to run a second copy of a given daemon for a
  different purpose is to create a symbolic link to its rc.d(8) control
  script: 

        # ln -s /etc/rc.d/tftpd /etc/rc.d/tftpd2
        # rcctl set tftpd status on
        # rcctl set tftpd2 status on
        # rcctl set tftpd flags -4 -l 10.0.0.32 /tftpboot/i386
        # rcctl set tftpd2 flags -4 -l 10.0.0.64 /tftpboot/amd64
        # rcctl start tftpd
        # rcctl start tftpd2

For the list of the flags for tftpd(8), see:  http://man.openbsd.org/tftpd

When you need to upgrade a system, link the boot.conf to a file with this:

        boot tftp:/bsd.rd

When done, link it back the boot.conf file to a file that has the generic:

        boot hd0a:/bsd

This way you always net boot the system, then make it auto_upgrade, or run
the already installed system from the first hard disk where the system is.

Of course you may want to adjust these as per your environment and set up.
I would be glad if you could share an idea how to toggle boot.conf better.

I would be further much more grateful if there is in the near future a way
to provide automatic response file for local install for the serve system.

> So I went through some older mailing list entries, adapted them, and updated
> my meanwhile extensive netboot document. I updated this into a PDF, covering
> many, many details (now ~50 pages). Wanted to give something back to the
> community. The PDF is currently located here:
> http://nowarra.ch/Volker/netboot_OpenBSD/170127_netbooting_OpenBSD60.pdf

Nice read, thank you.  Hopefully you could further extend it, for multiple
concurrent network boot environments for simpler setup w/o custom patches.

Kind regards,
Anton

Reply via email to