Yes, quite right. Hold off on that until you can boot properly.
Your screens do show that you know what changes to make when you get there.
Does your BIOS give you a boot menu. Often hitting F12 during boot will bring that up, but it’s a different key on some computers. I think it is F9 on HP systems.
Yes, my BIOS does give me a boot menu if I hit F2 or hold Down ESC. But the only option I have to try to boot off USB. I tried everything. Disable/Enable fast boot Secure boot CSM, etc.
Nothing is allowing me to see Boot Options for my SSD or an option to boot from it anywhere. Not sure what to try next?
Someone in another forum suggested I try the following which I might try next?
but I recently had to fix a non-booting CentOS drive and was unable to do it by booting from a USB with a different distro. What worked was that I mounted the CentOS root filesystem, chroot’ed to it, and then did grub2-install from the chroot. I think the issue was that grub on the USB was confused by my XFS root filesystem. so it was:
mount dev/sda1 /mnt/sysimage
chroot /mnt/sysimage
grub2-install /dev/sda
If I try this would I just want to change the first line to the following? I would just use the SUSE boot USB and try this method to see if that fixes this issue.
mount dev/sda8 /mnt/sysimage
Thanks again for any other suggestions! I was also debating on trying the install again with CSM disabled in UEFI mode. I’m up for suggestions.
That would install grub2 for MBR booting. And we were trying to avoid that.
This won’t solve your problem, but will be an interesting test. Use the USB that you are booting for UEFI. When you see the boot menu, try the option “Boot from hard drive”. That’s to see if it gets you into your system.
Can you check the “pmbr_boot” flag? Some BIOS use that to decide how to boot. Google for “pmbr_boot” should give you good information on how to check it.
Hi nricket, thanks for sticking with me on this dilemma! That’s the whole problem is I can’t find boot from hard drive anywhere. It’s like it doesn’t even exist anymore.
When I hit ESC to get options to boot from I only have the following options>
UEFI: KinstonDataTravler 3.0PMAP
KingstonDatTravler 3.0PMAP
Enter Setup
When I’m in setup I see the Samsung SSD 860 EVO 500 with the Serial Number and Device Type: Hard Disk
Under the Boot Section in BIOS I have Hard Drive BBS Priorities and Boot Option Priorities. No where can I select my Harddrive and that has been the issue since this started.
On my identical working Laptop I see my Samsung SSD drive to boot from.
If I go under add boot option I can see the path to the SSD similar to this>
PCI(1F|2) \DevicePath (LONG SSD PATH INFO)
I don’t know why my non-working system is unable to see the hard drive at all aside from in the Screen under SATA Configuration?
If I go to the same area under boot I can only see the path to my USB key. I have an option to add a ‘New boot option’ but I have no idea what I would put in that to be able to allow the BIOS to see my SSD again.
I searched for “pmbr_boot” flag but not finding anything on that yet. Not sure if I should just take my laptop apart and re install the original mechanical drive that I cloned my Windows 8.1 to before getting into this problem that does not appear to have a solution.
I have attached the output of fdisk, df , fstab etc from my identical/working laptop that has Win 8.1 + Ubuntu if that helps? Thanks again!
Working system output> Notice how the UUID is a very long string of numbers. I’m almost thinking I should try your instructions again by changing the UUID in fstab options from 4032-6F74 to 01f9031f-4dc3-45f8-a77a-a217e12be63d
Because the short UUID does not look right in fstab even though that’s what it shows with lsblk. It has a longer string that looks correct. linux-1fn2:~ # blkid /dev/sda2/dev/sda2: LABEL_FATBOOT=“4032-6F74” LABEL=“4032-6F74” UUID=“PARTUUID” TYPE=“vfat” PARTLABEL=“EFI system partition” PARTUUID=“01f9031f-4dc3-45f8-a77a-a217e12be63d”
That is, I’m thinking I should change PARTUUID in blkid output for /dev/sda8 instead of the UUID.
What do you think about that?
I was thinking of flashing the BIOS with “Easy Flash” but that will probably remove any reminents of my old Win 8.1 setup.
asusubuntu@asus:~$ df -k
Filesystem 1K-blocks Used Available Use% Mounted on
udev 1938884 0 1938884 0% /dev
tmpfs 392260 1768 390492 1% /run
/dev/sda9 73561320 56143440 13658060 81% /
tmpfs 1961284 0 1961284 0% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 1961284 0 1961284 0% /sys/fs/cgroup
/dev/loop0 56192 56192 0 100% /snap/gtk-common-themes/1502
/dev/loop1 63616 63616 0 100% /snap/gtk-common-themes/1506
/dev/loop2 166656 166656 0 100% /snap/blender/36
/dev/loop3 56320 56320 0 100% /snap/core18/1705
/dev/loop4 160512 160512 0 100% /snap/gnome-3-28-1804/110
/dev/loop6 167680 167680 0 100% /snap/spotify/41
/dev/loop8 166656 166656 0 100% /snap/blender/37
/dev/loop7 118528 118528 0 100% /snap/audio-recorder/46
/dev/loop5 96128 96128 0 100% /snap/core/8935
/dev/loop10 76672 76672 0 100% /snap/audio-recorder/113
/dev/loop9 96256 96256 0 100% /snap/core/9066
/dev/loop11 56320 56320 0 100% /snap/core18/1754
/dev/loop12 111360 111360 0 100% /snap/audio-recorder/30
/dev/loop13 164096 164096 0 100% /snap/gnome-3-28-1804/116
/dev/sda1 303104 65924 237180 22% /boot/efi
tmpfs 392256 24 392232 1% /run/user/1000
asusubuntu@asus:~$ blkid /dev/sda9
/dev/sda9: UUID="262b9275-9b3a-498e-b22d-93b902395e99" TYPE="ext4" PARTUUID="44b30727-f9e1-413b-a46f-73fbd2bb541a"
asusubuntu@asus:~$
asusubuntu@asus:~$ sudo fdisk -l
Disk /dev/loop0: 54.8 MiB, 57479168 bytes, 112264 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
Disk /dev/loop1: 62.1 MiB, 65105920 bytes, 127160 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
Disk /dev/loop2: 162.8 MiB, 170643456 bytes, 333288 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
Disk /dev/loop3: 55 MiB, 57614336 bytes, 112528 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
Disk /dev/loop4: 156.7 MiB, 164290560 bytes, 320880 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
Disk /dev/loop5: 93.8 MiB, 98336768 bytes, 192064 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
Disk /dev/loop6: 163.7 MiB, 171618304 bytes, 335192 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
Disk /dev/loop7: 115.7 MiB, 121315328 bytes, 236944 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
Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 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: gpt
Disk identifier: B9E2D182-C3A4-4CB5-98D5-89C2B1A71444
Device Start End Sectors Size Type
/dev/sda1 2048 616447 614400 300M EFI System
/dev/sda2 616448 2459647 1843200 900M Windows recovery environment
/dev/sda3 2459648 2721791 262144 128M Microsoft reserved
/dev/sda4 2721792 197359615 194637824 92.8G Microsoft basic data
/dev/sda5 197359616 198076415 716800 350M Windows recovery environment
/dev/sda6 198076416 288540671 90464256 43.1G Microsoft basic data
/dev/sda7 446433280 488396799 41963520 20G Windows recovery environment
/dev/sda8 288540672 288542719 2048 1M BIOS boot
/dev/sda9 288542720 438280191 149737472 71.4G Microsoft basic data
/dev/sda10 438280192 446433279 8153088 3.9G Linux swap
Partition table entries are not in disk order.
Disk /dev/loop8: 162.8 MiB, 170643456 bytes, 333288 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
Disk /dev/loop9: 93.9 MiB, 98484224 bytes, 192352 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
Disk /dev/loop10: 74.9 MiB, 78467072 bytes, 153256 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
Disk /dev/loop11: 55 MiB, 57618432 bytes, 112536 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
Disk /dev/loop12: 108.7 MiB, 113926144 bytes, 222512 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
Disk /dev/loop13: 160.2 MiB, 167931904 bytes, 327992 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
Disk /dev/sdb: 59.9 MiB, 62783488 bytes, 122624 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: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdb1 39 122623 122585 59.9M 1 FAT12
asusubuntu@asus:~$
asusubuntu@asus:/etc$ cat fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sda9 during installation
UUID=262b9275-9b3a-498e-b22d-93b902395e99 / ext4 errors=remount-ro 0 1
# swap was on /dev/sda10 during installation
UUID=262eb7f1-cac9-4581-9802-0bb357a958ee none swap sw 0 0
UUID=B2F5-192A /boot/efi vfat defaults 0 1
asusubuntu@asus:/etc$
Go with the first of those. It should give you the boot menu for the installer.
https://nwrickert2.files.wordpress.com/2019/05/screenshot_leap151_2019-05-17_185613.png
Then pick “Boot from hard disk” from the installer menu.
This doesn’t solve your problem. But it does test UEFI booting based on what you have now setup.
Can you post the output from:
parted /dev/sda print
If I boot from the USB UEFI mode with the Leap Media and choose “Boot from hard disk” I get this error>
error: no such device: /efi/boot/fallback.efi.
I noticed this right away after the first repair attempt when I selected boot from hard disk. It was doing the same thing on the 2nd repair when I disabled CSM.
If I boot from non-UEFI USB Option I get a different error
Boot failed: please change disk and press a key to continue
ERROR: idle with IF=0 and a bunch of other code.
I rebooted with the original USB key I used for the install where grub resides on /dev/sdb1 and ran the command.
Here’s the parted output. Thanks for any ideas!
linux-1fn2:~ # parted /dev/sda printModel: ATA Samsung SSD 860 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot
Number Start End Size File system Name Flags
1 1049kB 945MB 944MB ntfs Basic data partition hidden, diag
2 945MB 1259MB 315MB fat32 EFI system partition boot, esp
3 1259MB 1394MB 134MB Microsoft reserved partition msftres, legacy_boot
4 1394MB 181GB 180GB ntfs Basic data partition msftdata
6 181GB 181GB 8389kB bios_grub
7 181GB 184GB 2147MB linux-swap(v1) swap
5 258GB 384GB 125GB ntfs Basic data partition msftdata
8 384GB 500GB 116GB btrfs
Hi
I would guess that partition 6 and the fact your 'Disk Flags` is set to pmbr_boot are the underlying cause…
I see no flag set here;
parted /dev/sda print
Model: ATA WDC WDS250G2B0B- (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Suggest you turn off and run through the test again…
parted /dev/sda disk_set off
parted /dev/sda print
I concur. The test to run, is whether your BIOS boot menu now allows UEFI booting to openSUSE (or “opensuse-secureboot”).
Excellent discovery malcolmlewis! You are correct about that flag!
Once I removed the flag and rebooted my system went right back into Windows 8.1!
I can still get to my SUSE 15.1 Leap load through the original USB as well. I would like to get SUSE working but I can’t get this to boot from the USB stick by selecting Boot From hard disk.
However, I’m 100% certain when I was messing around and hit install with the USB installation media it had a prompt that came up “starting secure boot efi is enabled” or something to that affect.
That was when I had Secure boot enabled in the BIOS. However, I don’t know if I were to install in this mode if it would mess up my Windows 8.1? I can boot into Windows 8.1 now without any USB inserted and now see it as boot media!
So, **nricket **was very accurate in determining an issue with pmbr_boot was the cause of my issue. Thanks a lot for all the help guys!!
Here’s the before and after output of parted.
Command
linux-1fn2:~ # parted /dev/sda disk_set offparted: invalid token: off
Flag to Invert? [pmbr_boot]?
New state? on/[off]? off
Information: You may need to update /etc/fstab.
After Command: > after I ran this command I see no disk flag!!
linux-1fn2:~ # parted /dev/sda printModel: ATA Samsung SSD 860 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 945MB 944MB ntfs Basic data partition hidden, diag
2 945MB 1259MB 315MB fat32 EFI system partition boot, esp
3 1259MB 1394MB 134MB Microsoft reserved partition msftres, legacy_boot
4 1394MB 181GB 180GB ntfs Basic data partition msftdata
6 181GB 181GB 8389kB bios_grub
7 181GB 184GB 2147MB linux-swap(v1) swap
5 258GB 384GB 125GB ntfs Basic data partition msftdata
8 384GB 500GB 116GB btrfs
Great. We are making progress.
I can still get to my SUSE 15.1 Leap load through the original USB as well. I would like to get SUSE working but I can’t get this to boot from the USB stick by selecting Boot From hard disk.
Then let’s get that working.
You apparently have a very finicky UEFI firmware, so we may need to work around that.
However, I’m 100% certain when I was messing around and hit install with the USB installation media it had a prompt that came up “starting secure boot efi is enabled” or something to that affect.
It probably said that secure boot support is enabled. That has to do with openSUSE boot settings rather than BIOS settings.
That was when I had Secure boot enabled in the BIOS. However, I don’t know if I were to install in this mode if it would mess up my Windows 8.1? I can boot into Windows 8.1 now without any USB inserted and now see it as boot media!
Really, there is no need to reinstall.
If you reinstall, that won’t solve your problems. You will still have the same problems, because of limitations of your UEFI firmware. So we need to find out how to work around that.
Boot into your Leap 15.1 system - whichever way works.
Then (as root)
cd /boot/efi/EFI/Boot
cp /usr/share/efi/x86_64/fallback.efi .
After that, try again with “boot from hard drive” from the USB boot menu. I think it will work. If it does, it will give you a way of booting into your system in UEFI mode. And that will be better for making further progress.
I am just wondering whether the following would do the trick:
He has pretty much done that. The “shim-install” he used calls “grub2-install”.
However, here are the problems that I am still seeing:
1: The UEFI boot install was not enough. And that seems to be due to the “pmbr_boot” flag (now fixed).
2: At one stage, the output of “efibootmgr” looked right, except that there was no entry for Windows. There was an opensuse-secureboot entry.
3: After fixing the “pmbr_boot” flag problem, it booted to Windows, even though there was no boot entry for Windows.
Either: this system is has a builtin bias toward Windows;
Or: It might boot only from what is in “\EFI\Boot” in the EFI partition (or “/boot/efi/EFI/Boot”), and ignore the NVRAM programming.
So we need to explore those possibilities, and work around them
Do you mean this one?
It is the only output in this thread I could spot.
it booted to Windows, even though there was no boot entry for Windows.
It is likely the Boot0002 entry which as I mentioned recently usually implies trying \EFI\Boot\bootx64.efi on ESP. Without -v it is impossible to say what all these entries mean (and the fact it is called “opensuse-secure” does not really mean it actually refers to openSUSE at all). What’s in a name …
For good reasons I expunged everything but what is needed:
erlangen:~ # find /boot/efi/ -type f
/boot/efi/EFI/leap-15.1/grubx64.efi
/boot/efi/EFI/manjaro/grubx64.efi
/boot/efi/EFI/arch/grubx64.efi
/boot/efi/EFI/tw-20200416/grubx64.efi
/boot/efi/EFI/tumbleweed-btrfs/grubx64.efi
erlangen:~ #
For a private PC secure boot makes no sense in my opinion. When install would not work I tried something like this:
efibootmgr --create --disk /dev/sda --part 1 --label test --loader /EFI/opensuse/grubx64.efi
The boot entry “opensuse-secureboot” is what you get by default when you run “shim-install”. You still might not be using secure-boot, as that depends on the BIOS settings.
When install would not work I tried something like this:
efibootmgr --create --disk /dev/sda --part 1 --label test --loader /EFI/opensuse/grubx64.efi
But that only adds an entry until the next boot. When the system boots, the BIOS can make changes to that.
Yes, that’s the one. Yes, I agree that Boot0002 is probably what gives Windows.
Hi Guys,
Thanks for all the valuable input! I’ve been busy but should have some time again on Sunday to try and get this dual boot working again. I really want to get Leap 15.1 Working with Win 8.1!
But, I was curious if this is accurate for EOL ?
“Leap 15.1 - is expected to be maintained until end of November 2020”
If EOL support is coming up this soon I might want to consider a newer distribution before trying to get this working. I was going to follow nrickert’s instructions here but might hold off if EOL is coming up in November. Thanks for any info on the best long term support version of SUSE.
The original plan was to release Leap 15.2 in May. That has now been delayed until July. My guess is that the EOL for 15.1 will be extended to adjust for that.
In any case, I suggest continuing with 15.1 for now. This is a useful learning experience, even if you decide to install 15.2 after a few months.
Good to know. Do you happen to know if there are any plans for an in place upgrade from 15.1 to 15.2?
It has been a pretty good learning experience albeit somewhat more complicated than most the dual boot setups I’ve done in the past with the tricky UEFI stuff.
Yes, you can do that. And it works pretty well. Yes, I have tested it.