Boot failure - svn up from this morning

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Boot failure - svn up from this morning

andy-21
Hi:

I'm having a major problem after updating a 12-current machine today.
After buildworld/kernel/install cycle on reboot I'm getting the following
failure:

"/boot/kernel/kernel text=0xb7716f data=0x100548+0x398358
elf64_loadimage: read failed
can't load file '/boot/kernel/kernel': input/output error
can't load file '/boot/kernel/kernel': input/output error

OK boot kernel.old
elf64_loadimage: read failed
can't load file '/boot/kernel.old/kernel': input/output error
can't load file '/boot/kernel.old/kernel': input/output error"

I have never experienced this failure before, and don't know how to
proceed.  Any help recovering from this would be greatly appreciated.
Thanks in advance.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot failure - svn up from this morning

Chris H-2
On Thu, 2 Mar 2017 21:56:38 -0500 (EST) AN <[hidden email]> wrote

> Hi:
>
> I'm having a major problem after updating a 12-current machine today.
> After buildworld/kernel/install cycle on reboot I'm getting the following
> failure:
>
> "/boot/kernel/kernel text=0xb7716f data=0x100548+0x398358
> elf64_loadimage: read failed
> can't load file '/boot/kernel/kernel': input/output error
> can't load file '/boot/kernel/kernel': input/output error
>
> OK boot kernel.old
> elf64_loadimage: read failed
> can't load file '/boot/kernel.old/kernel': input/output error
> can't load file '/boot/kernel.old/kernel': input/output error"
>
> I have never experienced this failure before, and don't know how to
> proceed.  Any help recovering from this would be greatly appreciated.
> Thanks in advance.

I don't suppose you could post the output of
uname -a

and maybe a copy of dmesg(8) could you?

--Chris


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot failure - svn up from this morning

Enji Cooper

> On Mar 2, 2017, at 21:16, Chris H <[hidden email]> wrote:
>
> On Thu, 2 Mar 2017 21:56:38 -0500 (EST) AN <[hidden email]> wrote
>
>> Hi:
>>
>> I'm having a major problem after updating a 12-current machine today.
>> After buildworld/kernel/install cycle on reboot I'm getting the following
>> failure:
>>
>> "/boot/kernel/kernel text=0xb7716f data=0x100548+0x398358
>> elf64_loadimage: read failed
>> can't load file '/boot/kernel/kernel': input/output error
>> can't load file '/boot/kernel/kernel': input/output error
>>
>> OK boot kernel.old
>> elf64_loadimage: read failed
>> can't load file '/boot/kernel.old/kernel': input/output error
>> can't load file '/boot/kernel.old/kernel': input/output error"
>>
>> I have never experienced this failure before, and don't know how to
>> proceed.  Any help recovering from this would be greatly appreciated.
>> Thanks in advance.
>
> I don't suppose you could post the output of
> uname -a
>
> and maybe a copy of dmesg(8) could you?
That would be good, but I don’t know if it’s possible (the OP is noting that the boot is broken when executing loader(8)..).
-Ngie

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Boot failure - svn up from this morning

Chris H-2
On Thu, 2 Mar 2017 21:32:39 -0800 "Ngie Cooper (yaneurabeya)"
<[hidden email]> wrote

> > On Mar 2, 2017, at 21:16, Chris H <[hidden email]> wrote:
> >
> > On Thu, 2 Mar 2017 21:56:38 -0500 (EST) AN <[hidden email]> wrote
> >
> >> Hi:
> >>
> >> I'm having a major problem after updating a 12-current machine today.
> >> After buildworld/kernel/install cycle on reboot I'm getting the following
> >> failure:
> >>
> >> "/boot/kernel/kernel text=0xb7716f data=0x100548+0x398358
> >> elf64_loadimage: read failed
> >> can't load file '/boot/kernel/kernel': input/output error
> >> can't load file '/boot/kernel/kernel': input/output error
> >>
> >> OK boot kernel.old
> >> elf64_loadimage: read failed
> >> can't load file '/boot/kernel.old/kernel': input/output error
> >> can't load file '/boot/kernel.old/kernel': input/output error"
> >>
> >> I have never experienced this failure before, and don't know how to
> >> proceed.  Any help recovering from this would be greatly appreciated.
> >> Thanks in advance.
> >
> > I don't suppose you could post the output of
> > uname -a
> >
> > and maybe a copy of dmesg(8) could you?
>
> That would be good, but I don’t know if it’s possible (the OP is noting
> that the boot is broken when executing loader(8)..). -Ngie

