initrd testing

initrd testing

[Ben Collins]

Some people have reported problems with initrd on sparc64. I'm trying to
trace that problem (hard, because I can't reproduce it). If you've had
the problem where silo reports loading the initrd into memory, but the
kernel fails to detect and use it, please try the second.b in the url
below, and recompile a kernel using one of the two patches there aswell
(2.4 and 2.6).

The new second.b will show the phys address that the initrd was loaded
to, in addition to the virtual address.

Thanks.

http://www.sparc-boot.org/pub/testing/

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: initrd testing

[Joshua Kwan]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

[ Sorry for the huge crosspost, but this is a pretty big deal. ]

On Thu, May 13, 2004 at 04:21:46PM -0400, Ben Collins wrote:
> Some people have reported problems with initrd on sparc64. I'm trying to
> trace that problem (hard, because I can't reproduce it). If you've had
> the problem where silo reports loading the initrd into memory, but the
> kernel fails to detect and use it, please try the second.b in the url
> below, and recompile a kernel using one of the two patches there aswell
> (2.4 and 2.6).
> 
> The new second.b will show the phys address that the initrd was loaded
> to, in addition to the virtual address.

I've built debian-installer images for sparc based on kernels with this
patch (for 2.4) and the new second.b.

You probably want the CDROM image since it's the one most commonly
reported as not being able to boot. (cdrom-mini.iso) I am personally not
able to try these out until I receive a sparc64 machine, which should
happen sometime in the near future.

http://june.voxel.net/~joshk/d-i/images/2004-05-14/

I hope that this resolves the issues with SILO and initrd!

-- 
Joshua Kwan

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 881 bytes --]

Re: initrd testing

[Ben Collins]

> I hope that this resolves the issues with SILO and initrd!

Me too!

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: initrd testing

[Ben Collins]

> Ultra1:  On this one, I got (modulo any typos)
> 
>     Loading initial ramdisk (1477684 bytes at 0x01x phys 022340800 virt) ...
>     [spinning \/]
>     Remapping the kernel ...  FP Disabled
>     ok
> 
> and I was back to the OpenBoot 'ok' prompt.

This is strange.

> Ultra10:  On this one, I got much further.  The kernel was loading,
> but failed near the end.  The last messages were
> 
>     RAMDISK: couldn't find valid ramdisk image starting at 0.
>     Freeing initrd memory 1443k freed
>     cramfs: wrong magic
>     sh-2021: reiserfs_read_super: can not find reiserfs on ramdisk (1,0)
>     Kernel panic: VFS: Unable to mount root fs on 00:00
> 
> I hope this means something to somebody.

This means something. Atleast we are showing a ramdisk, but the start
point is all wrong. Did the old cd images work for you?

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: initrd testing

[Andy Dougherty]

On Thu, 13 May 2004, Joshua Kwan wrote:

> [ Sorry for the huge crosspost, but this is a pretty big deal. ]
>
> On Thu, May 13, 2004 at 04:21:46PM -0400, Ben Collins wrote:
> > Some people have reported problems with initrd on sparc64. I'm trying to
> > trace that problem (hard, because I can't reproduce it). If you've had
> > the problem where silo reports loading the initrd into memory, but the
> > kernel fails to detect and use it, please try the second.b in the url
> > below, and recompile a kernel using one of the two patches there aswell
> > (2.4 and 2.6).
> >
> > The new second.b will show the phys address that the initrd was loaded
> > to, in addition to the virtual address.
>
> I've built debian-installer images for sparc based on kernels with this
> patch (for 2.4) and the new second.b.
>
> You probably want the CDROM image since it's the one most commonly
> reported as not being able to boot. (cdrom-mini.iso) I am personally not
> able to try these out until I receive a sparc64 machine, which should
> happen sometime in the near future.
>
> http://june.voxel.net/~joshk/d-i/images/2004-05-14/

I tried http://june.voxel.net/~joshk/d-i/images/2004-05-14/drom-mini.iso
on two machines, an Ultra1 and an Ultra10; both failed, though
differently.

Ultra1:  On this one, I got (modulo any typos)

    Loading initial ramdisk (1477684 bytes at 0x01x phys 022340800 virt) ...
    [spinning \/]
    Remapping the kernel ...  FP Disabled
    ok

and I was back to the OpenBoot 'ok' prompt.

Ultra10:  On this one, I got much further.  The kernel was loading,
but failed near the end.  The last messages were

    RAMDISK: couldn't find valid ramdisk image starting at 0.
    Freeing initrd memory 1443k freed
    cramfs: wrong magic
    sh-2021: reiserfs_read_super: can not find reiserfs on ramdisk (1,0)
    Kernel panic: VFS: Unable to mount root fs on 00:00

I hope this means something to somebody.

-- 
    Andy Dougherty		doughera@lafayette.edu

Re: initrd testing

[Andy Dougherty]

On Fri, 14 May 2004, Ben Collins wrote:

AD> Ultra10:  On this one, I got much further.  The kernel was loading,
AD> but failed near the end.  The last messages were
AD>
AD>     RAMDISK: couldn't find valid ramdisk image starting at 0.
AD>     Freeing initrd memory 1443k freed
AD>     cramfs: wrong magic
AD>     sh-2021: reiserfs_read_super: can not find reiserfs on ramdisk (1,0)
AD>     Kernel panic: VFS: Unable to mount root fs on 00:00

> This means something. Atleast we are showing a ramdisk, but the start
> point is all wrong. Did the old cd images work for you?

I'm afraid I haven't been keeping up.  The last CD boot I did was the
woody install.  I can try (a small number) of other images, if you
have any specific suggestions.

-- 
    Andy Dougherty		doughera@lafayette.edu

Re: initrd testing

[Ben Collins]

> loaded kernel version 2.4.26
> Loading initial ramdisk ( 1477684 bytes at 0x01x phys, 0x60800000 virt)

Crap, silo's printf doesn't support lx or llx. I need to fix that,
because I really need that info.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: initrd testing

[Peter Karbaliotis]

Ben Collins wrote:
>>Ultra1:  On this one, I got (modulo any typos)
>>
>>    Loading initial ramdisk (1477684 bytes at 0x01x phys 022340800 virt) ...
>>    [spinning \/]
>>    Remapping the kernel ...  FP Disabled
>>    ok
>>
>>and I was back to the OpenBoot 'ok' prompt.
> 
> 
> This is strange.
> 
> 
>>Ultra10:  On this one, I got much further.  The kernel was loading,
>>but failed near the end.  The last messages were
>>
>>    RAMDISK: couldn't find valid ramdisk image starting at 0.
>>    Freeing initrd memory 1443k freed
>>    cramfs: wrong magic
>>    sh-2021: reiserfs_read_super: can not find reiserfs on ramdisk (1,0)
>>    Kernel panic: VFS: Unable to mount root fs on 00:00
>>
>>I hope this means something to somebody.
> 
> 
> This means something. Atleast we are showing a ramdisk, but the start
> point is all wrong. Did the old cd images work for you?
> 

I also saw this on a Sun Ultra 2.

Sun Ultra 2 UPA/Sbus (2 x UltraSPARC 200 MHz)
...
loaded kernel version 2.4.26
Loading initial ramdisk ( 1477684 bytes at 0x01x phys, 0x60800000 virt)
...
RAMDISK: Couldn't find valid RAM disk image starting at 0
Freeing initrd memory: 1443k freed
cramfs: wrong magic
sh-2021: reiserfs_read_super: can not find reiserfs on ramdisk (1,0)
kernel panic: VFS: Unable to mount root fs on 00:00
   Press L1-A to return to the boot prom


The 20040511 daily image boots up fine on this system.

-- 
Peter.Karbaliotis@ualberta.ca	780-492-7660
Computing and Network Services	University of Alberta

Re: initrd testing

[Joshua Kwan]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

On Fri, May 14, 2004 at 12:45:34PM -0400, Andy Dougherty wrote:
> I tried http://june.voxel.net/~joshk/d-i/images/2004-05-14/drom-mini.iso
> on two machines, an Ultra1 and an Ultra10; both failed, though
> differently.
> 
> Ultra1:  On this one, I got (modulo any typos)
> 
>     Loading initial ramdisk (1477684 bytes at 0x01x phys 022340800 virt) ...
>     [spinning \/]
>     Remapping the kernel ...  FP Disabled
>     ok

There's a chance that I could have botched the kernel, but I'm not sure
how...

>     RAMDISK: couldn't find valid ramdisk image starting at 0.
>     Freeing initrd memory 1443k freed
>     cramfs: wrong magic
>     sh-2021: reiserfs_read_super: can not find reiserfs on ramdisk (1,0)
>     Kernel panic: VFS: Unable to mount root fs on 00:00

This is the error that everyone has been getting, frankly all it does is
confirm that an initrd does exist somewhere.

Thanks for trying it out. Ben, was that patch supposed to actually fix
something, or was it just supposed to be informative?

-- 
Joshua Kwan

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 881 bytes --]

Re: initrd testing

[Joshua Kwan]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On Fri, May 14, 2004 at 01:56:25PM -0600, Peter Karbaliotis wrote:
> I also saw this on a Sun Ultra 2.
> 
> Sun Ultra 2 UPA/Sbus (2 x UltraSPARC 200 MHz)
> ...
> loaded kernel version 2.4.26
> Loading initial ramdisk ( 1477684 bytes at 0x01x phys, 0x60800000 virt)
> ...
> RAMDISK: Couldn't find valid RAM disk image starting at 0
> Freeing initrd memory: 1443k freed
> cramfs: wrong magic
> sh-2021: reiserfs_read_super: can not find reiserfs on ramdisk (1,0)
> kernel panic: VFS: Unable to mount root fs on 00:00
>   Press L1-A to return to the boot prom
> 
> 
> The 20040511 daily image boots up fine on this system.

Erk. That's a _regression_! Not good... Ben, did your patch interfere
with anything that would have made this not work? Also, this is CDROM,
right? Also, did you use a netinst/businesscard image, the
cdrom-mini.iso, or what?

I tried a boot floppy on my sparc32 box. It seemed to boot OK, but
possibly because SILO is not responible for the initrd for floppy
installs.

-- 
Joshua Kwan

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 881 bytes --]

