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.
SanDisk 2TB Ultra 3D NAND SSD, Internal Solid State Drive - SDSSDH3-2T00-G26
$149.99
Western Digital 250GB WD Blue SA510 SATA SSD, Internal M.2 2280 - WDS250G3B0B
$39.99
Team Group 512GB T-FORCE VULCAN Z 2.5" SATA III 3D NAND Internal SSD
$30.99
Patriot P210 128GB 256GB 512GB 1TB 2TB 2.5" SATA 3 6GB/s Internal SSD PC/MAC Lot
$14.99
Intel DC S3510 Series 120GB SSD 2.5" 6Gb/s SATA Solid State Drive SSDSC2BB120G6K
$9.99
Netac 1TB 2TB 512GB Internal SSD 2.5'' SATA III 6Gb/s Solid State Drive lot
$13.99
Fanxiang SSD 512GB 1TB 2TB 4TB 2.5'' SSD SATA III Internal Solid State Drive lot
$13.99
Fanxiang 4TB 2TB 1TB SSD 550MB/s 2.5'' SATA III Internal Solid State Drive lot
$209.99
Fanxiang SSD 512GB 1TB 2TB 4TB 2.5''SATA III Internal Solid State Hard Drive LOT
$269.98