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.
HP ProLiant DL360 G9 Server | 2 x E5-2660V3 2.6Ghz | 64GB | 2 x 900GB SAS HDD
$339.00
H261-Z61 2U 24SFF AMD Server 8x EPYC 7551 256-Cores 256GB RAM 8x25G NIC 2x2200W
$2612.18
Dell PowerEdge R730 8 SFF 2x E5-2660 v4 28 Cores 128/256GB 0/3x 900GB 6Gbps H730
$349.99
Supermicro 4U 36 Bay Storage Server 2.2Ghz 16-C 128GB 1x1280W Rails TrueNAS ZFS
$716.98
Dell PowerEdge R730XD 28 Core Server 2X Xeon E5-2680 V4 H730 128GB RAM No HDD
$389.99
Dell PowerEdge R620 Server 2x E5-2660 v1 2.2GHz 16 Cores 256GB RAM 2x 300GB HDD
$79.19
HP Proliant DL360 Gen9 28 Core SFF Server 2X E5-2680 V4 16GB RAM P440ar No HDD
$196.95
Dell PowerEdge R720XD Xeon E5-2680 V2 2.8GHz 20 Cores 256GB RAM 12x4TB
$510.00
1U Supermicro Server 10 Bay 2x Intel Xeon 3.3Ghz 8C 128GB RAM 480GB SSD 2x 10GBE
$297.00
DELL R730XD Server 2x E5-2680v4 2.4GHz =28 Cores 128GB H730 4x 1.2TB SAS 4xRJ45
$504.00