MX17.1 64bit install crashes at installing grub

[jajk]

I am trying to install MX17.1 64 bit (June update version) onto an Acer ES1-533-C2UM Laptop with UEFI only BIOS (no legacy mode available).
I have disabled Secure Boot in BIOS.
The installation to hard drive goes smoothly until I get to the installing Grub to ESP point, at which it crashes shortly after commencing.
This happens whether I try to install MX17.1 as the only O.S or if I try with Win10 already installed (with fastboot disabled).
Reading through the Wiki article on UEFI problems does not help me get past this roadblock.
Any advice appreciated.....

[Adrian]

We had some issues with the installer, can you please try to update it before installing (apt-get update; apt-get dist-upgrade) and let us know if you still see the problem? Or let me know if you already tried that.
Alternatively, as a workaround you could install without installing GRUB and then use MX Bootrepair to install it.

[jajk]

Further investigation found that crash occurs when grub tries to update nvram so manually installing grub through terminal with --n-nvram switch gets past this hurdle and onto the next.....
Seems to be a common problem on many Acer and Lenova trash laptops that are trying to lock users in to a miserable existence on Win10 without making this known
This is the script I found on another forum which works to a point:

Code: Select all

    Mount newly installed file system on /mnt:
(where sda2 is the root partition and sda1 is the EFI system partition)

mount /dev/sda2 /mnt
mkdir /mnt/boot/efi
mount /dev/sda1 /mnt/boot/efi
for i in /dev /dev/pts /proc /sys; do mount -B $i /mnt$i; done

    Load efivars by:

modprobe efivars

    Reinstall grub-install for a 64-bit version

apt-get install --reinstall grub-efi-amd64
grub-install --no-nvram --root-directory=/mnt

    Change root to /mnt and update grub

chroot /mnt
update-grub

    Move and rename the installed bootloader

cd /boot/efi/EFI
cp -R mx/* BOOT/
cd BOOT
cp grubx64.efi bootx64.efi

So two problems are solved so far:

• Attempt to update nvram causes crash
  grubx64.efi filename not recognized as the boot file - must be changed to bootx64.efi to mimic Win10

Now I can get as far as booting into grub from the hard drive but it is still missing the config file. update-grub command ends with an EOF error. So the remaining question (hopefully) is how to get the config file in the right location with the right contents???

@Adrian MX Bootrepair does not work in this situation as there is no ability to add a switch to turn off nvram updating so it simply crashes.
Have not tried to update the installer yet but will give that a go if nothing else is going to work

[jajk]

@ Adrian Fresh install with freshly updated distribution results in the same problems - nothing changes.

[Adrian]

@ Adrian Fresh install with freshly updated distribution results in the same problems - nothing changes.

Thanks, it's a different problem than I initially assumed, I will take a closer look at nvram update issue.

[jajk]

O.K let's narrow down the problem to not being able to generate a working config file for grub.
Can anyone provide me with a working example and the correct path to put it in for UEFI booting MX17.1 64bit?
My scenario is efi is sda1, root is sda2. I can easily edit an example to fit the task - just need an example to get me close

[fehlix]

O.K let's narrow down the problem to not being able to generate a working config file for grub.
Can anyone provide me with a working example and the correct path to put it in for UEFI booting MX17.1 64bit?
My scenario is efi is sda1, root is sda2. I can easily edit an example to fit the task - just need an example to get me close

You don't need to reinstall the grub-package via apt again only to trigger the grub-install.
IMHO, the --root-directory option you used is outdated.
You might just generate the grub-efi-bootloader grub64.efi
as such:

Code: Select all

grub-install --no-nvram --target=x86_64-efi --efi-directory=/mnt/boot  --boot-directory=/mnt/boot 

and would get the GRUB-menu generated
either way, like this:

Code: Select all

grub-mkconfig -o /mnt/boot/grub/grub.cfg

or after

Code: Select all

chroot /mnt
grub-mkconfig -o /boot/grub/grub.cfg

Don't think you need evivars, as you are not updating the "boot-device/Boot*" NVRAM variables, anyway.

[jajk]

@fehlix Thanks for the insight. I already figured to skip over the apt-get and yes, the --root-directory switch is obsolete and efivars is not needed
I will try your suggestions and report back

[jajk]

@fehlix I have had success using your suggestions thanks.
chroot /mnt
grub-mkconfig -o /boot/grub/grub.cfg is the one that worked for me.
Not as straightforward as expected.....new grub.cfg file gets named grub.cfg.new and does not work until renamed back to grub.cfg
I now have to work out where a long delay during boot is coming from between loading initial ramdisk... and gave up waiting for suspend/resume device

[jajk]

Latest round of updates have fixed the long delay during boot so I am happily running MX17.1 on this laptop even though Acer seemed to go to some lengths to prevent anything other than Win10 being installed.
I refuse to be herded and will avoid Acer in the future for dancing with the devil. When I first read about UEFI, I thought to myself "Here we go...Intel and Microsoft up to their usual tricks again" and I was correct - one more turn of the screw