why these partitions

Quote from lannox

and only 27M to /storage?

LibreELEC is designed to auto-resize the storage partition on the 1st boot of LibreELEC. Should that not happen for whatever reason, then you can use also tools such as Gparted to resize that partition manually.

You can try to trigger the resizing again by creating this file on the command line using a SSH connection:

touch /storage/.please_resize_me

Reboot LibreELEC when the file has been created.

Hi lannox,

For the record, df -h does not list partitions. It lists file systems along with their sizes and free space.

Here, filesystem should be interpreted very freely. It can include things such as tmpfs which is usually allocated (thinly) in RAM etc.; not everything on the list might not always reside on a physical block device. This is common to any Linux system (and many derivatives; probably any *nix, probably OS X and MacOS with minor tweaks, *BSD?). In your case, only partitions on your mmcblk0 are those named mmcblk0p? in the listing you've posted. So you've used only around 528M on the disk.

LibreELEC contains a very stripped down version of Linux ("just enough OS..."), but try lsblk or fdisk -l (or blkid ??? I don't remember what is on usual LibreELEC releases) to see what is actually going on with your disk.

So, basically Klojum is on the point, I'd also do as he suggested. This is just some additional information (which can hopefully be useful in the future =) ).

Quote from Klojum

You can try to trigger the resizing again by creating this file on the command line using a SSH connection:

Resize is only possible as long the partition is empty. External tools are needed after the system was booted (into Kodi) the first time.

Quote from lannox

Then I wonder, why affecting 1.9G to /tmp, or 1.8G to /var and only 27M to /storage?

Not really mentioned here, but /tmp and /var are "tmpfs" filesystems. Which is basically like a ramdisk and is not persistent storage or using any real disk partitions.

There is a safeguard in the resize script that will not do the resizing if the /storage partition already has some key folders. Where things go wrong is when you re-image and decide to copy files over and then recover files from a backup before first boot. This is likely your situation, and it requires a manual partition resizing & filesystem resizing.

Quote from Wild Penguin

LibreELEC contains a very stripped down version of Linux ("just enough OS..."), but try lsblk or fdisk -l ...

lsblk, fdisk are also stripped

but a sgdisk and parted is available

Lannox,

Most (all?) LibreElec releases images are quite small. The images contain a partition table, where there is a small fat16 partition and a storage partition. But the storage partition is very small, the bare minimum and it should be resized to the maximum available on the block device. 27M will fill up immediately.

For some reason LibreELEC skipped that part on your first boot this time. Frakkin64 gave one good suggestion as to why it might have happened.

You have not told as the size of the SD card you are using. Try parted /dev/mmcblk0 print and post the output here.

It's probably easiest to make a new SD cards and start over. The default 32MB /storage partition should be resized to 100% on first boot. For some unknown reason that didn't happen and unless you are familiar with Linux CLI commands and have another Linux VM around to mount the card and fix the partitions with, it's not something that's simple to resolve (cannot be done from the booted card). As a rule, the 2% of LE users who know how to solve that stuff just fix it instead of asking Qs in forums, so I assume you're iin the other 98%.

Hi Lannox,

There is no information whatsoever in the screenshots you've posted. They contain errors about creating a pasteboard image.

Hint: don't take screenshots of text content, instead copy+paste the text or use some pastebin client.

Also, it is worthwhile to tell in the first post what (and everything) you've done. Things such as not following the installation instructions might be especially vital information, and this information may help to reduce time to troubleshoot your issue on this (or other) forums.

I'm not familiar with raspberry pi imager tool, are you sure it supports creating LibreELEC images? It might expect something from the image file contents and modify them before burning (based on it's expectations).

The USB-SD Creator tool isn't properly maintained at the moment, so bumps & hiccups may occur. Just use your favorite disk image writing tool (Rufus works for me), and things should be fine.

I've used dd, it's simple, available on any Linux and works fine, but it's also called DiskDestroyer for a reason. I'm always nervously checking that I've not mixed up a letter in the of= part =). I've though about giving balenaEtcher or some equivalent a go at some point (AFAIK these frontends are a bit more clever and won't let you that easily write over a hard disk as dd does; just not needing to type the device names is a huge safety improvement for owners of sloppy fingers!).