Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #190497 > unrolled thread

How to relocate LVM pv to make room for grub install

Back to article view | Back to linux.debian.user

Contents

  How to relocate LVM pv to make room for grub install Tom Dial <tddial@comcast.net> - 2018-01-01 07:10 +0100
    Re: How to relocate LVM pv to make room for grub install Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-01 10:50 +0100
      Re: How to relocate LVM pv to make room for grub install Tom Dial <tddial@comcast.net> - 2018-01-02 01:20 +0100
        Re: How to relocate LVM pv to make room for grub install Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-02 19:20 +0100
          Re: How to relocate LVM pv to make room for grub install Tom Dial <tddial@comcast.net> - 2018-01-03 09:30 +0100
            Re: How to relocate LVM pv to make room for grub install Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-03 20:40 +0100

#190497 — How to relocate LVM pv to make room for grub install

Upgrading a workstation from Jessie to Stretch I found that the original
disk partitioning left insufficient space for grub (re)install. The
system has two identical ~233 GiB disks, sda and sdb, partitioned
identically:

Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00015e37

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1  *           63 122077934 122077872 58.2G 8e Linux LVM
/dev/sda2       122077935 244155869 122077935 58.2G 8e Linux LVM
/dev/sda3       244155870 366233804 122077935 58.2G 8e Linux LVM
/dev/sda4       366233805 488392064 122158260 58.3G 8e Linux LVM

sda1 and sdb2 form a volume group with active LVs containing OS and
data; sdb1 underpins a vg containing additional data. The other
partitions, sda2-sda4 and sdb3-sdb4, are not used at present, but are
configured as lvm physical volumes. Gparted is installed and I used it
to move these partitions toward the end of the disks, so that the maps
now are:

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sdb1              63 122077934 122077872 58.2G 8e Linux LVM
/dev/sdb2       122077935 244155869 122077935 58.2G 8e Linux LVM
*gap            244155870 244162559      6690  3.2M
/dev/sdb3       244162560 366239743 122077184 58.2G 8e Linux LVM
/dev/sdb4       366239744 488397167 122157424 58.3G 8e Linux LVM

and

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1  *           63 122077934 122077872 58.2G 8e Linux LVM
*gap            122077935 122085375      7441  3.6M
/dev/sda2       122085376 244162559 122077184 58.2G 8e Linux LVM
/dev/sda3       244162560 366239743 122077184 58.2G 8e Linux LVM
/dev/sda4       366239744 488397167 122157424 58.3G 8e Linux LVM

If I understand correctly, I should now be able to boot with a rescue
disk or USB key that has lvm, and move sdb2, sdb1, and sda1 similarly,
leaving several megabytes free at the beginning of each disk.

I haven't needed to do anything like this for quite a while and would be
grateful for corrections and suggestions to reduce risk, false starts,
and rework.

Specific questions addressed to anyone who knows:

1. the core.img file is 31952 bytes, apparently 208 bytes too long. Is
there a way to shorten it by that much without sacrificing the
capability to boot from an lvm logical volume and jfs file systems?

2. The grub install failed. The current modified grub.cfg was not
changed materially and references most objects by uuid. If I shut down
and move the necessary partitions, is the system likely to boot
successfully using the (hopefully unchanged) original grub installation,
so that I could simply move the pv partitions, reboot normally, run
grub-install, and then continue upgrading?

3. The problem occurred at the end of "apt upgrade." The necessary grub
commands appear to be in the current (although updated) grub.cfg.
Failing a successful normal boot, is it likely that I can boot the
system from a grub rescue device once the partitions are moved and
simply continue the upgrade from that point?

4. Any other suggestions thought useful are welcome.

I have file system backups from before the interrupted update and,
before I can see any possible responses, also will have a backup of the
current state of all file systems. The system appears to be running
normally and I do not plan to shut it down before finalizing a recovery
plan.

Thanks in advance,
Tom Dial

[toc] | [next] | [standalone]

#190498

