Need to change path for installing packages

When I first installed manjaro a few weeks ago I’ve got a problem with my storage selections and it seems I haven’t solve it yet:

I have a 16gb SSD and a 500g HD
and when installing it, I choosed the SSD to be /boot, and my HD to be /home

At the first time, I made a wrong choice and everything on internet I was downloading (not only packages), was being saved at the SSD, so I reinstalled manjaro and now that’s better, but I notice all packages are going to SSD and well, 16gb’s not a huge space.

Can someone help me on this?
Maybe if it’s possible to change the path for new packages and use the HD.

Hi @mariarttr,

I suspect you’ll find this extremely helpful:

2 Likes

Well, everything depends on how you’ve partitioned your drives, but yes, in theory it is possible to fine-tune this.

What you first and foremost need to understand is that GNU/Linux is a UNIX system, and that UNIX uses a standardized directory hierarchy — called the Filesystem Hierarchy Standard.

Unlike in the DOS- and CP/M-derived multi-volume approach of Microsoft Windows — which I presume you’re most familiar with — UNIX systems fully integrate the application software with the operating system itself at the filesystem level. Therefore, executable files are commonly all kept under the /usr hierarchy — usually in /usr/bin, but there are exceptions — and if they are software packages that were not installed by way of the system’s own package managers (i.e. pacman or pamac) then they are put under /opt.

Now, the best way of doing what you would want is to have /usr be located on your HDD instead of on your SSD, and to have it mounted automatically at boot time.

This is actually quite common, but in Manjaro and other distributions that use systemd as the service manager, this requires an extra step, namely, you have to modify the initramfs for your kernel(s) to have them automatically mount /usr in early user space — i.e. right after the kernel has been loaded but before systemd is started — because otherwise you’ll run into a chicken-and-egg problem due to the fact that systemd itself lives under /usr.

I have detailed the procedure in the following tutorial… :arrow_down:

The above is the complete tutorial, but if you directly want to jump to the section about splitting off /usr, then click here. :wink:

2 Likes

Yes — my apologies. It is best that you read the whole tutorial. :wink:

2 Likes

So once everything is going to the right place, my /home
…unless the exectuable ones, that would be only /usr for splitting off /
Is that right?

Thank you very much for help.

The tutorial lists all of the directories whose contents can be split off onto other (Linux-native) partitions — no ntfs or exfat, of course. You can split off quite a lot, actually, albeit not everything.

As an example, here’s how I installed my system — note: this is all on an SSD, and I do also have an HDD, but the HDD is actually smaller than my SSD and I’m only using it for storing backups.

:arrow_down:

[nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] >  lsblk -a /dev/sda
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda       8:0    0 931.5G  0 disk 
├─sda1    8:1    0   512M  0 part /boot/efi
├─sda2    8:2    0   512M  0 part /boot
├─sda3    8:3    0     1G  0 part /
├─sda4    8:4    0    22G  0 part /usr
├─sda5    8:5    0   512M  0 part /usr/local
├─sda6    8:6    0     2G  0 part /opt
├─sda7    8:7    0   1.5G  0 part 
├─sda8    8:8    0   400G  0 part /srv
├─sda9    8:9    0   450G  0 part /home
├─sda10   8:10   0    10G  0 part 
└─sda11   8:11   0    20G  0 part /var

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       511M  544K  511M   1% /boot/efi
/dev/sda2       488M   59M  393M  14% /boot
/dev/sda3       1.0G   25M  881M   3% /
/dev/sda4        22G  8.1G   14G  38% /usr
/dev/sda5       512M  3.4M  499M   1% /usr/local
/dev/sda6       2.0G  152M  1.7G   9% /opt
/dev/sda8       400G  102G  299G  26% /srv
/dev/sda9       450G  2.6G  446G   1% /home
/dev/sda11       20G  596M   20G   3% /var
1 Like

