LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 04-06-2010, 10:50 AM   #1
rainzone
LQ Newbie
 
Registered: Jun 2009
Location: Rochester, NY, USA
Posts: 9

Rep: Reputation: 0
ramdisk corrupted, only after booting with it (RHEL53)


I'm creating a ramdisk image (of a small custom root filesystem with
Red Hat Enterprise Linux 5.3) using genext2fs. I'm net booting that
image using PXE and using it as a permanent file system (rather than as
a temporary -- it never pivots to a hard drive boot).

That's been working fine for months (I thought), but I just found out that the ramdisk, after booting, has a small amount of corruption on it.
When I run fsck it shows about 10 i_block errors, one i_size error, and a multiply-referenced block. It's able to repair the errors, but they will be there again every time the ramdisk image reboots.

I've verified that the ramdisk image itself is not corrupt by mounting it and testing it. It always looks fine -- no corruption. But when I use it to boot, when the boot is finished the mounted root file system is corrupt (again, not totally corrupt, just containing these 12 or so repairable errors). This is true when booting normally via PXE, AND I also booted the image from the local disk using GRUB just to rule out any problems with the network boot (since the boot host is Solaris).

Either way, if it boots, it's corrupt. If it's mounted without boot (using mount -o loop), it's fine. So it seems there is something about the RHEL53 boot process that is causing the corruption.
This occurs on multiple machines, so I don't think it's hardware.

Here are the parameters I'm using for the PXE boot in pxelinux.cfg/default:

kernel vmlinuz-2.6.18-128.el5
append initrd=ramdisk.img.gz root=/dev/ram0 ramdisk_blocksize=1024 ramdisk_size=256000

Any suggestions would be most welcome!

Thank you!
Sean
 
Old 04-06-2010, 06:17 PM   #2
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,399
Blog Entries: 2

Rep: Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908
Could it be as simple as a mismatch between the ramdisk_size kernel argument and the actual size of the ramdisk? What is the size of the file? How did you arrive at 256000 as the specified size? Are there any undesirable symptoms, or is it benign, so far?

--- rod.
 
Old 04-07-2010, 08:14 AM   #3
rainzone
LQ Newbie
 
Registered: Jun 2009
Location: Rochester, NY, USA
Posts: 9

Original Poster
Rep: Reputation: 0
Rod,

Thanks for the suggestion. The size of the ramdisk (262144000 bytes) matches the kernel argument (256000 KB).
Maybe it would behave better if I make it a round 256 MB. I can try that later today.
There are few symptoms yet (just a screenfull of error messages when my script calls ldconfig, but the ldconfig works okay), but having corruption doesn't bode well for the future (this is going to be running embedded and deployed far afield where I can't keep watch on it).

Thanks!
Sean
 
Old 04-07-2010, 09:06 AM   #4
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,399
Blog Entries: 2

Rep: Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908
I'm not sure of the ramifications (pun somewhat intended) of not supplying a ramdisk_size argument, but I know that it is not always supplied. Perhaps try booting the kernel without that argument. I think it may be a matter of efficiency for the kernel to be advised of the size, but it will still figure out the size on it's own, and perhaps accurately enough that the errors go away (if it is indeed the problem).
Is it a custom ramdisk, or one provided with the distribution? If custom, how was it created? Do you have the possibility of loading the ramdisk & kernel with a different bootloader? Maybe even a different version of the PXE bootloader? My thinking is that since it is the bootloader that 'installs' the ramdisk, it may be part of the problem.

--- rod.

Last edited by theNbomr; 04-07-2010 at 09:10 AM.
 
Old 04-07-2010, 03:54 PM   #5
rainzone
LQ Newbie
 
Registered: Jun 2009
Location: Rochester, NY, USA
Posts: 9

Original Poster
Rep: Reputation: 0
I tried removing the ramdisk_size from the pxelinux.cfg/default file, and it was not happy. Massive errors, trying to read past end of disk, and a kernel panic. So I put that back in.

