(Sparc64) 2.6.20 seems to ignore initramfs

(Sparc64) 2.6.20 seems to ignore initramfs

[Andrew Walrond]

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 (nobody@spawn1.secure) (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

Re: (Sparc64) 2.6.20 seems to ignore initramfs

[Tomasz Chmielewski]

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

Re: (Sparc64) 2.6.20 seems to ignore initramfs

[Andrew Walrond]

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

Re: (Sparc64) 2.6.20 seems to ignore initramfs

[Tomasz Chmielewski]

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

Re: (Sparc64) 2.6.20 seems to ignore initramfs

[Andrew Walrond]

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

Re: (Sparc64) 2.6.20 seems to ignore initramfs

[Jan Engelhardt]

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
-- 

Re: (Sparc64) 2.6.20 seems to ignore initramfs

[Andrew Walrond]

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