You are not logged in.
Pages: 1
Hello, I am pretty new to Arch and love it so far. After 10 years of experience with Debian based systems I am glad to be on a rolling release now ![]()
I installed Arch on my machine and had just finished configuration when I rebooted and got presented with the UEFI(BIOS) menu. The Micron_M600_MTFD SSD was not recognized by the system anymore. Not in SATA settings and also not in Boot settings.
I had switched off secure boot mode prior to installing Arch. After consulting google for quite some time, I tried enabling "Launch CSM" (Compatibility Support Module or BIOS legacy mode) in the Asus Aptio UEFI settings. But still the SSD would not show up. I brought the machine back to the shop and they exchanged it for a new one which I received the next day.
In the meantime I tried to read everything I could find about UEFI, CSM, Secure Boot and found some very good resources:
http://www.rodsbooks.com/efi-bootloader … -ugly.html
http://www.rodsbooks.com/efi-bootloader … eboot.html
Of course, I read through the Arch wiki UEFI, systemd-boot articles.
When I got the new machine I wiped Win10 and installed Arch again and configured the system to my liking.
I again followed the Beginner's Guide and everything went smoothly.
EFI boot partition is on /dev/sda1 mounted to /boot (I use the original EFI partition that still has the Windows boot loader on it)
After working for 4 days with it, I rebooted and got presented with blue/white UEFI screen again.
This time, after enabling "Launch CSM" in Aptio UEFI setup tool, my SSD was visible again but the UEFI had lost the boot option for Arch so I added it back again and was able to reboot into my Arch install.
I then went and disabled CSM mode and it booted into Arch just fine in UEFI mode.
I have no idea what causes this behaviour. I suspect it might have to do with my hardware requiring to use secure boot, but this is just a wild guess. Anyways, I installed prebootloader, followed the instructions here and can now boot Arch with secure boot enabled.
Now I am hoping that the problem won't reappear. If anyone has any idea what could cause this problem, please drop a note here. Thank you for reading through all of this.
EDIT: Before choosing Arch for that laptop, I reassured that other people are running it successfully with that hardware:
https://wiki.archlinux.org/index.php/AS … tness_Keys
http://neugierig.org/software/blog/2015 … ux305.html
Last edited by gebeer (2015-12-25 11:10:43)
Offline
Just some update on this issue. The machine is still loosing its SSD and custom boot options in the UEFI from time to time. I can then recover by switching to CSM mode.
I am using the machine stationary. I have an external display connected through micro HDMI port all the time (so also on boot).
I now discovered that this device gets boot priority over my SSD sometimes in UEFI and then my custom boot option for arch disappers and I have to manually re-add it again.
There is an UEFI setting "BBS Priorities" where you can define which hardware device gets priority during boot. The UEFI listed my HDMI display as the top priority device. I now set my SSD there for the highest priority.
Not sure though if this will really help...
Offline
Not in SATA settings
Well in that case Arch forum is probably not good enough for you. You should contact ASUS or Micron customer support.
Offline
Thank you for the suggestion.
I already contacted their technical support. Answers from Asus were more of the standard type, like contact your next service center blabla. But I am still in contact with them and will follow up and report here.
Micron has not responded at all within the last 5 days.
The reason why I posted here is that I wanted to rule out that the problem is related to wrong UEFI setup when installing Arch. But since I have my bootloader in the right place and even secure boot is working, I think it is a hardware or UEFI related issue, too.
Offline
Update:
I received an email from Asus technical support where they say:
Generally speaking, we suggest you to enable CSM in BIOS if you install Linux OS.
I don't think that applies to Arch as it fully supports UEFI boot. Am I right here?
I also was able to sign the boot loader and kernel and then boot with secure boot enabled.
Offline
It doesn't apply to any distro. IMHO they only say that because they don't know about Linux or do not want to bother discussing Secure Boot. In my experience it isn't difficult to disable Secure Boot on ASUS boards though.
Anyway. That's not relevant. As I've said, if you cannot see your UEFI found the drive under SATA settings, it has nothing to do with CSM/Linux/whatsoever, it's just either the board or the drive is borked. You should simply take a pic of that and send it to ASUS instead of telling them it's "booting/Linux issue". It only let them make pointless excuses.
But I guess you need to make sure it's the drive that is broken first after all. Otherwise ASUS probably wouldn't give a damn.
Offline
I only sometimes cannot see the SSD in UEFI SATA settings. When I then switch to CSM, it appears again. Then I can switch back to UEFI mode and the SSD still is there and I can boot after re-adding the Arch boot option.
I explained this to Asus and they have no answer for that. I think, most likely their BIOS has some bugs.
Offline
I've been dealing with some boot problems regarding uefi implemantation on a msi motherboard. Boot entries would sometimes be gone all of a sudden, BBS priority randmomly changing. For a while I've been chrooting regularly to fix refind, very annoying.
Solution in my case was to open up my box, and plug in my SATA cables into "1 and 2" instead of "3 and 4" .....looks like no big deal, but atm I think indeed that uefi implementations can be buggy. In your case, maybe a bios update ?
Offline
I've been dealing with some boot problems regarding uefi implemantation on a msi motherboard. Boot entries would sometimes be gone all of a sudden, BBS priority randmomly changing.
That is exactly the same behaviout that I experience.
Only that Windows boot option is automagically added back by UEFI whilst I have to add Arch boot option back manually. Think I will trash the Win boot loader as I don't need it anymore on an Arch-only box.
Unfortunately I can't plug the SSD into a different SATA port without losing warranty on opening up my ultrabook ![]()
UEFI says there are 4 ports but I don't even know whether I can switch the SSD from its current port to a different one.
I believe more and more that the problems are related to a buggy UEFI/BIOS. Will wait for the next update (if there ever is one) and see if it goes better then.
Last edited by gebeer (2016-01-05 06:09:12)
Offline
You mind pasting the output of `ls -l /boot/efi/boot` (switch to uppercase when necessary)?
Offline
@tom.ty89 thanks for looking onto this.
My boot option in UEFI loads /boot/EFI/systems/loader.efi
ls -l /boot/EFI/Boot/
-rwxr-xr-x 1 root root 101160 Dec 25 16:51 bootx64.efi
-rwxr-xr-x 1 root root 80142 Dec 25 16:50 bootx64.efi.backup
-rwxr-xr-x 1 root root 100656 Dec 25 16:49 HashTool.efi
-rwxr-xr-x 1 root root 80142 Dec 25 16:50 loader.efi
I'm using systemd boot:
ls -l /boot/EFI/systemd/
-rwxr-xr-x 1 root root 100656 Dec 25 17:00 HashTool.efi
-rwxr-xr-x 1 root root 130057 Dec 25 17:00 KeyTool.efi
-rwxr-xr-x 1 root root 80142 Nov 26 03:13 loader.efi
-rwxr-xr-x 1 root root 101160 Dec 25 17:00 PreLoader.efi
and the Win boot loaders:
ls -l /boot/EFI/Microsoft/Boot/
-rwxr-xr-x 1 root root 32768 Dec 19 22:49 BCD
-rwxr-xr-x 1 root root 28672 Oct 12 21:36 BCD.LOG
-rwxr-xr-x 1 root root 0 Oct 12 21:36 BCD.LOG1
-rwxr-xr-x 1 root root 0 Oct 12 21:36 BCD.LOG2
drwxr-xr-x 2 root root 4096 Oct 12 21:36 bg-BG
-rwxr-xr-x 1 root root 1155424 Jul 24 02:31 bootmgfw.efi
-rwxr-xr-x 1 root root 1152864 Jul 24 02:31 bootmgr.efi
-rwxr-xr-x 1 root root 65536 Oct 12 21:36 BOOTSTAT.DAT
-rwxr-xr-x 1 root root 4247 Jul 10 10:00 boot.stl
-rwxr-xr-x 1 root root 80142 Dec 25 15:24 bootx64.efi
drwxr-xr-x 2 root root 4096 Oct 12 21:36 cs-CZ
drwxr-xr-x 2 root root 4096 Oct 12 21:36 da-DK
drwxr-xr-x 2 root root 4096 Oct 12 21:36 de-DE
drwxr-xr-x 2 root root 4096 Oct 12 21:36 el-GR
drwxr-xr-x 2 root root 4096 Oct 12 21:36 en-GB
drwxr-xr-x 2 root root 4096 Oct 12 21:36 en-US
drwxr-xr-x 2 root root 4096 Oct 12 21:36 es-ES
drwxr-xr-x 2 root root 4096 Oct 12 21:36 es-MX
drwxr-xr-x 2 root root 4096 Oct 12 21:36 et-EE
drwxr-xr-x 2 root root 4096 Oct 12 21:36 fi-FI
drwxr-xr-x 2 root root 4096 Oct 12 21:36 Fonts
drwxr-xr-x 2 root root 4096 Oct 12 21:36 fr-CA
drwxr-xr-x 2 root root 4096 Oct 12 21:36 fr-FR
drwxr-xr-x 2 root root 4096 Oct 12 21:36 hr-HR
drwxr-xr-x 2 root root 4096 Oct 12 21:36 hu-HU
drwxr-xr-x 2 root root 4096 Oct 12 21:36 it-IT
drwxr-xr-x 2 root root 4096 Oct 12 21:36 ja-JP
-rwxr-xr-x 1 root root 29024 Jul 10 09:59 kd_02_10df.dll
-rwxr-xr-x 1 root root 324960 Jul 10 09:59 kd_02_10ec.dll
-rwxr-xr-x 1 root root 13312 Jul 10 09:59 kd_02_1137.dll
-rwxr-xr-x 1 root root 211808 Jul 10 09:59 kd_02_14e4.dll
-rwxr-xr-x 1 root root 35168 Jul 10 09:59 kd_02_15b3.dll
-rwxr-xr-x 1 root root 38752 Jul 10 09:59 kd_02_1969.dll
-rwxr-xr-x 1 root root 29024 Jul 10 09:59 kd_02_19a2.dll
-rwxr-xr-x 1 root root 196448 Jul 10 09:59 kd_02_8086.dll
-rwxr-xr-x 1 root root 17248 Jul 10 09:59 kd_07_1415.dll
-rwxr-xr-x 1 root root 36704 Jul 10 09:59 kd_0C_8086.dll
-rwxr-xr-x 1 root root 15200 Jul 10 09:59 kdstub.dll
drwxr-xr-x 2 root root 4096 Oct 12 21:36 ko-KR
drwxr-xr-x 2 root root 4096 Oct 12 21:36 lt-LT
drwxr-xr-x 2 root root 4096 Oct 12 21:36 lv-LV
-rwxr-xr-x 1 root root 1021792 Jul 24 02:32 memtest.efi
drwxr-xr-x 2 root root 4096 Oct 12 21:36 nb-NO
drwxr-xr-x 2 root root 4096 Oct 12 21:36 nl-NL
drwxr-xr-x 2 root root 4096 Oct 12 21:36 pl-PL
drwxr-xr-x 2 root root 4096 Oct 12 21:36 pt-BR
drwxr-xr-x 2 root root 4096 Oct 12 21:36 pt-PT
drwxr-xr-x 2 root root 4096 Oct 12 21:36 qps-ploc
drwxr-xr-x 4 root root 4096 Oct 12 21:36 Resources
drwxr-xr-x 2 root root 4096 Oct 12 21:36 ro-RO
drwxr-xr-x 2 root root 4096 Oct 12 21:36 ru-RU
drwxr-xr-x 2 root root 4096 Oct 12 21:36 sk-SK
drwxr-xr-x 2 root root 4096 Oct 12 21:36 sl-SI
drwxr-xr-x 2 root root 4096 Oct 12 21:36 sr-Latn-CS
drwxr-xr-x 2 root root 4096 Oct 12 21:36 sr-Latn-RS
drwxr-xr-x 2 root root 4096 Oct 12 21:36 sv-SE
drwxr-xr-x 2 root root 4096 Oct 12 21:36 th-TH
drwxr-xr-x 2 root root 4096 Oct 12 21:36 tr-TR
drwxr-xr-x 2 root root 4096 Oct 12 21:36 uk-UA
drwxr-xr-x 2 root root 4096 Oct 12 21:36 zh-CN
drwxr-xr-x 2 root root 4096 Oct 12 21:36 zh-HK
drwxr-xr-x 2 root root 4096 Oct 12 21:36 zh-TW
I followed https://wiki.archlinux.org/index.php/Un … led_system to setup secure boot and copied the prebootloader files to 2 dirs Boot/ and systemd/
Last edited by gebeer (2016-01-05 08:14:23)
Offline
FWIW when you have \EFI\BOOT\BOOTX64.EFI on the ESP, the UEFI should always locates it and generates an boot entry upon booting (and most UEFI do that also for \EFI\Microsoft\Boot\bootmgfw.efi), which means normally, even if you removed all the boot entries with `efibootmgr` in Linux and reboot, you should still see a boot entry generated for each of those two efi binaries. If you do not experience this, I can already say that your UEFI has a bug.
EDIT: but it might get tricky if both of them exists on the same ESP though, so if you do not have Windows on that drive anymore, you should probably (re)move \EFI\Microsoft and see if the behaviour changes.
But your case is a bit special because your drive can disappear from SATA settings, so you need to make sure that the drive is found, but just the UEFI does not register \EFI\BOOT\BOOTX64.EFI automatically.
And of course we assume that \EFI\BOOT\BOOTX64.EFI is a valid efi binary.
Btw it does not really make sense to say that "my hardware requires secure boot to work" when there is an option in the UEFI for you to disable it (if you're saying Windows does not boot with it disabled, that's another story). So if I were you I wouldn't bother to try the prebootloader thing to introduce even more variables to the issue.
Last edited by tom.ty89 (2016-01-05 08:52:32)
Offline
Very enlightning info, thanks again.
I setup the secure boot just to see if it would work because I hadn't done it before. And it worked fine. Now I boot with secure boot disabled again for some time and it is working just fine.
Was not sure whether I can savely remove the whole /boot/EFI/Microsoft/ dir.
Honestly, I'm not sure anymore where /boot/EFI/Boot/bootx64.efi came from. I might have created that when messing with prebootloader.
Anyways, I will experiment some more and get back here. Thanks again.
Offline
Update:
I was asking Asus tech support if they have documented somewhere that Linux should be run in CSM mode.
Here's their answer:
Thank you for so detailed information. ASUS notebook is Microsoft's operating system supported. We couldn't ensure if it can work properly on Linux OS. But from personal experience and the feedback from other customer tried Linux, enable CSM is recommended. If your Linux can support UEFI mode, it is supposed to be supported when disabale CSM.
Whatever this means, in the end it does not really help to solve my problem.
Offline
My suggestion would be simply remove the whole /boot/EFI and all boot entries one by one with `efibootmgr -B -b XXXX`, and then reinstall systemd-boot with `bootctl install`. Reboot and check how many UEFI boot entries you got in the boot menu of your UEFI and in `efibootmgr` after it booted up.
Last edited by tom.ty89 (2016-01-05 12:17:46)
Offline
My suggestion would be simply remove the whole /boot/EFI and all boot entries one by one with `efibootmgr -B -b XXXX`
A word of caution: I advised a Debian user to try something similar over at forums.debian.net and it bricked his/her laptop.
See http://forums.debian.net/viewtopic.php?f=30&t=126338
The eventual solution was to remove the CMOS battery in the motherboard to reset the NVRAM entries.
EDIT: Would backing up the contents of /sys/firmware/efi/efivars be a sensible thing to do?
Last edited by Head_on_a_Stick (2016-01-05 12:24:21)
Jin, Jîyan, Azadî
Offline
@Head_on_a_Stick
thank you for that hint. I was already reading efibootmgr man page when your message came in.
Now I think I'm just going to wait if the problem occurs again and then maybe reinstall systemd boot.
ATM I need this machine for work...
Offline
I don't really know how you can backup (and restore) efivars...neither do I ever wanted that.
I am not convinced removing boot entries can brick a UEFI. I mean, if one could get bricked, it can be bricked by any kind of touch ![]()
Though it's true that personally I prefer rm /sys/firmware/efi/efivars/* over "wiping" it "partially" with efibootmgr, even when that would revert all the UEFI settings to default.
Offline
Pages: 1