In article <[EMAIL PROTECTED]>,
David Woodhouse <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] 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,
On Fri, 23 Mar 2001, Amit D Chaudhary wrote:
> Hi David,
>
> I did consider CRAMFS and JFFS2 when it was announced on the mtd list.
> Conserving flash over system ram is more relevant. Our reasons are below:
>
> RAMFS v/s CRAMFS
> 1. RAMFS is just more stable in terms of less complexity, less
Hi David,
I did consider CRAMFS and JFFS2 when it was announced on the mtd list.
Conserving flash over system ram is more relevant. Our reasons are below:
RAMFS v/s CRAMFS
1. RAMFS is just more stable in terms of less complexity, less bugs reported
over the time, etc.
2. RAMFS is a fairly
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
[EMAIL PROTECTED] 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
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
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
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
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
[EMAIL PROTECTED] 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
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
Hi David,
I did consider CRAMFS and JFFS2 when it was announced on the mtd list.
Conserving flash over system ram is more relevant. Our reasons are below:
RAMFS v/s CRAMFS
1. RAMFS is just more stable in terms of less complexity, less bugs reported
over the time, etc.
2. RAMFS is a fairly
On Fri, 23 Mar 2001, Amit D Chaudhary wrote:
Hi David,
I did consider CRAMFS and JFFS2 when it was announced on the mtd list.
Conserving flash over system ram is more relevant. Our reasons are below:
RAMFS v/s CRAMFS
1. RAMFS is just more stable in terms of less complexity, less bugs
In article [EMAIL PROTECTED],
David Woodhouse [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] 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
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
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,
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
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
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
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
20 matches
Mail list logo