Le 01/01/2018 à 06:51, Tom Dial a écrit :
> Upgrading a workstation from Jessie to Stretch I found that the original
> disk partitioning left insufficient space for grub (re)install. The
> system has two identical ~233 GiB disks, sda and sdb, partitioned
> identically:
> 
> Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x00015e37
> 
> Device     Boot     Start       End   Sectors  Size Id Type
> /dev/sda1  *           63 122077934 122077872 58.2G 8e Linux LVM
> /dev/sda2       122077935 244155869 122077935 58.2G 8e Linux LVM
> /dev/sda3       244155870 366233804 122077935 58.2G 8e Linux LVM
> /dev/sda4       366233805 488392064 122158260 58.3G 8e Linux LVM

This partition table must have been created a long time ago. At the time 
of Jessie, current partitioning tools would have aligned partitions on 
1-MiB boundaries instead of cylinder boundaries, leaving plenty of room 
for GRUB's core image.

> sda1 and sdb2 form a volume group with active LVs containing OS and
> data; sdb1 underpins a vg containing additional data. The other
> partitions, sda2-sda4 and sdb3-sdb4, are not used at present, but are
> configured as lvm physical volumes.

Do you mean that they are not part of any volume group ?

> Gparted is installed and I used it
> to move these partitions toward the end of the disks, so that the maps
> now are:
> 
> Device     Boot     Start       End   Sectors  Size Id Type
> /dev/sdb1              63 122077934 122077872 58.2G 8e Linux LVM
> /dev/sdb2       122077935 244155869 122077935 58.2G 8e Linux LVM
> *gap            244155870 244162559      6690  3.2M
> /dev/sdb3       244162560 366239743 122077184 58.2G 8e Linux LVM
> /dev/sdb4       366239744 488397167 122157424 58.3G 8e Linux LVM
> 
> and
> 
> Device     Boot     Start       End   Sectors  Size Id Type
> /dev/sda1  *           63 122077934 122077872 58.2G 8e Linux LVM
> *gap            122077935 122085375      7441  3.6M
> /dev/sda2       122085376 244162559 122077184 58.2G 8e Linux LVM
> /dev/sda3       244162560 366239743 122077184 58.2G 8e Linux LVM
> /dev/sda4       366239744 488397167 122157424 58.3G 8e Linux LVM

Which is the boot disk ?

> If I understand correctly, I should now be able to boot with a rescue
> disk or USB key that has lvm, and move sdb2, sdb1, and sda1 similarly,
> leaving several megabytes free at the beginning of each disk.

LVM tools cannot move partitions. pvmove does not move PV, it just moves 
LV data between PVs. You need Gparted to move partitions (and their 
contents). Of course you need to run Gparted from a system which does 
not use the partitions to be moved.

> 1. the core.img file is 31952 bytes, apparently 208 bytes too long. Is
> there a way to shorten it by that much without sacrificing the
> capability to boot from an lvm logical volume and jfs file systems?

Hardly. The core image must include necessary modules to read 
/boot/grub, including the partition table, lvm and the filesystem. You 
could move /boot/grub to a new LV with another filesystem type requiring 
less space in the core image. Checking the modules sizes, jfs.mod is 
slightly bigger than ext2.mod (by 156 bytes so I'm afraid it would not 
be enough). Smaller modules are fat.ko and minix*.ko. I have never used 
Minix filesystem, but I know GRUB can be installed on FAT, even though 
it does nogt sound very satifactory.

Other options :

- Move /boot/grub to a non-LVM partition. But I am not sure that the 
free 3.6 MiB on your disks will be enough even with a light filesystem.

- Install GRUB boot and core images in a btrfs non-LVM partition, which 
supports GRUB embedding, instead of in the MBR. However IME the minimum 
partition size for btrfs is at least 5 MiB (or 16 MiB, depending on 
btrfs tools version).

- Convert the partition table to GPT with gdisk and create a "BIOS boot" 
partition which GRUB can use to write the core image. However since you 
moved partitions to the very end of the disk there is no room any more 
to write the backup GPT partition table.

> 2. The grub install failed. The current modified grub.cfg was not
> changed materially and references most objects by uuid. If I shut down
> and move the necessary partitions, is the system likely to boot
> successfully using the (hopefully unchanged) original grub installation,
> so that I could simply move the pv partitions, reboot normally, run
> grub-install, and then continue upgrading?