Re: initrd testing

[Ben Collins]

> Thanks for trying it out. Ben, was that patch supposed to actually fix
> something, or was it just supposed to be informative?

Both.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: initrd testing

[Peter Karbaliotis]

Joshua Kwan wrote:
> On Fri, May 14, 2004 at 01:56:25PM -0600, Peter Karbaliotis wrote:
> 
>>I also saw this on a Sun Ultra 2.
>>
>>Sun Ultra 2 UPA/Sbus (2 x UltraSPARC 200 MHz)
>>...
>>loaded kernel version 2.4.26
>>Loading initial ramdisk ( 1477684 bytes at 0x01x phys, 0x60800000 virt)
>>...
>>RAMDISK: Couldn't find valid RAM disk image starting at 0
>>Freeing initrd memory: 1443k freed
>>cramfs: wrong magic
>>sh-2021: reiserfs_read_super: can not find reiserfs on ramdisk (1,0)
>>kernel panic: VFS: Unable to mount root fs on 00:00
>>  Press L1-A to return to the boot prom
>>
>>
>>The 20040511 daily image boots up fine on this system.
> 
> 
> Erk. That's a _regression_! Not good... Ben, did your patch interfere
> with anything that would have made this not work? Also, this is CDROM,
> right? Also, did you use a netinst/businesscard image, the
> cdrom-mini.iso, or what?
> 
> I tried a boot floppy on my sparc32 box. It seemed to boot OK, but
> possibly because SILO is not responible for the initrd for floppy
> installs.
> 

