Trouble with new hardware, UEFI, grub and booting Debian10

tredegar · 08-02-2020, 08:38 AM

I need some help please. The background:

My PC died. I had some backups.
I bought a Lenovo V530S. It came with windows10, so I let it boot to that.
As soon as I could, I shut down windows and fired up the UEFI interface (I am used to BIOS, but must march with the times.) The only thing I changed was the boot order, so it would boot from a DVD if one was present. I saved the changes and booted Debian 10 from a net-install CD.
I shrank the windows data partition to leave me a 180GB partition for Debian, and told the installer to put everything there, and not to touch the windows partitions. I don't want windows, but I've paid for it, and as I don't really understand this UEFI boot business, I am not sure how much of the SSD I can repartition and reformat.

Debian installed and installed grub. It did say that it could not find "any other operating systems, but if there was one (eg, windows,) that could be fixed later."

Debian 10 booted just fine, but at the grub menu I just have 2 entries Debian10 and Debian 10 safe mode, I think.

Today there was a new kernel installed. When it came to updating grub, there was an error message.
I can't remember exactly what it was (is it in a log somewhere?) it was to do with a grub problem, but I really don't want to power down this PC only to find it'll not boot Debian. I don't know how to fix a broken UEFI boot.

I thought I'd just run

Code:

root@office:~#  update-grub && grub-install /dev/sda

but before that, I thought I'd check the partitioning:

Code:

root@office:~# fdisk -l
Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Disk model: SKHynix_HFS256GD9TNG-L5B0B              
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: A25F9E0A-5749-40C9-A75A-95282CC249B4

Device             Start       End   Sectors  Size Type
/dev/       2048    534527    532480  260M EFI System
/dev/nvme0n1p2    534528    567295     32768   16M Microsoft reserved
/dev/nvme0n1p3    567296 106036045 105468750 50.3G Microsoft basic data
/dev/nvme0n1p4 498069504 500107263   2037760  995M Windows recovery environment
/dev/nvme0n1p5 106037248 498069503 392032256  187G Linux filesystem

Partition table entries are not in disk order.

And I am not a happy man!
Where is /dev/sda?
What is all this nvme0n1p* stuff? I know it relates to the type of SSD but has the naming of /dev/sd* gone the way of eth0 (which is now, so conveniently, enp0s25 )?

gdisk gives me this:

Code:

root@office:~#  gdisk -l
GPT fdisk (gdisk) version 1.0.3

Problem opening -l for reading! Error is 2.
The specified file does not exist!
root@office:~#

gparted - please see the screenshot

What I would like to achieve is
- Install / troubleshoot grub
- Boot to the new kernel
- (Optionally, have the choice to boot win10)
- Not lose the EFI stuff (which is like a BIOS, but stored on the disk? How do I back this up in case the disk fails? Do I need to do this?)

Thanks for your attention.

mrmazda · 08-02-2020, 08:56 AM

