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

2017-04-11 Thread 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: List test, please ignore.

2017-04-11 Thread Eric Joyner
Never!

On Tue, Apr 11, 2017 at 3:18 PM Sean Bruno  wrote:

> ignore
>
>
___
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"


List test, please ignore.

2017-04-11 Thread Sean Bruno
ignore



signature.asc
Description: OpenPGP digital signature


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

2017-04-11 Thread 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

2017-04-11 Thread 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: VNET branch destiny

2017-04-11 Thread peter . blok
Hi Kristof,

I’m prety sure it is the same as 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673 
. It is unrelated to 
epair or ng_eiface (my case).

I’ll dig some more.

Peter


> On 11 Apr 2017, at 08:47, Kristof Provost  wrote:
> 
> On 10 Apr 2017, at 12:10, peter.b...@bsd4all.org wrote:
>> There have been issues with pf if I recall correctly. I currently have 
>> issues with stable, pf and vnet. There is an issue with pf table entries 
>> when an interface is moved to a different vnet.
>> 
>> Does anyone no if there is a specific fix for this that hasn’t been ported 
>> to stable? I haven’t had the time to test this on current.
>> 
> I’m currently aware of at least some issues with pf and vnet, even in CURRENT.
> Not that one though, so can you make sure there’s a bug report with as much 
> detail as possible?
> Please also cc me (k...@freebsd.org) on the report.
> 
> Thanks,
> Kristof

___
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

2017-04-11 Thread 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"