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