Inodes Full

Also forgot to mention as I’m using a live session if I try to edit some of the files I get told I don’t have permission as they are write only. So any advice would probably need to include how to delete the files using terminal to bypass the read only/user permissions.

Can you boot the system normally?

If yes, then please open a terminal window (e.g. by simultaneously pressing ctrl-alt-t) and issue the following commands

uname -a
lsb_release -crid
df
df -i
sudo dpkg --audit

and copy/paste the results into this question document. This will hopefully help the diagnostics.

ubuntu@ubuntu:~$ uname -a
Linux ubuntu 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@ubuntu:~$ lsb_release -crid
Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04
Codename: focal
ubuntu@ubuntu:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 1897540 0 1897540 0% /dev
tmpfs 389176 1744 387432 1% /run
/dev/sdb1 60469824 2740096 57729728 5% /cdrom
/dev/loop0 2054400 2054400 0 100% /rofs
/cow 1945864 93428 1852436 5% /
tmpfs 1945864 0 1945864 0% /dev/shm
tmpfs 5120 8 5112 1% /run/lock
tmpfs 1945864 0 1945864 0% /sys/fs/cgroup
tmpfs 1945864 0 1945864 0% /tmp
tmpfs 389172 76 389096 1% /run/user/999
/dev/loop1 30720 30720 0 100% /snap/snapd/8542
/dev/loop2 56320 56320 0 100% /snap/core18/1880
/dev/loop3 261760 261760 0 100% /snap/gnome-3-34-1804/36
/dev/loop4 63616 63616 0 100% /snap/gtk-common-themes/1506
/dev/loop5 51072 51072 0 100% /snap/snap-store/467
/dev/mapper/ubuntu--vg-root 476099632 452673736 0 100% /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578
ubuntu@ubuntu:~$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 474385 604 473781 1% /dev
tmpfs 486466 1037 485429 1% /run
/dev/sdb1 0 0 0 - /cdrom
/dev/loop0 200949 200949 0 100% /rofs
/cow 486466 1309 485157 1% /
tmpfs 486466 1 486465 1% /dev/shm
tmpfs 486466 7 486459 1% /run/lock
tmpfs 486466 18 486448 1% /sys/fs/cgroup
tmpfs 486466 26 486440 1% /tmp
tmpfs 486466 101 486365 1% /run/user/999
/dev/loop1 463 463 0 100% /snap/snapd/8542
/dev/loop2 10756 10756 0 100% /snap/core18/1880
/dev/loop3 24339 24339 0 100% /snap/gnome-3-34-1804/36
/dev/loop4 62342 62342 0 100% /snap/gtk-common-themes/1506
/dev/loop5 15827 15827 0 100% /snap/snap-store/467
/dev/mapper/ubuntu--vg-root 30244864 232136 30012728 1% /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578
ubuntu@ubuntu:~$ sudo dpkg --audit
ubuntu@ubuntu:~$

As I’ve continued troubleshooting I seem to have been able to get around the permissions issue by activating a super user mode.

I have also noticed in var/lib/dpkg/info there is an absolute abundance of files, I think this is where the problem may be. On sizing the window I can see:

keyboard-configuration.config 1.9MB
librados2.symbols 1.8MB
linux-headers-4.15.0-101.md5sums 1.5MB
linux-headers-4.15.0-43.md5sums 1.5MB
Two other header lists at 1.2MB
libflite1:amd64.symbols 1.1MB

In comparison to the rest on the list these seem huge. I’m wondering is that what is hogging the space? Given that I am updating to a newer version of Ubuntu is it safe to just delete header files to hopefully free up enough space to let the update complete or are header files important and deleting them going to run me into a bigger headache?

You seem to be misinterpreting some of the output that you see.

