Updating Win 8.1 to Win 10 on a multiboot system went fairly smoothly - very
slow, but smooth - but the process messed up my partition table by
apparently creating new Win partitions in space cleared by removing some Win
9 cruft (my best guess at the problem). The result is that the table
sequence numbers on 3 additional Linux installations (plus the original swap
partition) have shifted. The table seems to have been sequenced in physical
order of position on the disk. It is now:
(CODE)
parted -l
Model: ATA ST2000DM001-9YN1 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Current partition 9 (swap) was 6 and 7/8 were 12/13 resp. I verified that by
the contents. It’s likely Win 10 re-ordered things as I haven’t seen any of
the Linux partitioning tools mucking with an established order.
When I now boot (UEFI), I get either part 7 or part 12 mounted to /. These
were bootable root partitions before the update. If I boot to one
functional root partition, would I be safe in editing fstab on that
partition then either running mkinitrd or just using yast to re-install
grub2 (UEFI)? I realize that I will need to patch up fstab on the other
installations before I’m home free.
I do miss the simplicity of grub1 where all the details are simple and
obvious to patch! I’m still not up to speed on grub2.
> Current partition 9 (swap) was 6 and 7/8 were 12/13 resp. I verified that by
> the contents. It’s likely Win 10 re-ordered things as I haven’t seen any of
> the Linux partitioning tools mucking with an established order.
Of course they do. Any Linux partitioning tool would do exactly the
same. A new partition was added, and anything that refers to partition
by number has to be changed to point to the new numbers. Next time,
better use uuid or labels, they don’t change.
So you have to boot a rescue Linux system, mount “/”, edit fstab and
grub configs, change the references, chroot the partition (with bind
mount to proc, sys and… I forget which… ah, dev), run mkinitrd,
perhaps reinstall grub. Then reboot. Roughly. I know how to do it, but
not how to give a detailed description.
Boot from live media, mount the root partition. Then edit “/etc/fstab”.
If an fstab entry uses UUID, then you should not need to change that.
Otherwise look for entries of the form “/dev/disk/by-id/some_long_string-partx”
and just change the “partx” to “party” where “x” is the old partition number and “y” is the new partition number. The rest of the string should be fine.
If you are using encrypted partitions, then you need to make similar changes in “/etc/crypttab”.
Personally, I would ignore the comment that says otherwise, and edit “/boot/grub2/grub.cfg” for the same changes. That will only be temporary. But once the system is up and running, it will be easier to edit “/etc/default/grub” and regenerate grub.cfg.
If you are using encryption, you probably need to regenerate the “initrd”. Without encryption, it might work with just the other changes.
If you need the details on regenerating “initrd”, then ask in a reply to this.
> If an fstab entry uses UUID, then you should not need to change that.
>
> Otherwise look for entries of the form
> “/dev/disk/by-id/some_long_string-partx”
> and just change the “partx” to “party” where “x” is the old partition
> number and “y” is the new partition number. The rest of the string
> should be fine.
>
> If you are using encrypted partitions, then you need to make similar
> changes in “/etc/crypttab”.
>
> Personally, I would ignore the comment that says otherwise, and ed
> “/boot/grub2/grub.cfg” for the same changes. That will only be
> temporary. But once the system is up and running, it will be easier to
> edit “/etc/default/grub” and regenerate grub.cfg.
>
OK, you have pretty well confirmed what I proposed to do. As soon as the
dust settles from the wife’s retirement party - big deal for her! - I’ll see
what I happens but it looks like a fairly straight forward matter of
changing the ******-partx.
Assuming I get at least one of the 13.x versions booting with correct
mapping, will simply doing some edit to trigger a re-load in the yast boot
loader section result in a complete refresh of the grub menu?
For reference, where do I change the settings to force use of the UUID
string to identify partitions? That seems to be a sensible thing to me.
> For reference, where do I change the settings to force use of the UUID
> string to identify partitions? That seems to be a sensible thing to me.
Actually it’s not such a good idea on multiboot systems WRT swap partitions.
Linux installers tend to assume it’s OK to reformat swap partitions. When
that happens, only the new installation has the correct UUID for swap until
fstab adjustments are made for other installations. Swap partitions, like
other partitions, can have a label applied. Labels can be something easy to
remember, easy to change in fstab, and easy to restore to the swap partition
when need be. Using UUID is similarly complicated if cloning is part of a
backup/restore strategy. Labels for such a use case are again easier than
UUIDs for a human brain to manage.
> Will Honea composed on 2015-08-02 04:47 (UTC):
>
>> For reference, where do I change the settings to force use of the UUID
>> string to identify partitions? That seems to be a sensible thing to me.
>
> Actually it’s not such a good idea on multiboot systems WRT swap
> partitions. Linux installers tend to assume it’s OK to reformat swap
> partitions. When that happens, only the new installation has the correct
> UUID for swap until fstab adjustments are made for other installations.
> Swap partitions, like other partitions, can have a label applied. Labels
> can be something easy to remember, easy to change in fstab, and easy to
> restore to the swap partition when need be. Using UUID is similarly
> complicated if cloning is part of a backup/restore strategy. Labels for
> such a use case are again easier than UUIDs for a human brain to manage.
Good point, Felix. I set this up with a single, common swap for the 3 Linux
versions when I started and now all 3 versions have it wrong. One of the
versions actually came thru bootable albeit with different root and home
partitions. Since version now thinks an ext4 formatted one, it actually
boots with NO swap so no damage has been done - yet - and with 12 GB of ram
I really have no need of a swap until I get everything straight. I still
have less problem manually processing partition tables with labels than
UUIDs but I see a pretty universal shift toward them and agree with the
philosophy.