[gentoo-user] LVM and making /var larger, file system won't resize.

[gentoo-user] LVM and making /var larger, file system won't resize.

[Dale]

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.  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 / #




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.  I even rebooted just
to be sure something wasn't off somewhere.  In the past, I've resized
ext4 while mounted several times, especially when growing the file
system and when encrypted I might add.  Am I missing something?  Has
something changed since I did this several years ago on this rig?  Some
extra step that isn't well documented yet for search engines to find? 
Or have I slipped my old rig into a worm hole??  ROFL 

By the way, I added 15GBs I think.  Old rig has the OS on a 160GB drive,
that someone from this list donated I might add. 

Any thoughts?  What's making this not work this time?

Dale

:-)  :-) 

P. S.  The only way I could work around this, uninstall Kicad and clean
out distfiles, including for packages I have installed.  O_O  There is a
next time tho. 

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]

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.


> 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 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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Alexandru N. Barloiu]

On 5/11/2025 1:20 PM, Michael wrote:
> 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.

Can just compile some place else. See:

PORTAGE_TMPDIR="/ramfs"
PORTAGE_TMPFS="/ramfs"

Can place it in make.conf or per package in package.env.

Don't need to compile in /var.

> 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.

Just to be clear... this is prolly a bad idea. IF you HAVE TO go this 
over NFS, it would be better to just mount  -o loop a nfs shared image 
instead of a directory. That way, your local kernel manages the file 
system (permissions and all that), instead of trying to relay all that 
info to a remote kernel over nfs.

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Dale]

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

:-)  :-) 

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]

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.


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Dale]

[-- 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 --]

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]

On Sunday, 11 May 2025 14:10:48 British Summer Time Dale wrote:

> 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   <== That's the path
>   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 / #

Hmm ... the fine manual of resize2fs command states upfront:

"The  resize2fs program will resize ext2, ext3, or ext4 file systems.  It can 
be used to enlarge or shrink an unmounted file system located on device.  If 
the file system is mounted, it can be used to expand  the  size of  the  
mounted  file  system,  assuming the kernel and the file system supports on-
line resizing."

So you should not need to unmount it - but I wonder if the LVM layer 
introduces some complexity here.  :-/


> 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???? 

Since /var/ is in use by the OS and you keep getting warnings about it being 
busy, I think you'll have to reboot with a LiveUSB to finish this job with var 
unmounted.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]

Michael wrote:
> On Sunday, 11 May 2025 14:10:48 British Summer Time Dale wrote:
>
>> 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   <== That's the path
>>   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 / #
> Hmm ... the fine manual of resize2fs command states upfront:
>
> "The  resize2fs program will resize ext2, ext3, or ext4 file systems.  It can 
> be used to enlarge or shrink an unmounted file system located on device.  If 
> the file system is mounted, it can be used to expand  the  size of  the  
> mounted  file  system,  assuming the kernel and the file system supports on-
> line resizing."
>
> So you should not need to unmount it - but I wonder if the LVM layer 
> introduces some complexity here.  :-/
>

Well, on this system, I've done this a few times without any problems. 
Just add some space with lvextend, resize file system and done.  It
doesn't seem to be working today tho.  Yesterday either.  LOL 


>> 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???? 
> Since /var/ is in use by the OS and you keep getting warnings about it being 
> busy, I think you'll have to reboot with a LiveUSB to finish this job with var 
> unmounted.

Well crap.  I checked once ages ago to see if I could do anything with
LVM and the commands did list things.  I guess LVM works on those but I
can't recall what I was booting.  Given it was a while ago, likely
systemrescue thingy.  That doesn't use Gentoo anymore so not sure on if
that would work or not.  I may have a old copy around here somewhere. 
Could put it on that Ventoy thingy.  See if that works. 

I was hoping to avoid that.  :/  I thought maybe I was missing something
or something changed that I couldn't find, yet. 

Thanks for the help.  We tried. 

Dale

