Re: r316677:EFI boot failure: Can't load kernel

[Toomas Soome]

> On 12. apr 2017, at 22:48, Chris H  wrote:
> 
> On Tue, 11 Apr 2017 23:42:52 +0900 (JST) Masachika ISHIZUKA
> mailto:i...@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. :-)
> 

I believe we did identify the problem, the fix is posted as 
https://reviews.freebsd.org/D10381  please 
review, if you can confirm the fix by testing, it would also be really helpful 
- the issue is, the problem appears to be system specific and not always 
manifesting itself.

thanks,
toomas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r316677:EFI boot failure: Can't load kernel

[Toomas Soome]

> On 12. apr 2017, at 22:48, Chris H  wrote:
> 
> On Tue, 11 Apr 2017 23:42:52 +0900 (JST) Masachika ISHIZUKA
> mailto:i...@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. :-)
> 

We have progress with investigation, but testing has to confirm if the suspect 
is really it or not.

rgds,
toomas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r316677:EFI boot failure: Can't load kernel

[Chris H]

On Tue, 11 Apr 2017 23:42:52 +0900 (JST) Masachika ISHIZUKA
 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


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r316677:EFI boot failure: Can't load kernel

[Masachika ISHIZUKA]

>>  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.
> 
> Yea, it seems to be the same issue for both of you, now have some work to do 
> to identify why this does happen.
> 
> from loader prompt the lsdev -v output would be helpful - you can send it 
> directly, we do not need to spam the list:)

  Hi.

  I cannot lsdev because loader.efi was hung up before loader menu.

=
EFI console:
\  <--- hang up
=

  I can only reboot (ctrl-alt-del) for this hang up.
-- 
Masachika ISHIZUKA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r316677:EFI boot failure: Can't load kernel

[Toomas Soome]

> On 11. apr 2017, at 17:42, Masachika ISHIZUKA  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.
> -- 
> Masachika ISHIZUKA


Yea, it seems to be the same issue for both of you, now have some work to do to 
identify why this does happen.

from loader prompt the lsdev -v output would be helpful - you can send it 
directly, we do not need to spam the list:)

rgds,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r316677:EFI boot failure: Can't load kernel

[Masachika ISHIZUKA]

> 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.
-- 
Masachika ISHIZUKA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r316677:EFI boot failure: Can't load kernel

[Hartmann, O.]

On Mon, 10 Apr 2017 21:04:04 +0200
"O. Hartmann"  wrote:

