network booting

network booting

[nimeesh]

hello sir,

I'm new to linux.I'm trying network booting of linux
system.System Conf.(intel 815 chipset ,PXE
bios,3com905c-ethernet card)

In that i'm facing problem with kernel image and it's
file system.

It gives me error as
kernel panic : unable to mount root fs on 01:00

Is it necessary to use NFS or is it possible without
that? Any special specification while creating kernel
image and filesystem?
If any body can tell me any doc available on net,i'll
be very thankful.

Thanks in Advance..
nimeesh patel



=====
nimeesh patel
Development Engg.
DiviNet Access Tech Ltd.
Pune.
Ph.No. 91(20)5284696

________________________________________________________________________
Looking for a job?  Visit Yahoo! India Careers
      Visit http://in.careers.yahoo.com

Re: network booting

[Chris Chabot]

Yes, a NFS root is (as far as i know!) the only networked drive type 
linux can boot of.
(ofcource any variation of local storage can be used, but then PXE is 
not realy needed ;-)

For PXE documentation, check out /usr/share/doc/pxe-.... (atleast thats 
on a redhat box), and for NFS-ROOT documentation check out 
/usr/src/linux/Documentation/nfsroot.txt ;-)

What i found to work well for testing is to build a nfs-root kernel, 
which i booted from HD for testing, with the nfsroot/dhcp command's 
appended on the lilo line.. when that works, try to move it to PXE 
boot-strapping.

Also, be carefull with pxe / dhcpd.. the order in which you start up 
those servers will determine if it works or not (start dhcpd first, else 
pxe will try to take the dhcp port).

Last, get your self a good boot-strapper. The one provided by intel in 
the pxe package gave me more headaches then confort, so i switched to 
BPBatch.

For more info on config files etc, check out this piece JMZ wrote:
http://www.dnalounge.com/backstage/src/kiosk/

    -- Chris

nimeesh wrote:

>hello sir,
>
>I'm new to linux.I'm trying network booting of linux
>system.System Conf.(intel 815 chipset ,PXE
>bios,3com905c-ethernet card)
>
>In that i'm facing problem with kernel image and it's
>file system.
>
>It gives me error as
>kernel panic : unable to mount root fs on 01:00
>
>Is it necessary to use NFS or is it possible without
>that? Any special specification while creating kernel
>image and filesystem?
>If any body can tell me any doc available on net,i'll
>be very thankful.
>
>Thanks in Advance..
>nimeesh patel
>
>
>
>=====
>nimeesh patel
>Development Engg.
>DiviNet Access Tech Ltd.
>Pune.
>Ph.No. 91(20)5284696
>
>________________________________________________________________________
>Looking for a job?  Visit Yahoo! India Careers
>      Visit http://in.careers.yahoo.com
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>

Re: network booting

[Wakko Warner]

> Yes, a NFS root is (as far as i know!) the only networked drive type 
> linux can boot of.
> (ofcource any variation of local storage can be used, but then PXE is 
> not realy needed ;-)
> 
> For PXE documentation, check out /usr/share/doc/pxe-.... (atleast thats 
> on a redhat box), and for NFS-ROOT documentation check out 
> /usr/src/linux/Documentation/nfsroot.txt ;-)
> 
> What i found to work well for testing is to build a nfs-root kernel, 
> which i booted from HD for testing, with the nfsroot/dhcp command's 
> appended on the lilo line.. when that works, try to move it to PXE 
> boot-strapping.
> 
> Also, be carefull with pxe / dhcpd.. the order in which you start up 
> those servers will determine if it works or not (start dhcpd first, else 
> pxe will try to take the dhcp port).
> 
> Last, get your self a good boot-strapper. The one provided by intel in 
> the pxe package gave me more headaches then confort, so i switched to 
> BPBatch.
> 
> For more info on config files etc, check out this piece JMZ wrote:
> http://www.dnalounge.com/backstage/src/kiosk/

I've been wanting to know about this.  I'm running a machine right now with
an intel 10/100 management adapter.  My server is running a very old copy of
debian.  It has a modded tftp server from HPA.  It downloads the pxelinux
(same as syslinux, but for network).

I found out this method doesn't work on 3com adapters.  the tftpserver and
pxelinux are the newest things on that machine (which is about 2 years old
now)

Where can I find the pxe thing you mentioned above?

> >hello sir,
> >
> >I'm new to linux.I'm trying network booting of linux
> >system.System Conf.(intel 815 chipset ,PXE
> >bios,3com905c-ethernet card)
> >
> >In that i'm facing problem with kernel image and it's
> >file system.
> >
> >It gives me error as
> >kernel panic : unable to mount root fs on 01:00
> >
> >Is it necessary to use NFS or is it possible without
> >that? Any special specification while creating kernel
> >image and filesystem?
> >If any body can tell me any doc available on net,i'll
> >be very thankful.
> >
> >Thanks in Advance..
> >nimeesh patel
> >
> >
> >
> >=====
> >nimeesh patel
> >Development Engg.
> >DiviNet Access Tech Ltd.
> >Pune.
> >Ph.No. 91(20)5284696
> >
> >________________________________________________________________________
> >Looking for a job?  Visit Yahoo! India Careers
> >      Visit http://in.careers.yahoo.com
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at  http://www.tux.org/lkml/
> >
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: network booting

[Chris Chabot]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

[..]

>I found out this method doesn't work on 3com adapters.  the tftpserver and
>pxelinux are the newest things on that machine (which is about 2 years old
>now)
>
>Where can I find the pxe thing you mentioned above?
>
See the README i cut&pasted below. It's the readme for intel's pxe-0.1 
for linux.. with all the relevant links in it.
ps, do note your BIOS has to be pc99 compliant to be able to do PXE booting.

If not, your alternatives are 1) a boot eprom with a kernel image or 
boot loader or 2) a floppy / cdrom with a boot loader and a kernel. This 
kernel can be configured for DHCP / nfsroot, so the actualy loading and 
anything afterwards will happen over the network.





