Full Root. Cannot reallocate free space from xfs. Is a fresh install the only way?
- Anmelden oder Registrieren um Kommentare zu schreiben
Root / is full. df -h shows 0 as Available, 100% as Use.
I would like to know if my only option right now is to reinstall Trisquel from a USB Startup Disk.
I was not careful enough; I ran apt install texlive-full. The installation did not complete. I cannot remove the already installed part of texlive-full, or bits of it that are on the system.
I tried apt autoremove and apt purge texlive-full in vain. Some unmet dependencies prevent me from installing or removing any package or using apt at all.
I wondered if I could remove a (large) package using ncdu -x /, but that sounds like a bad idea.
I deleted as many logs as I could using ncdu.
I only have free space available on a xfs partition which, I understand, I cannot reduce to move space to the unallocated partition, and then root; if that is how I should resize root.
When I boot (without the USB), I can only access the system via tty.
I attached a screenshot of GParted (from a live boot).
I have an up-to-date backup of /home with Backintime (I took a last snapshot before I switched off my computer - when I was still with GUI).
Is reinstalling Trisquel the only thing I can do?
| Anhang | Größe |
|---|---|
| gparted.png | 57.38 KB |
I guess you executed 'sudo apt clean' too, right?
Since you have a backup, you can, from a live system:
- delete /dev/sda4;
- expand /dev/sda3 in the free space (you may want a ~50 GB root partition to be at ease when it will come the time to upgrade to Trisquel 12);
- recreate a partition for /home, taking the rest of the disk (you may prefer ext4, which can be shrunk);
- adapt the line corresponding to /home in /etc/fstab (that of the installed system, not that of the live system) if necessary (in the first column, /dev/sda4 can identify it, if the number has not changed, xfs in the third column must become ext4, if you chose that type of the filesystem);
- reboot on the installed system;
- log in a text session;
- now that there is space available on /, try to fix your system, maybe with 'sudo apt-get -f install';
- restore the backup.
> I guess you executed 'sudo apt clean' too, right?
Thanks for asking.
I wasn't sure so I logged back in the installed system, landed on tty as expected, ran 'sudo apt clean'. At first it seemed that nothing had happened (after I typed in my password), I landed back on the prompt $. Then a second later the GUI showed up, and I was able to log in into the installed system via GUI.
Next I was able to do the following:
I ran 'sudo apt autoremove', still, there were these unmet dependencies. Apt suggested using '--fix-broken' so I ran 'sudo apt autoremove --fix-broken'. The command ran as expected.
Next I ran 'apt list texlive-full' which showed that the package was installed, so I ran 'sudo apt purge texlive-full' to take the chance to clear some space. Then I ran 'sudo apt autoremove' as the previous command suggested.
Now 'df -h' shows:
Filesystem Size Used Avail Use% Mounted on
tmpfs 368M 2.0M 366M 1% /run
/dev/sda3 19G 15G 2.4G 87% /
tmpfs 1.8G 0 1.8G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
/dev/sda2 512M 296K 512M 1% /boot/efi
/dev/sda4 447G 324G 123G 73% /home
tmpfs 368M 156K 368M 1% /run/user/1000
/dev/dm-0 3.6T 203G 3.3T 6% /media/user/bit-backup
I guess my next step is to resize /, say, to ~50 GB as you suggest. Maybe less ~35 GB, if you think it is not too little.
Since I understand I am stuck with this XFS partition, are the steps you provided above the way to go? Or can I get away without deleting the XFS partition?
Maybe less ~35 GB, if you think it is not too little.
If you do not plan to install heavy packages (the LaTeX documentation takes much space indeed), it may be enough. Remember that the upgrade of the distribution requires much free space: the packages are all downloaded before being installed, newer versions tend to take more space and packages that are not needed anymore are only removed at the end.
Since I understand I am stuck with this XFS partition, are the steps you provided above the way to go? Or can I get away without deleting the XFS partition?
XFS cannot be shrunk. You really need to delete the partition to make some free space.
> XFS cannot be shrunk. You really need to delete the partition to make some free space.
Ok. I will tackle this next.
One question: is it possible to encrypt /home when I "recreate a partition for /home"?
Also, about:
> adapt the line corresponding to /home in /etc/fstab (that of the installed system, not that of the live system) if necessary (in the first column, /dev/sda4 can identify it, if the number has not changed, xfs in the third column must become ext4, if you chose that type of the filesystem);
I am not too clear about this; do you know if there is a more detailed guide about this step on this forum I could follow? If not, nevermind. I will see when I have to do it, maybe it will become obvious. Otherwise I'll come back here.
Thanks for the extra suggestion about the size of /. And thanks a lot for your help (so far), and the quick replies. Anyway, I will post here again once I've tried the steps.
One question: is it possible to encrypt /home when I "recreate a partition for /home"?
Yes, but I have always let the installer encrypt for me. https://trisquel.info/en/wiki/linux-hard-disk-encryption-luks or https://trisquel.info/en/wiki/encrypt-home-directory-after-install probably help.
I am not too clear about this; do you know if there is a more detailed guide about this step on this forum I could follow?
It is quite easy. If the new filesystem you format for /home is /dev/sda4 and of the type XFS, then the line about /home in /etc/fstab can be:
/dev/sda4 /home xfs defaults 0 0
If it is of the tye Ext4 then xfs must become ext4. If you want to read more about fstab:
$ man fstab
I'm pretty certain that in modern usage that your entries in /etc/fstab should point to UUID's instead of your partitions' /dev/ locations. Because those /dev/ locations can change over time. Correct me if I'm wrong, or if UUID's don't apply to XFS partitions or something of that nature.
UUID's can be obtained with the blkid command.
I'm pretty certain that in modern usage that your entries in /etc/fstab should point to UUID's instead of your partitions' /dev/ locations.
Yes. Or labels. 'man fstab' explains:
LABEL= or UUID= may be given instead of a device name. This is the recommended method, as device names are often a coincidence of hardware detection order, and can change when other disks are added or removed.
My understanding is that Staircase's machine is a laptop or a desktop computer (since TeX Live was installed) and not a server with several disks. If there is no /dev/sdb, using device names in /etc/fstab should raise no problem.
I am a translator!
In step 4 of Magic Banana's instructions (so after you recreated the partition for home), you need to do
df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 400584 1248 399336 1% /run
/dev/vda3 14421444 8469636 5197428 62% /
tmpfs 2002908 0 2002908 0% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
/dev/vda5 24778780 77584 23417152 1% /home
/dev/vda2 524252 296 523956 1% /boot/efi
tmpfs 400580 120 400460 1% /run/user/1000
Here, you see that /home is on /dev/vda5.
There is a line for /home in /etc/fstab as well. That line may start with /dev/sdaN, where N is a single digit, or with something like UUID=4f05023e-e785-4c8f-bf28-0866fb567525.
In the first case, you need to modify the begining of the line so that it starts with /dev/sdaN that you saw in df (/dev/vda5 in the above case).
In the second case, you need to use blkid with /dev/sdaN that you saw:
blkid /dev/vda5
/dev/vda5: UUID="4f05023e-e785-4c8f-bf28-0866fb567525" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="ed8ffb4a-febd-4545-a54c-1cd914ad5d26"
In that case, you need to replace what is after UUID= in the line of /etc/fstab for /home with what is within the quotes (without the quotes):
UUID=4f05023e-e785-4c8f-bf28-0866fb567525 /home ext4 relatime 0 2
As mentioned by Magic Banana, if you use ext4, you need to replace "xfs" with "ext4" on that line.
Here, you see that /home is on /dev/vda5.
If you see that, then /etc/fstab is already OK. Device names can be determined in many ways. Given Staircase's original post, I imagine he or she will create the new partition with GParted. That program will then show the proper name. To rather use UUIDs, lsblk gives a nice output:
$ lsblk -f
In the second case, you need to use blkid with /dev/sdaN that you saw
You do not "need" to identify the filesystem in the same way as it used to. You can substitute "UUID=..." with a device name for instance.
I am a translator!
I guess the device should work but as observed by andyprough, UUID is probably a more robust method and this is what the 11.0.1 iso graphic installer did when I installed Trisquel 11 from the 11.0.1 iso again last week (keeping virtual machines for testing and getting screenshots for documentation), without LVM and ciphering.
I decided to go for a new install. Encrypting my drive is something I've been thinking I should have done before. This problem is the chance to do so. I read online that Gparted does not give the possibility to encrypt a newly created partition (but only to open and close existing ones https://gparted.org/display-doc.php?name=help-manual).
That said, before I decided that, I actually tried to delete, create and restore /home. I got stuck on step 4.
Deleting /home, expanding /, and recreating /home was easy with GParted. I got confused on step 4. When I ran 'df', it only showed the live USB, and 'vi /etc/fstab/' only had 2 lines (something with 'overlay' and 'tmfs' based on my notes). That is where I got confused: I thought step four should take place on the live system but I could not see how since /etc/fstab/ did not show me the drive. So I decided to try booting from the drive[1]. There blkid and /etc/fstab/ were showing the lines you show in your examples, but the disk was mounted - so I did not think editing the files would help. Still, I tried, I did replace the UUID of old /home with the UUID of new /home, and replaced 'xfs' with 'ext4'. When I rebooted, the screen with a GUI to log in was there (before it was some error screen that landing me on a text session), however, I was not able to go beyond that screen. Each time I typed my password, and press the Return key, the exact same log in screen reloaded. The only way out was through a text session (pressing key Alt + Ctrl + F1 or F3? I don't remember). Your explanations helped me understood what needed to be done, but I wasn't in the right place, I guess. Overnight thinking led me to the idea of a fresh install with encryption. Thanks for you help all.
[1] EDIT: maybe at that point I knew I'd go for a fresh install.
'vi /etc/fstab/' only had 2 lines (something with 'overlay' and 'tmfs' based on my notes). That is where I got confused: I thought step four should take place on the live system but I could not see how since /etc/fstab/ did not show me the drive.
That is the /etc/fstab file of the live system. As I wrote, you wanted that of the installed system: you had to mount the root partition of the installed system. The mount command could be used. Or the graphical file manager. From the mount point, the file fstab would then be in the etc directory.
I did not think editing the files would help.
It did, as you saw.
Each time I typed my password, and press the Return key, the exact same log in screen reloaded.
I believe it is simply because the home directory of your user was absent. I forgot to tell you to recreate it! sorry!
The only way out was through a text session (pressing key Alt + Ctrl + F1 or F3? I don't remember).
It does not matter what text session you use. From there you could have created the home directory of the user (with mkdir) or even restored the whole backup ('sudo backintime restore', if you use Trisquel's default backup system).
That is the /etc/fstab file of the live system. As I wrote, you wanted that of the installed system: you had to mount the root partition of the installed system. The mount command could >be used. Or the graphical file manager. From the mount point, the file fstab would then be in the etc directory.
Thank you for spelling out this step.
I believe it is simply because the home directory of your user was absent. I forgot to tell you to recreate it! sorry!
No worries. Thank you for letting me know.
It does not matter what text session you use. From there you could have created the home directory of the user (with mkdir) or even restored the whole backup ('sudo backintime restore', if you use Trisquel's default backup system).
(I did not know we could switch between text sessions?[1]). Thanks also for spelling out this step. (Yes, I use BackInTime). Thank you again.
EDIT: [1] found this in one of Magic Banana's old posts: "By default, six text sessions are available. You can switch between them with Ctrl+Alt+F1, Ctrl+Alt+F2, Ctrl+Alt+F3, etc." https://trisquel.info/en/forum/new-netinstall#comment-47809