Is it possible to put files in the storage folder when compiling?

  • I've been working on some custom compilation for LibreElec and my OCD is getting the better of me. I Understand on first boot the storage partition is deleted, resized, and recreated, so I can't really store anything there before then. But is it possible to configure some files to LIVE on the storage folder/partition? For example, there's some binaries and supporting files that get installed into /usr/bin and /usr/share that I really want to live in /storage, but I have to manually copy them over after the first boot is completed. Is it possible to automate this to run after storage is resized and then remove them from their original location so they only live in the /storage location? I'm guessing not since the file system is read only, but couldn't hurt to ask.

  • what about deleting the files from /usr after they have been copied so they don't exist in both locations?

    You can't delete files from /usr. If you want to avoid having files directly visible you could use some archive and extract it to /storage.

  • That's pretty much what I thought. What if I modified the file system resize script to only resize the storage partition and not delete+recreate it? Then any content I put there during compile wouldn't get lost. Are there any issues with that plan??

  • That's pretty much what I thought. What if I modified the file system resize script to only resize the storage partition and not delete+recreate it? Then any content I put there during compile wouldn't get lost. Are there any issues with that plan?

    You will lose everything in /storage if you do a full system reset.

  • Why do the binary files need to be in the writeable partition? What happens if the binary files are deleted, will you need to recreate them? What happens if you create a new version of your image, will you need to overwrite older binaries?

    Extracting the binary files to /storage if they're not present or out of date would work more reliably (and with fewer changes) than modifying the resize script (and the image creation process), though I'm interested to know why it is necessary to install the binaries in /storage if you are creating the image.

    Installing the binaries via a Kodi add-on is the other solution for third-party binaries as this allows periodic updates without updating the whole image.

  • ISTR the reason we "nuke and pave" the existing second partition is primarily about speed/performance as parted resize is a slower operation than remove and create new with the correct geometry and it's more prone to issues with the underlying boot media. Embedding files in the SYSTEM file and copying them out to /storage is the least invasive (requires least changes) approach to pre-configuring things on storage; it's also tried and tested. If you want to do something different and resize the existing partition it's not an invalid/wrong approach, but we're not going to be able to provide lots more guidance as it's simply not how we do things today.

  • All excellent feedback, thank you all. It makes sense, and I understand if the storage partition gets erased there's no way to restore those files, but just like any computer a good backup is important in those cases. I understand it's not the "normal" way of doing things, but it's good to know it's an option that I can explore. Love the expert feedback in this forum. thanks again