2000-10-30 07:28:03

by Anders Eriksson

[permalink] [raw]
Subject: / on ramfs, possible?


I want my / to be a ramfs filesystem. I intend to populate it from an
initrd image, and then remount / as the ramfs filesystem. Is that at
all possible? The way I see it the kernel requires / on a device
(major,minor) or nfs.

Am I out of luck using ramfs as /? If it's easy to fix, how do I fix it?

/Anders




Attachments:
(No filename) (235.00 B)

2000-10-30 07:34:44

by H. Peter Anvin

[permalink] [raw]
Subject: Re: / on ramfs, possible?

Followup to: <[email protected]>
By author: Anders Eriksson <[email protected]>
In newsgroup: linux.dev.kernel
>
> I want my / to be a ramfs filesystem. I intend to populate it from an
> initrd image, and then remount / as the ramfs filesystem. Is that at
> all possible? The way I see it the kernel requires / on a device
> (major,minor) or nfs.
>
> Am I out of luck using ramfs as /? If it's easy to fix, how do I fix it?
>

Use pivot_root instead of the initrd stuff in /proc/sys.

-hpa

--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

2000-10-30 07:40:03

by Adam J. Richter

[permalink] [raw]
Subject: Re: / on ramfs, possible?

Anders Eriksson <[email protected]> writes:
>I want my / to be a ramfs filesystem. I intend to populate it from an
>initrd image, and then remount / as the ramfs filesystem. Is that at
>all possible? The way I see it the kernel requires / on a device
>(major,minor) or nfs.
>
>Am I out of luck using ramfs as /? If it's easy to fix, how do I fix it?

We do that right now with cramfs. You might want to examine
ftp://ftp.yggdrasil.com/pub/dist/booting/make-ramdisk-0.19.tar.gz.

Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."

2000-10-30 08:02:02

by Akbar A.

[permalink] [raw]
Subject: cool dev help..

cool write up..
http://www.linuxdoc.org/LDP/tlk/tlk.html

but i just had 1 question:
is there anything similar to what microsoft has pulled of with msdn in the
linux world?
i mean there is man and all,
but is there anything more "user friendly" and in the digital means besides
Beg. Linux Programming (2nd edition)?

it would be really cool, if someone could point me out to something if it
existed...


laterz,
akbar A.

"you must find out what is already known, lest you waste your time doing
poorly what others have done well."
page 29- "The Practice of Programming"
;vertexabuse.cjb.net

2000-10-30 12:42:04

by Alan Cox

[permalink] [raw]
Subject: Re: / on ramfs, possible?

> I want my / to be a ramfs filesystem. I intend to populate it from an
> initrd image, and then remount / as the ramfs filesystem. Is that at
> all possible? The way I see it the kernel requires / on a device
> (major,minor) or nfs.
>
> Am I out of luck using ramfs as /? If it's easy to fix, how do I fix it?

Firstly make sure you get the patches that make ramfs work if they arent all
yet applied, then build your initrd that populates it on boot. Now you can
make use of the pivot_root() syscall (you may need to generate your own
syscall wrapper for that one as its very new). That lets you flip your root
and initrd around

2000-10-30 20:09:43

by sl

[permalink] [raw]
Subject: Re: / on ramfs, possible?

In article <[email protected]>,
Anders Eriksson <[email protected]> wrote:
>--==_Exmh_17293564P
>Content-Type: text/plain; charset=us-ascii
>
>
>I want my / to be a ramfs filesystem. I intend to populate it from an
>initrd image, and then remount / as the ramfs filesystem. Is that at
>all possible? The way I see it the kernel requires / on a device
>(major,minor) or nfs.
>
>Am I out of luck using ramfs as /? If it's easy to fix, how do I fix it?

Yes it works.

You will need pivot_root.

Something like the following at the end of your initrd /linuxrc script
should mount your ramfs, copy the existing root fs files to it, pivot
and unmount your old root. YMMV

mkdir -p /ramfs /ram1
mount -t ramfs /ramfs /ramfs
find / | sed '/^\/ramfs/d;/^\/proc\/.*/d' | cpio -pdmV /ramfs
cd /ramfs
pivot_root . ram1
exec chroot . sh -c 'umount /ram1; exit' < dev/console >dev/console


BTW has anyone thought of writing a small utility to emulate df for ramfs?

--
__O
Fireplug - a Lineo company _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <[email protected]> http://www.fireplug.net 604-461-7532

2000-10-30 23:25:23

by David Woodhouse

[permalink] [raw]
Subject: Re: / on ramfs, possible?

On 29 Oct 2000, H. Peter Anvin wrote:

> > I want my / to be a ramfs filesystem. I intend to populate it from an
> > initrd image, and then remount / as the ramfs filesystem. Is that at
> > all possible? The way I see it the kernel requires / on a device
> > (major,minor) or nfs.
> >
> > Am I out of luck using ramfs as /? If it's easy to fix, how do I fix it?
> >
>
> Use pivot_root instead of the initrd stuff in /proc/sys.

Urgh. Then you're still using an initrd, and you still have to include all
the crap necessary to support those horrid block-device thingies.

Why not just use a ramdisk?

--
dwmw2


