From: Dale <rdalek1967@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] LVM and making /var larger, file system won't resize.
Date: Sun, 11 May 2025 07:21:34 -0500 [thread overview]
Message-ID: <a6b2027b-3540-fa8b-a815-28890c11ede2@gmail.com> (raw)
In-Reply-To: <8569067.NyiUUSuA9g@rogueboard>
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
:-) :-)
next prev parent reply other threads:[~2025-05-11 12:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-11 5:41 [gentoo-user] LVM and making /var larger, file system won't resize Dale
2025-05-11 10:20 ` Michael
2025-05-11 10:40 ` Alexandru N. Barloiu
2025-05-11 12:21 ` Dale [this message]
2025-05-11 12:44 ` Michael
2025-05-11 13:10 ` Dale
2025-05-11 13:21 ` Michael
2025-05-11 14:39 ` Dale
2025-05-11 14:43 ` Michael
2025-05-11 15:10 ` Dale
2025-05-11 15:52 ` Michael
2025-05-11 16:14 ` Dale
2025-05-11 16:36 ` Jay Faulkner
2025-05-13 22:14 ` Frank Steinmetzger
2025-05-13 22:40 ` Dale
2025-05-13 22:03 ` Frank Steinmetzger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a6b2027b-3540-fa8b-a815-28890c11ede2@gmail.com \
--to=rdalek1967@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox