Michael wrote: > On Sunday, 11 May 2025 06:41:46 British Summer Time Dale wrote: >> Howdy, >> >> I'm updating my old rig. Well, I'm trying to. I kept running out of >> space while compiling rust. I need to make /var larger. > There are some alternatives to this, especially for rust: > > 1. First of all not compile it locally. You could use rust-bin, or you could > use the gentoo binhost package if your USE flags are default, or compile it > on > another PC of yours which has enough space, using appropriate C, CPU and USE > flags and then bring it over to this PC to emerge it as a binary. > > 2. Or if you want to compile it locally, you can consider 'mount --bind' to a > new directory on any other local fs, which has a large enough partition for > this job. Or you if you run out of fs space altogether, or RAM isn't enough > and therefore you can't use tmpfs for /var/tmp/portage and/or it swaps > continuously, you can configure and load zram, and/or set a lower number of > jobs in /etc/portage/package.env for rust to allow it to fit within available > fs and RAM. Sure, it will take for ever to emerge on say a PC with 4G of > RAM, > but if you *must* emerge it locally you should be able to get there. > > 3. You can even use NFS and mount a fs over the network for this purpose, but > this is rather more complicated than the above options and I expect it will > be > slow. >
Well, I still like to compile my own, that way I can use my own USE flags and such. I'd have to use some other drive to mount it elsewhere. I'd rather just grow that mount point and it will help with other large packages too. >> Thank goodness >> that is on a LVM. I have room left on that old drive so I wanted to >> just extend and then resize the ext4 file system, like I've done in the >> past I might add. I dug out my little cheat sheet and sure enough, >> lvextend -L <size to add> < lv name> and then resize file system. >> Simple enough. Should be, but it's not. This is some info, keep in >> mind, this is my old rig, not my new one. >> >> >> >> root@fireball / # pvs >> PV VG Fmt Attr PSize PFree >> /dev/sda7 OS lvm2 a-- <124.46g 5.39g >> root@fireball / # vgs >> VG #PV #LV #SN Attr VSize VFree >> OS 1 3 0 wz--n- <124.46g 5.39g >> root@fireball / # lvs >> LV VG Attr LSize Pool Origin Data% Meta% Move Log >> Cpy%Sync Convert >> swap OS -wi-ao---- >> 12.00g >> usr OS -wi-ao---- >> 39.06g >> var OS -wi-ao---- >> 68.00g >> >> root@fireball / # resize2fs /dev/mapper/OS-var >> resize2fs 1.47.2 (1-Jan-2025) >> open: Device or resource busy while opening /dev/mapper/OS-var >> root@fireball / # > Err ... what is this 'OS-var'? > I named it OS-var when I set up LVM. That way I know it is OS related and is the /var directory. I named /usr OS-usr too. :-D >> I checked other info on how to do this with searches. All report the >> same thing. Use lvextend to add to the size and then resize the file >> system. It also says to use resize2fs to do it. > Did you run lvextend first? Given your VG OS has 5.39G free space, I think > something like this should allocate extra space to your LV 'var': > > lvextend -L +5G /dev/OS/var > > or > > lvextend -l +100%FREE /dev/OS/var > > Then you could check the fs before you resize it: > > e2fsck -v /dev/OS/var > > resize2fs /dev/OS/var > > Check the above before you run them as things may have changed, I'm going by > (long term) memory here and check the names of VG, LV. I already did the extend part. I added 15GBs I think, which left about 5GB, in case /usr needs it later on. I'll try to do the e2fsck first. See if that helps. Well, that didn't work. I got this. root@fireball / # e2fsck -v /dev/mapper/OS-var e2fsck 1.47.2 (1-Jan-2025) /dev/mapper/OS-var is mounted. e2fsck: Cannot continue, aborting. root@fireball / # Do I have to unmount /var before I can do anything to that file system? When I did this in the past, I don't recall having to unmount first. It seems whether it is resize or fsck, it wants it unmounted first. Is there some change that requires a file system to not be in use before it can be resized now? Is there something else we are missing? Dale :-) :-)
