Fedora LiveOS root system and available RAM

Hi to all !

In the Fedora Wiki LiveOS image page it states about Storage :

When a Live CD or Live DVD (a LiveOS image on read-only disc media) is booted, temporary storage is prepared for the system in RAM on each boot by /sbin/dmsquash-live-root in initrd.img, the initial ramdisk filesystem. By default, a 32 GiB, in-memory, copy-on-write, system overlay in a sparse file is prepared (see File Systems below).

I have a hardware running with either 16Gb or 32Gb RAM.
In neither case when I boot a Fedora Live OS do I experience this 32 GiB, in-memory, copy-on-write system.

Instead, the root system is around 6.4 GB, with only roughly 1.5GB free space, as stated further :

an apparent 6.4 GiB ext4 root filesystem that has been sparsed and compressed into under 1.6 GiB of actual disc space in the .iso file (or on a LiveOS installed device file system). df -h on an untouched mounting of the root filesystem will report that 4.9G is used and 1.5G is available space out of a total size of 6.4G.

Trying to remount /as in: $ sudo mount / -o remount,70% results in failure.

How can I get the live file system to access all (or most like 70%) of the full RAM available on hardware ?

Thanks !

Playing with ram like that is totally unnecessary for most cases. When booting the live system it uses the available ram as needed and does not require user intervention. This only fails if the ram is so limited as to not be able to properly boot.

I do not understand why you think this would be an issue. Note that the final sentence of that paragraph says: Since the temporary overlay is a sparse file in a tmpfs, a large size, even larger than available memory, may be specified and only what is needed will be allocated as needed.

This means the system sees exactly what is required and allocates only what is necessary (automatically & without user intervention). It may even seem like magic to the uninitiated.

Here is my systematic experience with 8GB/16GB/32GB RAM laptops :

  1. boot the latest Fedora Workstation Live USB
  2. System monitor shows around 1,5GB available space for the root filesystem
  3. Do $ sudo dnf install -y or
    go to getfedora.org and download any .iso image heavier than 2GB

As soon as the required cumulative size of or the download exceeds 1,5/1,8 Gb => the root filesystem is full causing a system freeze.

I would gladly learn how to set the system so that after booting the live USB:

That has nothing to do with ram, and everything to do with free space in the file system.
Running out of space in the root file system has been a cause of freezes and crashes since the very beginning of computers.

What is the output of df?

Are you trying to do a large update or download like that when running the live version with the file system only in RAM and not installed where you have adequate space in the file system for downloads? If so then consider doing the download on a system where you have adequate drive space or use a second usb flash drive that is both mounted and writable as the target for the file being downloaded so you are not restricted to the RAM space for storage.

Instead of insulting arrogantly instructing you could just have given a solution or answered the question @computersavvy

The question was: If you have a huge amount of RAM, why is NOT possible to install a lot of programs and data into the home of your live Fedora system, like it is possible with Ubuntu and most other live systems. Is there an answer? Is there a workaround?

The problem was also discussed here, but without clear solution:

Hello @mahdiaqallal ,
Perhaps you’re looking for this Creating and using a live installation image :: Fedora Docs

I have tested livecd-iso-to-disk tool about a month ago, and it didn’t work very well. I used to use it ears ago, but lately I only used direct copy of the iso image to disk. I assumed I need --efi option when booting in UEFI mode.

I haven’t tested it lately myself, just thought that was what the OP was really after.

Interesting documentation. But doesn’t mention the artificial size limit, ie why there is only 1.5 GB free disc space (which seems arbitrary to me) – and how this could be changed.

I thought this

The livecd-iso-to-disk method is slightly less reliable than Fedora Media Writer and can be used reliably only from within Fedora: it does not work in Windows or macOS, and is not supported (and will usually fail) in non-Fedora distributions. However, it supports three advanced features which FMW does not include:

    You may use a non-destructive method to create the stick, meaning existing files on the stick will not be destroyed. This is less reliable than the destructive write methods, and should be used only if you have no stick you can afford to wipe.

    On live images, you can include a feature called a persistent overlay, which allows changes made to persist across reboots. You can perform updates just like a regular installation to your hard disk, except that kernel updates require manual intervention and overlay space may be insufficient. Without a persistent overlay, the stick will return to a fresh state each time it is booted.

    On live images, you can also have a separate area to store user account information and data such as documents and downloaded files, with optional encryption for security and peace of mind.