[-- Attachment #2: README --]
[-- Type: text/plain, Size: 16196 bytes --]

Preboot Execution Environment (PXE) README


When the PXE daemons are installed and configured, you will be able to remote 
boot and install Linux.

This README provides specific instructions for configuring a remote boot
network install of Linux on your system.  However, you can modify the procedure
to build Linux boot images for a variety of purposes (e.g. Remote boot Linux as your native OS, Beowulf configurations, etc.)


PXE Background Information  
==========================

PXE defines an industry standard method of remote booting.

PXE remote boot client support is a required by PC98 and PC99 for all Office
PCs (<http://www.pcdesguide.com/pc99>) and by the Wired for Management
Initiative sponsored by Intel Corp. (<http://developer.intel.com/ial/wfm>)
As a result, most PC OEMs offer PXE support for LAN on motherboard platforms
and for business platforms containing a PXE enabled NIC.

In addition, to upgrade existing PC platforms, PXE compliant NICs are offered
by Intel (<http://www.intel.com/network/products/pro100mgmt.htm>) 
and 3Com (<http://www.3comnicfinder.com/Product.asp?ProductID=49>), and
possibly other NIC vendors.

Finally, many NICs with boot ROM sockets or flash chips can be upgraded to PXE 
compliance.  PXE compliant boot ROMs are available from  
     -  Bootix Inc (<http://www.bootix.com>),  
     -  3Com/Lanworks (<http://www.3com.com/products/dsheets/400350.html>), and
     -  Elisa Research. (<http://www.elisaresearch.com/>).

The PXE 2.1 specification can be found at: 
	(<ftp://download.intel.com/ial/wfm/pxespec.pdf>)


Required Equipment
==================

To create a remote boot network environment you will need the following 
equipment:

     -  One DHCP Server (DHCP or BOOTP daemon required)

     -  One or (optionally) two PXE Servers (PXE daemon and TFTP/MTFTP daemon 
	required on each)

     -  One or more PXE PC clients


DHCP Server Considerations 
--------------------------

The DHCP server can be located anywhere on your network as long as it is 
reachable by the booting client(s).  The DHCP server provides the PXE client(s) 
with the following information: a client IP address, subnet mask, and optional 
gateway IP address.  Without this information the client cannot remote boot.

The PXE daemon cannot be used on this server because the DHCP daemon will not 
allow sending back a class-identifier (option 60) in the DHCP offer.  PXE 
clients must see the class-identifier (option 60) set to "PXEClient". 
Therefore this option (among others) must be provided by proxyDHCP (see next
section).


PXE Server Considerations
-------------------------

The following information provides an overview for a basic setup, but does not 
cover all the possible options available.  For more information on extending 
these capabilities you should refer to the PXE 2.1 specification.

The PXE server runs the PXE daemon and the TFTP and/or MTFTP daemons. The PXE 
daemon provides two capabilities: "proxyDHCP" and "PXE Bootserver".  The PXE 
daemon can be set up to provide either or both of the capabilities.  Both 
capabilities are required.  Normally you will enable both capabilities on a 
single machine, however you may wish to provide multiple "PXE Bootserver" 
capabilities across several machines to provide load balancing and redundancy
in a large installation.

Specific setup information is provided in the "Installing and Building PXE" 
section below.


proxyDHCP 
---------

proxyDHCP is a capability provided by the PXE daemon.  As the name implies, 
proxyDHCP works in parallel with DHCP and provides the booting client with 
remote boot configuration options.  ProxyDHCP provides the PXE client(s) with 
the following information: remote boot prompt with optional timeout, remote
boot menu and PXE Bootserver discovery options.

To insure that the server providing proxyDHCP is reachable by the PXE client,
do one of the following:

1.	Wherever you have a DHCP server on your network, place a proxyDHCP 
	server on the same subnet.  If you use routers to forward DHCP packets 
	to your DHCP server(s), you must reconfigure the routers to also 
	forward DHCP packets to the server providing proxyDHCP.

or

2.	Place a server providing proxyDHCP on each subnet where you have PXE 
	clients that you want/need to remote boot.

Whether you choose #1 or #2, is up to you.  The important thing is that the
DHCP discover packet sent by the PXE client reaches both the DHCP and the
proxyDHCP servers.

ProxyDHCP also serves up an initial NBP (network bootstrap program) to older 
(WfM-1.1a compliant) PXE boot ROMs.  These ROMs usually identify themselves
with a version numbers from 0.97 to 0.99n.  To insure support for these boot
ROMs, you must have a TFTP/MTFTP daemon installed on your proxyDHCP server and
you must include the initial bootstrap file:

	/tftpboot/X86PC/UNDI/BStrap/bstrap.0

At this point, the booting client now has enough information to discover the
PXE Bootserver.  Configuration of the PXE Bootserver is described in the next 
section.


PXE Bootserver  
--------------

The PXE Bootserver is a capability provided by the PXE daemon. The PXE 
Bootserver is the capability that provides the booting client with boot images 
for a particular boot environment.  In this case, you are setting up the PXE 
Bootserver to serve Linux remote installation boot images.

A PXE Bootserver serves up requested NBPs to PXE clients. PXE Clients locate
PXE Bootservers using discovery information provided to the client by
proxyDHCP.  The discovery method used by the PXE client (multicast, broadcast
or unicast) and the list of available bootserver types is controlled by
proxyDHCP.  PXE Bootservers always listen for all three types of discovery
requests and will respond to all valid requests.

Mulicast discovery:  If multicast discovery is used, all the PXE Bootservers 
must be configured to listen for the same multicast session.  If there are 
routers between your PXE Bootservers and your PXE clients, the routers must be 
configured to forward multicast IP packets.  When a PXE client tries to
discover a PXE Bootserver using multicast discovery, the client writes a PXE
Bootserver request packet to the PXE Bootserver multicast IP address and waits
for a matching broadcast or unicast PXE Bootserver reply packet.

Broadcast discovery:  If broadcast discovery is used, all of the PXE
Bootservers must be configured to listen for broadcast packets.  If there are
routers between your PXE Bootservers and your PXE clients, the routers must be 
configured to forward DHCP broadcast packets to the PXE Bootservers.

Unicast discovery:  If a list of PXE Bootserver types and IP addresses is 
included in the proxyDHCP offer packet, the PXE client will unicast a PXE 
Bootserver request packet to each PXE Bootserver in the list until it gets a 
matching PXE Bootserver reply packet.


PXE Client  
----------

Almost any Pentium-class machine with PXE support either built into the BIOS or 
included as an option ROM on an add-in NIC can be a PXE client.

There are two classes of PXE capable clients:  those that comply with the  
"Wired for Management Baseline Version 1.1a" (WfM-1.1a) specification and those 
that comply with the "Preboot Execution Environment Version 2.0" (PXE-2.0) 
specification.  The PXE for WfM-1.1a capability is a subset of PXE-2.0. 
Clients written to the WfM-1.1a specification require an additional bootstrap
program to be downloaded from the proxyDHCP server.  This is discussed earlier
in the "proxyDHCP" section.

When a client has completed its DHCP sequence and has received its proxyDHCP 
offer packet, it then does the following:

     -  If the offer packet includes a boot prompt, it is displayed on the 
	screen.

     -  If the offer packet includes a boot prompt timeout, the client waits 
	until the timeout expires.  If the timeout expires, the first item in 
	the remote boot menu is automatically selected.

     -  If the user presses F8, the timer stops and the remote boot menu is 
	displayed.  The user then selects the desired remote boot option. As 
	set up here, the two options are "Local Boot" and "Install  Linux"

     -  The selected boot menu item is executed.  This may be 'local boot', 
	which will cause PXE to unload and return control to the system BIOS, 
	which is normally followed by an attempt to boot from either the floppy 
	or hard drive.

     -  If "Install  Linux" is selected, the client tries to discover a PXE 
	Bootserver that serves Linux install NBPs.
	
     -  If a matching PXE Bootserver is not found, the client will timeout and 
	return control to the system BIOS.

     -  If a matching PXE Bootserver is found, the client downloads the initial 
	bootstrap from the boot server and transfers control to the downloaded 
	program.


Installing and Building PXE 
===========================

Install the PXE package:

	rpm -ihv /PATH-TO-RPM-FILE/pxe-#.#-#.src.rpm

If you want to rebuild the PXE network bootstrap programs (NBPs), you must 
install the dev86 package:

	rpm -ihv /PATH-TO-RPM-FILE/dev86-#.#.#-#.i386.rpm

After the PXE package is installed, the following files are created in your  
SOURCES directory ( /usr/src/redhat/SOURCES/ ):

	pxe-README (this file) 
	pxe-linux.tar.gz (PXE daemon, MTFTP daemon and NBP source files)
	pxe-linux-config.patch (RedHat specific changes/enhancements)
	pxe.init (PXE daemon start/stop script)

Expand the PXE tar file.  This will create a pxe-linux/ directory with the PXE 
daemon and NBP source files.

	cd /usr/src/redhat/SOURCES 
	tar xvofz pxe-linux.tar.gz

Apply the patch:

	patch -p0 <pxe-linux-config.patch

Copy the PXE daemon start/stop script:

	cp pxe.init /etc/rc.d/init.d/pxe

Build and install the PXE daemon:

	cd pxe-linux/server 
	make 
	make install

After running 'make install' the following files are installed:

	/usr/sbin/pxe 
	/usr/sbin/in.mtftpd 
	/etc/pxe.conf 
	/etc/mtftp.conf 
	/tftpboot/X86PC/UNDI/BStrap/bstrap.0 
	/tftpboot/X86PC/UNDI/linux-install/linux.0

You must add the following line to your /etc/inetd.conf file to enable the 
TFTP daemon:

	tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpboot

If you want to use the PXE MTFTP daemon, then also add this line to your 
/etc/inetd.conf file:

	mtftp dgrap udp wait root /usr/sbin/tcpd in.mtftpd /tftpboot

If you want to use the PXE MTFTP daemon, add the following line to your 
/etc/services file:

	mtftp		1759/udp

You must also add the following lines to your /etc/services file:

	pxe		67/udp 
	pxe		4011/udp

You now must edit the /etc/pxe.conf and /etc/mtftpd.conf files so they match 
your existing/desired network configuration.  For simple testing the existing 
/etc/pxe.conf and /etc/mtftpd.conf files are adequate. For improved performance 
and complex network configurations, these files must be changed.  These changes 
are covered later in this document in the "Configuring the PXE Daemon" section 
and in the "Configuring the MTFTP Daemon" section.

To enable the remote  Linux installation, you must add two more files to the 
/tftpboot/X86PC/UNDI/linux-install/ directory.  These files are:

	linux.1  (The Linux kernel)

and

	linux.2 (The Linux installation initrd image)

You will find the kernel and initial RAMDisk (initrd) image on the CD or FTP 
site:

	Kernel = misc/src/trees/boot/vmlinux 

	Initrd = misc/src/trees/initrd-network.img



Copy the vmlinux file to /tftpboot/X86PC/UNDI/linux-install/linux.1 and the 
initrd file to /tftpboot/X86PC/UNDI/linux-install/linux.2

Now start your PXE services.  You do this by restarting your Linux server or by 
running the following commands:

	/etc/rc.d/init.d/pxe start 
	/etc/rc.d/init.d/inet restart


Now boot a PXE client.  When "Press F8 to view menu..." is displayed on the 
booting client, press the <F8> key.  Select "Install Linux" from the remote
boot menu.

The client should download the kernel and initrd image, boot the kernel and 
bring up a Linux network installation screen.  If this does not happen, go back 
and double check your configuration files and insure your PXE and TFTP/MTFTP 
daemons are running.


Configuring the PXE Daemon
==========================

The following information provides an overview for a basic setup, but does not 
cover all the possible options available.  For more information on extending 
these capabilities you should refer to the PXE 2.1 specification.

The PXE daemon configuration file, /etc/pxe.conf, will work correctly for the 
'Network #1' setup defined later in this section.  If you need to add other 
proxyDHCP or Bootservers to your network, you will need to change some of the 
settings in this file.

Most of the fields in the configuration file are not described in this document 
because they do not affect the Linux remote boot installation.  Inside the 
configuration file you will find that all of the fields, and their settings, 
are documented.


Common Fields to Check
----------------------

[Discovery_MCast_Disabled]:  If you have routers on your network between your 
PXE Bootservers and your PXE clients and these routers are not configured to 
forward multicast IP packets, you will need to this field from '0' to '1'.  You 
will also want to disable MTFTP (see the next section on how to configure the 
MTFTP daemon).

[Discovery_BCast_Disabled]:  If you have routers on your network between your 
PXE Bootservers and your PXE clients and these routers are not configured to 
forward broadcast IP packets, you will need to change this field from '0' to 
'1'.

[Discovery_List]:  If you disable both multicast and broadcast discovery 
mechanisms, you MUST enable unicast discovery by filling in this field with the 
IP addresses and types of your PXE Bootservers.


Network #1 -  using a single PXE Server
----------

     -  A DHCP server

     -  One PXE server (proxyDHCP and PXE Bootserver both enabled)

     -  One or more PXE clients

     -  The defaults in your PXE daemon configuration file support this
     	configuration.


Network #2 – using multiple PXE Servers
----------

     -  A DHCP server

     -  One PXE Server with proxyDHCP enabled

     -  One or more PXE Servers with PXE Bootserver enabled

     -  One or more PXE clients

For this configuration, you must make the following changes to your PXE daemon 
configuration file (/etc/pxe.conf):

     -  On the PXE Server with proxyDHCP enabled, remove "13,linux-install" 
	from the list of supported [Service_Types].

     -  On the PXE Server() with PXE Bootserver enabled, change [StartProxy] 
	from '1' to '0' and remove "0,BStrap" from the list of supported 
	[Service_Types].


Configuring the MTFTP Daemon
============================

The MTFTP daemon configuration file, /etc/mtftpd.conf, will not need to be 
changed.  It is already configured to remote boot a Linux installation 
using MTFTP.

If you do not, or cannot, use MTFTP on your network; change 
[IsMulticastEnabled] from '1' to '0'.

You should not need to change the MTFTP port numbers [ServerPort] and 
[ClientPort].  All MTFTP servers and client on the same network can use the 
same initial port numbers.  Like TFTP, a MTFTP session switches to a different 
port number after the first packet exchange.

The [OpenTimeout] and [ReopenDelay] fields are good for most situations.  If 
you find that you are multicasting large files you might want to increase the 
timeout/delay fields a little.  Please note that these fields affect all 
multicasted files.  If you make these fields larger than 5 seconds, you should 
probably remove the smaller files from the [Multicast_ip_addresses] section.

If you look at the last section, [Multicast_ip_addresses] in the configuration 
file, you will see that both NBPs (bstrap.0 and linux.0), the kernel (linux.1) 
and the initial RAMDisk image (linux.2) have been assigned multicast IP 
addresses.  Any file that is not listed in this section will NOT be 
multicasted.  Any file that is listed MUST have a unique multicast IP address 
assigned to it.

If you change the name or location of your /tftpboot directory, you will have
to edit the filenames in the /etc/mtftpd.conf file and the directory names in
the /etc/pxe.conf file.

Network booting

[Chris Tapp]

Is there an easy way to have a system boot and load the rootfs from a network server?

I'm using an x86 system and can have the kernel and an initrd on it. I would use bootp, but a lot of end users either don't have this or will not allow it to be used. I think it needs to go something like:

1) Kernel loads the initrd and bring the network up (static or DHCP);
2) The rootfs image can then be download;
3) Some magic then makes this run...

This would allow easy update of the rootfs and makes it non-volatile (which is good for this project).

Does this make sense, or is there a better / easier way to do it?

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Network booting

[Chris Tapp]

On 31 Jul 2013, at 21:30, Chris Tapp wrote:

> Is there an easy way to have a system boot and load the rootfs from a network server?
> 
> I'm using an x86 system and can have the kernel and an initrd on it. I would use bootp, but a lot of end users either don't have this or will not allow it to be used. I think it needs to go something like:
> 
> 1) Kernel loads the initrd and bring the network up (static or DHCP);
> 2) The rootfs image can then be download;
> 3) Some magic then makes this run...
> 
> This would allow easy update of the rootfs and makes it non-volatile (which is good for this project).
> 
> Does this make sense, or is there a better / easier way to do it?

Looks like http://ipxe.org/ could be what's needed.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Network booting

[Paul Eggleton]

Hi Chris,

On Wednesday 31 July 2013 22:25:42 Chris Tapp wrote:
> On 31 Jul 2013, at 21:30, Chris Tapp wrote:
> > Is there an easy way to have a system boot and load the rootfs from a
> > network server?
> > 
> > I'm using an x86 system and can have the kernel and an initrd on it. I
> > would use bootp, but a lot of end users either don't have this or will
> > not allow it to be used. I think it needs to go something like:
> > 
> > 1) Kernel loads the initrd and bring the network up (static or DHCP);
> > 2) The rootfs image can then be download;
> > 3) Some magic then makes this run...
> > 
> > This would allow easy update of the rootfs and makes it non-volatile
> > (which is good for this project).
> > 
> > Does this make sense, or is there a better / easier way to do it?
> 
> Looks like http://ipxe.org/ could be what's needed.

