12.05.2019 17:28, Stephen Berman пишет:
GUID Partition Table detected.
Partition Attrs Start Sector End Sector # of Sectors System /dev/nvme0n11 2,048 1,050,623 1,048,576 Data partition (Windows/Linux) /dev/nvme0n12 B 1,050,624 214,042,623 212,992,000 Data partition (Linux) [...] Attributes: R=Required, N=No Block IO, B=Legacy BIOS Bootable, +=More bits set
IIUC these say that the partition nvme0n1p2 (which the script misidentifies as nvme0n12 is the partition table), which is the root partition of the Leap 15.0 installation, was made legacy BIOS bootable. Does this conflict with, or override, booting with EFI from the /boot (or /boot/efi) partition nvme0n1p1?
No. I am aware of the only bootloader that interprets this bit - Syslinux GPT MBR, which is legacy MBR code for disk with GPT. native EFI mode should not care about this flag. This allows in principle booting the same installation alternatively using legacy BIOS or native EFI. Linux should boot in either mode.
If this was not in the original installation, then it could only have resulted from my running grub2-mkconfig in Leap after installing TW, in order to make the latter appear in the boot menu.
grub2-mkconfig never fiddles with partition table, nor does grub2-install. Thus is result of choosing "Write generic Boot Code to MBR" and "Boot from Partition" during installation. The installer writes Syslinux GPTMBR into MBR and marks partition that contains /boot as bootable.
Was it a mistake to run grub2-mkconfig? If so, how can I repair it?
There is nothing to repair.
(Note I did not run grub2-install.)
My current plan, unless I get urgent advice to the contrary, is to reinstall TW and try to use GRUB2 for EFI.
Steve Berman
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org