PINE64
not enough free space in /var/cache/apt/archives - Printable Version

+- PINE64 (https://forum.pine64.org)
+-- Forum: PinePhone (https://forum.pine64.org/forumdisplay.php?fid=120)
+--- Forum: PinePhone Software (https://forum.pine64.org/forumdisplay.php?fid=121)
+---- Forum: Mobian on PinePhone (https://forum.pine64.org/forumdisplay.php?fid=139)
+---- Thread: not enough free space in /var/cache/apt/archives (/showthread.php?tid=10808)



not enough free space in /var/cache/apt/archives - HLing - 07-23-2020

I keep putting off asking for help, have been looking on line for a solution to the various messages of "not enough disk space in file system root.." that comes up on my phone.  I have attempted to resize when I use Jumpdrive and then the disk utility or gparted on my desktop, but one time I think I wiped the wrong partition, and then despite reading and reading, I just don't have a clear idea of how to go about increasing the root file system without wiping everything.  I have the 7-17-20 image flashed to the EMMC. I'm now unable to update due to not enough free space in /var/cache/apt/archives for the 92.6MB of archives. 
Your help would be appreciated. I apologize for asking what must seem elementary to you all.... Undecided


RE: not enough free space in /var/cache/apt/archives - devrtz - 07-23-2020

I think the most "friendly" way would be using jumpdrive as you said and running gparted.
There should be two partitions for the blockdevice which is exposed over USB.
The first partition (about 115MB in size) is the boot partition. You want to resize the second partition which holds the root filesystem.

Btw: If I'm not mistaken the newer images do resize the filesystem on the first boot, so you could just flash it anew (remember to backup your /home if you have files in there that you do not want to lose)

Also: Feel free to ask for help here or come have a chat in the matrix channel. You can definitely find people there willing to help ;)


RE: not enough free space in /var/cache/apt/archives - dukla2000 - 07-23-2020

(07-23-2020, 11:04 AM)HLing Wrote: I keep putting off asking for help, have been looking on line for a solution to the various messages of "not enough disk space in file system root.." that comes up on my phone.  I have attempted to resize when I use Jumpdrive and then the disk utility or gparted on my desktop, but one time I think I wiped the wrong partition, and then despite reading and reading, I just don't have a clear idea of how to go about increasing the root file system without wiping everything.  I have the 7-17-20 image flashed to the EMMC. I'm now unable to update due to not enough free space in /var/cache/apt/archives for the 92.6MB of archives. 
Your help would be appreciated. I apologize for asking what must seem elementary to you all.... Undecided

The wiki has one way to do it. I do something similar each time I flash an image. I usually use JumpDrive and dd the image from my RockPro64, then
Code:
sudo parted /dev/sda
resizepart
2
100%
quit
sudo resize2fs /dev/sda2

HEALTH WARNING - the specifics above currently work for me but come with no warranty of any kind! Big Grin


RE: not enough free space in /var/cache/apt/archives - HLing - 07-23-2020

(07-23-2020, 12:46 PM)devrtz Wrote: I think the most "friendly" way would be using jumpdrive as you said and running gparted.
There should be two partitions for the blockdevice which is exposed over USB.
The first partition (about 115MB in size) is the boot partition. You want to resize the second partition which holds the root filesystem.

Btw: If I'm not mistaken the newer images do resize the filesystem on the first boot, so you could just flash it anew (remember to backup your /home if you have files in there that you do not want to lose)

Also: Feel free to ask for help here or come have a chat in the matrix channel. You can definitely find people there willing to help Wink
Thank you, devrtz, for your kindness.  Do I have to format the 3rd partition into a particular file system first in order to resize the 2nd partition?  I think the 3rd partition is about 11 G. and is ext4.

(07-23-2020, 03:21 PM)dukla2000 Wrote:
(07-23-2020, 11:04 AM)HLing Wrote: I keep putting off asking for help, have been looking on line for a solution to the various messages of "not enough disk space in file system root.." that comes up on my phone.  I have attempted to resize when I use Jumpdrive and then the disk utility or gparted on my desktop, but one time I think I wiped the wrong partition, and then despite reading and reading, I just don't have a clear idea of how to go about increasing the root file system without wiping everything.  I have the 7-17-20 image flashed to the EMMC. I'm now unable to update due to not enough free space in /var/cache/apt/archives for the 92.6MB of archives. 
Your help would be appreciated. I apologize for asking what must seem elementary to you all.... Undecided

The wiki has one way to do it. I do something similar each time I flash an image. I usually use JumpDrive and dd the image from my RockPro64, then
Code:
sudo parted /dev/sda
resizepart
2
100%
quit
sudo resize2fs /dev/sda2

HEALTH WARNING - the specifics above currently work for me but come with no warranty of any kind! Big Grin

just saw your reply, Dukla2000.  Thank you!  I will try it out. wish me luck!



RE: not enough free space in /var/cache/apt/archives - devrtz - 07-23-2020

(07-23-2020, 03:31 PM)HLing Wrote: <snip>  Do I have to format the 3rd partition into a particular file system first in order to resize the 2nd partition?  I think the 3rd partition is about 11 G. and is ext4.


Third partition? Are you sure that your are looking at the device (SD card? eMMC?) where mobian is installed?
I have seen that UBports has a partitioning layout with quite a few partitions. Are you sure that you are not looking at them?

On my mobian I have the following:
Code:
mobian@mobian:~$ lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mmcblk2      179:0    0  14,7G  0 disk
├─mmcblk2p1  179:1    0 121,1M  0 part /boot
└─mmcblk2p2  179:2    0  14,6G  0 part /



RE: not enough free space in /var/cache/apt/archives - HLing - 07-23-2020

(07-23-2020, 04:27 PM)Thanks for your reply! so yes, I did have another partition that was not recognized by pinephone.  I was hoping it could be used as storage.  So, seeing how I had no ceiling to grow the root file system I deleted the 3rd partition and then I was able to use Gparted and resized to 5.8G. (then i formatted the rest to extended ext4, but it looked strange, and I have yet to see if that will be usable or not).  There were a few glitches to updating after the successful resizing, like the message saying my update will not happen for another 17 days (?!) then I saw that my clock had been set to July 5.Then after finally updating, the phone was very sluggish for a while. I had to double/triple tap to get through. slowly but surely. devrtz Wrote:
(07-23-2020, 03:31 PM)HLing Wrote: <snip>  Do I have to format the 3rd partition into a particular file system first in order to resize the 2nd partition?  I think the 3rd partition is about 11 G. and is ext4.


Third partition?  Are you sure that your are looking at the device (SD card? eMMC?) where mobian is installed?
I have seen that UBports has a partitioning layout with quite a few partitions. Are you sure that you are not looking at them?

On my mobian I have the following:
Code:
mobian@mobian:~$ lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mmcblk2      179:0    0  14,7G  0 disk
├─mmcblk2p1  179:1    0 121,1M  0 part /boot
└─mmcblk2p2  179:2    0  14,6G  0 part /



RE: not enough free space in /var/cache/apt/archives - jed - 07-28-2020

As an aside, should you reach this limitation with a correctly partitioned eMMC (or microSD card):

Code:
apt autoclean

This deletes stale .deb files, which is imperative on a rolling system - be it testing or unstable.


RE: not enough free space in /var/cache/apt/archives - HLing - 07-29-2020

(07-28-2020, 02:07 PM)jed Wrote: As an aside, should you reach this limitation with a correctly partitioned eMMC (or microSD card):

Code:
apt autoclean

This deletes stale .deb files, which is imperative on a rolling system - be it testing or unstable.
 Thanks, jed.  I did come across the code: sudo apt autoremove  while trying to free up some space.  It didn't give me enough at the time, but i understood it to be part of good maintenance practice after each update.