Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #190498
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: How to relocate LVM pv to make room for grub install |
| Date | 2018-01-01 10:50 +0100 |
| Message-ID | <v34Tf-tJ-3@gated-at.bofh.it> (permalink) |
| References | <v31sl-6Yn-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web