[uClibc] static compiling

Rob Landley rob at landley.net
Thu Feb 19 23:53:55 UTC 2004


On Wednesday 18 February 2004 10:29, Bennett Todd wrote:
> 2004-02-18T03:14:31 Rob Landley:
> > If you need a mini-system to bring up the real system, use an
> > initrd. (2.8 is going to strip the early setup stuff out of
> > the kernel and make an initramfs _mandatory_.
>
> Could you please be so kind as to expand on that bit? Is LILO,
> vmlinuz, and a root filesystem not going to suffice to boot 2.8?
> Will 2.8 no longer be able to work with root= and ro/rw boot
> parameters to directly boot onto a hard disk partition?

Part of the 2.6 build process already builds an initramfs, and the 2.6 boot 
process extracts it and loads it into memory.  It just doesn't run anything 
out of it.  (I've appended an old linux-kernel message from Al Viro about how 
to test out initramfs in 2.6 if you want to play with it.)

The new initramfs will be linked into the vmlinuz image during the build, 
rather than being a separate file.  That's what's done now, anyway.  Notice 
that the 2.6 linux-kernel tarball has sprouted a "usr" directory, which 
contains just skeleton code at the moment that generates and links in a more 
or less empty initramfs file (which is a cpio style archive, which is 
apparently less complicated than tarballs, search the archives for the 
flamewar on that issue).

Right now, initramfs is just an optional replacement to initrd.  /rootfs has 
basically become a special ramfs which initramfs extracts stuff into.  (note 
this means you have to delete that stuff to free up the memory, before doing 
your pivot_root to the real root and having your init script exec the real 
init so it inherits PID 1.  Whether or not you'll still have to do "echo 
0x0100 > /proc/sys/kernel/real-root-dev" is an open question.  I haven't 
tried all this, by the way.  Your mileage may vary.  This is currently 
"bleeding edge early adopters" stuff...)

In 2.7, they're going to take a lot of the nasty kernel code like automatic 
NFS root partition mounting (and the corresponding dhcp code), and a lot of 
the block device identification stuff (partition detection, etc) and move it 
into the usr directory to make an initramfs do it as userspace processes.  
(There's talk of having partitions eventually just be "device mapper" slices 
of block devices, set up by udev.  There was a recent linux-kernel flamewar 
on the subject, a month or two back.  It might help your google groups search 
to know that Greg Kroah-Hartman was involved, I think.  Basically, they're 
going to have hotplug start up as soon as the initramfs is up, and _all_ 
device detection and configuration will be done by hotplug events, even 
finding and mounting the root partition...)

Probably, at least a skeleton initramfs will always be generated by the linux 
kernel build.  Linus put his foot down a couple months ago saying that the 
block device/partition detection code was never moving out of the linux 
kernel source tarball, because without it the kernel was basically useless.  
So what's likely is a couple of really thin userspace things (klibc and udev, 
possibly) might move into the kernel tarball instead.  (Or else your kernel 
build will just assume they exist on your system...)

The details are still fuzzy, this is all 2.7 stuff.  Those arguments haven't 
happened yet. :)

Rob

-------------

Re: [PATCH] initrd with devfs enabled (Re: initrd and 2.6.0-test8)
Date: 2003-10-18 17:11
From: viro at parcelfarce.linux.theplanet.co.uk
To: Arkadiusz Miskiewicz <arekm at pld-linux.org>
CC: linux-kernel <linux-kernel at vger.kernel.org>

On Sat, Oct 18, 2003 at 11:56:04PM +0200, Arkadiusz Miskiewicz wrote:
> On Saturday 18 of October 2003 21:41, viro at parcelfarce.linux.theplanet.co.uk 
> wrote:
> >     OK, that should do it - the problems happened if you had devfs
> > enabled; in that case late-boot code does temporary mount of devfs over
> > rootfs /dev, which made /dev/initrd inaccessible.  For setups without
> > devfs that didn't happen.
> >
> >     Fix is trivial - put the file in question outside of /dev; IOW,
> > we simply replace "/dev/initrd" with "/initrd.image" in init/*.  It works
> > here; please check if it fixes all initrd problems on your boxen.
> Works fine for me.
> 
> btw. is it possible to do not use initrd with some fs and instead use 
external 
> initramfs image?
> 
> I've tried to create initramfs image with unpacking initrd image, mounting 
it 
> over loop and creating cpio archive from that (find . | cpio -o -c > 
> ../x.cpio), gzipping that cpio and placeing it instead of old initrd at 
> /boot/initrd + lilo reload. 
> 
> It doesn't work that way unfortunately (test8 with your patch).

Yes and no - it *is* unpacked, but currently we have no code that would
try to run something from initramfs.  If you want to play with that -
add something like run_init_process("/init"); right before the call of
prepare_namespace() in init/main.c (and be ready to have /init on
initramfs do the rest, obvoiusly).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




More information about the uClibc mailing list