Date: Wed, 12 Apr 2017 12:48:55 -0700 From: "Chris H" <bsd-lists@bsdforge.com> To: <freebsd-current@freebsd.org> Subject: Re: r316677:EFI boot failure: Can't load kernel Message-ID: <f5cca229ae70c6b2cce978438e650a27@ultimatedns.net> In-Reply-To: <20170411.234252.2142525569522461055.ish@amail.plala.or.jp> References: <AC12F921-A8BE-496A-A482-31A24913B0B6@me.com> <20170410210404.001e544d@thor.intern.walstatt.dynvpn.de> <20170411071734.52017b27@hermann>, <20170411.234252.2142525569522461055.ish@amail.plala.or.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Apr 2017 23:42:52 +0900 (JST) Masachika ISHIZUKA <ish@amail.plala.or.jp> wrote > > replaced /boot/loader with /boot/loader.old (which was from end of > > March) > > > > copied /boot/loader.efi from the r315864 snapshot USB image > > into /boot/loader.efi of the broken systems. > > > > Aprt from the fact that I don't know which one is broken, the boxes are > > booting again. > > > > Conclusion: UEFI loader is broken! > > Hi. > > I'm using dell xps12 9q33 (core i7-4500U) with an internal SSD. > As reporting Bug 218473, I cannot boot /boot/loader.efi after > r316585. Replacing only loader.efi before r316584, I can boot > again. I was going to also report similar findings. After reporting the problem && submitting additional info to help diagnose the situation. I found that the most efficient way to overcome the issue, was to move loader.efi aside, and copy loader.efi from the install DVD. I've since lowered the priority of (u)efi in the BIOS, taking legacy as the higher priority. Because I had additional problems with vt. In the end, I find I have no issues simply booting to syscons(4) -- Xorg even works more harmoniously with it. :-) --Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f5cca229ae70c6b2cce978438e650a27>