HOWTO: Converting your minirt.gz from initRD to initRAMFS

**firnsy** · 11-29-2005, 02:55 AM

HOWTO: Converting your minirt.gz from initRD to initRAMFS

Change Log:
* Version 1.3 - Mon Aug 21, 2006
Spelling corrections (Linuxgamer)

* Version 1.2 - Thu Feb 23, 2006
Ammended some grammar.

* Version 1.1 - Tue Nov 29, 2005
A little bit of clarification and restructuring.

* Version 1.0 - Tue Nov 28, 2005
Initial write

Disclaimer:
Always needed cause you just never know how people will interpret things. Please people, use this at your own risk. Whilst this method has and continues to work for me, I will not be held responsible for anything that might go wrong, due to an ommision or typo in this document. I too, like you, am human and do make mistakes.

initRD vs initRAMFS:
initRAMFS is, as it's described in the kernel documentation, 'a chunk of code that unpacks the compressed cpio image midway through the kernel boot process.' The files contained within that image are then used to populate the root filesystem. Initramfs is a part of a bigger concept called 'early-userspace'. It's described in detail in <kernel-sources>/Documentation/early-userspace/. The general idea is "if it can be kept out of the kernel, let it stay that way".

I'm not going into any huge debate about the pros and cons of these two but one thing I will mention is that initRD is old generation and there are plans to supersede it. "With what?" you ask. Currently there are two options being looked at that I know of, one is yaird (name speaks for itself) and the other is initramfs (which I will be talking about here). If you want to know more try Google but for now there is a Debian comparison available at http://wiki.debian.org/InitrdReplacementOptions

With initramfs you'll not notice any significant differences, in fact if you install it correctly, you should not notice any changes.

Why?
Simple really, firstly I was tired of upgrading the kernel and replacing the unionfs.ko module with the latest revision and getting all those out of space errors becuase it was to big to fit in minirt. Secondly, I've added the fbsplash patch, to to my distro and to get the live splash screen working required an initramfs image.

Another benefit that comes out of it for me, is that I can edit my miniroot image at any time, and rebuild it with one line of code. There is no immediate size limitations and i'm all for making things easier and simpler.

What are we going to replace/upgrade:
From my experience, in short, the steps are:

For the compressed filesystem (ie chroot environment, /source)
1. Extract and mount the initrd miniroot
2. Copy the files from the initrd to an initramfs working directory
3. Add the init script
4. Compress the initramfs miniroot

Easy, huh ... let's get our fingers dirty.

Extract and mount the miniroot

Code:

# cd /path/to/working/directory
# mkdir miniroot-initrd
# cp /path/to/minirt.gz .
# gunzip minirt.gz
# mount -o loop minirt miniroot-initrd

Setup our initramfs working directory, copy and clean up

Code:

# mkdir miniroot-initramfs
# cp -Rp miniroot-initrd/* miniroot-initramfs/
# umount ./miniroot-initrd
# rmdir ./miniroot-initrd

Ensure initramfs requirements are met with init

Code:

# cd miniroot-initramfs
# touch init
# chmod +x init
# vi init

Note we are creating an init file in the root directory of the miniroot image. Unlike an initRD image that looks for /linuxrc an initRAMFS image looks for /init

Add the following text and save

Code:

#!/static/ash
/linuxrc
exec /etc/init "$@" </dev/console >/dev/console 2>&1

You'll notice that this init may look like the same one in /etc of your miniroot (alternatively you could move that init file from /etc to /, if it exists that is)

Lastly we need to compress the miniroot environment to the minirt.gz that we know so well

Code:

# find . | cpio --quiet -o -H newc | gzip -9 > ../minirt.gz
# cd ..

And there you have it the one liner that takes your miniroot source tree and generates an initramfs image. Now everytime you have to replace a module or edit the linuxrc script you can just run the last command and get the most recent snapshot of your miniroot working directory. Supoib!!

Closing:
This HOWTO, like my others, will continue to evolve from any constructive feedback received. For now ... use it, abuse it, and let me know what you think.

**pracsec** · 02-21-2006, 01:47 AM

If you need to unpack minirt.gz after creating the cpio image - :

Code:

gzip minirt.gz
cat minirt | (cpio -i -d -m; cpio -i -d -m)

Perhaps there is a better way, but this seems to work

**meatwad** · 02-28-2006, 02:22 AM

Originally Posted by pracsec

If you need to unpack minirt.gz after creating the cpio image - :

Code:

gzip minirt.gz
cat minirt | (cpio -i -d -m; cpio -i -d -m)

Perhaps there is a better way, but this seems to work

Is that supposed to be 'gunzip minirt.gz' before that 'cat minirt'?

**pracsec** · 03-09-2006, 05:41 PM

Originally Posted by meatwad

Originally Posted by pracsec

If you need to unpack minirt.gz after creating the cpio image - :

Code:

gzip minirt.gz
cat minirt | (cpio -i -d -m; cpio -i -d -m)

Perhaps there is a better way, but this seems to work

Is that supposed to be 'gunzip minirt.gz' before that 'cat minirt'?

Yes, typo.

tr · 03-11-2006, 08:28 AM

[quote="meatwad"]

Originally Posted by pracsec

If you need to unpack minirt.gz after creating the cpio image - :

Your method seems too complicated for me, so this is how I do this:

Code:

gunzip minirt.gz
cpio -i < minirt

Now minirt is in the same directory as unpacked minirt - so you can delete it. Then do changes and repack directory to minirt.g as is told in this HOWTO:

Code:

find . | cpio --quiet -o -H newc | gzip -9 > ../minirt.gz

Now you have your minirt.gz in parent directory but also those minirt files existing in the directory where you gzunzipped them for further use. Great!

-tapsa-

tr · 06-15-2006, 06:40 PM

Knoppix 5.0.1 seems to cause some extra problem if using mkinitramfs. Boot process fails in Starting udev hot-plug hardware detection.... It should reply 'started' but now it is 'failed'.

I can bypass that by changing linuxrc:

Code:

  # /dev is a special case, it is now normally handled via udev
#  UNIONDEV=""
#  case "$CMDLINE" in *noudev*) UNIONDEV="dev"; ;; esac
#  for i in bin boot etc $UNIONDEV sbin var lib opt root usr; do # Move directories to unionfs
 for i in bin boot dev etc sbin var lib opt root usr; do # Move directories to unionfs

As you can see that last line is from Knoppix 4.0.2 (or from Kanotix - don't remember) and I had to comment 'UNIONDEV' section out from new Knoppix 5.0.1's linuxrc.

How could this be fixed? I don't find any better solution myself. I don't know exactly what this can cause but I noticed that Ctrl-O in Midnight Commander clears the screen in virtual consoles. It don't do that using original Knoppix 5.0.1's minirt.gz file with initrdfs.

Should init file be modified? Now my init file is:

Code:

#!/static/ash
/linuxrc
exec /etc/init "$@" </dev/console >/dev/console 2>&1

**firnsy** · 06-16-2006, 04:41 AM

It would appear that when udev is used in 5.0.1 then the /dev is not copied accross but rather entirely created dynamically during the bootup process. I don't think it is a problem of initRAMFS itself but something to do with the udev startup scripts.

I'll download 5.0.1 and give it a go.