> Am Mon, 10 Apr 2017 21:59:00 +0300
> Toomas Soome  schrieb:
> 
> > > On 10. apr 2017, at 21:04, O. Hartmann 
> > > wrote:
> > > 
> > > Am Mon, 10 Apr 2017 16:14:21 +0300
> > > Toomas Soome  schrieb:
> > > 
> > >>> On 10. apr 2017, at 15:58, Hartmann, O.
> > >>>  wrote:
> > >>> 
> > >>> After today's update to r316677, some UEFI boxes (Fujitsu
> > >>> Celsius M740 XEON) reject to boot properly. They die
> > >>> immediately after loading /boot/loader.efi and jump into loader
> > >>> prompt:
> > >>> 
> > >>> [...]
> > >>> \
> > >>> can't load 'kernel'
> > >>> 
> > >>> 
> > >>> I had to investigate with an USB flashdrive the filesystem, but
> > >>> everything seems to be properly in place and installed.
> > >>> 
> > >>> I need advice how to revive the system after this.
> > >>> 
> > >> 
> > >> 
> > >> hm, this implies that r316676 was ok? If so, the only logical
> > >> conclusion is that it hast to do about the kernel size and if
> > >> there is enough space in UEFI memory to place the kernel.
> > >> 
> > >> You can fetch the current memory map from loader OK prompt with
> > >> memmap command, I hope this will help to identify the issue.
> > >> 
> > >> rgds,
> > >> toomas
> > > 
> > > 
> > > And?
> > > 
> > > Regrads,
> > > 
> > > oh
> > > 
> > 
> > Well, the memory needed is starting from the:
> > 
> > #define KERNEL_PHYSICAL_BASE (2*1024*1024)
> > 
> > and it should be large enough for kernel. But it feels a bit like
> > barking under the random tree; the problem is that the error is not
> > telling us anything why it did happen:(
> > 
> > This message you get is coming from sys/boot/common/boot.c, as part
> > of the autoload sequence; did you try to load kernel manually with
> > load command? also if you have old kernel around, does old kernel
> > get loaded?
> > 
> > rgds,
> > toomas
> > 
> > 
> > 
> >   
> 
> I haven't done anything yet, since the accident happened when I left
> my bureau and I desperately tried to examine on the fly what happened.
> 
> I'll be at the box tomorrow morning and I will check whether I can
> load the old kernel manually.
> 
> I'll report in what happened.
> 
> Kind regards,
> 
> oh
> 

Sitting in front of the dead systems here, I checked for the
suggestions of yours. memmap doesn#t give me an insight - I'm not
familiar with the memory layout.

Issuing a "ls" shows only /

Also, we put an alternative UEFI boot loader onto the partition, taken
from the snapshot r315864 (/boot/boot1.efifat, dd'ed onto the EFI
partition) - with no success.

By the way, my EFI partition is 300MB in size - just for the record if
this is an issue.

The booting filesystems are UFS and residing on a SSD.

The point that the boot loader doens't see any folder structure but /
confuses me.

How to row back from this desaster?


Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r316677:EFI boot failure: Can't load kernel

[Hartmann, O.]

On Mon, 10 Apr 2017 21:04:04 +0200
"O. Hartmann"  wrote:

> Am Mon, 10 Apr 2017 21:59:00 +0300
> Toomas Soome  schrieb:
> 
> > > On 10. apr 2017, at 21:04, O. Hartmann 
> > > wrote:
> > > 
> > > Am Mon, 10 Apr 2017 16:14:21 +0300
> > > Toomas Soome  schrieb:
> > > 
> > >>> On 10. apr 2017, at 15:58, Hartmann, O.
> > >>>  wrote:
> > >>> 
> > >>> After today's update to r316677, some UEFI boxes (Fujitsu
> > >>> Celsius M740 XEON) reject to boot properly. They die
> > >>> immediately after loading /boot/loader.efi and jump into loader
> > >>> prompt:
> > >>> 
> > >>> [...]
> > >>> \
> > >>> can't load 'kernel'
> > >>> 
> > >>> 
> > >>> I had to investigate with an USB flashdrive the filesystem, but
> > >>> everything seems to be properly in place and installed.
> > >>> 
> > >>> I need advice how to revive the system after this.
> > >>> 
> > >> 
> > >> 
> > >> hm, this implies that r316676 was ok? If so, the only logical
> > >> conclusion is that it hast to do about the kernel size and if
> > >> there is enough space in UEFI memory to place the kernel.
> > >> 
> > >> You can fetch the current memory map from loader OK prompt with
> > >> memmap command, I hope this will help to identify the issue.
> > >> 
> > >> rgds,
> > >> toomas
> > > 
> > > 
> > > And?
> > > 
> > > Regrads,
> > > 
> > > oh
> > > 
> > 
> > Well, the memory needed is starting from the:
> > 
> > #define KERNEL_PHYSICAL_BASE (2*1024*1024)
> > 
> > and it should be large enough for kernel. But it feels a bit like
> > barking under the random tree; the problem is that the error is not
> > telling us anything why it did happen:(
> > 
> > This message you get is coming from sys/boot/common/boot.c, as part
> > of the autoload sequence; did you try to load kernel manually with
> > load command? also if you have old kernel around, does old kernel
> > get loaded?
> > 
> > rgds,
> > toomas
> > 
> > 
> > 
> >   
> 
> I haven't done anything yet, since the accident happened when I left
> my bureau and I desperately tried to examine on the fly what happened.
> 
> I'll be at the box tomorrow morning and I will check whether I can
> load the old kernel manually.
> 
> I'll report in what happened.
> 
> Kind regards,
> 
> oh
> 

I did the following:

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!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r316677:EFI boot failure: Can't load kernel

[O. Hartmann]

Am Mon, 10 Apr 2017 21:59:00 +0300
Toomas Soome  schrieb:

> > On 10. apr 2017, at 21:04, O. Hartmann  wrote:
> > 
> > Am Mon, 10 Apr 2017 16:14:21 +0300
> > Toomas Soome  schrieb:
> >   
> >>> On 10. apr 2017, at 15:58, Hartmann, O.  wrote:
> >>> 
> >>> After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740
> >>> XEON) reject to boot properly. They die immediately after
> >>> loading /boot/loader.efi and jump into loader prompt:
> >>> 
> >>> [...]
> >>> \
> >>> can't load 'kernel'
> >>> 
> >>> 
> >>> I had to investigate with an USB flashdrive the filesystem, but
> >>> everything seems to be properly in place and installed.
> >>> 
> >>> I need advice how to revive the system after this.
> >>>   
> >> 
> >> 
> >> hm, this implies that r316676 was ok? If so, the only logical conclusion 
> >> is that it
> >> hast to do about the kernel size and if there is enough space in UEFI 
> >> memory to place
> >> the kernel.
> >> 
> >> You can fetch the current memory map from loader OK prompt with memmap 
> >> command, I
> >> hope this will help to identify the issue.
> >> 
> >> rgds,
> >> toomas  
> > 
> > 
> > And?
> > 
> > Regrads,
> > 
> > oh
> >   
> 
> Well, the memory needed is starting from the:
> 
> #define KERNEL_PHYSICAL_BASE (2*1024*1024)
> 
> and it should be large enough for kernel. But it feels a bit like barking 
> under the
> random tree; the problem is that the error is not telling us anything why it 
> did
> happen:(
> 
> This message you get is coming from sys/boot/common/boot.c, as part of the 
> autoload
> sequence; did you try to load kernel manually with load command? also if you 
> have old
> kernel around, does old kernel get loaded?
> 
> rgds,
> toomas
> 
> 
> 
> 

I haven't done anything yet, since the accident happened when I left my bureau 
and I
desperately tried to examine on the fly what happened.

I'll be at the box tomorrow morning and I will check whether I can load the old 
kernel
manually.

I'll report in what happened.

Kind regards,

oh

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpHFWyMu1dZM.pgp
Description: OpenPGP digital signature

Re: r316677:EFI boot failure: Can't load kernel

[Toomas Soome]

> On 10. apr 2017, at 21:04, O. Hartmann  wrote:
> 
> Am Mon, 10 Apr 2017 16:14:21 +0300
> Toomas Soome  schrieb:
> 
>>> On 10. apr 2017, at 15:58, Hartmann, O.  wrote:
>>> 
>>> After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740
>>> XEON) reject to boot properly. They die immediately after
>>> loading /boot/loader.efi and jump into loader prompt:
>>> 
>>> [...]
>>> \
>>> can't load 'kernel'
>>> 
>>> 
>>> I had to investigate with an USB flashdrive the filesystem, but
>>> everything seems to be properly in place and installed.
>>> 
>>> I need advice how to revive the system after this.
>>> 
>> 
>> 
>> hm, this implies that r316676 was ok? If so, the only logical conclusion is 
>> that it
>> hast to do about the kernel size and if there is enough space in UEFI memory 
>> to place
>> the kernel.
>> 
>> You can fetch the current memory map from loader OK prompt with memmap 
>> command, I hope
>> this will help to identify the issue.
>> 
>> rgds,
>> toomas
> 
> 
> And?
> 
> Regrads,
> 
> oh
> 

