[opensuse] Lacking a bootable partition?
Hello all (and hopefully Andrei), While reading the recent thread (... Zypper dup renders 15.1 to 15.2...) I got curious about my own system - which had a reinstall (15.0) a few months ago, which went...poorly. It took several installs and boot attempts to get the thing to come up (which is really odd because it was a reinstall of 15.0 on top of the same 15.0 on seemingly perfectly good hardware) Now I see that perhaps my /boot/efi is not configured correctly? bootinfoscript doesn't even find/describe the disk where /boot/efi lives, (/dev/nvme0n1) for some reason. The guts of my system is $ df -h Filesystem Size Used Avail Use% Mounted on /dev/nvme0n1p2 233G 9.3G 212G 5% / /dev/nvme0n1p1 500M 5.1M 495M 2% /boot/efi /dev/sdb1 458G 97G 338G 23% /home There are a few data/backup/etc. disks attached, I ignore these for simplicity $ blkid /dev/nvme0n1* /dev/nvme0n1: PTUUID="c2d48243-da0e-456d-bd55-d3bee176dbec" PTTYPE="gpt" /dev/nvme0n1p1: SEC_TYPE="msdos" UUID="5591-235C" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="f95c0606-ecaa-44af-8fd0-51f9980f26a9" /dev/nvme0n1p2: UUID="65da4abd-8d32-4a12-a6d3-5f237343714d" TYPE="ext4" PARTLABEL="primary" PARTUUID="0c505856-c975-4f34-9119-7a9e70d78b2c" $ sudo fdisk -l /dev/nvme0n1* Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 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: C2D48243-DA0E-456D-BD55-D3BEE176DBEC Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data /dev/nvme0n1p2 3147776 500117503 496969728 237G Linux filesystem Disk /dev/nvme0n1p1: 500 MiB, 524288000 bytes, 1024000 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 Disk /dev/nvme0n1p2: 237 GiB, 254448500736 bytes, 496969728 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 $ ls -al /boot/efi/EFI/opensuse/ total 3600 drwxr-xr-x 3 root root 8192 Feb 14 16:29 . drwxr-xr-x 4 root root 8192 Feb 14 11:07 .. -rwxr-xr-x 1 root root 58 Feb 14 11:07 boot.csv drwxr-xr-x 2 root root 8192 Feb 14 16:29 fw -rwxr-xr-x 1 root root 70464 Feb 14 16:29 fwupx64.efi -rwxr-xr-x 1 root root 155 Feb 14 11:07 grub.cfg -rwxr-xr-x 1 root root 1060704 Feb 14 11:07 grub.efi -rwxr-xr-x 1 root root 123904 Feb 14 11:07 grubx64.efi -rwxr-xr-x 1 root root 1158688 Feb 14 11:07 MokManager.efi -rwxr-xr-x 1 root root 1208968 Feb 14 11:07 shim.efi (that `fw` directory is empty) For comparison, a simple one-disk system I have (also on 15.0) which "makes sense"
sudo blkid /dev/sda1: LABEL="ESP" UUID="4A08-2713" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="bd98a04b-2b82-4a57-9652-75c0189aaf2a" /dev/sda2: UUID="b34af9ea-c375-4b96-9adb-5fc88bcdf2f1" TYPE="swap" PARTUUID="be766a1e-c3de-4283-b18d-0fa489b74b1f" /dev/sda3: UUID="7716718f-9d03-470a-8a21-11e2aba10247" TYPE="ext4" PARTUUID="45b0ca46-3e31-4dbe-8475-bfb53ecb119c"
sudo fdisk -l /dev/sda [sudo] password for root: Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 2E601350-1A64-4CD5-9D45-A9E7BB0C428F
Device Start End Sectors Size Type /dev/sda1 2048 1333247 1331200 650M EFI System /dev/sda2 1333248 5527551 4194304 2G Linux swap /dev/sda3 5527552 1953525134 1947997583 928.9G Linux filesystem
ls -al /boot/efi/EFI/opensuse/ total 3492 drwxr-xr-x 2 root root 4096 Dec 3 2018 . drwxr-xr-x 6 root root 4096 Dec 3 2018 .. -rwxr-xr-x 1 root root 58 Dec 3 2018 boot.csv -rwxr-xr-x 1 root root 155 Dec 3 2018 grub.cfg -rwxr-xr-x 1 root root 1060704 Dec 3 2018 grub.efi -rwxr-xr-x 1 root root 123904 Dec 3 2018 grubx64.efi -rwxr-xr-x 1 root root 1158688 Dec 3 2018 MokManager.efi -rwxr-xr-x 1 root root 1208968 Dec 3 2018 shim.efi
I note that the md5sums of the files in the two machines /boot/efi/EFI/opensuse are all different (not sure if that means anything or not). So, is this a case of "boot from rescue disk and run various grub commands to re-write /boot/efi and all should be well" or ...? Many thanks from a man afraid to reboot his main computer. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 28/06/2020 13.58, Michael Fischer wrote:
Hello all (and hopefully Andrei),
While reading the recent thread (... Zypper dup renders 15.1 to 15.2...) I got curious about my own system - which had a reinstall (15.0) a few months ago, which went...poorly. It took several installs and boot attempts to get the thing to come up (which is really odd because it was a reinstall of 15.0 on top of the same 15.0 on seemingly perfectly good hardware)
Now I see that perhaps my /boot/efi is not configured correctly?
bootinfoscript doesn't even find/describe the disk where /boot/efi lives, (/dev/nvme0n1) for some reason.
Unfortunately, the script doesn't study /dev/nvme media, I understand.
The guts of my system is
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/nvme0n1p2 233G 9.3G 212G 5% / /dev/nvme0n1p1 500M 5.1M 495M 2% /boot/efi /dev/sdb1 458G 97G 338G 23% /home
There are a few data/backup/etc. disks attached, I ignore these for simplicity
$ blkid /dev/nvme0n1* /dev/nvme0n1: PTUUID="c2d48243-da0e-456d-bd55-d3bee176dbec" PTTYPE="gpt" /dev/nvme0n1p1: SEC_TYPE="msdos" UUID="5591-235C" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="f95c0606-ecaa-44af-8fd0-51f9980f26a9" /dev/nvme0n1p2: UUID="65da4abd-8d32-4a12-a6d3-5f237343714d" TYPE="ext4" PARTLABEL="primary" PARTUUID="0c505856-c975-4f34-9119-7a9e70d78b2c"
$ sudo fdisk -l /dev/nvme0n1*
You are calling fdisk on partitions. Instead, run fdisk -l /dev/nvme0n1 I don't know how a second nvme disk would be named (I only have one).
Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 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: C2D48243-DA0E-456D-BD55-D3BEE176DBEC
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data /dev/nvme0n1p2 3147776 500117503 496969728 237G Linux filesystem
Disk /dev/nvme0n1p1: 500 MiB, 524288000 bytes, 1024000 sectors
partition 1, ignore.
Disk /dev/nvme0n1p2: 237 GiB, 254448500736 bytes, 496969728 sectors
partition 2, ignore.
$ ls -al /boot/efi/EFI/opensuse/ total 3600 drwxr-xr-x 3 root root 8192 Feb 14 16:29 . drwxr-xr-x 4 root root 8192 Feb 14 11:07 .. -rwxr-xr-x 1 root root 58 Feb 14 11:07 boot.csv drwxr-xr-x 2 root root 8192 Feb 14 16:29 fw -rwxr-xr-x 1 root root 70464 Feb 14 16:29 fwupx64.efi -rwxr-xr-x 1 root root 155 Feb 14 11:07 grub.cfg -rwxr-xr-x 1 root root 1060704 Feb 14 11:07 grub.efi -rwxr-xr-x 1 root root 123904 Feb 14 11:07 grubx64.efi -rwxr-xr-x 1 root root 1158688 Feb 14 11:07 MokManager.efi -rwxr-xr-x 1 root root 1208968 Feb 14 11:07 shim.efi
(that `fw` directory is empty)
You could do, instead: tree -apugh --si /boot/efi
So, is this a case of "boot from rescue disk and run various grub commands to re-write /boot/efi and all should be well" or ...?
The problem that was reported was with an MBR boot. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sun, Jun 28, Carlos E. R. wrote:
On 28/06/2020 13.58, Michael Fischer wrote:
You are calling fdisk on partitions. Instead, run
fdisk -l /dev/nvme0n1
Well, that information was already included, but if you like: $ fdisk -l /dev/nvme0n1 Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 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: C2D48243-DA0E-456D-BD55-D3BEE176DBEC Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data /dev/nvme0n1p2 3147776 500117503 496969728 237G Linux filesystem /dev/nvme0n1p1 -> /boot/efi /dev/nvme0n1p2 -> /
You could do, instead:
tree -apugh --si /boot/efi
$ tree -apugh --si /boot/efi/ /boot/efi/ └── [drwxr-xr-x root root 8.2k] EFI ├── [drwxr-xr-x root root 8.2k] boot │ ├── [-rwxr-xr-x root root 1.2M] bootx64.efi │ └── [-rwxr-xr-x root root 359k] fallback.efi └── [drwxr-xr-x root root 8.2k] opensuse ├── [-rwxr-xr-x root root 58] boot.csv ├── [drwxr-xr-x root root 8.2k] fw ├── [-rwxr-xr-x root root 70k] fwupx64.efi ├── [-rwxr-xr-x root root 155] grub.cfg ├── [-rwxr-xr-x root root 1.1M] grub.efi ├── [-rwxr-xr-x root root 124k] grubx64.efi ├── [-rwxr-xr-x root root 1.2M] MokManager.efi └── [-rwxr-xr-x root root 1.2M] shim.efi
So, is this a case of "boot from rescue disk and run various grub commands to re-write /boot/efi and all should be well" or ...?
The problem that was reported was with an MBR boot.
You mean, in the previous thread? And.. MBR boots and /boot/efi are mutually exclusive? (sorry, not up on these matters). Still, I am bothered by the differnces between the two systems: /dev/nvme0n1p1: SEC_TYPE="msdos" UUID="5591-235C" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="f95c0606-ecaa-44af-8fd0-51f9980f26a9 /dev/sda1: LABEL="ESP" UUID="4A08-2713" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="bb-2b82-4a57-9652-75c0189aaf2a" Can the LABEL aspect here really screw things up? Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Michael Fischer composed on 2020-06-28 10:26 (UTC-0400):
Can the LABEL aspect here really screw things up?
No! LABELs are set by humans for humans, unlike UUIDs. A filesystem can have any label an admin chooses, or no label. This human for native filesystems uses only LABELs, never UUIDs: # grep LABEL /etc/fstab LABEL=swap05 swap swap defaults 0 0 LABEL=root07 /disk/1 ext4 noatime,noauto 0 0 LABEL=root08 / ext4 noatime 1 1 LABEL=root09 /disk/3 ext4 noatime,noauto 0 0 LABEL=root10 /disk/4 ext4 noatime,noauto 0 0 LABEL=root11 /disk/5 ext4 noatime,noauto 0 0 LABEL=md1srv /srv ext4 noatime,acl,nofail 0 0 LABEL=md2hom /home ext4 noatime,acl,nofail 0 0 # grep LABEL /boot/grub/menu.lst kernel /boot/vmlinuz showopts root=LABEL=root08... kernel /boot/vmlinuz-cur showopts root=LABEL=root08... kernel /boot/vmlinuz-prv showopts root=LABEL=root08... kernel /boot/vmlinuz-prv2 showopts root=LABEL=root08... # -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 28/06/2020 16.26, Michael Fischer wrote:
On Sun, Jun 28, Carlos E. R. wrote:
On 28/06/2020 13.58, Michael Fischer wrote:
You are calling fdisk on partitions. Instead, run
fdisk -l /dev/nvme0n1
Well, that information was already included, but if you like:
Sorry, I should have said "next time" :-)
$ fdisk -l /dev/nvme0n1 Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 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: C2D48243-DA0E-456D-BD55-D3BEE176DBEC
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data /dev/nvme0n1p2 3147776 500117503 496969728 237G Linux filesystem
/dev/nvme0n1p1 -> /boot/efi /dev/nvme0n1p2 -> /
You could do, instead:
tree -apugh --si /boot/efi
$ tree -apugh --si /boot/efi/ /boot/efi/ └── [drwxr-xr-x root root 8.2k] EFI ├── [drwxr-xr-x root root 8.2k] boot │ ├── [-rwxr-xr-x root root 1.2M] bootx64.efi │ └── [-rwxr-xr-x root root 359k] fallback.efi └── [drwxr-xr-x root root 8.2k] opensuse ├── [-rwxr-xr-x root root 58] boot.csv ├── [drwxr-xr-x root root 8.2k] fw ├── [-rwxr-xr-x root root 70k] fwupx64.efi ├── [-rwxr-xr-x root root 155] grub.cfg ├── [-rwxr-xr-x root root 1.1M] grub.efi ├── [-rwxr-xr-x root root 124k] grubx64.efi ├── [-rwxr-xr-x root root 1.2M] MokManager.efi └── [-rwxr-xr-x root root 1.2M] shim.efi
Looks normal to me. cer@Telcontar:~> tree -apugh --si /boot/efi /boot/efi └── [drwxr-xr-x root root 8.2k] EFI ├── [drwxr-xr-x root root 8.2k] auxiliary │ ├── [-rwxr-xr-x root root 1.2M] MokManager.efi │ ├── [-rwxr-xr-x root root 60] boot.csv │ ├── [-rwxr-xr-x root root 155] grub.cfg │ ├── [-rwxr-xr-x root root 1.1M] grub.efi │ ├── [-rwxr-xr-x root root 124k] grubx64.efi │ └── [-rwxr-xr-x root root 1.2M] shim.efi ├── [drwxr-xr-x root root 8.2k] boot │ ├── [-rwxr-xr-x root root 1.2M] MokManager.efi │ ├── [-rwxr-xr-x root root 1.2M] bootx64.efi │ ├── [-rwxr-xr-x root root 359k] fallback.efi │ ├── [-rwxr-xr-x root root 150] grub.cfg │ └── [-rwxr-xr-x root root 1.1M] grub.efi ├── [drwxr-xr-x root root 8.2k] main_opensuse │ ├── [-rwxr-xr-x root root 1.2M] MokManager.efi │ ├── [-rwxr-xr-x root root 68] boot.csv │ ├── [-rwxr-xr-x root root 150] grub.cfg │ ├── [-rwxr-xr-x root root 1.1M] grub.efi │ ├── [-rwxr-xr-x root root 124k] grubx64.efi │ └── [-rwxr-xr-x root root 1.2M] shim.efi └── [drwxr-xr-x root root 8.2k] opensuse ├── [-rwxr-xr-x root root 1.2M] MokManager.efi ├── [-rwxr-xr-x root root 58] boot.csv ├── [-rwxr-xr-x root root 155] grub.cfg ├── [-rwxr-xr-x root root 1.1M] grub.efi ├── [-rwxr-xr-x root root 124k] grubx64.efi └── [-rwxr-xr-x root root 1.2M] shim.efi 5 directories, 23 files cer@Telcontar:~>
So, is this a case of "boot from rescue disk and run various grub commands to re-write /boot/efi and all should be well" or ...?
The problem that was reported was with an MBR boot.
You mean, in the previous thread?
And.. MBR boots and /boot/efi are mutually exclusive? (sorry, not up on these matters).
Not exactly, you might install both (I'm not sure). But you can not /use/ both in a single session.
Still, I am bothered by the differnces between the two systems:
/dev/nvme0n1p1: SEC_TYPE="msdos" UUID="5591-235C" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="f95c0606-ecaa-44af-8fd0-51f9980f26a9
/dev/sda1: LABEL="ESP" UUID="4A08-2713" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="bb-2b82-4a57-9652-75c0189aaf2a"
Can the LABEL aspect here really screw things up?
No, the label is indifferent. It goes by some flag or type I don't remember the name. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Le 28/06/2020 à 13:58, Michael Fischer a écrit :
bootinfoscript doesn't even find/describe the disk where /boot/efi lives, (/dev/nvme0n1) for some reason.
the only thing I know is that nvme can have problem on bios level. Was this disk on the computer from the beginning? thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Jun 28, jdd@dodin.org wrote:
Le 28/06/2020 à 13:58, Michael Fischer a écrit :
bootinfoscript doesn't even find/describe the disk where /boot/efi lives, (/dev/nvme0n1) for some reason.
the only thing I know is that nvme can have problem on bios level. Was this disk on the computer from the beginning?
Yep. Shipped that way from dell. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Michael Fischer composed on 2020-06-28 07:58 (UTC-0400):
Now I see that perhaps my /boot/efi is not configured correctly?
bootinfoscript doesn't even find/describe the disk where /boot/efi lives, (/dev/nvme0n1) for some reason.
IIRC, Andrei reported that bootinfoscript requires work, due to reasons not under his control, that he cannot do to properly support nvme. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
28.06.2020 14:58, Michael Fischer пишет:
Hello all (and hopefully Andrei),
While reading the recent thread (... Zypper dup renders 15.1 to 15.2...) I got curious about my own system - which had a reinstall (15.0) a few months ago, which went...poorly. It took several installs and boot attempts to get the thing to come up (which is really odd because it was a reinstall of 15.0 on top of the same 15.0 on seemingly perfectly good hardware)
Now I see that perhaps my /boot/efi is not configured correctly?
Yes.
bootinfoscript doesn't even find/describe the disk where /boot/efi lives, (/dev/nvme0n1) for some reason.
The guts of my system is
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/nvme0n1p2 233G 9.3G 212G 5% / /dev/nvme0n1p1 500M 5.1M 495M 2% /boot/efi /dev/sdb1 458G 97G 338G 23% /home
There are a few data/backup/etc. disks attached, I ignore these for simplicity
$ blkid /dev/nvme0n1* /dev/nvme0n1: PTUUID="c2d48243-da0e-456d-bd55-d3bee176dbec" PTTYPE="gpt" /dev/nvme0n1p1: SEC_TYPE="msdos" UUID="5591-235C" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="f95c0606-ecaa-44af-8fd0-51f9980f26a9" /dev/nvme0n1p2: UUID="65da4abd-8d32-4a12-a6d3-5f237343714d" TYPE="ext4" PARTLABEL="primary" PARTUUID="0c505856-c975-4f34-9119-7a9e70d78b2c"
$ sudo fdisk -l /dev/nvme0n1* Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 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: C2D48243-DA0E-456D-BD55-D3BEE176DBEC
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data
The "type" of ESP is supposed to be "EFI System". Anything else is up to firmware implementation. Explicit firmware boot entries that point to this partition will likely work. "Boot from hard disk" in BIOS boot menu selection (exact name varies between vendors) may not be offered at all. Also os-prober and other operating systems may fail to find ESP. I would change type to "EFI System" just to be sure.
/dev/nvme0n1p2 3147776 500117503 496969728 237G Linux filesystem
Disk /dev/nvme0n1p1: 500 MiB, 524288000 bytes, 1024000 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
Disk /dev/nvme0n1p2: 237 GiB, 254448500736 bytes, 496969728 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
$ ls -al /boot/efi/EFI/opensuse/ total 3600 drwxr-xr-x 3 root root 8192 Feb 14 16:29 . drwxr-xr-x 4 root root 8192 Feb 14 11:07 .. -rwxr-xr-x 1 root root 58 Feb 14 11:07 boot.csv drwxr-xr-x 2 root root 8192 Feb 14 16:29 fw -rwxr-xr-x 1 root root 70464 Feb 14 16:29 fwupx64.efi -rwxr-xr-x 1 root root 155 Feb 14 11:07 grub.cfg -rwxr-xr-x 1 root root 1060704 Feb 14 11:07 grub.efi -rwxr-xr-x 1 root root 123904 Feb 14 11:07 grubx64.efi -rwxr-xr-x 1 root root 1158688 Feb 14 11:07 MokManager.efi -rwxr-xr-x 1 root root 1208968 Feb 14 11:07 shim.efi
(that `fw` directory is empty)
For comparison, a simple one-disk system I have (also on 15.0) which "makes sense"
sudo blkid /dev/sda1: LABEL="ESP" UUID="4A08-2713" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="bd98a04b-2b82-4a57-9652-75c0189aaf2a" /dev/sda2: UUID="b34af9ea-c375-4b96-9adb-5fc88bcdf2f1" TYPE="swap" PARTUUID="be766a1e-c3de-4283-b18d-0fa489b74b1f" /dev/sda3: UUID="7716718f-9d03-470a-8a21-11e2aba10247" TYPE="ext4" PARTUUID="45b0ca46-3e31-4dbe-8475-bfb53ecb119c"
sudo fdisk -l /dev/sda [sudo] password for root: Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 2E601350-1A64-4CD5-9D45-A9E7BB0C428F
Device Start End Sectors Size Type /dev/sda1 2048 1333247 1331200 650M EFI System /dev/sda2 1333248 5527551 4194304 2G Linux swap /dev/sda3 5527552 1953525134 1947997583 928.9G Linux filesystem
ls -al /boot/efi/EFI/opensuse/ total 3492 drwxr-xr-x 2 root root 4096 Dec 3 2018 . drwxr-xr-x 6 root root 4096 Dec 3 2018 .. -rwxr-xr-x 1 root root 58 Dec 3 2018 boot.csv -rwxr-xr-x 1 root root 155 Dec 3 2018 grub.cfg -rwxr-xr-x 1 root root 1060704 Dec 3 2018 grub.efi -rwxr-xr-x 1 root root 123904 Dec 3 2018 grubx64.efi -rwxr-xr-x 1 root root 1158688 Dec 3 2018 MokManager.efi -rwxr-xr-x 1 root root 1208968 Dec 3 2018 shim.efi
I note that the md5sums of the files in the two machines /boot/efi/EFI/opensuse are all different (not sure if that means anything or not).
So, is this a case of "boot from rescue disk and run various grub commands to re-write /boot/efi and all should be well" or ...?
Many thanks from a man afraid to reboot his main computer.
Michael
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 28/06/2020 20.17, Andrei Borzenkov wrote:
28.06.2020 14:58, Michael Fischer пишет:
Hello all (and hopefully Andrei),
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data
The "type" of ESP is supposed to be "EFI System". Anything else is up to firmware implementation. Explicit firmware boot entries that point to this partition will likely work. "Boot from hard disk" in BIOS boot menu selection (exact name varies between vendors) may not be offered at all.
Also os-prober and other operating systems may fail to find ESP.
I would change type to "EFI System" just to be sure.
Do you know which field in lsblk output prints that? I can't find it. Telcontar:~ # lsblk --help Usage: lsblk [options] [<device> ...] ... Available output columns: NAME device name KNAME internal kernel device name PATH path to the device node MAJ:MIN major:minor device number FSAVAIL filesystem size available FSSIZE filesystem size FSTYPE filesystem type FSUSED filesystem size used FSUSE% filesystem use percentage MOUNTPOINT where the device is mounted LABEL filesystem LABEL UUID filesystem UUID PTUUID partition table identifier (usually UUID) PTTYPE partition table type PARTTYPE partition type UUID PARTLABEL partition LABEL PARTUUID partition UUID PARTFLAGS partition flags RA read-ahead of the device RO read-only device RM removable device HOTPLUG removable or hotplug device (usb, pcmcia, ...) MODEL device identifier SERIAL disk serial number SIZE size of the device STATE state of the device OWNER user name GROUP group name MODE device node permissions ALIGNMENT alignment offset MIN-IO minimum I/O size OPT-IO optimal I/O size PHY-SEC physical sector size LOG-SEC logical sector size ROTA rotational device SCHED I/O scheduler name RQ-SIZE request queue size TYPE device type DISC-ALN discard alignment offset DISC-GRAN discard granularity DISC-MAX discard max bytes DISC-ZERO discard zeroes data WSAME write same max bytes WWN unique storage identifier RAND adds randomness PKNAME internal parent kernel device name HCTL Host:Channel:Target:Lun for SCSI TRAN device transport type SUBSYSTEMS de-duplicated chain of subsystems REV device revision VENDOR device vendor ZONED zone model For more details see lsblk(8). Telcontar:~ # For instance: Telcontar:~ # lsblk --output NAME,KNAME,RA,RM,RO,SIZE,TYPE,FSTYPE,LABEL,PARTLABEL,PTTYPE,FSTYPE,MOUNTPOINT,UUID,PARTUUID,WWN,MODEL,ALIGNMENT /dev/nvme0n1 NAME KNAME RA RM RO SIZE TYPE FSTYPE LABEL PARTLABEL PTTYPE FSTYPE MOUNTPOINT UUID PARTUUID WWN MODEL ALIGNMENT nvme0n1 nvme0n1 512 0 0 465.8G disk gpt Samsung SSD 970 EVO Plus 500 0 ├─nvme0n1p1 nvme0n1p1 512 0 0 500M part vfat EFI EFI vfat /boot/efi 1726-BDB2 800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8 0 ├─nvme0n1p2 nvme0n1p2 512 0 0 100G part swap nvme-swap nvme-swap swap [SWAP] 7f9467db-113f-4ca5-867c-85113ce94da9 3d186ef5-2041-4a47-9576-9ae9a49d5097 0 ├─nvme0n1p3 nvme0n1p3 512 0 0 30G part ext4 Auxiliary Auxiliary ext4 f0b68654-4d7f-4ff8-b68c-117e85bb5e7f 51be098c-35bc-44fa-8899-e78adfacf300 0 ├─nvme0n1p4 nvme0n1p4 512 0 0 1G part ext2 nvme-boot nvme-boot dos ext2 /boot a977c5c3-259f-4df6-80e4-9f21a1ae96f5 5f623dd4-a315-bb4a-8bcd-4b8f5e83b4b0 0 └─nvme0n1p5 nvme0n1p5 512 0 0 150G part ext4 nvme-main nvme-main ext4 / ac173013-18ad-4c4e-921e-fd2ecfb56495 bcc5e45e-cdae-264c-8a32-8383a60ab62f 0 Telcontar:~ # I'm not getting the correct field to identify the EFI partition. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
28.06.2020 21:27, Carlos E. R. пишет:
On 28/06/2020 20.17, Andrei Borzenkov wrote:
28.06.2020 14:58, Michael Fischer пишет:
Hello all (and hopefully Andrei),
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data
The "type" of ESP is supposed to be "EFI System". Anything else is up to firmware implementation. Explicit firmware boot entries that point to this partition will likely work. "Boot from hard disk" in BIOS boot menu selection (exact name varies between vendors) may not be offered at all.
Also os-prober and other operating systems may fail to find ESP.
I would change type to "EFI System" just to be sure.
Do you know which field in lsblk output prints that? I can't find it.
Telcontar:~ # lsblk --help
Usage: lsblk [options] [<device> ...]
...
Available output columns: ... PARTTYPE partition type UUID
This one. ESP is C12A7328-F81F-11D2-BA4B-00A0C93EC93B
On 28/06/2020 20.46, Andrei Borzenkov wrote:
28.06.2020 21:27, Carlos E. R. пишет:
On 28/06/2020 20.17, Andrei Borzenkov wrote:
28.06.2020 14:58, Michael Fischer пишет:
Hello all (and hopefully Andrei),
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data
The "type" of ESP is supposed to be "EFI System". Anything else is up to firmware implementation. Explicit firmware boot entries that point to this partition will likely work. "Boot from hard disk" in BIOS boot menu selection (exact name varies between vendors) may not be offered at all.
Also os-prober and other operating systems may fail to find ESP.
I would change type to "EFI System" just to be sure.
Do you know which field in lsblk output prints that? I can't find it.
Telcontar:~ # lsblk --help
Usage: lsblk [options] [<device> ...]
...
Available output columns: ... PARTTYPE partition type UUID
This one. ESP is C12A7328-F81F-11D2-BA4B-00A0C93EC93B
Oh. Not human readable output, I see. Couldn't they choose an uuid of 0 or 1, or something nice when they invented it? :-D -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sun, 28 Jun 2020 20:50:15 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 28/06/2020 20.46, Andrei Borzenkov wrote:
28.06.2020 21:27, Carlos E. R. пишет:
On 28/06/2020 20.17, Andrei Borzenkov wrote:
28.06.2020 14:58, Michael Fischer пишет:
Hello all (and hopefully Andrei),
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data
The "type" of ESP is supposed to be "EFI System". Anything else is up to firmware implementation. Explicit firmware boot entries that point to this partition will likely work. "Boot from hard disk" in BIOS boot menu selection (exact name varies between vendors) may not be offered at all.
Also os-prober and other operating systems may fail to find ESP.
I would change type to "EFI System" just to be sure.
Do you know which field in lsblk output prints that? I can't find it.
Telcontar:~ # lsblk --help
Usage: lsblk [options] [<device> ...]
...
Available output columns: ... PARTTYPE partition type UUID
This one. ESP is C12A7328-F81F-11D2-BA4B-00A0C93EC93B
Oh. Not human readable output, I see.
Couldn't they choose an uuid of 0 or 1, or something nice when they invented it? :-D
It was nice in the fdisk -l output. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 28/06/2020 21.46, Dave Howorth wrote:
On Sun, 28 Jun 2020 20:50:15 +0200 "Carlos E. R." <> wrote:
On 28/06/2020 20.46, Andrei Borzenkov wrote:
28.06.2020 21:27, Carlos E. R. пишет:
Do you know which field in lsblk output prints that? I can't find it.
Telcontar:~ # lsblk --help
Usage: lsblk [options] [<device> ...]
...
Available output columns: ... PARTTYPE partition type UUID
This one. ESP is C12A7328-F81F-11D2-BA4B-00A0C93EC93B
Oh. Not human readable output, I see.
Couldn't they choose an uuid of 0 or 1, or something nice when they invented it? :-D
It was nice in the fdisk -l output.
Not what I mean. That is a translation, a table lookup. I mean that the number they selected could have been nice itself. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sun, Jun 28, Andrei Borzenkov wrote:
28.06.2020 14:58, Michael Fischer пишет:
Hello all (and hopefully Andrei),
While reading the recent thread (... Zypper dup renders 15.1 to 15.2...) I got curious about my own system - which had a reinstall (15.0) a few months ago, which went...poorly. It took several installs and boot attempts to get the thing to come up (which is really odd because it was a reinstall of 15.0 on top of the same 15.0 on seemingly perfectly good hardware)
Now I see that perhaps my /boot/efi is not configured correctly?
Yes.
$ sudo fdisk -l /dev/nvme0n1* Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 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: C2D48243-DA0E-456D-BD55-D3BEE176DBEC
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data
The "type" of ESP is supposed to be "EFI System". Anything else is up to firmware implementation. Explicit firmware boot entries that point to this partition will likely work. "Boot from hard disk" in BIOS boot menu selection (exact name varies between vendors) may not be offered at all.
Also os-prober and other operating systems may fail to find ESP.
I would change type to "EFI System" just to be sure.
Thank you. I suspected as much. What are the commands I would want to use for this (these?) operations? /dev/nvme0n1p1: SEC_TYPE="msdos" UUID="5591-235C" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="f95c0606-ecaa-44af-8fd0-51f9980f26a9" Seems I want that to show `LABEL="ESP"` when I'm done. Also, that `SEC_TYPE="msdos"` probably wants to go away? Much appreciated. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Jun 28, Michael Fischer wrote:
On Sun, Jun 28, Andrei Borzenkov wrote:
The "type" of ESP is supposed to be "EFI System". Anything else is up to firmware implementation. Explicit firmware boot entries that point to this partition will likely work. "Boot from hard disk" in BIOS boot menu selection (exact name varies between vendors) may not be offered at all.
Also os-prober and other operating systems may fail to find ESP.
I would change type to "EFI System" just to be sure.
Thank you. I suspected as much. What are the commands I would want to use for this (these?) operations?
/dev/nvme0n1p1: SEC_TYPE="msdos" UUID="5591-235C" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="f95c0606-ecaa-44af-8fd0-51f9980f26a9"
Seems I want that to show `LABEL="ESP"` when I'm done. Also, that `SEC_TYPE="msdos"` probably wants to go away?
A little quick digging on my own made me wonder if ``` gdisk /dev/nvme0n1p1 t ef00 w ``` is the routine I want here (unsure if that is "legal" on a running system). However, that brought up the fun difference between the output of gdisk vs fdisk $ gdisk -l /dev/nvme0n1 GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/nvme0n1: 500118192 sectors, 238.5 GiB Logical sector size: 512 bytes Disk identifier (GUID): C2D48243-DA0E-456D-BD55-D3BEE176DBEC Partition table holds up to 128 entries First usable sector is 34, last usable sector is 500118158 Partitions will be aligned on 2048-sector boundaries Total free space is 2124397 sectors (1.0 GiB) Number Start (sector) End (sector) Size Code Name 1 2048 1026047 500.0 MiB 0700 EFI system partition 2 3147776 500117503 237.0 GiB 8300 primary $ fdisk -l /dev/nvme0n1 Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 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: C2D48243-DA0E-456D-BD55-D3BEE176DBEC Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data /dev/nvme0n1p2 3147776 500117503 496969728 237G Linux filesystem Yes, "Name" vs "Type"... Output of `blkid` upthread. The machine in question has no /dev/disk/by-label, but `ls -l /dev/disk/by-partlabel/` gives: lrwxrwxrwx 1 root root 15 Jun 28 16:14 EFI\x20system\x20partition -> ../../nvme0n1p1 Thanks again. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Michael Fischer composed on 2020-06-28 15:59 (UTC-0400):
Seems I want that to show `LABEL="ESP"` when I'm done. Also, that `SEC_TYPE="msdos"` probably wants to go away?
I don't think that's a good idea. Maybe the following excerpts from one of mine would be helpful: # blkid | grep nvme /dev/nvme0n1p1: SEC_TYPE="msdos" LABEL_FATBOOT="PI3P01ESP" LABEL="PI3P01ESP" UUID="20A0-1003" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="MuP P01 EFI System (ESP)" PARTUUID="5e15361e-57dc-4df5-a1ad-9e392a4c1de4" /dev/nvme0n1p2: LABEL="pi3p02swap" UUID="b870efcb-073c-4b72-9e8b-59cc7ee89135" TYPE="swap" PARTLABEL="MuP P02 Linux Swap" PARTUUID="5e153628-5bc7-4df5-a22c-c74e9a2faeca" /dev/nvme0n1p3: LABEL="pi3p03res" UUID="26b718d5-68a0-4e97-bc97-fd227bfba9c1" BLOCK_SIZE="4096" TYPE="ext2" PARTLABEL="MuP P03 Linux reservation" PARTUUID="5e153641-6584-4df5-a343-b258db6da1d6" /dev/nvme0n1p4: LABEL="pi3p04usrlcl" UUID="d2f725ff-edbf-420d-a4e3-c6f540e9dc66" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="MuP P04 Linux /usr/local" PARTUUID="5e15364b-69ab-4df5-a4cf-0b421a251bec" /dev/nvme0n1p5: LABEL="pi3p05home" UUID="b6bbcea2-4741-4b94-9017-7f46273ea730" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="MuP P05 Linux /home" PARTUUID="5e15365b-6fe5-4df5-a52c-6adb55bf549e" /dev/nvme0n1p6: LABEL="pi3p06pub" UUID="0941d25f-4cce-41d4-af9f-033ad02019cb" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="MuP P06 Linux /pub" PARTUUID="5e153665-73e0-4df5-a697-0e0edbba422a" /dev/nvme0n1p7: LABEL="pi3p07stw" UUID="00600ad5-1528-4a3b-9316-28e0176ed29d" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="MuP P07 openSUSE Tumbleweed" PARTUUID="5e153684-7fa2-4df5-a78c-ed4f2e7a2e96" # grep -i pi3 /etc/fstab LABEL=PI3P01ESP /boot/efi vfat codepage=437 0 0 LABEL=pi3p02swap swap swap defaults 0 0 LABEL=pi3p03res /disk/res ext2 noatime,nofail 0 2 LABEL=pi3p04usrlcl /usr/local ext4 noatime,data=ordered 0 2 LABEL=pi3p05home /home ext4 noatime,data=ordered 0 2 LABEL=pi3p06pub /pub ext4 noatime,data=ordered 0 2 LABEL=pi3p07stw / ext4 noatime 0 1 # lsblk | grep nvme nvme0n1 259:4 0 111.8G 0 disk ├─nvme0n1p1 259:5 0 320M 0 part /boot/efi ├─nvme0n1p2 259:6 0 1.5G 0 part [SWAP] ├─nvme0n1p3 259:7 0 400M 0 part /disks/res ├─nvme0n1p4 259:8 0 3.9G 0 part /usr/local ├─nvme0n1p5 259:9 0 6.3G 0 part /home ├─nvme0n1p6 259:10 0 12.3G 0 part /pub ├─nvme0n1p7 259:11 0 7.8G 0 part / -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Jun 28, Felix Miata wrote:
Michael Fischer composed on 2020-06-28 15:59 (UTC-0400):
Seems I want that to show `LABEL="ESP"` when I'm done. Also, that `SEC_TYPE="msdos"` probably wants to go away?
I don't think that's a good idea. Maybe the following excerpts from one of mine would be helpful:
# blkid | grep nvme /dev/nvme0n1p1: SEC_TYPE="msdos" LABEL_FATBOOT="PI3P01ESP" LABEL="PI3P01ESP" UUID="20A0-1003" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="MuP P01 EFI System (ESP)" PARTUUID="5e15361e-57dc-4df5-a1ad-9e392a4c1de4"
So your point is that you have a happy /dev/nvme0n1p1 with SEC_TYPE="msdos" working as ESP, and not with LABEL="ESP". Fair enough, I suppose... But, just BTW... what's with "disk" vs "disks" ?
/dev/nvme0n1p3: LABEL="pi3p03res" UUID="26b718d5-68a0-4e97-bc97-fd227bfba9c1" BLOCK_SIZE="4096" TYPE="ext2"
# grep -i pi3 /etc/fstab LABEL=pi3p03res /disk/res ext2 noatime,nofail 0 2
# lsblk | grep nvme nvme0n1 259:4 0 111.8G 0 disk ├─nvme0n1p3 259:7 0 400M 0 part /disks/res
Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Michael Fischer composed on 2020-06-28 17:45 (UTC-0400):
But, just BTW... what's with "disk" vs "disks" ?
/dev/nvme0n1p3: LABEL="pi3p03res" UUID="26b718d5-68a0-4e97-bc97-fd227bfba9c1" BLOCK_SIZE="4096" TYPE="ext2"
# grep -i pi3 /etc/fstab LABEL=pi3p03res /disk/res ext2 noatime,nofail 0 2
# lsblk | grep nvme nvme0n1 259:4 0 111.8G 0 disk ├─nvme0n1p3 259:7 0 400M 0 part /disks/res
Redaction error. :P -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 28/06/2020 21.59, Michael Fischer wrote:
On Sun, Jun 28, Andrei Borzenkov wrote:
28.06.2020 14:58, Michael Fischer пишет:
Hello all (and hopefully Andrei),
While reading the recent thread (... Zypper dup renders 15.1 to 15.2...) I got curious about my own system - which had a reinstall (15.0) a few months ago, which went...poorly. It took several installs and boot attempts to get the thing to come up (which is really odd because it was a reinstall of 15.0 on top of the same 15.0 on seemingly perfectly good hardware)
Now I see that perhaps my /boot/efi is not configured correctly?
Yes.
$ sudo fdisk -l /dev/nvme0n1* Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 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: C2D48243-DA0E-456D-BD55-D3BEE176DBEC
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data
The "type" of ESP is supposed to be "EFI System". Anything else is up to firmware implementation. Explicit firmware boot entries that point to this partition will likely work. "Boot from hard disk" in BIOS boot menu selection (exact name varies between vendors) may not be offered at all.
Also os-prober and other operating systems may fail to find ESP.
I would change type to "EFI System" just to be sure.
Thank you. I suspected as much. What are the commands I would want to use for this (these?) operations?
fdisk would do. ~# fdisk /dev/nvme0n1 Welcome to fdisk (util-linux 2.33.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk /dev/nvme0n1: 465.8 GiB, 500107862016 bytes, 976773168 sectors Disk model: Samsung SSD 970 EVO Plus 500GB 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: 40891E95-... Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data /dev/nvme0n1p2 42969088 252684287 209715200 100G Linux swap /dev/nvme0n1p3 252684288 315598847 62914560 30G Linux filesystem /dev/nvme0n1p4 315598848 317702143 2103296 1G Linux filesystem /dev/nvme0n1p5 317702144 632270847 314568704 150G Linux filesystem Command (m for help): Help: GPT M enter protective/hybrid MBR Generic d delete a partition F list free unpartitioned space l list known partition types n add a new partition p print the partition table t change a partition type <===== Command (m for help): t Partition number (1-5, default 5): 1 Partition type (type L to list all types): L 1 EFI System C12A7328-F81F-11D2-BA4B-00A0C93EC93B <=== 2 MBR partition scheme 024DEE41-33E7-11D3-9D69-0008C781F39F 3 Intel Fast Flash D3BFE2DE-3DAF-11DF-BA40-E3A556D89593 ... q
/dev/nvme0n1p1: SEC_TYPE="msdos" UUID="5591-235C" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="f95c0606-ecaa-44af-8fd0-51f9980f26a9"
Seems I want that to show `LABEL="ESP"` when I'm done.
Changing the label can have consequences, if something accesses the disk by the label.
Also, that `SEC_TYPE="msdos"` probably wants to go away?
No. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sun, Jun 28, Carlos E. R. wrote:
fdisk would do.
~# fdisk /dev/nvme0n1
Welcome to fdisk (util-linux 2.33.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command.
Command (m for help): p Disk /dev/nvme0n1: 465.8 GiB, 500107862016 bytes, 976773168 sectors Disk model: Samsung SSD 970 EVO Plus 500GB 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: 40891E95-...
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data /dev/nvme0n1p2 42969088 252684287 209715200 100G Linux swap /dev/nvme0n1p3 252684288 315598847 62914560 30G Linux filesystem /dev/nvme0n1p4 315598848 317702143 2103296 1G Linux filesystem /dev/nvme0n1p5 317702144 632270847 314568704 150G Linux filesystem
Command (m for help):
Help:
GPT M enter protective/hybrid MBR
Generic d delete a partition F list free unpartitioned space l list known partition types n add a new partition p print the partition table t change a partition type <=====
Command (m for help): t Partition number (1-5, default 5): 1 Partition type (type L to list all types): L 1 EFI System C12A7328-F81F-11D2-BA4B-00A0C93EC93B <=== 2 MBR partition scheme 024DEE41-33E7-11D3-9D69-0008C781F39F 3 Intel Fast Flash D3BFE2DE-3DAF-11DF-BA40-E3A556D89593 ... q
Understood, but (silly question), is this "safe" to run on a live system? Thanks Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/06/2020 23.31, Michael Fischer wrote:
On Sun, Jun 28, Carlos E. R. wrote:
fdisk would do.
~# fdisk /dev/nvme0n1
...
Command (m for help): t Partition number (1-5, default 5): 1 Partition type (type L to list all types): L 1 EFI System C12A7328-F81F-11D2-BA4B-00A0C93EC93B <=== 2 MBR partition scheme 024DEE41-33E7-11D3-9D69-0008C781F39F 3 Intel Fast Flash D3BFE2DE-3DAF-11DF-BA40-E3A556D89593 ... q
Understood, but (silly question), is this "safe" to run on a live system?
I believe so, yes. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Wed, Jul 01, Carlos E. R. wrote:
On 30/06/2020 23.31, Michael Fischer wrote:
On Sun, Jun 28, Carlos E. R. wrote:
fdisk would do.
~# fdisk /dev/nvme0n1
Understood, but (silly question), is this "safe" to run on a live system?
I believe so, yes.
Before: $ fdisk -l /dev/nvme0n1 ... Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data /dev/nvme0n1p2 3147776 500117503 496969728 237G Linux filesystem During: Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): Y OK; writing new GUID partition table (GPT) to /dev/nvme0n1. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully After: $ fdisk -l /dev/nvme0n1 ..... Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M EFI System /dev/nvme0n1p2 3147776 500117503 496969728 237G Linux filesystem Thanks all. Fingers crossed. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/07/2020 21.38, Michael Fischer wrote:
On Wed, Jul 01, Carlos E. R. wrote:
On 30/06/2020 23.31, Michael Fischer wrote:
On Sun, Jun 28, Carlos E. R. wrote:
fdisk would do.
~# fdisk /dev/nvme0n1
Understood, but (silly question), is this "safe" to run on a live system?
I believe so, yes.
Before:
$ fdisk -l /dev/nvme0n1 ...
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data /dev/nvme0n1p2 3147776 500117503 496969728 237G Linux filesystem
During:
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
Do you want to proceed? (Y/N): Y OK; writing new GUID partition table (GPT) to /dev/nvme0n1. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully
You can run "partprobe" at this point. The message is superfluous after such a trivial change to the partition table as you did, but anyway... :)
After:
$ fdisk -l /dev/nvme0n1 .....
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M EFI System /dev/nvme0n1p2 3147776 500117503 496969728 237G Linux filesystem
Thanks all. Fingers crossed.
Welcome. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 01/07/2020 21.38, Michael Fischer wrote:
On Wed, Jul 01, Carlos E. R. wrote:
After:
$ fdisk -l /dev/nvme0n1 .....
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M EFI System /dev/nvme0n1p2 3147776 500117503 496969728 237G Linux filesystem
Thanks all. Fingers crossed.
You could run: efibootmgr -v to verify that the UEFI (aka BIOS) has the OSES listed. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Wed, Jul 01, Carlos E. R. wrote:
On 01/07/2020 21.38, Michael Fischer wrote:
On Wed, Jul 01, Carlos E. R. wrote:
After:
$ fdisk -l /dev/nvme0n1 .....
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M EFI System /dev/nvme0n1p2 3147776 500117503 496969728 237G Linux filesystem
Thanks all. Fingers crossed.
You could run:
efibootmgr -v
to verify that the UEFI (aka BIOS) has the OSES listed.
Yeah, I ran that prior to doing gdisk, and opensuse-secureboot was present (after Windows Boot Manager for whatever reason) It still is there now after using the gdisk command. Not sure that output changed at all. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Andrei Borzenkov -
Carlos E. R. -
Dave Howorth -
Felix Miata -
jdd＠dodin.org -
Michael Fischer