Boot to Debian, run these, and post the input/output here surrounded by code tags ( click # above the input window):

Code:

efibootmgr -v
parted -l
grep GRUB_DISABLE_OS_PROBER /etc/default/grub

Your new SSD uses a newer, faster interface for solid state storage devices that the old libata system doesn't support, NVME.

It may be that Windows doesn't appear in the boot menu because GRUB_DISABLE_OS_PROBER="yes" and needs to be changed to GRUB_DISABLE_OS_PROBER="no", then run grub-mkconfig rather than grub-install. Another possibility is you installed Debian in legacy mode rather than UEFI mode. If Windows is installed in UEFI mode, Debian must be as well for Grub to be able to boot Windows. Reinstalling Debian by booting the installation media in UEFI mode should fix that. http://blog.getreu.net/_downloads/le...-uefi-boot.pdf and https://wiki.debian.org/GrubEFIReinstall explain the alternative, reconfiguring Debian from legacy to UEFI booting mode.

tredegar · 08-02-2020, 09:17 AM

Thanks for your speedy reply!

Code:

root@office:~# efibootmgr -v
EFI variables are not supported on this system.

root@office:~# parted -l
Model: SKHynix_HFS256GD9TNG-L5B0B (nvme)
Disk /dev/nvme0n1: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Warning: failed to translate partition name
Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  274MB   273MB   fat32        EFI system partition          boot, hidden, esp
 2      274MB   290MB   16.8MB               Microsoft reserved partition  msftres
 3      290MB   54.3GB  54.0GB  ntfs         Basic data partition          msftdata
 5      54.3GB  255GB   201GB   ext4         Debian
 4      255GB   256GB   1043MB  ntfs                                       hidden, diag

root@office:~# grep GRUB_DISABLE_OS_PROBER /etc/default/grub
root@office:~#    # returns nothing

You are saying that NVME SSDs are treated differently from normal ones? Hence the strange naming?

The debian installer (unusually) did not offer me any choices when it came to installing grub, or maybe I selected "Automatic", as I am unable to answer questions about UEFI booting yet. It just did it, but it seems that grub is booting "legacy" not EFI. Though how it manages that with no /dev/sda is beyond me.

Anyway, here is some information you requested, while I go and read that PDF you linked to.

mrmazda · 08-02-2020, 10:52 AM

Quote:

Originally Posted by tredegar

Code:

# efibootmgr -v
EFI variables are not supported on this system.

This confirms Debian was installed in legacy mode.

To boot the Debian installation media in UEFI mode in order to reinstall it will probably be necessary to go into UEFI BIOS setup and disable CSM mode, so that only booting UEFI mode is possible. Then the installer will be able to install grub-efi correctly and setup booting from Windows.

NVME is a different I/O interface, so requires a different driver. Thus, the kernel creating a different device name than /dev/sdX for the new interface made perfect sense. This name "change" is little different from when HD names changed from /dev/hdX to /dev/sdX well over a decade ago to better support the SATA interface deprecating the IDE interface.

tredegar · 08-02-2020, 11:51 AM

I have been doing some more reading......
I do remember the name change from /dev/hdX to /dev/sdX and was annoyed at the time because of typing muscle-memory and old dogs don't like to learn new tricks, but I got used to it. Now I understand the name change, but resent the number of characters I have to type. [Not your problem. "Get up to date, it's 2020 tredegar!" OK, I'm trying.]

Debian is booting in legacy mode, but the disk is gpt with a valid EFI partition:

Code:

root@office:~# gdisk /dev/nvme0n1 # <-- Instead of gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/nvme0n1: 500118192 sectors, 238.5 GiB
Model: SKHynix_HFS256GD9TNG-L5B0B              
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): ******
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 500118158
Partitions will be aligned on 2048-sector boundaries
Total free space is 14111 sectors (6.9 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          534527   260.0 MiB   EF00  EFI system partition
   2          534528          567295   16.0 MiB    0C01  Microsoft reserved ...
   3          567296       106036045   50.3 GiB    0700  Basic data partition
   4       498069504       500107263   995.0 MiB   2700  Basic data partition
   5       106037248       498069503   186.9 GiB   8300  Debian

I am not sure what gdisk means when it says MBR: protective Some more research might be needed...

I think I'll back up the EFI system partition, and the 67GB of microsoft partitions to an external device, just in case. Then I'll check that booting from EFI is enabled in the non-BIOS and then I'll probably install refind (which is in the current stable Debian branch's repositories) to get things back on track. Your link to https://wiki.debian.org/GrubEFIReinstall was most helpful.

Enough for today though.
Thanks for your support.

JeremyBoden · 08-02-2020, 06:01 PM

A protective MBR means that your BIOS has a 512 byte MBR area, so that if you should run any old-style MBR tools they won't corrupt your new style UEFI partitions.

tredegar · 08-03-2020, 10:09 AM

Quote:

A protective MBR means that your BIOS has a 512 byte MBR area, so that if you should run any old-style MBR tools they won't corrupt your new style UEFI partitions.

OK, thank you.

So, I didn't need to install refind (I did try, but it did not work, the reason probably was that the efi partition was not mounted)

What I did to get it working was basically follow the debian instructions

I DLd a live dvd of 64-bit Debian 10. Burned it and left the disk in the drive.
Shutdown Debian, powered up, F1 to enter the EFI screen.

There Startup was set to Legacy 1st, EFI second.
I made changes so that it would ONLY boot with EFI. I made sure that it would look for a DVD to boot from before it looked for the SSD. Saved the changes, exited, the live CD booted.

I followed the instructions to chroot to my Debian partition.

Everything went smoothly until grub-install failed with "Can't find the EFI partition."

It turned out that although the file /boot/efi existed, Debian had not mounted the EFI partition there. I fixed this with

Code:

# mount /dev/nvme0n1p1   /boot/efi

Then grub-install and update-grub ran just fine.
Grub offered me my Debian kernel, and even windows (but I haven't used or missed that since windows98!)

Thanks for your helps!