The current state is :
- GRUB boot image and core image from Jessie in the MBR and gap
- GRUB modules from Stretch in /boot/grub

So I am afraid that the core image and modules won't match and GRUB may 
not boot properly, ending up in the rescue prompt. However it may work 
if the versions are close enough. GRUB versions in jessie and stretch 
are much closer than those in wheezy and jessie.

> 3. The problem occurred at the end of "apt upgrade." The necessary grub
> commands appear to be in the current (although updated) grub.cfg.
> Failing a successful normal boot, is it likely that I can boot the
> system from a grub rescue device once the partitions are moved and
> simply continue the upgrade from that point?

Yes.

> 
> 4. Any other suggestions thought useful are welcome.

You can delete an unused PV, this will leave plenty of free disk space 
to set up any of the above options.

> I have file system backups from before the interrupted update and,
> before I can see any possible responses, also will have a backup of the
> current state of all file systems. The system appears to be running
> normally and I do not plan to shut it down before finalizing a recovery
> plan.

You can restore Jessie's /boot/grub/ contents in order to boot without 
GRUB rescue.

[toc] | [prev] | [next] | [standalone]

#190519

On 01/01/2018 02:46 AM, Pascal Hambourg wrote:
> Le 01/01/2018 à 06:51, Tom Dial a écrit :
>> Upgrading a workstation from Jessie to Stretch I found that the original
>> disk partitioning left insufficient space for grub (re)install. The
>> system has two identical ~233 GiB disks, sda and sdb, partitioned
>> identically:
>>
>> Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
>> Units: sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>> Disklabel type: dos
>> Disk identifier: 0x00015e37
>>
>> Device     Boot     Start       End   Sectors  Size Id Type
>> /dev/sda1  *           63 122077934 122077872 58.2G 8e Linux LVM
>> /dev/sda2       122077935 244155869 122077935 58.2G 8e Linux LVM
>> /dev/sda3       244155870 366233804 122077935 58.2G 8e Linux LVM
>> /dev/sda4       366233805 488392064 122158260 58.3G 8e Linux LVM
> 
> This partition table must have been created a long time ago. At the time
> of Jessie, current partitioning tools would have aligned partitions on
> 1-MiB boundaries instead of cylinder boundaries, leaving plenty of room
> for GRUB's core image.

Yes: March, 2008; Etch installed then, later upgraded successively to
Lenny, Squeeze, Wheezy, and Jessie without major difficulty.
> 
>> sda1 and sdb2 form a volume group with active LVs containing OS and
>> data; sdb1 underpins a vg containing additional data. The other
>> partitions, sda2-sda4 and sdb3-sdb4, are not used at present, but are
>> configured as lvm physical volumes.
> 
> Do you mean that they are not part of any volume group ?

Correct.
> 
>> Gparted is installed and I used it
>> to move these partitions toward the end of the disks, so that the maps
>> now are:
>>
>> Device     Boot     Start       End   Sectors  Size Id Type
>> /dev/sdb1              63 122077934 122077872 58.2G 8e Linux LVM
>> /dev/sdb2       122077935 244155869 122077935 58.2G 8e Linux LVM
>> *gap            244155870 244162559      6690  3.2M
>> /dev/sdb3       244162560 366239743 122077184 58.2G 8e Linux LVM
>> /dev/sdb4       366239744 488397167 122157424 58.3G 8e Linux LVM
>>
>> and
>>
>> Device     Boot     Start       End   Sectors  Size Id Type
>> /dev/sda1  *           63 122077934 122077872 58.2G 8e Linux LVM
>> *gap            122077935 122085375      7441  3.6M
>> /dev/sda2       122085376 244162559 122077184 58.2G 8e Linux LVM
>> /dev/sda3       244162560 366239743 122077184 58.2G 8e Linux LVM
>> /dev/sda4       366239744 488397167 122157424 58.3G 8e Linux LVM
> 
> Which is the boot disk ?

