New laptop, replaced HDD, refusing to boot

Hi folks,

I just bought a Toshiba Satellite Pro R50-B-10E, and replaced its stock 500GB HDD with a blank Seagate 1TB hybrid SSHD. I am now trying to install openSUSE 13.2 to this.

The BIOS correctly recognises the hard disk as ST1000LM014-1EJ164. BIOS version is 1.30 (as supplied), there is no more recent version available on Toshiba’s website.

Booting from a USB key works fine; I can run through the installation process as normal. (I can also boot into a live KDE environment from USB; no problem.) However, after the installation completed successfully, boot fails with “Insert system disk in drive. Press any key when ready…”.

Now, I have tried several different partitioning set-ups, and I really don’t believe this is a partitioning problem because I know what I am doing here. My original intention was to go for the current mainstream approach with GRUB2-EFI and a FAT partition for /boot/efi, then a BTRFS for /, and an XFS partition for /home. When I couldn’t get this to work, I tried instead a more legacy approach: 1GB /boot partition, rest of the disk on LVM, with a 40GB root volume and an 800GB /home volume (all ext4), with conventional GRUB2 instead of GRUB2-EFI. This didn’t work either.

(By the way, I’m not using a swap partition here because it’s an SSHD (hybrid) drive, and I don’t want it using its SSD capacity to support the swap space… I’m not trying to open that debate here and now, just including the info for partitioning completeness.)

Whatever I do, I am unable to get to a bootloader. It seems my laptop is refusing to boot from this HDD at all.

BIOS settings: changing the boot order to HDD first did not solve. I disabled an option called “Secure Boot” (“This feature checks if the bootable file on the selected boot device has a proper digital signature.”). That didn’t solve it either.

Is it possible that Toshiba locks these laptops to only boot on their original HDD, or indeed to only boot to Windows? This seems unusual, and I can’t find any trace of this on the internet.

I don’t think my Seagate drive is faulty, because: the BIOS recognises it, and I can partition and format it and install openSUSE without error. I just never get to the bootloader.

Advice??

Thanks,
K.

Hi
You disk is probably gpt format, so use UEFI, else you will need to remove gpt since mbr is protected (there is a method to use gpt), but if new install, just use gdisk to go back to a normal disk;


gdisk /dev/sda
x
z
Y
Y

That will wipe out the gpt and clear the mbr. Then use fdisk on it…

If you can do UEFI and secure boot, then I would suggest this method, so the disk needs to be gpt.

You seem to have a UEFI box (it knows about “secure boot”). So best to boot install media with UEFI, and install that way.

Traditional BIOS (non-UEFI) booting with a GPT partitioned disk probably won’t work unless you install grub in the MBR. And if you use “btrfs”, then grub probably won’t install in the MBR unless you create a BIOS Boot partition (you can google that).

I’m agreeing with Malcolm. It is best to use UEFI if possible.

People have been reporting some problems with Toshiba UEFI support. I don’t know whether those are solved. There’s a long thread from a year or two ago. If you have problems with UEFI, provide some details and we will try to help get it working.

Hi, thanks for the help so far. Unfortunately, still not working.

I re-created the GPT using gdisk as Malcolm suggested; gdisk now shows “Found valid GPT with protective MBR; using GPT”, while on the KDE live-usb. I then installed openSUSE from the live-usb environment, installation completed without error, but after rebooting I still get “Insert system disk in drive”.

When I previously attempted the “legacy” layout with ext4 partitions and no EFI, I had the GRUB2 boot code written to MBR too, and even that did not work. My preference would be UEFI secure boot, as you suggest, but at this stage any working solution is acceptable!

Hi
Boot from the live cd, then open a terminal and as root user run;


lsblk
efibootmgr -v

Lets see if you have efi entries and your disk setup.

Did you set the boot drive in the BIOS??? Sounds like the BIOS does not know to boot from the new drive

linux:/home/linux # lsblk
NAME           MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda              8:0    0 931.5G  0 disk 
├─sda1           8:1    0     1G  0 part 
└─sda2           8:2    0 930.5G  0 part 
  ├─vg0-lvhome 254:0    0   800G  0 lvm  
  └─vg0-lvroot 254:1    0    50G  0 lvm  
