Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
 Running Out of Disk Space Using Persistence With Mint
#1
Ventoy Experts:

I have a relatively new Dell PC (i7, 16GB memory, 1T SSD disk drive, NVDA graphics card) that came with Windows 11 pre-installed. I am not a big fan of Windows 11 (or any other Microsoft product for that matter!), so I decided to run Linux Mint. I got a SanDisk Ultra 256GB USB3.0 drive and loaded Ventoy 1.1.10 and Linux Mint 22.2 on it. I used the Ventoy instructions and some YouTube videos with no significant problems. That worked great until I rebooted - that's where I learned about the significance of a Live version! I poked around and learned about "persistence", so I did that with no significant problems. That has worked well for me until recently. I now keep getting Mint OS warnings about low disk space (the output of "du" currently shows I have 11M avail on "/"). I did find and use the "ExtendPersistentImg.sh" script to expand my persistence file, and that seemed to work correctly. The problem, however, "persists" (pun intended!) - I am VERY low on available disk space. Sooo, I am reaching out to the experts for help. What do I need to do to solve this problem? I have searched the forums here and found a few posts in the past with a similar (actually identical) problem, but there were no answers. I suppose I could move the "/" directory (or maybe just /home) to the 1T SSD drive, but my goal with this was to have everything on the USB stick.My plan is/was to run one ".iso" (the latest version of Mint) with lots of available space for emails/files/etc.

Thanks for the help.
Reply
#2
You mean that you still have 11M avaliable space after you extend the persistence backend file with ExtendPersistentImg.sh?
Reply
#3
(05-07-2026, 01:21 AM)longpanda Wrote: You mean that you still have 11M avaliable space after you extend the persistence backend file with ExtendPersistentImg.sh?

Thanks for the quick reply and help. The answer to your question, in a word, is "yes". Here's some more detail. I have ignored the "low disk space" warning from Lint (like they would magically go away!) until this past weekend. At that time, I had about 100M disk space available. I thought I could not be the first person with this problem, so I searched the Ventoy website, Ventoy Forums, and the Internet for help. That's when I read about the "ExtendPersisentImg.sh" script. I invoked the program and used an argument to extend the persistent file by 8GB. That seemed to work. I cannot seem to mount the USB device if I am running Mint, so I pulled out my USB device and rebooted into Windows 11.I plugged back in the USB device, and the Windows File Explorer said my persistence (i.e. persistence_ext4_4GB_casper-rw.dat) file is 12,484,608 KB. Seems correct to me. I rebooted again into Ventoy with Mint, thinking my problems were solved. That didn't last very long, as I quickly got another "Low Disk Space" warning from Mint. As I type this reply, I currently have 12M free on "/" (but I have not invoked Thunderbird (my email Client) at this time to save disk space). I did try to boot into Ventoy/Mint without persistence, and I have no disk space problems (for now). Any ideas/suggestions on how to solve this problem would be appreciated.

I suspect you are very busy administering Ventoy, so (again) I appreciate the quick response and help. Ventoy is great - thanks for providing it.
Reply
#4
1. Did the ExtendPersistentImg.sh finally report success? 

2. After boot into Mint with the new persistence file, run the followings cmds as in the picture.


Attached Files Thumbnail(s)
   
Reply
#5
(05-08-2026, 12:55 AM)longpanda Wrote: 1. Did the ExtendPersistentImg.sh finally report success? 

2. After boot into Mint with the new persistence file, run the followings cmds as in the picture.

Thanks for the quick reply this time too and the willingness to continue to help.

For 1. Yes, the ExtendPersistentImg.sh did (ultimately) return SUCCESS at the end. My memory fades a bit, but I recall during the expansion there were some info/error messages that came out. I did not completely understand the messages, but when I saw the SUCCESS at the end, I assumed all was well and continued without a second thought.

For 2.

