Re: input/output error @boot

[Chris H]

On Thu, 9 Mar 2017 06:00:23 + Dexuan Cui <de...@microsoft.com> wrote

> Hi Roberto, 
> Thanks for sending me your memmap and this is a temporary workaround
> patch for you:
> https://github.com/dcui/freebsd/commit/0edd1db55fbbb56352d6024250e4ae7dd8ad31
> e3.patch 
>
> I put the memmap info here for people who're interested:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c26
> 
> We can notice there is a 4MB BootServicesCode range at [12MB, 16MB) .
> loader.efi just writes into this range by force -- this is unsafe anyway!
> 
> To fix this correctly & thoroughly, IMO we need a relocatable kernel, but
> that would require a lot of complicated long term work:
> https://reviews.freebsd.org/D9686?id=25414#inline-56969
> 
> For now, I suggest we should only apply the idea "reduce the size of the
> staging area if necessary" to VM running on Hyper-V, we should restore the
> old behavior on physical machines since that has been working for people
> for a long period of time, though it's  potentially unsafe.
> 
> I think in the loader we can use CPUID to tell if we're running on Hyper-V or
> not. 

Indeed that will provide *capability*. But I'm don't think that can
tell you that it is currently *enabled* || *in use*.
The CPU I experienced the (u)efi issue on has the capability,
but I've turned it off, as it's more hindrance for performance,
for the server' intended use.

IOW I think just probing for *capability* isn't going to be enough.

--Chris
>
> Thanks,
> -- Dexuan
> 
> > -Original Message-
> > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> > curr...@freebsd.org] On Behalf Of Dexuan Cui
> > Sent: Thursday, March 9, 2017 10:44
> > To: Roberto Rodriguez Jr <rob.rodz@gmail.com>
> > Cc: FreeBSD Current <freebsd-current@freebsd.org>
> > Subject: RE: input/output error @boot
> > 
> > Hmm, Alex did report 314891 worked.
> > 
> > Can you please post the full boot log of the loader?
> > Especially, when you see the “OK” prompt, can you please run the
“memmap”
> > command like this link ...
> > 
> > You can take a photo of the screen and send it to me, if it’s too big.
> > 
> > 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: input/output error @boot

[Roberto Rodriguez Jr]

Hello all,

I am booting from CURRENTusb img.
For the life of me I cannot comprehend why I cannot see my /boot directory
after
Choose Shell from bsdinstall welcome
mkdir /tmp/mnt
zpool import
zpool import -fR /tmp/mnt mypool
zfs mount -a
ls
mypool var usr tmp

Where is boot, etc, bin, root?

zfs list
mypool/ROOT none

How do I mount my drive?
ZFS on root stripe0
314495 12 CUREENT
amd64 HP 15 Laptop A6-5200

I would love to learn so I can be a better tester.

I could the compile the new loader.efi after svn update. Thanks to all for
this fix. You are awesome! I love this community.

-R
___
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: input/output error @boot

[Pete Wright]

On 3/9/17 8:10 AM, Pete Wright wrote:



On 3/9/17 4:42 AM, Dexuan Cui wrote:

From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
curr...@freebsd.org] On Behalf Of Pete Wright
Sent: Thursday, March 9, 2017 14:04
To: freebsd-current@freebsd.org
Subject: Re: input/output error @boot
On 3/8/17 10:00 PM, Dexuan Cui wrote:

For now, I suggest we should only apply the idea "reduce the size of
the
staging area if necessary" to VM running on Hyper-V, we should
restore the
old behavior on physical machines since that has been working for
people
for a long period of time, though it's  potentially unsafe.


+1

i'd like to see the old behaviour for physical machines to be restored
as well since this has rendered my drm-next test rig broken :(

-pete


Eventually I committed 314956 for the issue:
https://svnweb.freebsd.org/base?view=revision=314956
The old behaviour for physical machines are restored.

PS, I understand usually I should put the patch on phabricator for
review,
before it's committed, but since the issue here is critical, I
committed it
directly to unblock people first. Sorry.
Please comment on the patch if you think it needs rework  -- I hope
not. :-)