Indeed. But that doesn't stop the OP from booting from the
install media. ;-) :-)

--Chris


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot failure - svn up from this morning

Alex Deiter-2
Hello,

The same issue with FreeBSD 12.0-CURRENT-r314563:

elf64_loadimage: could not read symbols - skipped!

http://picpaste.com/IMG_1764-vfZl1l5o.JPG

I suspect regression after:

Revision 314547 - Directory Listing
Modified Thu Mar 2 07:25:50 2017 UTC (25 hours, 54 minutes ago) by dexuan
loader.efi: reduce the size of the staging area if necessary

The loader assumes physical memory in [2MB, 2MB + EFI_STAGING_SIZE)
is Conventional Memory, but actually it may not, e.g. in the case
of Hyper-V Generation-2 VM (i.e. UEFI VM) running on Windows
Server 2012 R2 host, there is a BootServiceData memory block at
the address 47.449MB and the memory is not writable.

Without the patch, the loader will crash in efi_copy_finish():
see PR 211746.

The patch verifies the end of the staging area, and reduces its
size if necessary. This way, the loader will not try to write into
the BootServiceData memory any longer.

Thank Marcel Moolenaar for helping me on this issue!

The patch also allocates the staging area in the first 1GB memory.
See the comment in the patch for this.

PR: 211746
Reviewed by: marcel, kib, sephe
Approved by: sephe (mentor)
MFC after: 2 weeks
Sponsored by: Microsoft
Differential Revision:
https://reviews.freebsd.org/D9686

Alex Deiter
[hidden email]



> On 3 Mar 2017, at 09:20, Chris H <[hidden email]> wrote:
>
> On Thu, 2 Mar 2017 21:32:39 -0800 "Ngie Cooper (yaneurabeya)"
> <[hidden email]> wrote
>
>>> On Mar 2, 2017, at 21:16, Chris H <[hidden email]> wrote:
>>>
>>> On Thu, 2 Mar 2017 21:56:38 -0500 (EST) AN <[hidden email]> wrote
>>>
>>>> Hi:
>>>>
>>>> I'm having a major problem after updating a 12-current machine today.
>>>> After buildworld/kernel/install cycle on reboot I'm getting the following
>>>> failure:
>>>>
>>>> "/boot/kernel/kernel text=0xb7716f data=0x100548+0x398358
>>>> elf64_loadimage: read failed
>>>> can't load file '/boot/kernel/kernel': input/output error
>>>> can't load file '/boot/kernel/kernel': input/output error
>>>>
>>>> OK boot kernel.old
>>>> elf64_loadimage: read failed
>>>> can't load file '/boot/kernel.old/kernel': input/output error
>>>> can't load file '/boot/kernel.old/kernel': input/output error"
>>>>
>>>> I have never experienced this failure before, and don't know how to
>>>> proceed.  Any help recovering from this would be greatly appreciated.
>>>> Thanks in advance.
>>>
>>> I don't suppose you could post the output of
>>> uname -a
>>>
>>> and maybe a copy of dmesg(8) could you?
>>
>> That would be good, but I don’t know if it’s possible (the OP is noting
>> that the boot is broken when executing loader(8)..). -Ngie
>
> Indeed. But that doesn't stop the OP from booting from the
> install media. ;-) :-)
>
> --Chris
>
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[hidden email]"

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: Boot failure - svn up from this morning

Dexuan Cui
> From: Alex Deiter
> Sent: Friday, March 3, 2017 17:22
>
> Hello,
> The same issue with FreeBSD 12.0-CURRENT-r314563:
> elf64_loadimage: could not read symbols - skipped!
>
> I suspect regression after:
>
> Revision 314547 - Directory Listing
> Modified Thu Mar 2 07:25:50 2017 UTC (25 hours, 54 minutes ago) by dexuan
> loader.efi: reduce the size of the staging area if necessary

