You are not logged in.
Pages: 1
Hi,
first some information:
I have two disks, one Windows 10, one Arch (x86_64).
And current uefi version 3016: Asus H170M-Plus bios.
The arch root is encrypted (not boot).
Both disks have their own boot sections, i choose the os which i want to boot over the uefi.
What happens:
I just tried to boot my arch, after a time of around 3 month and updated uefi version, again and it just shows a black screen for a second and then switched immediately back to the uefi.
What did i do then:
chroot into my arch
update keyring --> works without errors
force update the ttf-dejavu --> works without errors
update the rest --> works without errors
-> same result
chroot into my arch
mkinitcpio -p linux --> works without errors, at least the missing modules wd719x and aic94xx for fallback
mount -t efivarfs efivarfs /sys/firmware/efi/efivars
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck --debug --> no errors reporting
grub-mkconfig -o /boot/grub/grub.conf --> WARNING: Failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.
-> same result
What should i do now? Do you need more informations?
Should i replace the uefi with the older version (1805) again?
Ps:
Sorry if iam in the wrong forum part.
Iam not that linux pro.
Iam not a native english speaker.
Iam open to new things
Last edited by Iceflowre (2017-01-29 10:38:32)
Offline
Please post the output of:
# efibootmgr -v
This command can be run from any live environment.
Perhaps the firmware update has b0rked things, you could try copying the Arch .efi loader to the Windows loader location.
From the Arch live ISO image:
mount /dev/sdXY /mnt # replace XY with the letter & number of the Arch EFI system partition
mkdir -p /mnt/EFI/Microsoft/Boot
cp /mnt/EFI/grub/grubx64.efi /mnt/EFI/Microsoft/Boot/bootmgfw.efi
More on this technique here:
http://www.rodsbooks.com/efi-bootloader … ive-naming
EDIT: clarifications
Last edited by Head_on_a_Stick (2017-01-28 14:55:34)
Jin, Jîyan, Azadî
Offline
I don't know what to make of the error message that grub-mkconfig is giving you but I know what works for me and I think the trouble has to do with using 2 disks. Grub uses efibootmgr to make the boot entry in UEFI and it may not be over-riding the efibootmgr default of disk 1. I don't use grub and it doesn't sound like you need to either since you are choosing the boot option in UEFI. Do the arch-chroot with your root and ESP mounted. Use /boot for the ESP mount point. Run lsblk to make sure of your device id's. Then run this command:
#efibootmgr -d /dev/sdX -p Y -c -L "ArchLinux" -l \vmlinuz-linux -u "root=/dev/sdxZ initrd=/iinitramfs-linux.img"
Notes of using efibootmgr:
X=your linux drive ID
Y=your ESP partition number on the linux drive
Z=your root partition number on the linux drive
Note the use of backslash on the -l \vmlinuz-linux. That is telling UEFI the name of the UEFI executable to load, the linux kernel. Backslash is used because UEFI is loading the kernel from the ESP which is FAT32.
The -u parameter is used to pass kernel parameters including what the disk and partition ID's are for the root partition and the file name of the initial ramdisk.
I've never had to mount the efivar file system as you did.
Simple and Open
Offline
Please post the output of:
# efibootmgr -v
This command can be run from any live environment.
Perhaps the firmware update has b0rked things, you could try copying the Arch .efi loader to the Windows loader location.
From the Arch live ISO image:
mount /dev/sdXY /mnt # replace XY with the letter & number of the Arch EFI system partition mkdir -p /mnt/EFI/Microsoft/Boot cp /mnt/EFI/grub/grubx64.efi /mnt/EFI/Microsoft/Boot/bootmgfw.efi
More on this technique here:
http://www.rodsbooks.com/efi-bootloader … ive-naming
EDIT: clarifications
That works like a charm! Thank you very much!
Offline
Ah, excellent news
I don't suppose you would consider reporting this issue to your motherboard manufacturer?
The UEFI standard stipulates that the firmware should load $ESP/EFI/BOOT/BOOT{X64,IA32}.EFI automatically and your update has caused the motherboard to only load $ESP/EFI/Microsoft/Boot/bootmgfw.efi — this is in clear violation of the specification and should probably be reported as a bug.
Jin, Jîyan, Azadî
Offline
Pages: 1