We created the custom ramdisk with a long script that copies the essential pieces from a full install into a working directory, deletes unneeded stuff, adds in needed /usr/ files, creates the users and a bunch of other stuff, then runs genext2fs to make the working directory into a filesystem image.
I did try booting it both with PXE (network) and with GRUB (local), with the same result.

Thanks,
Sean
 
Old 04-07-2010, 05:11 PM   #6
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,399
Blog Entries: 2

Rep: Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908
Hmm. Isn't a an init ramdisk normally in the form of a compressed cpio archive? From the description of genext2fs, it is creating an image with an ext2 filesystem embedded. I don't know what distinction this creates for the kernel, but it sounds like the two entities must be different. In fact I'm a bit surprised it works at all when I think about it. I suppose if the kernel has a built-in ext2 driver module, it would understand the image, but perhaps something else doesn't know how to deal with ext2 in RAM. Sorry to be so imprecise; I'm kind of thinking out loud here.
--- rod.
 
Old 04-08-2010, 08:07 AM   #7
rainzone
LQ Newbie
 
Registered: Jun 2009
Location: Rochester, NY, USA
Posts: 9

Original Poster
Rep: Reputation: 0
Good catch. Yes, I think the kernel looks in the ramdisk and sees it's an ext2 filesystem and does have a driver for that. But it's definitely worth a try to create the ramdisk as a cpio archive instead. Maybe there are bugs in that driver, or in some executables that are (perhaps) trying to access the filesystem in a non-standard way.

Do you know of a good tool to generate a cpio archive? I'm about to google it, of course.

Thanks!!!
Sean
 
Old 04-08-2010, 08:20 AM   #8
Skaperen
Senior Member
 
Registered: May 2009
Location: center of singularity
Distribution: Xubuntu, Ubuntu, Slackware, Amazon Linux, OpenBSD, LFS (on Sparc_32 and i386)
Posts: 2,684
Blog Entries: 31

Rep: Reputation: 176Reputation: 176
The kernel can handle both an initial ramdisk and initial ramfs. It can get either a disk image filesystem from the bootloader (creates a ramdisk) or a compressed cpio image (creates a ramfs). The latter is the preferred method and is often used even with the wrong terminology attached (e.g. they say "ramdisk" and you get "ramfs"). Additionally, the kernel can be built with the compressed cpio image built-in. If both a kernel initramfs image and a boot loader provided initramfs image are there, they will be merged (been there, done that, a couple years ago) before the "/linuxrc" program is run (handy to tweak files otherwise built into the kernel initramfs image without having to rebuild a kernel every time, when doing testing).

The initramfs approach, with a compressed cpio image, is the preferred method these days. It has fewer issues (size does not needed to be coordinated) and more flexibility. It's the way to go for any new projects.
 
Old 04-08-2010, 08:31 AM   #9
Skaperen
Senior Member
 
Registered: May 2009
Location: center of singularity
Distribution: Xubuntu, Ubuntu, Slackware, Amazon Linux, OpenBSD, LFS (on Sparc_32 and i386)
Posts: 2,684
Blog Entries: 31

Rep: Reputation: 176Reputation: 176
The kernel build uses a special cpio tool that uses a control file to specify what files go into the image, where to get them from, and what their metadata is (how a non-root user can create a root-owned file inside that image). It also has ways to create device nodes directly into the image. It is used for making the cpio image that gets built into the kernel (which, BTW, is always there, even if empty, and the kernel always goes through the motions to extract it to the initial ramfs). Grab the latest kernel source tarball and extract it. Files to read include:

Documentation/initrd.txt
Documentation/early-userspace/README
Documentation/early-userspace/buffer-format.txt
Documentation/filesystems/ramfs-rootfs-initramfs.txt

If you want to dig into the kernel logic in how it handles this and starts the user space, change into the "init" subdirectory and read those source files.
 
Old 04-08-2010, 08:35 AM   #10
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,399
Blog Entries: 2