Yes, I believe the issue is caused by the patch, which is supposed to PR 211746:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746

Sorry for causing the issue to you, but I suspect the patch reveals a bug in your
host's firmware: the memory map reported by the host's firmware may be
incorrect.

Can you please try the patch to dump the memory map?
https://github.com/dcui/freebsd/commit/6094aac8ac9bddb24e3ac45493ac020c94029ce8.patch

And the patch will allow your host to boot.
Note: there is a 10-second pause every time 5 lines are printed. This is to make
sure we have enough time to take a screenshot or photo. :-)

About how to apply the patch and build/install it:
'wget' the above patch, and 'cd' into your FREEBSD_SOURCE_ROOT/sys/boot/ and run
"patch -p3 < the_patch_name". If you have run 'make buildworld", just run 'make' in the
sys/boot/ directory and copy the new loader.efi into the boot folder, e.g. in my side, I
use
cp -iv  /usr/obj/root/bsd.git/sys/boot/efi/loader/loader.efi /boot/loader.efi

Thanks,
-- Dexuan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: Boot failure - svn up from this morning

Dexuan Cui
> From: Dexuan Cui
> Sent: Friday, March 3, 2017 19:50
> > From: Alex Deiter
> > Sent: Friday, March 3, 2017 17:22
> > Hello,
> > The same issue with FreeBSD 12.0-CURRENT-r314563:
> > elf64_loadimage: could not read symbols - skipped!
> >
> > I suspect regression after:
> >
> > Revision 314547 - Directory Listing
> > Modified Thu Mar 2 07:25:50 2017 UTC (25 hours, 54 minutes ago) by dexuan
> > loader.efi: reduce the size of the staging area if necessary
>
> Yes, I believe the issue is caused by the patch, which is supposed to PR 211746:
> ...
> Can you please try the patch to dump the memory map?
> ...

BTW, I understand it's really annoying to boot the host first...
I'm really sorry for this.

I suppose you're able to build or find a good 'loader.efi' binary on another host,
and  then manage to replace the bad 'loader.efi' on the host broken by me. :-)

Thanks,
-- Dexuan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot failure - svn up from this morning

Michael Tuexen-2
> On 3 Mar 2017, at 12:59, Dexuan Cui <[hidden email]> wrote:

>
>> From: Dexuan Cui
>> Sent: Friday, March 3, 2017 19:50
>>> From: Alex Deiter
>>> Sent: Friday, March 3, 2017 17:22
>>> Hello,
>>> The same issue with FreeBSD 12.0-CURRENT-r314563:
>>> elf64_loadimage: could not read symbols - skipped!
>>>
>>> I suspect regression after:
>>>
>>> Revision 314547 - Directory Listing
>>> Modified Thu Mar 2 07:25:50 2017 UTC (25 hours, 54 minutes ago) by dexuan
>>> loader.efi: reduce the size of the staging area if necessary
>>
>> Yes, I believe the issue is caused by the patch, which is supposed to PR 211746:
>> ...
>> Can you please try the patch to dump the memory map?
>> ...
>
> BTW, I understand it's really annoying to boot the host first...
> I'm really sorry for this.
>
> I suppose you're able to build or find a good 'loader.efi' binary on another host,
> and  then manage to replace the bad 'loader.efi' on the host broken by me. :-)
This problem also occurred on a Dell R430...

Best regards
Michael
>
> Thanks,
> -- Dexuan
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[hidden email]"


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Boot failure - svn up from this morning

Dexuan Cui
> From: Michael Tuexen
> Sent: Friday, March 3, 2017 21:30
> > BTW, I understand it's really annoying to boot the host first...
> > I'm really sorry for this.
> >
> > I suppose you're able to build or find a good 'loader.efi' binary on another host,
> > and  then manage to replace the bad 'loader.efi' on the host broken by me. :-)
> This problem also occurred on a Dell R430...
>
> Best regards
> Michael

Can you please use the patch to dump the EFI memory map:
https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064979.html

Let's get this fixed ASAP.

Thanks,
-- Dexuan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot failure - svn up from this morning

Alex Deiter-2
In reply to this post by Dexuan Cui
Hello Dexuan,

