[Succeed]rEFind安装之在Deepin上的一番折腾~怀疑联想~Could not prepare Boot variable: No space left on device | 您所在的位置:网站首页 › efibootmgr无效 › [Succeed]rEFind安装之在Deepin上的一番折腾~怀疑联想~Could not prepare Boot variable: No space left on device |
intro
$ uname -a
Linux xx 5.10.5-amd64-desktop+ #1 SMP Mon Jan 11 14:55:28 CST 2021 x86_64 GNU/Linux
Begin
install
下载地址:https://sourceforge.net/projects/refind/ 我下载了deb用深度安装器安装,然后把启动时间默认的20修改5保存,重启。。还是进入deepin,于是关机进入boot menu。。没有refind reinstall with ALERT $ sudo refind-install ShimSource is none Installing rEFInd on Linux.... ESP was found at /boot/efi using vfat Found rEFInd installation in /boot/efi/EFI/refind; upgrading it. Installing driver for ext4 (ext4_x64.efi) Copied rEFInd binary files Notice: Backed up existing icons directory as icons-backup. Existing refind.conf file found; copying sample file as refind.conf-sample to avoid overwriting your customizations. Creating new NVRAM entry ALERT: There were problems running the efibootmgr program! You may need to rename the refind_x64.efi binary to the default name (EFI/BOOT/bootx64.efi on x86-64 systems, EFI/BOOT/bootia32.efi on x86 systems, or EFI/BOOT/bootaa64.efi on ARM64 systems) to have it run! Existing //boot/refind_linux.conf found; not overwriting.根据ALERT的提示,我把/boot/efi/EFI/refind/refind_x64.efi重命名为bootx64.efi,然后备份原来boot下的文件,之后把重命名之后的refind复制过去,重启无效。。boot menu也没有,于是再加上一个重命名为bootia32.efi的粘贴过去。。重启无效。。 难道是我放置位置不对???于是我把重命名后的两个refind复制到refind下。。重启一样fail。。。 由于Boot Menu中没有出现refind。。就纳闷是不是没有更新boot menu。。。于是用更新grub的方法(sudo update-grub)尝试之后也无效。。。于是各种搜索没啥相同的alert。。只好到官网找issue或者troubleshoot。。但是都没有。。只好随便看看。。看到下面这个 The rEFInd Boot Manager:Keeping rEFInd Booting 查看启动项 $ sudo efibootmgr -v BootCurrent: 0003 Timeout: 0 seconds BootOrder: 0003,0002,0001,0014,0000,0015,0016,0017,0018,0019,001A,001B Boot0000* ubuntu HD(1,GPT,171ffb3e-6c37-4801-8b11-3ba3cea2e27a,0x800,0x82000)/File(\EFI\ubuntu\shimx64.efi) Boot0001* Windows Boot Manager HD(1,GPT,171ffb3e-6c37-4801-8b11-3ba3cea2e27a,0x800,0x82000)/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.}...7................ Boot0002* UOS HD(1,GPT,171ffb3e-6c37-4801-8b11-3ba3cea2e27a,0x800,0x82000)/File(\EFI\UOS\shimx64.efi) Boot0003* deepin HD(1,GPT,171ffb3e-6c37-4801-8b11-3ba3cea2e27a,0x800,0x82000)/File(\EFI\deepin\shimx64.efi) Boot0004* Fedora HD(1,GPT,171ffb3e-6c37-4801-8b11-3ba3cea2e27a,0x800,0x82000)/File(\EFI\fedora\shimx64.efi) Boot0010 Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9) Boot0011 Boot Menu FvFile(86488440-41bb-42c7-93ac-450fbf7766bf) Boot0012 Diagnostic Splash FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380) Boot0013 UEFI Diagnostics FvFile(f8397897-e203-4a62-b977-9e7e5d94d91b) Boot0014* NVMe: WDC PC SN730 SDBPNTY-512G-1101 PciRoot(0x0)/Pci(0x2,0x4)/Pci(0x0,0x0)/NVMe(0x1,00-1B-44-8B-46-3A-AB-8F)....2.LN........ Boot0015* ATA HDD: VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600) Boot0016* ATA HDD1: VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f601) Boot0017* ATAPI CD: VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a354) Boot0018* USB HDD: VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803) Boot0019* USB FDD: VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49) Boot001A* USB CD: VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55) Boot001B* Lenovo Recovery System File(\EFI\Microsoft\Boot\lrsBootMgr.efi)从上面可以看到所有启动清单(Boot00xx)以及启动顺序(BootOrder)。可以看到压根没有refind。。而且还有Fedora(前天安装的,昨天格式化其分区,也删除了efi下的fedora目录。。)这说明卸载fedora不细致。。比较没有那个OS有一个说明书说怎么卸载自己。 Ubuntu和UOS都是deepin一个家伙自己整的(问我也不知道为什么),删了就gg,以前删过。。修复忘了,好像有帖子 删除多余的启动项(非必需)2.删除一个引导项 efibootmgr -b UEFIno -B 其中UEFIno为删除引导项对应标号,可以通过直接使用efibootmgr指令可以查看当前EFI启动顺序及标号。 Linux下UEFI启动项的管理命令efibootmgr介绍 NaiveYoungPeo 上面说了fedora是多余的对于Boot0004* Fedora HD(1,GPT,171ffb3e-6c37-4801-8b11-3ba3cea2e27a,0x800,0x82000)/File(\EFI\fedora\shimx64.efi): 开头的编号是0004 sudo efibootmgr -b 0004 -B辣么首先要查看硬盘设备名称 sudo fdisk -l
添加一个引导项 efibootmgr -c -w -L “BootOptionName” -d /dev/sda -p 1 -l \EFI\refind\refind_x64.efi -L参数 中BootOptionName 为 自定义启动项名称 -d 参数后面是系统所在的硬盘设备名称,例如/dev/hda、/dev/hdb -p 参数是vfat 分区的分区编号/dev/hda1 用-p 1 -l 参数后面是该引导项指向的efi 启动文件在该分区上的位置。请注意使用“\”来表示目录的分级。 Linux下UEFI启动项的管理命令efibootmgr介绍 NaiveYoungPeo sudo efibootmgr -c -w -L "rEFind" -d /dev/nvme0n1 -p 1 -l \boot\efi\EFI\EFI\refind\refind_x64.efi sudo efibootmgr -c -w -L "rEFind" -d /dev/nvme0n1 -p 1 -l \EFI\EFI\refind\refind_x64.efi sudo efibootmgr -c -w -L "rEFind" -d /dev/nvme0n1 -p 1 -l \\EFI\\EFI\\refind\\refind_x64.efi sudo efibootmgr -c -w -L "rEFind" -d /dev/sda1 -p 1 -l \\EFI\\EFI\\refind\\refind_x64.efi绝了,怀疑人生 There have been a number of reports that if the NVRAM is more than 50% used, the efibootmgr will fail because there’s a concern about being able to garbage collect EFI variables properly, or some such. Unfortunately, I couldn’t find a clear way to determine the used/free space in NVRAM, so I’m going on suspicion. There are a number of potential solutions to this: Clear the dump files grub stores efi logs in /sys/fs/efi/efivars/dump-* Try deleting these to see if that’s enough to bring the used space down. Then run apt -f install to see if the error has changed. BIOS upgrade If your hardware provider has a BIOS/EFI upgrade, then I’d recommend doing that also, then try apt -f install again. LAST RESORT - DISABLE EFI CHECK It’s a little dangerous, because you could technically fill your NVRAM to a point were it’s unbootable. However, I have used this process successfully on a Dell R420. To override the check, add “efi_no_storage_paranoia” to the kernel option. To do this: Append “efi_no_storage_paranoia” to the GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX variables in /etc/default/grub Update grub by running sudo update-grub Reboot Run apt -f install For safety, I reverse this process afterward also. Kernel safety override parameters are not something you want to leave lying around! Could not prepare Boot variable: No space left on device grub-install: error: efibootmgr failed to register the boot entry: Input/output error
重启 see rEFind配置忽略项以及主题~win/deepin/arch – update-grub:未找到命令 Kearney form An idea 2021-02-21 referThe rEFInd Boot Manager:Keeping rEFInd Booting The rEFInd Boot Manager by Roderick W. Smith, [email protected] 下载地址:https://sourceforge.net/projects/refind/ reEFInd(refind)引导Windows+deepin双系统 a__flying__fish:linux失败。。未解决,用win UEFI/GPT 模式下使用 rEFInd 引导 Win10 & Linux 双系统的方案:对启动efi做了很好的解释 Linux下UEFI启动项的管理命令efibootmgr介绍 NaiveYoungPeo 用efibootmgr管理UEFI启动项,添加丢失的启动项 https://www.cnblogs.com/busui/p/10758441.html 为了修补**efibootmgr **错误,我们首先挂载Boot variables: # mount -t efivarfs efivarfs /sys/firmware/efi/efivars 然后efibootmgr返回空间不足的信息: Could not prepare Boot variable: No space left on device 删除dump文件(也就是清除NVROM中的无效/垃圾项): # rm /sys/firmware/efi/efivars/dump-* 然后在root模式下(或者普通用户用sudo来更新grub): update-grub grub-install -v --target=x86_64-efi --recheck /dev/sda
efibootmgr: Could not set variable Boot0004: No space left on device I thought, is my /boot partition filled up? or my / is filled up so early. Had to even extend my /boot partition to see if it resolves this, but to no avail. Finally got it fix by clearing contents in /sys/fs/pstore as it was filled with grub logs. Clear by typing $ sudo rm /sys/fs/pstore/* Run the grub command again and see it fixed $ sudo grub-install /dev/sdaX Hope this helps…
fibootmgr: Could not prepare Boot variable: No space left on device It’s quite likely not a problem with the ESP on /boot/efi, but maybe a problem with the variable storage space on your computer. What make and model are you using? I’m also curious about the command line you’re using. I’d expect to see something more like: efibootmgr -c -L debian -l \EFI\debian\grubx64.efi (maybe along with some other options). grub-install -v will show you exactly what commands grub is trying to use. sudo grub-install -v
rEFind配置忽略项以及主题~win/deepin/arch – update-grub:未找到命令 Kearney form An idea 2021-02-21 End |
CopyRight 2018-2019 实验室设备网 版权所有 |