On the same topic, I have not found any change in free memory reported before
and after the ioctl call. Though umount /initrd does free around 2 MB.
Amit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Hi,
After testing with patch-2.4.2-ac28, the df commands works fine on a dir
mounted as ramfs. Also, it recognizes the limits set, etc.
Thanks to David Gibson, Alan and others for making this available.
Regards
Amit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>(none):/mnt/ramfs/root# df -h /mnt/ramfs/
>FilesystemSize Used Avail Use% Mounted on
>ramfs0 0 0 - /mnt/ramfs
I am not sure, how related this is, but we have / on ramfs and using rpm
to install(-iUvh) fails with the mesages, need 12K on /
Amit
-
Werner Almesberger wrote:
> Easy solution: don't run linuxrc, run something else instead. E.g.
> putting the following into the kernel's command line should do th
> trick:
> init=/your_script root=/dev/ram
>
> (With your_script being the original version, without real-root-dev)
This works. And
Hi,
We(my team) had some questions regarding booting from initrd and using
/linuxrc. It will help someone(David, Werner,...) can give their
thoughts on this.
To put it in brief, since running sbin/init from /linuxrc as resulting
in init not having PID 1 and thereby not doing some initializati
> I don't know why the comparision is made though, they are used for two
> completely different things... ramfs is for temporary file storage, cramfs
> is for immutable files stored on flash. Each by itself is quite optimal
> for what it's designed for, isn't it ?
Exactly. My mistake earlier to a
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 robu
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 ca
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 automati
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
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
Hi Arnaldo,
Thanks every much for the pointer. Yes, with 2.4.2-ac5 the problem is gone.
Also, there was another similar problem with lilo stalling that is gone too.
Regards
Amit
Arnaldo Carvalho de Melo wrote:
> Em Tue, Feb 27, 2001 at 06:25:08PM -0800, Amit D Chaudhary escreveu:
>
&
Hi,
I am hoping someone knows more about this case. I have a intel pc
running linux 2.4 and the last command below hangs and the statements as
they are printed. Even kill -9 does not get it to terminate.
#touch img.test
#dd if=/dev/zero of=img.test bs=1k count=2000
2000+0 records in
2000+0 rec
why not
#include
Amit
"Heusden, Folkert van" wrote:
>
> I need to include (in a driver) a header-file from arch//subdir. I
> could, of course,
> do something like #include "../../arch/i386/{etc}" with a couple of #ifdef's
> to get things
> working for each environment. I guess that's now the
Sorry, I might not been clear enough, I meant the files are of size 0 in
the following file and also it's valinux mirror,
ftp://ftp.kernel.org/pub/linux/kernel/v2.2/linux-2.2.17.tar.gz
I did not patch the sources, I was just extracting the tar file.
Alan or someone who looks in the sources, ple
Hi,
When trying to create a patch with linux 2.2.17 sources, I found the
following files to be of size 0 in linux-2.2.17.tar.gz.
linux/include/linux/dasd.h
linux/include/linux/coda_opstats.h
Since the file is the most latest in the kernel/v2.2 directory, thought
should point this out.
Amit
-
16 matches
Mail list logo
