Re: Resizing LVM partitions
On 1/24/24 11:27 PM, Greg Wooledge wrote: On Wed, Jan 24, 2024 at 10:43:51PM +0100, Miroslav Skoric wrote: I do not have root account. Sure you do. You might not have a root *password* set. (I use sudo from my user account.) I think I already tried rescue mode in the past but was not prompted for root password. You can set a root password: sudo passwd root That should allow you to enter single-user mode, or to login directly as root on a text console, both of which are things that you may need to do as a system administrator. Especially if you're trying to unmount /home. Of course, sorry for my mixing terms. In fact I have never logged in directly as root so I thought the account was disabled or unusable. In any case, after setting a root password I did this: 1. Log-out as user (in GUI) 2. Ctrl-Alt-F2 3. Log-in as root (in CLI) 4. # lvreduce --size -50G --resizefs /dev/mapper/localhost-home Do you want to unmount "/home" ? [Y|n] y ... ... Size of logical volume localhost/home changed from 261.00 GiB (66816 extents) to 211.00 GiB (54016 extents). Logical volume localhost/home successfully resized. ... after reboot ... # df -h Filesystem Size Used Avail Use% Mounted on udev1.5G 0 1.5G 0% /dev tmpfs 297M 8.9M 288M 3% /run /dev/mapper/localhost-root 6.2G 4.7G 1.2G 81% / /dev/mapper/localhost-usr15G 11G 2.7G 80% /usr tmpfs 1.5G 0 1.5G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup /dev/sda1 228M 142M 74M 66% /boot /dev/mapper/localhost-home 208G 60G 138G 31% /home /dev/mapper/localhost-var 3.7G 2.0G 1.6G 57% /var /dev/mapper/localhost-tmp 2.3G 57K 2.2G 1% /tmp tmpfs 297M 32K 297M 1% /run/user/1000 # vgdisplay --- Volume group --- VG Name localhost System ID Formatlvm2 Metadata Areas1 Metadata Sequence No 21 VG Access read/write VG Status resizable MAX LV0 Cur LV6 Open LV 6 Max PV0 Cur PV1 Act PV1 VG Size <297.85 GiB PE Size 4.00 MiB Total PE 76249 Alloc PE / Size 62346 / <243.54 GiB Free PE / Size 13903 / <54.31 GiB VG UUID fbCaw1-u3SN-2HCy-w6y8-v0nK-QsFE-FETNZM ... and then I extended /, /usr, and /var for 1GB each. Seems all ok. Thank you!
Re: Resizing LVM partitions
BTW, instead of rescue mode, you can use the initramfs to do such things (I like to do that when I don't have a LiveUSB at hand because it lets you manipulate *all* partitions, including /). I.e. do something like: - Reboot - In Grub, edit your boot script (with `e`) to add `break=mount` to the kernel command line. - Use `F10` to boot with that boot script. - You should very quickly be dropped into a fairly minimal shell, without any password. - None of your volumes are mounted yet. Even LVM isn't initialized yet. - Then type something like (guaranteed 100% untested) lvm vgchange -ay # Activate your LVM volumes. mount /dev/mapper/localhost-root /mnt # Mount / mount --bind /dev /mnt/dev chroot /mnt /bin/bash lvreduce --size -50G --resizefs /dev/mapper/localhost-home exit umount /mnt/dev umount /mnt exit --- Stefan
Re: Resizing LVM partitions
On Wed, Jan 24, 2024 at 10:43:51PM +0100, Miroslav Skoric wrote: > I do not have root account. Sure you do. You might not have a root *password* set. > (I use sudo from my user account.) I think I > already tried rescue mode in the past but was not prompted for root > password. You can set a root password: sudo passwd root That should allow you to enter single-user mode, or to login directly as root on a text console, both of which are things that you may need to do as a system administrator. Especially if you're trying to unmount /home.
On the deprecation of separate /usr (Was: Re: Resizing LVM partitions)
Hello, On Wed, Jan 24, 2024 at 09:20:47AM +0700, Max Nikulin wrote: > Notice that separate /usr is not supported by latest systemd that should be > a part of the next Debian release. I don't think this is the case. What I think is not supported is a separate /usr that is not mounted by initramfs. On Debian, if you do nothing special, any separate /usr will be mounted by initramfs. As far as I'm aware it is only a concern for: people who have a /usr mount point && ( (do not use an initramfs) || (have meddled with their initramfs to stop it from mounting /usr) ) What systemd has decided to no longer support is what they call "split /usr": https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html They define that as "/usr that is not populated at boot time". i.e. a /usr that would be mounted during boot from /etc/fstab or similar. If /usr is mounted by the initramfs, that is before userland boot, and systemd doesn't care about that. Debian does that where there is a separate mount point for /usr. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Resizing LVM partitions
On 1/24/24 3:20 AM, Max Nikulin wrote: On 24/01/2024 06:29, Miroslav Skoric wrote: # df -h /dev/mapper/localhost-root 6.2G 4.7G 1.2G 81% / Taking into account size of kernel packages, I would allocate a few G more for the root partition. dpkg -s linux-image-6.1.0-17-amd64 | grep -i size Installed-Size: 398452 Notice that separate /usr is not supported by latest systemd that should be a part of the next Debian release. Thank you. Will consider that.
Re: Resizing LVM partitions
On 1/24/24 12:42 AM, Greg Wooledge wrote: You'll have to unmount it, which generally means you will have to reboot in single-user mode, or from rescue media, whichever is easier. If you aren't opposed to setting a root password (some people have *weird* self-imposed restrictions, seriously), single-user mode (aka "rescue mode" from the GRUB menu) is the standard way to do this. Boot to the GRUB menu, select rescue mode, give the root password when prompted, then you should end up with a root shell prompt. I don't recall whether /home will be mounted at that point; if it is, unmount it. Then you should be able to do whatever resizing is needed. When done, exit from the shell, and the system should boot normally. I do not have root account. (I use sudo from my user account.) I think I already tried rescue mode in the past but was not prompted for root password.
Re: Resizing LVM partitions
Hi, On Wed, Jan 24, 2024 at 12:29:18AM +0100, Miroslav Skoric wrote: > Dunno ... in any case, for some reason the rescue mode I went to by booting > from an old installation CD (dated back to Debian 6.0.1A Squeeze!) did not > see partitions in form of e.g. /dev/mapper/localhost-home, but rather > /dev/localhost/home, so lvreduce rejected to proceed. Booting into an ancient userland like Debian 6 to do vital work on your storage stack is completely insane. Bear in mind the amount of changes and bug fixes that will have taken place in kernel, filesystem and LVM tools between Debian 6 and Debian 12. You are lucky we are not now having a very different kind of conversation. Always try to use a rescue/live environment that is close to, or newer than your actual system. Anything else risks catastrophe. > So I tried vgdisplay. It returned ... among the others ... > > ... > Total PE 76249 > Alloc PE / Size 74378 / 290.54 GiB > Free PE / Size 1871 / 7.31 GiB Summary: you managed to use some of that available space. > In any case, what is left to do is to find the best way to take some space > from /home which is largely underused. You should be able to do this bit without going into a live/rescue env. You won't be able to do it while any user is logged in, so shut down any desktop environment and log out of all users. Log back in as root from console and just do the lvreduce --resizefs from there. It should ask if you are willing to unmount /home. If there's anything left running from /home the unmount won't work and you'll have to track down those stray processes, but should be easily doable. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Resizing LVM partitions
On Wed, Jan 24, 2024 at 06:45:12AM +0100, to...@tuxteam.de wrote: > On Tue, Jan 23, 2024 at 06:42:43PM -0500, Greg Wooledge wrote: > > You'll have to unmount it, which generally means you will have to reboot > > in single-user mode, or from rescue media, whichever is easier. > > If you log in as root in a Linux console before the graphical > thing gets started, you might get a stab at it, too. No reason > for /home to be in use if no user has a session running Depends on the system. If you've got user crontabs that run @reboot (or their systemd equivalents, if such a thing exists), those might try to use files in $HOME. If you're running a mail transfer agent that receives email, it might attempt deliveries, which would involve looking for ~/.forward or similar files, and deliveries could be done to the home directory (but not by default on Debian). But yeah, for *most* users, what you said is probably accurate.
Re: Resizing LVM partitions
On Tue, Jan 23, 2024 at 06:42:43PM -0500, Greg Wooledge wrote: > On Wed, Jan 24, 2024 at 12:29:18AM +0100, Miroslav Skoric wrote: > > Total PE 76249 > > Alloc PE / Size 75146 / <293.54 GiB > > Free PE / Size 1103 / <4.31 GiB > > VG UUID fbCaw1-u3SN-2HCy-w6y8-v0nK-QsFE-FETNZM > > > > ... seems that I still have some 4 GB of unallocated space to add somewhere > > if/when needed. > > Yes. Everything looks fine. > > > In any case, what is left to do is to find the best way to take some space > > from /home which is largely underused. > > You'll have to unmount it, which generally means you will have to reboot > in single-user mode, or from rescue media, whichever is easier. If you log in as root in a Linux console before the graphical thing gets started, you might get a stab at it, too. No reason for /home to be in use if no user has a session running (I can only vouch for a pretty minimal graphical system with no DE, but it might work for the newfangled things, too). Cheers -- t signature.asc Description: PGP signature
Re: Resizing LVM partitions
On 24/01/2024 06:29, Miroslav Skoric wrote: # df -h /dev/mapper/localhost-root 6.2G 4.7G 1.2G 81% / Taking into account size of kernel packages, I would allocate a few G more for the root partition. dpkg -s linux-image-6.1.0-17-amd64 | grep -i size Installed-Size: 398452 Notice that separate /usr is not supported by latest systemd that should be a part of the next Debian release.
Re: Resizing LVM partitions
On Wed, Jan 24, 2024 at 12:29:18AM +0100, Miroslav Skoric wrote: > Total PE 76249 > Alloc PE / Size 75146 / <293.54 GiB > Free PE / Size 1103 / <4.31 GiB > VG UUID fbCaw1-u3SN-2HCy-w6y8-v0nK-QsFE-FETNZM > > ... seems that I still have some 4 GB of unallocated space to add somewhere > if/when needed. Yes. Everything looks fine. > In any case, what is left to do is to find the best way to take some space > from /home which is largely underused. You'll have to unmount it, which generally means you will have to reboot in single-user mode, or from rescue media, whichever is easier. If you aren't opposed to setting a root password (some people have *weird* self-imposed restrictions, seriously), single-user mode (aka "rescue mode" from the GRUB menu) is the standard way to do this. Boot to the GRUB menu, select rescue mode, give the root password when prompted, then you should end up with a root shell prompt. I don't recall whether /home will be mounted at that point; if it is, unmount it. Then you should be able to do whatever resizing is needed. When done, exit from the shell, and the system should boot normally.
Re: Resizing LVM partitions
On 1/23/24 7:36 AM, Andy Smith wrote: ext filesystems do need to be unmounted when shrinking them (they can grow online, though). When you use the --resizefs (-r) option, LVM asks you if you wish to unmount. Obviously you cannot do that on a fiulesystme which is in use, which means you'll need a live or rescue environment to do it for the root filesystem. I'd shrink what else I could and then see where I am at. It's okay to do them one at a time. LVM will just not do it if there's a problem. Another thing I sometimes do in these situations is make a new LV and move some of the things in / out into it where possible, to free up some more space on /. Dunno ... in any case, for some reason the rescue mode I went to by booting from an old installation CD (dated back to Debian 6.0.1A Squeeze!) did not see partitions in form of e.g. /dev/mapper/localhost-home, but rather /dev/localhost/home, so lvreduce rejected to proceed. So I tried vgdisplay. It returned ... among the others ... ... Total PE 76249 Alloc PE / Size 74378 / 290.54 GiB Free PE / Size 1871 / 7.31 GiB ... so I considered that 7.31 GB could be used for extending /, /usr, and /var file systems. I rebooted machine into normal operation and did the following: # vgdisplay --- Volume group --- VG Name localhost System ID Formatlvm2 Metadata Areas1 Metadata Sequence No 17 VG Access read/write VG Status resizable MAX LV0 Cur LV6 Open LV 6 Max PV0 Cur PV1 Act PV1 VG Size <297.85 GiB PE Size 4.00 MiB Total PE 76249 Alloc PE / Size 74378 / <290.54 GiB Free PE / Size 1871 / <7.31 GiB VG UUID fbCaw1-u3SN-2HCy-w6y8-v0nK-QsFE-FETNZM # df -h Filesystem Size Used Avail Use% Mounted on udev1.5G 0 1.5G 0% /dev tmpfs 297M 8.8M 288M 3% /run /dev/mapper/localhost-root 5.2G 4.7G 211M 96% / /dev/mapper/localhost-usr14G 12G 948M 93% /usr tmpfs 1.5G 0 1.5G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup /dev/sda1 228M 133M 84M 62% /boot /dev/mapper/localhost-tmp 2.3G 55K 2.2G 1% /tmp /dev/mapper/localhost-var 2.7G 1.9G 659M 75% /var /dev/mapper/localhost-home 257G 63G 182G 26% /home tmpfs 297M 32K 297M 1% /run/user/1000 # lvextend --size +1G --resizefs /dev/mapper/localhost-root Size of logical volume localhost/root changed from 5.32 GiB (1363 extents) to 6.32 GiB (1619 extents). Logical volume localhost/root successfully resized. resize2fs 1.44.5 (15-Dec-2018) Filesystem at /dev/mapper/localhost-root is mounted on /; on-line resizing required old_desc_blocks = 22, new_desc_blocks = 26 The filesystem on /dev/mapper/localhost-root is now 6631424 (1k) blocks long. # df -h (to check the new status) Filesystem Size Used Avail Use% Mounted on udev1.5G 0 1.5G 0% /dev tmpfs 297M 8.8M 288M 3% /run /dev/mapper/localhost-root 6.2G 4.7G 1.2G 81% / /dev/mapper/localhost-usr14G 12G 948M 93% /usr tmpfs 1.5G 0 1.5G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup /dev/sda1 228M 133M 84M 62% /boot /dev/mapper/localhost-tmp 2.3G 55K 2.2G 1% /tmp /dev/mapper/localhost-var 2.7G 1.9G 659M 75% /var /dev/mapper/localhost-home 257G 63G 182G 26% /home tmpfs 297M 32K 297M 1% /run/user/1000 # lvextend --size +1G --resizefs /dev/mapper/localhost-usr Size of logical volume localhost/usr changed from <13.38 GiB (3425 extents) to <14.38 GiB (3681 extents). Logical volume localhost/usr successfully resized. resize2fs 1.44.5 (15-Dec-2018) Filesystem at /dev/mapper/localhost-usr is mounted on /usr; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 The filesystem on /dev/mapper/localhost-usr is now 3769344 (4k) blocks long. # df -h Filesystem Size Used Avail Use% Mounted on udev1.5G 0 1.5G 0% /dev tmpfs 297M 8.8M 288M 3% /run /dev/mapper/localhost-root 6.2G 4.7G 1.2G 81% / /dev/mapper/localhost-usr15G 12G 1.9G 86% /usr tmpfs 1.5G 0 1.5G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup /dev/sda1 228M 133M 84M 62% /boot /dev/mapper/localhost-tmp 2.3G 55K 2.2G 1% /tmp /dev/mapper/localhost-var
Re: Resizing LVM partitions
On 1/22/24 11:21 PM, Greg Wooledge wrote: On Mon, Jan 22, 2024 at 10:41:57PM +0100, Miroslav Skoric wrote: As I need to extend & resize more than one LV in the file system (/, /usr, and /var), should they all need to be unmounted before the operation? As I remember, it is ext3 system on that comp. What?? I don't think these words mean what you think they mean. An LV is a logical volume, which is like a virtual partition. It's a block device, like /dev/sda2. You can use an LV the same way you would use a partition -- you can use it for swap space, or a file system, or other purposes. A file system is a mountable directory structure that you can put inside a partition, or an LV. File system types include ext4, ext3, xfs, vfat, and so on. Sorry for my ignorance regarding terminology, I mix terms sometimes :-) If your system has separately mounted file systems for /, /usr and /var and you want to shrink ALL of them, then yes, you would need to unmount all three of them, shrink them, then (re)boot. You can't unmount / during normal operations, so the only ways to shrink / would involved booting in a special way, either with some external medium, or with specific kernel parameters. Thus, you'd typically reboot to get back to normal operations afterward. Let me clarify: I did not plan to shrink all of those, but rather just one (/home). The other three (/, /usr, and /var) shall be extended from the released space. I managed to locate the first CD of my very old initial installation set (squeeze). However, booting from that one did not help me to get /home available for shrinking. See later what I did instead. However, if you're in a position where you think you need to make dramatic changes to FOUR of your mounted file systems, perhaps you might want to consider restarting from scratch. Ponder why you have separate file systems at all. Are they really giving you a benefit? Have you ever filled up one of them and thought "Oh wow, I am *so* glad I separated these file systems so I didn't fill up ___ as well!" Or are they just giving you grief with no benefits? Well I belong to those who are going to exercise any possible way to prolong the life of an existing installation, no matter how old it is. In my case it started from squeeze a decade or more ago and gradually upgraded during the years. And I knew that some years ago I resized the file system because of similar reasons, and that worked at the time. But the procedure disappeared from memory :-) Reinstalling from scratch is always possible, of course.
Re: Resizing LVM partitions
On 1/22/24 7:01 PM, to...@tuxteam.de wrote: Ah, forgot to say: "pvdisplay -m" will give you a "physical" map of your physical volume. So you get an idea what is where and where you find gaps. "pvdisplay -m" provided some idea that there was some free space but (if I am not wrong) not how much in MB, GB, or else. I found gvdisplay more precise in that direction.
Re: Resizing LVM partitions
On 1/22/24 5:02 PM, Greg Wooledge wrote: On Mon, Jan 22, 2024 at 03:17:36PM +, Alain D D Williams wrote: The shrinking of /home is the hard part. You MUST first unmount /home, then resize the file system, then resize the logical volume. Before doing any of that, one should check the volume group and see if there are unallocated hunks of free space that can simply be assigned to the root LV. vgdisplay ? It helped me for now, see my other responses to the topic ...
Re: Resizing LVM partitions
Hi, On Mon, Jan 22, 2024 at 10:59:55PM +0100, Miroslav Skoric wrote: > On 1/22/24 6:59 PM, to...@tuxteam.de wrote: > > On Mon, Jan 22, 2024 at 03:40:06PM +, Alain D D Williams wrote: > > > On Mon, Jan 22, 2024 at 10:29:55AM -0500, Stefan Monnier wrote: > > > > lvreduce --size -50G --resizefs /dev/mapper/localhost-home > > > > > > Oh, even better. It is a long time since I looked at than man page. > > > > > > Does this still need to be done with the file system unmounted or can it > > > be > > > done with an active file system these days ? > > > > You have first to shrink the file system (if it's ext4, you can use > > resize2fs: note that you can only *grow* an ext4 which is mounted > > (called "online resizing) -- to *shrink* it, it has to be unmounted. > > > > I will check it again but I think that file systems in that LVM are ext3. So > it requires all of them to be unmounted prior to resizing ? ext filesystems do need to be unmounted when shrinking them (they can grow online, though). When you use the --resizefs (-r) option, LVM asks you if you wish to unmount. Obviously you cannot do that on a fiulesystme which is in use, which means you'll need a live or rescue environment to do it for the root filesystem. I'd shrink what else I could and then see where I am at. It's okay to do them one at a time. LVM will just not do it if there's a problem. Another thing I sometimes do in these situations is make a new LV and move some of the things in / out into it where possible, to free up some more space on /. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Resizing LVM partitions
On Mon, Jan 22, 2024 at 10:59:55PM +0100, Miroslav Skoric wrote: [...] > That last resize2fs (without params) would not work here, or at least it > would not work for my three file systems that need to be extended: / , /usr > , and /var . Maybe to extend each of them separately like this: > > lvextend --size +1G --resizefs /dev/mapper/localhost-root > lvextend --size +1G --resizefs /dev/mapper/localhost-usr > lvextend --size +1G --resizefs /dev/mapper/localhost-var Ah, I didn't know of lvextend's --resizefs option. It seems lvreduce has same. Their man pages refer to fsadm for that which is short in details. Still, yes, you have to unmount ext2/ext3/ext4 to reduce their sizes (you can "grow" them while mounted). Lvadm has an option to do that for you, no idea whether lvextend or lvreduce can pass it to lvadm via the --resizefs option. Cheers -- t signature.asc Description: PGP signature
Re: Resizing LVM partitions
On Mon, Jan 22, 2024 at 10:41:57PM +0100, Miroslav Skoric wrote: > As I need to extend & resize more than one LV in the file system (/, /usr, > and /var), should they all need to be unmounted before the operation? As I > remember, it is ext3 system on that comp. What?? I don't think these words mean what you think they mean. An LV is a logical volume, which is like a virtual partition. It's a block device, like /dev/sda2. You can use an LV the same way you would use a partition -- you can use it for swap space, or a file system, or other purposes. A file system is a mountable directory structure that you can put inside a partition, or an LV. File system types include ext4, ext3, xfs, vfat, and so on. If your system has separately mounted file systems for /, /usr and /var and you want to shrink ALL of them, then yes, you would need to unmount all three of them, shrink them, then (re)boot. You can't unmount / during normal operations, so the only ways to shrink / would involved booting in a special way, either with some external medium, or with specific kernel parameters. Thus, you'd typically reboot to get back to normal operations afterward. However, if you're in a position where you think you need to make dramatic changes to FOUR of your mounted file systems, perhaps you might want to consider restarting from scratch. Ponder why you have separate file systems at all. Are they really giving you a benefit? Have you ever filled up one of them and thought "Oh wow, I am *so* glad I separated these file systems so I didn't fill up ___ as well!" Or are they just giving you grief with no benefits?
Re: Resizing LVM partitions
On 1/22/24 6:59 PM, to...@tuxteam.de wrote: On Mon, Jan 22, 2024 at 03:40:06PM +, Alain D D Williams wrote: On Mon, Jan 22, 2024 at 10:29:55AM -0500, Stefan Monnier wrote: lvextend --size +1G --resizefs /dev/mapper/localhost-home Ie get lvextend to do the maths & work it out for me. Those who are cleverer than me might be able to tell you how to get it right first time! lvreduce --size -50G --resizefs /dev/mapper/localhost-home Oh, even better. It is a long time since I looked at than man page. Does this still need to be done with the file system unmounted or can it be done with an active file system these days ? You have first to shrink the file system (if it's ext4, you can use resize2fs: note that you can only *grow* an ext4 which is mounted (called "online resizing) -- to *shrink* it, it has to be unmounted. I will check it again but I think that file systems in that LVM are ext3. So it requires all of them to be unmounted prior to resizing ? Since I wasn't quite sure whether ext2's Gs are the same as LVM's and didn't want to bother with whatever clippings each process takes, what I did in this situation was: - shrink (resize2fs) the file system to a size clearly below target - resize the LVM to my target size - resize2fs again without params, which lets it take whatever the partition offers That last resize2fs (without params) would not work here, or at least it would not work for my three file systems that need to be extended: / , /usr , and /var . Maybe to extend each of them separately like this: lvextend --size +1G --resizefs /dev/mapper/localhost-root lvextend --size +1G --resizefs /dev/mapper/localhost-usr lvextend --size +1G --resizefs /dev/mapper/localhost-var ?
Re: Resizing LVM partitions
On 1/22/24 4:40 PM, Alain D D Williams wrote: On Mon, Jan 22, 2024 at 10:29:55AM -0500, Stefan Monnier wrote: lvextend --size +1G --resizefs /dev/mapper/localhost-home Ie get lvextend to do the maths & work it out for me. Those who are cleverer than me might be able to tell you how to get it right first time! lvreduce --size -50G --resizefs /dev/mapper/localhost-home Oh, even better. It is a long time since I looked at than man page. Does this still need to be done with the file system unmounted or can it be done with an active file system these days ? As I need to extend & resize more than one LV in the file system (/, /usr, and /var), should they all need to be unmounted before the operation? As I remember, it is ext3 system on that comp.
Re: Resizing LVM partitions
On 1/22/24 4:17 PM, Alain D D Williams wrote: On Mon, Jan 22, 2024 at 03:32:30PM +0100, sko...@uns.ac.rs wrote: I am getting the following message at any boot: "The volume "Filesystem root" has only 221.1 MB disk space remaining." df -h says: Filesystem Size Used Avail Use% Mounted on udev1.5G 0 1.5G 0% /dev tmpfs 297M 9.0M 288M 4% /run /dev/mapper/localhost-root 5.2G 4.7G 211M 96% / /dev/mapper/localhost-usr14G 12G 948M 93% /usr tmpfs 1.5G 0 1.5G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup /dev/sda1 228M 133M 84M 62% /boot /dev/mapper/localhost-tmp 2.3G 57K 2.2G 1% /tmp /dev/mapper/localhost-var 2.7G 2.5G 55M 98% /var /dev/mapper/localhost-home 257G 73G 172G 30% /home tmpfs 297M 40K 297M 1% /run/user/1000 As my system has encrypted LVM, I suppose that I shall reduce some space used for /home, and then use it to extend /, /usr, and /var logical partitions. I think I did (or tried to do) something similar several years ago, but forgot the proper procedure. Any link for a good tutorial is welcomed. Thanks. The shrinking of /home is the hard part. You MUST first unmount /home, then resize the file system, then resize the logical volume. umount /home Find out how big it is: resize2fs /dev/mapper/localhost-home Change the filesystem size: resize2fs /dev/mapper/localhost-home NEW-SIZE Change the partition size: lvextend --size 200G /dev/mapper/localhost-home The hard bit is working out what NEW-SIZE should be and having it such that you use all of the partition but without making the file system size greater than the partition size - ie getting the last few megabytes right. What I do is make NEW-SIZE 2GB smaller than I want (assuming that it still fits), the size I give to lvextend 1GB smaller - so it all works, but there is wasted space & it is not quite big enough. I then do: lvextend --size +1G --resizefs /dev/mapper/localhost-home Ie get lvextend to do the maths & work it out for me. Those who are cleverer than me might be able to tell you how to get it right first time! mount /home Extending the others is easy and can be done when the system is running & active, something like: lvextend --size +1G --resizefs /dev/mapper/localhost-var Finally: ensure that you have a good backup of /home before you start. Sounds interesting. Thank you. Will see other opinions too.
Re: Resizing LVM partitions
On Mon, Jan 22, 2024 at 07:01:13PM +0100, to...@tuxteam.de wrote: > On Mon, Jan 22, 2024 at 11:02:06AM -0500, Greg Wooledge wrote: > > On Mon, Jan 22, 2024 at 03:17:36PM +, Alain D D Williams wrote: > > > The shrinking of /home is the hard part. You MUST first unmount /home, > > > then > > > resize the file system, then resize the logical volume. > > > > Before doing any of that, one should check the volume group and see > > if there are unallocated hunks of free space that can simply be assigned > > to the root LV. > > Ah, forgot to say: "pvdisplay -m" will give you a "physical" map of > your physical volume. So you get an idea what is where and where > you find gaps. A volume group (VG) may be comprised of one or more physical volumes (PV), and the free space would be counted at the VG level. So I'd suggest "vgdisplay" instead. This tells you how many "PE" (physical extents, aka hunks of space) are allocated, and how many are free.
Re: Resizing LVM partitions
On Mon, Jan 22, 2024 at 01:06:16PM -0500, Gremlin wrote: > I use to use LVM and RAID but I quit using that after finding out that > partition the drive and using gparted was way more easier If you allocate all the space during installation and don't leave any to make adjustments, or to make snapshots, then you're not getting any of the benefits of LVM. In this case, you're just doing static partitioning with extra complexity, and your conclusion would be correct. The key to LVM is to leave some space unallocated. Then you get *options*.
Re: Resizing LVM partitions
On 1/22/24 10:17, Alain D D Williams wrote: On Mon, Jan 22, 2024 at 03:32:30PM +0100, sko...@uns.ac.rs wrote: I am getting the following message at any boot: "The volume "Filesystem root" has only 221.1 MB disk space remaining." df -h says: Filesystem Size Used Avail Use% Mounted on udev1.5G 0 1.5G 0% /dev tmpfs 297M 9.0M 288M 4% /run /dev/mapper/localhost-root 5.2G 4.7G 211M 96% / /dev/mapper/localhost-usr14G 12G 948M 93% /usr tmpfs 1.5G 0 1.5G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup /dev/sda1 228M 133M 84M 62% /boot /dev/mapper/localhost-tmp 2.3G 57K 2.2G 1% /tmp /dev/mapper/localhost-var 2.7G 2.5G 55M 98% /var /dev/mapper/localhost-home 257G 73G 172G 30% /home tmpfs 297M 40K 297M 1% /run/user/1000 As my system has encrypted LVM, I suppose that I shall reduce some space used for /home, and then use it to extend /, /usr, and /var logical partitions. I think I did (or tried to do) something similar several years ago, but forgot the proper procedure. Any link for a good tutorial is welcomed. Thanks. The shrinking of /home is the hard part. You MUST first unmount /home, then resize the file system, then resize the logical volume. umount /home Find out how big it is: resize2fs /dev/mapper/localhost-home Change the filesystem size: resize2fs /dev/mapper/localhost-home NEW-SIZE Change the partition size: lvextend --size 200G /dev/mapper/localhost-home The hard bit is working out what NEW-SIZE should be and having it such that you use all of the partition but without making the file system size greater than the partition size - ie getting the last few megabytes right. What I do is make NEW-SIZE 2GB smaller than I want (assuming that it still fits), the size I give to lvextend 1GB smaller - so it all works, but there is wasted space & it is not quite big enough. I then do: lvextend --size +1G --resizefs /dev/mapper/localhost-home Ie get lvextend to do the maths & work it out for me. Those who are cleverer than me might be able to tell you how to get it right first time! mount /home Extending the others is easy and can be done when the system is running & active, something like: lvextend --size +1G --resizefs /dev/mapper/localhost-var Finally: ensure that you have a good backup of /home before you start. I use to use LVM and RAID but I quit using that after finding out that partition the drive and using gparted was way more easier
Re: Resizing LVM partitions
On Mon, Jan 22, 2024 at 11:02:06AM -0500, Greg Wooledge wrote: > On Mon, Jan 22, 2024 at 03:17:36PM +, Alain D D Williams wrote: > > The shrinking of /home is the hard part. You MUST first unmount /home, then > > resize the file system, then resize the logical volume. > > Before doing any of that, one should check the volume group and see > if there are unallocated hunks of free space that can simply be assigned > to the root LV. Ah, forgot to say: "pvdisplay -m" will give you a "physical" map of your physical volume. So you get an idea what is where and where you find gaps. Cheers -- t signature.asc Description: PGP signature
Re: Resizing LVM partitions
On Mon, Jan 22, 2024 at 03:40:06PM +, Alain D D Williams wrote: > On Mon, Jan 22, 2024 at 10:29:55AM -0500, Stefan Monnier wrote: > > > lvextend --size +1G --resizefs /dev/mapper/localhost-home > > > > > > Ie get lvextend to do the maths & work it out for me. > > > > > > Those who are cleverer than me might be able to tell you how to get it > > > right > > > first time! > > > > lvreduce --size -50G --resizefs /dev/mapper/localhost-home > > Oh, even better. It is a long time since I looked at than man page. > > Does this still need to be done with the file system unmounted or can it be > done with an active file system these days ? You have first to shrink the file system (if it's ext4, you can use resize2fs: note that you can only *grow* an ext4 which is mounted (called "online resizing) -- to *shrink* it, it has to be unmounted. Since I wasn't quite sure whether ext2's Gs are the same as LVM's and didn't want to bother with whatever clippings each process takes, what I did in this situation was: - shrink (resize2fs) the file system to a size clearly below target - resize the LVM to my target size - resize2fs again without params, which lets it take whatever the partition offers Sounds complicated, but is not :-) You can shrink the partition to be smaller than the file system, but then you'll thrash it sooner or later, when two file sysems start quibbling over blocks on the fence like angry neighbours :) Cheers -- t signature.asc Description: PGP signature
Re: Resizing LVM partitions
On Mon, Jan 22, 2024 at 03:17:36PM +, Alain D D Williams wrote: > The shrinking of /home is the hard part. You MUST first unmount /home, then > resize the file system, then resize the logical volume. Before doing any of that, one should check the volume group and see if there are unallocated hunks of free space that can simply be assigned to the root LV. One of the fundamental *reasons* to use LVM is to leave a bunch of space unallocated, and assign it to whatever needs it later, once the storage needs become known. Leaving some unallocated space also allows the use of snapshots, which are nice when doing backups. I heard someone say, once, that the Debian installer will assign all of the space in a VG during installation, if you follow its "guided" path. This is a tragedy, if it's still true.
Re: Resizing LVM partitions
On Mon, Jan 22, 2024 at 10:29:55AM -0500, Stefan Monnier wrote: > > lvextend --size +1G --resizefs /dev/mapper/localhost-home > > > > Ie get lvextend to do the maths & work it out for me. > > > > Those who are cleverer than me might be able to tell you how to get it right > > first time! > > lvreduce --size -50G --resizefs /dev/mapper/localhost-home Oh, even better. It is a long time since I looked at than man page. Does this still need to be done with the file system unmounted or can it be done with an active file system these days ? -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include
Re: Resizing LVM partitions
> lvextend --size +1G --resizefs /dev/mapper/localhost-home > > Ie get lvextend to do the maths & work it out for me. > > Those who are cleverer than me might be able to tell you how to get it right > first time! lvreduce --size -50G --resizefs /dev/mapper/localhost-home ? Stefan
Re: Resizing LVM partitions
On Mon, Jan 22, 2024 at 03:32:30PM +0100, sko...@uns.ac.rs wrote: > I am getting the following message at any boot: > > "The volume "Filesystem root" has only 221.1 MB disk space remaining." > > df -h says: > > Filesystem Size Used Avail Use% Mounted on > udev1.5G 0 1.5G 0% /dev > tmpfs 297M 9.0M 288M 4% /run > /dev/mapper/localhost-root 5.2G 4.7G 211M 96% / > /dev/mapper/localhost-usr14G 12G 948M 93% /usr > tmpfs 1.5G 0 1.5G 0% /dev/shm > tmpfs 5.0M 4.0K 5.0M 1% /run/lock > tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup > /dev/sda1 228M 133M 84M 62% /boot > /dev/mapper/localhost-tmp 2.3G 57K 2.2G 1% /tmp > /dev/mapper/localhost-var 2.7G 2.5G 55M 98% /var > /dev/mapper/localhost-home 257G 73G 172G 30% /home > tmpfs 297M 40K 297M 1% /run/user/1000 > > As my system has encrypted LVM, I suppose that I shall reduce some space > used for /home, and then use it to extend /, /usr, and /var logical > partitions. I think I did (or tried to do) something similar several years > ago, but forgot the proper procedure. Any link for a good tutorial is > welcomed. Thanks. The shrinking of /home is the hard part. You MUST first unmount /home, then resize the file system, then resize the logical volume. umount /home Find out how big it is: resize2fs /dev/mapper/localhost-home Change the filesystem size: resize2fs /dev/mapper/localhost-home NEW-SIZE Change the partition size: lvextend --size 200G /dev/mapper/localhost-home The hard bit is working out what NEW-SIZE should be and having it such that you use all of the partition but without making the file system size greater than the partition size - ie getting the last few megabytes right. What I do is make NEW-SIZE 2GB smaller than I want (assuming that it still fits), the size I give to lvextend 1GB smaller - so it all works, but there is wasted space & it is not quite big enough. I then do: lvextend --size +1G --resizefs /dev/mapper/localhost-home Ie get lvextend to do the maths & work it out for me. Those who are cleverer than me might be able to tell you how to get it right first time! mount /home Extending the others is easy and can be done when the system is running & active, something like: lvextend --size +1G --resizefs /dev/mapper/localhost-var Finally: ensure that you have a good backup of /home before you start. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include
Resizing LVM partitions
I am getting the following message at any boot: "The volume "Filesystem root" has only 221.1 MB disk space remaining." df -h says: Filesystem Size Used Avail Use% Mounted on udev1.5G 0 1.5G 0% /dev tmpfs 297M 9.0M 288M 4% /run /dev/mapper/localhost-root 5.2G 4.7G 211M 96% / /dev/mapper/localhost-usr14G 12G 948M 93% /usr tmpfs 1.5G 0 1.5G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup /dev/sda1 228M 133M 84M 62% /boot /dev/mapper/localhost-tmp 2.3G 57K 2.2G 1% /tmp /dev/mapper/localhost-var 2.7G 2.5G 55M 98% /var /dev/mapper/localhost-home 257G 73G 172G 30% /home tmpfs 297M 40K 297M 1% /run/user/1000 As my system has encrypted LVM, I suppose that I shall reduce some space used for /home, and then use it to extend /, /usr, and /var logical partitions. I think I did (or tried to do) something similar several years ago, but forgot the proper procedure. Any link for a good tutorial is welcomed. Thanks. Misko