Thank you Dexuan - I will do a build today and reboot when I am home
from work tonight.  FWIW I verified that if I boot my system with in
"classic" BIOS mode I am able to load the kernel and go multi-user, so
this is probably the fix for me.



Happy to report that 314956 addresses the issue I was having with UEFI 
not booting.  Thanks for the fix!


-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
___
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: input/output error @boot

[Pete Wright]

On 3/9/17 4:42 AM, Dexuan Cui wrote:

From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
curr...@freebsd.org] On Behalf Of Pete Wright
Sent: Thursday, March 9, 2017 14:04
To: freebsd-current@freebsd.org
Subject: Re: input/output error @boot
On 3/8/17 10:00 PM, Dexuan Cui wrote:

For now, I suggest we should only apply the idea "reduce the size of the
staging area if necessary" to VM running on Hyper-V, we should restore the
old behavior on physical machines since that has been working for people
for a long period of time, though it's  potentially unsafe.


+1

i'd like to see the old behaviour for physical machines to be restored
as well since this has rendered my drm-next test rig broken :(

-pete


Eventually I committed 314956 for the issue:
https://svnweb.freebsd.org/base?view=revision=314956
The old behaviour for physical machines are restored.

PS, I understand usually I should put the patch on phabricator for review,
before it's committed, but since the issue here is critical, I committed it
directly to unblock people first. Sorry.
Please comment on the patch if you think it needs rework  -- I hope not. :-)



Thank you Dexuan - I will do a build today and reboot when I am home 
from work tonight.  FWIW I verified that if I boot my system with in 
"classic" BIOS mode I am able to load the kernel and go multi-user, so 
this is probably the fix for me.


Cheers!
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
___
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: input/output error @boot

[Toomas Soome]

> On 9. märts 2017, at 15:03, Dexuan Cui  wrote:
> 
>> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
>> curr...@freebsd.org] On Behalf Of Toomas Soome
>> 
>> IMO there are multiple issues around this problem and workaround.
>> 
>> First of all, to control UEFI memory allocation, the AllocatePages() has 
>> options:
>> 
>> AllocateAnyPages,
>> AllocateMaxAddress,
>> AllocateAddress
>> 
>> On x86, we use:
>> 
>>staging = 1024*1024*1024;
>>status = BS->AllocatePages(AllocateMaxAddress, EfiLoaderData,
>>nr_pages, );
>> 
>> Which means:
>> 
>> "Allocation requests of Type AllocateMaxAddress allocate any available range 
>> of
>> pages whose uppermost address is less than or equal to the address pointed to
>> by Memory on input.”
>> 
>> So, we are asking for an amount of memory (64MB), with condition that all the
>> pages should be below 1GB.
>> 
>> And we get it. If hyper-v is in fact returning us memory from already 
>> occupied
>> area - there can be exactly one conclusion - it is bug in hyper-v.
> 
> Hyper-V has no bug here: Hyper-V doesn't return memory from already occupied
> area. The issue is: the loader here tries to write the 64MB staging area 
> (BTW, it's
> 48MB in 10.3) into the physical memory range [2MB, 2MB+64MB) -- the loader
> assumes this range is writable. However, this is not true with Hyper-V EFI
> firmware: there is a read-only BootServicesData memory block starting at
> about 47.449MB, causing a crash in the loader.
> 
> If you're interested, the whole long story is in the below link.  :-)
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746, e.g. please see the
> screenshot in comment #8.
> 


ah, right, so it already does the relocation and will get busted there, sorry, 
missed that:D