:-)  :-) 

P. S.  I have some 500GB drives in a box somewhere.  Could move the OS
over to that and have even more room.  I could do like I did on my new
rig, make everything big enough that I'd need to worry about the rig
blowing smoke before running out of room.  ROFL

[-- Attachment #2: Type: text/html, Size: 4003 bytes --]

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]

On Sunday, 11 May 2025 15:39:22 British Summer Time Dale wrote:
> Michael wrote:
> > On Sunday, 11 May 2025 14:10:48 British Summer Time Dale wrote:
> >> 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   <== That's the
> >>   path
> >>   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 / #
> > 
> > Hmm ... the fine manual of resize2fs command states upfront:
> > 
> > "The  resize2fs program will resize ext2, ext3, or ext4 file systems.  It
> > can be used to enlarge or shrink an unmounted file system located on
> > device.  If the file system is mounted, it can be used to expand  the 
> > size of  the mounted  file  system,  assuming the kernel and the file
> > system supports on- line resizing."
> > 
> > So you should not need to unmount it - but I wonder if the LVM layer
> > introduces some complexity here.  :-/
> 
> Well, on this system, I've done this a few times without any problems. 
> Just add some space with lvextend, resize file system and done.  It
> doesn't seem to be working today tho.  Yesterday either.  LOL 
> 
> >> 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????
> > 
> > Since /var/ is in use by the OS and you keep getting warnings about it
> > being busy, I think you'll have to reboot with a LiveUSB to finish this
> > job with var unmounted.
> 
> Well crap.  I checked once ages ago to see if I could do anything with
> LVM and the commands did list things.  I guess LVM works on those but I
> can't recall what I was booting.  Given it was a while ago, likely
> systemrescue thingy.  That doesn't use Gentoo anymore so not sure on if
> that would work or not.  I may have a old copy around here somewhere. 
> Could put it on that Ventoy thingy.  See if that works. 
> 
> I was hoping to avoid that.  :/  I thought maybe I was missing something
> or something changed that I couldn't find, yet. 
> 
> Thanks for the help.  We tried. 
> 
> Dale
> 
> :-)  :-) 
> 
> P. S.  I have some 500GB drives in a box somewhere.  Could move the OS
> over to that and have even more room.  I could do like I did on my new
> rig, make everything big enough that I'd need to worry about the rig
> blowing smoke before running out of room.  ROFL

I'm not the best person to advise on LVM, I just shared what I know, but I 
haven't used LVM in anger for a few years now.  Hopefully someone with more 
hands on experience will chime in.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

Michael wrote:
>
> I'm not the best person to advise on LVM, I just shared what I know, but I 
> haven't used LVM in anger for a few years now.  Hopefully someone with more 
> hands on experience will chime in.


Since the lv command worked, I don't think this is a LVM problem.  That
part of the growth is there.  It seems to be resize2fs that has the
problem.  I just wonder, if I could do a file system check, would it
work then?  Thing is, it to wants it unmounted.  It makes me wonder if
there is something that needs to be fixed, even if it is minor and not a
actual data problem, but it isn't just saying the file system needs to
be fixed first.  When I did my searches, most people had a part in the
output about a bad super block or that a super block wasn't found.  Mine
doesn't have that tho.  I'm not sure what difference that makes. 

I'll try to boot some media and do it I guess.  Just not today. 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 1560 bytes --]

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

On Sunday, 11 May 2025 16:10:43 British Summer Time Dale wrote:
> Michael wrote:
> > I'm not the best person to advise on LVM, I just shared what I know, but I
> > haven't used LVM in anger for a few years now.  Hopefully someone with
> > more
> > hands on experience will chime in.
> 
> Since the lv command worked, I don't think this is a LVM problem.  That
> part of the growth is there.  It seems to be resize2fs that has the
> problem.  I just wonder, if I could do a file system check, would it
> work then?  Thing is, it to wants it unmounted.  It makes me wonder if
> there is something that needs to be fixed, even if it is minor and not a
> actual data problem, but it isn't just saying the file system needs to
> be fixed first.  When I did my searches, most people had a part in the
> output about a bad super block or that a super block wasn't found.  Mine
> doesn't have that tho.  I'm not sure what difference that makes. 
> 
> I'll try to boot some media and do it I guess.  Just not today. 
> 
> Dale
> 
> :-)  :-) 

