From: robin_listas@es.invalid   
      
   On 26/02/2021 15.09, Sidney_Kotic wrote:   
   > On 2/26/21 3:38 AM, Andrew wrote:   
   >   
   >> This discussion is going way off-topic, but I'll go a bit deeper into   
   >> this problem.   
   >> The Leap 15.2 Install dvd does some pre-install analysis of the   
   >> hardware and the bios, as it should.  I'm not sure how this works but   
   >> on my test system it essentially booted in EFI mode because the BIOS   
   >> supports this, and then got rather upset (dire warnings about   
   >> unbootable systems) when it "realised" it was supposed to be setting   
   >> up and old-style-BIOS install.  Those dire warnings turned out to be   
   >> overrated, the install ran correctly and the booted Leap 15.2 worked.   
   >> Then I tried to convert that machine to EFI boot and things got ugly.   
   >> This is what test-systems are for.  I have an idea how to go forwards   
   >> but it will take a day and some prep-work, it will also involve   
   >> comparing a Leap 15.2 EFI system with a Leap 15.2 old-style system -   
   >> no big deal because I have both.   
   >   
   > Is there a place where this process is documented?  I have a computer   
   > sitting in that state, BIOS boot and complaining about (U?)EFI.  I'm   
   > really hesitant to attack it because of the way the drives are laid   
   > out.  Basically there's a boot drive with the OS and the standard files   
   > on it, then there are 2 8TB mirrored drives with lots of stuff on them.    
   > While I could backup the data up onto removable drives it's a multi-day   
   > process to off-load and then the same to recover it.   
      
   I can tell what I did, more or less.   
      
   In my case, it was a migration from BIOS machine to UEFI machine.   
      
   I started with creating a small, fresh installation, with UEFI, on a new   
   nvme "disk". This system I use as rescue system to do the migration, and   
   to learn what the boot parameters would be on this UEFI machine.   
      
   Then I created partitions to migrate the system from the old machine   
   using rsync:   
      
   > Telcontar:~ # lsblk --output NAME,KNAME,RA,RM,RO,PARTFLAGS,SIZ   
   ,TYPE,FSTYPE,LABEL,PARTLABEL,PTTYPE,MOUNTPOINT,UUID,PARTUUID,WWN   
   MODEL,ALIGNMENT /dev/nvme0n1   
   > NAME        KNAME      RA RM RO PARTFLAGS   SIZE TYPE FSTYPE LABEL       
   PARTLABEL PTTYPE MOUNTPOINT   
   > nvme0n1     nvme0n1   512  0  0           465.8G dis   
                               gpt   
   > ├─nvme0n1p1 nvme0n1p1 512  0  0             500M part vfat   EFI         
   EFI       gpt    /boot/efi   
   > ├─nvme0n1p2 nvme0n1p2 512  0  0             100G part swap   nvme-swap   
   nvme-swap gpt    [SWAP]   
   > ├─nvme0n1p3 nvme0n1p3 512  0  0              30G part ext4   Auxiliary   
   Auxiliary gpt   
   > ├─nvme0n1p4 nvme0n1p4 512  0  0               1G part ext2   nvme-boot   
   nvme-boot dos    /boot   
   > └─nvme0n1p5 nvme0n1p5 512  0  0             150G part ext4   nvme-main   
   nvme-main gpt    /   
   > Telcontar:~ #   
      
   "/", "/boot", /boot/efi, swap.   
      
   Make sure that the "rescue" partition has detected (os-probe) the new   
   "install", the moved one.   
      
   Then I chrooted to the new "main" partition, and used YaST in text mode   
   to configure boot, using the "Boot loader" module, telling it this time   
   to use UEFI mode.   
      
   It is crucial to previously edit in the file "/etc/default/grub", the line:   
      
   GRUB_DISTRIBUTOR="main-os"   
      
   Write something that is not the default; otherwise, it will overwrite   
   other openSUSE installs, such as the rescue partition. And edit that   
   file on all openSUSE installs.   
      
   Then reboot, and try to reboot that migrated system. If it fails (mine   
   failed), find out why, and correct.   
      
   I had to do a few cycles.   
      
   At some stage I finally was able to boot the migrated system using the   
   grub of the rescue system. Soon after that I managed to boot the   
   migrated system on its own.   
      
      
   Trick: The YaST "Boot loader" module writes everything to disk if you   
   change the timeout value in seconds, just one second.   
      
      
      
   You see, I can not document the exact procedure because I had to try a   
   few times till the system was happy and booted. I don't know what   
   exactly was wrong or missing in the first move. Or maybe it is   
   impossible to do it in one move.   
      
      
   --   
   Cheers, Carlos.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)