Re: /linuxrc query

Re: /linuxrc query

[Stuart Lynne]

In article <985356959.24859@whiskey.enposte.net>,
David Woodhouse <dwmw2@infradead.org> wrote:
>amit@muppetlabs.com said:
>>  Also as a note, what we are doing is keeping our rootfs on flash as a
>> tar.gz and  reading it and mounting it on a ramfs in the /linuxrc
>> before doing a pivot_root.  To summarize, pivot_root has been a life
>> saver as the earlier real_root_dev  might not have been useful in this
>> case. Not using the ramfs limits for now, will do soon.
>
>If you're concerned about memory usage - why untar the whole of your root
>filesystem into a ramfs? My preferred solution is to just mount the root
>filesystem directly from the flash as cramfs (or JFFS2), with symlinks into a
>ramfs for appropriate parts like /tmp and /var.
>
>I suppose the best option is actually to union-mount the ramfs over the 
>root, rather than mucking about with symlinks. I just haven't got round to 
>doing that yet.

Union would be fine. But until then I prefer ramfs as root with symlinks
to cramfs for anything that doesn't need to be writeable. 

-- 
                                            __O 
Lineo - For Embedded Linux Solutions      _-\<,_ 
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <sl@fireplug.net>       www.fireplug.net        604-461-7532

Re: /linuxrc query

[Amit D Chaudhary]

Werner Almesberger wrote:

> Amit D Chaudhary wrote:
>> But other information in the 
>> initrd.txt mentions otherwise, hence the query here.
> 
> 
> Hmm, sounds like a bug. Where did you find this ?
I quote from the version in linux-2.4.2-ac22
"
Now, the initrd can be unmounted and the memory allocated by the RAM
disk can be freed:

# umount /initrd
# blockdev --flushbufs /dev/ram0    # /dev/rd/0 if using devfs
"

I guess I assumed the above has to be put in /linuxrc as it follows other 
commands which do go in the /linuxrc. The assumption is not quite correct as I 
have since found out.

Regards
Amit

Re: /linuxrc query

[David Woodhouse]

amit@muppetlabs.com said:
>  Also as a note, what we are doing is keeping our rootfs on flash as a
> tar.gz and  reading it and mounting it on a ramfs in the /linuxrc
> before doing a pivot_root.  To summarize, pivot_root has been a life
> saver as the earlier real_root_dev  might not have been useful in this
> case. Not using the ramfs limits for now, will do soon.

If you're concerned about memory usage - why untar the whole of your root
filesystem into a ramfs? My preferred solution is to just mount the root
filesystem directly from the flash as cramfs (or JFFS2), with symlinks into a
ramfs for appropriate parts like /tmp and /var.

I suppose the best option is actually to union-mount the ramfs over the 
root, rather than mucking about with symlinks. I just haven't got round to 
doing that yet.

--
dwmw2

Re: /linuxrc query

[Werner Almesberger]

Amit D Chaudhary wrote:
> To summarize, pivot_root has been a life saver as the earlier real_root_dev 
> might not have been useful in this case.

The whole old change_root mechanism with real_root_dev is best forgotten
quickly ;-) It's also completely helpless as soon as you fire off some
kernel threads that don't call exit_fs.

> Not using the ramfs limits for now, will do soon.

BTW, if you can't free the RAM disk, you may have to apply
http://icawww1.epfl.ch/~almesber/patches/rdfree

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

Re: /linuxrc query

[Werner Almesberger]

Amit D Chaudhary wrote:
> So, it is not a requirement currently but it is useful to have the script not 
> dependent on the current pivot_root implementation.

Yes. Also note that the relative path for  dev/console  works in
either case, while /dev/console would fail without the implied
chroot in pivot_root.

> But other information in the 
> initrd.txt mentions otherwise, hence the query here.

Hmm, sounds like a bug. Where did you find this ?

> I am assuming umount and thereby blockdev after pivot_script and before
> "chroot . init ..." don't make sense as files(dev/console among others)
> are\might still be in use.

Exactly. They's in use in any case until you close and re-open the
console.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

Re: /linuxrc query

[Amit D Chaudhary]

Hi,