2000-10-30 23:27:13

by H. Peter Anvin

[permalink] [raw]
Subject: Re: / on ramfs, possible?

David Woodhouse wrote:
>
> On 29 Oct 2000, H. Peter Anvin wrote:
>
> > > I want my / to be a ramfs filesystem. I intend to populate it from an
> > > initrd image, and then remount / as the ramfs filesystem. Is that at
> > > all possible? The way I see it the kernel requires / on a device
> > > (major,minor) or nfs.
> > >
> > > Am I out of luck using ramfs as /? If it's easy to fix, how do I fix it?
> > >
> >
> > Use pivot_root instead of the initrd stuff in /proc/sys.
>
> Urgh. Then you're still using an initrd, and you still have to include all
> the crap necessary to support those horrid block-device thingies.
>
> Why not just use a ramdisk?
>

Pardon?! This doesn't make any sense...

The question was: how do switch from the initrd to using the ramfs as /?
Using pivot_root should do it (after the pivot, you can of course nuke
the initrd ramdisk.)

-hpa

--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

2000-10-30 23:32:53

by David Woodhouse

[permalink] [raw]
Subject: Re: / on ramfs, possible?

On Mon, 30 Oct 2000, H. Peter Anvin wrote:

> Pardon?! This doesn't make any sense...
>
> The question was: how do switch from the initrd to using the ramfs as /?
> Using pivot_root should do it (after the pivot, you can of course nuke
> the initrd ramdisk.)

My question is: What do you want to do that for? You can nuke the initrd
ramdisk, but you can't drop the rd.c code, or ll_rw_blk.c code, etc. So
why not just keep your root filesystem in the initrd where it started off?

--
dwmw2


2000-10-30 23:37:34

by H. Peter Anvin

[permalink] [raw]
Subject: Re: / on ramfs, possible?

David Woodhouse wrote:
>
> On Mon, 30 Oct 2000, H. Peter Anvin wrote:
>
> > Pardon?! This doesn't make any sense...
> >
> > The question was: how do switch from the initrd to using the ramfs as /?
> > Using pivot_root should do it (after the pivot, you can of course nuke
> > the initrd ramdisk.)
>
> My question is: What do you want to do that for? You can nuke the initrd
> ramdisk, but you can't drop the rd.c code, or ll_rw_blk.c code, etc. So
> why not just keep your root filesystem in the initrd where it started off?
>

Umm... because the size of a ramdisk is fixed, but the size of a ramfs is
flexible?

I can certainly understand this problem... I might in fact do exactly
this in the next version of my SuperRescue disk. There, the ramdisk
which is the real root is populated from a .tar.gz file; the initrd is
just there to unpack the .tar.gz file onto the "real" ramdisk; the initrd
is then jettisoned.

Why not just have the real root be the initrd, you ask? It's too large:
since an initrd needs to exist in both compressed form and uncompressed
form in memory at the same time; it would mean SuperRescue would no
longer work on systems with 64 MB RAM. If I went to ramfs it might
actually work on systems with 48 MB RAM, albeit you better not need to
much space in / (or conversely, it would suddenly let you put a whole lot
more stuff in /tmp if you have 512 MB.)

-hpa

--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

2000-10-30 23:40:54

by Jeff Garzik

[permalink] [raw]
Subject: Re: / on ramfs, possible?

David Woodhouse wrote:
>
> On Mon, 30 Oct 2000, H. Peter Anvin wrote:
>
> > Pardon?! This doesn't make any sense...
> >
> > The question was: how do switch from the initrd to using the ramfs as /?
> > Using pivot_root should do it (after the pivot, you can of course nuke
> > the initrd ramdisk.)
>
> My question is: What do you want to do that for? You can nuke the initrd
> ramdisk, but you can't drop the rd.c code, or ll_rw_blk.c code, etc. So
> why not just keep your root filesystem in the initrd where it started off?

ramfs size is far more dynamic than rd, and it shrinks as well as grows.

Unless you are creating a lot of temporary files and such, though,
initrd is indeed a much better solution from many perspectives. (IMHO)

Jeff


--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft | dash and shrieking like a cheerleader."
| -Max

2000-11-01 09:18:18

by Anders Eriksson

[permalink] [raw]
Subject: Re: / on ramfs, possible?


> On Mon, 30 Oct 2000, H. Peter Anvin wrote:
>
> > Pardon?! This doesn't make any sense...
> >
> > The question was: how do switch from the initrd to using the ramfs as /?
> > Using pivot_root should do it (after the pivot, you can of course nuke
> > the initrd ramdisk.)
>
> My question is: What do you want to do that for? You can nuke the initrd
> ramdisk, but you can't drop the rd.c code, or ll_rw_blk.c code, etc. So
> why not just keep your root filesystem in the initrd where it started off?
>

Because the stuff on the initrd is not at all what I want in the resultant filesystem. The machine(s) in question are some disk-based some disk-less. I have a system for remote installation/removal of packages (--> the "partition" _has_ to be able to grove/shrink).

The package builder should not have to worry about these details, so the directory hierarcy cannot contain any traces of _how_ the packges got there in the first place.

/Anders






Attachments:
(No filename) (235.00 B)