mint@mint:~$ sudo mount|grep persist
mint@mint:~$ sudo df -h /run/live/persistence/dm-3
df: /run/live/persistence/dm-3: No such file or directory
mint@mint:~$
mint@mint:~$
mint@mint:~$ df -h
Filesystem          Size  Used Avail Use% Mounted on
tmpfs              1.6G  2.1M  1.6G  1% /run
efivarfs            438K  225K  209K  52% /sys/firmware/efi/efivars
/dev/mapper/ventoy  2.9G  2.9G    0 100% /cdrom
/cow                3.8G  3.6G  9.6M 100% /
tmpfs              7.7G  4.0K  7.7G  1% /dev/shm
tmpfs              5.0M  8.0K  5.0M  1% /run/lock
tmpfs              7.7G  4.0K  7.7G  1% /tmp
tmpfs              1.6G  2.6M  1.6G  1% /run/user/1000
mint@mint:~$
mint@mint:~$
mint@mint:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=7981128k,nr_inodes=1995282,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1605288k,mode=755,inode64)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/mapper/ventoy on /cdrom type iso9660 (ro,noatime,nojoliet,check=s,map=n,blocksize=2048,iocharset=utf8)
/dev/loop0 on /rofs type squashfs (ro,noatime,errors=continue,threads=single)
/cow on / type overlay (rw,relatime,lowerdir=/filesystem.squashfs,upperdir=/cow/upper,workdir=/cow/work,xino=off,nouserxattr)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=32,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=4692)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,inode64)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1605284k,nr_inodes=401321,mode=700,uid=1000,gid=1000,inode64)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
mint@mint:~$
Reply
#6
1. Please also run the cmd:

Code:
sudo dmsetup ls

If the persistence take affect, there should be a vtoy_persistent like in the picture.
   

Then take the number after the colon (in this picture, it is  254:3, so the number after colon is 3)
Run the cmds:
Code:
sudo  mount /dev/dm-3  /mnt
sudo  df -h /mnt

PS:  You should use the correct /dev/dm-X according to your environment (e.g.  /dev/dm-1   /dev/dm-4 ...)



2. Which Mint ISO file did you test?
3. Which persistence file did you boot with? The file name and size.
Reply
#7
(05-08-2026, 07:39 AM)longpanda Wrote: 1. Please also run the cmd:

Code:
sudo dmsetup ls

If the persistence take affect, there should be a vtoy_persistent like in the picture.


Then take the number after the colon (in this picture, it is  254:3, so the number after colon is 3)
Run the cmds:
Code:
sudo  mount /dev/dm-3  /mnt
sudo  df -h /mnt

PS:  You should use the correct /dev/dm-X according to your environment (e.g.  /dev/dm-1   /dev/dm-4 ...)



2. Which Mint ISO file did you test?
3. Which persistence file did you boot with? The file name and size.


As before, thanks for the continued help.

For #1, I was able to mount the persistence directory after re-reading your "Linux Remount Feature" article. See the output below.
For #2, I use Linux Mint Cinnamon 22.2. See the output below.
For #3, I use the generic "casper" file. It is "persistence_ext4_4GB_casper-rw.dat" Again, see the output below. I must admit I cannot find where I originally got this file from. I have been learning (and promptly forentoy USB device. I have gotten side-tracked by this disk space issue.

After your last reply, and the difference between your output and my output, it seemed to me my problem was how I was extending the persistence file. So, I tried again and extended my persistence file another 16G. While that was running, I realized I made a mistake in how I was invoking the command. I did not use the "bash" keyword in my previous try's. So, the last attempt at using the ExtendPersistentImg.sh script, correctly has the "bash" keyword. I do not know if this error has completely screwed-up my persistence file. I do not want to start over, as my current persistence file has information (mostly email messages) I do not want to lose. I have been exporting my email messages, so I should be able to recover that if I have to...

You may want to read the terminal output from the end to the beginning. PLEASE READ WHAT'S AFTER THE OUTPUT.
BEGIN TERMINAL OUTPUT
======================
mint@mint:/mnt$ lsf
'System Volume Information'/  iso/  persistence/  ventoy/
mint@mint:/mnt$ cd persistence/
mint@mint:/mnt/persistence$ lsf
persistence_ext4_4GB_casper-rw.dat*
mint@mint:/mnt/persistence$ sudo /home/mint/Downloads/Ventoy-1.1.12/ventoy-1.1.12/ExtendPersistentImg.sh persistence_ext4_4GB_casper-rw.dat 16192
Extend dat file... (current is 12192MB, append 16192MB, total 28384MB)
Extend ext filesystem by resize2fs ...
resize2fs /dev/loop1 28384M
e2fsck 1.47.0 (5-Feb-2023)
casper-rw: recovering journal
Clearing orphaned inode 139063 (uid=1000, gid=1000, mode=0100664, size=32768)
Clearing orphaned inode 138894 (uid=1000, gid=1000, mode=0100600, size=39132)
Clearing orphaned inode 138891 (uid=1000, gid=1000, mode=0100664, size=32768)
Clearing orphaned inode 137776 (uid=1000, gid=1000, mode=0100600, size=3796)
Clearing orphaned inode 137586 (uid=1000, gid=1000, mode=0100664, size=32768)
Clearing orphaned inode 133599 (uid=1000, gid=1000, mode=0100600, size=64)
Clearing orphaned inode 142920 (uid=1000, gid=1000, mode=0100664, size=32768)
Clearing orphaned inode 142855 (uid=1000, gid=1000, mode=0100600, size=38592)
Clearing orphaned inode 137721 (uid=1000, gid=1000, mode=0100664, size=19969)
Clearing orphaned inode 132566 (uid=1000, gid=1000, mode=0100664, size=19969)
Resize inode not valid.  Recreate<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Inode 155073 extent tree (at level 1) could be shorter.  Optimize<y>? yes
Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (784, counted=785).
Fix<y>? yes
Free blocks count wrong (58335, counted=58327).
Fix<y>? yes
Free inodes count wrong (238003, counted=238130).
Fix<y>? yes

casper-rw: ***** FILE SYSTEM WAS MODIFIED *****
casper-rw: 24014/262144 files (4.7% non-contiguous), 990249/1048576 blocks
resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/loop1 to 7266304 (4k) blocks.
The filesystem on /dev/loop1 is now 7266304 (4k) blocks long.


======= SUCCESS =========

mint@mint:/mnt/persistence$ sudo bash /home/mint/Downloads/Ventoy-1.1.12/ventoy-1.1.12/ExtendPersistentImg.sh persistence_ext4_4GB_casper-rw.dat 2048
Extend dat file... (current is 28384MB, append 2048MB, total 30432MB)
Extend ext filesystem by resize2fs ...
resize2fs /dev/loop1 30432M
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes
Inode 133599 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Unattached inode 136447
Connect to /lost+found<y>? yes
Inode 136447 ref count is 2, should be 1.  Fix<y>? yes
Pass 5: Checking group summary information
Block bitmap differences:  -557636 -(559035--559039) -560967 -561576 -(563616--563623) -(565091--565095) -(574576--574583) -(575496--575505) -(575520--575527) -(576768--576775) -(576994--577003)
Fix<y>? yes
Free blocks count wrong for group #17 (946, counted=944).
Fix<y>? yes
Free blocks count wrong (6176856, counted=6176854).
Fix<y>? yes
Inode bitmap differences:  -132566 -133599 -137586 -137721 -137776 -138891 -138894 -139063
Fix<y>? yes
Free inodes count wrong for group #16 (129, counted=128).
Fix<y>? yes
Free inodes count wrong (1794610, counted=1794609).
Fix<y>? yes

casper-rw: ***** FILE SYSTEM WAS MODIFIED *****
casper-rw: 24015/1818624 files (4.7% non-contiguous), 1089450/7266304 blocks
resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/loop1 to 7790592 (4k) blocks.
The filesystem on /dev/loop1 is now 7790592 (4k) blocks long.


======= SUCCESS =========

mint@mint:/mnt/persistence$ pwd
/mnt/persistence
mint@mint:/mnt/persistence$ ll
total 31162624
drwxr-xr-x 2 root root      131072 Dec 26 21:49 ./
drwxr-xr-x 6 root root      131072 May  8 20:20 ../
-rwxr-xr-x 1 root root 31910264832 May  8 20:50 persistence_ext4_4GB_casper-rw.dat*
mint@mint:/mnt/persistence$ cd ..
mint@mint:/mnt$ lsf
'System Volume Information'/  iso/  persistence/  ventoy/
mint@mint:/mnt$ lsf iso
linuxmint-22.2-cinnamon-64bit.iso*
mint@mint:/mnt$ lsf ventoy/
ventoy.json*
mint@mint:/mnt$ df -h
Filesystem          Size  Used Avail Use% Mounted on
tmpfs              1.6G  2.1M  1.6G  1% /run
efivarfs            438K  225K  209K  52% /sys/firmware/efi/efivars
/dev/mapper/ventoy  2.9G  2.9G    0 100% /cdrom
/cow                3.8G  3.6G  6.7M 100% /
tmpfs              7.7G  4.0K  7.7G  1% /dev/shm
tmpfs              5.0M  8.0K  5.0M  1% /run/lock
tmpfs              7.7G  4.0K  7.7G  1% /tmp
tmpfs              1.6G  2.6M  1.6G  1% /run/user/1000
/dev/mapper/sda1    233G  33G  201G  14% /mnt
mint@mint:/mnt$ sudo dmsetup ls
sda1 (252:2)
ventoy (252:0)
vtoy_persistent (252:1)
mint@mint:/mnt$ sudo df -h /mnt
Filesystem        Size  Used Avail Use% Mounted on
/dev/mapper/sda1  233G  33G  201G  14% /mnt
mint@mint:/mnt$ du /home|grep -i Mail
18764 /home/mint/.thunderbird/1b2ron07.default-esr/Mail/Local Folders
677432 /home/mint/.thunderbird/1b2ron07.default-esr/Mail/mail.comcast.net
696200 /home/mint/.thunderbird/1b2ron07.default-esr/Mail
4 /home/mint/.cache/evolution/mail/trash
8 /home/mint/.cache/evolution/mail
4 /home/mint/.local/share/evolution/mail/trash
8 /home/mint/.local/share/evolution/mail
mint@mint:/mnt$
END TERMINAL OUTPUT
====================

It occurs to me my problem is not about extending the persistence file. It's about not having a link between my home directory and the persistence file. My home directory is mounted on "/" (on filesystem /cow), and the persistence is mounted on "/mnt" (on filesystem /dev/mapper/sda1). I somehow need to link /mnt and /cow, or move the /cow filesystem to /mnt.
Reply
#8
vtoy_persistent (252:1)

so run the cmds:
Code:
mkdir -p  /tmp/test
sudo mount /dev/dm-1  /tmp/test
sudo df -h  /tmp/test

vtoy_persistent is a virtual device which mapped to the persistence file.
If the persistence take affect, the system should mount /dev/dm-1 to someware and use it as the persistence space.
The /dev/mapper/sda1 (Linux Remount feature) is not for persistence.
Reply
#9
(05-09-2026, 05:43 AM)longpanda Wrote: vtoy_persistent (252:1)

so run the cmds:
Code:
mkdir -p  /tmp/test
sudo mount /dev/dm-1  /tmp/test
sudo df -h  /tmp/test

vtoy_persistent is a virtual device which mapped to the persistence file.
If the persistence take affect, the system should mount /dev/dm-1 to someware and use it as the persistence space.
The /dev/mapper/sda1 (Linux Remount feature) is not for persistence.

As always, I appreciate the continued support/guidance. I apologize that you have to "spoon-feed" this to me, but I still do not get it (and, I'd like to think, I know some of this stuff - I am former: 25yrs Bell Labs;8 yrs NASA; 6 yrs Raytheon;MCSE;CCNA;CLAD;RHCSA on RHEL 7). After my last email, I have started to learn about Copy-On-Write (COW). I also checked my Shell, and it's "bash" (so leaving out that argument from ExtendPersistentImg.sh should be OK).

I entered the three commands you suggested above, and I see that "/tmp/test" seems to "mirror" "/". See the "df" output below. My problem persists, though. I was able to successfully bring up Thunderbird email. When I went to "Compact Folders", I got a low disk space error. So, I must assume, that my persistence did NOT take affect (as you mentioned above). I, seriously, appreciate the help, but I am asking for more...any suggestions on how to make my persistence take affect???

DF COMMAND OUTPUT
===================

mint@mint:~$ df -h
Filesystem                  Size  Used Avail Use% Mounted on
tmpfs                        1.6G  2.1M  1.6G  1% /run
efivarfs                    438K  225K  209K  52% /sys/firmware/efi/efivars
/dev/mapper/ventoy          2.9G  2.9G    0 100% /cdrom
/cow                        3.8G  3.6G  34M 100% /
tmpfs                        7.7G  4.0K  7.7G  1% /dev/shm
tmpfs                        5.0M  8.0K  5.0M  1% /run/lock
tmpfs                        7.7G  40K  7.7G  1% /tmp
tmpfs                        1.6G  2.6M  1.6G  1% /run/user/1000
/dev/mapper/sda1            233G  33G  201G  14% /mnt
/dev/mapper/vtoy_persistent  3.8G  3.6G  34M 100% /tmp/test
/dev/sdb1                    58G  6.7G  51G  12% /media/mint/0E92-4A7E
mint@mint:~$ echo $SHELL
/bin/bash
mint@mint:~$
Reply
#10
I test the mint ISO file with VM myself with persistence and later extend the persistence file, everything goes well.

When you boot with persistence file, you see /cow is the rootfs, but we can not see where is /cow mounted.

We can add a break=bottom boot option to the boot menu and make it break to a shell during boot
then we can see that /cow is actually mounted from /dev/dm-X (vtoy_persistent).

This means that the persistence mechanism actually take affect (your data file were successfully saved).

I take some screenshots, hope that can help.

(the forums limit up to 5 attachments, so the screenshots are in 3 posts)


Attached Files Thumbnail(s)
                   
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)