Andrei Borzenkov wrote:
On Fri, Mar 30, 2018 at 3:58 PM, Peter Suetterlin <pit@astro.su.se> wrote:
After I finally used the proper boot stick I have access to the system again. And 0:rescue:~ # efibootmgr -v
Boot0018* UEFI: InnostorInnostor 1.00, Partition 1 PciRoot(0x0)/Pci(0x14,0x0)/USB(4,0)/HD(1,MBR,0x1b681c50,0x107c,0x1e84)..BO Boot0019* InnostorInnostor 1.00 BBS(HD,,0x0)..BO
This is probably your USB stick added automatically
Correct.
Boot001A* Samsung SSD 950 PRO 512GB BBS(HD,,0x0)..BO
This is legacy boot which I assume is your default one according to BootOrder.
Ah, so internally it uses the efi-entries also for legacy. Didn't know that..
RESULTS.txt from https://github.com/arvidjaar/bootinfoscript could be helpful.
I had tried running yast2 bootloader first. That had very weird settings, telling to install to a disk that resolved to /dev/sda. That disk is part of a RAID set. Just hope it didn't mess up that one... I entered correct values and wanted to install bootmanager - and it failed, complaining device.map has too many entries. Oh hell. So I had a look at /etc/default/grub* and /boot/grub2/device* first, which luckily had *.old files around the contained the previous (correct) settings. The device.map contained all 22 'normal' disks of this system (16 SSD plus 6 HDD), but not the actual system disk, an NVMe one. So no wonder the install failed. So reducing device.map to a single entry (hd0) /dev/nvme0n1 and also /etc/default/grub_installdevice to the old values I could now re-run the yast2 bootloader and properly install it. I'll see if I can spot the moment when those files were changed, but I don't keep too many snapshots around. In any case MANY thanks for your assistance! -- Dr. Peter "Pit" Suetterlin http://www.astro.su.se/~pit Institute for Solar Physics Tel.: +34 922 405 590 (Spain) P.Suetterlin@royac.iac.es +46 8 5537 8559 (Sweden) Peter.Suetterlin@astro.su.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org