Unable to Update after initial installation

[gsarish]

Hit:1 http://ppa.launchpad.net/otto-kesselgulasch/gimp/ubuntu bionic InRelease
Hit:2 http://ppa.launchpad.net/teejee2008/ppa/ubuntu bionic InRelease
Hit:3 http://archive.canonical.com/ubuntu bionic InRelease
Hit:4 http://repo.linuxliteos.com/linuxlite diamond InRelease
Hit:5 http://us.archive.ubuntu.com/ubuntu bionic InRelease
Hit:6 http://us.archive.ubuntu.com/ubuntu bionic-security InRelease
Hit:7 http://us.archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:8 http://us.archive.ubuntu.com/ubuntu bionic-backports InRelease
Reading package lists...
E: Write error - write (28: No space left on device)
E: IO Error saving source cache
E: The package lists or status file could not be parsed or opened.

[Şerban S.]

Hi!
This is a common issue, especially when the version IS NEW.
You have to consider the fact that the various Apps, are released on a different time-line than Ubuntu (for one).
What this means is, there are still many Apps that have versions for Ubuntu 18.04.x, which is the core of Linux Lite and many other distros.
While Jerry works hard to gather as many apps as he can under Lite's umbrella, he can only solve problems related to the compatibility with the Linux Core, mainstream DEs and the mainstream WMs. The development of the Apps, is another very long story. Regardless the number of members in the development team in Linux Lite, they are too few to fix problems related to the thousands Apps that are running under Linux.
Since Linux Lite 5.0 has the Ubuntu 20.04 Core, this means all Apps have to be prepared to run under Ubuntu Core 20.04.x
So, given that fact, what can we do?

Solution:

1. Open Synaptic Package Manager.
2. Click the Settings menu item, then Repositories. A window will pop-up.
3. Click the Other Software Tab on this window.
4. Uncheck the checkbox for "http://ppa.launchpad.net/otto-kesselgulasch/gimp/ubuntu". I had trouble with GIMP many times. The "Stable" release cycle for GIMP, looks it is very different from the release cycle of Ubuntu Core. This prevents the apt-get and dpkg to fetch all the software database and leads to an early abortion of the task.

Other Apps I know that are behind the schedule and cause the same problem:

Grub Customizer:
http://ppa.launchpad.net/danielrichter20...zer/ubuntu
FSLint
Has Python issues, they are working to move to Python 3.x instead of Python 2.x.
While there may be many other apps that still lack a version for Ubuntu Core 20.04, those are the Apps I use and know about.
If you have any other PPAs that seem to lack the proper version (which is FOCAL), do the same and from time to time, re-enable the PPA and see if you get the same error message. If so, uncheck and check later for the newest version.


Issue 2: Hard Drive storage capacity
See the messasge you got from the apt-get / dpkg:

"E: Write error - write (28: No space left on device)"

Commonly, users use the default storage, which might be:
The Root Partition, /home directory, commonly named /sda1.
A /home partition (this is my case, and the name is /dev/sda5), which can be anything, from /sda4 to whatever number of partitions you have on the disk (I'll skip details).
Since assumming any of the above is a bad choice for me, here is what you can do:
1. If you have a /home PARTITION, you need to make room for more files. That means you have to check for some free space on the other drives, resize the one that has enough space, and then add the freed space to the partition that needs that space, either Root (/, /dev/sda1) or /home.

AFTER resizing, check if the update still gives you errors and if so, check the above solution.
From my perspective, it is more likely to be a storage issue than a Repository issue, but until the storage issue remains unsolved, both issues might be true.



I hope this solves the problem!

Best Regards!

PS:
If this answer solves the Update issue, please, mark it [SOLVED]. This will help other people track the solution, if they encounter the same kind of trouble.
Thanks!

[TheDead]

@Serban
Nice helpful answers in the forums, I clicked your Thank button. I was first! )

