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 08:10:48 -0500 [thread overview]
Message-ID: <bcb8eef3-4579-d662-35d5-4a028a71da9a@gmail.com> (raw)
In-Reply-To: <4858231.rnE6jSC6OK@rogueboard>
[-- Attachment #1: Type: text/plain, Size: 5361 bytes --]
Michael wrote:
> On Sunday, 11 May 2025 13:21:34 British Summer Time Dale wrote:
>> 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.
> [snip ...]
>
>> Well, I still like to compile my own, that way I can use my own USE
>> flags and such.
> [snip ...]
>
>>>> 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
> Try:
>
> lvdisplay
> vgdisplay
> pvdisplay
>
> Your lvs output shows VG named "OS" and the LV named as "var".
>
> As I understand this, subdirectories of /dev/mapper/ would be VGs. The /dev/
> VG/LV nomenclature should be used to perform a resize on the LV.
>
> Try 'lvscan' to see what path to use for the resize command.
>
I usually go in the other direction, pv first, vg and then lv. I listed
them in the order you posted them tho. I removed unrelated things like
/home and a spare drive that I don't think has anything on it now.
root@fireball / # lvdisplay
--- Logical volume ---
LV Path /dev/OS/var
LV Name var
VG Name OS
LV UUID Vqlsc3-jYak-HHAy-AkZg-02hH-1RNK-RQ4vRA
LV Write Access read/write
LV Creation host, time ,
LV Status available
# open 1
LV Size 68.00 GiB
Current LE 17408
Segments 5
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:4
root@fireball / # vgdisplay
--- Volume group ---
VG Name OS
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 22
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 1
Act PV 1
VG Size <124.46 GiB
PE Size 4.00 MiB
Total PE 31861
Alloc PE / Size 30480 / 119.06 GiB
Free PE / Size 1381 / 5.39 GiB
VG UUID gefYst-CTE9-B4Hp-wy53-WBxr-J7Li-h8c90V
root@fireball / # pvdisplay
--- Physical volume ---
PV Name /dev/sda7
VG Name OS
PV Size 124.46 GiB / not usable 3.80 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 31861
Free PE 1381
Allocated PE 30480
PV UUID rQs0i9-1LRP-0X2Y-p2WV-wptb-Xebe-wOmmjx
root@fireball / #
I do like this command better. :-D I gotta see what this does for
encrypted stuff. o_O
root@fireball / # lvscan
ACTIVE '/dev/home/home-lv' [<7.28 TiB] inherit
ACTIVE '/dev/backup/backup' [698.63 GiB] inherit
ACTIVE '/dev/OS/usr' [39.06 GiB] inherit
ACTIVE '/dev/OS/var' [68.00 GiB] inherit
ACTIVE '/dev/OS/swap' [12.00 GiB] inherit
root@fireball / # resize2fs /dev/OS/var
resize2fs 1.47.2 (1-Jan-2025)
open: Device or resource busy while opening /dev/OS/var
root@fireball / #
I think all those link to the same device node, usually dm-<some number>
tho. Still, I tried it anyway. Worst thing, same excuse for not
resizing the darn thing. :/
Am I going to have to boot other media and resize this thing????
Dale
:-) :-)
[-- Attachment #2: Type: text/html, Size: 7757 bytes --]
next prev parent reply other threads:[~2025-05-11 13:11 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
2025-05-11 12:44 ` Michael
2025-05-11 13:10 ` Dale [this message]
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=bcb8eef3-4579-d662-35d5-4a028a71da9a@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