FWIW, a couple of years ago I did write a recipe for ipxe which I successfully
used for over-the-network booting with atom-pc. I never found a proper home
for it though so it's still sitting in one of my poky-contrib branches:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/tree/meta/recipes-bsp/ipxe?h=paule/ipxe

Feel free to make use of it if it helps you. (I can't promise it hasn't
bitrotted in the time since I wrote it, so it may need tweaking; I notice
I didn't even specify a SRCREV which really should be specified, and
I'm not sure if it's cross-compiling properly either).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Network booting

[Chris Tapp]

Hi Paul,

On 1 Aug 2013, at 09:35, Paul Eggleton wrote:

> Hi Chris,
> 
> On Wednesday 31 July 2013 22:25:42 Chris Tapp wrote:
>> On 31 Jul 2013, at 21:30, Chris Tapp wrote:
>>> Is there an easy way to have a system boot and load the rootfs from a
>>> network server?
>>> 
>>> I'm using an x86 system and can have the kernel and an initrd on it. I
>>> would use bootp, but a lot of end users either don't have this or will
>>> not allow it to be used. I think it needs to go something like:
>>> 
>>> 1) Kernel loads the initrd and bring the network up (static or DHCP);
>>> 2) The rootfs image can then be download;
>>> 3) Some magic then makes this run...
>>> 
>>> This would allow easy update of the rootfs and makes it non-volatile
>>> (which is good for this project).
>>> 
>>> Does this make sense, or is there a better / easier way to do it?
>> 
>> Looks like http://ipxe.org/ could be what's needed.
> 
> FWIW, a couple of years ago I did write a recipe for ipxe which I successfully
> used for over-the-network booting with atom-pc. I never found a proper home
> for it though so it's still sitting in one of my poky-contrib branches:
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/tree/meta/recipes-bsp/ipxe?h=paule/ipxe
> 
> Feel free to make use of it if it helps you. (I can't promise it hasn't
> bitrotted in the time since I wrote it, so it may need tweaking; I notice
> I didn't even specify a SRCREV which really should be specified, and
> I'm not sure if it's cross-compiling properly either).


I'm running on Cedartrail, so this will probably work nearly as-is. Thanks.

I need to use http rather then tftp, but that looks simple enough to do.

I think I need to add a new image so that a SYSLINUX (or EXTLINUX) USB boot disk image gets created at the same time as the kernel / rootfs. I can do this manually, but it'll probably be worth adding it as another build option (note to self: make it usable as in installer as well). Just need to find a recipe that installs syslinux to see how to do it...

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Network booting

[Rudolf Streif]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

> Is there an easy way to have a system boot and load the rootfs from a
> network server?
>
> The classic way is to serve the root file system from an NFS server. You
will have to pass the root=/dev/nfs and
nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
to your kernel via boot loader.

Every system you want to boot this way will need to have its own root file
system on the NFS server. However, there is the nfsroot project [1] that
reportedly allows booting entire clusters sharing one root file system. I
have not used that though.



> I'm using an x86 system and can have the kernel and an initrd on it. I
> would use bootp, but a lot of end users either don't have this or will not
> allow it to be used. I think it needs to go something like:
>
> 1) Kernel loads the initrd and bring the network up (static or DHCP);
> 2) The rootfs image can then be download;
> 3) Some magic then makes this run...
>
> This looks like you want to start up the system, download a root file
system tarball, extract it to somewhere and then use that as the root file
system by chroot'ing to it.


>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 2566 bytes --]

Re: Network booting

[Chris Tapp]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

Hi Rudolf,

On 31 Jul 2013, at 22:29, Rudolf Streif wrote:

> 
> Is there an easy way to have a system boot and load the rootfs from a network server?
> 
> The classic way is to serve the root file system from an NFS server. You will have to pass the root=/dev/nfs and nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>] to your kernel via boot loader.
> 
> Every system you want to boot this way will need to have its own root file system on the NFS server. However, there is the nfsroot project [1] that reportedly allows booting entire clusters sharing one root file system. I have not used that though.

Ah. I forgot to mention that it has to boot from a Windows server and NFS will not be available. Sorry about that.

> 
> 
>  
> I'm using an x86 system and can have the kernel and an initrd on it. I would use bootp, but a lot of end users either don't have this or will not allow it to be used. I think it needs to go something like:
> 
> 1) Kernel loads the initrd and bring the network up (static or DHCP);
> 2) The rootfs image can then be download;
> 3) Some magic then makes this run...
> 
> This looks like you want to start up the system, download a root file system tarball, extract it to somewhere and then use that as the root file system by chroot'ing to it.
>  
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> 
> 