cdrom-mini.iso from your daily build.

-- 
Peter.Karbaliotis@ualberta.ca	780-492-7660
Computing and Network Services	University of Alberta

Re: initrd testing

[Ben Collins]

> Loading initial ramdisk ( 1477684 bytes at 0x01x phys, 0x60800000 virt)

Ok, there's a new second.b on sparc-boot.org/pub/testing/. Give that a
shot.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: initrd testing

[Joshua Kwan]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

On Sat, May 15, 2004 at 06:46:50AM -0400, Ben Collins wrote:
> Ok, there's a new second.b on sparc-boot.org/pub/testing/. Give that a
> shot.

Updated images with this second.b are at

http://june.voxel.net/~joshk/d-i/images/2004-05-15

Remember, the images from gluck.debian.org don't contain a patched
kernel or second.b.

-- 
Joshua Kwan

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 881 bytes --]

Re: initrd testing

[Patrick Morris]

For what it's worth, I get the same thing reported earlier when trying 
this image on my Ultra 5:

NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Couldn't find valid RAM disk image starting at 0.
Freeing initrd memory: 1442 freed
cramfs: wrong magic
sh-2021: reiserfs_read_super: can not find reiserfs on ramdisk(1,0)
Kernel panic: VFS: Unable to mount root fs on 00:00
 Press L1-A to return to the boot prom

Joshua Kwan wrote:

>Updated images with this second.b are at
>
>http://june.voxel.net/~joshk/d-i/images/2004-05-15
>
>Remember, the images from gluck.debian.org don't contain a patched
>kernel or second.b.
>
>  
>

Re: initrd testing

[Ben Collins]

