nALFS2 development

Jeremy Huntwork jhuntwork at
Fri Aug 6 05:52:39 PDT 2004

On Thu, 2004-08-05 at 18:57 -0700, Kevin P. Fleming wrote:
> Kevin P. Fleming wrote:
> I missed a really important point here: I see great value in being able 
> to provide a "profile repository", something that could be a public 
> server (the LFS team could have one, as could anyone else), where you 
> could connect using the nALFS front end of your choice and pick profile 
> bits that you wanted. This could be a big project by itself, given that 
> it would need to support some sort of "packages" of profile bits that go 
> together, versioning, and other stuff, but it would be really, really cool.

Not sure how easy this would be to implement, but a thought just sprang
to mind while reading these recent posts.  It would be nice to be able
to start an automated install on a network client that has no host

Here's my idea, (just typing this out as it develops in my mind, so
please pardon the roughness)

The client boots with grub, either previously installed as a bootloader
or perhaps from a floppy.  You set the tftpserver option to a server
that is set up to host a kernel with initramfs, to be able to cp over a
few necessary binaries.

Once the network is properly up and running, and your hard drive
properly partitioned/formatted, you begin downloading and unpacking a
chroot type env, like what is built in chapt. 5 and then the packages
(This all could *conceivably* be done in the initramfs before moving on
to another init, like /bin/bash or /sbin/init)

Finally a bootscript begins running the automated install based on your
client/daemon suggestion.

Already I can see a few problems that you might run into with this, but
it's just an idea in the rough.  Any thoughts on this? Suggestions?
Flames? (hopefully not!! ;) )

Jeremy Huntwork

More information about the alfs-discuss mailing list