FOS does not honor web gui parameter FOG_KERNEL_RAMDISK_SIZE

[george1421]

Server

• FOG Version: 1.4.4
• OS: Centos 7

Client

• Service Version: N/A
• OS: N/A

I’m working with Dell’s command and control tool kit. I need to be able to install these files in FOS using a postinit script. The FOS root disk is only 109MB in size. I need to expand this disk larger to support a few more files. I assume that the web gui kernel parameter FOG_KERNEL_RAMDISK_SIZE controls the size of the FOS RAM Drive. I do see the updated values passed as a kernel parameter to FOS, but the disk remains the same size.

Am I misunderstanding the intent of this kernel parameter. I could bake the files into the init.xz file, but that would then create a custom init that would need to be updated each time fog is updated.

Description

[Sebastian Roth]

@george1421 Unfortunately the parameter is not controlling the actual size of the root filesystem of the running FOS system. See the RAM drive as a container. With this FOG setting (and therefore kernel parameter) we create kind of an in-memory block device that is used to dump the initrd before using it’s contents. It’s kind of like when you write the unpacked initrd onto a USB key using dd. Sure you can use a bigger USB key but that won’t expand the initrd image at all. It would just leave more free space (not allocated within the initrd “partition”). So currently I don’t think there is a way of dynamically adjusting the size of the root fs itself. It’s not a bug it’s just technically not possible.

That said I totally understand your request and I think we already have what you are looking for. It’s called tmpfs. Just copy your files to /tmp or /run and you won’t hit the 109MB size limit of the root filesystem. Limit is more or less the RAM size of your machine. Nothing to adjust via parameters…

[george1421]

@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.

[Sebastian Roth]

@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.

[george1421]

@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.

[george1421]

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=0

ref: 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

1. How much space?
2. 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…

[Sebastian Roth]

@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.

[Sebastian Roth]

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. Bug mount 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.

[george1421]

@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!

[Sebastian Roth]

@george1421 Bump…

[george1421]

@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 .

[Sebastian Roth]

@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?