Could not prepare Boot variable: No medium found
I'm trying to make an upgraded NVME boot. Old was 120G. New is 500G. The ESP is giving me no apparent trouble, but booting from NVME normally from NVME instead of via rescue media is somehow being blocked by inability to create an EFI boot entry causing $SUBJECT message. # grep DISTR /etc/default/grub GRUB_DISTRIBUTOR="opensusetw" # ls -1 /sys/firmware/efi/efivars | wc -l 82 # parted /dev/nvme0n1 print | grep -Ei 'p01|p07' 1 1049kB 337MB 336MB fat32 PNY5 p01 EFI System (ESP) boot, esp 7 29.3GB 37.7GB 8389MB ext4 PNY5 p07 openSUSE Tumbleweed # grep -E '0 1|boot/' /etc/fstab LABEL=PNY5P01ESP /boot/efi vfat codepage=437 0 0 LABEL=pny5p07stw / ext4 noatime 0 1 # ls -gG /boot/efi/EFI/opensusetw/ -rwxr-xr-x 1 143360 Sep 19 18:55 grubx64.efi # ls -gG /sys/firmware/ drwxr-xr-x 6 0 Nov 7 23:14 acpi drwxr-xr-x 3 0 Nov 7 23:14 dmi drwxr-xr-x 7 0 Nov 7 23:14 efi drwxr-xr-x 27 0 Nov 8 03:27 memmap # mount | grep nvme0 /dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) /dev/nvme0n1p7 on / type ext4 (rw,noatime) # ls -Gg /boot | grep '5.19' | grep -E 'vmlinuz|initrd' lrwxrwxrwx 1 24 Oct 9 23:10 initrd -> initrd-5.19.13-1-default -rw------- 1 14166604 Oct 9 23:10 initrd-5.19.13-1-default lrwxrwxrwx 1 25 Oct 9 23:10 vmlinuz -> vmlinuz-5.19.13-1-default lrwxrwxrwx 1 44 Oct 9 23:10 vmlinuz-5.19.13-1-default -> ../usr/lib/modules/5.19.13-1-default/vmlinuz # efibootmgr BootCurrent: 0007 Timeout: 1 seconds BootOrder: 0003,0004,0007 Boot0003* Hard Drive Boot0004* CD/DVD Drive Boot0007* UEFI: USB DISK 3.2 PMAP, Partition 2 # lsblk -f | grep nvme0 nvme0n1 ├─nvme0n1p1 vfat FAT32 PNY5P01ESP 4C58-8D7E 294.1M 8% /boot/efi ├─nvme0n1p7 ext4 1.0 pny5p07stw ae6c138b-f360-45e7-a43c-188fcd3b3f07 2.7G 60% / # blkid | grep nvme0 /dev/nvme0n1p1: LABEL_FATBOOT="PNY5P01ESP" LABEL="PNY5P01ESP" UUID="4C58-8D7E" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="PNY5 p01 EFI System (ESP)" PARTUUID="6369e907-1e83-4df5-8574-d6d1d34e9b7e" /dev/nvme0n1p7: LABEL="pny5p07stw" UUID="ae6c138b-f360-45e7-a43c-188fcd3b3f07" BLOCK_SIZE="2048" TYPE="ext4" PARTLABEL="PNY5 p07 openSUSE Tumbleweed" PARTUUID="6369ef77-a213-4df5-8bfd-cd881d32e345" # efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi' # lower case EL, not one Could not prepare Boot variable: No medium found A web search found me zero hits for "Could not prepare Boot variable: No medium found" What medium is missing from where? What's necessary to fix this (make efibootmgr -c work)? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Tue, Nov 8, 2022 at 12:03 PM Felix Miata
I'm trying to make an upgraded NVME boot. Old was 120G. New is 500G. The ESP is giving me no apparent trouble, but booting from NVME normally from NVME instead of via rescue media is somehow being blocked by inability to create an EFI boot entry causing $SUBJECT message.
# grep DISTR /etc/default/grub GRUB_DISTRIBUTOR="opensusetw" # ls -1 /sys/firmware/efi/efivars | wc -l 82 # parted /dev/nvme0n1 print | grep -Ei 'p01|p07' 1 1049kB 337MB 336MB fat32 PNY5 p01 EFI System (ESP) boot, esp 7 29.3GB 37.7GB 8389MB ext4 PNY5 p07 openSUSE Tumbleweed # grep -E '0 1|boot/' /etc/fstab LABEL=PNY5P01ESP /boot/efi vfat codepage=437 0 0 LABEL=pny5p07stw / ext4 noatime 0 1 # ls -gG /boot/efi/EFI/opensusetw/ -rwxr-xr-x 1 143360 Sep 19 18:55 grubx64.efi # ls -gG /sys/firmware/ drwxr-xr-x 6 0 Nov 7 23:14 acpi drwxr-xr-x 3 0 Nov 7 23:14 dmi drwxr-xr-x 7 0 Nov 7 23:14 efi drwxr-xr-x 27 0 Nov 8 03:27 memmap # mount | grep nvme0 /dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) /dev/nvme0n1p7 on / type ext4 (rw,noatime) # ls -Gg /boot | grep '5.19' | grep -E 'vmlinuz|initrd' lrwxrwxrwx 1 24 Oct 9 23:10 initrd -> initrd-5.19.13-1-default -rw------- 1 14166604 Oct 9 23:10 initrd-5.19.13-1-default lrwxrwxrwx 1 25 Oct 9 23:10 vmlinuz -> vmlinuz-5.19.13-1-default lrwxrwxrwx 1 44 Oct 9 23:10 vmlinuz-5.19.13-1-default -> ../usr/lib/modules/5.19.13-1-default/vmlinuz # efibootmgr
Output of lonely efibootmgr is usually useless. Show "efibootmgr -v". Always.
BootCurrent: 0007 Timeout: 1 seconds BootOrder: 0003,0004,0007 Boot0003* Hard Drive Boot0004* CD/DVD Drive Boot0007* UEFI: USB DISK 3.2 PMAP, Partition 2
Are you sure your firmware is capable of booting from NVMe directly?
# lsblk -f | grep nvme0 nvme0n1 ├─nvme0n1p1 vfat FAT32 PNY5P01ESP 4C58-8D7E 294.1M 8% /boot/efi ├─nvme0n1p7 ext4 1.0 pny5p07stw ae6c138b-f360-45e7-a43c-188fcd3b3f07 2.7G 60% / # blkid | grep nvme0 /dev/nvme0n1p1: LABEL_FATBOOT="PNY5P01ESP" LABEL="PNY5P01ESP" UUID="4C58-8D7E" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="PNY5 p01 EFI System (ESP)" PARTUUID="6369e907-1e83-4df5-8574-d6d1d34e9b7e" /dev/nvme0n1p7: LABEL="pny5p07stw" UUID="ae6c138b-f360-45e7-a43c-188fcd3b3f07" BLOCK_SIZE="2048" TYPE="ext4" PARTLABEL="PNY5 p07 openSUSE Tumbleweed" PARTUUID="6369ef77-a213-4df5-8bfd-cd881d32e345" # efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi' # lower case EL, not one Could not prepare Boot variable: No medium found
A web search found me zero hits for
"Could not prepare Boot variable: No medium found"
What medium is missing from where?
This is simply the standard error string for ENOMEDIUM. Programs are free to return any error code they deem appropriate. Failure to resolve the path to this device via UEFI would certainly qualify for this error code. The ultimate way is to boot into EFI Shell and check which devices are available.
What's necessary to fix this (make efibootmgr -c work)? -- Evolution as taught in public schools is, like religion, based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
Andrei Borzenkov composed on 2022-11-08 12:15 (UTC+0300):
Output of lonely efibootmgr is usually useless. Show "efibootmgr -v". Always.
Showing only three boot entries, including the USB rescue stick and DVD burner, it looked totally useless to me, so I didn't want to clutter the email further: # efibootmgr -v BootCurrent: 0007 Timeout: 1 seconds BootOrder: 0003,0004,0007 Boot0003* Hard Drive BBS(HD,,0x0)..GO..NO........{.P.N.Y. .C.S.1.0.3.0. .5.0.0.G.B. .S.S.D....................A..........................dy.m`..[.....>..Gd-.;.A..MQ..L.P.N.Y. .C.S.1.0.3.0. .5.0.0.G.B. .S.S.D........BO..NO........`.G.e.n.e.r.i.c.-.C.o.m.p.a.c.t. .F.l.a.s.h. .1...0.1....................A...............................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6........BO..NO........`.G.e.n.e.r.i.c.-.S.M./.x.D.-.P.i.c.t.u.r.e. .1...0.2....................A...............................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6........BO..NO........`.G.e.n.e.r.i.c.-.M.S./.M.S.-.P.r.o. .1...0.3....................A...............................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6........BO..NO........[.G.e.n.e.r.i.c.-.S.D./.M.M.C. .1...0.0....................A..........................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6........BO..NO........s.M.K.N.S.S.D.P.L.1.2.0.G.B.-.D.8....................A.......................................6..Gd-.;.A..MQ..L.M.K.N.S.S.D.P.L.1.2.0.G.B.-.D.8........BO..NO........c. .U.S.B. .D.I.S.K. .3...2. .P.M.A.P....................A.......................6..Gd-.;.A..MQ..L.0.7.1.C.1.B.D.1.2.2.5.1.2.E.1.5........BO Boot0004* CD/DVD Drive BBS(CDROM,,0x0)..GO..NO........o.P.L.E.X.T.O.R. .P.X.-.8.9.1.S.A.F....................A...........................>..Gd-.;.A..MQ..L.5.3.4.2.7.7. .2.M.2.7.8.9.2.0.5.0.1.3.5........BO Boot0007* UEFI: USB DISK 3.2 PMAP, Partition 2 PciRoot(0x0)/Pci(0x14,0x0)/USB(18,0)/HD(2,MBR,0x37b2dd7,0x31c2000,0x10000)..BO -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2022-11-08 13:28, Felix Miata wrote:
Andrei Borzenkov composed on 2022-11-08 12:15 (UTC+0300):
Output of lonely efibootmgr is usually useless. Show "efibootmgr -v". Always.
Showing only three boot entries, including the USB rescue stick and DVD burner, it looked totally useless to me, so I didn't want to clutter the email further:
And the UEFI configuration screens only show those three? Then your UEFI does not see your media, garbage it.
# efibootmgr -v BootCurrent: 0007 Timeout: 1 seconds BootOrder: 0003,0004,0007 Boot0003* Hard Drive BBS(HD,,0x0)..GO..NO........{.P.N.Y. .C.S.1.0.3.0. .5.0.0.G.B. .S.S.D....................A..........................dy.m`..[.....>..Gd-.;.A..MQ..L.P.N.Y. .C.S.1.0.3.0. .5.0.0.G.B. .S.S.D........BO..NO........`.G.e.n.e.r.i.c.-.C.o.m.p.a.c.t. .F.l.a.s.h. .1...0.1....................A...............................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6........BO..NO........`.G.e.n.e.r.i.c.-.S.M./.x.D.-.P.i.c.t.u.r.e. .1...0.2....................A...............................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6........BO..NO........`.G.e.n.e.r.i.c.-.M.S./.M.S.-.P.r.o. .1...0.3....................A...............................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6........BO..NO........[.G.e.n.e.r.i.c.-.S.D./.M.M.C. .1...0.0....................A..........................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6........BO..NO........s.M.K.N.S.S.D.P.L.1.2.0.G.B.-.D.8....................A.......................................6..Gd-.;.A..MQ..L.M.K.N.S.S.D.P.L.1.2.0.G.B.-.D.8........BO..NO........c. .U.S.B. .D.I.S.K. .3...2. .P.M.A.P....................A.......................6..Gd-.;.A..MQ..L.0.7.1.C.1.B.D.1.2.2.5.1.2.E.1.5........BO Boot0004* CD/DVD Drive BBS(CDROM,,0x0)..GO..NO........o.P.L.E.X.T.O.R. .P.X.-.8.9.1.S.A.F....................A...........................>..Gd-.;.A..MQ..L.5.3.4.2.7.7. .2.M.2.7.8.9.2.0.5.0.1.3.5........BO Boot0007* UEFI: USB DISK 3.2 PMAP, Partition 2 PciRoot(0x0)/Pci(0x14,0x0)/USB(18,0)/HD(2,MBR,0x37b2dd7,0x31c2000,0x10000)..BO
-- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Carlos E. R. composed on 2022-11-08 13:56 (UTC60100):
Felix Miata wrote:
Andrei Borzenkov composed on 2022-11-08 12:15 (UTC+0300):
Output of lonely efibootmgr is usually useless. Show "efibootmgr -v". Always.
Showing only three boot entries, including the USB rescue stick and DVD burner, it looked totally useless to me, so I didn't want to clutter the email further:
And the UEFI configuration screens only show those three?
Then your UEFI does not see your media, garbage it.
Before I started composing the OP, I had booted the installed system via TW .iso on Ventoy USB. At that point there were other entries, including Boot0000* opensusetw that I had previously created manually, after deleting the existing Boot0000* opensusetw from the old NVME that won't be in the PC once all cloning processes have been completed, and which I have no present interest in booting again from the PC it's being removed from. IOW, I removed obsolete/unwanted entries before attempting efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi' expecting to have 4 entries. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2022-11-08 14:20, Felix Miata wrote:
Carlos E. R. composed on 2022-11-08 13:56 (UTC60100):
Felix Miata wrote:
from the old NVME that won't be in the PC once all cloning processes have been completed, and which I have no present interest in booting again from the PC it's being removed from. IOW, I removed obsolete/unwanted entries before attempting
efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi'
expecting to have 4 entries.
Notice that firmwares have their own ideas of what characters are acceptable and what lengths. See my other post. Edit that file and use YaST. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Carlos E. R. composed on 2022-11-08 14:25 (UTC+0100):
Felix Miata wrote:
Carlos E. R. composed on 2022-11-08 13:56 (UTC60100):
Felix Miata wrote:
from the old NVME that won't be in the PC once all cloning processes have been completed, and which I have no present interest in booting again from the PC it's being removed from. IOW, I removed obsolete/unwanted entries before attempting
efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi'
expecting to have 4 entries.
Notice that firmwares have their own ideas of what characters are acceptable and what lengths. See my other post. Edit that file and use YaST. This is a test system. YaST will not be involved in the current process of migrating from a small NVME to a larger. All my EFI systems have only one installed bootloader, which is TW's, and uses opensusetw in /boot/efi/EFI/ and /etc/default/grub's GRUB_DISTRIBUTOR=.
I didn't do a true clone of anything on the new NVME. On the new, I: partitioned afresh formatted the new NVME's 1 (ESP), 2 (swap) & 7 (TW) partitions with unique LABELs copied content from old 1 to new 1 and old 7 to new 7 using rsync edited fstab, custom.cfg and grub.cfg as required on new 7 removed old NVME EFI entry with efibootmgr removed old NVME (IIRC, it's in there now, as cloning is incomplete) tried to create new, working NVME EFI entry with efibootmgr I've done essentially the same thing before, except with SATA SSDs, not NVMEs. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Andrei Borzenkov composed on 2022-11-08 12:15 (UTC+0300):
Felix Miata wrote:
I'm trying to make an upgraded NVME boot. Old was 120G. New is 500G. The ESP is giving me no apparent trouble, but booting from NVME normally from NVME instead of via rescue media is somehow being blocked by inability to create an EFI boot entry causing $SUBJECT message. ... Are you sure your firmware is capable of booting from NVMe directly?
4 year old *NVME* /is 120G. New *NVME* is 500G. It was able to initialize boot into the new ESP using the efibootmgr-created entry I made to test with before populating the TW system partition with rsync from the old NVME, but there just wasn't any /boot/grub2 directory tree from which to load normal, custom.cfg or grub.cfg from. ...
# efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi' # lower case EL, not one Could not prepare Boot variable: No medium found
A web search found me zero hits for
"Could not prepare Boot variable: No medium found"
What medium is missing from where?
This is simply the standard error string for ENOMEDIUM. Programs are free to return any error code they deem appropriate. Failure to resolve the path to this device via UEFI would certainly qualify for this error code.
The ultimate way is to boot into EFI Shell and check which devices are available.
Is that some different EFI shell from the rescue shell that is presented booting without the USB stick? After doing the latter, following: error: symbol 'grub_is_lockdown' not found. Entering rescue mode... grub rescue> ls is included: 6 partitions on the Ventoy rescue boot media containing a TW20220925 .iso from which I booted the installed system on nvme0n1p7. ((hd0) (hd1) (hd2) ... (hd5)) (hd6) 16 partitions on the old NVME ((hd6,gpt16) (hd6,gpt15) ... (hd6,gpt1)) (hd7) 18 partitions on the new NVME ((hd7,gpt18) (hd7,gpt17) ... (hd7,gpt1)) What is the "Boot variable" it could not prepare using efibootmgr -c? For similar reasons several days ago I searched for symbol 'grub_is_lockdown' not found without finding a useful hit. On that PC I solved the problem by an (ASUS) BIOS change: enabling legacy booting. That didn't help in the instant situation. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2022-11-08 14:09, Felix Miata wrote:
Andrei Borzenkov composed on 2022-11-08 12:15 (UTC+0300):
Felix Miata wrote:
I'm trying to make an upgraded NVME boot. Old was 120G. New is 500G. The ESP is giving me no apparent trouble, but booting from NVME normally from NVME instead of via rescue media is somehow being blocked by inability to create an EFI boot entry causing $SUBJECT message. ... Are you sure your firmware is capable of booting from NVMe directly?
4 year old *NVME* /is 120G. New *NVME* is 500G.
It was able to initialize boot into the new ESP using the efibootmgr-created entry I made to test with before populating the TW system partition with rsync from the old NVME, but there just wasn't any /boot/grub2 directory tree from which to load normal, custom.cfg or grub.cfg from.
Do both system have different names? grep GRUB_DISTRIBUTOR /etc/default/grub If not, change it. And beware that the firmware may not like some characters and ignore the entry. To initialize, I *always* use yast boot manager. Just change the time out one second up or down. If it is another partition than the current system, chroot it. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On 08.11.2022 16:09, Felix Miata wrote: ...
...
# efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi' # lower case EL, not one Could not prepare Boot variable: No medium found
Add "-v -v -v" to efibootmgr invocation, it may show something more useful.
A web search found me zero hits for
"Could not prepare Boot variable: No medium found"
What medium is missing from where?
This is simply the standard error string for ENOMEDIUM. Programs are free to return any error code they deem appropriate. Failure to resolve the path to this device via UEFI would certainly qualify for this error code.
The ultimate way is to boot into EFI Shell and check which devices are available.
Is that some different EFI shell from the rescue shell that is presented booting without the USB stick? After doing the latter, following:
error: symbol 'grub_is_lockdown' not found. Entering rescue mode... grub rescue> ls
No, it is different. Sometimes it is included in firmware, although I guess on consumer systems it is less likely (at least, it may be hidden behind some magic incantation). Otherwise it is just another EFI program that can be loaded instead of grub. It provide some useful commands to inspect EFI environment.
is included:
6 partitions on the Ventoy rescue boot media containing a TW20220925 .iso from which I booted the installed system on nvme0n1p7. ((hd0) (hd1) (hd2) ... (hd5)) (hd6) 16 partitions on the old NVME ((hd6,gpt16) (hd6,gpt15) ... (hd6,gpt1)) (hd7) 18 partitions on the new NVME ((hd7,gpt18) (hd7,gpt17) ... (hd7,gpt1))
"symbol not found" is common and I am surprised you need to ask what it is. It means that grub binary loaded by firmware (stage1/stage1.5) does not match grub modules in /boot/grub2/$platform. As we do not really know where this grub is loaded from and where it looks for modules it is hard to guess what happens. But your efibootmgr shows only legacy BIOS boot option, so it could be loaded in this mode. Unfortunately in this rescue shell there is not much that can be done.
What is the "Boot variable" it could not prepare using efibootmgr -c?
For similar reasons several days ago I searched for
symbol 'grub_is_lockdown' not found
Because it could be different symbol depending on exact grub version and vendor.
without finding a useful hit. On that PC I solved the problem by an (ASUS) BIOS change: enabling legacy booting. That didn't help in the instant situation.
I see something strange in this line. efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi' 1. Is this the partitonlabel > "opensusetw" ? It should be ! 2. The medium is not adressed in this line -d /dev/nvme0n1 Good luck. On 08/11/2022 17:44, Andrei Borzenkov wrote:
On 08.11.2022 16:09, Felix Miata wrote: ...
...
# efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi' # lower case EL, not one Could not prepare Boot variable: No medium found
Add "-v -v -v" to efibootmgr invocation, it may show something more useful.
A web search found me zero hits for
"Could not prepare Boot variable: No medium found"
What medium is missing from where?
This is simply the standard error string for ENOMEDIUM. Programs are free to return any error code they deem appropriate. Failure to resolve the path to this device via UEFI would certainly qualify for this error code.
The ultimate way is to boot into EFI Shell and check which devices are available.
Is that some different EFI shell from the rescue shell that is presented booting without the USB stick? After doing the latter, following:
error: symbol 'grub_is_lockdown' not found. Entering rescue mode... grub rescue> ls
No, it is different. Sometimes it is included in firmware, although I guess on consumer systems it is less likely (at least, it may be hidden behind some magic incantation). Otherwise it is just another EFI program that can be loaded instead of grub. It provide some useful commands to inspect EFI environment.
is included:
6 partitions on the Ventoy rescue boot media containing a TW20220925 .iso from which I booted the installed system on nvme0n1p7. ((hd0) (hd1) (hd2) ... (hd5)) (hd6) 16 partitions on the old NVME ((hd6,gpt16) (hd6,gpt15) ... (hd6,gpt1)) (hd7) 18 partitions on the new NVME ((hd7,gpt18) (hd7,gpt17) ... (hd7,gpt1))
"symbol not found" is common and I am surprised you need to ask what it is. It means that grub binary loaded by firmware (stage1/stage1.5) does not match grub modules in /boot/grub2/$platform. As we do not really know where this grub is loaded from and where it looks for modules it is hard to guess what happens. But your efibootmgr shows only legacy BIOS boot option, so it could be loaded in this mode. Unfortunately in this rescue shell there is not much that can be done.
What is the "Boot variable" it could not prepare using efibootmgr -c?
For similar reasons several days ago I searched for
symbol 'grub_is_lockdown' not found
Because it could be different symbol depending on exact grub version and vendor.
without finding a useful hit. On that PC I solved the problem by an (ASUS) BIOS change: enabling legacy booting. That didn't help in the instant situation.
On 2022-11-08 21:16, JJM de Faber wrote:
I see something strange in this line.
efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi'
1. Is this the partitonlabel > "opensusetw" ? It should be !
No. -L | --label LABEL Boot manager display label (defaults to "Linux") And this should be the same⁽¹⁾ as stored in grep GRUB_DISTRIBUTOR /etc/default/grub I have had two issues with it: what is the maximum length, and what chars are acceptable. Once I found my name was too long, and another I found that it did not accept '-' or '_' (I forget which). In both cases, the result was that the firmware silently erased the entry. (1) It is used by YaST and by automatic upgrades that affect boot things.
2. The medium is not adressed in this line -d /dev/nvme0n1
I thought it defaults to the current disk the system is in, but the manual says it is /dev/sda.
Good luck. --
Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
JJM de Faber composed on 2022-11-08 21:16 (UTC+0100):
I see something strange in this line.
efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi'
1. Is this the partitonlabel > "opensusetw" ? It should be !
I don't see how you're seen any relationship between
2. The medium is not adressed in this line -d /dev/nvme0n1
Good luck.
Apparently I had never needed to create an efi entry from scratch from within a rescue environment before, so my notes made no mention of need for the -d option. efibootmgr -c -L "opensusetw" -d /dev/nvme0n1 -l '\EFI\opensusetw\grubx64.efi' proved the full solution for recovery of the original NVME reinstalled, but only a partial solution for the clone. Grub is working for the clone: finding PNY CS1030 500GB SSD pny5p07stw Reached target Initrd Root Device but dracut has spewed these 120 lines per boot about not finding the original NVME's ESP's FAT serial number, so ending in a dracut emergency shell announcing need to examine /run/initramfs/rdsosreport.txt: dracut-initqueue[337]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f20A0-1003.sh: "[ -e "/dev/disk/by-uuid/20A0-1003" ] https://paste.opensuse.org/8935122 I don't see anything in it suggested why the 20A0-1003 device is wanted. It's not anywhere in the new fstab, or grub.cfg, or custom.cfg. Obviously it's in the initrds, but not obvious why. Dracut is being obstreperous, rejects any and all attempts to regenerate initrd for the running 5.19.13 kernel, but claiming to generate one for 5.19.10, which has no representation in /usr/lib/modules. # dracut -f -k /usr/lib/modules/5.19.13-1-default dracut: -k/--kmoddir path must contain "lib/modules" as a parent of your kernel dracut: module directory, or modules may not be placed in the correct location dracut: inside the initramfs. dracut: was given: /usr/lib/modules/5.19.13-1-default dracut: expected: /usr/lib/modules/lib/modules/ (yes, .10!!!) dracut: Please move your modules into the correct directory structure and pass dracut: the new location, or set DRACUT_KMODDIR_OVERIDE=1 to correct this check. Prepending DRACUT_KMODDIR_OVERIDE=1 to dracut command results in errors, such as /boot/initrd-5.19.10-1-default instead of /boot/initrd-5.19.13-1-default -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Felix Miata composed on 2022-11-09 01:06 (UTC-0500):
Apparently I had never needed to create an efi entry from scratch from within a rescue environment before, so my notes made no mention of need for the -d option.
efibootmgr -c -L "opensusetw" -d /dev/nvme0n1 -l '\EFI\opensusetw\grubx64.efi'
proved the full solution for recovery of the original NVME reinstalled, but only a partial solution for the clone. Grub is working for the clone:
finding PNY CS1030 500GB SSD pny5p07stw Reached target Initrd Root Device
but dracut has spewed these 120 lines per boot about not finding the original NVME's ESP's FAT serial number, so ending in a dracut emergency shell announcing need to examine /run/initramfs/rdsosreport.txt:
dracut-initqueue[337]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f20A0-1003.sh: "[ -e "/dev/disk/by-uuid/20A0-1003" ]
I don't see anything in it suggested why the 20A0-1003 device is wanted. It's not anywhere in the new fstab, or grub.cfg, or custom.cfg. Obviously it's in the initrds, but not obvious why. Dracut is being obstreperous, rejects any and all attempts to regenerate initrd for the running 5.19.13 kernel, but claiming to generate one for 5.19.10, which has no representation in /usr/lib/modules.
# dracut -f -k /usr/lib/modules/5.19.13-1-default dracut: -k/--kmoddir path must contain "lib/modules" as a parent of your kernel dracut: module directory, or modules may not be placed in the correct location dracut: inside the initramfs. dracut: was given: /usr/lib/modules/5.19.13-1-default dracut: expected: /usr/lib/modules/lib/modules/ (yes, .10!!!) dracut: Please move your modules into the correct directory structure and pass dracut: the new location, or set DRACUT_KMODDIR_OVERIDE=1 to correct this check.
Prepending DRACUT_KMODDIR_OVERIDE=1 to dracut command results in errors, such as
/boot/initrd-5.19.10-1-default instead of /boot/initrd-5.19.13-1-default
Only TW presented trouble from the NVME migration. I filed a new bug about the ESP FAT serial number blocking TW boot on the new NVME: https://bugzilla.opensuse.org/show_bug.cgi?id=1205261 dracut/hooks/emergency...ESP's FAT serial number in initrd halts boot in dracut emergency shell after rsync migration to new GPT system disk Once I found out that I was able to boot from the new NVME from the migrated distros other than TW, all of which behaved as if nothing had been changed, and all of which I booted from TW's /boot/grub2/custom.cfg, I was able to chroot to TW and rebuild initrds that fully boot TW as expected. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Andrei Borzenkov composed on 2022-11-08 12:15 (UTC+0300):
Felix Miata wrote:
I'm trying to make an upgraded NVME boot. Old was 120G. New is 500G. The ESP is giving me no apparent trouble, but booting from NVME normally from NVME instead of via rescue media is somehow being blocked by inability to create an EFI boot entry causing $SUBJECT message. ...>> # efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi' # lower case EL, not one Could not prepare Boot variable: No medium found
A web search found me zero hits for
"Could not prepare Boot variable: No medium found"
What medium is missing from where?
This is simply the standard error string for ENOMEDIUM. Programs are free to return any error code they deem appropriate. Failure to resolve the path to this device via UEFI would certainly qualify for this error code.
The ultimate way is to boot into EFI Shell and check which devices are available.
I think I've found a cause, but not the right solution. A boot into TW installation media rescue system followed by traditional chroot[1] into installed system does not populate /sys/firmware/efi/efivars. So from outside chroot I did: mount -o bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars This enabled efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi' to run without error, but it did not produce expected result: # efibootmgr -v BootCurrent: 000A Timeout: 1 seconds BootOrder: 0000,0003,0008,000A,0004 Boot0000* opensusetw HD(1,MBR,0x793e116c,0xc84,0x1b90)/File(\EFI\opensusetw\grubx64.efi) Boot0003* Hard Drive BBS(HD,,0x0)..GO..NO........{.P.N.Y. .C.S.1.0.3.0. .5.0.0.G.B. .S.S.D....................A..........................dy.m`..[.....>..Gd-.;.A..MQ..L.P.N.Y. .C.S.1.0.3.0. .5.0.0.G.B. .S.S.D........BO..NO........`.G.e.n.e.r.i.c.-.C.o.m.p.a.c.t. .F.l.a.s.h. .1...0.1....................A...............................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6........BO..NO........`.G.e.n.e.r.i.c.-.S.M./.x.D.-.P.i.c.t.u.r.e. .1...0.2....................A...............................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6........BO..NO........`.G.e.n.e.r.i.c.-.M.S./.M.S.-.P.r.o. .1...0.3....................A...............................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6........BO..NO........[.G.e.n.e.r.i.c.-.S.D./.M.M.C. .1...0.0....................A..........................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6........BO..NO........c. .U.S.B. .D.I.S.K. .3...2. .P.M.A.P....................A.......................6..Gd-.;.A..MQ..L.0.7.1.C.1.B.D.1.2.7.1.1.F.6.1.5........BO Boot0004* CD/DVD Drive BBS(CDROM,,0x0)..GO..NO........o.P.L.E.X.T.O.R. .P.X.-.8.9.1.S.A.F....................A...........................>..Gd-.;.A..MQ..L.5.3.4.2.7.7. .2.M.2.7.8.9.2.0.5.0.1.3.5........BO Boot0008* opensuse HD(1,GPT,6369e907-1e83-4df5-8574-d6d1d34e9b7e,0x800,0xa0000)/File(\EFI\OPENSUSE\GRUBX64.EFI)..BO Boot000A* UEFI: USB DISK 3.2 PMAP PciRoot(0x0)/Pci(0x14,0x0)/USB(18,0)/CDROM(1,0xc84,0x6e40)..BO For Boot0000* I expect to see: Boot0000* opensusetw HD(1,GPT,6369e907-1e83-4df5-8574-d6d1d34e9b7e,0x800,0xa0000)/File(\EFI\OPENSUSE\GRUBX64.EFI) While Boot0008* opensuse's existence is a mystery. Trying to boot in this state by selecting from BBS menu the NVME device produces: Welcome to GRUB! error: symbol 'grub_is_lockdown' not found. Entering rescue mode... grub rescue> ls (hd0) (hd1) (hd2) (hd3) (hd4) (hd5) (hd5,gpt18) (hd5,gpt17) (hd5,gpt16) (hd5,gpt15) (hd5,gpt14) (hd5,gpt13) (hd5,gpt12) (hd5,gpt11) (hd5,gpt10) (hd5,gpt9) (hd5,gpt8) (hd5,gpt7) (hd5,gpt6) (hd5,gpt5) (hd5,gpt4) (hd5,gpt3) (hd5,gpt2) (hd5,gpt1) I next unpluged the card reader's USB cable responsible for the non-existent HDs, and the DVD cable, and booted to TW rescue to chroot the installed system, bind mounted /sys/firmware/efi/efivars to /mnt/sys/firmware/efi/efivars, but again the entry creation turned out to be: Boot0000* opensusetw HD(1,MBR,0x793e116c,0xc84,0x1b90)/File(\EFI\opensusetw\grubx64.efi) and again error: symbol 'grub_is_lockdown' not found. Entering rescue mode... grub rescue> What am I missing? [1] I'm chrooting from TW installation media rather than booting installed system from it because attempting to boot installed system black screens and locks up the PC so that remote login isn't possible. If I try booting installed system using nomodeset, the hang is at finding PNY CS1030 500GB SSD pny5p07stw Reached target Initrd Root Device Eventually it continues Starting Dracut Emergency Shell... Warning: /dev/disk/by-uuid/20A0-1003 does not exist Generating "/run/initramfs/rdsosreport.txt" 20A0-1003 is the FAT serial number of the old 120G NVME's ESP. :( All above was composed several hours ago, before any responses to my last thread post. I forgot to send before napping. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
participants (4)
-
Andrei Borzenkov
-
Carlos E. R.
-
Felix Miata
-
JJM de Faber