On a Sun T1000 I am trying to boot 2.6.20 using initramfs. (I use the same
procedure successfully on x86_64 and itanium2 servers).
The relevent silo section looks like this:
image=/boot/2.6.20.image
label=2.6.20
initrd=/boot/2.6.20.initramfs
partition=2
read-only
The kernel loads and boots and I see
Allocated 8 Megs of memory at 0x40000000 for kernel
Loaded kernel version 2.6.20
Loading initial ramdisk (127932430 bytes at 0x1000000 phys, 0x40C00000
virt)...
/
Remapping the kernel... done.
Booting Linux...
PROMLIB: Sun IEEE Boot Prom 'OBP 4.23.0 2006/06/02 16:14'
PROMLIB: Root node compatible: sun4v
Linux version 2.6.20 ([email protected]) (gcc version 4.1.1) #1 SMP Thu Feb
22 16:25:18 GMT 2007
ARCH: SUN4V
Ethernet address: 00:14:4f:2a:90:92
PROM: Built device tree with 65903 bytes of memory.
Built 1 zonelists. Total pages: 242541
Kernel command line: ro
[snip]
checking if image is initramfs... it is
Freeing initrd memory: 124934k freed
[snip]
VFS: Cannot open root device "<NULL>" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
<0>Press Stop-A (L1-A) to return to the boot prom
So it knows about the initramfs, but then tries to mount a root filesystem
instead...
I haven't tried this (initramfs) with earlier kernels, so I don't know
whether this is a regression. Any clues about how to solve this would be
greatly appreciated.
Andrew Walrond
Andrew Walrond schrieb:
> On a Sun T1000 I am trying to boot 2.6.20 using initramfs. (I use the same
> procedure successfully on x86_64 and itanium2 servers).
>
> The relevent silo section looks like this:
>
> image=/boot/2.6.20.image
> label=2.6.20
> initrd=/boot/2.6.20.initramfs
> partition=2
> read-only
>
> The kernel loads and boots and I see
>
(...)
>
> So it knows about the initramfs, but then tries to mount a root filesystem
> instead...
>
> I haven't tried this (initramfs) with earlier kernels, so I don't know
> whether this is a regression. Any clues about how to solve this would be
> greatly appreciated.
Does it make a difference if you embed initramfs directly in the kernel?
CONFIG_INITRAMFS_SOURCE="/path/to/your/initramfs/directory"
--
Tomasz Chmielewski
http://wpkg.org
On Friday 23 February 2007 13:32, Tomasz Chmielewski wrote:
> Andrew Walrond schrieb:
> > On a Sun T1000 I am trying to boot 2.6.20 using initramfs. (I use the
> > same procedure successfully on x86_64 and itanium2 servers).
> >
> > The relevent silo section looks like this:
> >
> > image=/boot/2.6.20.image
> > label=2.6.20
> > initrd=/boot/2.6.20.initramfs
> > partition=2
> > read-only
> >
> > The kernel loads and boots and I see
>
> (...)
>
> > So it knows about the initramfs, but then tries to mount a root
> > filesystem instead...
> >
> > I haven't tried this (initramfs) with earlier kernels, so I don't know
> > whether this is a regression. Any clues about how to solve this would be
> > greatly appreciated.
>
> Does it make a difference if you embed initramfs directly in the kernel?
>
> CONFIG_INITRAMFS_SOURCE="/path/to/your/initramfs/directory"
Hi Tomasz. I can't tell; The combined kernel+initramfs is bigger than the 8Mb
silo allocates for the kernel, and it does this:
boot: chunky
Allocated 8 Megs of memory at 0x40000000 for kernel
/
Fatal error: Image too large to fit in destination
Fatal error: Image too large to fit in destination
Error loading /boot/chunky
Image not found.... try again
I don't see any silo config options to increase this value in the docs.
Good idea though :)
Andrew Walrond
Andrew Walrond schrieb:
> On Friday 23 February 2007 13:32, Tomasz Chmielewski wrote:
>> Andrew Walrond schrieb:
>>> On a Sun T1000 I am trying to boot 2.6.20 using initramfs. (I use the
>>> same procedure successfully on x86_64 and itanium2 servers).
>>>
>>> The relevent silo section looks like this:
>>>
>>> image=/boot/2.6.20.image
>>> label=2.6.20
>>> initrd=/boot/2.6.20.initramfs
>>> partition=2
>>> read-only
>>>
>>> The kernel loads and boots and I see
>> (...)
>>
>>> So it knows about the initramfs, but then tries to mount a root
>>> filesystem instead...
>>>
>>> I haven't tried this (initramfs) with earlier kernels, so I don't know
>>> whether this is a regression. Any clues about how to solve this would be
>>> greatly appreciated.
>> Does it make a difference if you embed initramfs directly in the kernel?
>>
>> CONFIG_INITRAMFS_SOURCE="/path/to/your/initramfs/directory"
>
> Hi Tomasz. I can't tell; The combined kernel+initramfs is bigger than the 8Mb
> silo allocates for the kernel, and it does this:
>
> boot: chunky
> Allocated 8 Megs of memory at 0x40000000 for kernel
> /
> Fatal error: Image too large to fit in destination
>
> Fatal error: Image too large to fit in destination
>
> Error loading /boot/chunky
>
> Image not found.... try again
>
>
> I don't see any silo config options to increase this value in the docs.
>
> Good idea though :)
Try to decrease the initramfs size just to know if it boots correctly.
I.e., put just a sh/bash/ash/dash binary there (probably /dev/console
node, too), executed in init.
Then, try to start the kernel with initramfs embedded in the kernel,
then as initrd etc. - this will show if the fault is on your side, or
kernel's.
--
Tomasz Chmielewski
http://wpkg.org
On Friday 23 February 2007 15:17, Tomasz Chmielewski wrote:
>
> Try to decrease the initramfs size just to know if it boots correctly.
>
> I.e., put just a sh/bash/ash/dash binary there (probably /dev/console
> node, too), executed in init.
>
> Then, try to start the kernel with initramfs embedded in the kernel,
> then as initrd etc. - this will show if the fault is on your side, or
> kernel's.
I have tracked this down to a broken version of gnu cpio (latest release, 2.7)
which was used to create the initramfs archive. Bloody annoying since this
has bitten me before! Last time I even sent the maintainer a bug report, and
apparently a fix is in CVS waiting for the next release. Ho hum.
Sorry for the noise.
Andrew Walrond
On Feb 23 2007 15:47, Andrew Walrond wrote:
>On Friday 23 February 2007 15:17, Tomasz Chmielewski wrote:
>>
>> Try to decrease the initramfs size just to know if it boots correctly.
>>
>> I.e., put just a sh/bash/ash/dash binary there (probably /dev/console
>> node, too), executed in init.
>>
>> Then, try to start the kernel with initramfs embedded in the kernel,
>> then as initrd etc. - this will show if the fault is on your side, or
>> kernel's.
>
>I have tracked this down to a broken version of gnu cpio (latest release, 2.7)
>which was used to create the initramfs archive. Bloody annoying since this
>has bitten me before! Last time I even sent the maintainer a bug report, and
>apparently a fix is in CVS waiting for the next release. Ho hum.
Forgot the -c flag, right?
Jan
--
On Saturday 24 February 2007 15:23, Jan Engelhardt wrote:
> On Feb 23 2007 15:47, Andrew Walrond wrote:
> >
> >I have tracked this down to a broken version of gnu cpio (latest release,
> > 2.7) which was used to create the initramfs archive. Bloody annoying
> > since this has bitten me before! Last time I even sent the maintainer a
> > bug report, and apparently a fix is in CVS waiting for the next release.
> > Ho hum.
>
> Forgot the -c flag, right?
>
No, I use '-H newc' as per the instrucions in
Documentation/filesystems/ramfs-rootfs-initramfs.txt. Does -c do the same
thing? [checks man cpio...]
But there is a real bug in cpio 2.7 which can break the archive. Its been
fixed in cpio cvs awaiting the next release.
My report to the cpio ML:
Hello list,
I've been experimenting with large (500Mb) initramfs cpio archives on
linux, x86_64, using cpio 2.7, compiled 64bit with gcc4.1.1.
If I create a cpio archive, then extract it and compare with the
original, I see broken symlinks.
I don't know if the archives themselves are corrupt, or whether the
extraction code is broken, but I guess you guys can work that out.
An example:
root@orac initramfs $ cd rootfs
root@orac rootfs $ find . | cpio -o -H newc > ../rootfs.cpio
857030 blocks
root@orac rootfs $ cd ..
root@orac initramfs $ mkdir tmp
root@orac initramfs $ cd tmp
root@orac tmp $ cpio -i -d -H newc -F ../rootfs.cpio --no-absolute-filenames
857030 blocks
root@orac tmp $ ll ../rootfs/pkg/linux/lib/modules/2.6.19.2/
total 1.1M
lrwxrwxrwx 1 root root 17 Jan 11 13:39 build -> /pkg/linux/source
drwxrwxr-x 11 root root 4.0K Jan 11 11:14 kernel
-rw-rw-r-- 1 root root 229K Jan 11 11:14 modules.alias
-rw-rw-r-- 1 root root 69 Jan 11 11:14 modules.ccwmap
-rw-rw-r-- 1 root root 246K Jan 11 11:14 modules.dep
-rw-rw-r-- 1 root root 813 Jan 11 11:14 modules.ieee1394map
-rw-rw-r-- 1 root root 788 Jan 11 11:14 modules.inputmap
-rw-rw-r-- 1 root root 2.6K Jan 11 11:14 modules.isapnpmap
-rw-rw-r-- 1 root root 74 Jan 11 11:14 modules.ofmap
-rw-rw-r-- 1 root root 161K Jan 11 11:14 modules.pcimap
-rw-rw-r-- 1 root root 967 Jan 11 11:14 modules.seriomap
-rw-rw-r-- 1 root root 100K Jan 11 11:14 modules.symbols
-rw-rw-r-- 1 root root 306K Jan 11 11:14 modules.usbmap
lrwxrwxrwx 1 root root 17 Jan 11 13:39 source -> /pkg/linux/source
root@orac tmp $ ll pkg/linux/lib/modules/2.6.19.2/
total 1.1M
lrwxrwxrwx 1 root root 23 Jan 12 12:08 build -> /pkg/linux/sourceodules
drwxrwxr-x 11 root root 4.0K Jan 12 12:08 kernel
-rw-rw-r-- 1 root root 229K Jan 12 12:08 modules.alias
-rw-rw-r-- 1 root root 69 Jan 12 12:08 modules.ccwmap
-rw-rw-r-- 1 root root 246K Jan 12 12:08 modules.dep
-rw-rw-r-- 1 root root 813 Jan 12 12:08 modules.ieee1394map
-rw-rw-r-- 1 root root 788 Jan 12 12:08 modules.inputmap
-rw-rw-r-- 1 root root 2.6K Jan 12 12:08 modules.isapnpmap
-rw-rw-r-- 1 root root 74 Jan 12 12:08 modules.ofmap
-rw-rw-r-- 1 root root 161K Jan 12 12:08 modules.pcimap
-rw-rw-r-- 1 root root 967 Jan 12 12:08 modules.seriomap
-rw-rw-r-- 1 root root 100K Jan 12 12:08 modules.symbols
-rw-rw-r-- 1 root root 306K Jan 12 12:08 modules.usbmap
lrwxrwxrwx 1 root root 23 Jan 12 12:08 source -> /pkg/linux/sourceodules
root@orac tmp $
The extra 'odules' is suspiciously like 'modules'...
I am now using version 2.6 with debian patches to 2.6-17, and this works
fine. I've tried making a small test case, but it only seems to occur
with my large (500Mb) root filesystem archives. If I just archive the
modules directory in the example above, the corruption does not occur.
Anyhow; if I can do anything to chase this down further, let me know. I
have joined the ML.
Andrew Walrond