Thank you for the patch!
I’ll test it and let you know the result.

Thank you!

Alex Deiter
[hidden email]



> On 3 Mar 2017, at 14:49, Dexuan Cui <[hidden email]> wrote:
>
>> From: Alex Deiter
>> Sent: Friday, March 3, 2017 17:22
>>
>> Hello,
>> The same issue with FreeBSD 12.0-CURRENT-r314563:
>> elf64_loadimage: could not read symbols - skipped!
>>
>> I suspect regression after:
>>
>> Revision 314547 - Directory Listing
>> Modified Thu Mar 2 07:25:50 2017 UTC (25 hours, 54 minutes ago) by dexuan
>> loader.efi: reduce the size of the staging area if necessary
>
> Yes, I believe the issue is caused by the patch, which is supposed to PR 211746:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
>
> Sorry for causing the issue to you, but I suspect the patch reveals a bug in your
> host's firmware: the memory map reported by the host's firmware may be
> incorrect.
>
> Can you please try the patch to dump the memory map?
> https://github.com/dcui/freebsd/commit/6094aac8ac9bddb24e3ac45493ac020c94029ce8.patch
>
> And the patch will allow your host to boot.
> Note: there is a 10-second pause every time 5 lines are printed. This is to make
> sure we have enough time to take a screenshot or photo. :-)
>
> About how to apply the patch and build/install it:
> 'wget' the above patch, and 'cd' into your FREEBSD_SOURCE_ROOT/sys/boot/ and run
> "patch -p3 < the_patch_name". If you have run 'make buildworld", just run 'make' in the
> sys/boot/ directory and copy the new loader.efi into the boot folder, e.g. in my side, I
> use
> cp -iv  /usr/obj/root/bsd.git/sys/boot/efi/loader/loader.efi /boot/loader.efi
>
> Thanks,
> -- Dexuan

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot failure - svn up from this morning

Alex Deiter-2
In reply to this post by Dexuan Cui
Hello,

Screenshot: boot with patched loader: http://picpaste.com/IMG_1768-PnmZAtBZ.JPG
Video: boot with patched loader: https://youtu.be/thzyRk0D36w

Thank you!

Alex Deiter
[hidden email]



> On 3 Mar 2017, at 16:37, Dexuan Cui <[hidden email]> wrote:
>
>> From: Michael Tuexen
>> Sent: Friday, March 3, 2017 21:30
>>> BTW, I understand it's really annoying to boot the host first...
>>> I'm really sorry for this.
>>>
>>> I suppose you're able to build or find a good 'loader.efi' binary on another host,
>>> and  then manage to replace the bad 'loader.efi' on the host broken by me. :-)
>> This problem also occurred on a Dell R430...
>>
>> Best regards
>> Michael
>
> Can you please use the patch to dump the

> :
> https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064979.html
>
> Let's get this fixed ASAP.
>
> Thanks,
> -- Dexuan

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot failure - svn up from this morning

Shawn Webb-3
In reply to this post by Michael Tuexen-2
On Fri, Mar 03, 2017 at 02:30:08PM +0100, Michael Tuexen wrote:

> > On 3 Mar 2017, at 12:59, Dexuan Cui <[hidden email]> wrote:
> >
> >> From: Dexuan Cui
> >> Sent: Friday, March 3, 2017 19:50
> >>> From: Alex Deiter
> >>> Sent: Friday, March 3, 2017 17:22
> >>> Hello,
> >>> The same issue with FreeBSD 12.0-CURRENT-r314563:
> >>> elf64_loadimage: could not read symbols - skipped!
> >>>
> >>> I suspect regression after:
> >>>
> >>> Revision 314547 - Directory Listing
> >>> Modified Thu Mar 2 07:25:50 2017 UTC (25 hours, 54 minutes ago) by dexuan
> >>> loader.efi: reduce the size of the staging area if necessary
> >>
> >> Yes, I believe the issue is caused by the patch, which is supposed to PR 211746:
> >> ...
> >> Can you please try the patch to dump the memory map?
> >> ...
> >
> > BTW, I understand it's really annoying to boot the host first...
> > I'm really sorry for this.
> >
> > I suppose you're able to build or find a good 'loader.efi' binary on another host,
> > and  then manage to replace the bad 'loader.efi' on the host broken by me. :-)
> This problem also occurred on a Dell R430...
And in bhyve with UEFI mode.