/dev/sda
> 
>> If I understand correctly, I should now be able to boot with a rescue
>> disk or USB key that has lvm, and move sdb2, sdb1, and sda1 similarly,
>> leaving several megabytes free at the beginning of each disk.>
> LVM tools cannot move partitions. pvmove does not move PV, it just moves
> LV data between PVs. You need Gparted to move partitions (and their
> contents). Of course you need to run Gparted from a system which does
> not use the partitions to be moved.

Thanks for the correction. I might have caught the error, or might not.
> 
>> 1. the core.img file is 31952 bytes, apparently 208 bytes too long. Is
>> there a way to shorten it by that much without sacrificing the
>> capability to boot from an lvm logical volume and jfs file systems?
> 
> Hardly. The core image must include necessary modules to read
> /boot/grub, including the partition table, lvm and the filesystem. You
> could move /boot/grub to a new LV with another filesystem type requiring
> less space in the core image. Checking the modules sizes, jfs.mod is
> slightly bigger than ext2.mod (by 156 bytes so I'm afraid it would not
> be enough). Smaller modules are fat.ko and minix*.ko. I have never used
> Minix filesystem, but I know GRUB can be installed on FAT, even though
> it does nogt sound very satifactory.
> 
> Other options :
> 
> - Move /boot/grub to a non-LVM partition. But I am not sure that the
> free 3.6 MiB on your disks will be enough even with a light filesystem.
> 
> - Install GRUB boot and core images in a btrfs non-LVM partition, which
> supports GRUB embedding, instead of in the MBR. However IME the minimum
> partition size for btrfs is at least 5 MiB (or 16 MiB, depending on
> btrfs tools version).
> 
> - Convert the partition table to GPT with gdisk and create a "BIOS boot"
> partition which GRUB can use to write the core image. However since you
> moved partitions to the very end of the disk there is no room any more
> to write the backup GPT partition table.
> 
>> 2. The grub install failed. The current modified grub.cfg was not
>> changed materially and references most objects by uuid. If I shut down
>> and move the necessary partitions, is the system likely to boot
>> successfully using the (hopefully unchanged) original grub installation,
>> so that I could simply move the pv partitions, reboot normally, run
>> grub-install, and then continue upgrading?
> 
> The current state is :
> - GRUB boot image and core image from Jessie in the MBR and gap
> - GRUB modules from Stretch in /boot/grub
> 
> So I am afraid that the core image and modules won't match and GRUB may
> not boot properly, ending up in the rescue prompt. However it may work
> if the versions are close enough. GRUB versions in jessie and stretch
> are much closer than those in wheezy and jessie.
> 
>> 3. The problem occurred at the end of "apt upgrade." The necessary grub
>> commands appear to be in the current (although updated) grub.cfg.
>> Failing a successful normal boot, is it likely that I can boot the
>> system from a grub rescue device once the partitions are moved and
>> simply continue the upgrade from that point?
> 
> Yes.
> 
>>
>> 4. Any other suggestions thought useful are welcome.
> 
> You can delete an unused PV, this will leave plenty of free disk space
> to set up any of the above options.
> 
>> I have file system backups from before the interrupted update and,
>> before I can see any possible responses, also will have a backup of the
>> current state of all file systems. The system appears to be running
>> normally and I do not plan to shut it down before finalizing a recovery
>> plan.
> 
> You can restore Jessie's /boot/grub/ contents in order to boot without
> GRUB rescue.