> 
>> Note, this allocation method does *not* set the starting point for 
>> allocation, it
>> can return us *any* chunk of memory of given size, below 1GB.
> Yes. This can potentially cause new issues...
> 
>> So the attempt to control such allocation by size, is unfortunately flawed - 
>> it
>> really does not control the allocation.
> Yes, you're correct.
> The patch is flawed. I only expect (or hope) it can work around the issues 
> with
> typical Hyper-V UEFI firmware.
> In my test, it works with Hyper-V 2012 R2 and 2016.
> I hope it could work in future Hyper-V too...
> 
>> Note that I have also seen AllocateAddress failures - there was nicely 
>> available
>> chunk of memory, but the firmware just did not allocate with given address 
>> (it
>> did happen with OVMF + qemu).
>> 
>> The secondary flaw there is also about firmware. Sure, with UEFI you can have
>> “random” allocations and the actual control over memory is actually problem,
>> but to plant an “egg”  in 1MB-1GB range, where you have most chances any OS
>> will live - IMO this is just stupid.
>> 
>> The only real solution here is to either rise the MaxAddress limit or use
>> AllocateAnyPages, get kernel loaded into the memory, and after switching off
>> the boot services and before jumping to kernel, relocate the kernel to 
>> available
>> location below 1GB…
> Yes. IMO the biggest issue is that currently the kernel can't be relocated... 
> :-(
> It's a long term work to make it relocatable, I'm afraid.
> 
> Thanks,
> -- Dexuan

true, and there are other systems with same issue. relocatable kernels are not 
really that common even today;) anyhow, good work from your side;)

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: input/output error @boot

[Dexuan Cui]

> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Toomas Soome
>
> IMO there are multiple issues around this problem and workaround.
>
> First of all, to control UEFI memory allocation, the AllocatePages() has 
> options:
>
> AllocateAnyPages,
> AllocateMaxAddress,
> AllocateAddress
>
> On x86, we use:
>
> staging = 1024*1024*1024;
> status = BS->AllocatePages(AllocateMaxAddress, EfiLoaderData,
> nr_pages, );
>
> Which means:
>
> "Allocation requests of Type AllocateMaxAddress allocate any available range 
> of
> pages whose uppermost address is less than or equal to the address pointed to
> by Memory on input.”
>
> So, we are asking for an amount of memory (64MB), with condition that all the
> pages should be below 1GB.
>
> And we get it. If hyper-v is in fact returning us memory from already occupied
> area - there can be exactly one conclusion - it is bug in hyper-v.

Hyper-V has no bug here: Hyper-V doesn't return memory from already occupied
area. The issue is: the loader here tries to write the 64MB staging area (BTW, 
it's
48MB in 10.3) into the physical memory range [2MB, 2MB+64MB) -- the loader
assumes this range is writable. However, this is not true with Hyper-V EFI
firmware: there is a read-only BootServicesData memory block starting at
about 47.449MB, causing a crash in the loader.

If you're interested, the whole long story is in the below link.  :-)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746, e.g. please see the
screenshot in comment #8.


> Note, this allocation method does *not* set the starting point for 
> allocation, it
> can return us *any* chunk of memory of given size, below 1GB.
Yes. This can potentially cause new issues...

> So the attempt to control such allocation by size, is unfortunately flawed - 
> it
> really does not control the allocation.
Yes, you're correct.
The patch is flawed. I only expect (or hope) it can work around the issues with
typical Hyper-V UEFI firmware.
In my test, it works with Hyper-V 2012 R2 and 2016.
I hope it could work in future Hyper-V too...

