From mboxrd@z Thu Jan 1 00:00:00 1970 X-Received: by 10.236.63.8 with SMTP id z8mr25505096yhc.15.1421722996172; Mon, 19 Jan 2015 19:03:16 -0800 (PST) X-BeenThere: voidlinux@googlegroups.com Received: by 10.50.66.194 with SMTP id h2ls1139386igt.18.gmail; Mon, 19 Jan 2015 19:03:16 -0800 (PST) X-Received: by 10.50.43.197 with SMTP id y5mr296807igl.17.1421722996030; Mon, 19 Jan 2015 19:03:16 -0800 (PST) Date: Mon, 19 Jan 2015 19:03:14 -0800 (PST) From: Antonio Malcolm To: voidlinux@googlegroups.com Message-Id: <572af14e-f30f-4a54-a4f0-329662bb21e1@googlegroups.com> In-Reply-To: <84a466b2-0c98-4e86-af50-b43547a5a09a@googlegroups.com> References: <28993ed0-596f-4b40-99c4-d665e6dead8e@googlegroups.com> <91d3c2bd-41e4-43ac-be32-942a03695cb3@googlegroups.com> <84a466b2-0c98-4e86-af50-b43547a5a09a@googlegroups.com> Subject: Re: Can't Achieve A Bootable Void Install On UEFI + BIOS RAID + mdadm MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2909_175773636.1421722994549" ------=_Part_2909_175773636.1421722994549 Content-Type: multipart/alternative; boundary="----=_Part_2910_1437485627.1421722994549" ------=_Part_2910_1437485627.1421722994549 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit BOOM GOES THE DYNAMITE! OK, concatenating my last few responses, to keep things organized, as I got this working, now. After much trial, error, and research, I think the issue may have been in the way my logic board's firmware detects bootable volumes and maintains their records in NVRAM- I'm on a Gigabyte logic board (Aorus X3 laptop), and Gigabyte's UEFI implementation is know to be a bit janky. In fact, while the following IS successful, the machine conveniently "FORGETS" it on reboot: efibootmgr --create --gpt --disk /dev/md126 --part 1 --label "Void Linux (GRUB)" --loader '\EFI\void_grub\grubx64.efi' However, as Manjaro's GRUB install works, and sticks, I started with that, then installed Void again, per my above procedure, which updates GRUB, without overwriting the directories Manjaro's GRUB installs. The difference, between the two, which stands out most, is the presence of a /BOOT/GRUBX64.EFI file, under /EFI. One issue which has been pointed out, not necessarily in buggy UEFI implementations, but on boards with Intel controllers (which my machine uses) is the seeking of directories in a case-sensitive manner. Nasty stuff. It might be fun to think, because it still works with Windows, maybe Intel has some conspiracy going on with them, but the reasoning is probably much dumber than that. In Manjaro's case, they have a fairly big and broad user base, so it makes sense for them to "plan for all scenarios". This benefited me, today, save for having to "clean" my boot directory, free of anything specific to their install (such as their linux 3.16 kernel images). If you like, I can give you a more detailed description of the the /boot directory, and, if you're up to it, you can adjust your GRUB install/bootloader setup for the next release. ALSO, as my procedure for rolling Void out on a BIOS RAID would likely work for most folks, without the troubles I had, I'm more than happy to clean up my notes, to add to the WIki, There were some additions I made to the dracut.conf, to assemble the array on startup. And, we can always add a footnote about the UEFI stuffs... ------=_Part_2910_1437485627.1421722994549 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
BOOM GOES THE DYNAMITE! OK, concatenating my last few resp= onses, to keep things organized, as I got this working, now.

After m= uch trial, error, and research, I think the issue may have been in the way = my logic board's firmware detects bootable volumes and maintains their reco= rds in NVRAM-
I'm on a Gigabyte logic board (Aorus X3 laptop), and Gigab= yte's UEFI implementation is know to be a bit janky.

In fact, while = the following IS successful, the machine conveniently "FORGETS" it on reboo= t:

efibootmgr --create --gpt --disk /dev/md126 --part 1 --label "Voi= d Linux (GRUB)" --loader '\EFI\void_grub\grubx64.efi'

However, as Ma= njaro's GRUB install works, and sticks, I started with that, then installed= Void again, per my above procedure, which updates GRUB, without overwritin= g the directories Manjaro's GRUB installs.
The difference, between the t= wo, which stands out most, is the presence of a /BOOT/GRUBX64.EFI file, und= er /EFI. One issue which has been pointed out, not necessarily in buggy UEF= I implementations, but on boards with Intel controllers (which my machine u= ses) is the seeking of directories in a case-sensitive manner. Nasty stuff.= It might be fun to think, because it still works with Windows, maybe Intel= has some conspiracy going on with them, but the reasoning is probably much= dumber than that.

In Manjaro's case, they have a fairly big and bro= ad user base, so it makes sense for them to "plan for all scenarios".
Th= is benefited me, today, save for having to "clean" my boot directory, free = of anything specific to their install (such as their linux 3.16 kernel imag= es).

If you like, I can give you a more detailed description of the = the /boot directory, and, if you're up to it, you can adjust your GRUB inst= all/bootloader setup for the next release.
ALSO, as my procedure for rol= ling Void out on a BIOS RAID would likely work for most folks, without the = troubles I had, I'm more than happy to clean up my notes, to add to the WIk= i, There were some additions I made to the dracut.conf, to assemble the arr= ay on startup. And, we can always add a footnote about the UEFI stuffs...
------=_Part_2910_1437485627.1421722994549-- ------=_Part_2909_175773636.1421722994549--