Hi I had some doubts regarding what all the init application should do:>> so, that should that application do? >> - mount /dev/hda1 /new-root >> - cd /new-root >> - run-init1. Of what I understand, before exitting, init should mount the realroot and execute the init process. Is realroot the '/' or the empty directory created (in the cpio archive) ? How should I go about it? Using pivot_root, chroot ...? Am not very clear with these. 2. At the time init(from initrmafs) is called, is there any file system mounted? Thanks Rachita.
On Mon, 2005-02-14 at 15:54 +0530, Rachita Kothiyal wrote:> I had some doubts regarding what all the init application should do: > > >> so, that should that application do? > >> - mount /dev/hda1 /new-root > >> - cd /new-root > >> - run-init > 1. Of what I understand, before exitting, init should mount the realroot > and execute the init process. > Is realroot the '/' or the empty directory created (in the cpio > archive) ?initramfs has / as root. the real root (i.e. the root for your real system) is whatever you mount whereever you mount it. above commands mount "/dev/hda1" to the empty directory "/new-root".> How should I go about it? Using pivot_root, chroot ...? Am not very > clear with these.no, use "run-init", it is an utility program included in klibc.> 2. At the time init(from initrmafs) is called, is there any file system > mounted?yes, / is a tmpfs and the content are the files that where in the initramfs cpio. unlike initrd this initramfs is writeable, so you can do any changes and create any number of new files (up to your ram max.) also unlike initrd - as far as I know - there is no size contraint. I have some 8+ MB initramfs based on glibc and they work fine. Good luck! Andreas -- ---------------------[ Ciphire Signature ]---------------------- From: aj@ciphirelabs.com signed email body (987 characters) Date: on 14 February 2005 at 11:39:12 UTC To: rachitako@in.ibm.com, klibc@zytor.com ---------------------------------------------------------------- : Ciphire has secured this email against identity theft. : Free download at www.ciphire.com. The garbled lines : below are the sender's verifiable digital signature. ---------------------------------------------------------------- 00fAAAAAEAAADgjRBC2wMAABoDAAIAAgACACCFlK4A+54we7zwPJsjFBflkYBMj+ KIfUWI8cEb4zJitwEAjuLZDHPnOxRgKfQyXaVwrQqQB78iLphbN7mW+8mUnEE+5Q BAGxPU2spXsYQto0PWBrxnMtRLKb5Yp0b+fcotHQ=------------------[ End Ciphire Signed Message ]----------------
> How should I go about it? Using pivot_root, chroot ...? Am not very > clear with these.>> no, use "run-init", it is an utility program included in klibc.In the run-init.c, I am passing my /newroot as the realroot. It does a chdir(realroot) fine. But, it fails in the check being done by the stat() and the kernel panics. Following is the error message I get: (null): Current directory on the same filesystem as root: Success Kernel panic: Not Syncing: Attempted to kill init! Both rst.st_dev and cst.st_dev have the value '1'. Does this mean they are associated with the same device? Can you please explain why I might be getting this error. My initramfs.cpio.gz contains run-init.o(as init), /dev/hda1, /dev/console, /newroot. As of now my init(of initramfs) does'nt do anything. After it starts executing, it tries mounting the real root so that the real init can further be run on it. But it is failing in the first step itself(ie mounting the realroot) as listed above. I shall be very grateful if you can pls. tell me where I am going wrong. Thanks Rachita.
Hi Andreas,>> you need to mount something to /newroot.>> the run-init.c in klibc expects that this has already been done.>> so insert a mount() call somewhere in the main() function, for examplemount("/dev/hda1","/newroot","ext2",MS_RDONLY,NULL);>> should work (untested).Using the above, I have been able to mount newroot as root. But the system gets lost in trying to exec 'init' (the last line in run-init.c). I am using /sbin/init for init and am passing NULL as the arguments to execv(). It simply hangs there. The exec call is not failing though. Could you pls. tell me what I am missing... Are there more things that need to be set before exec'ing init? Thanks Rachita.
Hi Rachita, known issue: if you do pivot_root on an initramfs, and you try to unmount the /initrd (original initramfs), the linux kernel will crash. I think that is a bug, and should be fixed, but as far as I know there is no progress. But you shoudln't do that anyway. Replace pivot_root with run-init from klibc distribution, and you don't have that problem. try to put back the mount calls from the original run-init.c instead of the pivot_root and you should be fine. Good luck! Regards, Andreas -- ---------------------[ Ciphire Signature ]---------------------- From: aj@ciphirelabs.com signed email body (412 characters) Date: on 22 February 2005 at 15:03:28 UTC To: klibc@zytor.com ---------------------------------------------------------------- : Ciphire has secured this email against identity theft. : Free download at www.ciphire.com. The garbled lines : below are the sender's verifiable digital signature. ---------------------------------------------------------------- 00fAAAAAEAAADASRtCnAEAAIACAAIAAgACACCFlK4A+54we7zwPJsjFBflkYBMj+ KIfUWI8cEb4zJitwEAjuLZDHPnOxRgKfQyXaVwrQqQB78iLphbN7mW+8mUnEEzus 04n2WsTXpgGtW+SkzjRw684zhyBWG9VcGc4PoAiw=------------------[ End Ciphire Signed Message ]----------------
Hi Andreas
I am now able to exec the real init on the real root.
But, I still have a problem:
While doing a reboot (from the system booted via initramfs), it stops
responding with the following messages on display:
Starting killall OK
Turning off swap OK
Turning off quotas OK
Unmounting file systems
After doing a chdir(realroot),
I have used pivot_root(".", "dump-iniitramfs") in the
run-init to change
the root to /newroot (this is the realroot).
Of what I understand, this shd mount /newroot as "/" and shd move the
"/"
of the running process, which is the /initramfs to /dump-initramfs.
After this, I exec the real init. This too works fine.
I suspect the problem is with the 'dump-initramfs'. Even if I try doing
a "
rm -rf /dump-initramfs " after the system comes up, it gives me an error
saying, "the device or resource is busy". Are there some processes
still
accesing the old-root which is keeping it busy ?
Kindly tell me what I might be missing..Thanks in advance.
Am sending along the run-init.c ( have made my changes in this file itself)
and the initramfs cpio archive.
Thanks
Rachita.
(See attached file: initramfs.cpio.gz) (See attached file:
run-init-mod2.c)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: initramfs.cpio.gz
Type: application/octet-stream
Size: 209379 bytes
Desc: not available
Url :
http://www.vas.nu/pipermail/klibc/attachments/20050222/61fae752/initramfs.cpio-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run-init-mod2.c
Type: application/octet-stream
Size: 7360 bytes
Desc: not available
Url :
http://www.vas.nu/pipermail/klibc/attachments/20050222/61fae752/run-init-mod2-0001.obj
Hi Andreas,>> known issue: >> if you do pivot_root on an initramfs, and you try to unmount >> the /initrd (original initramfs), the linux kernel will crash. >> I think that is a bug, and should be fixed, but as far as I know >> there is no progress.>> But you shoudln't do that anyway. Replace pivot_root with >> run-init from klibc distribution, and you don't have that >> problem.>> try to put back the mount calls from the original run-init.c >> instead of the pivot_root and you should be fine.Did this. It works fine now. Thanks a lot for your help. Thanks Rachita.