You are not logged in.
Hello,
I'm trying to reinstall Arch along side Windows 10. The problem here is after I installed arch and reboot for the second time, grub is gone from the boot menu.
drive info:
Disk /dev/sda: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST1000DM003-1CH1
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: 9B27AF13-E87B-4367-9428-2BA90F4E4011
Device Start End Sectors Size Type
/dev/sda1 2048 1050623 1048576 512M EFI System
/dev/sda2 590350336 590383103 32768 16M Microsoft reserved
/dev/sda3 590383104 1953523711 1363140608 650G Microsoft basic data
/dev/sda4 1050624 68159487 67108864 32G Linux root (x86-64)
/dev/sda5 68159488 101713919 33554432 16G Linux swap
/dev/sda6 101713920 590350335 488636416 233G Linux homeSteps I took to install grub:
mnt /dev/sda4 /mnt
mnt /dev/sda1 /mnt/efi
arch-chroot /mnt
grub-install --target=x86_64-efi --boot-directory=/boot --efi-directory=/efi --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg
exit
umount -R /mnt
rebootI also tried to enable boot option manually via efibootmgr:
efibootmgr -v
BootCurrent: 0012
Timeout: 1 seconds
BootOrder: 0011,0012,000F,0000
Boot0000 GRUB VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot000F Windows Boot Manager VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)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.}....................
Boot0011* UEFI: ST1000DM003-1CH162 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/HD(1,GPT,096be387-6c33-2047-b92c-4e840996dc5c,0x800,0x100000)AMBO
Boot0012 UEFI: Generic-SD/MMC/MS/MSPRO 1.00 PciRoot(0x0)/Pci(0x1a,0x0)/USB(1,0)/USB(5,0)/SCSI(0,4)/HD(1,MBR,0x5d84088,0xa4,0x20000)AMBO
efibootmgr -b 0 -aBut that didn't work as it did not show up in the menu & after reboot and checking efibootmgr it was disabled again.
Offline
What's the mainboard? Some only allow adding new entries via their own UEFI interface, others don't really support custom entries at all. What should work regardless is using that grub-install command and adding a --removable that way the standard /EFI/BOOT/BOOTx64.efi path is populated which every UEFI should be able to boot. That does have the caveat that that location might be overriden by Windows updates so you might have to be wary of that
Offline
I can't find the specific motherboards name because I think it only ship's with Acers Predator G3620 series.
I should also mention that it worked previously before I messed up my partitions. I deleted the EFI partition by accident. I fixed it by booting into windows from a live usb and install the EFI on a new EFI partition as listed in my previous post from fdsk -l /dev/sda1.
I tried out the --removable option but it didn't even show up in the boot menu. Normally without the --removable the first boot I can see the GRUB option but after the second reboot it's gone.
Last edited by archuser7465 (2020-06-07 15:42:01)
Offline
Yes acers are notorious for that, you have to add an entry in it's own firmware. What you might have to do to enable said option to add your own entry is to enable secure boot -> go back into the firmware -> mark a firmware as trusted -> select the GRUB binary -> save -> go back in -> disable secure boot.
Offline
try rebooting again with instalation driver, and mount again all and enter there with "arch-chroot /mnt", then install this "pacman -S os-prober" then install grub again with "grub-install /dev/sdx" and then reconfigure it "grub-mkconfig -o /boot/grub/grub.cfg" and "mkinitcpio -P"
Offline
Isn't the EFI partition supposed to mounted at /boot/EFI not /boot/efi?
Linux is simple, but it takes a genius to understand it
Offline
@sanbope your instructions don't work and are irrelevant on an UEFI system
@supermario9590 It does not matter - at all - for the process of booting where you end up mounting your ESP. It has to be present one time, when you add your boot loaders files to it, or in the case of not using GRUB but e.g. systemd-boot or efistub instead every time the kernel is updated, which is easiest done by mounting it to /boot but this doesn't matter here, from that aspect archuser745 did everything properly. Think about it for a second, we are talking about the process that happens before any operating system is loaded, it cannot have a relevance where your installed system ends up mounting the partition.
Last edited by V1del (2020-06-09 16:26:48)
Offline