RAM DISK error with new kernel

[lagagnon]

I am remastering VL6.0 Standard with the newer 2.6.30.3 kernel, via the repository packages. All is well. My only concern now is an error in dmesg (which does not seem to affect system performance) but is still a concern. Here is dmesg output (grep on RAM) from a standard distro with the old kernel:

Code:

BIOS-provided physical RAM map:
Phoenix BIOS detected: BIOS may corrupt low RAM, working it around.
  mapped low ram: 0 - 38000000
  low ram: 00000000 - 38000000
  #1 [0000001000 - 0000002000]    EX TRAMPOLINE ==> [0000001000 - 0000002000]
  #2 [0000006000 - 0000007000]       TRAMPOLINE ==> [0000006000 - 0000007000]
Security Framework initialized
vesafb: framebuffer at 0xe0000000, mapped to 0xf8d00000, using 6144k, total 131072k
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
TuxOnIce: Resume= parameter is empty. Hibernating will be disabled.
ReiserFS: hda5: journal params: device hda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
TuxOnIce: Resume= parameter is empty. Hibernating will be disabled.
ReiserFS: hda6: journal params: device hda6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30

And here is the same dmesg output with the new kernel:

Code:

BIOS-provided physical RAM map:
Phoenix BIOS detected: BIOS may corrupt low RAM, working around it.
RAMDISK: 00eab000 - 00eff7b0
 mapped low ram: 0 - 377fe000
   low ram: 0 - 377fe000
   node 0 low ram: 00000000 - 377fe000
   #1 [0000001000 - 0000002000]    EX TRAMPOLINE ==> [0000001000 - 0000002000]
   #2 [0000006000 - 0000007000]       TRAMPOLINE ==> [0000006000 - 0000007000]
   #4 [0000eab000 - 0000eff7b0]          RAMDISK ==> [0000eab000 - 0000eff7b0]
Security Framework initialized
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (junk in compressed archive); looks like an initrd
vesafb: framebuffer at 0xe0000000, mapped to 0xf8500000, using 3072k, total 131072k
fb0: VESA VGA frame buffer device
RAMDISK: Couldn't find valid RAM disk image starting at 0.
REISERFS (device hda7): journal params: device hda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
rtc0: alarms up to one year, y3k, 242 bytes nvram
REISERFS (device hda8): journal params: device hda8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
REISERFS (device hda6): journal params: device hda6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
REISERFS (device hda5): journal params: device hda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30

I am concerned about the rootfs image is not initramfs (junk in compressed archive); looks like an initrd message and this: RAMDISK: Couldn't find valid RAM disk image starting at 0.

I wonder if /boot/initrd needs updating and if so how do I do that as "mkinitrd" is not supplied. Any ideas on what this message really means and how to fix it or should I not concern myself about it?

Larry

[uelsk8s]

initramfs is the new cpio initrd format.
the old one works just fine, you just get these errors
if you want to create a cpio initrd from the current initrd you need to unzip the initrd, mount it then extract it to a folder and run

Code:

find ./ | cpio -H newc -o |gzip -c9 >../initrd.img

from inside the folder you copied all the files into

HTH,
Uelsk8s

[Matt John]

I see you are using ram with 16MB disk size and actual this is far too little.

Database sizes today:
45M 14. Mai 18:00 main.cld
3,8M 12. Aug 20:00 daily.cld

If you take a look at output errror message, you can see: Can't unpack CVD file
and this is not a ext2, or havp related problem!

Update:  Sorry for my mistaken, I have to correct myself, I took a look on a system, where I'm running havp with ramdisk size 8MB! Used size is 1,5M and using ext3. But I remember, it was a little bit trickly to get it running. Perhaps a user right problem?

This is a part of my init script, to get it running:

Code:
                        echo -n "Creating File System and starting HAVP ..."
                        /sbin/mkfs.ext3 /dev/ram0
                        sleep 2
                        `mount /dev/ram0 /var/tmp/havp -o mand`
                        `chown -R clamav:clamav /var/tmp/havp/`
                        $HAVP_BIN -c $HAVP_CONFIG




Code:
/dev/ram0             7,8M  1,5M  6,0M  20% /var/tmp/havp