Chris Tapp

opensource@keylevel.com
www.keylevel.com




[-- Attachment #2: Type: text/html, Size: 4281 bytes --]

Re: Network booting

[Tomas Frydrych]

On 31/07/13 21:30, Chris Tapp wrote:
> Is there an easy way to have a system boot and load the rootfs from a
> network server?
> 
> I'm using an x86 system and can have the kernel and an initrd on it.
> I would use bootp, but a lot of end users either don't have this or
> will not allow it to be used. I think it needs to go something like:
> 
> 1) Kernel loads the initrd and bring the network up (static or
> DHCP); 2) The rootfs image can then be download; 3) Some magic then
> makes this run...
> 
> This would allow easy update of the rootfs and makes it non-volatile
> (which is good for this project).

It's relatively easy to add support for tftp to the yocto live image
scripts; this allows you to either boot from the network, or install
from the network. I have have some raw patches kicking around, that add
support for both tftp and scp, I have been meaning to clean it up and
post an rfc to the list, I'll try to get that done this week.

Tomas

-- 
http://sleepfive.com

Re: Network booting

[Tomas Frydrych]

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

Hi Chris,

On 01/08/13 09:08, Tomas Frydrych wrote:
> On 31/07/13 21:30, Chris Tapp wrote:
> It's relatively easy to add support for tftp to the yocto live image
> scripts; this allows you to either boot from the network, or install
> from the network. I have have some raw patches kicking around, that add
> support for both tftp and scp, I have been meaning to clean it up and
> post an rfc to the list, I'll try to get that done this week.

I am attaching the patches I have, it's a bit raw, and needs more work
before submitting for consideration in oe-core, but I think out of the
box tftp support would be useful to have somewhere.

The patches include changes to the live/install scripts from the oe-core
initramfs recipes and an image recipe for an initrd image with the
necessary tools (I initially started to write separate recipes for the
scripts, but realized quickly that the differences from the standard
live image bits are so small that's hardly justified in comparison to
the increased maintenance burden.)

The main changes to the scripts are:

 * use syslinux instead of grub, makes life lot simpler, 'naf said,
 * rework the install script so that unassisted install is possible,
 * support tfpt for kernel/rootfs loading, and scp for rootfs loading,

The test-ssh-key recipe provides a dummy (i.e., compromised) ssh key
that can be used for rudimentary testing of using scp for kernel
loading; scp is potentially useful for remote system updates from
outside of LAN boundaries, but a real set up would need bit of thought
on how to manage the real keys, etc.

The net-image also generates a sample config file for PXELinux in the
deploy/images directory (net-image.pxelinux.cfg), which documents fairly
well how to set it up. I hope this is of some use, at least to foster
more discussion. :)

Tomas

-- 
http://sleepfive.com

[-- Attachment #2: 0001-test-ssh-key-dummy-ssh-key-for-testing-of-scp-functi.patch --]
[-- Type: text/x-patch, Size: 4434 bytes --]

From 53e082c2b3eed2b1dafc604452d0414b6cdd9478 Mon Sep 17 00:00:00 2001
From: Tomas Frydrych <tomas@sleepfive.com>
Date: Thu, 1 Aug 2013 10:24:19 +0100
Subject: [PATCH 1/4] test-ssh-key: dummy ssh key for testing of scp
 functionality

---
 meta/recipes-support/test-ssh-key/test-ssh-key.bb |   73 +++++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100644 meta/recipes-support/test-ssh-key/test-ssh-key.bb

diff --git a/meta/recipes-support/test-ssh-key/test-ssh-key.bb b/meta/recipes-support/test-ssh-key/test-ssh-key.bb
new file mode 100644
index 0000000..1e8fc86
--- /dev/null
+++ b/meta/recipes-support/test-ssh-key/test-ssh-key.bb
@@ -0,0 +1,73 @@
+DESCRIPTION = "Private ssh key for root user (for testing purposes only!)"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58"
+
+# NB: THIS PACKAGE MUST NOT BE USED ON PRODUCTION IMAGES
+#
+# This package is intended for testing purposes only; it suffers from a number
+# of flaws:
+#
+#    1. The private key is not private and hence already compromized
+#
+#    2. The ssh config file is set up to avoid integrity checks on server keys
+#       -- real set up would need to include a suitably pre-populated
+#       known_hosts file.
+
+inherit allarch
+
+# SSHKEY and SSHKEY_PUB are variables, but are declared as functions so we
+# can use line breaks (a real package would source this from a file)
+
+SSHKEY () {
+-----BEGIN RSA PRIVATE KEY-----
+MIIEowIBAAKCAQEAquOX/60//MR1gHpOjjTBkp4kl9Ry7ig3WY/r9h8nq3ody9zu
+tJmMIpTJKbDy0ZlSeFtE2ZwBrDBceuECH8jvHQC8EH3gj49eSwVOwbQu4A7ZdN0V
+l0Vm2vgG0Xvs3o2HzONm6NWYCrj2UfCeIeYrDFBuFpvCZSYxvw/qz9G8oSmi2brJ
+/Oqqz1BeAqgWraDwprdkQ7GHSNfkPdSZW+b1F/Gr2TTDU4N6IGGSgrMUxZZsf1kC
+D10qv73WyU3WODW5oycxw0kS7AisQis9A9n2XispYDfJuN3Fp6WcWI5GgILjqSWG
+g/rtvWU8EpK/nNJGei+cHXcFa8odzCVOqNO8lwIDAQABAoIBAQCiHgoL33Mtu77x
+JJazp+7fxjFW7JAfyX1A9R1YP5QlxFLSHQVDxctA3z+70od5OmgXkBZQDwUzMin5
+1M5sEvZs4E6JorFP4CYHK8DcWLCDlPLNQBQEjy2Vm+j0AQnk1AW55R2y0zdLLM9Z
+Stjpte6u3vqhbiDMTqCw7kvH3eSCSm2yV8e7ydFpRZxMjMcSNovjqq+hqSLKcLGL
+F4WoYotA5vomGT4D1YWWzD03QgElVnGT+VrOt0PtC5QHWvlsmkuZWeJukNOFLip7
++DH6/9fbTskO43O7p3tC1Lq1TkqUrXTJfUrVr5qjw6Nl07lO/gC/qFULA0FjUf8F
+Ayt7Ax35AoGBANR0+1FEvBBt5R16sdsbUdqLHMAq2efE0UdHSvyrIboj1frI+Xgn
+iN4p3rrJdWeKBJL4YH4XeOT/XYAmmfvffhEeiF1zB1Wy5/63TABXDf/uvh3GyO8P
+iL1ev0rswU56yqcQrX/j7SfOUtZwVyYnqblfemG/6v45uxdLyegDM8gNAoGBAM3p
+qQbJ8FDvgL9WoiRFN75bpV2wkx8ukHGfZt6I1nFvXreAwAa6zD5zxHjdn2R+sQUV
+wlqvgDjFjdp6xDiXMrsV47RSjJiByo15d+6jdXhZ8jrXXOYrZ4qDXE/wSnSei9bl
+iE82paKTNEeT7pz5psNf/DlRcb10ykX8Urgag+ozAoGAV5LYvQj+FC+YT2xxv4Ul
+WlYZRcTkCTsBoMXsTPYlctquqy8IVdTF//12R7we3szvUb172L3IIWx5mAdRVZcs
+GdZiE1ME5PhX1JCtjT5VEPfR+egkjxXyIUzawQGSNM08l1yyh5LmAJB1aNrpsVqM
+BVMr2PsI3D3jtpiQ40feokkCgYAuzV1N3bhxrP5mfxp7hAAXlF0R3oCSJdNPABwx
+mIilX9r3epwq62phB48wqa8A+IrjzP5P/nP2c3C6qAzRkAxH2cHXyquKPnX7khBg
+fWbF5Cvak/jZmCQAp7rjsIo7142RWrqQxqr/ONY5Lradl2EAJ2D85jYkCdev8Joc
+nmo9YQKBgG3EjvO1yJ0JxuImSNGq4W/2e8cXPMW/XTenQztPALU5mAAvxSCp7pi2
+zNmv60E3QHbdB4arglV73oCdGVpgFAamQbzvmVe9UptYs/iFVGIfktqlFqI7DelM
+4NmUlKy0OYMGvQ348Sg6trWQnaiw+F2I/Xtuw2cHRgv3N7346j2Q
+-----END RSA PRIVATE KEY-----
+}
+
+SSHKEY_PUB () {
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCq45f/rT/8xHWAek6ONMGSniSX1HLuKDdZj+v2Hyereh3L3O60mYwilMkpsPLRmVJ4W0TZnAGsMFx64QIfyO8dALwQfeCPj15LBU7BtC7gDtl03RWXRWba+AbRe+zejYfM42bo1ZgKuPZR8J4h5isMUG4Wm8JlJjG/D+rP0byhKaLZusn86qrPUF4CqBatoPCmt2RDsYdI1+Q91Jlb5vUX8avZNMNTg3ogYZKCsxTFlmx/WQIPXSq/vdbJTdY4NbmjJzHDSRLsCKxCKz0D2fZeKylgN8m43cWnpZxYjkaAguOpJYaD+u29ZTwSkr+c0kZ6L5wddwVryh3MJU6o07yX neftest@i7-990x
+}
+
+do_install () {
+    install -m 0700 -d ${D}/home/root/.ssh
+
+    echo "${SSHKEY}" > ${D}/home/root/.ssh/id_rsa
+    chmod 0700 ${D}/home/root/.ssh/id_rsa
+
+    echo "${SSHKEY_PUB}" > ${D}/home/root/.ssh/id_rsa.pub
+    chmod 0700 ${D}/home/root/.ssh/id_rsa.pub
+
+    echo "IdentityFile ~/.ssh/id_rsa" > ${D}/home/root/.ssh/config
+    echo "PreferredAuthentications publickey" >> ${D}/home/root/.ssh/config
+    echo "VisualHostKey no" >> ${D}/home/root/.ssh/config
+    echo "PreferredAuthentications publickey" >> ${D}/home/root/.ssh/config
+    echo "UserKnownHostsFile=/dev/null" >> ${D}/home/root/.ssh/config
+    echo "StrictHostKeyChecking=no" >> ${D}/home/root/.ssh/config
+    chmod 0700 ${D}/home/root/.ssh/config
+}
+
+FILES_${PN} = "/home/*"
-- 
1.7.10.4


[-- Attachment #3: 0002-initramfs-live-install-improve-install-script-for-un.patch --]
[-- Type: text/x-patch, Size: 8196 bytes --]

From bc0caeac7cfae173e98fa69c5217a9738b9284cb Mon Sep 17 00:00:00 2001
From: Tomas Frydrych <tomas@sleepfive.com>
Date: Thu, 1 Aug 2013 10:34:06 +0100
Subject: [PATCH 2/4] initramfs-live-install: improve install script for
 unassisted tftp installs

This commit also modifies the script to use syslinux instead of grub
---
 .../initrdscripts/files/init-install.sh            |  194 ++++++++++++--------
 .../initrdscripts/initramfs-live-install_1.0.bb    |    4 +-
 2 files changed, 119 insertions(+), 79 deletions(-)

diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh b/meta/recipes-core/initrdscripts/files/init-install.sh
index d2a0db3..8054173 100644
--- a/meta/recipes-core/initrdscripts/files/init-install.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install.sh
@@ -1,6 +1,7 @@
 #!/bin/sh -e
 #
 # Copyright (C) 2008-2011 Intel
+# Copyright (C) 2013 sleep(5) ltd
 #
 # install.sh [device_name] [rootfs_name] [video_mode] [vga_mode]
 #
@@ -13,43 +14,80 @@ boot_size=20
 # 5% for the swap
 swap_ratio=5
 
-found="no"
-
-echo "Searching for a hard drive..."
-for device in 'hda' 'hdb' 'sda' 'sdb' 'mmcblk0' 'mmcblk1'
-  do
-  if [ -e /sys/block/${device}/removable ]; then
-      if [ "$(cat /sys/block/${device}/removable)" = "0" ]; then
-	  found="yes"
-
-	  while true; do
+# parse current cmdline, strip out things we do not want, then append
+# the rest
+read_args() {
+    [ -z "$CMDLINE" ] && CMDLINE=`cat /proc/cmdline`
+    for arg in $CMDLINE; do
+        optarg=`expr "x$arg" : 'x[^=]*=\(.*\)' || :`
+        case $arg in
+            root=*) ;;
+            rootfstype=*) ;;
+            LABEL=*) ;;
+	    initrd=*) ;;
+	    ramdisk_size=*) ;;
+	    ip=*) ;;
+	    tftp_*) ;;
+	    ro) ;;
+	    BOOT_IMAGE=*) ;;
+	    unassisted)
+	        unassisted=yes ;;
+	    install_dev=*)
+	        install_dev=$optarg
+		unassisted=yes ;;
+	    *) append="$append $arg" ;;
+        esac
+    done
+}
+
+append=
+unassisted=
+install_dev=
+read_args
+
+if [ "x$install_dev" = "x" ] ; then
+    found="no"
+
+    echo "Searching for a hard drive..."
+    for device in 'hda' 'hdb' 'sda' 'sdb' 'mmcblk0' 'mmcblk1'
+    do
+	if [ -e /sys/block/${device}/removable ]; then
+	    if [ "$(cat /sys/block/${device}/removable)" = "0" ]; then
+		found="yes"
+
+		if [ "x$unassisted" != "xyes" ] ; then
+		    while true; do
 	      # Try sleeping here to avoid getting kernel messages
               # obscuring/confusing user
