* RFC: initramfs unpack point and rules
@ 2007-04-05 12:34 Krzysztof Halasa
2007-04-05 14:31 ` Krzysztof Halasa
2007-04-12 11:06 ` Al Viro
0 siblings, 2 replies; 4+ messages in thread
From: Krzysztof Halasa @ 2007-04-05 12:34 UTC (permalink / raw)
To: linux-kernel
Hi,
I recently got a BSOD bootup problem with external initramfs (it's
ARM but it seems it doesn't matter).
--------------------------------------------------------------------------
First problem: initramfs is unpacked way before console drivers
are initialized, so you aren't going to see the panic():
init/initramfs.c:static int __init populate_rootfs(void)
...
printk(KERN_INFO "Unpacking initramfs...");
err = unpack_to_rootfs((char *)initrd_start,
initrd_end - initrd_start, 0);
if (err)
panic(err);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
printk(" done\n");
free_initrd();
I wonder why is initramfs unpacked that early, before most drivers?
I'd expect it much later in the boot sequence, just before userspace
and initial devices (/dev/console etc) are needed. Should it be moved
there? populate_rootfs() unpacks both builtin and external initramfs.
--------------------------------------------------------------------------
Second problem:
RedBoot> exec -r 0x800000 -s 8000000 -c "console=ttyS0,115200"
Using base address 0x00030000 and length 0x001eea08
Uncompressing Linux...............................done, booting the kernel.
[nothing then]
Obviously I didn't want to specify the exact size and expected inflate
to determine it by itself. I think a valid gzipped cpio image, followed
by some junk, should not be a problem here. Currently, unpack_to_rootfs()
does the job but returns "bad gzip magic numbers" error message - I think
I should change it to return that message only for first initramfs header
and return a success if some junk is spotted after a valid end of
compressed data.
Opinions?
--
Krzysztof Halasa
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: initramfs unpack point and rules
2007-04-05 12:34 RFC: initramfs unpack point and rules Krzysztof Halasa
@ 2007-04-05 14:31 ` Krzysztof Halasa
2007-04-12 11:06 ` Al Viro
1 sibling, 0 replies; 4+ messages in thread
From: Krzysztof Halasa @ 2007-04-05 14:31 UTC (permalink / raw)
To: linux-kernel
> I wonder why is initramfs unpacked that early, before most drivers?
> I'd expect it much later in the boot sequence, just before userspace
> and initial devices (/dev/console etc) are needed. Should it be moved
> there? populate_rootfs() unpacks both builtin and external initramfs.
I mean something like the attached patch would change the boot order
from:
TCP reno registered
Unpacking initramfs... done
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Freeing initrd memory: 7812K
NetWinder Floating Point Emulator V0.97 (double precision)
io scheduler noop registered (default)
IXP4xx Watchdog Timer: heartbeat 60 sec
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xc8000000 (irq = 15) is a XScale
serial8250.0: ttyS1 at MMIO 0xc8001000 (irq = 13) is a XScale
PPP generic driver version 2.4.2
...
to:
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
Unpacking initramfs... done
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Freeing initrd memory: 7812K
XScale DSP coprocessor detected.
Freeing init memory: 628K
Time: OSTS clocksource has been installed.
login:
What do you think?
In case someone wants to apply it (but something tells me it's not
that simple):
Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl>
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 9fcc8d9..33e3036 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -223,9 +223,9 @@
*(.initcall4s.init) \
*(.initcall5.init) \
*(.initcall5s.init) \
- *(.initcallrootfs.init) \
*(.initcall6.init) \
*(.initcall6s.init) \
+ *(.initcallrootfs.init) \
*(.initcall7.init) \
*(.initcall7s.init)
diff --git a/include/linux/init.h b/include/linux/init.h
index 5a593a1..6da2106 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -111,9 +111,9 @@ extern void setup_arch(char **);
#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)
#define fs_initcall(fn) __define_initcall("5",fn,5)
#define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)
-#define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)
#define device_initcall(fn) __define_initcall("6",fn,6)
#define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
+#define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)
#define late_initcall(fn) __define_initcall("7",fn,7)
#define late_initcall_sync(fn) __define_initcall("7s",fn,7s)
--
Krzysztof Halasa
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: RFC: initramfs unpack point and rules
2007-04-05 12:34 RFC: initramfs unpack point and rules Krzysztof Halasa
2007-04-05 14:31 ` Krzysztof Halasa
@ 2007-04-12 11:06 ` Al Viro
2007-04-13 12:08 ` Krzysztof Halasa
1 sibling, 1 reply; 4+ messages in thread
From: Al Viro @ 2007-04-12 11:06 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: linux-kernel
On Thu, Apr 05, 2007 at 02:34:39PM +0200, Krzysztof Halasa wrote:
> First problem: initramfs is unpacked way before console drivers
> are initialized, so you aren't going to see the panic():
>
> init/initramfs.c:static int __init populate_rootfs(void)
> ...
> printk(KERN_INFO "Unpacking initramfs...");
> err = unpack_to_rootfs((char *)initrd_start,
> initrd_end - initrd_start, 0);
> if (err)
> panic(err);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> printk(" done\n");
> free_initrd();
>
> I wonder why is initramfs unpacked that early, before most drivers?
> I'd expect it much later in the boot sequence, just before userspace
> and initial devices (/dev/console etc) are needed. Should it be moved
> there? populate_rootfs() unpacks both builtin and external initramfs.
Nope. The point is to have it as early as possible, so that we had more
or less normal environment when drivers, etc. are being initialized.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: initramfs unpack point and rules
2007-04-12 11:06 ` Al Viro
@ 2007-04-13 12:08 ` Krzysztof Halasa
0 siblings, 0 replies; 4+ messages in thread
From: Krzysztof Halasa @ 2007-04-13 12:08 UTC (permalink / raw)
To: Al Viro; +Cc: linux-kernel
Al Viro <viro@ftp.linux.org.uk> writes:
> Nope. The point is to have it as early as possible, so that we had more
> or less normal environment when drivers, etc. are being initialized.
But traditionally the "normal environment" is a root fs not yet
mounted. Do the drivers need initramfs? Which drivers?
In both cases it's a bit before /sbin/init (or /init) is launched,
udevd isn't running and firmware can't be loaded.
OTOH when something goes wrong before console drivers are initialized,
nothing can be seen. And with initramfs (especially with the external
one) it's easy to screw something.
--
Krzysztof Halasa
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-04-13 12:08 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-04-05 12:34 RFC: initramfs unpack point and rules Krzysztof Halasa
2007-04-05 14:31 ` Krzysztof Halasa
2007-04-12 11:06 ` Al Viro
2007-04-13 12:08 ` Krzysztof Halasa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox