Hi All
[please forgive a NOOB/Stranger in A Strange Land]
I am trying to apply dietpi v9.4.2 to my existing v9.3.0 machine, and the update FAILS on free space check in the ‘update pre-requirements’ phase. I have applied all recent updates successfully (they “just work”) and this is the first hard error I’ve experienced.
TLDR: I have very little experience in the world of Linux. This machine is used as a headless music playback appliance - hosting MPD is its only function. SSH session via PuTTY is how I administer updates, check temperature & shutdown. The computer was built following a recipe detailed here → (https://www.diyaudio.com/community/attachments/blitzklang-pdf.1184006/)
MPD is controlled from a Windows laptop using Cantata, local music files come from a NAS, over ethernet.
During the past months, every time an upgrade has been installed, the quality of sound has improved a little bit, so I look forward to v9.4.2 for another possible improvement.
/TLDR
This is what happens when attempting the update:
This is likely sooooo easy to fix, but I am completely in the dark on how to approach the issue, what tools and commands to use to free up the needed space. My guess is a particular installation work area has leftovers from previous upgrades, which should be cleared out. Having dedicated a 32GB SSD just for the OS, I can’t imagine it is truly filled up.
Thanks so much for help, guidance and patience with an enthusiastic noobie 
Creating a bug report/issue
I have searched the existing open and closed issues
Required Information
- DietPi version | G_DIETPI_VERSION_CORE=9 G_DIETPI_VERSION_SUB=3 G_DIETPI_VERSION_RC=0 G_GITBRANCH=‘master’ G_GITOWNER=‘MichaIng’
- Distro version | bullseye
- Kernel version | Linux DietPi 5.19.17-100HZv2 #1 SMP PREEMPT_DYNAMIC Sat Sep 9 22:35:44 BST 2023 x86_64 GNU/Linux
- Architecture | amd64
- SBC model | Native PC (x86_64)
- Power supply used | HDPlex 400W DC-ATX Converter
- SD card used | Kingston 32GB SSDNow 100 SSD (as OS drive)
Additional Information (if applicable)
see screen cap above
Steps to reproduce
- execute dietpi-update
- …
Expected behaviour
- successful completion of update from v9.3.0 > v9.4.2
Actual behaviour
- FAIL checking for free space in pre-requirements phase
Extra details
can you share following?
df -h
Pls try to copy information from SSH terminal to avoid doing screen prints.
Thanks for quick reply (and sorry about the screen shot).
root@DietPi:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 17M 1.6G 2% /run
/dev/sda2 30G 30G 0 100% /
tmpfs 7.8G 0 7.8G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 7.8G 0 7.8G 0% /tmp
tmpfs 50M 8.0K 50M 1% /var/log
/dev/sda1 63M 11M 53M 18% /boot/efi
//192.168.0.175/Media_2/Music/2-CH/LossLess 25T 9.5T 16T 38% /mnt/FREENAS/Media_2/Music/2-CH/LossLess
There you go. Your root file system is full.
We could try to find the largest files if you like.
Yes please (there has to be unnecessary data lurking in there) 
du -a / --exclude /mnt/FREENAS | sort -n -r | head -n 20
root@DietPi:~# du -a / --exclude /mnt/FREENAS | sort -n -r | head -n 20
du: cannot access '/proc/2591/task/2591/fd/4': No such file or directory
du: cannot access '/proc/2591/task/2591/fdinfo/4': No such file or directory
du: cannot access '/proc/2591/fd/3': No such file or directory
du: cannot access '/proc/2591/fdinfo/3': No such file or directory
…unexpected result ??? 
This is all? It might keep running for a while
It stopped as shown, but using CTRL-C to copy the text may have halted the operation. I will run it again and leave it alone for longer. Thanks for your help !!
Ha-ha - too quick on the draw… Full output:
root@DietPi:~# du -a / --exclude /mnt/FREENAS | sort -n -r | head -n 20
du: cannot access '/proc/2654/task/2654/fd/4': No such file or directory
du: cannot access '/proc/2654/task/2654/fdinfo/4': No such file or directory
du: cannot access '/proc/2654/fd/3': No such file or directory
du: cannot access '/proc/2654/fdinfo/3': No such file or directory
du: cannot read directory '/mnt/2TB_Music': No such device
du: cannot read directory '/mnt/WTF_Music': No such device
30761852 /
25030024 /mnt
25027260 /mnt/dietpi-backup
5678768 /mnt/dietpi-backup/data
5678688 /mnt/dietpi-backup/data_3
5678648 /mnt/dietpi-backup/data_4
5678632 /mnt/dietpi-backup/data_5
3698656 /mnt/dietpi-backup/data_3/root
3698652 /mnt/dietpi-backup/data_5/root
3698652 /mnt/dietpi-backup/data_4/root
3698636 /mnt/dietpi-backup/data/root
3672708 /root
3495080 /mnt/dietpi-backup/data_3/root/linux-5.19.17
3495076 /mnt/dietpi-backup/data_5/root/linux-5.19.17
3495076 /mnt/dietpi-backup/data_4/root/linux-5.19.17
3495056 /mnt/dietpi-backup/data/root/linux-5.19.17
3469128 /root/linux-5.19.17
2312340 /mnt/dietpi-backup/data_2
2207272 /mnt/dietpi-backup/data_2/root
2137480 /root/linux-5.19.17/drivers
root@DietPi:~#
FYI: before applying each upgrade, I used the dietpi-backup function (“just in case…”). The last one taken is of the system prior to attempting the v9.3.0 > v9.4.2 operation. The previous backups could be safely deleted (…if only I understood how to do it “properly”).
How many backup copies should be kept? I would reduce the numbers to 2 or 3. Because each backup is a full system backup. Personally I just have 1 
You can safely remove the whole folder /mnt/dietpi-backup/data_5 and probably 4
Could you do
du -ah / --exclude /mnt/FREENAS | sort -n -r | head -n 20
For human readable sizes?
I use ncdu as a my du app…made a change in my .bash_aliases so it will automatically search/sort sizes for me
Still great way to find those pesky files/folders that are filling up a partition
@Joulinar: 3 maximum backups would fulfill the need/purpose. One as disaster recovery, but -2 & -3 versions to restore if OS updates cause a reduction in the awesome quality of sound coming from this PB device.
So yes - agree data_4 and data_5 can go. Let me guess (before destroying something…)
rm -rf /mnt/dietpi-backup/data_4
and likewise for the data_5 information ???
@WarHawk: as suggested (yes, much easier to comprehend the size !):
root@DietPi:~# du -ah / --exclude /mnt/FREENAS | sort -n -r | head -n 20
du: cannot access '/proc/2718/task/2718/fd/4': No such file or directory
du: cannot access '/proc/2718/task/2718/fdinfo/4': No such file or directory
du: cannot access '/proc/2718/fd/3': No such file or directory
du: cannot access '/proc/2718/fdinfo/3': No such file or directory
du: cannot read directory '/mnt/2TB_Music': No such device
du: cannot read directory '/mnt/WTF_Music': No such device
1020K /usr/lib/modules/5.19.17-100HZv2/kernel/fs/f2fs
1020K /usr/lib/modules/5.19.17-100HZv2/kernel/drivers/nvme
1020K /usr/lib/firmware/iwlwifi-cc-a0-46.ucode
1020K /root/linux-5.19.17/fs/ksmbd
1020K /root/linux-5.19.17/arch/s390/include/asm
1020K /mnt/dietpi-backup/data_5/usr/lib/modules/5.19.17-100HZv2/kernel/fs/f2fs
1020K /mnt/dietpi-backup/data_5/usr/lib/modules/5.19.17-100HZv2/kernel/drivers/nvme
1020K /mnt/dietpi-backup/data_5/usr/lib/firmware/iwlwifi-cc-a0-46.ucode
1020K /mnt/dietpi-backup/data_5/root/linux-5.19.17/fs/ksmbd
1020K /mnt/dietpi-backup/data_5/root/linux-5.19.17/arch/s390/include/asm
1020K /mnt/dietpi-backup/data_4/usr/lib/modules/5.19.17-100HZv2/kernel/fs/f2fs
1020K /mnt/dietpi-backup/data_4/usr/lib/modules/5.19.17-100HZv2/kernel/drivers/nvme
1020K /mnt/dietpi-backup/data_4/usr/lib/firmware/iwlwifi-cc-a0-46.ucode
1020K /mnt/dietpi-backup/data_4/root/linux-5.19.17/fs/ksmbd
1020K /mnt/dietpi-backup/data_4/root/linux-5.19.17/arch/s390/include/asm
1020K /mnt/dietpi-backup/data_3/usr/lib/modules/5.19.17-100HZv2/kernel/fs/f2fs
1020K /mnt/dietpi-backup/data_3/usr/lib/modules/5.19.17-100HZv2/kernel/drivers/nvme
1020K /mnt/dietpi-backup/data_3/usr/lib/firmware/iwlwifi-cc-a0-46.ucode
1020K /mnt/dietpi-backup/data_3/root/linux-5.19.17/fs/ksmbd
1020K /mnt/dietpi-backup/data_3/root/linux-5.19.17/arch/s390/include/asm
root@DietPi:~#
You can adjust this within dietpi-backup
Yes this should to it.
But the sort is not correctly done now. You see, first line is showing 1020K for directoty /usr/lib/modules/5.19.17-100HZv2/kernel/fs/f2fs, which is not correct.
Better to use following instead as it will show /mnt/dietpi-backup on top again
du -aBM / --exclude /mnt/FREENAS | sort -n -r | head -n 20
@Joulinar / @WarHawk Gentlemen - Thank You so much for your help and guidance !!
Space problem solved, update applied and… BEAUTIFUL MUSIC issues forth like never before ! Yes, the sonic improvement lies in the subtleties of the music, but it is a real and tangible step up. Crazy as it may seem to some, whatever optimizations were made in the OS have resulted in MPD providing cleaner, clearer playback.
So thank you for helping to upgrade my HiFi !
Solution: the root cause in this case was/is User Error (or more correctly, user ignorance)… not understanding the implication of storing many system backups without considering the space impact.
I deleted the backup data_4 & data_5 folders, and ran the update without incident. Easy.
Also, set the “amount of backups” to 3, to avoid this problem reoccurring.
Much better now:
root@DietPi:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 17M 1.6G 2% /run
/dev/sda2 30G 19G 9.4G 67% /
tmpfs 7.8G 0 7.8G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 7.8G 0 7.8G 0% /tmp
tmpfs 50M 0 50M 0% /var/log
/dev/sda1 63M 11M 53M 18% /boot/efi
//192.168.0.175/Media_2/Music/2-CH/LossLess 25T 9.5T 16T 38% /mnt/FREENAS/Media_2/Music/2-CH/LossLess
root@DietPi:~#
Is there anything I can safely exclude from the backup process, or am I tempting Trouble by not making a full system image ? And… any recommendations for using dietpi-cleaner to remove unnecessary files ?
Thanks again for your kind and patient help !
Cheers,
Grant