Ok, back to seriousness...
Have a related idea (question?) : Could it be that the USB key (i.e. the "Live" OS) is still the one booting after installation and/or that the installation was done on the wrong disk?
I have the habit or removing the install key/ISO after installation but what if you leave it plugged in, the boot menu will default to internal HDD I hope?
Could be a BIOS thing.

Anyhoo, it's just some blah blah and could be unrelated. You can elegantly ask to me to go off a bridge and I will acquiesce.

[Şerban S.]

@Serban
Nice helpful answers in the forums, I clicked your Thank button. I was first! )

Thanks! I returned the favor!

[...] Could it be that the USB key (i.e. the "Live" OS) is still the one booting after installation

I seriously doubt it.
Supposing we forget to get out the stick. What update is it running?
This would be possible only IF the Update command was issued FROM WITHIN the llive distribution.
While this is definitely possible, since we are on an "unwritable" medium, the ISO having a fixed size, I still doubt this happened.
I was once curious to see what happens if I trigger the update from a live distribution and the console message usually points to the media that is out of space.
Since the snippet contains only strictly the messages related to wget and the errors that occured, it is impossible to know for sure what really happened, so I went on the idea of a partition that is full since I would never issue an update command on a medium that is "ReadOnly", as the Live USB distros look like for the system. Due to the fixed size of the ISOs, even if there is lots of space on the drive, it remains unpartitioned, thus it looks like "Full". Knowing that, why would one issue "Update"?
But, as you pointed out, IT IS POSSIBLE.

[...] and/or that the installation was done on the wrong disk? [...]

Unlikely. It's waaaaay too hard to pick unintentionally EXACTLY a partition that is some 1 - 2 MB only larger than the installed OS. That would be wizardry! I mean, do you know exactly +/- 1 MB what space would it occupy after installation and size the partition exactly at this size UNINTENTIONALLY?
First scenario, is more likely to happen (Issue Update from the Live distro) than targeting a drive that has exactely the size of the installed distro and nothing more.
As far as I know, the script generated by wget (the update lists), is at most 50 - 100 KB (many times, even less!) so picking by mistake a partition with the exact size of the installed OS +/- 10 KB is really a weird scenario.
It IS possible, only on an live distro, though. This is exactely the case: fixed size of the partition.

In order to use "Persistent", you need a special ISO, with a special ISO Installer script to (A) check the amount of free space on the drive then ask you if you want it to partition and format as "Persistent" and (B), a special installation script that knows that the live distro actually CAN write on the stick and where exactely to do this.
I lack the knowledge if Linux Lite Live can do this. As far as I know, usually this kind of magic, is done for specific distros that are intentionally built to run from an USB stick, and they are usually "minimalist" distros, with a lot of tweaking for the OS, since running from USB is very slow and this requires high level knowledge on optimizing the kernel and the other components to use the lowest possible amount of RAM and CPU. Most of those distros, lack tons of features, exactely due to the resources problem.
I know this, because I tested myself the USB installation of some distros and they run like on a 386 CPU, regardless the amount of RAM or number of threads (nucleuses) per CPU.
Anyone can in fact test the speed of an USB stick, using the speed test from within hardinfo. They are comparable with the speed of a Blue-Ray, maybe a little faster sometimes.

All the best!

[TheDead]

Thanks for the explanations!
It was mentionned in other threads but I'll say it again, running from USB is nice but if you use them daily like me, it's worth every penny to buy fast USB keys.They are (really) not all alike and can render some experiences almost painful.
I started to use Sandisk Ultra's and Extreme's years ago and never looked back. The revelation was when I ran Win-something-something 10 from USB (Shhh!, never say its name or it will haunt you! ). And... it booted faster than from HDD.
I replaced all the other keys I had... Except Clonezilla, because it was too cool :
(related picture )

[Artim]

You want a really fast USB key?  Check this one out!

[gsarish]

Thank you very much for helping me on resolving my issues. Thank you very much once again.

[Şerban S.]

Thank you very much for helping me on resolving my issues. Thank you very much once again.

May you have a happy Linux Lite experience!
I really love Linux Lite!
I know this is called "subjectivism", but this is ME!