problem mounting tmpfs

[wysiwyg]

Gang,

     I'm attempting to mount several filesystems during the bootup process, but get hung up.  I created an /sbin/init bash script that does the following in the order shown:

mount /proc
mount /sys
mount /dev (as mdev)
mkdir /dev/pts
mount /dev/pts (as devpts)
echo /sbin/mdev > /proc/sys/kernel/hotplug && /sbin/mdev -s

Everything ran fine with this setup.  I've since added runit (init replacement) so that the startup process can be more complex than a single bash script.  That is the only addition to the OS and now if I run the old init bash script from the prompt, it gets to the point where it tries to mount the /dev (mdev) filesystem but errors out saying "can't setup loop device: no space left on device".  I tried Googling that exact error, but only have a few results for the Andriod OS.  Any help would greatly be appreciated.

Also, my OS has been pretty much copying Tinycore up to this point.  I noticed that in TC, the /init script does the following:
if mount -t tmpfs -o size=90% tmpfs /mnt; then
  if tar -C / --exclude=mnt -cf - . | tar -C /mnt/ -xf - ; then
    mkdir /mnt/mnt
    exec /sbin/switch_root mnt /sbin/init
  fi
fi

Is there a reason to not just remain in the original ramdisk?  Are there advantages either way?

Thanks,
Dave

[tinypoodle]

There is no ramdisk to begin with...

Search forum and docs for keyword "embed" (e.g. bootcode).

[wysiwyg]

There is no ramdisk to begin with...

Search forum and docs for keyword "embed" (e.g. bootcode).

Ok, I've searched the forums for "embed", "bootcode", "embed +bootcode" and couldn't find anything relevant on the first couple of pages.  Can you be more specific or provide a direct link?

[curaga]

Is there a reason to not just remain in the original ramdisk?  Are there advantages either way?

Without the copy, it doesn't show up in df. Thus some binary installers blow up when they can't measure free space.

[wysiwyg]

Is there a reason to not just remain in the original ramdisk?  Are there advantages either way?

Without the copy, it doesn't show up in df. Thus some binary installers blow up when they can't measure free space.

As in the copy using the TC code provide in the OP?

[wysiwyg]

Ok, further testing has produced an interesting result.  If I mount in this order instead of the order from the OP, everything works fine:

mount /dev
mount /proc
mount /sys
mount /dev/pts
echo /sbin/mdev > /proc/kernel...; mdev -s

Why would one way work over the others?  How is the same space not being taken up doing things in this order versus the other?


One other question... why wouldn't it be better to use a ramdisk (e.g. /dev/ram0) formatted with ext2/3/4 to switch root to instead of another tmpfs?  To me, it would seem one way can clearly define a "work space" whereas the tmpfs could just continue to grow and potentially use up all the ram available.

[curaga]

As in the copy using the TC code provide in the OP?

Yes.

One other question... why wouldn't it be better to use a ramdisk (e.g. /dev/ram0) formatted with ext2/3/4 to switch root to instead of another tmpfs?  To me, it would seem one way can clearly define a "work space" whereas the tmpfs could just continue to grow and potentially use up all the ram available.

Always fixed size, formatting takes time, no swapping, and unused, but previously used space takes ram.

[wysiwyg]

One other question... why wouldn't it be better to use a ramdisk (e.g. /dev/ram0) formatted with ext2/3/4 to switch root to instead of another tmpfs?  To me, it would seem one way can clearly define a "work space" whereas the tmpfs could just continue to grow and potentially use up all the ram available.

Always fixed size, formatting takes time, no swapping, and unused, but previously used space takes ram.

That makes sense.  I am, however, trying to limit the amount of space the tmpfs can use (to prevent problems with programming mistakes or malicious activity).  I suppose I can just use the 'size=' parameter, that way the only "drawback" will be a smaller fixed size than the 90% assigned by TC.

And yet... another question!   Going back to the OP question about the switch_root, so is the only reason TC does this so that binaries like df work correctly or are there other reasons too?

Dave

[curaga]

No other reasons really. As you can see, with the "embed" bootcode that part is skipped.
Our kernel is patched anyway so that rootfs is tmpfs, and so we get the other benefits of tmpfs (swap-ability) even with an embed boot.

[wysiwyg]