-	      sleep 5
-	      echo "Found drive at /dev/${device}. Do you want to install this image there ? [y/n]"
-	      read answer
-	      if [ "$answer" = "y" ] ; then
-		  break
-	      fi
-	  
-	      if [ "$answer" = "n" ] ; then
-		  found=no
-		  break
-	      fi
-
-	      echo "Please answer by y or n"
-	  done
-      fi
-  fi
-
-  if [ "$found" = "yes" ]; then
-      break;
-  fi
-
-done
-
-if [ "$found" = "no" ]; then
-      exit 1      
+			sleep 5
+			echo "Found drive at /dev/${device}. Do you want to install this image there ? [y/n]"
+			read answer
+			if [ "$answer" = "y" ] ; then
+			    break
+			fi
+
+			if [ "$answer" = "n" ] ; then
+			    found=no
+			    break
+			fi
+
+			echo "Please answer by y or n"
+		    done
+		fi
+	    fi
+	fi
+
+	if [ "$found" = "yes" ]; then
+	    break;
+	fi
+
+    done
+
+    if [ "$found" = "no" ]; then
+	exit 1
+    fi
+else
+    device=$install_dev
 fi
 
 echo "Installing image on /dev/${device}"
@@ -80,6 +118,28 @@ fi
 mkdir -p /tmp
 cat /proc/mounts > /etc/mtab
 
+mkdir /rootmnt
+mount -o rw,loop,noatime,nodiratime /media/$1/$2 /rootmnt
+
+# check we have kernel in the image /boot directory before we do anything
+# else
+KERNEL_NAME=
+for k in `ls /rootmnt/boot/`; do
+    case $k in
+	bzImage|vmlinuz|zImage)
+	    KERNEL_NAME=$k ;;
+	bzImage*|vmlinuz*|zImage*)
+	    KERNEL_NAME=$k ;;
+    esac
+done
+
+if [ "x$KERNEL_NAME" != "x" ] ; then
+    echo "Using kernel $KERNEL_NAME"
+else
+    echo "Failed to locate kernel"
+    exit 1
+fi
+
 disk_size=$(parted /dev/${device} unit mb print | grep Disk | cut -d" " -f 3 | sed -e "s/MB//")
 
 swap_size=$((disk_size*swap_ratio/100))
@@ -115,6 +175,7 @@ parted /dev/${device} mklabel msdos
 
 echo "Creating boot partition on $bootfs"
 parted /dev/${device} mkpart primary 0% $boot_size
+parted /dev/${device} "set"  1 boot on
 
 echo "Creating rootfs partition on $rootfs"
 parted /dev/${device} mkpart primary $rootfs_start $rootfs_end
@@ -124,8 +185,8 @@ parted /dev/${device} mkpart primary $swap_start 100%
 
 parted /dev/${device} print
 
-echo "Formatting $bootfs to ext3..."
-mkfs.ext3 $bootfs
+echo "Formatting $bootfs to FAT16..."
+mkfs.msdos -F 16 $bootfs
 
 echo "Formatting $rootfs to ext3..."
 mkfs.ext3 $rootfs
@@ -134,11 +195,10 @@ echo "Formatting swap partition...($swap)"
 mkswap $swap
 
 mkdir /ssd
-mkdir /rootmnt
 mkdir /bootmnt
 
 mount $rootfs /ssd
