Frank Miles wrote:
> I recently added a new hard drive to my home system. I decided to use it
> to create an all-new bootable 'jessie' system. I created a partition
> table that I thought would be flexible:
> /dev/sdb1 / (root) {7G}
> /dev/sdb2 /swap {4GB}
> /dev/sdb3 /oldjunk {1G}
> /dev/sdb4 extended {remainder}
> /dev/sdb5 LVM {one large volume}
Why didn't you put / on LVM? Because you put your /boot there?
I know this is too late for you but I recommend putting /boot on the
first partition. Just /boot and nothing else. Getting the initrd and
the kernel loaded I still think is less trouble when they exist on a
simple filesystem and outside of lvm. Then use the rest of
the disk as physical volumes for lvm. For you I might suggest:
/dev/sdb1 /boot {256M}
/dev/sdb4 extended {remainder}
/dev/sdb5 LVM PV {one large volume}
But that is water under the bridge now. But consider that for next
time.
> Most of the partitions- /usr, /home, /var, ... were in LVM2.
>
> What I've learned since then is that /usr seems to have special
> status, and probably shouldn't be part of LVM as certain tasks
> early in the boot process can't seem to access the interior of
> LVM.
My /usr is always on lvm and I have not experienced any trouble.
Having /usr on lvm is okay.
You may have been hearing that a separate /usr partition is now
deprecated due to entanglements at early boot time. It is no longer
recommended to have /usr separate from / due to the lack of
bootstraping anymore. (Grr...) But that is a completely different
issue from having it on lvm.
> I've moved 'oldjunk' into the LVM, and want to expand this
> partition to become the new /usr. I've shrunk the LVM, but
> the freed space is all at the far end of the LVM. I have
> been unable to move it towards the end of the disk space,
> so I can expand /dev/sdb3. gparted, resize2fs, pvmove,...
> (running from a CDROM-based rescue disk) have all failed.
>
> Is there some method that I've overlooked?
Yes. Simply add those partitions as additional PVs to the VG volume
group. If you have freed up their data then increase the size of your
volume group by using them as physical volumes. Then with more space
in your volume group you can allocate the space to your logical
volumes. There is no need to move the start of sdb5 PV down.
pvcreate /dev/sdb3
vgextend vg1 /dev/sdb3
Assuming your volume group name is vg1. Change that as appropriate.
(I always choose short names so that 'df' output is conveniently on one
line. Long names force it to break onto two lines.)
I always put swap on lvm too so that I can change the size of it
later. You could still do this if you wanted. For example with:
swapoff /dev/sdb2
pvcreate /dev/sdb2
vgextend vg1 /dev/sdb2
lvcreate -L4G -nswap vg1
mkswap /dev/vg1/swap
swapon /dev/vg1/swap
It is unfortunate that you chose a fixed size for /. If it were me
inheriting this system I would boot the debian-installer in rescue
mode and then create a new root partition as an LV in LVM and copy
everything from the old root to the new LVM LV root. Then free up all
three of sdb1, sdb2, sdb3 and create two new partitions. First I
would create a new /boot as a 256M primary partition. I would create
it as an ext2 file system. (No need for wasting space in a journal
there and fsck is lightning fast already on a 256M ext2 file system.)
Then create an sdb2 partition to hold all of the free space between
sdb1 and the existing data in sdb5. Then "pvcreate /dev/sdb2" and
"vgextend vg1 /dev/sdb2" to include it in the VG. Then 'grub-install'
and 'update-grub' to install the boot loader although exactly how
depends upon your how your sda disk is set up. Then boot to the new
system with / on LVM. If there is any problem repeat booting into
rescue mode and make corrections as needed.
You can extend ext file systems on the fly. (Where vg1 is the name of
your volume group and lv1 is the name of your logical volume.)
lvextend -L+25G /dev/vg1/lv1
resize2fs /dev/vg1/lv1
For me a real example with real names on a real system might be:
lvextend -L+25G /dev/h9/home
resize2fs /dev/h9/home
Then like magic the /home partition is now 25G larger than before all
online while the system is running.
I always keep some space reserved as free space in the vg just for
being able to expand where I need to expand. File systems can easily
be expanded but cannot easily be shrunk. Therefore I try to avoid
making huge file systems with a lot of wasted space and instead to
grow them where they are actually needed. If they are made too big
then they are too big forever and you can't move the space elsewhere.
At least not easily.
These are all just ideas. Something to think about for the future.
Bob
Attachment:
signature.asc
Description: Digital signature