Last thing to mention just in case it applies this your case.

You know you may be able to extend a LV and resize the underlying fs in one 
go?  The command 'lvextend --resizefs -L +5G /dev/VG/LV' should do this in one 
go (according to the man page it will use fsadm to resize the fs).



[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1558 bytes --]

Michael wrote:
> On Sunday, 11 May 2025 16:10:43 British Summer Time Dale wrote:
>> Michael wrote:
>>> I'm not the best person to advise on LVM, I just shared what I know, but I
>>> haven't used LVM in anger for a few years now.  Hopefully someone with
>>> more
>>> hands on experience will chime in.
>> Since the lv command worked, I don't think this is a LVM problem.  That
>> part of the growth is there.  It seems to be resize2fs that has the
>> problem.  I just wonder, if I could do a file system check, would it
>> work then?  Thing is, it to wants it unmounted.  It makes me wonder if
>> there is something that needs to be fixed, even if it is minor and not a
>> actual data problem, but it isn't just saying the file system needs to
>> be fixed first.  When I did my searches, most people had a part in the
>> output about a bad super block or that a super block wasn't found.  Mine
>> doesn't have that tho.  I'm not sure what difference that makes. 
>>
>> I'll try to boot some media and do it I guess.  Just not today. 
>>
>> Dale
>>
>> :-)  :-) 
> Last thing to mention just in case it applies this your case.
>
> You know you may be able to extend a LV and resize the underlying fs in one 
> go?  The command 'lvextend --resizefs -L +5G /dev/VG/LV' should do this in one 
> go (according to the man page it will use fsadm to resize the fs).
>
>


I saw that after I used lvextend without the option.  The short version
is -r.  I wish I had seen it first and tried it.  Maybe it would have
worked.  Doubtful but maybe. 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 2552 bytes --]

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Jay Faulkner]

Hey Dale, couple of comments:

- LVM should not impact the resizing of the FS at all. I'm assuming the 
68GB you see for /dev/OS/var is the new size in the lvscan output? If 
so, you should be ready to resize. If not, your LVM is not quite ready yet.

- Are you sure you're using ext2/3/4 as the FS? Use lsblk to check. If 
yes, another thing to try might be remounting the fs as read only during 
the action: `mount -oremount,rw /var`

Good luck,

Jay

On 5/11/2025 7:39 AM, Dale wrote:
> open: Device or resource busy while opening /dev/OS/var

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Am Sun, May 11, 2025 at 02:21:07PM +0100 schrieb Michael:

> Hmm ... the fine manual of resize2fs command states upfront:
> 
> "The  resize2fs program will resize ext2, ext3, or ext4 file systems.  It can 
> be used to enlarge or shrink an unmounted file system located on device.  If 
> the file system is mounted, it can be used to expand  the  size of  the  
> mounted  file  system,  assuming the kernel and the file system supports on-
> line resizing."
>
> So you should not need to unmount it - but I wonder if the LVM layer 
> introduces some complexity here.  :-/

On the contrary. There is actually an LVM command to expand a lv and its FS 
in one swoop.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

Lettered up the mixes?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

Am Sun, May 11, 2025 at 09:39:22AM -0500 schrieb Dale:

> >> Am I going to have to boot other media and resize this thing???? 
> > Since /var/ is in use by the OS and you keep getting warnings about it being 
> > busy, I think you'll have to reboot with a LiveUSB to finish this job with var 
> > unmounted.
> 
> Well crap.  I checked once ages ago to see if I could do anything with
> LVM and the commands did list things.  I guess LVM works on those but I
> can't recall what I was booting.  Given it was a while ago, likely
> systemrescue thingy.  That doesn't use Gentoo anymore so not sure on if
> that would work or not. 

