Hi.

Is there any purpose to having CONFIG_IP_PNP=y in the Alpine kernel 
configuration? It appears that this feature necessitates network drivers 
to be built into the kernel, rather than as modules, but since Alpine 
builds such drivers as modules, the feature is unusable. Correct me if 
I'm wrong on this.

If this were disabled, we could instead handle "ip=dhcp" in the command 
line via the initrd init script and udhcpc, after network drivers were 
loaded. The inclusion of network drives in the initrd would be 
configurable via mkinitfs to keep default initrd sizes down.

The ultimate goal here is to enable Alpine to usefully PXE boot. Once 
Alpine is able to obtain an IP at the initrd phase, further 
modifications to the initrd init script to permit NFS or HTTP servers to 
be specified in the alpine_dev argument should be relatively 
straightforward.

Hugo Landau


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

On Wed, 03 Apr 2013 06:49:38 +0100
Hugo Landau <hlandau@devever.net> wrote:

> Hi.
> 
> Is there any purpose to having CONFIG_IP_PNP=y in the Alpine kernel 
> configuration? It appears that this feature necessitates network
> drivers to be built into the kernel, rather than as modules, but
> since Alpine builds such drivers as modules, the feature is unusable.
> Correct me if I'm wrong on this.

You are probably right. I am currently on vacation so could you please
create an issue on https://bugs.alpinelinux.org for this so I does not
get forgotten.

> 
> If this were disabled, we could instead handle "ip=dhcp" in the
> command line via the initrd init script and udhcpc, after network
> drivers were loaded. The inclusion of network drives in the initrd
> would be configurable via mkinitfs to keep default initrd sizes down.
> 
> The ultimate goal here is to enable Alpine to usefully PXE boot. Once 
> Alpine is able to obtain an IP at the initrd phase, further 
> modifications to the initrd init script to permit NFS or HTTP servers
> to be specified in the alpine_dev argument should be relatively 
> straightforward.

This is something we want yes.

Thanks!


-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

I now have a modified mkinitfs init script which can be used to PXE boot 
successfully to userspace using an HTTP server as the apk repository. 
The remaining difficulties are making modloop work, and getting overlays 
working (I haven't tested this yet).

My understanding is mdev executes shell scripts on certain events, and 
many of these scripts call modprobe. Thus, the modloop filesystem needs 
to be available perpetually after booting. modprobe, etc. aren't exactly 
suited to loading modules over HTTP; some way of doing this could 
probably be found but it would be quite against the flow of the system.

This leaves a few possibilities, such as downloading a squashfs image 
into memory, which isn't too great, or using NFS, which is better. I'd 
like to split the "alpine_dev" argument into "alpine_dev" and 
"alpine_repo". alpine_dev would, as now, specify a filesystem 
(optionally NFS), for use by things that require a filesystem interface 
(modprobe). alpine_repo would specify a line for /etc/apk/repositories. 
These are quite different functions and should probably be untied. 
Compatibility can be preserved by ensuring that alpine_dev is processed 
as it currently (search for .boot_repository on alpine_dev) if 
alpine_repo is omitted - this has the side effect of allowing NFS to be 
used for apk as well. ovl_dev could specify an HTTP URL for an apkovl 
file or a device as usual.

As an example, a PXE-booting system would have a command line of 
something like:
alpine_dev=nfs:IP:EXPORT alpine_repo=http://nl.alpinelinux.org/... 
ovl_dev=http://.../foo.apkovl.tar.gz
No pre-existing command line would be adversely affected.

After this is all done the only remaining obstacle should be some slight 
changes to the modloop init script to make it understand NFS alpine_dev.

Hugo Landau



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---