1. All those /dev/loop* and /snap/* file systems are supposed to be 100% full. They are somewhat virtual file systems.

2. The files in /var/lib/dpkg/info should not be deleted.

3. It seems to me that the output was made from a live system from an Ubuntu installer, is that correct? What happens if you try booting "normal"?

Please also provide the output of

sudo fdisk -l
du -schx /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/*
ls -l /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/boot/
cat /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/etc/fstab

Absolutely; as mentioned I’m not tech savvy & 48hrs ago I’d never even used Linux so it’s all new to me. Appreciate you explaining it so at least now I know what I’m looking at, other explanations have conflicted.

That is correct. If you boot into normal mode after login you get black screen; back to login mode. Any terminals or anything you actually manage to get up don’t work because they won’t get past the login they just loop to.

Info you requested is as follows:

root@ubuntu:~# sudo fdisk -l
Disk /dev/loop0: 1.98 GiB, 2103640064 bytes, 4108672 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop1: 29.9 MiB, 31334400 bytes, 61200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop2: 54.98 MiB, 57626624 bytes, 112552 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop3: 255.58 MiB, 267980800 bytes, 523400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop4: 62.9 MiB, 65105920 bytes, 127160 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop5: 49.8 MiB, 52203520 bytes, 101960 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/sda: 465.78 GiB, 500107862016 bytes, 976773168 sectors
Disk model: ST500LT012-9WS14
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x93de1081

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 999423 997376 487M 83 Linux
/dev/sda2 1001470 976771071 975769602 465.3G 5 Extended
/dev/sda5 1001472 976771071 975769600 465.3G 8e Linux LVM

Partition 2 does not start on physical sector boundary.

Disk /dev/sdb: 57.7 GiB, 61937287168 bytes, 120971264 sectors
Disk model: USB DISK Pro
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00217761

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 120971263 120969216 57.7G c W95 FAT32 (LBA)

Disk /dev/mapper/ubuntu--vg-root: 461.42 GiB, 495435382784 bytes, 967647232 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/mapper/ubuntu--vg-swap_1: 3.89 GiB, 4156555264 bytes, 8118272 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
root@ubuntu:~# du -schx /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/*
13M /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/bin
4.0K /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/boot
4.0K /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/cdrom
12K /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/dev
15M /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/etc
327G /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/home
0 /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/initrd.img
0 /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/initrd.img.old
855M /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/lib
4.0K /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/lib64
16K /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/lost+found
12K /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/media
4.0K /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/mnt
4.0K /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/proc
600M /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/root
84K /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/run
15M /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/sbin
192K /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/snap
4.0K /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/srv
4.0K /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/sys
56K /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/tmp
3.2G /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/usr
6.9G /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/var
0 /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/vmlinuz
0 /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/vmlinuz.old
338G total
root@ubuntu:~# ls -l /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/boot/
total 0
root@ubuntu:~# cat /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578/etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
#UUID=747f0ada-87cf-4f47-8917-a707fb9feda1 /boot ext2 defaults 0 2
/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0
#UUID=747f0ada-87cf-4f47-8917-a707fb9feda1 /boot ext2 defaults 0 2
#UUID=747f0ada-87cf-4f47-8917-a707fb9feda1 /boot ext2 defaults 0 2
UUID=747f0ada-87cf-4f47-8917-a707fb9feda1 /boot ext2 defaults 0 2
root@ubuntu:~#

Also, could you explain why what you asked for says “Partition 2 does not start on physical sector boundary’” in red and what the best method would be to correct this if it needs it? Thanks.

From what you requested I was able to narrow down where some of the big files seem to be. I’ve narrowed down to a folder called deja-dup which has 3,183 items in it. Pressing properties on that gives the info, Type: Folder (inode/directory). Contents: 3,183 items, totalling 167.9GB. On entering this folder I find it is filled with nothing other than .gpg files for duplicity. A Google search tells me these are encryption files for backups?

Would I be right in guessing then that the problem is this program, duplicity, every time it has made a periodic backup has also made with it an encryption key and saved it at 52.5MB a time and these older encryption receipts essentially have never been deleted and that’s what’s hogged all the memory with 3,183 receipts now in this folder?

The "not on physical sector boundary" message is not relevant and can be ignored.

I do not see a space problem or inode problem anywhere, The reason that you are thrown back to the login screen must have a different reason.

Boot the system normally until you see the login screen, and instead of logging in press the key combination ctrl-alt-F3
You should then see a virtual terminal with a prompt requesting your username, and after the username the password.
Does this work, can you log on in this text mode?

If that works, you can enter commands like
sudo apt update
sudo apt full-upgrade

For ending this you can shut down the computer by entering the command
sudo shutdown

Does this work?

No that won’t work that’s the reason I’m using the virtual installer to bypass. If I go that route in the text mode after entering the username and password it just asks for them again on the next line in a never ending loop.

But you’ve been right here you’ve definitely on the right trail. Because in this deja-duo folder between July 31st 2018 and 1st August 2018 it generated 3,183 encryption keys at 52.5MB a time costing a whopping 167.9GB in total. So this has to be the issue?

So question being, am I safe to just delete the oldest of these .gpg files and the program will take from the soonest for the backups or have these been created as a result of multiple things being encrypted, let’s say for example an entire folder of ‘landscape photos’ being encrypted and these are the unlock encryption keys for the backup which will corrupt without them?

Essentially if they are safe to delete I would want to save maybe the last ten or even 20 to be safe and let the owner narrow them down further, which would allow me enough space upon deleting the rest to do the installs and work in the background I need to.

Or could it be, given this spans across a day, that this has been an automatic backup happening late at night which has froze midway through and attempted to automatically recover itself getting stuck at the same stage attempting it 3,183 times before it or the laptop gave up lol?

I guess what I want to be 100% certain of, is that this is not in fact an entire system backup which this program “Duplicity” has somehow broken down into equal packets and each of those packets has an encryption key of 52.5MB as some sort of higher security measure meaning you couldn’t decrypt anything from the backup without all the encryption codes to decrypt each 52.5MB sector and put it back together again like a jigsaw or something of that nature?

Talking to the owner they said the original issue on the laptop happened because after a recovery the battery died. So I’m guessing somewhere the laptop has to have emergency power shutdown settings which has forced a shutdown as something has been happening with the encryption/decryption process?

Question being therefore, what is safe to delete of these .gpg files and what is not?

I have to correct one of my conclusions.
Apparently I have overlooked a line in your output:

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/ubuntu--vg-root 476099632 452673736 0 100% /media/ubuntu/f94f4fee-a9cd-448d-a43a-cdc5ff74f578

Yes, that is a space problem, the main hard disk partition is nearly full.

And yes, it seems that you have identified the backup directory as being the one that consumes much space.
These file ending in *.gpg are not encryption keys, but are the backups which are encrypted.
They can be used to restore files.

The file names should give an indication of the date when each of these files was created, and whether each of them is a full backup, or just the incremental difference to the previous backup.

If they are full backups, then the older ones can be deleted and just the newest one be used for restoring (or maybe just keep the first one of each month to be able to restore the files to the state that they were at certain moments in the past).

If they are incremental backups, then for restoring the contents you would need a full backup file and all incremental files since the time of the full backup.

Your idea to delete the oldest files from that directory is definitely a promising approach.
As an even more secure approach you eventually could - instead of deleting - move them to some external storage.

Can you list a sample of the file names from that directory?
Do they all have similar size, or are there some with name and/or size deviating from the other ones?

This question was expired because it remained in the 'Needs information' state without activity for the last 15 days.