No other reasons really. As you can see, with the "embed" bootcode that part is skipped.
Our kernel is patched anyway so that rootfs is tmpfs, and so we get the other benefits of tmpfs (swap-ability) even with an embed boot.

Is it possible to just patch the kernel so there's no need to do a swap?  This can save some time.  If the 'embed' bootcode skips it, wouldn't some binaries using that system still mess up (e.g. df)?

[tinypoodle]

formatting takes time

plus space (in case of ramdisk translated into RAM usage)

[curaga]

Is it possible to just patch the kernel so there's no need to do a swap?  This can save some time.  If the 'embed' bootcode skips it, wouldn't some binaries using that system still mess up (e.g. df)?

I think you mixed the terms there, by swap-ability I meant the ability for data not recently accessed in the tmpfs to go to swap, leaving more free ram.

Yes, with an "embed" boot the root fs will not show in df. But it's a tradeoff between that and some boot speed, so it's left to the user's discretion.

[wysiwyg]

Is it possible to just patch the kernel so there's no need to do a swap?  This can save some time.  If the 'embed' bootcode skips it, wouldn't some binaries using that system still mess up (e.g. df)?

I think you mixed the terms there, by swap-ability I meant the ability for data not recently accessed in the tmpfs to go to swap, leaving more free ram.

Yes, with an "embed" boot the root fs will not show in df. But it's a tradeoff between that and some boot speed, so it's left to the user's discretion.

Yeah, I did misunderstand apparently.  

I ended up adding the switch_root code to my own project (as shown below) so that binaries such as df would work properly.  After looking at the output, I realized something must be wrong.  This is what my information looks like:
Output from df:
FS         Size             Used    Avail          Use  Mounted
tmpfs    2769380      0         2769380    0%   /mnt/switch_root
mdev    1538544      0         1538544    0%   /dev/shm

Output from mount
rootfs on / type rootfs (...)
tmpfs on /mnt/switch_root type tmpfs (...)
mdev on /dev type tmpfs (...)
...

Then I booted into TC to see what there's was showing and this is what the result is:
Output from df:
FS         Size      Used    Avail     Use  Mounted
tmpfs    2.6G     16.9M   2.6G    1%   /
tmpfs    1.5G      0          1.5G    0%   /dev/shm

Output from mount
rootfs on / type rootfs (...)
tmpfs on / type tmpfs (...)
proc on /proc type proc (...)
...


Couple of questions....
1) Why does the rootfs still show in both OS's?  Once you switch_root, shouldn't the initial ramdisk be destroyed?
2) Why does mine read as /mnt/switch_root (which is the directory everything should be moved into using the switch_root call as found in the TC /init script) instead of just / ?
3) Why are all of the mounts not shown in the df output?

Dave



UPDATE:
Apparently I wasn't using switch_root right and as a result the filesystem created to switch_root to wasn't being switch_root'ed to so it just showed up as an additional mounted filesystem.  I've since corrected the issue and now my "output from mount" shows the same as TC.  But my question still remains... shouldn't that have gone away once the switch_root took place?

[tinypoodle]

You have been told many times (in other very similar threads) to read basic documentation about filesystems involved, which it appears you eiter failed to do or understand, so you go on asking questions based on imaginary scenarios without corresponding to facts.

1) if there is no ramdisk involved, there is none to be quote:"destroyed"
3) because you obviously did not mount the file systems

[wysiwyg]

You have been told many times (in other very similar threads) to read basic documentation about filesystems involved, which it appears you eiter failed to do or understand, so you go on asking questions based on imaginary scenarios without corresponding to facts.

1) if there is no ramdisk involved, there is none to be quote:"destroyed"
3) because you obviously did not mount the file systems

I actually did read the documentation you provided in the other post, thanks for that.  I did, however, ask you to please specify a link to more information after my search failed, which you failed to do.  Without additional insight, I kept referring to it as I understand it.  Finally, there is no need for attitude.  It's very obvious I'm learning here, so patience is required.  ...as the old saying goes, if you don't have anything nice to say, don't say anything at all. 

Referring to the "destroyed" part, I was curious as to why both systems would still show the rootfs.  To my understanding, once switch_root is executed, the initial "filesystem" (since we don't want another bad post should be destroyed, freeing resources.  If that is correct, why is that not happening?