If you need to unpack minirt.gz after creating the cpio image - :
Perhaps there is a better way, but this seems to workCode:gzip minirt.gz cat minirt | (cpio -i -d -m; cpio -i -d -m)
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
Setup our initramfs working directory, copy and clean upCode:# cd /path/to/working/directory # mkdir miniroot-initrd # cp /path/to/minirt.gz . # gunzip minirt.gz # mount -o loop minirt miniroot-initrd
Ensure initramfs requirements are met with initCode:# mkdir miniroot-initramfs # cp -Rp miniroot-initrd/* miniroot-initramfs/ # umount ./miniroot-initrd # rmdir ./miniroot-initrd
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 /initCode:# cd miniroot-initramfs # touch init # chmod +x init # vi init
Add the following text and save
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)Code:#!/static/ash /linuxrc exec /etc/init "$@" </dev/console >/dev/console 2>&1
Lastly we need to compress the miniroot environment to the minirt.gz that we know so well
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!!Code:# find . | cpio --quiet -o -H newc | gzip -9 > ../minirt.gz # cd ..
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.
If you need to unpack minirt.gz after creating the cpio image - :
Perhaps there is a better way, but this seems to workCode:gzip minirt.gz cat minirt | (cpio -i -d -m; cpio -i -d -m)
Is that supposed to be 'gunzip minirt.gz' before that 'cat minirt'?Originally Posted by pracsec
Yes, typo.Originally Posted by meatwad
[quote="meatwad"]Your method seems too complicated for me, so this is how I do this:Originally Posted by pracsec
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:gunzip minirt.gz cpio -i < minirt
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!Code:find . | cpio --quiet -o -H newc | gzip -9 > ../minirt.gz
-tapsa-
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:
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.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
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
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.
IBM System X3500 M4 7383AC1 (E5-2650 v2 2.60GHz - 192GB RAM - M2000 - NO OS/HDD)
$264.92
IBM Power S822 12-Bay Server System Power8 Core 3.42Ghz DVD-Rom Drive 64GB No HD
$399.99
IBM 7944AC1 System x3550 M3 Server 1*Intel Xeon X5650 2.67GHz 4GB SEE NOTES
$27.25
IBM Power 740 8205-E6C Express 8-SFF Power7 3.55GHz CPU 64GB RAM *No HDD* Server
$191.99
Lenovo IBM x3500 M5 Tower Server E5-2670 V3 2.30GHz
$999.99
IBM System x3250 M4 Server Intel Xeon E3-1220 3.10GHz 8GB RAM No HDDs
$65.02
IBM Power 720 POWER7 00E6516 3.6GHz CPU 64GB RAM Server
$209.98
IBM Lenovo X3650 M5 2U 8x 2.5” CTO Rack Server – 2x HS, 2x 750W
$199.00
IBM 8203 E4A p520 Server 8203-E4A 4.2GHz 2-Core POWER6 32GB RAM / NO HDD USED
$99.99
IBM System x3250 M1 1U Server Intel Pentium D @3.4 2GB RAM x2 250GB DRIVES NO OS
$27.99