sdb              8:16   1  14.7G  0 disk 
├─sdb1           8:17   1     4M  0 part 
├─sdb2           8:18   1   903M  0 part /livecd
└─sdb3           8:19   1  13.9G  0 part /read-write
loop0            7:0    0 783.6M  1 loop /read-only
linux:/home/linux # efibootmgr -v
BootCurrent: 000A
Timeout: 1 seconds
BootOrder: 000A,0007,0006,0004,0003,0005,0009,0008
Boot0000* HDD1  BIOS(2,0,58).......................................................................
Boot0001* LAN1  BIOS(80,0,58).......................................................................
Boot0002* LAN1  BIOS(80,0,58).......................................................................
Boot0003* Windows Boot Manager  HD(2,200800,32000,397a0667-3b66-11e4-9366-b86b23079781)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...9................
Boot0004* Windows Boot Manager  HD(2,200800,32000,397a0667-3b66-11e4-9366-b86b23079781)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0005* HDD/SSD       ACPI(a0341d0,0)PCI(1f,2)03120a00000000000000
Boot0006* CentOS        HD(1,800,64000,b94ffc22-3ede-4c81-a61d-4f839ffa9735)File(\EFI\centos\shim.efi)
Boot0007* opensuse-secureboot   HD(1,800,201800,5d75efae-30bf-45f9-a153-7b1a08dbcc95)File(\EFI\opensuse\shim.efi)
Boot0008* LAN2  ACPI(a0341d0,0)PCI(1c,0)PCI(0,0)MAC(b86b23079781,0)IPv4(0.0.0.0:0<->0.0.0.0:0,0, 0
Boot0009* LAN1  ACPI(a0341d0,0)PCI(1c,0)PCI(0,0)MAC(b86b23079781,0)030d3c000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000
Boot000A* USB Memory    ACPI(a0341d0,0)PCI(14,0)USB(0,0)
linux:/home/linux #

I see it remembers its Toshiba factory Windows install, and an earlier attempt to install CentOS 7 (which failed in the same way as openSUSE - I just wanted to make sure it wasn’t a distribution or setup medium problem).

I can confirm that /dev/sda1 contains a FAT filesystem, and has the file EFI/opensuse/shim.efi.

I notice the linux entries start with HD(1,… and the Windows entries with HD(2,… but I don’t know the meaning of these lines, it looks to me like they identify a location on a hard disk.

If I mount /dev/sda1 on /boot/efi, and run “efibootmgr -c”, a line gets added as follows:

Boot000B* Linux HD(1,800,201800,5d75efae-30bf-45f9-a153-7b1a08dbcc95)File(\efi\linux\grub.efi)

I notice it still references HD(1,… and is similar in most respects to the previous opensuse-secure line, except it points to a non-existing folder /efi/linux, and grub.efi instead of shim.efi.

I got curious about what “shim” is, and found some interesting reading about UEFI and Windows 8 laptops:
http://www.zdnet.com/article/microsoft-to-stop-linux-older-windows-from-running-on-windows-8-pcs/
http://www.zdnet.com/article/shimming-your-way-to-linux-on-windows-8-pcs/

This gives me the impression that UEFI Secure Boot is just Microsoft’s latest attempt to prevent me from running Linux on my new laptop. (Successful attempt, thus far.) I’m wondering now: what is the merit of using UEFI Secure Boot, as opposed to disabling it in BIOS settings?

If anyone feels like explaining, then please do. But what’s more important to me is getting this thing to work. I’m really not interested in UEFI Secure Boot versus legacy MBR boot with Secure Boot disabled (the BIOS settings give me this option, but I couldn’t get it to work).

Ok, game changer:

I’ve noticed that if I select “Boot from Hard Disk” in the Live USB’s boot menu, the following messages flash up very briefly (then, the boot menu shows again):

Welcome to GRUB!
error: file `EFI/BOOT/x86_64-efi/linux.mod' not found.
error: file `EFI/BOOT/x86_64-efi/ls.mod' not found.
error: terminal `gfxterm' isn't found.

When I set the BIOS to attempt HDD boot before USB, it appears these same messages flash up very briefly (too fast to read). Anyway, it appears I have a GRUB problem, not a UEFI problem.

I can confirm that the entire folder EFI/BOOT/x86_64-efi does not exist on /dev/sda1 (/boot/efi):

linux:/boot/efi # ls -R
.:
EFI

./EFI:
boot  opensuse

./EFI/boot:
bootx64.efi  fallback.efi

./EFI/opensuse:
MokManager.efi  boot.csv  grub.cfg  grub.efi  grubx64.efi  shim.efi
linux:/boot/efi #

That grub.cfg seems to point to another grub.cfg, in /boot/grub2:

linux:/boot/efi/EFI/opensuse # cat boot.csv
shim.efi,opensuse-secureboot
linux:/boot/efi/EFI/opensuse # cat grub.cfg
set btrfs_relative_path="yes"
search --fs-uuid --set=root bf6fc774-d37b-49f6-ae6a-405746e5cdbf
set prefix=(${root})/boot/grub2
configfile $prefix/grub.cfg
linux:/boot/efi/EFI/opensuse #

Even that file /boot/grub2/grub.cfg does not, however, reference the linux.mod and ls.mod files from the error message.

As for those .mod files, they actually live in “/boot/grub2/x86_64-efi/”.

I copied that whole folder /boot/grub2/x86_64-efi/ to /boot/efi/EFI/BOOT/x86_64-efi, so that the linux.mod and ls.mod files are available at that location, but oddly the same error messages still appear when attempting to boot.

Instead, try:

(1) Make a copy of “/boot/efi/EFI/BOOT” to somewhere else. This is just for safety.
(2) Copy “/boot/efi/EFI/opensuse” to “/boot/efi/EFI/BOOT”. That is, copy the entire directory content.
(3) Look in “/boot/efi/EFI/BOOT”. If there is now a file there named “shim.efi”, then rename that to “bootx64.efi”. If there is no “shim.efi” then look for “grubx64.efi” and instead rename that to “bootx64.efi”.

As for UEFI: It really is a better way to boot systems. Unfortunately, Toshiba didn’t quite get it right.

And as for “secure-boot”: I don’t find it particularly useful. But I don’t think Microsoft was trying to lock out linux. I think they were trying to lock out software pirated version of Windows.

Thanks again for your time and your help, guys, I really appreciate this.

I did some more experimenting, and got it working with a traditional MBR. To this end, I changed two things in the BIOS settings:

  • Secure Boot: Enabled -> Disabled
  • Boot Mode: UEFI Boot -> CSM Boot (“Support booting a non UEFI-capable OS that expects a legacy BIOS interface.”)

Apparently, the installation process is aware of these settings. When I ran through the installation with the BIOS settings for secure UEFI boot, the proposed partitioning had a 156.88MiB FAT partition on /boot/efi, and the bootloader was GRUB2-EFI. When I run the installation with settings for CSM (legacy) boot, a conventional GRUB2 set-up is proposed. If I then try to manually create a GRUB2-EFI set-up (while the BIOS settings are for CSM boot), I get the warning: “Unsupported combination of hardware platform x86_64 and bootloader grub2-efi”. I am allowed to continue installing despite this warning, but the resulting installation does not work.

So, here goes my final attempt to get this working with UEFI: I set the BIOS for secure UEFI boot, and run the installation from scratch. Feeling less than courageous about XFS and Btrfs, I fall back to the safety and comfort of an LVM/ext4 layout as follows:

/dev/sda1:        1GiB  ext4           /boot
/dev/sda2:        1GiB  fat            /boot/efi
/dev/sda3:              LVM partition
  -> vg0                volume group
    -> lvroot:   40GiB  ext4           /
    -> lvhome:  800GiB  ext4           /home

By the way: if I select Btrfs for the root partition instead, I get a warning that says: “Warning: Some subvolumes of the root filesystem are shadowed by mount points of other filesystem. This could lead to problems. Really use this setup?”. Even if I go into “Subvolume handling” for the root volume, and get rid of the subvolumes boot/grub2/i386-pc and boot/grub2/x86_64-efi, I still keep getting that warning. Since I don’t quite understand how Btrfs works and what to make of this warning, and don’t have any explicit need for Btrfs here, I’m happy enough to stick with ext4.

This installation completes without error, but then I get, as before: “Insert system disk in drive. Press any key when ready…”.
So I boot up the live usb, select “Boot from Hard Disk”, and now I only get:

Welcome to GRUB!
error: terminal `gfxterm' isn't found.

So, apparently the switch from Btrfs to ext4 (thus getting rid of the “shadowed subvolumes” problem) resolved the issue of GRUB not finding the linux.mod and ls.mod files. This is progress… but, it’s still not quite there.

Any suggestions on how to cross this final hurdle?

When I’ve done (1) and (2), I have in /boot/efi/EFI/BOOT the files shim.efi and bootx64.efi, which are identical (in size and sha1sum), and a file grubx64.efi which is a lot smaller (119KB vs 1286KB). Based on “efibootmgr -v” output, it appears that “shim.efi” is currently invoked at boot; the result remains the same as before.

Mixing mode on the same disk is not a great idea some BIOS can handle it some can’t So for dual boot both OS should be installed in the same mode. Install in MBR then turning arond and installing in EFI can cause problems since GPT and MBR formating use different tables and table location you can have bothe and that can confuse things where one program see a MBR formatted disk another sees a GPT formatted disk. You need to wipe and correct the first track to make things right. So it is not a great idea to randomly try stuff

Gogalthorp, I am indeed wiping and re-formatting the disk between attempts. In any case, my weekend is running out and I need this laptop to be working tomorrow, so I’m going with the MBR solution now.

If you use Windows mainly for business ( ie no high end gaming) You might consider running Windows in a Virtual Machine. That is what I do and have done for years. It truly simplifies your life. I still get a kick seeing Windows boot in a Window on my desktop rotfl!

Which partition is marked Active or Boot?:wink: