Re: Boot failure - svn up from this morning

[Subbsd]

Hi,

I had the same problems, however, there is one more regression after
these changes. It stably reproduces if you use EFI_STAGING_SIZE.
I have custom FreeBSD distributive which has a sufficiently large
mfsroot which is loaded through UEFI mode.

To solve the problem, it was suggested to increase this variable and
rebuild /sys/boot:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209944

Also, it has to be increased periodically for some reason:

https://svnweb.freebsd.org/base/stable/11/sys/boot/efi/loader/copy.c?r1=305779=305778=305779

I've try to ask why than threatens to increase this parameter at once
large (or make it dependent on RAM):
https://lists.freebsd.org/pipermail/freebsd-hackers/2016-November/050142.html
but there are no answer options.

At the moment, on r315141 boot via UEFI is fixed without EFI_STAGING_SIZE.

With EFI_STAGING_SIZE=768 i got regression after last changes in panic
with follow message:

failed to allocate staging area:9
failed to allocate stating area
Failed to start image provided by ZFS (5)

http://pasteboard.co/IvbhU9Ffu.jpg

I believe that there mfsroot may be greater than 64MB soon or later.

Also there are no problems with loading big mfsroot images when MBR
method is used.

PS:  I have ZFS-on-root system. With EFI_STAGING_SIZE=768 I lived with
constant CURRENT svnup/rebuilds for about a year. So I will be glad if
you pay attention to this.

PPS: How to reproduce:

1) EFI_STAGING_SIZE=768 in /etc/make.conf
2) make -C /sys/boot clean
3) make -C /sys/boot
4) make -C /sys/boot install
5) reboot

Thanks!
___
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: Boot failure - svn up from this morning

[Jonathan Anderson]

On 7 Mar 2017, at 16:50, Chris H wrote:

On Tue, 07 Mar 2017 16:27:59 -0330 "Jonathan Anderson" 


wrote


Hi,

On 5 Mar 2017, at 20:31, Chris H wrote:


OK copying the boot.efi from the install DVD will only
hose the system (EFI).


Before I attempt to do the same thing... what do you mean by "hose 
the

system"? Is the correct recovery path to build a new USB image with
"make release" post-r314828?

That was *my* bad. I inadvertently copied the *wrong* file
(I was in a hurry).
So. That said; if you move loader.efi aside -- say; to
_loader.efi.
Then copy loader.efi from the install DVD, or any other
system that's not too much older, and is good. You should
be fine. :-)
Make sure the permissions are correct, after the copy.

Sorry for the misinformation.


Thanks for the clarification! I am back up and running now.

Cheers,


Jon
--
jonat...@freebsd.org
___
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: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Alex Deiter [mailto:alex.dei...@gmail.com]
> Hello Dexuan,
> This issue reproduced at least for 4 different HW platform
> How can I help you resolve this issue ?
> 
> The same result for r314862:

Hi guys,
Sorry, I had to commit a new patch (r314891) just now to really fix
the off-by-one bug.
Thank Alex for reporting the issue in my previous patch (r314828).

Hope this issue is finally fixed this time! :-)

Thanks,
-- Dexuan
___
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: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Alex Deiter [mailto:alex.dei...@gmail.com]
> Sent: Wednesday, March 8, 2017 09:39
> To: Dexuan Cui <de...@microsoft.com>; freebsd-current  curr...@freebsd.org>
> Cc: Chris H <bsd-li...@bsdforge.com>; AN <a...@neu.net>; Ngie Cooper
> (yaneurabeya) <yaneurab...@gmail.com>; Michael Tuexen
> <tue...@freebsd.org>; Roberto Rodriguez Jr <rob.rodz@gmail.com>; Guido
> Falsi <m...@madpilot.net>; Warner Losh <i...@bsdimp.com>; Ultima
> <ultima1...@gmail.com>; Sepherosa Ziehau <se...@freebsd.org>
> Subject: Re: Boot failure - svn up from this morning
> 
> Hello Dexuan,
> 
> This issue reproduced at least for 4 different HW platform:
> 
> Supermicro 6037R-TXRF
> Supermicro A1SRM-2758F
> Supermicro X9SCM-F
> Gigabyte GA-C1037UN-EU
> 
> How can I help you resolve this issue ?
> 
> Thank you!
> 
> The same result for r314862:

Weird... :-(
I'm looking at the code again. Will report back soon.

___
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: Boot failure - svn up from this morning

[Alex Deiter]

Hello Dexuan,

This issue reproduced at least for 4 different HW platform:

Supermicro 6037R-TXRF
Supermicro A1SRM-2758F
Supermicro X9SCM-F
Gigabyte GA-C1037UN-EU

How can I help you resolve this issue ?

Thank you! 

The same result for r314862:

>> FreeBSD EFI boot block
  Loader path: /boot/loader.efi

  Initializing modules: ZFS UFS
  Probing 16 block devices..*.+.. done
   ZFS found the following pools: zroot
   UFS found no partitions
Consoles: EFI console  
Staging area's size is reduced: 16384 -> 64!
Command line arguments: loader.efi
Image base: 0x6dc65000
EFI version: 2.31
EFI Firmware: American Megatrends (rev 5.08)

FreeBSD/amd64 EFI loader, Revision 1.1
EFI boot environment
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0x9210f8 
elf64_loadimage: read failed
can't load file '/boot/kernel/kernel': input/output error
can't load file '/boot/kernel/kernel': input/output error

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel] in 2 seconds... 

Type '?' for a list of commands, 'help' for more detailed help.
OK  
OK  memmap
  Type Physical  Virtual   #Pages Attr
  BootServicesCode   0008 UC WC WT WB 
ConventionalMemory 8000  0027 UC WC WT WB 
  BootServicesData 0002f000  0011 UC WC WT WB 
  BootServicesCode 0004  0060 UC WC WT WB 
ConventionalMemory 0010  0100 UC WC WT WB 
  BootServicesData 0020  0040 UC WC WT WB 
ConventionalMemory 0024  0003fd80 UC WC WT WB 
LoaderData 3ffc  0040 UC WC WT WB 
ConventionalMemory 4000  00029c65 UC WC WT WB 
LoaderData 69c65000  4000 UC WC WT WB 
LoaderCode 6dc65000  0071 UC WC WT WB 
LoaderData 6dcd6000  2171 UC WC WT WB 
LoaderCode 6fe47000  001d UC WC WT WB 
MemoryMappedIO 6fe64000  0014 UC WC WT WB 
  BootServicesData 6fe78000  ec32 UC WC WT WB 
ConventionalMemory 7eaaa000  037b UC WC WT WB 
  BootServicesCode 7ee25000  0285 UC WC WT WB 
  Reserved 7f0aa000  0075 UC WC WT WB 
ConventionalMemory 7f11f000  00ae UC WC WT WB 
 ACPIMemoryNVS 7f1cd000  027b UC WC WT WB 
   RuntimeServicesData 7f448000  01a7 UC WC WT WB 
   RuntimeServicesCode 7f5ef000  005c UC WC WT WB 
  BootServicesData 7f64b000  01b5 UC WC WT WB 
ConventionalMemory 0001  0078 UC WC WT WB 
MemoryMappedIO e000  4000 UC 
MemoryMappedIO fed01000  0003 UC 
MemoryMappedIO fed08000  0001 UC 
MemoryMappedIO fed0c000  0004 UC 
MemoryMappedIO fed1c000  0001 UC 
MemoryMappedIO fef0  1100 UC 
OK 


Thank you!


Alex Deiter
alex.dei...@gmail.com



> On 7 Mar 2017, at 06:45, Dexuan Cui <de...@microsoft.com> wrote:
> 
>> From: Dexuan Cui
>> Sent: Tuesday, March 7, 2017 11:18
>> To: 'Alex Deiter' <alex.dei...@gmail.com>
>> Cc: Chris H <bsd-li...@bsdforge.com>; AN <a...@neu.net>; Ngie Cooper
>> (yaneurabeya) <yaneurab...@gmail.com>; Michael Tuexen
>> <tue...@freebsd.org>; Roberto Rodriguez Jr <rob.rodz@gmail.com>; Guido
>> Falsi <m...@madpilot.net>; Warner Losh <i...@bsdimp.com>; Ultima
>> <ultima1...@gmail.com>; Sepherosa Ziehau <se...@freebsd.org>
>> Subject: RE: Boot failure - svn up from this morning
>> 
>>> From: Alex Deiter [mailto:alex.dei...@gmail.com]
>>> Sent: Tuesday, March 7, 2017 11:04
>>> To: Dexuan Cui <de...@microsoft.com>
>> 
>> 
>> Hi Alex,
>> Thanks very much for the quick reply!
>> 
>> I found an off-by-one bug in my patch and here is the fix.
>> I'll commit it shortly.
> 
> Hi Alex,
> I committed Revision 314828 for this:
> https://svnweb.freebsd.org/base?view=revision=314828
> 
> I believe it should fix the issue for you now. :-)
> 
> Thanks,
> -- Dexuan

___
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: Boot failure - svn up from this morning

[Chris H]

On Tue, 07 Mar 2017 16:27:59 -0330 "Jonathan Anderson" 
wrote

> Hi,
> 
> On 5 Mar 2017, at 20:31, Chris H wrote:
> 
> > OK copying the boot.efi from the install DVD will only
> > hose the system (EFI).
> 
> Before I attempt to do the same thing... what do you mean by "hose the 
> system"? Is the correct recovery path to build a new USB image with 
> "make release" post-r314828?
That was *my* bad. I inadvertently copied the *wrong* file
(I was in a hurry).
So. That said; if you move loader.efi aside -- say; to
_loader.efi.
Then copy loader.efi from the install DVD, or any other
system that's not too much older, and is good. You should
be fine. :-)
Make sure the permissions are correct, after the copy.

Sorry for the misinformation.

--Chris
> 
> Thanks,
> 
> 
> Jon
> --
> jonat...@freebsd.org


___
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: Boot failure - svn up from this morning

[Jonathan Anderson]

Hi,

On 5 Mar 2017, at 20:31, Chris H wrote:


OK copying the boot.efi from the install DVD will only
hose the system (EFI).


Before I attempt to do the same thing... what do you mean by "hose the 
system"? Is the correct recovery path to build a new USB image with 
"make release" post-r314828?


Thanks,


Jon
--
jonat...@freebsd.org
___
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: Boot failure - svn up from this morning

[Chris H]

On Mon, 6 Mar 2017 04:01:04 + Dexuan Cui  wrote

> > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> > curr...@freebsd.org] 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...

It may already be too late. But I just wanted to let you know that
I hadn't overlooked/discarded your message. $WORK$ is riding my a$$
pretty hard, and I'm not going to get a chance to catch my breath
till at least mid day. But I *do* plan to give this a shot, and
my earliest opportunity.

Thanks, Dexuan!

--Chris
> 
> Thanks,
> -- Dexuan


___
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: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Dexuan Cui
> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770
> 
> Please let me know in case this can't solve the issue.
 
Sorry, r314770  has a bug, so I had to commit r314828 for this:
https://svnweb.freebsd.org/base?view=revision=314828

Please make sure you use the latest code, i.e. >= r314828.

Thanks,
-- Dexuan
___
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: Boot failure - svn up from this morning

[Dexuan Cui]

> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] 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
___
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: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Dexuan Cui
> Sent: Monday, March 6, 2017 13:10
> 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...

I committed r314770 just now to minimize the impact:
https://svnweb.freebsd.org/base?view=revision=314770

Please let me know in case this can't solve the issue.

 Thanks,
-- Dexuan
___
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: Boot failure - svn up from this morning

[Chris H]

On Mon, 6 Mar 2017 04:01:04 + Dexuan Cui  wrote

> > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> > curr...@freebsd.org] 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?
Yes. I can't do it right away. Because that box is in the middle
of a big build session. But the moment it's done. I'll give it
a try, and report the results.

Thanks again, Dexuan, for all your continued dedication to this!

--Chris

> 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


___
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: Boot failure - svn up from this morning

[Chris H]

On Mon, 6 Mar 2017 03:00:20 + Dexuan Cui  wrote

> > From: Chris H [mailto:bsd-li...@bsdforge.com]
> > 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!!!
No. Thank YOU, for all the work you're doing on this.
Not to mention all the (personal) help you've given me.

Greatly appreciated, Dexuan!

--Chris
> 
> 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


___
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: Boot failure - svn up from this morning

[Dexuan Cui]

> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] 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.

(Some of you may receive this same mail twice or even thrice -- sorry
for the confusion, it's because my first mail "is being held until the
list moderator can review it for approval" due to "Too many recipients
to the message"...)

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
___
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: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Chris H [mailto:bsd-li...@bsdforge.com]
> 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
___
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: Boot failure - svn up from this morning

[Chris H]

Thank you verymuch for the reply, Dexuan!

On Mon, 6 Mar 2017 00:34:19 + Dexuan Cui  wrote

> > From: Chris H [mailto:bsd-li...@bsdforge.com]
> > > 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


___
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: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Chris H [mailto:bsd-li...@bsdforge.com]
> 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
___
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: Boot failure - svn up from this morning

[Dexuan Cui]

> From: Chris H [mailto:bsd-li...@bsdforge.com]
> > 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
___
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: Boot failure - svn up from this morning

[Chris H]

On Sun, 05 Mar 2017 15:14:52 -0800 "Chris H"  wrote

> On Sun, 5 Mar 2017 10:48:32 + Dexuan Cui  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


___
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: Boot failure - svn up from this morning

[Chris H]

On Sun, 5 Mar 2017 10:48:32 + Dexuan Cui  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


___
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: Boot failure - svn up from this morning

[Dexuan Cui]

> 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   0080 UC WC WT WB
   BootServicesData 0008  0001 UC WC WT WB
 ConventionalMemory 00081000  001f UC WC WT WB
   BootServicesData 0010  0020 UC WC WT WB
 ConventionalMemory 0012  2e53 UC WC WT WB
   BootServicesData 02f73000  118d UC WC WT WB
 ConventionalMemory 0410  00037f00 UC WC WT WB
 LoaderData 3c00  4000 UC WC WT WB
 ConventionalMemory 4000  000b0adf UC WC WT WB
 LoaderData f0adf000  4000 UC WC WT WB
 LoaderCode f4adf000  0072 UC WC WT WB
 LoaderData f4b51000  217b UC WC WT WB
 LoaderCode f6ccc000  001d UC WC WT WB
  ACPIReclaimMemory f6ce9000  0001 UC WC WT WB
   Reserved f6cea000  0007 UC WC WT WB
  ACPIReclaimMemory f6cf1000  0001 UC WC WT WB
RuntimeServicesData f6cf2000  0029 UC WC WT WB
 ConventionalMemory f6d1b000  0890 UC WC WT WB
   BootServicesData f75ab000  0017 UC WC WT WB
 ConventionalMemory f75c2000  0001 UC WC WT WB
   BootServicesData f75c3000  000d UC WC WT WB
 ConventionalMemory f75d  000c UC WC WT WB
 --more--   page down  line down  quit

Thanks,
-- Dexuan

___
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: Boot failure - svn up from this morning

[Shawn Webb]

On Fri, Mar 03, 2017 at 02:30:08PM +0100, Michael Tuexen wrote:
> > On 3 Mar 2017, at 12:59, Dexuan Cui  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
Description: PGP signature

Re: Boot failure - svn up from this morning

[Alex Deiter]

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
alex.dei...@gmail.com



> On 3 Mar 2017, at 16:37, Dexuan Cui  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

___
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: Boot failure - svn up from this morning

[Alex Deiter]

Hello Dexuan,

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

Thank you!

Alex Deiter
alex.dei...@gmail.com



> On 3 Mar 2017, at 14:49, Dexuan Cui  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

___
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: Boot failure - svn up from this morning

[Michael Tuexen]

> On 3 Mar 2017, at 12:59, Dexuan Cui  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
> ___
> 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"



smime.p7s
Description: S/MIME cryptographic signature

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
___
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: 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
___
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: 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
___
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: Boot failure - svn up from this morning

[Alex Deiter]

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
alex.dei...@gmail.com



> On 3 Mar 2017, at 09:20, Chris H  wrote:
> 
> On Thu, 2 Mar 2017 21:32:39 -0800 "Ngie Cooper (yaneurabeya)"
>  wrote
> 
>>> On Mar 2, 2017, at 21:16, Chris H  wrote:
>>> 
>>> On Thu, 2 Mar 2017 21:56:38 -0500 (EST) AN  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
> 
> 
> ___
> 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"

___
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: Boot failure - svn up from this morning

[Chris H]

On Thu, 2 Mar 2017 21:32:39 -0800 "Ngie Cooper (yaneurabeya)"
 wrote

> > On Mar 2, 2017, at 21:16, Chris H  wrote:
> > 
> > On Thu, 2 Mar 2017 21:56:38 -0500 (EST) AN  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


___
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: Boot failure - svn up from this morning

[Ngie Cooper (yaneurabeya)]

> On Mar 2, 2017, at 21:16, Chris H  wrote:
> 
> On Thu, 2 Mar 2017 21:56:38 -0500 (EST) AN  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
Description: Message signed with OpenPGP using GPGMail

Re: Boot failure - svn up from this morning

[Chris H]

On Thu, 2 Mar 2017 21:56:38 -0500 (EST) AN  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


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

Boot failure - svn up from this morning

[AN]

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.

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