> Note that I have also seen AllocateAddress failures - there was nicely 
> available
> chunk of memory, but the firmware just did not allocate with given address (it
> did happen with OVMF + qemu).
>
> The secondary flaw there is also about firmware. Sure, with UEFI you can have
> “random” allocations and the actual control over memory is actually problem,
> but to plant an “egg”  in 1MB-1GB range, where you have most chances any OS
> will live - IMO this is just stupid.
>
> The only real solution here is to either rise the MaxAddress limit or use
> AllocateAnyPages, get kernel loaded into the memory, and after switching off
> the boot services and before jumping to kernel, relocate the kernel to 
> available
> location below 1GB…
Yes. IMO the biggest issue is that currently the kernel can't be relocated... 
:-(
It's a long term work to make it relocatable, I'm afraid.

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: input/output error @boot

[Dexuan Cui]

> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Pete Wright
> Sent: Thursday, March 9, 2017 14:04
> To: freebsd-current@freebsd.org
> Subject: Re: input/output error @boot
> On 3/8/17 10:00 PM, Dexuan Cui wrote:
> > For now, I suggest we should only apply the idea "reduce the size of the
> > staging area if necessary" to VM running on Hyper-V, we should restore the
> > old behavior on physical machines since that has been working for people
> > for a long period of time, though it's  potentially unsafe.
> >
> +1
> 
> i'd like to see the old behaviour for physical machines to be restored
> as well since this has rendered my drm-next test rig broken :(
> 
> -pete

Eventually I committed 314956 for the issue:
https://svnweb.freebsd.org/base?view=revision=314956
The old behaviour for physical machines are restored.

PS, I understand usually I should put the patch on phabricator for review,
before it's committed, but since the issue here is critical, I committed it
directly to unblock people first. Sorry.
Please comment on the patch if you think it needs rework  -- I hope not. :-) 

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: input/output error @boot

[Toomas Soome]

> On 9. märts 2017, at 8:00, Dexuan Cui <de...@microsoft.com> wrote:
> 
> Hi Roberto, 
> Thanks for sending me your memmap and this is a temporary workaround
> patch for you:
> https://github.com/dcui/freebsd/commit/0edd1db55fbbb56352d6024250e4ae7dd8ad31e3.patch
> 
> I put the memmap info here for people who're interested:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c26
> 
> We can notice there is a 4MB BootServicesCode range at [12MB, 16MB) .
> loader.efi just writes into this range by force -- this is unsafe anyway!
> 
> To fix this correctly & thoroughly, IMO we need a relocatable kernel, but
> that would require a lot of complicated long term work:
> https://reviews.freebsd.org/D9686?id=25414#inline-56969
> 
> For now, I suggest we should only apply the idea "reduce the size of the
> staging area if necessary" to VM running on Hyper-V, we should restore the
> old behavior on physical machines since that has been working for people
> for a long period of time, though it's  potentially unsafe.
> 
> I think in the loader we can use CPUID to tell if we're running on Hyper-V or 
> not.


IMO there are multiple issues around this problem and workaround.

First of all, to control UEFI memory allocation, the AllocatePages() has 
options:

AllocateAnyPages,
AllocateMaxAddress,
AllocateAddress

On x86, we use:

staging = 1024*1024*1024;
status = BS->AllocatePages(AllocateMaxAddress, EfiLoaderData,
nr_pages, );

Which means:

"Allocation requests of Type AllocateMaxAddress allocate any available range of 
pages whose uppermost address is less than or equal to the address pointed to 
by Memory on input.”

So, we are asking for an amount of memory (64MB), with condition that all the 
pages should be below 1GB.

And we get it. If hyper-v is in fact returning us memory from already occupied 
area - there can be exactly one conclusion - it is bug in hyper-v.

Note, this allocation method does *not* set the starting point for allocation, 
it can return us *any* chunk of memory of given size, below 1GB.

So the attempt to control such allocation by size, is unfortunately flawed - it 
really does not control the allocation.

Note that I have also seen AllocateAddress failures - there was nicely 
available chunk of memory, but the firmware just did not allocate with given 
address (it did happen with OVMF + qemu).

The secondary flaw there is also about firmware. Sure, with UEFI you can have 
“random” allocations and the actual control over memory is actually problem, 
but to plant an “egg”  in 1MB-1GB range, where you have most chances any OS 
will live - IMO this is just stupid.

The only real solution here is to either rise the MaxAddress limit or use 
AllocateAnyPages, get kernel loaded into the memory, and after switching off 
the boot services and before jumping to kernel, relocate the kernel to 
available location below 1GB… 

rgds,
toomas



> 
> Thanks,
> -- Dexuan
> 
>> -Original Message-
>> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
>> curr...@freebsd.org] On Behalf Of Dexuan Cui
>> Sent: Thursday, March 9, 2017 10:44
>> To: Roberto Rodriguez Jr <rob.rodz@gmail.com>
>> Cc: FreeBSD Current <freebsd-current@freebsd.org>
>> Subject: RE: input/output error @boot
>> 
>> [This sender failed our fraud detection checks and may not be who they appear
>> to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>> 
>> Hmm, Alex did report 314891 worked.
>> 
>> Can you please post the full boot log of the loader?
>> Especially, when you see the “OK” prompt, can you please run the “memmap”
>> command like this link ...
>> 
>> You can take a photo of the screen and send it to me, if it’s too big.
>> 
>> 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"

___
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: input/output error @boot

[Pete Wright]

On 3/8/17 10:00 PM, Dexuan Cui wrote:



For now, I suggest we should only apply the idea "reduce the size of the
staging area if necessary" to VM running on Hyper-V, we should restore the
old behavior on physical machines since that has been working for people
for a long period of time, though it's  potentially unsafe.


+1

i'd like to see the old behaviour for physical machines to be restored 
as well since this has rendered my drm-next test rig broken :(


thanks!

-pete


--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
___
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: input/output error @boot

[Dexuan Cui]

Hi Roberto, 
Thanks for sending me your memmap and this is a temporary workaround
patch for you:
https://github.com/dcui/freebsd/commit/0edd1db55fbbb56352d6024250e4ae7dd8ad31e3.patch

I put the memmap info here for people who're interested:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c26

We can notice there is a 4MB BootServicesCode range at [12MB, 16MB) .
loader.efi just writes into this range by force -- this is unsafe anyway!

To fix this correctly & thoroughly, IMO we need a relocatable kernel, but
that would require a lot of complicated long term work:
https://reviews.freebsd.org/D9686?id=25414#inline-56969

For now, I suggest we should only apply the idea "reduce the size of the
staging area if necessary" to VM running on Hyper-V, we should restore the
old behavior on physical machines since that has been working for people
for a long period of time, though it's  potentially unsafe.

I think in the loader we can use CPUID to tell if we're running on Hyper-V or 
not.

Thanks,
-- Dexuan

> -Original Message-
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Dexuan Cui
> Sent: Thursday, March 9, 2017 10:44
> To: Roberto Rodriguez Jr <rob.rodz@gmail.com>
> Cc: FreeBSD Current <freebsd-current@freebsd.org>
> Subject: RE: input/output error @boot
> 
> [This sender failed our fraud detection checks and may not be who they appear
> to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
> 
> Hmm, Alex did report 314891 worked.
> 
> Can you please post the full boot log of the loader?
> Especially, when you see the “OK” prompt, can you please run the “memmap”
> command like this link ...
> 
> You can take a photo of the screen and send it to me, if it’s too big.
> 
> 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: input/output error @boot

[Dexuan Cui]

Hmm, Alex did report 314891 worked.

Can you please post the full boot log of the loader?
Especially, when you see the “OK” prompt, can you please run the “memmap” 
command like this link
https://lists.freebsd.org/pipermail/freebsd-current/2017-March/065090.html ?

You can take a photo of the screen and send it to me, if it’s too big.

Thanks,
-- Dexuan

From: Roberto Rodriguez Jr [mailto:rob.rodz@gmail.com]
Sent: Thursday, March 9, 2017 10:34
To: Dexuan Cui <de...@microsoft.com>
Cc: FreeBSD Current <freebsd-current@freebsd.org>
Subject: RE: input/output error @boot

314916 same error :(
input/output
cannot load file
elf64_loadimage read failed
oh well

On Mar 7, 2017 9:58 PM, "Dexuan Cui" 
<de...@microsoft.com<mailto:de...@microsoft.com>> wrote:
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

From: Roberto Rodriguez Jr 
[mailto:rob.rodz@gmail.com<mailto:rob.rodz@gmail.com>]
Sent: Tuesday, March 7, 2017 21:27

To: Dexuan Cui <de...@microsoft.com<mailto:de...@microsoft.com>>
Cc: FreeBSD Current 
<freebsd-current@freebsd.org<mailto:freebsd-current@freebsd.org>>
Subject: RE: input/output error @boot

I will test tonight. Thank you very much for your time

On Mar 6, 2017 11:52 PM, "Dexuan Cui" 
<de...@microsoft.com<mailto:de...@microsoft.com>> wrote:
> From: Dexuan Cui
> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314770=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990=ZQrsZR%2BVSgQeCx5KKlyCWwxvpCsuwhMP31WTgqQvHW4%3D=0>
>
> Please let me know in case this can't solve the issue.
Sorry, r314770  has a bug, so I had to commit r314828:
https://svnweb.freebsd.org/base?view=revision=314828<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314828=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990=1wchIdcrlXMUxN1DmMeSnuYE7wKHWzoaLYOFP2LregQ%3D=0>

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: input/output error @boot

[Roberto Rodriguez Jr]

314916 same error :(
input/output
cannot load file
elf64_loadimage read failed
oh well

On Mar 7, 2017 9:58 PM, "Dexuan Cui" <de...@microsoft.com> wrote:

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



*From:* Roberto Rodriguez Jr [mailto:rob.rodz@gmail.com]
*Sent:* Tuesday, March 7, 2017 21:27

*To:* Dexuan Cui <de...@microsoft.com>
*Cc:* FreeBSD Current <freebsd-current@freebsd.org>
*Subject:* RE: input/output error @boot



I will test tonight. Thank you very much for your time



On Mar 6, 2017 11:52 PM, "Dexuan Cui" <de...@microsoft.com> wrote:

> From: Dexuan Cui

> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314770=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990=ZQrsZR%2BVSgQeCx5KKlyCWwxvpCsuwhMP31WTgqQvHW4%3D=0>
>
> Please let me know in case this can't solve the issue.

Sorry, r314770  has a bug, so I had to commit r314828:
https://svnweb.freebsd.org/base?view=revision=314828
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314828=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990=1wchIdcrlXMUxN1DmMeSnuYE7wKHWzoaLYOFP2LregQ%3D=0>

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: input/output error @boot

[Dexuan Cui]

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

From: Roberto Rodriguez Jr [mailto:rob.rodz@gmail.com]
Sent: Tuesday, March 7, 2017 21:27
To: Dexuan Cui <de...@microsoft.com>
Cc: FreeBSD Current <freebsd-current@freebsd.org>
Subject: RE: input/output error @boot

I will test tonight. Thank you very much for your time

On Mar 6, 2017 11:52 PM, "Dexuan Cui" 
<de...@microsoft.com<mailto:de...@microsoft.com>> wrote:
> From: Dexuan Cui
> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314770=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990=ZQrsZR%2BVSgQeCx5KKlyCWwxvpCsuwhMP31WTgqQvHW4%3D=0>
>
> Please let me know in case this can't solve the issue.
Sorry, r314770  has a bug, so I had to commit r314828:
https://svnweb.freebsd.org/base?view=revision=314828<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314828=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990=1wchIdcrlXMUxN1DmMeSnuYE7wKHWzoaLYOFP2LregQ%3D=0>

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: input/output error @boot

[Roberto Rodriguez Jr]

I will test tonight. Thank you very much for your time

On Mar 6, 2017 11:52 PM, "Dexuan Cui"  wrote:

> 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:
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: input/output error @boot

[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:
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: input/output error @boot

[Roberto Rodriguez Jr]

Very excellent! looks good ... I do it when I get home from work. Thank u

On Mar 6, 2017 9:06 AM, "Dexuan Cui" <de...@microsoft.com> wrote:

> Hi Roberto,
>
> I’m not sure if the snapshot is built daily or weekly.
>
>
>
> To have this latest fix, I suggest you re-buildworld.
>
> If you have done buildworld in your local directory, then you only need to
> rebuild the EFI loader:
>
>
>
> 'wget' the patch (https://github.com/freebsd/freebsd/commit/
> f61d2c287970bdfb013deafb416e82a844415031.patch)
>
> 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
>
>
>
> *From:* Roberto Rodriguez Jr [mailto:rob.rodz@gmail.com]
> *Sent:* Monday, March 6, 2017 20:33
> *To:* Dexuan Cui <de...@microsoft.com>
> *Cc:* FreeBSD Current <freebsd-current@freebsd.org>
> *Subject:* RE: input/output error @boot
>
>
>
> Hey I do appreciate the work and time put into this issue. I will update
> my sources when I chroot from the USB, need to find out how first, ;) and
> do I rebuildworld  or just download the lastest head snapshot? Im new to
> testing with others. Thank you very much
>
___
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: input/output error @boot

[Dexuan Cui]

Hi Roberto,
I’m not sure if the snapshot is built daily or weekly.

To have this latest fix, I suggest you re-buildworld.
If you have done buildworld in your local directory, then you only need to 
rebuild the EFI loader:

'wget' the patch 
(https://github.com/freebsd/freebsd/commit/f61d2c287970bdfb013deafb416e82a844415031.patch)
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

From: Roberto Rodriguez Jr [mailto:rob.rodz@gmail.com]
Sent: Monday, March 6, 2017 20:33
To: Dexuan Cui <de...@microsoft.com>
Cc: FreeBSD Current <freebsd-current@freebsd.org>
Subject: RE: input/output error @boot

Hey I do appreciate the work and time put into this issue. I will update my 
sources when I chroot from the USB, need to find out how first, ;) and do I 
rebuildworld  or just download the lastest head snapshot? Im new to testing 
with others. Thank you very much
___
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: input/output error @boot

[Roberto Rodriguez Jr]

Hey I do appreciate the work and time put into this issue. I will update my
sources when I chroot from the USB, need to find out how first, ;) and do I
rebuildworld  or just download the lastest head snapshot? Im new to testing
with others. Thank you very much
___
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: input/output error @boot

[Dexuan Cui]

> From: Dexuan Cui
> Sent: Monday, March 6, 2017 14:35
> To: 'Roberto Rodriguez Jr' <rob.rodz@gmail.com>; freebsd-
> curr...@freebsd.org
> Subject: RE: input/output error @boot
> 
> > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> > curr...@freebsd.org] On Behalf Of Roberto Rodriguez Jr
> > Sent: Monday, March 6, 2017 04:05
> > To: freebsd-current@freebsd.org
> > Subject: Re: input/output error @boot
> >
> > When I get to the house I'll try to patch it and see if I get any results.
> > Thank u very much
> 
> Hi Roberto,
> I posted https://reviews.freebsd.org/D9904 to fix the issue.
> It would be great if you can try this patch directly.
> 
> I'm planning to commit the patch to the HEAD in ~3 hours.
 
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: input/output error @boot

[Dexuan Cui]

> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Roberto Rodriguez Jr
> Sent: Monday, March 6, 2017 04:05
> To: freebsd-current@freebsd.org
> Subject: Re: input/output error @boot
> 
> When I get to the house I'll try to patch it and see if I get any results.
> Thank u very much

Hi Roberto, 
I posted https://reviews.freebsd.org/D9904 to fix the issue.
It would be great if you can try this patch directly.

I'm planning to commit the patch to the HEAD in ~3 hours.

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: input/output error @boot

[Roberto Rodriguez Jr]

When I get to the house I'll try to patch it and see if I get any results.
Thank u very much


I guess this is
https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064971.html

Best regards
Michael
> ___
> 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: input/output error @boot

[Michael Tuexen]

> On 5 Mar 2017, at 18:20, Roberto Rodriguez Jr  wrote:
> 
> HP 15 AMD64 laptop a6-5200 apu... this is the error below
> 
> On Mar 5, 2017 11:37 AM, "Ultima"  wrote:
> 
> Its showing...
> 
> elf64_loadimage: read failed
> can't load file /boot/kernel/kernel
> 
> Can the same when attempting to load kernel.old, had to revert to old
> snapshot on usb rescue.
> This is not a hardware problem.
I guess this is
https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064971.html

Best regards
Michael
> ___
> 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: input/output error @boot

[Roberto Rodriguez Jr]

HP 15 AMD64 laptop a6-5200 apu... this is the error below

On Mar 5, 2017 11:37 AM, "Ultima"  wrote:

Its showing...

elf64_loadimage: read failed
can't load file /boot/kernel/kernel

Can the same when attempting to load kernel.old, had to revert to old
snapshot on usb rescue.
This is not a hardware problem.
___
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: input/output error @boot

[Ultima]

Its showing...

elf64_loadimage: read failed
can't load file /boot/kernel/kernel

Can the same when attempting to load kernel.old, had to revert to old
snapshot on usb rescue.
This is not a hardware problem.

On Sun, Mar 5, 2017 at 10:43 AM, Warner Losh  wrote:

> On Sun, Mar 5, 2017 at 8:16 AM, Guido Falsi  wrote:
> > On 03/05/17 16:04, Roberto Rodriguez Jr wrote:
> >> I installed the latest snapshot and when I checked out the latest Source
> >> yesterday evening I rebuilt world and kernel installed kernel rebooted
> >> installed World follow every step in the handbook and I continue to
> have an
> >> input output error at boot time I can't attach a picture at the moment
> or
> >> any text about the error cuz I cannot proceed after the boot screen
> under
> >> UEFI.. I get a ? prompt
> >
> > I am unable to help you about this, I'm not an expert about UEFI, but
> > anyone able to will need some more information.
> >
> > You should at least state make and model of your Mother board and CPU,
> > kind of disks attached, type make and model of controller. If it is a
> > branded box, make and model of the box could suffice.
>
> If it is the UEFI Shell, which is possible, try typing 'FS0:' and see
> if the prompt changes to FS0:\> or similar. Then cd boot and see if
> there's an EFI subdir. cd to EFI subdir and see if there's any .efi
> programs. There should at least be bootx64.efi if there's a loot
> loader. If there is, you can type bootx64.efi. If not, then I'm not
> sure what the ? is.
>
> Warner
> ___
> 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: input/output error @boot

[Warner Losh]

On Sun, Mar 5, 2017 at 8:16 AM, Guido Falsi  wrote:
> On 03/05/17 16:04, Roberto Rodriguez Jr wrote:
>> I installed the latest snapshot and when I checked out the latest Source
>> yesterday evening I rebuilt world and kernel installed kernel rebooted
>> installed World follow every step in the handbook and I continue to have an
>> input output error at boot time I can't attach a picture at the moment or
>> any text about the error cuz I cannot proceed after the boot screen under
>> UEFI.. I get a ? prompt
>
> I am unable to help you about this, I'm not an expert about UEFI, but
> anyone able to will need some more information.
>
> You should at least state make and model of your Mother board and CPU,
> kind of disks attached, type make and model of controller. If it is a
> branded box, make and model of the box could suffice.

If it is the UEFI Shell, which is possible, try typing 'FS0:' and see
if the prompt changes to FS0:\> or similar. Then cd boot and see if
there's an EFI subdir. cd to EFI subdir and see if there's any .efi
programs. There should at least be bootx64.efi if there's a loot
loader. If there is, you can type bootx64.efi. If not, then I'm not
sure what the ? is.

Warner
___
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: input/output error @boot

[Guido Falsi]

On 03/05/17 16:04, Roberto Rodriguez Jr wrote:
> I installed the latest snapshot and when I checked out the latest Source
> yesterday evening I rebuilt world and kernel installed kernel rebooted
> installed World follow every step in the handbook and I continue to have an
> input output error at boot time I can't attach a picture at the moment or
> any text about the error cuz I cannot proceed after the boot screen under
> UEFI.. I get a ? prompt

I am unable to help you about this, I'm not an expert about UEFI, but
anyone able to will need some more information.

You should at least state make and model of your Mother board and CPU,
kind of disks attached, type make and model of controller. If it is a
branded box, make and model of the box could suffice.

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