On Sun, May 16, 2004 at 11:21:01PM -0700, Patrick Morris wrote:
> For what it's worth, I get the same thing reported earlier when trying 
> this image on my Ultra 5:
> 
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> RAMDISK: Couldn't find valid RAM disk image starting at 0.
> Freeing initrd memory: 1442 freed
> cramfs: wrong magic
> sh-2021: reiserfs_read_super: can not find reiserfs on ramdisk(1,0)
> Kernel panic: VFS: Unable to mount root fs on 00:00
> Press L1-A to return to the boot prom

I need the line that silo prints out about where it is locating the
initrd in memory.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: initrd testing

[Ben Collins]

On Mon, May 17, 2004 at 07:50:44AM -0700, Patrick Morris wrote:
> boot:
> Allocated 8 Megs of memory at 0x40000000 for kernel
> Uncompressing image...
> Loaded kernel version 2.4.26
> Loading initial ramdisk (1477459 bytes at 0x10C00000 phys, 0x40C00000 
> virt)...
> Remapping the kernel... Done
> Booting Linux

Ok, that looks correct. Now the question is why isn't the kernel doing
the right thing.

Do the cdrom images have bootmem debug enabled in the kernels? If so,
I'd like to see what bootmem-debug says about the pages it is reserving
for the initrd.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: initrd testing

[Ben Collins]

> >>RAMDISK: Couldn't find valid RAM disk image starting at 0.
> >>Freeing initrd memory: 1442 freed
> >>cramfs: wrong magic

Wait a second. Is this ramdisk really cramfs, or is it romfs?

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: initrd testing

[Patrick Morris]

boot:
Allocated 8 Megs of memory at 0x40000000 for kernel
Uncompressing image...
Loaded kernel version 2.4.26
Loading initial ramdisk (1477459 bytes at 0x10C00000 phys, 0x40C00000 
virt)...
Remapping the kernel... Done
Booting Linux

Ben Collins wrote:

>On Sun, May 16, 2004 at 11:21:01PM -0700, Patrick Morris wrote:
>  
>
>>For what it's worth, I get the same thing reported earlier when trying 
>>this image on my Ultra 5:
>>
>>NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
>>RAMDISK: Couldn't find valid RAM disk image starting at 0.
>>Freeing initrd memory: 1442 freed
>>cramfs: wrong magic
>>sh-2021: reiserfs_read_super: can not find reiserfs on ramdisk(1,0)
>>Kernel panic: VFS: Unable to mount root fs on 00:00
>>Press L1-A to return to the boot prom
>>    
>>
>
>I need the line that silo prints out about where it is locating the
>initrd in memory.
>
>  
>

Re: initrd testing

[Peter Karbaliotis]

Sun Ultra 1 (uniprocessor UltraSPARC):
Loading initital ramdisk (1477740 bytes at 0x20800000 phys 0x40c00000 virt)

Sun Ultra Enterprise 2 (dual processor UltraSPARC):
Loading initital ramdisk (1477740 bytes at 0x60800000 phys 0x40c00000 virt)

Panics with the same message as before:

> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> RAMDISK: Couldn't find valid RAM disk image starting at 0.
> Freeing initrd memory: 1442 freed
> cramfs: wrong magic
> sh-2021: reiserfs_read_super: can not find reiserfs on ramdisk(1,0)
> Kernel panic: VFS: Unable to mount root fs on 00:00
> Press L1-A to return to the boot prom

-- 
Peter.Karbaliotis@ualberta.ca	780-492-7660
Computing and Network Services	University of Alberta

Re: initrd testing

[Joshua Kwan]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

On Mon, May 17, 2004 at 10:40:11AM -0400, Ben Collins wrote:
> > >>RAMDISK: Couldn't find valid RAM disk image starting at 0.
> > >>Freeing initrd memory: 1442 freed
> > >>cramfs: wrong magic
> 
> Wait a second. Is this ramdisk really cramfs, or is it romfs?

Neither. It's gzipped ext2.

-- 
Joshua Kwan

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 881 bytes --]

Re: initrd testing

[Patrick Morris]

Hope nobody's been waiting for a reply from me on this one...  Since I 
can't get it to boot, I've got a dead Ultra 5 (well, a couple, 
actually), and I really couldn't say what kernel options are included, 
or what fs was used for the initial ramdisk. If it helps, though,  I'll 
poke around on the CD a bit more and see if I can come up with answers 
to those questions -- I'm as eager as anyone to see this one finally 
worked out.

Ben Collins wrote:

>Do the cdrom images have bootmem debug enabled in the kernels? If so,
>I'd like to see what bootmem-debug says about the pages it is reserving
>for the initrd.
>  
>