Hi David;

I tried buildimage today and wasn't able to boot the genarated iso image in 
qemu.
Right now I'm doing a full rebuild from from scratch to be shure that the 
error was not caused by changes in my buildenv.
Will report later or tomorrow - a full rebuild takes some time.

Am Sonntag, 26. September 2010, 09:05:47 schrieb davidMbrooke:
> Thanks kp. Responses to your comments added below.
> 
> davidMbrooke
> 
> On Sat, 2010-09-25 at 23:22 +0200, KP Kirchdoerfer wrote:
> > > My work on a new image build script for Bering-uClibc 4.x is not
> > > complete but it is ready to be shared. I have just checked an initial
> > > version of "buildimage.pl" into CVS. It is heavily based on
> > > "buildpacket.pl" and hopefully you will spot the similarities.
> > > 
> > > The basic idea is as follows:
> > >    - There are multiple "disk image" targets.
> > >    - Each of these has its own configuration file (buildimage.cfg)
> > >    which
> > > 
> > > I have chosen to locate in directories called buildtool/image/*
> > > 
> > >    - So far I have created two examples:
> > >          buildtool/image/Bering-uClibc-isolinux-std/buildimage.cfg
> > >          buildtool/image/Bering-uClibc-syslinux-std/buildimage.cfg
> > >    
> > >    - The first example is intended to replicate the current
> > > 
> > > tools/geniso.sh script and creates an equivalent .iso file

Ok, once that works I'd think we should keep an eye on the directory 
structure.
The whole buildtool/tools directory start to become a complete mess; outdated 
files, different directories for things I don't understand myself after a few 
weeks. That makes the buildprocess really difficult to understand.

I think about something like
buildtool/images providing only the images without subdirs
buildtool/images/isolinux with isolinux related files and buildimage.cfg
buildtool/images/syslinux with syslinux related files and buildimage.cfg

Maybe something else, but at least better than what we do have today :)

> > >       - The .iso file is now created in the relevant sub-directory of
> > > 
> > > buildtool/image
> > > 
> > >       - I have intentionally omitted the .ser (Serial Console)
> > > 
> > > configuration since I expect to have alternative image configurations
> > > for these (Bering-uClibc-isolinux-ser perhaps)
> > 
> > An easier (and more general) solution will be a seperate configdb.lrp, as
> > Martin has done in his draft for a 2.6 kernel release.
> 
> Yes, but there needs to be a modified isolinux.cfg (from isolinux.ser)
> and configdb.ser needs to be loaded as configdb.lrp. These files could
> be renamed automatically using a separate "serial" buildimage.cfg so
> that the user does not need to edit the contents of the image manually.

Agree.

> > >    - The second example has the same contents but generates a .tar.gz
> > > 
> > > file intended to be copied to a SYSLINUX-prepared flash drive
> > > 
> > >       - I don't think it is practical to create a ".img" or similar for
> > > 
> > > a flash drive, but please correct me if that is wrong
> > > 
> > >    - As with the previous scripts, some template files are taken from
> > > 
> > > tools/image/* but I have created new sub-directories (common, isolinux,
> > > syslinux)
> > > 
> > >    - The buildtool.cfg file controls the substitution of variables in
> > > 
> > > these template files
> > > 
> > > Please give it a try and see what you think. An example command line is:
> > >    ./buildimage.pl --image=Bering-uClibc-isolinux-std --relver=4.0alpha
> > > 
> > > Note that I had to add some more lines to conf/buildtool.conf
> > > 
> > > Comments, questions, bug reports, enhancement requests are all welcome.
> > > 
> > > There is some documentation at
> > > https://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uCli
> > > bc_4 .x_-_Developer_Guide_-_Building_an_Image though I need to update
> > > that with examples of the configuration file syntax.
> > 
> > I've read the wiki (and having your thoughts above in mind) I'm confused
> > about PXE and CF disks.
> > 
> > It is my understanding that everyone thinks PXE is only for booting a
> > complete and runnable router from a tftp-server.
> > 
> > Preparing a bootable CF disk is done via "copying" files to the CF.
> > 
> > A smart way to make use of PXE to load a CF disk has been documented a
> > few years ago:
> > http://leaf.sourceforge.net/doc/buci-ide3.html#id3226960
> > 
> > It may have overseen, but that's what I'm aiming for with a pxe-capable
> > image (it's different from an ISO image and from a "tar.gz" to copy to a
> > CF).
> 
> I understand - using PXE to "bootstrap" an install on a machine with a
> CF, rather than physically removing the CF card and copying files with a
> USB-to-CF adaptor.

Yes. This has served me pretty well in the past.
Maybe should just be more clear in the new documentation (currently it's well 
hidden) and the syslinux-based tgz fit my needs. 

> That page talks about a "modified linuxrc" at step 4. I guess if we make
> the standard linuxrc more generic with respect to PKGPATH we could
> specify e.g. tftp://server/path as PKGPATH in leaf.cfg for PXE boot.
> We also need the tftp client as part of initrd, wouldn't we?
> > In other words:
> > 
> > There shall be another buildimage.cfg for PXE/CF in the future.
> 
> Sure.This would generate a .tar.gz for installing on the PXE server.
> That is what I originally had in mind, although for "full" PXE booting
> rather than for installing on a CF card. If we add the tftp client and
> change linuxrc we can do both.
> 
> I will add a "PXELINUX" block at the end of buildimage.pl

Fine with me; but I wasn't very clear - IMHO such an image is "just nice-to-
have" but not my first, second or third entry in the todo-list.
And the should mention preparing a CF disk can be done with the "pxe-
bootstrap-utility"

> > Speaking about the wiki:
> > I've always found wiki's like a stone quarry. Pls let us avoid to produce
> > another one. IMHO we should first have a structure - similar to a good
> > programming practice, "write the docs first".
> 
> I agree 100% ! Structure and consistency are important in the
> documentation. The Wiki technology is useful in many ways but good
> structure does not come automatically.
> I have started drafting a structure for the User Guide by adding to the
> "Table of Contents" page for that document. Let us use that and the
> "discussion" pages on the Wiki to share plans for the documentation.

Ok - will discuss and complain on the correct place in future :)

kp


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to