So maybe the right plan is
0. make a grub-rescue CD just in case of need
1. restore the old (jessie) /boot/grub/*
2. shut down, move the remaining partitions with gparted
3. reboot using the old grub, kernel, initrd, etc.
4. restore the new (stretch) /boot/grub/*
5. run grub-install to install the new grub
6. reboot and finish the stretch upgrade.

Thank you very much for the quick, concise, and detailed answers.

Tom Dial

[toc] | [prev] | [next] | [standalone]

#190554

Le 02/01/2018 à 00:56, Tom Dial a écrit :
> 
>> Which is the boot disk ?
> 
> /dev/sda

Then you didn't need to make room for GRUB on /dev/sdb.

> So maybe the right plan is

This is one of the many possible plans.

> 0. make a grub-rescue CD just in case of need
> 1. restore the old (jessie) /boot/grub/*
> 2. shut down, move the remaining partitions with gparted

Actually only /dev/sda1, which must not be in used, i.e. no LV having 
extents in it must be active.

> 3. reboot using the old grub, kernel, initrd, etc.
> 4. restore the new (stretch) /boot/grub/*

No need to restore the new /boot/grub/*, grub-install will recreate it.

> 5. run grub-install to install the new grub
> 6. reboot and finish the stretch upgrade.

[toc] | [prev] | [next] | [standalone]

#190590

On 01/02/2018 11:14 AM, Pascal Hambourg wrote:
> Le 02/01/2018 à 00:56, Tom Dial a écrit :
>>
>>> Which is the boot disk ?
>>
>> /dev/sda
> 
> Then you didn't need to make room for GRUB on /dev/sdb.
> 
>> So maybe the right plan is
> 
> This is one of the many possible plans.

But it is uncomplicated and simple to execute using available or easily
obtained tools. The total outage time was around 2 hours and, as pointed
out below, could have been much less if I had moved only the partitions
on the current boot disk.
> 
>> 0. make a grub-rescue CD just in case of need
>> 1. restore the old (jessie) /boot/grub/*
>> 2. shut down, move the remaining partitions with gparted
> 
> Actually only /dev/sda1, which must not be in used, i.e. no LV having
> extents in it must be active.

I realized that part way through, but pushed on for consistency, and
with a half-formed and unresearched notion of installing grub on the
second disk as well.

What I did not know until finishing is that gparted would, without being
told, leave the first 2048 blocks vacant. So I told it explicitly to
leave 1M empty at the beginning, so the first partitions now actually
begin at block 4096.
> 
>> 3. reboot using the old grub, kernel, initrd, etc.
>> 4. restore the new (stretch) /boot/grub/*
> 
> No need to restore the new /boot/grub/*, grub-install will recreate it.

Another thing I did not know, then.
> 
>> 5. run grub-install to install the new grub
>> 6. reboot and finish the stretch upgrade.

Overall, it went fairly well, and in particular, there were no boot
issues or data corruption. The only issue is that the first partition on
the boot drive was resized, but the PV it contains apparently was not,
so now is larger than the partition. I suspect this happened because the
PV was fully allocated to LVs. It has not caused any apparent problems,
probably because the file systems on the LVs are not very full. I will
need to fix it, though.

Thanks again.

Tom Dial

[toc] | [prev] | [next] | [standalone]

#190620

Le 03/01/2018 à 09:10, Tom Dial a écrit :
> On 01/02/2018 11:14 AM, Pascal Hambourg wrote:
>>
>> This is one of the many possible plans.
> 
> But it is uncomplicated and simple to execute using available or easily
> obtained tools. The total outage time was around 2 hours and, as pointed
> out below, could have been much less if I had moved only the partitions
> on the current boot disk.

IMO, moving partitions is complicated, tedious, and dangerous. I avoid 
doing it as much as possible.
Complicated because it requires running Gparted, in a graphic 
environment, without the partition being in use.
Tedious because it requires moving (=reading and writing) each data 
block around, which can take a long time with big partitions.
Dangerous because if anything interrupts the process before completion 
(system crash, power loss, or maybe even read/write error), the 
partition and its contents is lost.

This is why I suggested alternatives.

> Overall, it went fairly well, and in particular, there were no boot
> issues or data corruption. The only issue is that the first partition on
> the boot drive was resized, but the PV it contains apparently was not,
> so now is larger than the partition.

This is not good. The partition should not have been reduced. If it had 
happened to a plain ext4 partition without reducing the filesystem 
first, the kernel would refust to mount it.
You can try to resize the PV with pvresize, in hope that the missing 
extents were not allocated to any LV.

> I suspect this happened because the
> PV was fully allocated to LVs. It has not caused any apparent problems,
> probably because the file systems on the LVs are not very full. I will
> need to fix it, though.

If the PV was fully allocated, then I'm afraid you experience trouble 
sooner or later. You can check with pvdisplay.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web