Why shouldn’t it? Even if it is Arch and not Gentoo, it uses the same LVM 
software as Gentoo does. Maybe a slightly different version, but not too 
different to cause compat issues.

> I may have a old copy around here somewhere. 
> Could put it on that Ventoy thingy.  See if that works. 

I thought you had an extralarge /boot partition to keep a live ISO around at 
all times. :o)

> I was hoping to avoid that.  :/  I thought maybe I was missing something
> or something changed that I couldn't find, yet. 

I recently embiggened the root partition on one of my machines and it worked 
like you said. Add extents, auto-extend the FS, done:

thinkpad / # resize2fs /dev/mapper/tp-home
resize2fs 1.47.2 (1-Jan-2025)
The filesystem is already 26214400 (4k) blocks long.  Nothing to do!


Can you reduce your running system’s footprint? As in log out of KDE and go 
to a tty. Maybe something causes a lock.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

“First off, I’d suggest printing out a copy of the GNU coding standards,
and NOT read it.  Burn them, it’s a great symbolic gesture.”
– Linus Torvalds, Linux kernel coding style documentation

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] LVM and making /var larger, file system won't resize.

[Dale]

Frank Steinmetzger wrote:
> Am Sun, May 11, 2025 at 09:39:22AM -0500 schrieb Dale:
>
>>>> Am I going to have to boot other media and resize this thing???? 
>>> Since /var/ is in use by the OS and you keep getting warnings about it being 
>>> busy, I think you'll have to reboot with a LiveUSB to finish this job with var 
>>> unmounted.
>> Well crap.  I checked once ages ago to see if I could do anything with
>> LVM and the commands did list things.  I guess LVM works on those but I
>> can't recall what I was booting.  Given it was a while ago, likely
>> systemrescue thingy.  That doesn't use Gentoo anymore so not sure on if
>> that would work or not. 
> Why shouldn’t it? Even if it is Arch and not Gentoo, it uses the same LVM 
> software as Gentoo does. Maybe a slightly different version, but not too 
> different to cause compat issues.

Well, I just liked it better when it was Gentoo too.  That way I know
everything is compatible. 


>> I may have a old copy around here somewhere. 
>> Could put it on that Ventoy thingy.  See if that works. 
> I thought you had an extralarge /boot partition to keep a live ISO around at 
> all times. :o)

I do on my main rig.  This is on my old rig tho.  It has a lot smaller
hard drive for the OS.  I have three rigs I use for things.  It can get
confusing, even for me.  Newest rig is Gentoo-1, old rig is Fireball and
other rig is NAS. 


>> I was hoping to avoid that.  :/  I thought maybe I was missing something
>> or something changed that I couldn't find, yet. 
> I recently embiggened the root partition on one of my machines and it worked 
> like you said. Add extents, auto-extend the FS, done:
>
> thinkpad / # resize2fs /dev/mapper/tp-home
> resize2fs 1.47.2 (1-Jan-2025)
> The filesystem is already 26214400 (4k) blocks long.  Nothing to do!
>
>
> Can you reduce your running system’s footprint? As in log out of KDE and go 
> to a tty. Maybe something causes a lock.
>


I still think there is something strange about this.  I've done this
before on that very rig and that very mount point.  I've done it on /usr
as well.  It just worked.  Anyway, it's on my todo list.  Right now, I
got a 8TB SMR type drive that I'm testing and I'm waiting on UPS to
deliver another 16TB spare drive, that was supposed to be here last
week.  Part of me wouldn't mind that SMR driving dying.  I use it but I
don't like it.  Didn't know it was a SMR until I had it for months.  I
kept feeling it bumping even when my data was transferred.  Rich
explained to me what a SMR drive was.  I had no idea. 

Dale

:-)  :-)