I've been a monolithic kernel guy forever. But with all the new toys
going into 2.6 I figured I'd try to catch up with the times.
I've got udev + hotplug halfway functioning, and wanted to try moving
even my fs and IDE/SCSI modules out of the kernel. It seems the way to
do that is with an initramfs.
So I figure I'll start simple, I got klibc and built it. Copied the the
lib and executables into a new tree, lib in lib and bins in bin.
Symlinked linuxrc to /bin/sh. I also added a dev directory with ram0,
ram1, and initrd (later in my experimentation). Then I cpio'd up the
tree, gzip'd it, and put it where I told grub to find it:
"initrd (hd0,0)/boot/test/initramfs.cpio.gz"
When I boot the kernel associated with that initrd line, it says that it
found a compressed image at block 0. But then panics saying it can't
mount the root filesystem.
I've tried various root= options.
>From /dev/ram0, /dev/ram1, /dev/initrd, and initramfs. All fail.
Although /dev/ram0, spit out its own name instead of an unknown block
device 0,0.
So, what am I missing? I've Googled for about an hour now. Everyone is
just talking about the neat new features of initramfs, but no one says,
"do this". The in-tree documentation isn't much better, although it is
what got me this far. The early-userspace document talks about
short-circuting the kernel build to get a custom initramfs appended to
the kernel image. But that seems a bit rough, shouldn't the bootloader
be able to do the appending?
Any help will be welcomed.
--
Chris
On Thu, 2004-04-08 at 12:17, Chris Meadors wrote:
> Then I cpio'd up the
> tree, gzip'd it, and put it where I told grub to find it:
> "initrd (hd0,0)/boot/test/initramfs.cpio.gz"
Did you use a newc-format cpio archive? Sounds like yes, but I want to
be sure.
> When I boot the kernel associated with that initrd line, it says that it
> found a compressed image at block 0. But then panics saying it can't
> mount the root filesystem.
You need a patch to force the kernel not to bother trying to mount a
root filesystem. This has been floating around for a while somewhere.
If you don't use this patch, the kernel won't fall through to initramfs
and panics instead, as you are seeing.
Ooh, I see that Olaf Hering has a recent variant of this patch which is
in -aa kernels. Andrew, can you consider dropping this into -mc or -mm,
please? It won't break normal operation, but will relieve the pain of
the not-yet-battle-scarred. It's less fugly than the earlier dev=0:0
patch. Maybe.
http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.6/2.6.5-rc3-aa1/initramfs-search-for-init
<b
"Bryan O'Sullivan" <[email protected]> writes:
> Ooh, I see that Olaf Hering has a recent variant of this patch which is
> in -aa kernels. Andrew, can you consider dropping this into -mc or -mm,
> please? It won't break normal operation, but will relieve the pain of
> the not-yet-battle-scarred. It's less fugly than the earlier dev=0:0
> patch. Maybe.
>
> http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.6/2.6.5-rc3-aa1/initramfs-search-for-init
If you use that, can you just keep using the initial initramfs as your
root fs forever? That'd be swell for embedded systems...
If so, it'd be nice if it checked for some other name than /init
(e.g. /sbin/init) -- there's too much crap in / already.
Thanks,
-Miles
--
I'd rather be consing.
On Thu, 2004-04-08 at 23:48, Miles Bader wrote:
> If you use that, can you just keep using the initial initramfs as your
> root fs forever? That'd be swell for embedded systems...
You could do so, yep.
> If so, it'd be nice if it checked for some other name than /init
> (e.g. /sbin/init) -- there's too much crap in / already.
I'm agnostic. It's a two-line patch. I don't care if it's called
/spam/fandango/wubble, so long as the brave souls who are trying out
initramfs don't keep stumbling over the same problem again and again :-)
<b
On Fri, Apr 09, 2004 at 10:21:39AM -0700, Bryan O'Sullivan wrote:
> > If so, it'd be nice if it checked for some other name than /init
> > (e.g. /sbin/init) -- there's too much crap in / already.
>
> I'm agnostic. It's a two-line patch. I don't care if it's called
> /spam/fandango/wubble, so long as the brave souls who are trying out
> initramfs don't keep stumbling over the same problem again and again :-)
Indeed; I just wanna raise the point before people start actually using /init
in large numbers...
I wonder if you could move the bulk of stuff (the console open, the calls to
run_init_proces) that happens after prepare_namespace into a separate
function and attempt to call it both before and after prepare_namespace; the
problem seems to be the unlock_kernel &c., which I gather must be done after
prepare_namespace?
-Miles
--
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff
On Friday 09 April 2004 6:21 pm, Bryan O'Sullivan wrote:
> On Thu, 2004-04-08 at 23:48, Miles Bader wrote:
> I'm agnostic. It's a two-line patch. I don't care if it's called
> /spam/fandango/wubble, so long as the brave souls who are trying out
> initramfs don't keep stumbling over the same problem again and again :-)
May I suggest
diff -Naur linux-2.6.5.old/init/main.c linux-2.6.5/init/main.c
--- linux-2.6.5.old/init/main.c 2004-04-05 18:19:04.000000000 +0100
+++ linux-2.6.5/init/main.c 2004-04-18 15:37:56.000000000 +0100
@@ -604,7 +604,12 @@
smp_init();
do_basic_setup();
- prepare_namespace();
+ /*
+ * check if there is an early userspace init, if yes
+ * let it do all the work
+ */
+ if ( ! sys_access("/linuxrc", 0) == 0)
+ prepare_namespace();
/*
* Ok, we have completed the initial bootup, and
linuxrc already exists for initrd systems, and is coded in anyway.
I have tested this with both with both linuxrc -> bin/ash
and with a script that brings up a full system. (I have made
a boot CD that installs Linux-2.6.5 with udev)
Chris Lingard
Followup to: <[email protected]>
By author: Chris Lingard <[email protected]>
In newsgroup: linux.dev.kernel
>
> linuxrc already exists for initrd systems, and is coded in anyway.
>
NO NO NO NO NO NO NO NO NO NO NO ...
Calling it /linuxrc instead of /sbin/init was a bad idea to begin with
.. let's not make it worse by making it magic...
-hpa