--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Boot failure - svn up from this morning

Dexuan Cui
In reply to this post by Alex Deiter-2
> From: Alex Deiter
> Sent: Sunday, March 5, 2017 03:32
>
> Hello,
>
> Screenshot: boot with patched loader:
> Video: boot with patched loader:

Hi Alex,
Thanks for the info!
Unluckily it looks the delay() in my patch didn't work here somehow, so the screen
scrolled up so quickly that we're unable to see the output clearly... :-(

Luckily we can use this new method:
When you reach the "OK " prompt in your screenshot
 (http://picpaste.com/IMG_1768-PnmZAtBZ.JPG), please run "memmap" command
and share the output with me. Please press space to show the complete  info and
share the screenshots.

E.g. in my side, the memmap command shows:

                  Type     Physical      Virtual   #Pages Attr
     ConventionalMemory 000000000000 000000000000 00000080 UC WC WT WB
       BootServicesData 000000080000 000000000000 00000001 UC WC WT WB
     ConventionalMemory 000000081000 000000000000 0000001f UC WC WT WB
       BootServicesData 000000100000 000000000000 00000020 UC WC WT WB
     ConventionalMemory 000000120000 000000000000 00002e53 UC WC WT WB
       BootServicesData 000002f73000 000000000000 0000118d UC WC WT WB
     ConventionalMemory 000004100000 000000000000 00037f00 UC WC WT WB
             LoaderData 00003c000000 000000000000 00004000 UC WC WT WB
     ConventionalMemory 000040000000 000000000000 000b0adf UC WC WT WB
             LoaderData 0000f0adf000 000000000000 00004000 UC WC WT WB
             LoaderCode 0000f4adf000 000000000000 00000072 UC WC WT WB
             LoaderData 0000f4b51000 000000000000 0000217b UC WC WT WB
             LoaderCode 0000f6ccc000 000000000000 0000001d UC WC WT WB
      ACPIReclaimMemory 0000f6ce9000 000000000000 00000001 UC WC WT WB
               Reserved 0000f6cea000 000000000000 00000007 UC WC WT WB
      ACPIReclaimMemory 0000f6cf1000 000000000000 00000001 UC WC WT WB
    RuntimeServicesData 0000f6cf2000 000000000000 00000029 UC WC WT WB
     ConventionalMemory 0000f6d1b000 000000000000 00000890 UC WC WT WB
       BootServicesData 0000f75ab000 000000000000 00000017 UC WC WT WB
     ConventionalMemory 0000f75c2000 000000000000 00000001 UC WC WT WB
       BootServicesData 0000f75c3000 000000000000 0000000d UC WC WT WB
     ConventionalMemory 0000f75d0000 000000000000 0000000c UC WC WT WB
 --more--  <space> page down <enter> line down <q> quit

Thanks,
-- Dexuan

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot failure - svn up from this morning

Chris H-2
On Sun, 5 Mar 2017 10:48:32 +0000 Dexuan Cui <[hidden email]> wrote

> > From: Alex Deiter
> > Sent: Sunday, March 5, 2017 03:32
> >
> > Hello,
> >
> > Screenshot: boot with patched loader:
> > Video: boot with patched loader:
>
> Hi Alex,
> Thanks for the info!
> Unluckily it looks the delay() in my patch didn't work here somehow, so the
> screen scrolled up so quickly that we're unable to see the output clearly...
> :-(
>
> Luckily we can use this new method:
> When you reach the "OK " prompt in your screenshot
>  (http://picpaste.com/IMG_1768-PnmZAtBZ.JPG), please run "memmap" command
> and share the output with me. Please press space to show the complete  info
> and  share the screenshots.
>
> E.g. in my side, the memmap command shows:
I'm experiencing the same problem.
I've taken several screen shots, but not sure I got all of them.
I guess the first, and last will maybe the most important. I'll
clean them up, and post a link to them.

In the meantime, is there any way to get the system to boot again?
Is it possible to simply boot the install DVD, and replace the
efi image on the system, with the one on the install DVD. Or
can the offending commit simply be reverted.

Thanks!

--Chris

>
> Thanks,
> -- Dexuan


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot failure - svn up from this morning

Chris H-2
On Sun, 05 Mar 2017 15:14:52 -0800 "Chris H" <[hidden email]> wrote

> On Sun, 5 Mar 2017 10:48:32 +0000 Dexuan Cui <[hidden email]> wrote
>
> > > From: Alex Deiter
> > > Sent: Sunday, March 5, 2017 03:32
> > >
> > > Hello,
> > >
> > > Screenshot: boot with patched loader:
> > > Video: boot with patched loader:
> >
> > Hi Alex,
> > Thanks for the info!
> > Unluckily it looks the delay() in my patch didn't work here somehow, so the
> > screen scrolled up so quickly that we're unable to see the output
> > clearly... :-(
> >
> > Luckily we can use this new method:
> > When you reach the "OK " prompt in your screenshot
> >  (http://picpaste.com/IMG_1768-PnmZAtBZ.JPG), please run "memmap" command
> > and share the output with me. Please press space to show the complete  info
> > and  share the screenshots.
> >
> > E.g. in my side, the memmap command shows:
> I'm experiencing the same problem.
> I've taken several screen shots, but not sure I got all of them.
> I guess the first, and last will maybe the most important. I'll
> clean them up, and post a link to them.
>
> In the meantime, is there any way to get the system to boot again?
> Is it possible to simply boot the install DVD, and replace the
> efi image on the system, with the one on the install DVD. Or
> can the offending commit simply be reverted.

OK copying the boot.efi from the install DVD will only
hose the system (EFI).
So how long till (u)efi is again supported on FreeBSD?
Sorry for the frustration. But getting a working FreeBSD
on this system has become an unusually long, and expensive
process, this time around -- even for CURRENT.

Thanks, for all your time, and consideration!

--Chris
>
> Thanks!
>
> --Chris
>
> >
> > Thanks,
> > -- Dexuan


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: Boot failure - svn up from this morning

Dexuan Cui
In reply to this post by Chris H-2
> From: Chris H [mailto:[hidden email]]
> > Hi Alex,
> > Thanks for the info!
> > Unluckily it looks the delay() in my patch didn't work here somehow, so the
> > screen scrolled up so quickly that we're unable to see the output clearly...
> > :-(
> >
> > Luckily we can use this new method:
> > When you reach the "OK " prompt in your screenshot
> > please run "memmap" command
> > and share the output with me. Please press space to show the complete  info
> > and  share the screenshots.
> >
> > E.g. in my side, the memmap command shows:
> I'm experiencing the same problem.
> I've taken several screen shots, but not sure I got all of them.
> I guess the first, and last will maybe the most important. I'll
> clean them up, and post a link to them.

Thanks! I'm eager to see your screenshots.
The line whose "Physical" address contains 2MB is the most interesting to me.
And please at least post the other lines around the line.

> In the meantime, is there any way to get the system to boot again?
> Is it possible to simply boot the install DVD, and replace the
> efi image on the system, with the one on the install DVD. Or
> can the offending commit simply be reverted.
>
> --Chris
Yes, you can replace the broken system's bad /boot/loader.efi  with a
good version. You can also revert the offending commit ("loader.efi: reduce
the size of the staging area if necessary").

Thanks,
-- Dexuan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: Boot failure - svn up from this morning

Dexuan Cui
In reply to this post by Chris H-2
> From: Chris H [mailto:[hidden email]]
> OK copying the boot.efi from the install DVD will only
> hose the system (EFI).
Do you mean copying the boot.efi from the install DVD doesn't work?
If so we need to build a good boot.efi with the CURRENT code + reverting
the offending commit.

> So how long till (u)efi is again supported on FreeBSD?
> Sorry for the frustration. But getting a working FreeBSD
> on this system has become an unusually long, and expensive
> process, this time around -- even for CURRENT.
>
> --Chris

I think EFI boot has been supported by FreeBSD for years and it's only
broken since last Thursday by my patch... Sorry. Let's make it
right soon, once I understand why the patch breaks it  by checking
the memory maps on your system.

Thanks,
-- Dexuan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot failure - svn up from this morning

Chris H-2
In reply to this post by Dexuan Cui
Thank you verymuch for the reply, Dexuan!

On Mon, 6 Mar 2017 00:34:19 +0000 Dexuan Cui <[hidden email]> wrote

> > From: Chris H [mailto:[hidden email]]
> > > Hi Alex,
> > > Thanks for the info!
> > > Unluckily it looks the delay() in my patch didn't work here somehow, so
> > > the screen scrolled up so quickly that we're unable to see the output
> > > clearly... :-(
> > >
> > > Luckily we can use this new method:
> > > When you reach the "OK " prompt in your screenshot
> > > please run "memmap" command
> > > and share the output with me. Please press space to show the complete
> > > info and  share the screenshots.
> > >
> > > E.g. in my side, the memmap command shows:
> > I'm experiencing the same problem.
> > I've taken several screen shots, but not sure I got all of them.
> > I guess the first, and last will maybe the most important. I'll
> > clean them up, and post a link to them.
>
> Thanks! I'm eager to see your screenshots.
> The line whose "Physical" address contains 2MB is the most interesting to me.
> And please at least post the other lines around the line.
OK. Her you go. It's taken me some time to get any shots
that are readable -- I don't have a very steady hand. :-(
Anyway, I haven't touched them. They're just as my phone camera
produced them. Because of their size, I've packed them all up.
I'm afraid I don't know their exact order. Hopefully you'll
know by looking at them. :-)
They're located at: bsdforge.com/efi-memmap.tar.xz

Thank you very much for all your time, and attention to this,
Dexuan! And sorry for my frustration.

--Chris

>
> > In the meantime, is there any way to get the system to boot again?
> > Is it possible to simply boot the install DVD, and replace the
> > efi image on the system, with the one on the install DVD. Or
> > can the offending commit simply be reverted.
> >
> > --Chris
> Yes, you can replace the broken system's bad /boot/loader.efi  with a
> good version. You can also revert the offending commit ("loader.efi: reduce
> the size of the staging area if necessary").
>
> Thanks,
> -- Dexuan


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: Boot failure - svn up from this morning

Dexuan Cui
> From: Chris H [mailto:[hidden email]]
> Sent: Monday, March 6, 2017 09:57
> > Thanks! I'm eager to see your screenshots.
> > The line whose "Physical" address contains 2MB is the most interesting to me.
> > And please at least post the other lines around the line.
> OK. Her you go. It's taken me some time to get any shots
> that are readable -- I don't have a very steady hand. :-(
> Anyway, I haven't touched them. They're just as my phone camera
> produced them. Because of their size, I've packed them all up.
> I'm afraid I don't know their exact order. Hopefully you'll
> know by looking at them. :-)
> They're located at: bsdforge.com/efi-memmap.tar.xz

Hi Chris,
Thank you very much for the screenshots!!!

On the host there is a 1MB LoaderData memory range, which splits
the big Conventional Memory range into a small one (15MB) and a
big one: the small one is too small to hold the staging area.

I'm going to post a patch shortly.

For people who are interested in the details: please see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c22

Thanks,
-- Dexuan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: Boot failure - svn up from this morning

Dexuan Cui
> From: [hidden email] [mailto:owner-freebsd-
> [hidden email]] On Behalf Of Dexuan Cui
> Hi Chris,
> Thank you very much for the screenshots!!!
>
> On the host there is a 1MB LoaderData memory range, which splits
> the big Conventional Memory range into a small one (15MB) and a
> big one: the small one is too small to hold the staging area.
>
> I'm going to post a patch shortly.

Can you please try the below patch?
https://reviews.freebsd.org/D9904
You can find the URL of the "Download Raw Diff" in the page and
'wget' the patch and then apply it.

It should be able to fix the recent UEFI-boot issue introduced by me.

You may not need to re-buildworld. Please this link to replace the
bad 'loader.efi':
https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064979.html

I'm planning to commit the patch later today in about 6 hours, because
I'm pretty confident in the patch and it should fix the critical issue...

Thanks,
-- Dexuan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
12