Created attachment 687995 [details]
grub.cfg
With a fresh install of 42.1 on a recent model laptop (Not UEFI)
grub.cfg has these lines, which only work on this laptop.
If clonezilla is used to replace the hard drive, or clone to a identical
laptop. It will not boot due to UUID's being used in grub.cfg
(Clonezilla settings, disks-Images, basic/beginner, Restore/save disks, all
other default options, Via samba)
You can then from the grub console easily find and boot the system, But YaST2
Boot Loader BUG # https://bugzilla.opensuse.org/show_bug.cgi?id=949796 will
occur preventing a permanent fix.
You can edit the grub.cfg by hand to fix the issue, but given yast2 still
crashes on boot loader config, i worry this isn���t a good solution.
This bug can be reproduced on identical machines.
A set of 4 Identically configured Lenovo X300 Laptops with SSD's were used.
ATTACHED grub.cfg
If you replace all lines like this...
search --no-floppy --fs-uuid --set=root 6ab67475-b1f0-4f91-81ac-0bcb395f4b31
With this line...
search --no-floppy --fs-uuid --set=root hd0,msdos2
Everything works for cloning and booting.
But if you try to run YaST2 Boot Loader, BUG #
https://bugzilla.opensuse.org/show_bug.cgi?id=949796 will occur.
SYSTEM Configuration
/etc/fstab
LABEL=swap swap swap
defaults 0 0
LABEL=root / ext4
noatime,acl,user_xattr 1 1
LABEL=home /home ext4
noatime,acl,user_xattr 1 2
fdisk /dev/sda (Print)
Disk /dev/sda: 59.6 GiB, 64023257088 bytes, 125045424 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: 0xf38e3fd3
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 8402943 8400896 4G 82 Linux swap / Solaris
LABEL=swap
/dev/sda2 * 8402944 29382655 20979712 10G 83 Linux LABEL=root
/dev/sda3 29382656 125044735 95662080 45.6G 83 Linux LABEL=home
======================== Start /dev/disks On working Origin system.
========================
linux-930q:/dev/disk # ls -R
.:
by-id by-label by-path by-uuid
./by-id:
ata-MATSHITADVD-RAM_UJ-844
scsi-SATA_SAMSUNG_MCCOE64GSE816A6533
ata-SAMSUNG_MCCOE64G8MPP-0VA_SE816A6533
scsi-SATA_SAMSUNG_MCCOE64G_SE816A6533
ata-SAMSUNG_MCCOE64G8MPP-0VA_SE816A6533-part1
scsi-SATA_SAMSUNG_MCCOE64G_SE816A6533-part1
ata-SAMSUNG_MCCOE64G8MPP-0VA_SE816A6533-part2
scsi-SATA_SAMSUNG_MCCOE64GSE816A6533-part1
ata-SAMSUNG_MCCOE64G8MPP-0VA_SE816A6533-part3
scsi-SATA_SAMSUNG_MCCOE64G_SE816A6533-part2
scsi-0ATA_SAMSUNG_MCCOE64G_SE816A6533
scsi-SATA_SAMSUNG_MCCOE64GSE816A6533-part2
scsi-0ATA_SAMSUNG_MCCOE64G_SE816A6533-part1
scsi-SATA_SAMSUNG_MCCOE64G_SE816A6533-part3
scsi-0ATA_SAMSUNG_MCCOE64G_SE816A6533-part2
scsi-SATA_SAMSUNG_MCCOE64GSE816A6533-part3
scsi-0ATA_SAMSUNG_MCCOE64G_SE816A6533-part3
scsi-SATA_SAMSUNG_MCCOE64SE816A6533
scsi-1ATA_SAMSUNG_MCCOE64G8MPP-0VA_SE816A6533
scsi-SATA_SAMSUNG_MCCOE64SE816A6533-part1
scsi-1ATA_SAMSUNG_MCCOE64G8MPP-0VA_SE816A6533-part1
scsi-SATA_SAMSUNG_MCCOE64SE816A6533-part2
scsi-1ATA_SAMSUNG_MCCOE64G8MPP-0VA_SE816A6533-part2
scsi-SATA_SAMSUNG_MCCOE64SE816A6533-part3
scsi-1ATA_SAMSUNG_MCCOE64G8MPP-0VA_SE816A6533-part3
./by-label:
home root swap
./by-path:
pci-0000:00:1f.1-ata-1.0 pci-0000:00:1f.2-ata-1.0-part1
pci-0000:00:1f.2-scsi-0:0:0:0 pci-0000:00:1f.2-scsi-0:0:0:0-part3
pci-0000:00:1f.1-scsi-3:0:0:0 pci-0000:00:1f.2-ata-1.0-part2
pci-0000:00:1f.2-scsi-0:0:0:0-part1
pci-0000:00:1f.2-ata-1.0 pci-0000:00:1f.2-ata-1.0-part3
pci-0000:00:1f.2-scsi-0:0:0:0-part2
./by-uuid:
565fc838-eae8-4b00-854d-4881abea156b 6ab67475-b1f0-4f91-81ac-0bcb395f4b31
6cb9f8ea-7da4-4eb3-80a5-24651095e5f8
======================== End /dev/disks On working Origin system.
========================
======================== Start /dev/disks On Cloned Broken System Identical
Laptop. ========================
user@linux-930q:/dev/disk> ls -R
.:
by-id by-label by-path by-uuid
./by-id:
ata-MATSHITADVD-RAM_UJ-844
scsi-SATA_SAMSUNG_MMCRE64GSE837B7191
ata-SAMSUNG_MMCRE64G8MPP-0VA_SE837B7191
scsi-SATA_SAMSUNG_MMCRE64G_SE837B7191
ata-SAMSUNG_MMCRE64G8MPP-0VA_SE837B7191-part1
scsi-SATA_SAMSUNG_MMCRE64G_SE837B7191-part1
ata-SAMSUNG_MMCRE64G8MPP-0VA_SE837B7191-part2
scsi-SATA_SAMSUNG_MMCRE64GSE837B7191-part1
ata-SAMSUNG_MMCRE64G8MPP-0VA_SE837B7191-part3
scsi-SATA_SAMSUNG_MMCRE64G_SE837B7191-part2
scsi-0ATA_SAMSUNG_MMCRE64G_SE837B7191
scsi-SATA_SAMSUNG_MMCRE64GSE837B7191-part2
scsi-0ATA_SAMSUNG_MMCRE64G_SE837B7191-part1
scsi-SATA_SAMSUNG_MMCRE64G_SE837B7191-part3
scsi-0ATA_SAMSUNG_MMCRE64G_SE837B7191-part2
scsi-SATA_SAMSUNG_MMCRE64GSE837B7191-part3
scsi-0ATA_SAMSUNG_MMCRE64G_SE837B7191-part3
scsi-SATA_SAMSUNG_MMCRE64SE837B7191
scsi-1ATA_SAMSUNG_MMCRE64G8MPP-0VA_SE837B7191
scsi-SATA_SAMSUNG_MMCRE64SE837B7191-part1
scsi-1ATA_SAMSUNG_MMCRE64G8MPP-0VA_SE837B7191-part1
scsi-SATA_SAMSUNG_MMCRE64SE837B7191-part2
scsi-1ATA_SAMSUNG_MMCRE64G8MPP-0VA_SE837B7191-part2
scsi-SATA_SAMSUNG_MMCRE64SE837B7191-part3
scsi-1ATA_SAMSUNG_MMCRE64G8MPP-0VA_SE837B7191-part3
./by-label:
home root swap
./by-path:
pci-0000:00:1f.2-ata-1.0 pci-0000:00:1f.2-ata-1.0-part3
pci-0000:00:1f.2-scsi-0:0:0:0-part1 pci-0000:00:1f.2-scsi-1:0:0:0
pci-0000:00:1f.2-ata-1.0-part1 pci-0000:00:1f.2-ata-2.0
pci-0000:00:1f.2-scsi-0:0:0:0-part2
pci-0000:00:1f.2-ata-1.0-part2 pci-0000:00:1f.2-scsi-0:0:0:0
pci-0000:00:1f.2-scsi-0:0:0:0-part3
./by-uuid:
565fc838-eae8-4b00-854d-4881abea156b 6ab67475-b1f0-4f91-81ac-0bcb395f4b31
6cb9f8ea-7da4-4eb3-80a5-24651095e5f8
======================== End /dev/disks On Cloned Broken System Identical
Laptop. ========================
YaST2 PARTITIONER
I have set mount by to device ID.
This causes the yast2 boot loader config to keep a setting of /dev/sda for the
boot drive.
But this setting has no effect on how the grub.cfg is generated.
If you use volume label as the mount by, then the boot drive changes to
/dev/disk/by-id/msdos which is bogus and will never save.
POSSIBLE SOLUTIONS
Write /etc/grub.d/10-linux.cfg so the generated grub.cfg trys UUID first, (hd)
paths 2nd, Labels 3rd .....
Make YaST2 Bootloader prefer disk Lables if they are set, and, add a option to
change the preferred method for finding drives in grub.
If disk labels were initialized every time on install to a random value + mount
name. then they might be a more reliable way to go for mounting and booting.