Was what was wanted.

Persistent overlay was not the question. Have you ever used Ubuntu live or any other live system? You can create, download, install as much data as you want (until RAM is full). Since 12 years at least. It is not persistent and doesn’t/shouldn’t need to be.

Why is this different with Fedora live systems? And how can it be changed? Why the 1.5 GB limit?

Well it sort of is about all of the things I was pointing to with that documentation link. For instance persistence is happening with the LiveOS’s since otherwise you would be reinstalling and updating every time you plugged it into another device. You can also use the available space as another mount point and with persistence change the fstab to be what you want and mount it, voila extra storage. At least I would think it’s doable.

I don’t know if it works, but there is an option

           Specifies a non-persistent Device-mapper overlay size in MiB. The default is 32768.

You can add that to the boot command line if you hit the e key in the grub2 menu.

The option is documented in man dracut.cmdline.

1 Like

Wow, that sounds great! I will try it.

Thank you very much.

Wait, it says 32 GB is the default. That is impossible. Maybe the default was changed, because I have never had 32 GB (minus the used storage of the Fedora live system maybe) of free space.

Still worth a try.

In the source of dracut the rd.live.overlay.size can only be found in the file modules.d/90dmsquash-live/dmsquash-live-root.sh in the do_live_overlay() function.

And this do_live_overlay() function is only being called once at line 398. Well, I didn’t read all the code, but it seems, that some more option is needed to have this 32 GB default overlay, because I get only around 1.5 GB of free space at /dev/mapper/live-rw.

Well, I have no clue how to achive this with Fedora. But this is a workaround with a manual overlay. It didn’t work to overlay the root filesystem itself, namely /, it just remained the same small amount of free space, don’t know why. So I just overlayed /usr, /var and /home:

for i in usr var home; do
  sudo mkdir -p /tmp/O_${i}/{U,W}
  sudo mount  -t overlay \
              -o  lowerdir=/${i}/,upperdir=/tmp/O_${i}/U,workdir=/tmp/O_${i}/W \
              overlay /${i}/

I have put this into a file called overlay.source, and I source it as soon as I have an internet connection in my Fedora live system like this:

source <(curl myserver.com/overlay.source)

If you call the file just ov, then this could also be typed with fewer keystrokes:

. <(curl myserver.com/ov)

I would still apreciate if somebody could tell me how this can be done without this hack.

FWIW, the difference between Fedora’s LiveOS and what some other distros use is explained at the end of this post: Re: Dracut, dmsquash, and overlays - devel - Fedora Mailing-Lists

And here is another post with another hint at why Fedora uses what they do for the Live images: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2TQWU7C65BQCL5AVFFEMJS2WKD55YM3H/

(TL;DR, Fedora uses a small ext (I guess it is actually Btrfs now?) filesystem instead of a raw squashfs filesystem so that their installer can “dd” the filesystem image to the user’s hard drive as a means of quickly installing the OS. Other distros use a “AUFS” overlay that is not available in the upstream kernel.)

If the rootfs in the Live image is a Btrfs filesystem, it should be possible to extend it on the running system with a command like the following. (caveat emptor – I’m not a Btrfs expert. I had to look this up. Correct me if I’m wrong.)

# btrfs device add /dev/sdX /

Actually, if that 32GB of space is already there in the RAM drive, the following might be all you need to tell Btrfs to “expand” and use all the available space.

# btrfs filesystem resize max /

It is ext4, actually, and there would hardly be any benefit from using btrfs instead. The installer uses the rsync or similar command to recursively copy the files to the target file systems.

In that case, I guess resize2fs /dev/mapper/live-rw might work to gain access to the full 32 GB of space (assuming the system has that much RAM)?

1 Like

Great, I will try that. Still strange that it isn’t resized to max by default. Maybe this is a decade-long bug.