Just remember I’ve made a mess while installing manjaro, because in the installer screen I couldn’t make the SSD only for boot and the HD for files, packages, etc. I remember I’ve even disabled uefi, but well then I could install it. Don’t know if that is something I’d need to go back and change, don’t know the difference.

But: The hole 500gb HD is mounted at /home and /usr is at the 16gb ssd,
so it seems it would be nice for me to separate the HD for /home and /usr.

To make the hole process it meant formatting the spare partition, so…I should format the HD, right?

also,

I couldn’t log out of GUI and see login screen again. It’s been a few days since I don’t see that screen. I can only open GUI system with startx /usr/bin/xfce4-session - I’m having a lightdm display manager error and couldn’t solve it yet. :frowning_with_open_mouth:

Please educate yourself about filesystem hierarchy in linux and what sane defaults are. Yours aren’t.

Throw it in a bin. (Do 16 GB SSDs even exist? I bought 120 GB 10 years ago for 80 euros.)

1 Like

That is correct. Unfortunately, the developers of the Calamares installer did not provide for a way to do this at installation time. That doesn’t mean that it cannot be done — obviously I did it :stuck_out_tongue: — but it does require a bit of manual intervention, and knowing what you’re doing.

I come from quite a different background compared to most of our users — and most of the Calamares developers — and so I already had a sufficient amount of experience to be able to circumvent this limitation of the Calamares installer.

For the Calamares developers, it’s easier to say “We’re not going to support that” than to actually modify their code so that it would be supported. In a way, I understand their stance, because most of the people new to Manjaro are also new to GNU/Linux in general, having first used Microsoft Windows or Apple macOS, and both of those systems install everything in a single volume by default.

Well, a native UEFI boot is actually the preferred way of installing — it’s superior to a legacy BIOS installation in many ways — but Secure Boot and Fast Boot have to be disabled. It’s not that difficult to do, though.

If you’ve partitioned the whole HDD as a single partition for /home, then that’s not going to work for moving the contents of /usr over to the HDD, of course. You’d need to shrink /home and create a separate partition of about 20 to 30 GiB for /usr.

You could try shrinking /home and creating a new partition for /usr in the free space. But in that case, it would be best that you work from the live session of the installer USB/DVD/CD instead of from single-user mode, even if only because single-user mode does not have a graphical user interface — it’s a command-line terminal environment only.

Here’s what I think would be the best approach… :arrow_down:

  1. Boot up from the installer USB/DVD/CD.

  2. Open up the partition manager and resize the /home partition on the HDD. You only need about 20 to 30 GiB of free space.

  3. Create a new ext4 partition in that free space and save the layout. Make sure you copy the UUID of the new partition, because you’re going to need that.

  4. Open up a terminal window and issue the following commands… :arrow_down:

sudo su -
manjaro-chroot -a

Now, follow these steps. :arrow_down:

  1. Mount the new partition at the directory /mnt inside the chroot environment. I’m going to use /dev/sdb2 in the example below as the designation for your new partition, but change this to what applies on your system. :arrow_down:
mount -t ext4 /dev/sdb2 /mnt
  1. Copy over the contents of /usr to the new partition. This is going to take quite some time… :arrow_down:
