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