-mount -o rw,loop,noatime,nodiratime /media/$1/$2 /rootmnt
+mount $bootfs /bootmnt
 
 echo "Copying rootfs files..."
 cp -a /rootmnt/* /ssd
@@ -152,49 +212,29 @@ if [ -d /ssd/etc/ ] ; then
     fi
 fi
 
-if [ -f /etc/grub.d/40_custom ] ; then
-    echo "Preparing custom grub2 menu..."
-    GRUBCFG="/bootmnt/boot/grub/grub.cfg"
-    mount $bootfs /bootmnt
-    mkdir -p $(dirname $GRUBCFG)
-    cp /etc/grub.d/40_custom $GRUBCFG
-    sed -i "s@__ROOTFS__@$rootfs $rootwait@g" $GRUBCFG
-    sed -i "s/__VIDEO_MODE__/$3/g" $GRUBCFG
-    sed -i "s/__VGA_MODE__/$4/g" $GRUBCFG
-    sed -i "s/__CONSOLE__/$5/g" $GRUBCFG
-    sed -i "/#/d" $GRUBCFG
-    sed -i "/exec tail/d" $GRUBCFG
-    chmod 0444 $GRUBCFG
-    umount /bootmnt
-fi
-
 umount /ssd
-umount /rootmnt
 
 echo "Preparing boot partition..."
-mount $bootfs /ssd
-grub-install --root-directory=/ssd /dev/${device}
-
-echo "(hd0) /dev/${device}" > /ssd/boot/grub/device.map
-
-# If grub.cfg doesn't exist, assume GRUB 0.97 and create a menu.lst
-if [ ! -f /ssd/boot/grub/grub.cfg ] ; then
-    echo "Preparing custom grub menu..."
-    echo "default 0" > /ssd/boot/grub/menu.lst
-    echo "timeout 30" >> /ssd/boot/grub/menu.lst
-    echo "title Live Boot/Install-Image" >> /ssd/boot/grub/menu.lst
-    echo "root  (hd0,0)" >> /ssd/boot/grub/menu.lst
-    echo "kernel /boot/vmlinuz root=$rootfs rw $3 $4 quiet" >> /ssd/boot/grub/menu.lst
-fi
-
-cp /media/$1/vmlinuz /ssd/boot/
-
-umount /ssd
+syslinux -i ${bootfs}
+dd bs=440 count=1 if=/usr/lib/syslinux/mbr.bin of=/dev/${device}
+
+echo "Preparing syslinux menu..."
+echo "ALLOWOPTIONS 1" > /bootmnt/syslinux.cfg
+echo "DEFAULT default" >> /bootmnt/syslinux.cfg
+echo "TIMEOUT 10" >> /bootmnt/syslinux.cfg
+echo "PROMPT 1" >> /bootmnt/syslinux.cfg
+echo "LABEL default" >> /bootmnt/syslinux.cfg
+echo "KERNEL /vmlinuz" >> /bootmnt/syslinux.cfg
+echo "APPEND root=$rootfs rw $3 $4 $append" >> /bootmnt/syslinux.cfg
+
+cp /rootmnt/boot/$KERNEL_NAME /bootmnt/vmlinuz
+umount /bootmnt
 sync
 
-echo "Remove your installation media, and press ENTER"
-
-read enter
+if [ "x$1" != "xtftp" ] ; then
+    echo "Remove your installation media, and press ENTER"
+    read enter
+fi
 
 echo "Rebooting..."
 reboot -f
diff --git a/meta/recipes-core/initrdscripts/initramfs-live-install_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-live-install_1.0.bb
index 3a8836d..6ba3bcf 100644
--- a/meta/recipes-core/initrdscripts/initramfs-live-install_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-live-install_1.0.bb
@@ -5,13 +5,13 @@ SRC_URI = "file://init-install.sh"
 
 PR = "r9"
 
-RDEPENDS_${PN} = "grub parted e2fsprogs-mke2fs"
+RDEPENDS_${PN} = "syslinux syslinux-mbr parted e2fsprogs-mke2fs"
 
 do_install() {
         install -m 0755 ${WORKDIR}/init-install.sh ${D}/install.sh
 }
 
-# While this package maybe an allarch due to it being a 
+# While this package maybe an allarch due to it being a
 # simple script, reality is that it is Host specific based
 # on the COMPATIBLE_HOST below, which needs to take precedence
 #inherit allarch
-- 
1.7.10.4


[-- Attachment #4: 0003-initramfs-live-boot-improve-script-to-support-tftp-b.patch --]
[-- Type: text/x-patch, Size: 9327 bytes --]

From bdd17fc507135d6c35c674cf1feb8e2e8ad92b98 Mon Sep 17 00:00:00 2001
From: Tomas Frydrych <tomas@sleepfive.com>
Date: Thu, 1 Aug 2013 10:35:34 +0100
Subject: [PATCH 3/4] initramfs-live-boot: improve script to support tftp
 booting

---
 meta/recipes-core/initrdscripts/files/init-live.sh |  240 ++++++++++++--------
 1 file changed, 147 insertions(+), 93 deletions(-)

diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh b/meta/recipes-core/initrdscripts/files/init-live.sh
index 890c562..45a5ebf 100644
--- a/meta/recipes-core/initrdscripts/files/init-live.sh
+++ b/meta/recipes-core/initrdscripts/files/init-live.sh
@@ -7,6 +7,8 @@ ROOT_IMAGE="rootfs.img"
 MOUNT="/bin/mount"
 UMOUNT="/bin/umount"
 ISOLINUX=""
+UNIONFS="no"
+SCP=`which scp`
 
 # Copied from initramfs-framework. The core of this script probably should be
 # turned into initramfs-framework modules to reduce duplication.
@@ -45,7 +47,7 @@ early_setup() {
 read_args() {
     [ -z "$CMDLINE" ] && CMDLINE=`cat /proc/cmdline`
     for arg in $CMDLINE; do
-        optarg=`expr "x$arg" : 'x[^=]*=\(.*\)'`
+        optarg=`expr "x$arg" : 'x[^=]*=\(.*\)' || :`
         case $arg in
             root=*)
                 ROOT_DEVICE=$optarg ;;
@@ -68,26 +70,39 @@ read_args() {
                         shelltimeout=30
                 else
                         shelltimeout=$optarg
-                fi 
+                fi ;;
+            BOOT_IMAGE=*)
+                bootimg=$optarg ;;
+            tftp_server=*)
+                tftp_server=$optarg ;;
+            tftp_rootimg=*)
+                tftp_rootimg=$optarg
+		ROOT_IMAGE=`basename $tftp_rootimg`;;
+            tftp_bootimg=*)
+                tftp_bootimg=$optarg ;;
+            tftp_protocol=*)
+                tftp_protocol=$optarg ;;
         esac
     done
+
+    if [ "x$tftp_bootimg" = "x" ] ; then
+	tftp_bootimg=$bootimg
+    fi
 }
 
 boot_live_root() {
-    # Watches the udev event queue, and exits if all current events are handled
-    udevadm settle --timeout=3 --quiet
-    killall "${_UDEV_DAEMON##*/}" 2>/dev/null
+    killall udevd 2>/dev/null
 
     # Move the mount points of some filesystems over to
     # the corresponding directories under the real root filesystem.
-    for dir in `awk '/\/dev.* \/media/{print $2}' /proc/mounts`; do
-        mkdir -p  ${ROOT_MOUNT}/$dir
-        mount -n --move $dir ${ROOT_MOUNT}/$dir
-    done
     mount -n --move /proc ${ROOT_MOUNT}/proc
     mount -n --move /sys ${ROOT_MOUNT}/sys
     mount -n --move /dev ${ROOT_MOUNT}/dev
 
+    if [ "x$tftp_rootimg" = "x" ] ; then
+        # Move /media/$i over to the real root filesystem
+	mount -n --move /media/$i ${ROOT_MOUNT}/media/realroot
+    fi
     cd $ROOT_MOUNT
     exec switch_root -c /dev/console $ROOT_MOUNT /sbin/init
 }
@@ -98,112 +113,151 @@ fatal() {
     exec sh
 }
 