Rep: Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908
I think you can easily roll your own. I do it by creating an on-disk directory structure containing all of the components I want, and then:
Code:
#! /bin/sh
 #
 #
 #   Example usage:
 #   trmkinitrd initrd-2.6.10
 #
 #   A complementary script 'truninitrd' performs the
 #   reverse operation of this script.
 #
 #   $Author:$
 #   $Date:$
 #
 #   $Revision:$
 #
 # ======================================================

 if [ $# -eq 0 -o ! -d $1 ]; then
    echo "Initrd builder"
    echo ""
    echo "Run this script by specifying the name of a "
    echo "directory containg initrd image data as the first argument."
    echo "Usage:"
    echo "trmkinitrd initrd.2.x.y"
    exit 1
 fi


 img=$1

 echo "Creating cpio style image ${img}.img"
 find $1 | cpio --create --format='newc' > ${img}.img

 echo "gzip compressing ${img}.img"
 gzip ${img}.img
 mv ${img}.img.gz ${img}.img

 #   echo "copying to tftp server root"
 #   sudo cp ${img}.img /tftpboot

 echo "Complete"
The 'uninitrd' script:
Code:
#! /bin/sh
 #
 #
 #   Example usage:
 #   truninitrd /boot/initrd-2.6.10.img
 #
 #   A complementary script 'trmkinitrd' performs the
 #   reverse operation of this script.
 #
 #   $Author:$
 #   $Date:$
 #
 #   $Revision:$
 #
 # ======================================================

 if [ $# -eq 0 ]; then
    echo "Initrd unroller"
    echo ""
    echo "Run this script by specifying the name of a "
    echo "compressed initrd image as the first argument."
    echo "The source image will be unrolled into a directory"
    echo "structure in the present working directory. "
    echo "The source image will be left unmodified."
    echo "May require root privileges to create dev/ directories."
    echo "Usage:"
    echo "truninitrd /boot/initrd.2.x.y-zzzz.img"
    exit 1
 fi

 img=`basename $1 .img`
 gzimg=${img}.gz

 echo "Preparing directory structure ${img}"
 if [ ! -d $img ]; then
   mkdir $img
   echo "New base directory $img created"
 else
   rm -rf $img/*
   echo "Removed old directory contents"
 fi

 echo "Uncompressing image"
 cp $1 ${img}/$gzimg
 cd $img
 gunzip $gzimg

 echo "De-archiving cpio archive image"
 cpio -i < $img

 echo "Complete"
--- rod.

EDIT: This was intended as a followup to post #7.

Last edited by theNbomr; 04-08-2010 at 08:36 AM.
 
Old 04-09-2010, 02:39 PM   #11
rainzone
LQ Newbie
 
Registered: Jun 2009
Location: Rochester, NY, USA
Posts: 9

Original Poster
Rep: Reputation: 0
Thank you both for the info!
I'm not sure whether the kernel I'm using
(2.6.18-128.el5PAE) can mount a cpio "ramdisk" as a file system (ramfs?). Maybe I'd have to rebuild the kernel with ramfs support?

I tried making the initrd as you suggested, Rod, but when I boot it I get:

...
md: ... autorun DONE.
No filesystem could mount root, tried ext2 iso9660
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)


I'm not making a temporary initrd, I'm booting, mounting this as my root filesystem, and running with it indefinitely, never switching to a hard disk filesystem.

Sean
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Booting fedora using initial ramdisk Ehsanulhaq Linux - Newbie 2 03-13-2010 07:58 PM
Lilo not booting ramdisk clcbluemont Linux - Software 2 02-26-2009 05:17 PM
Problem booting kernel without initial ramdisk m4mach Linux - General 25 08-03-2007 09:16 AM
booting read only - how do I load /dev files in ramdisk? drkstr Slackware 4 07-19-2006 01:56 AM
Slow booting ramdisk (isolinux) Dark Carnival Linux - General 1 11-09-2004 04:07 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 03:44 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration