FOS does not honor web gui parameter FOG_KERNEL_RAMDISK_SIZE
-
@sebastian-roth OK I will have to look into what I need to install. The code kind of weaves it self into the existing paths.
It would be interesting to know if we could expand the initrd fs to the size of the “ram drive” kind of how FOG does with single disk expandable.
-
@george1421 Ah I see. Well then we could use overlayfs I suppose. Let me see if I can put together a small script for you to use.
-
@sebastian-roth Can you tell me how the system picks the size for the root file system. Is it the size of init.xz + some kind of buffer? If I add files to init.xz and then recompact the files it seems to grow some how.
-
Well I’ve done quite a bit of reading and reverse engineering on this. I now see how the root file system is the size it is. Basically when buildroot is run and the init file system is created it takes the size of the files and adds in a small buffer space for log files and that becomes your initfs.
I also see that buildroot has the ability to add in some “fluff” space just in case some idiot (like me) needs to add files to the initfs dynamically. Currently the FOG buildroot config file has the “fluff” space set to 0, so we are only getting the files size + buffer space.
Ref: https://svn.code.sf.net/p/freeghost/code/trunk/src/buildroot/fog.buildroot.config.64
Field: BR2_TARGET_ROOTFS_EXT2_EXTRA_BLOCKS=0
Field: BR2_TARGET_ROOTFS_EXT2_EXTRA_INODES=0ref: https://git.busybox.net/buildroot/commit?id=301c18e1233a4e1bbbd5368496ddfe99480909bf for the descriptions of these settings (yes I know its a diff patch file)
So its possible to add in some space into the root FS. So the questions are
- How much space?
- Should this be done at a fog system level or a one off case?
For #1.
That is a slippery slope. Lets say we add in an extra 100MB. What happens when someone needs 103MB extra? Then the next guy +110MB extra? How is that process managed? Sometimes its easier to say NO. Just build it your self. The other issue is the kernel size for the kernel_ramdisk_size. Are they related? If we make the initfs too big will it bump in to the default value of 127MB for this ramdisk? Or is that something else all together?For #2
If this change is made at a FOG foundation level will we run into issues with all of the deployments currently out there (like the comment about the kernel ramdisk size). Will that need to be adjusted to use this larger initfs?I don’t have the answers, I’m just thinking out loud here…
-
@george1421 See you’ve found out a lot of interesting things about buildroot that I didn’t know about yet. As far as I see it there is no good reason to add some kind of “fluff” space to the init because there will always be a situation where the choosen amount is not be enough! So I think we should really focus on making this a dynamic thing. Using overlayfs we should be able to do exactly what you want to achieve without restricting ourself to some amount of size.
EDIT: Our current kernel config does not have overlayfs included but this is just a tiny change. I already started to put together a script to test my idea… Currently building a fresh kernel with the correct driver included.
-
Not as easy as I thought at first but it surely works as I expected. Find a kernel and initd (only 64 bit so far) here. It’s not perfect yet as you only see the “old-root” (initrd root fs) in
df -h
. This is kind of confusing. Bugmount
does properly show the overlayfs to be the new root fs. As far as I tested you can copy as much data wherever you want. -
@sebastian-roth These files were successful in creating a platform with an expandable filesystem for FOS. I was able to install the Dell CCTK drivers but they failed to work. I’m still working on this project in the background, cause it would be an interesting option. From a FOS standpoint I can do what is needed so that is a success so great job!
-
@george1421 Bump…
-
@sebastian-roth Bump back
I did come across an old linux project I worked on years ago. Here is how they presented the overlay fs for their rootfs .
-
@george1421 What is this project called? Do you see any difference between the
df -h
output? Mind posting a picture of the output when booting the patched FOS?