-early_setup
+# server, what, whereto
+fetch_tftp ()
+{
+    if [ "x$tftp_protocol" = "xssh" ] ; then
+	if ! $SCP $1:$2 $3 ; then
+	    fatal "Failed to scp $2 from $1"
+	fi
+    else
+	if ! tftp -g -r $2 -l $3 $1 ; then
+	    fatal "Failed to tftp $2 from $1"
+	fi
+    fi
+}
+install_tftp() {
+    mkdir -p /media/tftp
 
-[ -z "$CONSOLE" ] && CONSOLE="/dev/console"
+    echo "Downloading root image to install"
+    fetch_tftp $tftp_server $tftp_rootimg /media/tftp/$ROOT_IMAGE
 
-read_args
+    ./$label.sh tftp $ROOT_IMAGE $video_mode $vga_mode $console_params
+}
+
+boot_tftp() {
+    mkdir $ROOT_MOUNT
+    mknod /dev/loop0 b 7 0 2>/dev/null
+
+    echo "Downloading root image"
+    fetch_tftp $tftp_server $tftp_rootimg $ROOT_IMAGE
+
+    if [ "$UNIONFS" = "yes" ]; then
+	mkdir /rootfs-tmp
 
-echo "Waiting for removable media..."
-C=0
-while true
-do
-  for i in `ls /media 2>/dev/null`; do
-      if [ -f /media/$i/$ROOT_IMAGE ] ; then
+	if ! $MOUNT -o rw,loop,noatime,nodiratime /$ROOT_IMAGE /rootfs-tmp ; then
+	    fatal "Could not mount rootfs image"
+	else
+	    mkdir /cow
+	    mount -t tmpfs -o rw,noatime,mode=755 tmpfs /cow
+	    mount -t unionfs -o dirs=/cow:/rootfs-tmp=ro unionfs $ROOT_MOUNT
+	    boot_live_root
+	fi
+    else
+	if ! $MOUNT -o rw,loop,noatime,nodiratime /$ROOT_IMAGE $ROOT_MOUNT ; then
+	    fatal "Could not mount rootfs image"
+	else
+	    boot_live_root
+	fi
+    fi
+}
+
+wait_for_removables() {
+    echo "Waiting for removable media..."
+    C=0
+    while true
+    do
+	for i in `ls /media 2>/dev/null`; do
+	    if [ -f /media/$i/$ROOT_IMAGE ] ; then
 		found="yes"
 		break
-	  elif [ -f /media/$i/isolinux/$ROOT_IMAGE ]; then
+	    elif [ -f /media/$i/isolinux/$ROOT_IMAGE ]; then
 		found="yes"
 		ISOLINUX="isolinux"
-		break	
-      fi
-  done
-  if [ "$found" = "yes" ]; then
-      break;
-  fi
+		break
+	    fi
+	done
+	if [ "$found" = "yes" ]; then
+	    break;
+	fi
   # don't wait for more than $shelltimeout seconds, if it's set
-  if [ -n "$shelltimeout" ]; then
-      echo -n " " $(( $shelltimeout - $C ))
-      if [ $C -ge $shelltimeout ]; then
-           echo "..."
-	   echo "Mounted filesystems"
-           mount | grep media
-           echo "Available block devices"
-           ls /dev/sd*
-           fatal "Cannot find rootfs.img file in /media/* , dropping to a shell "
-      fi
-      C=$(( C + 1 ))
-  fi
-  sleep 1
-done
-
-# Try to make a union mount of the root image.
-# If no unification filesystem is available, mount the image read-only.
-mount_and_boot() {
+	if [ -n "$shelltimeout" ]; then
+	    echo -n " " $(( $shelltimeout - $C ))
+	    if [ $C -ge $shelltimeout ]; then
+		echo "..."
+		echo "Mounted filesystems"
+		mount | grep media
+		echo "Available block devices"
+		ls /dev/sd*
+		fatal "Cannot find rootfs.img file in /media/* , dropping to a shell "
+	    fi
+	    C=$(( C + 1 ))
+	fi
+	sleep 1
+    done
+}
+
+boot_normal() {
+    wait_for_removables
+
     mkdir $ROOT_MOUNT
     mknod /dev/loop0 b 7 0 2>/dev/null
 
-    # determine which unification filesystem to use
-    union_fs_type=""
-    if grep -q -w "overlayfs" /proc/filesystems; then
-	union_fs_type="overlayfs"
-    elif grep -q -w "aufs" /proc/filesystems; then
-	union_fs_type="aufs"
+    if [ "$UNIONFS" = "yes" ]; then
+	mkdir /rootfs-tmp
+
+	if ! $MOUNT -o rw,loop,noatime,nodiratime /media/$i/$ISOLINUX/$ROOT_IMAGE /rootfs-tmp ; then
+	    fatal "Could not mount rootfs image"
+	else
+	    mkdir /cow
+	    mount -t tmpfs -o rw,noatime,mode=755 tmpfs /cow
+	    mount -t unionfs -o dirs=/cow:/rootfs-tmp=ro unionfs $ROOT_MOUNT
+	    boot_live_root
+	fi
     else
-	union_fs_type=""
+	if ! $MOUNT -o rw,loop,noatime,nodiratime /media/$i/$ISOLINUX/$ROOT_IMAGE $ROOT_MOUNT ; then
+	    fatal "Could not mount rootfs image"
+	else
+	    boot_live_root
+	fi
     fi
+}
 
-    # make a union mount if possible
-    case $union_fs_type in
-	"overlayfs")
-	    mkdir -p /rootfs.ro /rootfs.rw
-	    if ! mount -o rw,loop,noatime,nodiratime /media/$i/$ISOLINUX/$ROOT_IMAGE /rootfs.ro; then
-		rm -rf /rootfs.ro /rootfs.rw
-		fatal "Could not mount rootfs image"
-	    else
-		mount -t tmpfs -o rw,noatime,mode=755 tmpfs /rootfs.rw
-		mount -t overlayfs -o "lowerdir=/rootfs.ro,upperdir=/rootfs.rw" overlayfs $ROOT_MOUNT
-		mkdir -p $ROOT_MOUNT/rootfs.ro $ROOT_MOUNT/rootfs.rw
-		mount --move /rootfs.ro $ROOT_MOUNT/rootfs.ro
-		mount --move /rootfs.rw $ROOT_MOUNT/rootfs.rw
-	    fi
-	    ;;
-	"aufs")
-	    mkdir -p /rootfs.ro /rootfs.rw
-	    if ! mount -o rw,loop,noatime,nodiratime /media/$i/$ISOLINUX/$ROOT_IMAGE /rootfs.ro; then
-		rm -rf /rootfs.ro /rootfs.rw
-		fatal "Could not mount rootfs image"
-	    else
-		mount -t tmpfs -o rw,noatime,mode=755 tmpfs /rootfs.rw
-		mount -t aufs -o "dirs=/rootfs.rw=rw:/rootfs.ro=ro" aufs $ROOT_MOUNT
-		mkdir -p $ROOT_MOUNT/rootfs.ro $ROOT_MOUNT/rootfs.rw
-		mount --move /rootfs.ro $ROOT_MOUNT/rootfs.ro
-		mount --move /rootfs.rw $ROOT_MOUNT/rootfs.rw
-	    fi
-	    ;;
-	"")
-	    if ! mount -o rw,loop,noatime,nodiratime /media/$i/$ISOLINUX/$ROOT_IMAGE $ROOT_MOUNT ; then
-		fatal "Could not mount rootfs image"
-	    fi
-	    ;;
-    esac
-
-    # boot the image
-    boot_live_root
+install_normal() {
+    if [ -f /media/$i/$ISOLINUX/$ROOT_IMAGE ] ; then
+	./$label.sh $i/$ISOLINUX $ROOT_IMAGE $video_mode $vga_mode $console_params
+    else
+	fatal "Could not find $label script"
+    fi
 }
 
+early_setup
+
+[ -z "$CONSOLE" ] && CONSOLE="/dev/console"
+
+tftp_protocol=tftp
+read_args
+
+if [ "x$tftp_protocol" = "xssh" -a "x$SCP" = "x" ] ; then
+    fatal "ssh protocol is not supported"
+fi
+
 case $label in
-    boot)
-	mount_and_boot
-	;;
     install|install-efi)
-	if [ -f /media/$i/$ISOLINUX/$ROOT_IMAGE ] ; then
-	    ./$label.sh $i/$ISOLINUX $ROOT_IMAGE $video_mode $vga_mode $console_params
+	if [ "x$tftp_rootimg" = "x" ] ; then
+	    install_normal
 	else
-	    fatal "Could not find $label script"
+	    install_tftp
 	fi
 
 	# If we're getting here, we failed...
 	fatal "Installation image failed"
 	;;
+    *)
+	if [ "x$tftp_rootimg" = "x" ] ; then
+	    boot_normal
+	else
+	    boot_tftp
+	fi
+	;;
 esac
-- 
1.7.10.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0004-net-image-initrd-image-for-tfpt-booting.patch --]
[-- Type: text/x-patch; name="0004-net-image-initrd-image-for-tfpt-booting.patch", Size: 5463 bytes --]

From eb212f41a4b2aa0baaf90baf01f9a5365153a57c Mon Sep 17 00:00:00 2001
From: Tomas Frydrych <tomas@sleepfive.com>
Date: Thu, 1 Aug 2013 13:57:35 +0100
Subject: [PATCH 4/4] net-image: initrd image for tfpt booting

---
 meta/recipes-core/images/net-image.bb |  121 +++++++++++++++++++++++++++++++++
 1 file changed, 121 insertions(+)
 create mode 100644 meta/recipes-core/images/net-image.bb