Also as a note, what we are doing is keeping our rootfs on flash as a tar.gz and 
reading it and mounting it on a ramfs in the /linuxrc before doing a pivot_root. 
To summarize, pivot_root has been a life saver as the earlier real_root_dev 
might not have been useful in this case.
Not using the ramfs limits for now, will do soon.

Thanks
Amit

Werner Almesberger wrote:

> Amit D Chaudhary wrote:
> 
>> what does redirecting stdin\stdout\stderr to dev/console achieve? I thought 
>> since the root is now the "new" root, dev/console will be used automatically?
> 
> 
> No, you would continue using the file descriptors which are already
> open, i.e. on /dev/console on the old root.
> 
> 
>> Also, why chroot, why not call init directly?
> 
> 
> To make sure the root of the current process is indeed changed.
> pivot_root currently forces a chroot on all processes (except the
> ones that have explicitly moved out of /) in order to move all the
> kernel threads too, but this is not a nice solution. Once a better
> solution is implemented for the kernel threads, we might drop the
> forced chroot, and then the explicit chroot here becomes important.
> 
> 
>> Since the above never returns, what follows in not freed.
> 
> 
> You can run them later, e.g. /etc/rc.d/rc.local
> Or, if you needs the space immediately,  make "what-follows" a
> script than first frees them, and then exec's init.
> 
> - Werner

Re: /linuxrc query

[Amit D Chaudhary]

Hi,

Thanks for the response. PSB,

Werner Almesberger wrote:

> Amit D Chaudhary wrote:
> 
> No, you would continue using the file descriptors which are already
> open, i.e. on /dev/console on the old root.
So, makes sense. And the child process that follow will use now the new fd's.

>> Also, why chroot, why not call init directly?
> 
> 
> To make sure the root of the current process is indeed changed.
> pivot_root currently forces a chroot on all processes (except the
> ones that have explicitly moved out of /) in order to move all the
> kernel threads too, but this is not a nice solution. Once a better
> solution is implemented for the kernel threads, we might drop the
> forced chroot, and then the explicit chroot here becomes important.
So, it is not a requirement currently but it is useful to have the script not 
dependent on the current pivot_root implementation.


> You can run them later, e.g. /etc/rc.d/rc.local
> Or, if you needs the space immediately,  make "what-follows" a
> script than first frees them, and then exec's init.
Sure will put in a script that does it. I had left it in /linuxrc as I thought 
that's what initrd.txt suggested one to do. But other information in the 
initrd.txt mentions otherwise, hence the query here.

I am assuming umount and thereby blockdev after pivot_script and before "chroot 
. init ..." don't make sense as files(dev/console among others) are\might still 
be in use.

Best Regards
Amit

Re: /linuxrc query

[Werner Almesberger]

Amit D Chaudhary wrote:
> what does redirecting stdin\stdout\stderr to dev/console achieve? I thought 
> since the root is now the "new" root, dev/console will be used automatically?

No, you would continue using the file descriptors which are already
open, i.e. on /dev/console on the old root.

> Also, why chroot, why not call init directly?

To make sure the root of the current process is indeed changed.
pivot_root currently forces a chroot on all processes (except the
ones that have explicitly moved out of /) in order to move all the
kernel threads too, but this is not a nice solution. Once a better
solution is implemented for the kernel threads, we might drop the
forced chroot, and then the explicit chroot here becomes important.

> Since the above never returns, what follows in not freed.

You can run them later, e.g. /etc/rc.d/rc.local
Or, if you needs the space immediately,  make "what-follows" a
script than first frees them, and then exec's init.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

/linuxrc query

[Amit D Chaudhary]

Hi,

I have a initrd working, a /linuxrc on it that runs and executes. My question 
for the commands after pivot_root which works like a charm, thanks to initrd.txt,

what does redirecting stdin\stdout\stderr to dev/console achieve? I thought 
since the root is now the "new" root, dev/console will be used automatically? 
Also, why chroot, why not call init directly?
#exec chroot . sbin/init 3 <dev/console >dev/console 2>&1

Since the above never returns, what follows in not freed. Does this mean I have 
around 4-6 mb of ram being used up unnecessarily? Any solution?

#umount /initrd
#blockdev --flushbufs /dev/ram0    # /dev/rd/0 if using devfs


Thanks and Regards
Amit