Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Apr 2017 06:51:17 +0200
From:      "Hartmann, O." <o.hartmann@walstatt.org>
To:        Toomas Soome <tsoome@me.com>
Cc:        "O. Hartmann" <ohartmann@walstatt.org>, FreeBSD CURRENT <freebsd-current@freebsd.org>
Subject:   Re: r316677:EFI boot failure: Can't load kernel
Message-ID:  <20170411065109.3c74c132@hermann>
In-Reply-To: <20170410210404.001e544d@thor.intern.walstatt.dynvpn.de>
References:  <20170410145846.73d4350a@hermann> <C72648F4-086A-45E5-AB3A-101DFA888E26@me.com> <20170410200440.5e70c172@thor.intern.walstatt.dynvpn.de> <AC12F921-A8BE-496A-A482-31A24913B0B6@me.com> <20170410210404.001e544d@thor.intern.walstatt.dynvpn.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 Apr 2017 21:04:04 +0200
"O. Hartmann" <ohartmann@walstatt.org> wrote:

> Am Mon, 10 Apr 2017 21:59:00 +0300
> Toomas Soome <tsoome@me.com> schrieb:
> 
> > > On 10. apr 2017, at 21:04, O. Hartmann <o.hartmann@walstatt.org>
> > > wrote:
> > > 
> > > Am Mon, 10 Apr 2017 16:14:21 +0300
> > > Toomas Soome <tsoome@me.com> schrieb:
> > >     
> > >>> On 10. apr 2017, at 15:58, Hartmann, O.
> > >>> <ohartmann@walstatt.org> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170411065109.3c74c132>