diff --git a/meta/recipes-core/images/net-image.bb b/meta/recipes-core/images/net-image.bb
new file mode 100644
index 0000000..3e78321
--- /dev/null
+++ b/meta/recipes-core/images/net-image.bb
@@ -0,0 +1,121 @@
+# Simple initramfs image. Mostly used for live images.
+DESCRIPTION = "Small image capable of booting a device. The kernel includes \
+the Minimal RAM-based Initial Root Filesystem (initramfs), which finds the \
+first “init” program more efficiently."
+
+INITRAMFS_SSHKEY ?= "test-ssh-key"
+
+IMAGE_INSTALL = "				\
+		 initramfs-live-boot		\
+		 initramfs-live-install		\
+		 initramfs-live-install-efi	\
+		 busybox			\
+		 udev				\
+		 base-passwd			\
+		 init-ifupdown			\
+		 openssh-ssh			\
+		 openssh-scp			\
+		 ${INITRAMFS_SSHKEY}		\
+		"
+
+# Do not pollute the initrd image with rootfs features
+IMAGE_FEATURES = ""
+
+export IMAGE_BASENAME = "net-image"
+IMAGE_LINGUAS = ""
+
+LICENSE = "MIT"
+
+IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
+inherit core-image
+
+IMAGE_ROOTFS_SIZE = "8192"
+
+BAD_RECOMMENDATIONS += "busybox-syslog"
+
+python __anonymous() {
+    if d.getVar('INITRAMFS_SSHKEY', True) == 'test-ssh-key':
+        bb.warn('Package test-ssh-key is being used; the ssh key contained in this package should be considered compromized and should not be used in production.')
+}
+
+CM="#"
+
+create_pxe_config () {
+  cfg="${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.pxelinux.cfg"
+
+  cat >> $cfg << EOF
+${CM}
+${CM} Sample PXELinux configuration
+${CM}
+${CM} General notes
+${CM} <tftpboot>: in the examples below this is the directory on your remote
+${CM} server where the file(s) reside.
+${CM}
+${CM} Kernel images: Yocto generates the kernel images with a .bin suffix, but
+${CM} please note that PXELinux will interpret this as a CD boot sector rather
+${CM} than Linux kernel, so either rename these, or use the 'linux' keyword
+${CM} instead of 'kernel'.
+${CM}
+${CM} Parameters:
+${CM}   tftp_protocol: tftp or ssh; tftp is the default, using ssh
+${CM}   requires for the initrd image to contain appropriate ssh key. Also note
+${CM}   that the ssh protocol is only used to load the disk image, the kernel
+${CM}   and initrd can only be loaded from a tftp server.
+${CM}
+${CM}   tftp_server: the address of the remote server; when using ssh
+${CM}   this should be in the 'user@address' form.
+${CM}
+${CM}   tftp_rootimg: the disk image to fetch from the server.
+${CM}
+${CM}   ramdisk_size: the ramdisk has to be big enough to hold both the initrd
+${CM}   filesystem and the rootimg file.
+${CM}
+${CM}   LABEL: this is used by Yocto to decide if the system should boot or
+${CM}   switch over into install mode; for the latter the label has to be either
+${CM}   'install' or 'install-efi' (however, install-efi mode is currently not
+${CM}   supported by net images).
+${CM}
+
+
+${CM}
+${CM} Sample configurations
+${CM}
+
+${CM} Boot system, loading disk image from a tftp server
+LABEL boot
+        linux <tftpboot>/vmlinuz-${MACHINE}
+	append initrd=<tftpboot>/${INITRD_IMAGE}-${MACHINE}.cpio.gz root=/dev/ram0 ramdisk_size=65536 ip=dhcp tftp_server=<yourserveraddress> tftp_rootimg=<tftpboot>/${IMAGE_BASENAME}.ext3 quiet LABEL=boot
+
+${CM} Boot system, loading disk image using ssh protocol
+LABEL boot-ssh
+        linux <tftpboot>/vmlinuz-${MACHINE}
+	append initrd=<tftpboot>/${INITRD_IMAGE}-${MACHINE}.cpio.gz root=/dev/ram0 ramdisk_size=65536 ip=dhcp tftp_server=<user@yourserveraddress> tftp_rootimg=<tftpboot>/${IMAGE_BASENAME}.ext3 tftp_protocol=ssh quiet LABEL=boot
+
+${CM} Boot system, download disk image from a tftp server and then install it
+${CM} on /dev/sda. If install_dev is not specified and 'unassisted' option is
+${CM} given instead, the first available disk will be used; if unassisted is not
+${CM} given, the user will be prompted on the console
+${CM}
+${CM} NB: the LABEL argument must be given and must be 'install', otherwise the
+${CM}     the system will just boot
+LABEL install
+        linux <tftpboot>/vmlinuz-${MACHINE}
+	append initrd=<tftpboot>/${INITRD_IMAGE}-${MACHINE}.cpio.gz root=/dev/ram0 ramdisk_size=65536 ip=dhcp tftp_server=<yourserveraddress> tftp_rootimg=<tftpboot>/${IMAGE_BASENAME}.ext3 quiet LABEL=install install_dev=sda
+
+${CM} As above, but use ssh instead of tftp
+${CM}
+${CM} NB: the LABEL argument must be given and must be 'install', otherwise the
+${CM}     system will just boot
+LABEL install-ssh
+        linux <tftpboot>/vmlinuz-${MACHINE}
+	append initrd=<tftpboot>/${INITRD_IMAGE}-${MACHINE}.cpio.gz root=/dev/ram0 ramdisk_size=65536 ip=dhcp tftp_server=<yourserveraddress> tftp_rootimg=<tftpboot>/${IMAGE_BASENAME}.ext3 quiet tftp_protocol=ssh LABEL=install install_dev=sda
+EOF
+
+    ln -sf $cfg ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.pxelinux.cfg
+}
+
+python do_pxeconfig () {
+        bb.build.exec_func('create_pxe_config', d)
+}
+
+addtask pxeconfig after do_rootfs before do_build
-- 
1.7.10.4

Re: Network booting

[Chris Tapp]

Hi Tomas,

On 1 Aug 2013, at 15:06, Tomas Frydrych wrote:

> Hi Chris,
> 
> On 01/08/13 09:08, Tomas Frydrych wrote:
>> On 31/07/13 21:30, Chris Tapp wrote:
>> It's relatively easy to add support for tftp to the yocto live image
>> scripts; this allows you to either boot from the network, or install
>> from the network. I have have some raw patches kicking around, that add
>> support for both tftp and scp, I have been meaning to clean it up and
>> post an rfc to the list, I'll try to get that done this week.
> 
> I am attaching the patches I have, it's a bit raw, and needs more work
> before submitting for consideration in oe-core, but I think out of the
> box tftp support would be useful to have somewhere.
> 
> The patches include changes to the live/install scripts from the oe-core
> initramfs recipes and an image recipe for an initrd image with the
> necessary tools (I initially started to write separate recipes for the
> scripts, but realized quickly that the differences from the standard
> live image bits are so small that's hardly justified in comparison to
> the increased maintenance burden.)
> 
> The main changes to the scripts are:
> 
> * use syslinux instead of grub, makes life lot simpler, 'naf said,
> * rework the install script so that unassisted install is possible,
> * support tfpt for kernel/rootfs loading, and scp for rootfs loading,

Thanks, these look very useful.

> The test-ssh-key recipe provides a dummy (i.e., compromised) ssh key
> that can be used for rudimentary testing of using scp for kernel
> loading; scp is potentially useful for remote system updates from
> outside of LAN boundaries, but a real set up would need bit of thought
> on how to manage the real keys, etc.
> 
> The net-image also generates a sample config file for PXELinux in the
> deploy/images directory (net-image.pxelinux.cfg), which documents fairly
> well how to set it up. I hope this is of some use, at least to foster
> more discussion. :)

I think it is ;-) I think I'll still need to use ipxe as I need to be able to boot without DHCP support as well.

> Tomas
> 
> -- 
> http://sleepfive.com
> <0001-test-ssh-key-dummy-ssh-key-for-testing-of-scp-functi.patch><0002-initramfs-live-install-improve-install-script-for-un.patch><0003-initramfs-live-boot-improve-script-to-support-tftp-b.patch><0004-net-image-initrd-image-for-tfpt-booting.patch>_______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Network booting

[Tomas Frydrych]

On 01/08/13 19:53, Chris Tapp wrote:
> I think it is ;-) I think I'll still need to use ipxe as I need to be
> able to boot without DHCP support as well.

Depends on the bios, if your machine's bios supports PXE, then you do
not need ipxe, just a tftp server set up on the LAN that serves PXELinux.

I am wondering if having a thin meta-pxe layer would be useful to pull
some of this together both code and people interested, or whether we
should aim adding this functionality to OE-core?

Tomas


-- 
http://sleepfive.com

Re: Network booting

[Chris Tapp]

Hi Thomas,

On 2 Aug 2013, at 08:22, Tomas Frydrych wrote:

> On 01/08/13 19:53, Chris Tapp wrote:
>> I think it is ;-) I think I'll still need to use ipxe as I need to be
>> able to boot without DHCP support as well.
> 
> Depends on the bios, if your machine's bios supports PXE, then you do
> not need ipxe, just a tftp server set up on the LAN that serves PXELinux.

My case is a bit more complicated as I also can't have non-secure (t)ftp! Are you saying that PXE can work without DHCP/BOOTP?

> I am wondering if having a thin meta-pxe layer would be useful to pull
> some of this together both code and people interested, or whether we
> should aim adding this functionality to OE-core?

I think this could be made a general use-case. A meta-layer sounds sensible to get it going - this could then be added to OE-core later if that makes sense.

It would benefit from some scripting support in the image to personalise it as it boots (e.g. setting IP configuration, hostname, etc.) - I'm currently looking to do this by passing parameters back from the server through the kernel command line.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Network booting

[Tomas Frydrych]

On 02/08/13 08:35, Chris Tapp wrote:
>> Depends on the bios, if your machine's bios supports PXE, then you
>> do not need ipxe, just a tftp server set up on the LAN that serves
>> PXELinux.
> 
> My case is a bit more complicated as I also can't have non-secure
> (t)ftp! Are you saying that PXE can work without DHCP/BOOTP?

It probably depends on the BIOS, iirc, standard PXE does not support
anything other than tfpt, but you can probably configure the IP settings
manually, and I think the bios on the machine I was working with
supported https (but I am not 100% sure, and can't check at the moment).
iPXE supports https, of course, so we definitely want iPXE recipe and
documentation.


> It would benefit from some scripting support in the image to
> personalise it as it boots (e.g. setting IP configuration, hostname,
> etc.) - I'm currently looking to do this by passing parameters back
> from the server through the kernel command line.

Yeah, but keep in mind that the stuff only happens 'in the image' when
you have already booted, so you can only script stuff to do with the
rootfs in the image; the kernel and initrd is loaded by the PXE
bootloader so the control here is whatever the PXE bootloader gives you.

Tomas

-- 
http://sleepfive.com

Network Booting

[Chris McKillop]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

Hey...

	Does anyone provide a pre-built kernel that I can use with BootX
that supports mounting / as NFS?  I don't want to mess with the drive on
my wife's laptop but I would love to have Linux running on it and I can
setup / for it on my PC running Linux no problem.  Anyone else doing this?

	chris

-- 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
chris mckillop - cdm@debian.org    "The faster I go, the behinder I get."
Debian GNU/Linux                                     -- Lewis Carroll 
http://www.debian.org/              
Waterloo Aerial Robotics Group - http://ece.uwaterloo.ca/~warg/

[-- Attachment #2: Type: application/pgp-signature, Size: 290 bytes --]