cp -RPpv /usr/* /mnt/
  1. Verify that everything is there. Note that there may be a small difference in the reported sizes of the du command, which could be due to fragmentation… :arrow_down:
ls -l /mnt/
du -sh /mnt/
du -sh /usr/
  1. Now, grab the note where you wrote down the UUID of the new partition and add a record for the partition to /etc/fstab:arrow_down:
nano /etc/fstab

The new record should look something like this… :arrow_down:

UUID=the-UUID-you-wrote-down   /usr   ext4   auto,defaults     0   0

Save the file with Ctrl+O and Enter/Return, and exit nano with Ctrl+X.

  1. Edit the file /etc/mkinitcpio.conf:arrow_down:
nano /etc/mkinitcpio.conf

Look for the line that starts with… :arrow_down:

HOOKS=(base udev ....

Now, on that line, add the word usr right after the word udev and before the word autodetect. Then, at the end of that line, add the words fsck and shutdown right before the closing ellipsis.

Save the file with Ctrl+O and Enter/Return, and exit nano with Ctrl+X.

  1. Now you must rebuild the initramfs for every installed kernel… :arrow_down:
for i in /boot/vmlinuz* ; do mkinitcpio -P -k $i ; done 
  1. Now you must update the boot loader configuration… :arrow_down:
update-grub
  1. And then now the last step, i.e. cleaning up and reclaiming the space on the SSD that was formerly used by the contents of /usr. For this, you’ll need to exit the chroot first… :arrow_down:
exit

… but now you have to mount your root filesystem again without chrooting. If the root filesystem is /dev/sda2 — replace this by the correct designation — then issue these commands… :arrow_down:

[ ! -d /mnt ] && mkdir /mnt
mount -t ext4 /dev/sda2 /mnt
rm -rf /mnt/usr/*

Make sure there are no typos in those commands. Every space character needs to be where it is, and you should of course replace /dev/sda2 with the proper device special file for the root filesystem on your SSD.

  1. Finish up by unmounting the root filesystem again and cleanly rebooting. Be sure to remove the USB/DVD/CD in time, and cross your fingers. :slight_smile: :arrow_down:
umount /mnt
systemctl reboot

:crossed_fingers:

2 Likes

You might need to add some additional hooks for mkinitcpio, IIRC - for separate /usr.

I did that. See my above post. :stuck_out_tongue:

Ah sorry. Sun in shining into my eyes and can’t see and read properly, apparently. :stuck_out_tongue:

1 Like

That’s the SSD my laptop came with. At least it serves for booting.

How should sane defaults be?

just a doubt in here, you said before that i would need about 22-30gb for /usr, right?
so…am i going to save all packages there? :face_with_monocle: will that be enough? or packages should be installed in another directory?

Yes, for a normal installation, 20 to 30 GiB will be more than enough. But if you’re in doubt, make it 50 GiB. :wink:

Not “packages” but executable files, libraries, et al. The packages themselves are downloaded to /var/cache/pacman/pkg and are no longer needed once they have been unpacked and installed, although the general advice is to keep at least the last two versions of the packages around.

The system will normally periodically clean out the cache except for those last two generations, but you can do this manually. For instance, the command… :arrow_down:

sudo paccache -rvk2

… will clean out all downloaded packages from the repositories except for the last two generations. That way you can always roll back a package to an earlier version if the new version gives you trouble. But at the same time, downgrading one or several packages creates a partial-upgrade situation, and this is not supported, so it’s only really useful as a temporary workaround.

1 Like

hope this is last question, Aragorn,
but i don’t always know when i need to change some key that applies to my system
so… when i see /usr/* i wonder if i should change *for something else…

No, that is to be used literally. You don’t want to copy the directory /usr, because that directory needs to sit on the root filesystem as the mountpoint for the new partition. So what you need to copy is the content of /usr, and recursively so. That’s what the -R option is for. The other options are for preserving file ownership and permissions, and for making the copy process verbose, so that you see the files being copied over.

The only two things you need to change in my above explanation are the device special files for the partitions.

I named them /dev/sdb2 for the newly to be created partition on your HDD and /dev/sda2 for the root filesystem on your SSD, and so that’s what you need to adapt. Everything else is to be taken over verbatim — well, you do have to add the correct UUID to your /etc/fstab, but I reckon that was already beyond doubt.

1 Like

theres no such line in mkinitcpio.config

GNU nano 6.4                 /etc/mkinitcpio.config 

That’s because the file does not exist — you entered the wrong filename and so now you are creating a new and empty file. :stuck_out_tongue:

The correct name is /etc/mkinitcpio.conf. :wink:

(The line is somewhere near the bottom, by the way.)

there’s 4 lines that starts with HOOKS=(base udev so I’ll be adding usr to all them?