Hi everybody,
for the last few weeks, Dirk Gfroerer, Eric Spakman and myself have been
working on getting kernel 2.6 to work with Bering-uClibc. By now, we
have things working enough that we feel it's fit to be shown to the
other leaf developers out there. It is by no means ready, probably not
even functional at this point, but we have a kernel, an initrd and a
quemu image that boots.
I've checked all the changes into CVS - to check it out from CVS, do the
following:
leaf project members:
export CVS_RSH=ssh
cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf \
co src/The_UnNamed_One
everybody else:
cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/leaf login
cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvsroot/leaf \
co src/The_UnNamed_One
Things to do first after checkout:
in src/bering-uclibc/buildtool/make/MasterInclude.mk :
HOSTCC should pointing to a gcc 3.x compiler. The buildenv will not
build with gcc 4.0
Building the buildenv and packages is the same as for Bering uclibc. It
has been tested on RHEL 3/4 and CentOS 4
If you want to test it, you can find a qemu image plus kernel and initrd at:
http://sourceforge.net/project/showfiles.php?group_id=13751&package_id=265425
To run this image in qemu, download and extract the tarball (it contains
the image, kernel and initrd) and then start quemu like this:
qemu -hda root.img --initrd initrd.lrp --kernel linux \
--append "init= rw LEAFCFG=/dev/hda1:msdos"
(for some reason, qemu hangs when started just with "qemu -hda hd.img "
after loading the kernel and initrd)
To access the contents of the image, follow these steps:
# /sbin/fdisk -lu root.img
This should produce output similar to this:
> > You must set cylinders.
> > You can do this from the extra functions menu.
> >
> > Disk hd.img: 0 MB, 0 bytes
> > 8 heads, 32 sectors/track, 0 cylinders, total 0 sectors
> > Units = sectors of 1 * 512 = 512 bytes
> >---^
> >
> > Device Boot Start End Blocks Id System
> > hd.img1 * 32 125439 62704b W95 FAT32
> > ^
the underlined numbers are relevant if you want to mount the image
(since it's an image of a whole HD, not just of a partition)
So, to mount, you then do:
# mount -o loop,offset=$(( 32 * 512 )) hd.img /mnt/loop
(replace 32 and 512 with the corresponding numbers from
"/sbin/fdisk -lu root.img ", should they be different on your system).
About the changes we made:
* kernel 2.6.24.2
* initrd is now using initramfs
* udev (busybox calls it mdev) support
* updated versions of busybox, iptables, iproute2
Where to go from here:
This obviously still needs a lot of work, and even more testing. We'll
be happy to receive feedback here on leaf-devel about things that work
and don't work, but please refrain from asking us to build package XY,
add support for modules currently unsupported or something like that at
this point. Currently, the focus is on getting the base image working -
everything else will come at a later point.
Due to things we have learned from the 2.x and 3.x releases of Bering
uClibc, we are going to significantly cut down the number of packages
maintained by the "core" Bering uClibc team. Packages can be added,
provided that somebody is willing to be the maintainer of that package.
The reason for this is that it has become almost impossible for a
handful of people to maintain the 158 packages we are currently offering
for Bering uClibc 3.x (some of which we can't even test, since we don't
have the hardware or the software setup to test them).
In the end, this will mean that the contrib section will probably become
quite a bit bigger, while the number of "core packages" will be smaller.
And hopefully, it will also mean that number of developers increases at
least a bit, so the workload gets spread out a bit more than in the past.
We're still looking for a name for this branch (we don't really want to
call it Bering uClibc 4.0 - with dropping floppy support, and changing
how the packages are maintained, it's probably better give it a new
name) - so if you have ideas, we're be happy to hear them. We've been
looking for something short (not a mouthful), somewhat relating to
Bering (as in straits, canals, dams or something like that)
But in the end, if it sounds good, and doesn't cause cultural problems
(many names that sound great in German just don't work for an
international community), I guess we can agree on that.
Martin
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
