[SOLVED] Advice on replacing boot disk, non-identical partitions

michaelk · 12-28-2021, 10:25 PM

As far as I know the setting the boot flag using gparted just sets the flag and does not actually install grub.

Use UUIDs in your /etc/fstab so the order of disks does not matter.

Different inodes should not matter.

colorpurple21859 · 12-29-2021, 01:33 AM

Quote:

So, to make the things clearer to me: the fact that I set the "boot" flag on the /dev/sdc1 partition using GParted has created the boot code in the MBR
and just by copying into /dev/sdc1 all the files from /dev/sda1 will make the boot process successfull

No, setting the boot flag does not install grub boot-loader code to the mbr.

After copying files to /dev/sdc1 umount /dev/sda1 from /boot and mount /dev/sdc1 to /boot. Change the uuid in /etc/fstab from /dev/sda1 uuid to /dev/sdc1 uuid for the /boot mount entry

Code:

grub2-install /dev/sdc
grub2-mkconfig -o /boot/grub2/grub.cfg

The system should boot after changing the boot order of the drives.

kaza · 12-30-2021, 01:04 PM

Thanks for the replyes!

After reading the michaelk's reply I also thought that I need to edit the /etc/fstab
so that UUID will be of the new disk (currently /dev/sdc) so I'm glad my thought was correct at least
on that point.

Since the "/" is on the LVM that means before editing the /dev/fstab I need to copy all of the LVs
of /dev/sda to /dev/sdc. Since /dev/sdc currently has only one partition (/dev/sdc1) to become bootable,
I think I should first create on the /dev/sdc unallocated space a new partition of the "lvm2 pv" type (same
as /dev/sda2) and then run "pvmove /dev/sda2 /dev/sdc2", right?

Does the "pvmove /dev/sda2 /dev/sdc2" copies or moves the physical volume? That is, what happens to the /dev/sda2?
If it copies, what happens to the volume group names on two disks which (I think) become identical? Can LVM
deal with it?

TIA,
kaza.

Brains · 12-30-2021, 11:34 PM

Quote:

When copying files using a simple "cp" the "inodes" on the destination might not be the same as on the source (I think), does the boot code cares about such things
or it's sophisticated enough to find the files just by their names?

Inodes are irrelevant. With most all platforms, Windows, Linux, BSD etc. A well designed backup tool only collects used data blocks, not unused, some defragment the data in the process.

I do a lot of these type of backups and generally what matters most is proper partition UUID for Grub as that's the typical default settings, using UUID rather than paths or devices. You may choose to chroot into it after transfer and change the /etc/fstab UUID entries to match that of the new partitons and then reconfigure Grub to pick it up, or change the UUID of the new partitions to match that of the same partitions on the old drive.

But when it comes to restoring most of these data only backups, the way I see it, inodes and partition size is irrelevant, just dump the files and directories collected from one partition and drop them in another, if UUID information is proper, it will boot.

Brains · 12-31-2021, 12:24 AM

BTW: I haven't tried yet to make a new IFL ISO, but I know Image for UEFI and it asks you during creation if you want a UEFI (default) or BIOS boot disk.

My experience with Fedora:
When it fails to boot, I can never get it to boot again. Because I give it a partition in my multiboot and LVM can't be used in this scenario. But it still installs with LVM hierarchy, root has a folder called home and a folder called root. I haven't found a way around this issue when it comes to re-configuring Grub. It either does that by default in VMWare or I make a mistake, but seems the second time I installed Fedora 34 and this current Fedora 35 VMs I let it do it's default thing and I have same issue with them, LVM structure but not LVM.
CentOS installed properly with an actual LVM partition scheme.

colorpurple21859 · 12-31-2021, 02:03 AM

Brains:

Quote:

LVM structure but not LVM.

Fedora now uses btrfs by default, has sub-volumes similar to lvm, but not lvm.

Brains:

Quote:

My experience with Fedora:
When it fails to boot, I can never get it to boot again.

Grub2 is considered complicate by some. Fedora made grub2 more complicated in the process of attempting to make it user friendly IMHO, especially in efi mode.

When multibooting with other distros and the other distros have there own separate boot partition grub os-prober doesn't find the kernels on the other boot partitions. The enabling of BLSCFG in grub configuration by Fedora makes the use fedora grub.cfg for booting from other distro useless.

kaza:

Quote:

Does the "pvmove /dev/sda2 /dev/sdc2" copies or moves the physical volume?

There are several tutorials on the web that explain how to migrate a lvm to a new drive.

kaza · 12-31-2021, 03:14 AM

Thanks for the replyes,

I'm currently reading

https://www.casesup.com/category/knowledgebase/howtos/how-to-migrate-lvm-to-new-storage

and

https://www.tecmint.com/lvm-storage-migration/

I think I'll prefare the second one.

BTW, in both of them the use of "pvmove" is discouraged in favor of mirroring,
why is that?

TIA,
kaza.

colorpurple21859 · 12-31-2021, 03:31 AM

mirroring: data is on both drives, pvmove: data is only on new drive

syg00 · 12-31-2021, 03:49 AM

Quote:

Originally Posted by colorpurple21859

mirroring: data is on both drives, pvmove: data is only on new drive

Nope - that explanation is too superficial. pvmove allocates a temporary lv that is effectively a mirror. Hence the ability to interrupt it safely. Note that despite its name pvmove migrates data, not the pv itself.

Different solutions to different requirements. There is no need to explicitly create a mirror - use pvmove; it has all the functionality needed.

I like the RHEL LVM guide for background on LVM - very extensive and available for free download last I looked.

kaza · 12-31-2021, 08:38 AM

Thanks for all the replyes,

I successfully switched to booting the new disk (RAID 1 array).

I only had a minor "hickup" in the process:

Code:

<root localhost.localdomain>.../root>lvconvert -m 1 /dev/VolGroup/lv_home /dev/sdc2
Are you sure you want to convert linear LV VolGroup/lv_home to raid1 with 2 images enhancing resilience? [y/n]: y
  Insufficient free space: 1 extents needed, but only 0 available

After finding an explanation and solutions, I thought weather to start resizing the LVs but at the end decided
to use an old "mirror" type and log in the memory:

Code:

lvconvert --type mirror --mirrorlog core  -m 1 /dev/VolGroup/lv_home /dev/sdc2
lvconvert --type mirror --mirrorlog core  -m 1 /dev/VolGroup/lv_root /dev/sdc2
lvconvert --type mirror --mirrorlog core  -m 1 /dev/VolGroup/lv_swap /dev/sdc2

and that worked OK.

After switching the order of arrays in the controller utility, the PC booted OK
and I could somewhat increase the "/home" as the new array is larger.

Now I'll rerun the backup again (2 * 25 hours) to have the new configuration
saved.

Thanks again,
kaza.