Tiny Core Linux
Off-Topic => Off-Topic - Tiny Tux's Corner => Topic started by: wysiwyg on January 05, 2011, 05:55:31 PM
-
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
-
There is no ramdisk to begin with...
Search forum and docs for keyword "embed" (e.g. bootcode).
-
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?
-
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.
-
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?
-
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.
-
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.
-
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
-
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.
-
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)?
-
formatting takes time
plus space (in case of ramdisk translated into RAM usage)
-
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.
-
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?
-
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
-
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?
-
Ok, to find out more, you could first read kernel docs and then google for the following filesystems involved: "initramfs" "rootfs" "tmpfs" (ramfs is related but not used in TC).
Booting with 'syslog' and then examine /var/log/messages could give you some insight about what is happening.
Resources are freed after switch_root has been executed.
IIRC - it is a long time - when booting from initial ramdisks, they used to end up being mounted on some mountpoint on the root fs by default or at least in some cases.
-
Resources are freed after switch_root has been executed.
So would it be ok to umount the rootfs since it's no longer being used? Currently both TC and my distro (since I'm cloning parts of TC) both have two root mounts / (one rootfs and one tmpfs). Since I sized my tmpfs partition way down from 90%, I can see that the / tmpfs is the one that actually should be used as it reports the correct size while the / rootfs still shows the 90%.
-
i would bet you would never be able to umount rootfs.
-
i would bet you would never be able to umount rootfs.
I bet you're right. There's no UUID or anything specific about that mount that can be targeted for umount is there? Obviously, a "umount /" wouldn't work... :)