Re: input/output error @boot
On Thu, 9 Mar 2017 06:00:23 + Dexuan Cui 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 > > Cc: FreeBSD Current > > 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
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
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&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
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&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
> 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, &staging); >> >> 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
> 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, &staging); > > 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
> 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&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
> On 9. märts 2017, at 8:00, Dexuan Cui 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, &staging); 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 >> Cc: FreeBSD Current >> 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
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
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 > Cc: FreeBSD Current > 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
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 Cc: FreeBSD Current 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" 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 mailto:de...@microsoft.com>> Cc: FreeBSD Current 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" mailto:de...@microsoft.com>> wrote: > From: Dexuan Cui > I committed r314770 just now to minimize the impact: > https://svnweb.freebsd.org/base?view=revision&revision=314770<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314770&data=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990&sdata=ZQrsZR%2BVSgQeCx5KKlyCWwxvpCsuwhMP31WTgqQvHW4%3D&reserved=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&revision=314828<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314828&data=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990&sdata=1wchIdcrlXMUxN1DmMeSnuYE7wKHWzoaLYOFP2LregQ%3D&reserved=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
314916 same error :( input/output cannot load file elf64_loadimage read failed oh well On Mar 7, 2017 9:58 PM, "Dexuan Cui" 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 *Cc:* FreeBSD Current *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" wrote: > From: Dexuan Cui > I committed r314770 just now to minimize the impact: > https://svnweb.freebsd.org/base?view=revision&revision=314770 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314770&data=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990&sdata=ZQrsZR%2BVSgQeCx5KKlyCWwxvpCsuwhMP31WTgqQvHW4%3D&reserved=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&revision=314828 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314828&data=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990&sdata=1wchIdcrlXMUxN1DmMeSnuYE7wKHWzoaLYOFP2LregQ%3D&reserved=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
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 Cc: FreeBSD Current 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" mailto:de...@microsoft.com>> wrote: > From: Dexuan Cui > I committed r314770 just now to minimize the impact: > https://svnweb.freebsd.org/base?view=revision&revision=314770<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314770&data=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990&sdata=ZQrsZR%2BVSgQeCx5KKlyCWwxvpCsuwhMP31WTgqQvHW4%3D&reserved=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&revision=314828<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvnweb.freebsd.org%2Fbase%3Fview%3Drevision%26revision%3D314828&data=02%7C01%7Cdecui%40microsoft.com%7C4740c4467d264a5ec04f08d4655da57a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244900268178990&sdata=1wchIdcrlXMUxN1DmMeSnuYE7wKHWzoaLYOFP2LregQ%3D&reserved=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
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&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&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
> From: Dexuan Cui > I committed r314770 just now to minimize the impact: > https://svnweb.freebsd.org/base?view=revision&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&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
Very excellent! looks good ... I do it when I get home from work. Thank u On Mar 6, 2017 9:06 AM, "Dexuan Cui" 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 > *Cc:* FreeBSD Current > *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
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 Cc: FreeBSD Current 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
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
> From: Dexuan Cui > Sent: Monday, March 6, 2017 14:35 > To: 'Roberto Rodriguez Jr' ; 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&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
> 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
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
> 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
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
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
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
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"