Well, the memory needed is starting from the:

#define KERNEL_PHYSICAL_BASE (2*1024*1024)

and it should be large enough for kernel. But it feels a bit like barking under 
the random tree; the problem is that the error is not telling us anything why 
it did happen:(

This message you get is coming from sys/boot/common/boot.c, as part of the 
autoload sequence; did you try to load kernel manually with load command? also 
if you have old kernel around, does old kernel get loaded?

rgds,
toomas




___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r316677:EFI boot failure: Can't load kernel

[O. Hartmann]

Am Mon, 10 Apr 2017 16:14:21 +0300
Toomas Soome  schrieb:

> > On 10. apr 2017, at 15:58, Hartmann, O.  wrote:
> > 
> > After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740
> > XEON) reject to boot properly. They die immediately after
> > loading /boot/loader.efi and jump into loader prompt:
> > 
> > [...]
> > \
> > can't load 'kernel'
> > 
> > 
> > I had to investigate with an USB flashdrive the filesystem, but
> > everything seems to be properly in place and installed.
> > 
> > I need advice how to revive the system after this.
> >   
> 
> 
> hm, this implies that r316676 was ok? If so, the only logical conclusion is 
> that it
> hast to do about the kernel size and if there is enough space in UEFI memory 
> to place
> the kernel.
> 
> You can fetch the current memory map from loader OK prompt with memmap 
> command, I hope
> this will help to identify the issue.
> 
> rgds,
> toomas


And?

Regrads,

oh

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpkSoVAEEdcs.pgp
Description: OpenPGP digital signature

Re: r316677:EFI boot failure: Can't load kernel

[Toomas Soome]

> On 10. apr 2017, at 15:58, Hartmann, O.  wrote:
> 
> After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740
> XEON) reject to boot properly. They die immediately after
> loading /boot/loader.efi and jump into loader prompt:
> 
> [...]
> \
> can't load 'kernel'
> 
> 
> I had to investigate with an USB flashdrive the filesystem, but
> everything seems to be properly in place and installed.
> 
> I need advice how to revive the system after this.
> 


hm, this implies that r316676 was ok? If so, the only logical conclusion is 
that it hast to do about the kernel size and if there is enough space in UEFI 
memory to place the kernel.

You can fetch the current memory map from loader OK prompt with memmap command, 
I hope this will help to identify the issue.

rgds,
toomas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r316677:EFI boot failure: Can't load kernel

[Hartmann, O.]

After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740
XEON) reject to boot properly. They die immediately after
loading /boot/loader.efi and jump into loader prompt:

[...]
\
can't load 'kernel'


I had to investigate with an USB flashdrive the filesystem, but
everything seems to be properly in place and installed.

I need advice how to revive the system after this.

Thanks in advance,

Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"