Re: r336921 broke booting on MBP 2017, EFIRT related

[Toomas Soome]

> On 29 Aug 2018, at 15:05, Toomas Soome  wrote:
> 
> 
> 
>> On 29 Aug 2018, at 14:53, Yuri Pankov > <mailto:yur...@yuripv.net>> wrote:
>> 
>> Yuri Pankov wrote:
>>> Konstantin Belousov wrote:
>>>> On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:
>>>>> Hi,
>>>>> 
>>>>> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
>>>>> 20180802) fail to boot on MBP 2017:
>>>>> 
>>>>> kbd0 at kbdmux0
>>>>> netmap: loaded module
>>>>> nexus0
>>>>> 
>>>>> Fatal trap 12: page fault while in kernel mode
>>>>> cpuid = 2: apic id = 02
>>>>> fault virtual address  = 0x74c64a50
>>>>> fault code = supervisor read data, page not present
>>>>> instruction pointer= 0x20: 0x7abece31
>>>>> stack pointer  = 0x28: 0x82b2f7c0
>>>>> frame pointer  = 0x28: 0x82b2f810
>>>>> code segment   = base 0x0, limit 0xf, type 0x1b
>>>>>  = DPL 0, pres 1, long 1, def32 0, gran 1
>>>>> processor eflags   = interrupt enabled, resume, IOPL = 0
>>>>> current process= 0 (swapper)
>>>>> [ thread pid 0 tid 10 ]
>>>>> Stopped at  0x7abece31:calll   *0x18(%rax)
>>>>> db>
>>>>> 
>>>>> Sadly, there's no support for internal keyboard yet (it's connected via
>>>>> SPI), and external USB one stops working.
>>>>> 
>>>>> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
>>>>> 
>>>>> Some questions here:
>>>>> - is this something that can/should be fixed?
>>>>> - can we print some "enabling EFIRT" message to the console to make
>>>>> guesses about the problem source a bit easier?
>>>> 
>>>> It is not in 'enabling'.  Looking at the faulting VA, I believe that
>>>> it occurs inside the BIOS code.
>>>> 
>>>> Disable efirt by removing the kernel option, then try to load the module
>>>> at runtime.  Does it still fault ?  Also, get the efi mem map for the
>>>> machine and look at which region the faulting address and the faulting
>>>> instruction belong.
>>> kldload'ing the efirt module gets the same fault.  Several top lines of 
>>> backtrace:
>>> kernphys() at 0x7abece31
>>> efi_get_time() at efi_get_time+0xd9
>>> efirtc_probe() at efirtc_probe+0x17
>> 
>> For the efi mem map, if I'm understanding it correctly, there's the 
>> following:
>> 
>> ...
>>   BootServicesData 7421d000  0a8b UC WC WT WB
>> ...
>> RuntimeServicesCode 7ab9f000  0070 UC WC WT WB
>> …
> 
> if my math is correct, this RTS code area will end at 0x7abe5000 and 
> if 0x7abece31 is fault location, its just after that RTS code area, 
> that is, 7 pages after… meaning you would need to get the next entry:)
> 

ya well, my math does suck because its 0x70 pages, not 70:D

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: r336921 broke booting on MBP 2017, EFIRT related

[Toomas Soome]

> On 29 Aug 2018, at 14:53, Yuri Pankov  wrote:
> 
> Yuri Pankov wrote:
>> Konstantin Belousov wrote:
>>> On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:
 Hi,
 
 I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
 20180802) fail to boot on MBP 2017:
 
 kbd0 at kbdmux0
 netmap: loaded module
 nexus0
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 2: apic id = 02
 fault virtual address  = 0x74c64a50
 fault code = supervisor read data, page not present
 instruction pointer= 0x20: 0x7abece31
 stack pointer  = 0x28: 0x82b2f7c0
 frame pointer  = 0x28: 0x82b2f810
 code segment   = base 0x0, limit 0xf, type 0x1b
  = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags   = interrupt enabled, resume, IOPL = 0
 current process= 0 (swapper)
 [ thread pid 0 tid 10 ]
 Stopped at  0x7abece31:calll   *0x18(%rax)
 db>
 
 Sadly, there's no support for internal keyboard yet (it's connected via
 SPI), and external USB one stops working.
 
 A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
 
 Some questions here:
 - is this something that can/should be fixed?
 - can we print some "enabling EFIRT" message to the console to make
 guesses about the problem source a bit easier?
>>> 
>>> It is not in 'enabling'.  Looking at the faulting VA, I believe that
>>> it occurs inside the BIOS code.
>>> 
>>> Disable efirt by removing the kernel option, then try to load the module
>>> at runtime.  Does it still fault ?  Also, get the efi mem map for the
>>> machine and look at which region the faulting address and the faulting
>>> instruction belong.
>> kldload'ing the efirt module gets the same fault.  Several top lines of 
>> backtrace:
>> kernphys() at 0x7abece31
>> efi_get_time() at efi_get_time+0xd9
>> efirtc_probe() at efirtc_probe+0x17
> 
> For the efi mem map, if I'm understanding it correctly, there's the following:
> 
> ...
>   BootServicesData 7421d000  0a8b UC WC WT WB
> ...
> RuntimeServicesCode 7ab9f000  0070 UC WC WT WB
> …

if my math is correct, this RTS code area will end at 0x7abe5000 and if 
0x7abece31 is fault location, its just after that RTS code area, that 
is, 7 pages after… meaning you would need to get the next entry:)

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: FreeBSD EFI projects

[Toomas Soome]

> On 19 Sep 2018, at 18:31, Rodney W. Grimes 
>  wrote:
> 
>> On Wed, Sep 19, 2018 at 6:06 PM, Rodney W. Grimes 
>>  wrote:
 On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
  wrote:
>> On 9/18/18 4:11 AM, Greg V wrote:
>> 
>>> 
>>> I can confirm that the kernel already worked fine when booted 
 from
>>> 32-bit EFI.
>>> 
>>> I booted an old Mac into HardenedBSD using a 32-bit-EFI build 
 of
>> GRUB2 :)
>> 
>> 
>> Was that a 64-bit version of FreeBSD? My understanding is the 
 32-bit
>> FreeBSD boots fine, but 64-bit needs work.
> 
> You would be hard pressed to find a system with a 64 bit CPU that
> could run 64 bit FreeBSD that had a 32 bit EFI implementation.
 
 Mac mini 2006 with a Core2Duo instead of the stock CoreDuo (and the
 2007 model's firmware flashed, but I don't think that impacts 
 FreeBSD).
>>> 
>>> Yes, that is one of the catagories of rare, a EFI-32 bit system that
>>> was originally shipped with a 32 bit only CPU, that later got upgraded
>>> in the field with a 64 bit CPU, that still runs a EFI-32 bios.
>>> Are you sure the 2007 firmware is EFI32?  I would of thought
>>> since they upgraded the base system to a 64 bit CPU they would
>>> of shipped it with a EFI-64 bios.
>> 
>> The EFI firmware is technically 64 bit? but it only boots 32-bit 
>> binaries.
>> 
>> https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html
>> 'Furthermore, it appears that although subsequently released MacBook, 
>> MacBook Air, and pre-"Mid-2010" Mac mini models all are equipped with 
>> "Core 2 Duo" 64-bit processors and 64-bit EFIs, Apple has blocked these 
>> "consumer-targeted" Macs from booting in 64-bit mode. iMac and MacBook 
>> Pro models released in 2007 with 64-bit EFIs seem to have been blocked 
>> as well.'
> 
> That is not EFI32, so that is not a test case for how FreeBSD boots   
>   
>  
> on EFI32 systems.  That is a restriction apple artificially placed
> in the implementation.
> 
 And probably just the 2007 model as well :)
 
 Also, IIRC there were some Intel Atom tablets with 32-bit EFI.
>>> 
>>> Atom N2xx and Z5xx series Atom models cannot run x86-64
>> 
>> Atom Z3740 ? "Instruction Set: 64-bit"
>> https://ark.intel.com/products/76759/Intel-Atom-Processor-Z3740-2M-Cache-up-to-1_86-GHz
>>  
>> 
> 
> The above does not say Atom Z3xxx.  If you find a Atom
> N2xx or Z5xx based system it most certainly has a EFI32.
> 
>> 
>> The tablet in question: ASUS VivoTab Note 8 (M80TA)
>> https://www.asus.com/us/Tablets/ASUS_VivoTab_Note_8_M80TA/ 
>> 
> 
> I can not find enough detail to know for certain that tablet
> actually has which version of EFI.
> You are saying it has EFI32?  And if so based on what information?
> 

I have Lenovo MIIX-300 and it has UEFI32.

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: FreeBSD EFI projects

[Toomas Soome]

I still have it all in the queue, just the paid work is taking its toll and 
then FreeBSD and illumos  :)

Next week I am on vacation trip but then I’ll be back and kicking. 

Rgds,
Toomas

Sent from my iPhone

> On 20 Sep 2018, at 02:37, Warner Losh  wrote:
> 
>> On Wed, Sep 19, 2018 at 4:33 PM Rebecca Cran  wrote:
>> 
>> Oh, that's a really good point - thanks! I happen to have a Minnowboard
>> Turbot currently sitting unused.
>> 
> 
> One other idea, unrelated to the 32-bit UEFI to boot 64-bit kernel, is to
> see about mining tsoome@'s port of FreeBSD boot loader to OpenIndiana. He's
> done a lot of cool things that would be useful to bring in, but need
> someone with a UEFI clue to do it. He's not had the time to get them
> reviewed and tested in our environment, if I understand correctly. You
> might want to reach out to him to see if there's things that would be
> useful. The biggest one I can think of is that his efi show variable code
> knows about standard UEFI variables and prints them out interpreted, not in
> unhelpful without the standard handy binary form like our loader does.
> 
> 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: UEFI Loader problems in CURRENT

[Toomas Soome]

If the hung/crash is after printout of bootorder, and the fix (at least in some 
cases) is about setting the boot device (with linux tools, but I’d assume the 
efi bootmanager setup would do the same), it means, we do get bad value from 
efi boot manager variables, and if the fbsd installer and/or boot program 
update does not include the variable setup, we can not rely on those values in 
loader. Or, we should have foolproof way to check the values - if we can trust 
them. 

Rgds,
Toomas

> On 30 Sep 2018, at 08:06, Warner Losh  wrote:
> 
> Having had a few hours to think about things, I'm starting to think that
> the loader may be crashing w/o any clue or traceback. I'll look into this
> being a possibility. In the past, this has happened because of an untested
> error condition and/or assuming pointers were non-NULL. It would be super
> swell if there were a cheap to obtain box that exhibits this problem.
> 
> Warner
> 
>> On Sat, Sep 29, 2018 at 6:14 PM Warner Losh  wrote:
>> 
>> Sadly both of these bugs are thin on detail beyond it doesn't work. Makes
>> it hard to even look into it.
>> 
>> Warner
>> 
>>> On Sat, Sep 29, 2018, 6:00 PM Yuri  wrote:
>>> 
>>> See:
>>> 
>>> * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230090
>>> 
>>> * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219957
>>> 
>>> 
>>> Yuri
>>> 
>>> 
>>> ___
>>> 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"
___
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: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

[Toomas Soome]

> On 22 Oct 2018, at 06:30, Warner Losh  wrote:
> 
> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh  > wrote:
> 
>> 
>> 
>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable <
>> freebsd-sta...@freebsd.org> wrote:
>> 
>>> [I built based on WITHOUT_ZFS= for other reasons. But,
>>> after installing the build, Hyper-V based boots are
>>> working.]
>>> 
>>> On 2018-Oct-20, at 2:09 AM, Mark Millard  wrote:
>>> 
 On 2018-Oct-20, at 1:39 AM, Mark Millard  wrote:
 
> I attempted to jump from head -r334014 to -r339076
> on a threadripper 1950X board and the boot fails.
> This is both native booting and under Hyper-V,
> same machine and root file system in both cases.
 
 I did my investigation under Hyper-V after seeing
 a boot failure native.
 
 Looks like the native failure is even earlier,
 before db> is even possible, possibly during
 early loader activity.
 
 So this report is really for running under
 Hyper-V: -r338804 boots and -r338810 does
 not. By contrast -r334804 does not boot native.
 (But I've little information for that context.)
 
 Sorry for the confusion. I rushed the report
 in hopes of getting to sleep. It was not to be.
 
> It fails just after the FreeBSD/SMP lines,
> reporting "kernel trap 9 with interrupts disabled".
> 
> It fails in pmap_force_invaldiate_cache_range at
> a clflusl (%rax) instruction that produces a
> "Fatal trap 9: general protection fault while
> in kernel mode". cpudid=0 apic id= 00
> 
> I used kernel.txz files from:
> 
> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/
> 
> to narrow the range of kernel builds for working -> failing
> and got:
> 
> -r338804 boots fine
> (no amd64 kernel builds between to try)
> -r338810+ fails (any that I tried, anyway)
> 
> In that range is -r338807 :
> 
> QUOTE
> Author: kib
> Date: Wed Sep 19 19:35:02 2018
> New Revision: 338807
> URL:
> https://svnweb.freebsd.org/changeset/base/338807
> 
> 
> Log:
> Convert x86 cache invalidation functions to ifuncs.
> 
> This simplifies the runtime logic and reduces the number of
> runtime-constant branches.
> 
> Reviewed by: alc, markj
> Sponsored by:The FreeBSD Foundation
> Approved by: re (gjb)
> Differential revision:
> https://reviews.freebsd.org/D16736
> 
> Modified:
> head/sys/amd64/amd64/pmap.c
> head/sys/amd64/include/pmap.h
> head/sys/dev/drm2/drm_os_freebsd.c
> head/sys/dev/drm2/i915/intel_ringbuffer.c
> head/sys/i386/i386/pmap.c
> head/sys/i386/i386/vm_machdep.c
> head/sys/i386/include/pmap.h
> head/sys/x86/iommu/intel_utils.c
> END QUOTE
> 
> There do seem to be changes associated with
> clflush(...) use. Looking at:
> 
> 
>>> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=339432
> 
> it appears that pmap_force_invalidate_cache_range has not
> changed since -r338807.
> 
> It seems that -r338806 and -r3388810 would be unlikely
> contributors.
 
>>> 
>>> I went after my native-boot loader problem first because I
>>> could switch kernels via the loader for booting FreeBSD under
>>> Hyper-V. Switching loaders is more of a problem.
>>> 
>>> In order to avoid the loader-time crash I switched to building
>>> installing based on WITHOUT_ZFS= . I've had no active use of
>>> ZFS in years. (The old official-build loaders that worked were
>>> non-ZFS ones.)
>>> 
>>> This took care of the native-boot loader-crash --and, to my
>>> surprise, also the Hyper-V-boot kernel-time crash.
>>> 
>>> My private builds now boot the 1950X in both contexts just
>>> fine.
>>> 
>>> During my early investigation I did pick up specific changes
>>> from after -r339076 that seemed to be tied to Ryzen and such.
>>> (They made no difference to the boot problems at the time
>>> but I saw no reason to remove them.)
>>> 
>>> # uname -apKU
>>> FreeBSD FBSDFSSD 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #5 r339076:339432M: Sun
>>> Oct 21 16:44:25 PDT 2018 
>>> markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG
>>> amd64 amd64 1200084 1200084
>> 
>> 
> (stupid gmail)
> 
> The phrase "no active use" bothers me. What does that mean? Are there any
> ZFS pools or any disks that any whiff of ZFSish thing on it at all?
> Clearly, there's something in the zfs boot loader that's freaking out by
> something on your system, but absent that information I can't help you.
> 

It would help to get output from loader lsdev -v command. Also if you could 
test boot loader with UEFI - for example get to loader prompt via usb/cd boot 
and then get the same lsdev -v output. I would be interested to see the sector 
size information and if the UEFI loader does also have issues. If it does, I’d 
like to see the o

Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

[Toomas Soome]

> On 22 Oct 2018, at 13:58, Mark Millard  wrote:
> 
> On 2018-Oct-22, at 2:27 AM, Toomas Soome http://me.com/>> 
> wrote:
>> 
>>> On 22 Oct 2018, at 06:30, Warner Losh  wrote:
>>> 
>>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh  wrote:
>>> 
>>>> 
>>>> 
>>>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable <
>>>> freebsd-sta...@freebsd.org> wrote:
>>>> 
>>>>> [I built based on WITHOUT_ZFS= for other reasons. But,
>>>>> after installing the build, Hyper-V based boots are
>>>>> working.]
>>>>> 
>>>>> On 2018-Oct-20, at 2:09 AM, Mark Millard  wrote:
>>>>> 
>>>>>> On 2018-Oct-20, at 1:39 AM, Mark Millard  wrote:
>>>>>> 
>>>>>>> I attempted to jump from head -r334014 to -r339076
>>>>>>> on a threadripper 1950X board and the boot fails.
>>>>>>> This is both native booting and under Hyper-V,
>>>>>>> same machine and root file system in both cases.
>>>>>> 
>>>>>> I did my investigation under Hyper-V after seeing
>>>>>> a boot failure native.
>>>>>> 
>>>>>> Looks like the native failure is even earlier,
>>>>>> before db> is even possible, possibly during
>>>>>> early loader activity.
>>>>>> 
>>>>>> So this report is really for running under
>>>>>> Hyper-V: -r338804 boots and -r338810 does
>>>>>> not. By contrast -r334804 does not boot native.
>>>>>> (But I've little information for that context.)
>>>>>> 
>>>>>> Sorry for the confusion. I rushed the report
>>>>>> in hopes of getting to sleep. It was not to be.
>>>>>> 
>>>>>>> It fails just after the FreeBSD/SMP lines,
>>>>>>> reporting "kernel trap 9 with interrupts disabled".
>>>>>>> 
>>>>>>> It fails in pmap_force_invaldiate_cache_range at
>>>>>>> a clflusl (%rax) instruction that produces a
>>>>>>> "Fatal trap 9: general protection fault while
>>>>>>> in kernel mode". cpudid=0 apic id= 00
>>>>>>> 
>>>>>>> I used kernel.txz files from:
>>>>>>> 
>>>>>>> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/
>>>>>>> 
>>>>>>> to narrow the range of kernel builds for working -> failing
>>>>>>> and got:
>>>>>>> 
>>>>>>> -r338804 boots fine
>>>>>>> (no amd64 kernel builds between to try)
>>>>>>> -r338810+ fails (any that I tried, anyway)
>>>>>>> 
>>>>>>> In that range is -r338807 :
>>>>>>> 
>>>>>>> QUOTE
>>>>>>> Author: kib
>>>>>>> Date: Wed Sep 19 19:35:02 2018
>>>>>>> New Revision: 338807
>>>>>>> URL:
>>>>>>> https://svnweb.freebsd.org/changeset/base/338807
>>>>>>> 
>>>>>>> 
>>>>>>> Log:
>>>>>>> Convert x86 cache invalidation functions to ifuncs.
>>>>>>> 
>>>>>>> This simplifies the runtime logic and reduces the number of
>>>>>>> runtime-constant branches.
>>>>>>> 
>>>>>>> Reviewed by: alc, markj
>>>>>>> Sponsored by:The FreeBSD Foundation
>>>>>>> Approved by: re (gjb)
>>>>>>> Differential revision:
>>>>>>> https://reviews.freebsd.org/D16736
>>>>>>> 
>>>>>>> Modified:
>>>>>>> head/sys/amd64/amd64/pmap.c
>>>>>>> head/sys/amd64/include/pmap.h
>>>>>>> head/sys/dev/drm2/drm_os_freebsd.c
>>>>>>> head/sys/dev/drm2/i915/intel_ringbuffer.c
>>>>>>> head/sys/i386/i386/pmap.c
>>>>>>> head/sys/i386/i386/vm_machdep.c
>>>>>>> head/sys/i386/include/pmap.h
>>>>>>> head/sys/x86/iommu/intel_utils.c
>>>>>>> END QUOTE
>>>>>>> 
>>>>>>> There do seem to be changes associated with
>>>>>>> clflush(...) 

Re: loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated)

[Toomas Soome]

> On 23 Oct 2018, at 13:53, Lev Serebryakov  wrote:
> 
> On 22.10.2018 12:27, Toomas Soome wrote:
> 
>> It would help to get output from loader lsdev -v command.
> current loader crashes on "lsdev" for me:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232483 (it is not
> threadripper-related, my hardware is Intel Atom).
> 
> -- 
> // Lev Serebryakov
> 

That error means something is corrupting the memory, it is hard to guess what 
exactly and debugging it is nasty - it means we would need to track down what 
was allocated before this memory block (guard1 is marker inserted in front of 
the allocated memory block). 

Fortunately the code to print the partition table is in stand/common/disk.c and 
the partition code is just next to it and so it should be relatively easy to 
find the guilty one… I will try to see if I can replicate the issue.

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: UEFI boot hangs after loader

[Toomas Soome]

Do you get boot menu? if so, press esc to get to ok prompt, then type start - 
if its bootfort based loader, it will load the kernel and modules. lsmod will 
then list the loaded files.

If the loader prompt is still usable, then next command would be: boot

rgds,
toomas

> On 23 Oct 2018, at 20:45, Harry Newton  wrote:
> 
> Just upgraded my Asus UX303L (amd64) from 11-STABLE to 12.0-BETA1 r339529
> by source.  Have a problem with booting which hangs after:
> 
>>> FreeBSD EFI boot block
> Loader path: /boot/loader.efi
> 
> Initializing modules: ZFS UFS
> Probing 5 block devices ... done
>  ZFS found the following pools: zroot
>  UFS found no partitions
>  Consoles: EFI console
>  FreeBSD/amd64 EFI loader, Revision 1.1
> 
>Command line arguments: loader.efi
>EFI version 2.31
>EFI Firmware: American Megatrends (rev 4.654)
>Console: efi(0)
>Load Path: HD(4, GPT [ ... ]
>Load Device: Pci Root [ ... ]
>Boot Current: 0001
>Boot Order: 0001 [x]
>Boot Info Path: HS(1, GPT,  [ ... ]  /\EFI\BOOT\BOOTX64.EFI
> -
> 
> So it gets into loader.efi which runs but stops I think just before loading
> the kernel.  Partitions:
> 
> =>   40  250069600  ada0  GPT  (119G)
> 40   1600 1  efi  (800K)
>   1640   1024 2  freebsd-boot  (512K)
>   2664   1432- free -  (716K)
>   40964194304 3  freebsd-swap  (2.0G)
>4198400  245870592 4  freebsd-zfs  (117G)
>  250068992648- free -  (324K)
> 
> and the EFI partition is FAT 12.
> 
> I can't provide (at the moment) any output from efibootmgr:
> 
> root@gryphon:~ # efibootmgr -v
> efibootmgr: efi variables not supported on this system. root? kldload efirt?
> root@gryphon:~ # kldload efirt
> kldload: can't load efirt: module already loaded or in kernel
> 
> which I don't understand.
> 
> I'm going to rebuild the kernel (currently GENERIC) and see if that allows
> me to load efirt / use efibootmgr.
> 
> In the meantime, I should be very grateful for any advice.
> 
> ( Currently booting using a 11-RELEASE memstick image and dropping into its
> loader to get to the installed 12-STABLE ).
> 
> /Harry
> ___
> 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: UEFI boot hangs after loader

[Toomas Soome]

hm. in that case, whats the content of /boot/loader.rc ?

rgds,
toomas

> On 23 Oct 2018, at 23:01, Harry Newton  wrote:
> 
> If boot menu is the screen where you get the options for various kernels and 
> the picture of the daemon head, no.  It stops at the point in my email — 
> though not as I said just before the kernel is loaded but in point of fact 
> before the menu.
> 
> I've also rebuilt the kernel and still can't use efibootmgr which is puzzling 
> me.
> 
> /H
> 
> 
> On 23 October 2018 at 20:56, Toomas Soome  <mailto:tso...@me.com>> wrote:
> Do you get boot menu? if so, press esc to get to ok prompt, then type start - 
> if its bootfort based loader, it will load the kernel and modules. lsmod will 
> then list the loaded files.
> 
> If the loader prompt is still usable, then next command would be: boot
> 
> rgds,
> toomas
> 
> > On 23 Oct 2018, at 20:45, Harry Newton  > <mailto:h...@yewbarrow.net>> wrote:
> > 
> > Just upgraded my Asus UX303L (amd64) from 11-STABLE to 12.0-BETA1 r339529
> > by source.  Have a problem with booting which hangs after:
> > 
> >>> FreeBSD EFI boot block
> > Loader path: /boot/loader.efi
> > 
> > Initializing modules: ZFS UFS
> > Probing 5 block devices ... done
> >  ZFS found the following pools: zroot
> >  UFS found no partitions
> >  Consoles: EFI console
> >  FreeBSD/amd64 EFI loader, Revision 1.1
> > 
> >Command line arguments: loader.efi
> >EFI version 2.31
> >EFI Firmware: American Megatrends (rev 4.654)
> >Console: efi(0)
> >Load Path: HD(4, GPT [ ... ]
> >Load Device: Pci Root [ ... ]
> >Boot Current: 0001
> >Boot Order: 0001 [x]
> >Boot Info Path: HS(1, GPT,  [ ... ]  /\EFI\BOOT\BOOTX64.EFI
> > -
> > 
> > So it gets into loader.efi which runs but stops I think just before loading
> > the kernel.  Partitions:
> > 
> > =>   40  250069600  ada0  GPT  (119G)
> > 40   1600 1  efi  (800K)
> >   1640   1024 2  freebsd-boot  (512K)
> >   2664   1432- free -  (716K)
> >   40964194304 3  freebsd-swap  (2.0G)
> >4198400  245870592 4  freebsd-zfs  (117G)
> >  250068992648- free -  (324K)
> > 
> > and the EFI partition is FAT 12.
> > 
> > I can't provide (at the moment) any output from efibootmgr:
> > 
> > root@gryphon:~ # efibootmgr -v
> > efibootmgr: efi variables not supported on this system. root? kldload efirt?
> > root@gryphon:~ # kldload efirt
> > kldload: can't load efirt: module already loaded or in kernel
> > 
> > which I don't understand.
> > 
> > I'm going to rebuild the kernel (currently GENERIC) and see if that allows
> > me to load efirt / use efibootmgr.
> > 
> > In the meantime, I should be very grateful for any advice.
> > 
> > ( Currently booting using a 11-RELEASE memstick image and dropping into its
> > loader to get to the installed 12-STABLE ).
> > 
> > /Harry
> > ___
> > freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> mailing 
> > list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current 
> > <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org 
> > <mailto:freebsd-current-unsubscr...@freebsd.org>"
> 
> 
> 
> 
> -- 
> Harry Newton

___
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: UEFI boot hangs after loader

[Toomas Soome]

ok, in that case I’d suggest to test out if forth based one is still working - 
at least you can get the bootable system. And then there is a chance to debug 
the lua version too (note it should be possible to chain /boot/loader_lua.efi).

rgds,
toomas

> On 23 Oct 2018, at 23:08, Harry Newton  wrote:
> 
> So it's got FORTH in it, but my loader is lua based, and also doesn't
> appear to read loader.rc.
> 
> /H
> 
> On 23 October 2018 at 21:03, Toomas Soome  wrote:
> 
>> hm. in that case, whats the content of /boot/loader.rc ?
>> 
>> rgds,
>> toomas
>> 
>> 
>> On 23 Oct 2018, at 23:01, Harry Newton  wrote:
>> 
>> If boot menu is the screen where you get the options for various kernels
>> and the picture of the daemon head, no.  It stops at the point in my email
>> — though not as I said just before the kernel is loaded but in point of
>> fact before the menu.
>> 
>> I've also rebuilt the kernel and still can't use efibootmgr which is
>> puzzling me.
>> 
>> /H
>> 
>> 
>> On 23 October 2018 at 20:56, Toomas Soome  wrote:
>> 
>>> Do you get boot menu? if so, press esc to get to ok prompt, then type
>>> start - if its bootfort based loader, it will load the kernel and modules.
>>> lsmod will then list the loaded files.
>>> 
>>> If the loader prompt is still usable, then next command would be: boot
>>> 
>>> rgds,
>>> toomas
>>> 
>>>> On 23 Oct 2018, at 20:45, Harry Newton  wrote:
>>>> 
>>>> Just upgraded my Asus UX303L (amd64) from 11-STABLE to 12.0-BETA1
>>> r339529
>>>> by source.  Have a problem with booting which hangs after:
>>>> 
>>>>>> FreeBSD EFI boot block
>>>> Loader path: /boot/loader.efi
>>>> 
>>>> Initializing modules: ZFS UFS
>>>> Probing 5 block devices ... done
>>>> ZFS found the following pools: zroot
>>>> UFS found no partitions
>>>> Consoles: EFI console
>>>> FreeBSD/amd64 EFI loader, Revision 1.1
>>>> 
>>>>   Command line arguments: loader.efi
>>>>   EFI version 2.31
>>>>   EFI Firmware: American Megatrends (rev 4.654)
>>>>   Console: efi(0)
>>>>   Load Path: HD(4, GPT [ ... ]
>>>>   Load Device: Pci Root [ ... ]
>>>>   Boot Current: 0001
>>>>   Boot Order: 0001 [x]
>>>>   Boot Info Path: HS(1, GPT,  [ ... ]  /\EFI\BOOT\BOOTX64.EFI
>>>> -
>>>> 
>>>> So it gets into loader.efi which runs but stops I think just before
>>> loading
>>>> the kernel.  Partitions:
>>>> 
>>>> =>   40  250069600  ada0  GPT  (119G)
>>>>40   1600 1  efi  (800K)
>>>>  1640   1024 2  freebsd-boot  (512K)
>>>>  2664   1432- free -  (716K)
>>>>  40964194304 3  freebsd-swap  (2.0G)
>>>>   4198400  245870592 4  freebsd-zfs  (117G)
>>>> 250068992648- free -  (324K)
>>>> 
>>>> and the EFI partition is FAT 12.
>>>> 
>>>> I can't provide (at the moment) any output from efibootmgr:
>>>> 
>>>> root@gryphon:~ # efibootmgr -v
>>>> efibootmgr: efi variables not supported on this system. root? kldload
>>> efirt?
>>>> root@gryphon:~ # kldload efirt
>>>> kldload: can't load efirt: module already loaded or in kernel
>>>> 
>>>> which I don't understand.
>>>> 
>>>> I'm going to rebuild the kernel (currently GENERIC) and see if that
>>> allows
>>>> me to load efirt / use efibootmgr.
>>>> 
>>>> In the meantime, I should be very grateful for any advice.
>>>> 
>>>> ( Currently booting using a 11-RELEASE memstick image and dropping into
>>> its
>>>> loader to get to the installed 12-STABLE ).
>>>> 
>>>> /Harry
>>>> ___
>>>> freebsd-current@freebsd.org mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
>>> reebsd.org"
>>> 
>>> 
>> 
>> 
>> --
>> Harry Newton
>> 
>> 
>> 
> 
> 
> -- 
> Harry Newton
> ___
> 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: UEFI boot hangs after loader

[Toomas Soome]

you should have the binaries in boot - just ln (or copy) one to loader.efi

rgds,
toomas

> On 23 Oct 2018, at 23:22, Harry Newton  wrote:
> 
> Yes ... so as everything is built, can I just alter LOADER_DEFAULT_INTERP in 
> /etc/make.conf and then reinstall just the loader and boot parts onto the 
> UEFI partition ?  If so, how ?
> 
> 
> On 23 October 2018 at 21:17, Toomas Soome  <mailto:tso...@me.com>> wrote:
> ok, in that case I’d suggest to test out if forth based one is still working 
> - at least you can get the bootable system. And then there is a chance to 
> debug the lua version too (note it should be possible to chain 
> /boot/loader_lua.efi).
> 
> rgds,
> toomas
> 
> > On 23 Oct 2018, at 23:08, Harry Newton  > <mailto:h...@yewbarrow.net>> wrote:
> > 
> > So it's got FORTH in it, but my loader is lua based, and also doesn't
> > appear to read loader.rc.
> > 
> > /H
> > 
> > On 23 October 2018 at 21:03, Toomas Soome  > <mailto:tso...@me.com>> wrote:
> > 
> >> hm. in that case, whats the content of /boot/loader.rc ?
> >> 
> >> rgds,
> >> toomas
> >> 
> >> 
> >> On 23 Oct 2018, at 23:01, Harry Newton  >> <mailto:h...@yewbarrow.net>> wrote:
> >> 
> >> If boot menu is the screen where you get the options for various kernels
> >> and the picture of the daemon head, no.  It stops at the point in my email
> >> — though not as I said just before the kernel is loaded but in point of
> >> fact before the menu.
> >> 
> >> I've also rebuilt the kernel and still can't use efibootmgr which is
> >> puzzling me.
> >> 
> >> /H
> >> 
> >> 
> >> On 23 October 2018 at 20:56, Toomas Soome  >> <mailto:tso...@me.com>> wrote:
> >> 
> >>> Do you get boot menu? if so, press esc to get to ok prompt, then type
> >>> start - if its bootfort based loader, it will load the kernel and modules.
> >>> lsmod will then list the loaded files.
> >>> 
> >>> If the loader prompt is still usable, then next command would be: boot
> >>> 
> >>> rgds,
> >>> toomas
> >>> 
> >>>> On 23 Oct 2018, at 20:45, Harry Newton  >>>> <mailto:h...@yewbarrow.net>> wrote:
> >>>> 
> >>>> Just upgraded my Asus UX303L (amd64) from 11-STABLE to 12.0-BETA1
> >>> r339529
> >>>> by source.  Have a problem with booting which hangs after:
> >>>> 
> >>>>>> FreeBSD EFI boot block
> >>>> Loader path: /boot/loader.efi
> >>>> 
> >>>> Initializing modules: ZFS UFS
> >>>> Probing 5 block devices ... done
> >>>> ZFS found the following pools: zroot
> >>>> UFS found no partitions
> >>>> Consoles: EFI console
> >>>> FreeBSD/amd64 EFI loader, Revision 1.1
> >>>> 
> >>>>   Command line arguments: loader.efi
> >>>>   EFI version 2.31
> >>>>   EFI Firmware: American Megatrends (rev 4.654)
> >>>>   Console: efi(0)
> >>>>   Load Path: HD(4, GPT [ ... ]
> >>>>   Load Device: Pci Root [ ... ]
> >>>>   Boot Current: 0001
> >>>>   Boot Order: 0001 [x]
> >>>>   Boot Info Path: HS(1, GPT,  [ ... ]  /\EFI\BOOT\BOOTX64.EFI
> >>>> -
> >>>> 
> >>>> So it gets into loader.efi which runs but stops I think just before
> >>> loading
> >>>> the kernel.  Partitions:
> >>>> 
> >>>> =>   40  250069600  ada0  GPT  (119G)
> >>>>40   1600 1  efi  (800K)
> >>>>  1640   1024 2  freebsd-boot  (512K)
> >>>>  2664   1432- free -  (716K)
> >>>>  40964194304 3  freebsd-swap  (2.0G)
> >>>>   4198400  245870592 4  freebsd-zfs  (117G)
> >>>> 250068992648- free -  (324K)
> >>>> 
> >>>> and the EFI partition is FAT 12.
> >>>> 
> >>>> I can't provide (at the moment) any output from efibootmgr:
> >>>> 
> >>>> root@gryphon:~ # efibootmgr -v
> >>>> efibootmgr: efi variables not supported on this system. root? kldload
> >>> efirt?
> >>>> root@gryphon:~ # kldload efirt
> >>>> kldload: can't load efirt: module already loaded or in

Re: UEFI boot hangs after loader

[Toomas Soome]

> On 24 Oct 2018, at 00:51, Kyle Evans  wrote:
> 
> Hi,
> 
> I suspect 4th vs. lua has no impact here, given the output shown --
> can you throw one of the installer images [0] on some removable media
> and give that a shot for booting? If that works, we can explore UEFI
> variables from there.
> 


Yes, thats my guess too, my guess is that since in general the uefi boot is 
working, in this case it has to be some corner case, and I would start checking 
with boot variable related code; specifically, I’d suggest to patch 
(temporarily) the find_currdev() in efi/loader/main.c to set do_bootmgr = false 
and see if that will fix the boot. Then we can explore what is happening in 
match_boot_info() 

rgds,
toomas

> efibootmgr will only work on a successful UEFI boot, unfortunately- if
> we didn't make uefi loader -> kernel transition, then we don't have
> access to runtime services.
> 
> Thanks,
> 
> Kyle Evans
> 
> [0] https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.0/
> 
> On Tue, Oct 23, 2018 at 4:23 PM Harry Newton  wrote:
>> 
>> I set LOADER_DEFAULT_INTERP=4th and went in /usr/src/stand and re-made the
>> binaries in /boot but this doesn't solve the problem.  It did copy
>> /boot/loader_4th.efi to /boot/loader.efi which is (according to uefi(8)
>> which is what is called from /boot/boot1.efi and which contains the strings
>> I see on the console before the hang.  But it must then call / read
>> something else and I don't think it can find it.  Not sure why it doesn't
>> produce an error message.  I *think* it may be something to do with EFI
>> variables, but as efibootmgr doesn't work I can't explore this, despite
>> efirt being in the kernel.
>> 
>> Suggestions received welcomed, and new suggestions / leads to follow also
>> very much welcomed.
>> 
>> /H
>> 
>> 
>> On 23 October 2018 at 21:33, Harry Newton  wrote:
>> 
>>> Right ... I've the binaries in /boot, freshly made.  This might be a silly
>>> question ... do I not need to copy them (or dd the boot1.efifat image) to
>>> the EFI partition ?
>>> 
>>> /H
>>> 
>>> On 23 October 2018 at 21:30, Toomas Soome  wrote:
>>> 
>>>> you should have the binaries in boot - just ln (or copy) one to loader.efi
>>>> 
>>>> rgds,
>>>> toomas
>>>> 
>>>> 
>>>> On 23 Oct 2018, at 23:22, Harry Newton  wrote:
>>>> 
>>>> Yes ... so as everything is built, can I just alter LOADER_DEFAULT_INTERP
>>>> in /etc/make.conf and then reinstall just the loader and boot parts onto
>>>> the UEFI partition ?  If so, how ?
>>>> 
>>>> 
>>>> On 23 October 2018 at 21:17, Toomas Soome  wrote:
>>>> 
>>>>> ok, in that case I’d suggest to test out if forth based one is still
>>>>> working - at least you can get the bootable system. And then there is a
>>>>> chance to debug the lua version too (note it should be possible to chain
>>>>> /boot/loader_lua.efi).
>>>>> 
>>>>> rgds,
>>>>> toomas
>>>>> 
>>>>>> On 23 Oct 2018, at 23:08, Harry Newton  wrote:
>>>>>> 
>>>>>> So it's got FORTH in it, but my loader is lua based, and also doesn't
>>>>>> appear to read loader.rc.
>>>>>> 
>>>>>> /H
>>>>>> 
>>>>>> On 23 October 2018 at 21:03, Toomas Soome  wrote:
>>>>>> 
>>>>>>> hm. in that case, whats the content of /boot/loader.rc ?
>>>>>>> 
>>>>>>> rgds,
>>>>>>> toomas
>>>>>>> 
>>>>>>> 
>>>>>>> On 23 Oct 2018, at 23:01, Harry Newton  wrote:
>>>>>>> 
>>>>>>> If boot menu is the screen where you get the options for various
>>>>> kernels
>>>>>>> and the picture of the daemon head, no.  It stops at the point in my
>>>>> email
>>>>>>> — though not as I said just before the kernel is loaded but in point
>>>>> of
>>>>>>> fact before the menu.
>>>>>>> 
>>>>>>> I've also rebuilt the kernel and still can't use efibootmgr which is
>>>>>>> puzzling me.
>>>>>>> 
>>>>>>> /H
>>>>>>> 
>>>>>>> 
>>>

Re: UEFI boot hangs after loader

[Toomas Soome]

> On 24 Oct 2018, at 10:13, Harry Newton  wrote:
> 
> Booted with the installer image makes efibootmgr to work as you said:
> 
> gryphon# efibootmgr -v
> BootCurrent: 0002
> Timeout : 2 seconds 
> BootOrder : 0001, 0002 
> Boot0001* UEFI OS 
> HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/File(\EFI\BOOT\BOOTX64.EFI)
>  ada0p1:/EFI/BOOT/BOOTX64.EFI (null) 
> 
> However it (efibootmgr) hangs and doesn't return to the shell, though it is 
> interruptible with ^C.
> 
> The partition listed against Boot0001 is my efi partition.

My guess is that the loader.efi is hung by exactly the same reason - there is 
some bad (unexpected) value, also the printed out (null) hints about weirdness 
there, because we normally get (null) when NULL pointer was passed to printf(). 
So either we should debug the loader.efi or efibootmgr to identify why it is 
hung and fix the code to avoid it. 

rgds,
toomas

> 
> /H
> 
> On 23 October 2018 at 22:51, Kyle Evans  <mailto:kev...@freebsd.org>> wrote:
> Hi,
> 
> I suspect 4th vs. lua has no impact here, given the output shown --
> can you throw one of the installer images [0] on some removable media
> and give that a shot for booting? If that works, we can explore UEFI
> variables from there.
> 
> efibootmgr will only work on a successful UEFI boot, unfortunately- if
> we didn't make uefi loader -> kernel transition, then we don't have
> access to runtime services.
> 
> Thanks,
> 
> Kyle Evans
> 
> [0] https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.0/ 
> <https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.0/>
> 
> On Tue, Oct 23, 2018 at 4:23 PM Harry Newton  <mailto:h...@yewbarrow.net>> wrote:
> >
> > I set LOADER_DEFAULT_INTERP=4th and went in /usr/src/stand and re-made the
> > binaries in /boot but this doesn't solve the problem.  It did copy
> > /boot/loader_4th.efi to /boot/loader.efi which is (according to uefi(8)
> > which is what is called from /boot/boot1.efi and which contains the strings
> > I see on the console before the hang.  But it must then call / read
> > something else and I don't think it can find it.  Not sure why it doesn't
> > produce an error message.  I *think* it may be something to do with EFI
> > variables, but as efibootmgr doesn't work I can't explore this, despite
> > efirt being in the kernel.
> >
> > Suggestions received welcomed, and new suggestions / leads to follow also
> > very much welcomed.
> >
> > /H
> >
> >
> > On 23 October 2018 at 21:33, Harry Newton  > <mailto:h...@yewbarrow.net>> wrote:
> >
> > > Right ... I've the binaries in /boot, freshly made.  This might be a silly
> > > question ... do I not need to copy them (or dd the boot1.efifat image) to
> > > the EFI partition ?
> > >
> > > /H
> > >
> > > On 23 October 2018 at 21:30, Toomas Soome  > > <mailto:tso...@me.com>> wrote:
> > >
> > >> you should have the binaries in boot - just ln (or copy) one to 
> > >> loader.efi
> > >>
> > >> rgds,
> > >> toomas
> > >>
> > >>
> > >> On 23 Oct 2018, at 23:22, Harry Newton  > >> <mailto:h...@yewbarrow.net>> wrote:
> > >>
> > >> Yes ... so as everything is built, can I just alter LOADER_DEFAULT_INTERP
> > >> in /etc/make.conf and then reinstall just the loader and boot parts onto
> > >> the UEFI partition ?  If so, how ?
> > >>
> > >>
> > >> On 23 October 2018 at 21:17, Toomas Soome  > >> <mailto:tso...@me.com>> wrote:
> > >>
> > >>> ok, in that case I’d suggest to test out if forth based one is still
> > >>> working - at least you can get the bootable system. And then there is a
> > >>> chance to debug the lua version too (note it should be possible to chain
> > >>> /boot/loader_lua.efi).
> > >>>
> > >>> rgds,
> > >>> toomas
> > >>>
> > >>> > On 23 Oct 2018, at 23:08, Harry Newton  > >>> > <mailto:h...@yewbarrow.net>> wrote:
> > >>> >
> > >>> > So it's got FORTH in it, but my loader is lua based, and also doesn't
> > >>> > appear to read loader.rc.
> > >>> >
> > >>> > /H
> > >>> >
> > >>> > On 23 October 2018 at 21:03, Toomas Soome  > >>> > <mailto:tso...@me.com>&g

Re: installer loader hangs going from 20181026 to 20181101 snapshot with Supermicro virtual IPMI disks

[Toomas Soome]

Darn, I will get to it.
Thanks for reporting it,
Toomas

Sent from my iPhone

> On 2 Nov 2018, at 07:43, Yuri Pankov  wrote:
> 
> Hi,
> 
> Trying to boot latest -current snapshot (20181101) on Supermicro H8DG6
> using the IPMI virtual CD hangs after displaying the disks information,
> however booting the previous one (20181026) works.  The difference is
> that newer one displays the "BIOS drive A:", so it could be related to
> recent changes by Toomas (CC'ed).
> 
> The screenshots are:
> https://people.freebsd.org/~yuripv/sm-13-20181026.jpg
> https://people.freebsd.org/~yuripv/sm-13-20181101.jpg
> 
___
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: UEFI: How to go about updating the ESP with loader.efi during installworld

[Toomas Soome]

> On 4 Nov 2018, at 23:25, Allan Jude  wrote:
> 
> On 2018-11-04 16:20, Rebecca Cran wrote:
>> I'm currently working on creating and updating the ESP (EFI System 
>> Partition) 
>> for UEFI booting during installation and installworld. 
>> 
>> During installation, with my changes it gets mounted on /boot/efi and 
>> loader.efi 
>> copied into /boot/efi/EFI/FreeBSD and /boot/efi/EFI/BOOT. An entry gets 
>> added to 
>> /etc/fstab as noauto.
>> 
>> The issue comes during installworld, where we'll need to update the loader, 
>> and I'm not sure how we should handle that. 
>> If NO_ROOT isn't defined, do we just "mount /boot/efi", overwrite the files 
>> then 
>> unmount it? What should we do if NO_ROOT _is_ defined?
>> 
> 
> Previous to now, installworld has not updated the boot blocks. You've
> had to manually run 'gpart bootcode' to change the boot blocks.
> 
> However, those boot blocks mostly just loaded /boot/loader, which was
> updated by installworld.
> 
> So I can see how this is not directly analogous.
> 
> I wouldn't depend on the /etc/fstab entry existing. I am not sure I want
> installworld randomly fobbing around in my EFI partition. Especially if,
> for example, my EFI/BOOT is not FreeBSD, but rEFInd or something.
> 

I  would not add fstab entry at all. First of all, what should I have there for 
my 3+1 raidz1?;) 

it is reasonable to have efi/freebsd directory, the efi/boot/bootx64.efi is 
hard one of course. But then again, it is problem only when we can not setup 
EFI bootmanager variables — the bootx64.efi is default when bootmgr is not set 
up.

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: UEFI GOP: screen goes blank during boot after loader is finished

[Toomas Soome]

> On 17 Nov 2018, at 18:29, Subbsd  wrote:
> 
> On Fri, Nov 16, 2018 at 8:03 AM Warner Losh  > wrote:
>> 
>> 
>> 
>> On Thu, Nov 15, 2018 at 12:10 PM Rebecca Cran  wrote:
>>> 
>>> On Wednesday, 14 November 2018 19:56:56 MST Warner Losh wrote:
>>> 
 What is the ConOut evifar look like? We set serial when the UEFI env says
 to do  so.
>>> 
>>> Booting with:
>>> 
>>> sudo bhyve -A -P -c 2 -H -m 4G -s 0:0,hostbridge -s 31:0,lpc -s 2,ahci-
>>> cd,FreeBSD-12.0-BETA4-amd64-disc1.iso -s
>>> 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait -l bootrom,/usr/local/share/uefi-
>>> firmware/BHYVE_UEFI.fd -u vm5
>>> 
>>> dh in the shell shows:
>>> 
>>> 7D: ConsoleOut SimpleTextOut GraphicsOutput(GraphicsOutput)
>>> PCIIO DevicePath(PciRoot (0x0)/Pci(0x1D,0x0))
>>> 
>>> 84: StdErr ConsoleOut ConsoleIn SimpleTextOut SimpleTextInEx SimpleTextIn
>>> DevicePath(t(115200,8,N,1)/VenVt100Plus())
>>> 
>>> 89: SimpleTextOut SimpleTextInEx SimpleTextIn DevicePath(Uart(115200,8,N,1)/
>>> VenPcAnsi())
>> 
>> 
>> If I read that right, then the ConOut variable first has the video device 
>> listed, then the serial port (this wasn't the form I expected to see it in, 
>> so I'm not sure thats the case). In either event, we should get console 
>> output on both the serial and the video at least until the /etc/rc script 
>> starts...
>> 
>> Warner
> 
> Perhaps this is not a special case of FreeBSD guest, since the latest
> versions of FreeBSD are loaded normally in other UEFI systems (e.g
> Virtualbox, KVM). For example someone from CBSD Telegram chat reported
> a similar problem for OpenIndiana 2018 ( which uses FreeBSD loader
> however) in bhyve.
> Thus, perhaps the root of this problem should be sought in
> uefi-edk2-bhyve the package. Latest CBSD release (12.0.1) fixed this
> problem by disabling serial console. However, CBSD uses an alternative
> boot method  for bhyve ( uefi-edk2-bhyve + reFIND )
> ___

You can not yet bring in OpenIndiana into the game because it does not have FB 
console support - it *only* can use serial console with UEFI. 

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: Fujitsu Lifebook E751 (iGPU: HM65): distorted console with UEFI boot

[Toomas Soome]

Note about hw.vga.textmode: this tunable has no meaning for UEFI - first of 
all, there is no API to change to VGA text mode in UEFI, secondly, there may or 
may not be VGA (firmware) at all. We only do land in kernel with linear 
framebuffer mode active and all we have is information about that mode (FB 
address, size and color bits). In *worst* case, it is actually even possible 
that we only have UEFI API for boot loader and no linear framebuffer for kernel.

distorted console after kernel start means that either the kernel efifb driver 
does something wrong, or the console device gfx mode change did happen but the 
FB driver was not properly informed about the fact.

rgds,
toomas


> On 28 Nov 2018, at 11:51, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> I ran into some trouble booting off a Fujitsu Lifebook E751 (firmware is 
> latest, r1.22
> from 2013). The E751 is of model series S26391-K326-V100 and equipted with a 
> Core
> i5-2520M CPU and supposed to be also equipted with a iGPU HM65 according to 
> the
> techniscal specifications from Fujitsu.
> 
> Trying to boot off 12-PRERELEASE/12-RC2 and/or 13-CURRENT (most recent I 
> could grap from
> the download page), the screen becomes distorted immediately after the kernel 
> has
> loaded and initialised/booted. The screen is at the loader's all right so far.
> 
> Trying to disable graphics mode via escaping to the loader's prompt and 
> setting 
> 
> set hw.vga.textmode=1
> 
> subsequently loading the kernel and then booting, doesn't help. The screen is 
> distorted
> again. The notebook seems UEFI only and doesn't boot off from MBR partioned 
> devices (i.e.
> NanoBSD I used to use).
> 
> Loading /boot/kernel/i915kms.ko
> 
> after manually having loaded /boot/kernel/kernel (and not booted yet) doesn't 
> change
> anything either.
> 
> Booting off and installing Linux (Ubuntu, Mint so far, most revent verions I 
> can get my
> hands on) is no problem. The console works fine from the beginning and so the 
> graphics.
> 
> Is there a chance to get a FreeBSD booting the easy way? 
> 
> The provided boot images do not contain any of the 
> graphics/drm-stable|next|legacy-kmod
> stuff, I tried to load i915kms.ko off from /boot/modules/ (were those modules 
> from the
> ports are supposed to reside) but no chance.
> 
> Before starting investigating this issue further I'd like to ask wether there 
> is a
> general support provided or is that type of notebook dead matter for FreeBSD 
> of the
> modern kind?
> 
> Thanks in advance,
> 
> oh
> 
> p.s. please CC me, I'm not subscribing all lists.
> 
> - -- 
> O. Hartmann
> -BEGIN PGP SIGNATURE-
> 
> iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW/5lKgAKCRDS528fyFhY
> lMhRAf4yv4MqmHYVZIKo+TE1VACuHpXSv8ad4JzVKMG/S9uGcLLDfLgSM9699FDP
> /QhIMCCHJ1hGAtXACdwGCsyZ5LmiAf93JHFU0W+GJWdXJI+sRcWvEZrzQlb5Czhf
> vaM5QZ+3n0ermbe5/Ibvo/yzhL5YyonG7/lEqvnf7GAA+snv+Dvg
> =XD7b
> -END PGP SIGNATURE-
> ___
> 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 loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Toomas Soome]

I just did push biosdisk updates to stable/12, I wonder if you could test those 
bits…

rgds,
toomas

> On 29 Nov 2018, at 17:01, Mark Martinec  wrote:
> 
> After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 (amd64,
> zfs, bios), I tried my luck with one of our production hosts, and ended up
> with a stuck loader after rebooting with a new kernel (after the first
> stage of upgrade).
> 
> These were the steps, and all went smoothly and normally until a reboot:
> 
>  freebsd-update upgrade -r 12.0-RC2
>  freebsd-update install
>  shutdown -r now
> 
> While booting, the 'BTX loader' comes up, lists the BIOS drives,
> then the spinner below the list comes up and begins turning,
> stuttering, and after a couple of seconds it grinds to a standstill
> and nothing happens afterwards.
> 
> At this point the ZFS and the bootstrap loader is supposed to
> come up, but it doesn't.
> 
> This host has too zfs pools, the system pool consists of two SSDs
> in a zfs mirror (also holding a freebsd-boot partition each), the
> other pool is a raidz2 with six JBOD disks on an LSI controller.
> The gptzfsboot in both freebsd-boot partitions is fresh from 11.2,
> both zpool versions are up-to-date with 11.2. The 'zpool status -v'
> is happy with both pools.
> 
> After rebooting from an USB drive and reverting the /boot directory
> to a previous version, the machine comes up normally again
> with the 11.2-RELEASE-p4.
> 
> I found a file init.core in the / directory, slightly predating the
> last reboot with a salvaged system - although it was probably not
> a cause of the problem, but a consequence of the rescue operation.
> 
> It is unfortunate that this is a production host, so I can't play
> much with it. One or two more quick experiments I can probably
> afford, but not much more. Should I just first wait for the
> official 12.0 release? Should I try booting with a 12.0 on USB
> and try to import pools? Suggestions welcome.
> 
> 
> 
> Now that the /boot has been manually restored to the 11.2 state,
> A SECOND QUESTION is about freebsd-update, which still thinks we are
> in the middle of an upgrade procedure. Trying now to just update
> the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains:
> 
>  # uname -a
>  FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4
>  #
>  # freebsd-version
>  11.2-RELEASE-p4
>  #
>  # freebsd-update fetch
>  src component not installed, skipped
>  You have a partially completed upgrade pending
>  Run '/usr/sbin/freebsd-update install' first.
>  Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway.
> 
> So what is the right way to get rid of all traces of the
> unsuccessful upgrade, and let freebsd-update believe we are cleanly
> at 11.2-p4 ?  Removing /var/db/freebsd-update did not help.
> 
>  Mark
> ___
> 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: WITH_CTF breaks CD loader: "File too big"

[Toomas Soome]

> On 2 Dec 2018, at 17:08, Yuri Pankov  wrote:
> 
> Hi,
> 
> Building disc1.iso using `make release` and having WITH_CTF set in
> src.conf leads to "File too big" displayed when booting the image.
> 
> Would it make sense to build loader and related parts without CTF
> unconditionally as it doesn't look useful there?
> 

+1

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: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Toomas Soome]

> On 2 Dec 2018, at 01:11, Mark Martinec  wrote:
> 
> 2018-11-29 18:43, Toomas Soome wrote:
>> I just did push biosdisk updates to stable/12, I wonder if you could
>> test those bits…
> 
> Thank you!  I haven't tried it yet, but I wonder whether this fix was
> already incorporated into 12.0-RC3, which would make my rescue easier.
> 
> Otherwise I can build a stable/12 on another host and transplant
> the problematic file(s) to the affected host - if I knew which files
> to copy.
> 
> I wonder also, if the today's posting by cksalexan...@q.com on the
> freebsd-stable ML titled "FreeBSD-12.0-RC3-i386-disc1.iso does not boot"
> could be describing the same problem?
> 
>  Mark
> 

The files are /boot/loader* binaries - to be exact, check which one is linked 
to /boot/loader. I can provide binaries if needed.

Can not tell about post in freebsd-stable - it simply does not provide enough 
information.

rgds,
toomas


> 
>>> On 29 Nov 2018, at 17:01, Mark Martinec  
>>> wrote:
>>> After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 (amd64,
>>> zfs, bios), I tried my luck with one of our production hosts, and ended up
>>> with a stuck loader after rebooting with a new kernel (after the first
>>> stage of upgrade).
>>> These were the steps, and all went smoothly and normally until a reboot:
>>> freebsd-update upgrade -r 12.0-RC2
>>> freebsd-update install
>>> shutdown -r now
>>> While booting, the 'BTX loader' comes up, lists the BIOS drives,
>>> then the spinner below the list comes up and begins turning,
>>> stuttering, and after a couple of seconds it grinds to a standstill
>>> and nothing happens afterwards.
>>> At this point the ZFS and the bootstrap loader is supposed to
>>> come up, but it doesn't.
>>> This host has too zfs pools, the system pool consists of two SSDs
>>> in a zfs mirror (also holding a freebsd-boot partition each), the
>>> other pool is a raidz2 with six JBOD disks on an LSI controller.
>>> The gptzfsboot in both freebsd-boot partitions is fresh from 11.2,
>>> both zpool versions are up-to-date with 11.2. The 'zpool status -v'
>>> is happy with both pools.
>>> After rebooting from an USB drive and reverting the /boot directory
>>> to a previous version, the machine comes up normally again
>>> with the 11.2-RELEASE-p4.
>>> I found a file init.core in the / directory, slightly predating the
>>> last reboot with a salvaged system - although it was probably not
>>> a cause of the problem, but a consequence of the rescue operation.
>>> It is unfortunate that this is a production host, so I can't play
>>> much with it. One or two more quick experiments I can probably
>>> afford, but not much more. Should I just first wait for the
>>> official 12.0 release? Should I try booting with a 12.0 on USB
>>> and try to import pools? Suggestions welcome.
>>> Now that the /boot has been manually restored to the 11.2 state,
>>> A SECOND QUESTION is about freebsd-update, which still thinks we are
>>> in the middle of an upgrade procedure. Trying now to just update
>>> the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains:
>>> # uname -a
>>> FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4
>>> #
>>> # freebsd-version
>>> 11.2-RELEASE-p4
>>> #
>>> # freebsd-update fetch
>>> src component not installed, skipped
>>> You have a partially completed upgrade pending
>>> Run '/usr/sbin/freebsd-update install' first.
>>> Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway.
>>> So what is the right way to get rid of all traces of the
>>> unsuccessful upgrade, and let freebsd-update believe we are cleanly
>>> at 11.2-p4 ?  Removing /var/db/freebsd-update did not help.
>>> Mark
> ___
> 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 loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Toomas Soome]

> On 4 Dec 2018, at 19:59, Mark Martinec  wrote:
> 
>>> 2018-11-29 18:43, Toomas Soome wrote:
>>>> I just did push biosdisk updates to stable/12, I wonder if you could
>>>> test those bits…
> 
> Myself wrote:
>>> Thank you!  I haven't tried it yet, but I wonder whether this fix was
>>> already incorporated into 12.0-RC3, which would make my rescue easier.
>>> Otherwise I can build a stable/12 on another host and transplant
>>> the problematic file(s) to the affected host - if I knew which files
>>> to copy.
> 
> 2018-12-02 18:59, Toomas wrote:
>> The files are /boot/loader* binaries - to be exact, check which one is
>> linked to /boot/loader. I can provide binaries if needed.
>> [...]
>> rgds,
>> toomas
> 
> I got a maintenance window today so I tried with the new loader,
> and it did not help.
> 
> More specifically:
> 
> As it comes with 12-RC2, the /boot/loader was hard linked with loader_lua.
> Its size is 421888 bytes. So I concentrated on this loader.
> 
> I build a fresh stable/12 on another host, and copied the newly
> built loader_lua (425984 bytes) to the /boot directory of the affected
> host, deleted the file 'loader', and hard-linked loader_lua to loader.
> 
> The situation has not changed: the BTX loader lists all BIOS drives
> C..J (disk0..disk7), then a spinner starts and gets stuck forever.
> It never reaches the 'BIOS 635kB/3537856kB available memory' line.
> 
> While trying to restore the old /boot from 11.2, I tried booting
> a live image from a 12.0-RC3 memory stick - and the loader got
> stuck again, same as when booting from a disk.
> 
> So I had to boot from an 11.2 memstick to be able to regain control.
> 
>  Mark
> 
> 

ok, if you could perform 2 tests:

1. from loader prompt enter 0x413 0xa000 - @w . cr

2. on first spinner, press space and type on boot: prompt: /boot/loader_4th and 
see if that will do better
thanks,
toomas


> 
>>>>> On 29 Nov 2018, at 17:01, Mark Martinec  
>>>>> wrote:
>>>>> After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 (amd64,
>>>>> zfs, bios), I tried my luck with one of our production hosts, and ended up
>>>>> with a stuck loader after rebooting with a new kernel (after the first
>>>>> stage of upgrade).
>>>>> These were the steps, and all went smoothly and normally until a reboot:
>>>>> freebsd-update upgrade -r 12.0-RC2
>>>>> freebsd-update install
>>>>> shutdown -r now
>>>>> While booting, the 'BTX loader' comes up, lists the BIOS drives,
>>>>> then the spinner below the list comes up and begins turning,
>>>>> stuttering, and after a couple of seconds it grinds to a standstill
>>>>> and nothing happens afterwards.
>>>>> At this point the ZFS and the bootstrap loader is supposed to
>>>>> come up, but it doesn't.
>>>>> This host has too zfs pools, the system pool consists of two SSDs
>>>>> in a zfs mirror (also holding a freebsd-boot partition each), the
>>>>> other pool is a raidz2 with six JBOD disks on an LSI controller.
>>>>> The gptzfsboot in both freebsd-boot partitions is fresh from 11.2,
>>>>> both zpool versions are up-to-date with 11.2. The 'zpool status -v'
>>>>> is happy with both pools.
>>>>> After rebooting from an USB drive and reverting the /boot directory
>>>>> to a previous version, the machine comes up normally again
>>>>> with the 11.2-RELEASE-p4.
>>>>> I found a file init.core in the / directory, slightly predating the
>>>>> last reboot with a salvaged system - although it was probably not
>>>>> a cause of the problem, but a consequence of the rescue operation.
>>>>> It is unfortunate that this is a production host, so I can't play
>>>>> much with it. One or two more quick experiments I can probably
>>>>> afford, but not much more. Should I just first wait for the
>>>>> official 12.0 release? Should I try booting with a 12.0 on USB
>>>>> and try to import pools? Suggestions welcome.
>>>>> Now that the /boot has been manually restored to the 11.2 state,
>>>>> A SECOND QUESTION is about freebsd-update, which still thinks we are
>>>>> in the middle of an upgrade procedure. Trying now to just update
>>>>> the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains:
>>>>> # uname -a
>>>>> FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4
>>>>> #
>>>>> # freebsd-version
>>>>> 11.2-RELEASE-p4
>>>>> #
>>>>> # freebsd-update fetch
>>>>> src component not installed, skipped
>>>>> You have a partially completed upgrade pending
>>>>> Run '/usr/sbin/freebsd-update install' first.
>>>>> Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway.
>>>>> So what is the right way to get rid of all traces of the
>>>>> unsuccessful upgrade, and let freebsd-update believe we are cleanly
>>>>> at 11.2-p4 ?  Removing /var/db/freebsd-update did not help.
>>>>> Mark

___
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 loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Toomas Soome]

Yes, that must be true but it does not hurt to get checked.

And of course, lsdev -v from 11.x loader would be good too.

Anyhow, I am afraid we have reached to point where more specific debug info is 
needed (printed out), with lack of output about disks at all, it must be 
related to floppy device checks.

Rgds,
Toomas

Sent from my iPhone

> On 4 Dec 2018, at 22:19, Ian Lepore  wrote:
> 
> On Tue, 2018-12-04 at 21:51 +0200, Toomas Soome via freebsd-stable
> wrote:
>> 
>>> 
>>> On 4 Dec 2018, at 19:59, Mark Martinec >> i> wrote:
>>> 
>>>> 
>>>>> 
>>>>> 2018-11-29 18:43, Toomas Soome wrote:
>>>>>> 
>>>>>> I just did push biosdisk updates to stable/12, I wonder if
>>>>>> you could
>>>>>> test those bits…
>>> Myself wrote:
>>>> 
>>>>> 
>>>>> Thank you!  I haven't tried it yet, but I wonder whether this
>>>>> fix was
>>>>> already incorporated into 12.0-RC3, which would make my rescue
>>>>> easier.
>>>>> Otherwise I can build a stable/12 on another host and
>>>>> transplant
>>>>> the problematic file(s) to the affected host - if I knew which
>>>>> files
>>>>> to copy.
>>> 2018-12-02 18:59, Toomas wrote:
>>>> 
>>>> The files are /boot/loader* binaries - to be exact, check which
>>>> one is
>>>> linked to /boot/loader. I can provide binaries if needed.
>>>> [...]
>>>> rgds,
>>>> toomas
>>> I got a maintenance window today so I tried with the new loader,
>>> and it did not help.
>>> 
>>> More specifically:
>>> 
>>> As it comes with 12-RC2, the /boot/loader was hard linked with
>>> loader_lua.
>>> Its size is 421888 bytes. So I concentrated on this loader.
>>> 
>>> I build a fresh stable/12 on another host, and copied the newly
>>> built loader_lua (425984 bytes) to the /boot directory of the
>>> affected
>>> host, deleted the file 'loader', and hard-linked loader_lua to
>>> loader.
>>> 
>>> The situation has not changed: the BTX loader lists all BIOS drives
>>> C..J (disk0..disk7), then a spinner starts and gets stuck forever.
>>> It never reaches the 'BIOS 635kB/3537856kB available memory' line.
>>> 
>>> While trying to restore the old /boot from 11.2, I tried booting
>>> a live image from a 12.0-RC3 memory stick - and the loader got
>>> stuck again, same as when booting from a disk.
>>> 
>>> So I had to boot from an 11.2 memstick to be able to regain
>>> control.
>>> 
>>>  Mark
>>> 
>>> 
>> ok, if you could perform 2 tests:
>> 
>> 1. from loader prompt enter 0x413 0xa000 - @w . cr
>> 
>> 2. on first spinner, press space and type on boot: prompt:
>> /boot/loader_4th and see if that will do better
>> thanks,
>> toomas
>> 
> 
> I don't think that will be an option.  If it hasn't gotten to the point
> of saying how much BIOS available memory there is, it's only halfway
> through loader main() and has hung before getting to interact().
> 
> In fact, if that line hasn't printed, but some disk drives have been
> listed, it pretty much has to be hung in the "March through the device
> switch probing for things" loop. If all the disks are listed, then it
> got through that entry in the devsw, and is likely hanging in the
> dv_init calls for either the pxedisk or zfsdev devices.
> 
> -- Ian
> 
>> 
>>> 
>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> On 29 Nov 2018, at 17:01, Mark Martinec >>>>>> b...@ijs.si> wrote:
>>>>>>> After successfully upgraded three hosts from 11.2-p4 to
>>>>>>> 12.0-RC2 (amd64,
>>>>>>> zfs, bios), I tried my luck with one of our production
>>>>>>> hosts, and ended up
>>>>>>> with a stuck loader after rebooting with a new kernel
>>>>>>> (after the first
>>>>>>> stage of upgrade).
>>>>>>> These were the steps, and all went smoothly and normally
>>>>>>> until a reboot:
>>>>>>> freebsd-update upgrade -r 12.0-RC2
>>>>>>> freebsd-update install
>>>>>>> shutdown -r now
>>>>>>>

Re: UEFI, loader.efi and /boot.config

[Toomas Soome]

The loader.efi (EFI application) can receive command line arguments, set up in 
UEFI boot manager.

rgds,
toomas

> On 18 Jan 2019, at 16:14, Kurt Jaeger  wrote:
> 
> Hello,
> 
>> I was wondering if people will expect /boot.config to still be read and so 
>> code should be added to loader to continue to parse it, or if loader.conf 
>> can be considered the correct place and boot.config forgotten about?
> 
> If the early boot messages are not displayed as Olivier mentioned,
> that would be fatal. On some systems no other output besides serial
> is useful.
> 
> -- 
> p...@opsec.eu+49 171 3101372One year to go !
> ___
> 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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

[Toomas Soome]

> On 18 Jan 2019, at 19:57, Lev Serebryakov  wrote:
> 
> On 18.01.2019 20:13, Warner Losh wrote:
> 
>>> Also, there are same problems with GPT/BIOS setup (which uses GPT but
>>> legacy boot) :-(
>>> 
>> 
>> What same problems? I don't think we've touched how gptboot has handed off
>> to /boot/loader in a long, long time. It there's an issue here, it's a
>> different issue.
> Ok, strictly speaking it is different issue with same "high-level"
> description: pmbr/gptboot has less features than simplest oldest boot0.
> 
> pmbr/gptbood doesn't have any way to select partition to boot from, as
> "boot0" has. No, setting "nextboot" from live system is not a solution.
> I speak about NanoBSD situation when there is tow partitions, both
> bootable, one marked as "active" ("bootme" on GPT parlance) but it is
> completely broken and user need to boot from other one form very
> beginning. This task is trivially solved by "boot0" in pure-MBR case.
> What about GPT/Legacy and GPT/UEFI?
> 
> -- 
> // Lev Serebryakov
> 

errm.. you press a key and enter device and or loader path. if it is not 
working - the code is there to be fixed. GPT does not have the concept of 
active partition.

My suggestion would be to walk all those boot programs and document them, then 
see what features are possible to bring to sync.

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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

[Toomas Soome]

> On 18 Jan 2019, at 21:33, Rodney W. Grimes 
>  wrote:
> 
>> 
>> 
>>> On 18 Jan 2019, at 19:57, Lev Serebryakov  wrote:
>>> 
>>> On 18.01.2019 20:13, Warner Losh wrote:
>>> 
> Also, there are same problems with GPT/BIOS setup (which uses GPT but
> legacy boot) :-(
> 
 
 What same problems? I don't think we've touched how gptboot has handed off
 to /boot/loader in a long, long time. It there's an issue here, it's a
 different issue.
>>> Ok, strictly speaking it is different issue with same "high-level"
>>> description: pmbr/gptboot has less features than simplest oldest boot0.
>>> 
>>> pmbr/gptbood doesn't have any way to select partition to boot from, as
>>> "boot0" has. No, setting "nextboot" from live system is not a solution.
>>> I speak about NanoBSD situation when there is tow partitions, both
>>> bootable, one marked as "active" ("bootme" on GPT parlance) but it is
>>> completely broken and user need to boot from other one form very
>>> beginning. This task is trivially solved by "boot0" in pure-MBR case.
>>> What about GPT/Legacy and GPT/UEFI?
>>> 
>>> -- 
>>> // Lev Serebryakov
>>> 
>> 
>> errm.. you press a key and enter device and or loader path. if it is not 
>> working - the code is there to be fixed.
>> GPT does not have the concept of active partition.
> 
> It certainly does, it is called the attribute bootme,
> and the above correctly states that.
> 

Shall you give the reference to specification?:) 

I am very well aware about the “vendor” attributes, and I guess You can make a 
difference about vendor extensions and specification…  

And regarding to GPT attributes, I personally would avoid writing partition 
table from the boot loader…

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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

[Toomas Soome]

> On 19 Jan 2019, at 11:52, Lev Serebryakov  wrote:
> 
> Hello Warner,
> 
> Saturday, January 19, 2019, 12:17:29 AM, you wrote:
> 
>> Also most UEFI BIOSes I've used (which isn't a lot) allow one to choose
>> which Boot variable to use to boot. Some will even create new Boot
>> variables that they use when you choose a raw device to boot from.
> I have never seen such item in BIOS Setup. I've checked two MoBos now (one is
> Supermicro X9something and other is brand-new Goldmont-based Chinese MiniPC
> like Intel NUK): both have one knob in setup about boot type
> (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not Chinese
> one) could be booted to "UEFI Console" which is not documented anywhere.
> 
> Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could
> not find or understand anything in this home-rown UI with crazy-fast mouse.
> 
> I have never seen documentation in MoBo manuals about such features, BTW.
> 
> And, again, GPT/Legacy still left behind, and it could be very useful for
> small systems, as sometimes 4 partitions of MBR is not enough (2 code
> partitions + 1 config partition + 1 persistent data partition, and
> SOMETIMES, there is place for swap, for example, but MBR is full already).
> 

you can always create BSD label inside MBR slice. Also you can add 
chain_disk=devicename:  into loader.conf and get same one key selection in boot 
menu (or Boot Enviroments for that matter). There is no need to struggle with 
446 byte asm code when you have full power from your boot loader.

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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

[Toomas Soome]

> On 21 Jan 2019, at 14:15, Lev Serebryakov  wrote:
> 
> On 20.01.2019 20:05, Warner Losh wrote:
> 
>> Is too complicated? Boot1.efi doesn't allow that, but loader.efi does.
> loader.efi lives on ESP partition, do I understand it right? So, it
> could not be damaged with "bad" upgrade?
> 
> -- 
> // Lev Serebryakov
> 

It could, unless the backup is created. 

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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

[Toomas Soome]

> On 21 Jan 2019, at 14:45, Lev Serebryakov  wrote:
> 
> On 21.01.2019 15:39, Toomas Soome wrote:
> 
>>>> Is too complicated? Boot1.efi doesn't allow that, but loader.efi does.
>>> loader.efi lives on ESP partition, do I understand it right? So, it
>>> could not be damaged with "bad" upgrade?
>> 
>> It could, unless the backup is created. 
> Does it live on code (root) FS or ESP? I understand, that when you
> upgrade ESP partition, you could ruin it, but typically root FS is
> upgraded much more often than ESP/boot0/boot1 parts.
> 
> -- 
> // Lev Serebryakov
> 

If you are using boot1.efi, the loader.efi is in OS /boot/loader.efi annd 
boot1.efi is stored to ESP and will execute loader.efi as bios boot2 programs 
do.

As UEFI does not *replace* the program which did call StartImage() but both do 
stay in memory (so you have both boot1.efi and loader.efi in memory), and 
boot1.efi does not add any significant features, we will drop boot1.efi (it is 
already dropped in illumos btw), and will only use loader.efi - and in this 
case, the loader.efi is installed to ESP and will only start the kernel.

This also does mean that in ideal world, the update should create backup of 
boot program in ESP (this actually also does apply to boot1.efi), but the 
default ESP created by FreeBSD used to be too small for that.

With normal systems it should not be an issue because you can always boot from 
usb stick/cd (image), but with embedded systems it may be significant issue. 
But then again, if you are using stock (generic) OS on embedded system, you are 
already doing it wrong and will get into the trouble sooner or later:)

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: ZFS: can't read MOS of zpool...

[Toomas Soome]

When did you update the bootblocks last time?

You can grab iso/usb image with current and check if loader there can see your 
pools - and if yes, update the boot blocks on disk…

rgds,
toomas

> On 9 Apr 2019, at 20:37, Alexandre C. Guimarães  wrote:
> 
> Hello,
> 
> I can't say the precise point this started but I am convinced that was
> right after running `zpool upgrade` after upgrading to 12-RELEASE:
> 
> ---
> ZFS: i/o error - all block copies unavailable
> ZFS: can't read MOS of pool zdata
> ---
> 
> So, I got another disk to substitute that one, and now I have the same
> message two times. :-(
> 
> https://ibb.co/G0sfv3p
> 
> I suppose that would be very unfortunate to have the same problem in two
> completely unrelated disks at the same time; however, that error don't
> occurs with the SSD.
> 
> Both disks pools were created raw, however I've tried to do using GPT, MBR,
> and I got the same error messages.
> 
> ---
> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
> ada0:  ACS-2 ATA SATA 3.x device
> ada0: Serial Number 1838DB806764
> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
> ada0: Command Queueing enabled
> ada0: 114480MB (234455040 512 byte sectors)
> ada1 at ahcich1 bus 0 scbus1 target 0 lun 0
> ada1:  ATA8-ACS SATA 2.x device
> ada1: Serial Number S22KJ56S906708
> ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
> ada1: Command Queueing enabled
> ada1: 305245MB (625142448 512 byte sectors)
> ada2 at ahcich2 bus 0 scbus2 target 0 lun 0
> ada2:  ATA8-ACS SATA 2.x device
> ada2: Serial Number TNS519GY1G75LG
> ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
> ada2: Command Queueing enabled
> ada2: 476940MB (976773168 512 byte sectors)
> ---
> 
> What more information would be useful? :-)
> 
> Thank you! :-)
> 
> -- 
> Best Regards,
> Alexandre C. Guimarães.
> https://bitbucket.org/rigoletto-freebsd/

___
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: Question about 'gptzfsboot'

[Toomas Soome]

> On 26 Apr 2019, at 14:31, Thomas Laus  wrote:
> 
> List:
> 
> I have been having gptzfsboot issues with my two laptops since 12.0 was
> still CURRENT.  I receive 'error 1' on the first boot most days.
> 
> gptzfsboot: error 1 LBA 18446744072709551608
> gptzfsboot: error 1 LBA 1
> gptzfsboot: No ZFS pools located, can't boot
> 
> Most of the time the boot process is successful on my next attempt.
> This happens on two different laptops (different manufacturer).
> Different hard drives (one mechanical, the other SSD).  Both laptops are
> running 13.0-CURRENT FreeBSD 13.0-CURRENT r346544 GENERIC-NODEBUG.  All
> of my desktop computers are running the same version of FreeBSD and
> never exhibit this issue.  Is there something unique to a laptop reading
> the boot record and looking for a GELI encrypted partition that a
> desktop does not?
> 


The key is about LBA in first message. Make sure you have latest boot code 
installed with gpart.

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: Question about 'gptzfsboot'

[Toomas Soome]

> On 26 Apr 2019, at 16:20, Thomas Laus  wrote:
> 
> Toomas Soome [tso...@me.com] wrote:
>> 
>> The key is about LBA in first message. Make sure you have latest
>> boot code installed with gpart.
>> 
> I always update the bootcode with gpart each time when updating my system.
> 

Oh right, this from gptzfsboot… ok, I guess I should do something I have been 
planning all along… Do you need some sort of quick workaround?

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: Question about 'gptzfsboot'

[Toomas Soome]

> On 29 Apr 2019, at 21:47, Thomas Laus  wrote:
> 
> On 2019-04-29 14:27, Thomas Laus wrote:
>> It was more than a broken console.  All of the other 2 computers that I
>> upgraded to r346885 were essentially 'dead'.  I could not even remotely
>> login to them via ssh.  All of them required a hard power button reset
>> to get into single user mode to let me comment out the rc.conf line that
>> loads the DRM driver.  The computer could successfully boot without DRM
>> activation but would go to a black console screen again with 'startx'.
>> This also required a hard power button shutdown.  I rolled back to
>> r346544 and everything worked again like before.
>> 
>> My disastrous update to r346885 included installing a new gptzfsboot and
>> pmbr in the drive boot record.  I did not try booting an older kernel
>> using the new gptzfsboot.  I was concerned about the lack of ssh login
>> when the computers lost their console, so I just rolled back my system
>> to the last snapshot made a week ago.
>> 
> Ian:
> 
> I re-activated the r346885 BEADM snapshot and booted from my
> 'kernel.old' from r346544 and everything came up OK including 'X'.
> 
> I don't know what that means.  It might be that I have a DRM issue
> instead of a gptzfsboot problem?  Everything except for the kernel is
> now running CURRENT r346885.  I am not using the updated
> drm-current-kmod because I am using the r346544 kernel.old.
> 

It means you have different issues - one is about gptzfsboot causing boot 
problems and apparently it got fixed when you did update the bootcode (the boot 
partition is global). But also you got bitten by DRM update, and since you had 
old BE around, you were able to load old kernel.

Now the question is, is that gptzfsboot issue really fixed or is it just the 
“warm boot” fix you were seeing earlier too.

rgds,
toomas


> Tom
> 
> 
> -- 
> Public Keys:
> PGP KeyID = 0x5F22FDC1
> GnuPG KeyID = 0x620836CF
> ___
> 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: Got the same error from gptzfsboot this morning

[Toomas Soome]

> On 4 May 2019, at 21:34, Warner Losh  wrote:
> 
> On Thu, May 2, 2019 at 9:12 AM Thomas Laus  wrote:
> 
>> Toomas:
>> 
>> My laptop has been booting up flawlessly since I installed the
>> gptzfsboot file that you sent.  It also successfully rebooted from a
>> cold start this morning but I received the same error message just a few
>> minutes ago when powering up again.
>> 
>> gptzfsboot: error 1 LBA 18446744072709551608
>> gptzfsboot: error 1 LBA 1
>> gptzfsboot: No ZFS pools located, can't boot
>> 
>> On my third retry, I was successful.  This is the same LBA and error
>> number that I was getting previously.
>> 
> 
> We need to add a disk the error came from indication to that error message.
> 

and better indication where we did fail. But for this error we already did find 
the source - the geli_taste() goes to negative value with off_t, and then the 
value is used to read from disk (as unsigned value), hence we will see the 
error with really huge LBA. So we need to figure out why this happens and how 
to failsafe this all.

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: Triveal bootloader patch for FreeBSD 11.2 regression

[Toomas Soome]

> On 5 May 2019, at 04:44, John Wehle  wrote:
> 
>  Bug 236585 - BTX Halted upgrading FreeBSD 11.2 UFS from r344213 to r345199
> 
> has a triveal patch which may also apply to:
> 
>  Bug 215459 - Installing card reader causes bootloader to fail with BTX Halted
> 
>  Bug 235509 - BTX Freezes during boot on Supermicro H8DGi-F after update to 
> 12.0
> 
> Any chance of the patch being reviewed in time for the FreeBSD 11.3 release?
> 

Hm, I like that check. BTW, have you checked if current image still does crash 
on your hw?

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: UEFI boot broken in 13?

[Toomas Soome]

> On 4 Jun 2019, at 04:38, Johannes Lundberg  wrote:
> 
> Hi
> 
> I'm using poudriere-image to create usb memstick images. The images are
> identical except OS version. They are tested on a laptop with 13-CURRENT
> installed as only OS, having UEFI boot and root on zfs.
> 
> 12-STABLE memstick boots fine with in UEFI mode.
> 
> With 13-CURRENT memstick it boots the installed FreeBSD from the SSD
> instead (I choose USB UEFI OS in boot menu but it silently boots from
> the SSD instead). If I switch to legacy boot, the memstick image boots fine.
> 
> Any ideas?
> 
> /Johannes
> 

If your system does provide UEFI shell, start it and try to start boot loader 
from memstick manually to get the messages. And make sure you have latest.

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: PCengines APU2C4, 12-STABLE: bootloader failure: Panic: free: guard2 fail @ 0x1000 + 2311663946 from

[Toomas Soome]

> On 24 Jul 2019, at 11:11, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hallo,
> 
> on APU2C4 from PCengines with latest firmware apu2_v4.9.0.7.rom, SeaBIOS
> rel-1.12.1.3-0-g300e8b7, booting via legacy MBR FreeBSD 12-STABLE r350274 
> (the same with
> r350115) fails to boot with an immediate loader error:
> 
> [...]
> SeaBIOS (version rel-1.12.1.3-0-g300e8b7)
> 
> Press F10 key now for boot menu
> 
> Booting from Hard Disk...
> /
> 
> onsoles: internal video/keyboard   
> IOS drive C: is disk0 
> IOS drive D: is disk1 
> IOS 639kB/340kB available memory 
> 
> reeBSD/x86 bootstrap loader, Revision 1.1  
> Mon Apr 15 21:28:11 CEST 2019 root@thor) 
> anic: free: guard2 fail @ 0x1000 + 2311663946 from 
> Xçu0ç}4çl$♦├í@┤♠:2106163957 
> -> Press a key on the console to reboot <-- 
> […]


This is definitely something “funny”, we are apparently attempting to free 
pointer 0x1000 which is definitely wrong because our heap should be just below 
4GB line. Since we do get list of disks printed, also memory and version, it 
means we get error from interpretator - it is possible the stack did clash with 
bss and hence the corruption.

You can try to press space on first spinner and enter alternate loader on boot: 
prompt. (enter ?/boot on boot: prompt to see the file list).


> 
> 
> 
> 
> Booting 12.0-STABLE #78 r349288: Sat Jun 22 09:10:25 CEST 2019 amd64 works 
> fine with nothing
> changed except the OS version.
> 
> 
> Booting 2.0-STABLE #78 r349288 works fine:
> 
> [...]
> SeaBIOS (version rel-1.12.1.3-0-g300e8b7)
> 
> Press F10 key now for boot menu
> 
> Booting from Hard Disk...
> |
> 
> onsoles: internal video/keyboard   
> IOS drive C: is disk0 
> IOS drive D: is disk1 
> IOS 639kB/340kB available memory 
> 
> reeBSD/x86 bootstrap loader, Revision 1.1 
> Mon Apr 15 21:28:11 CEST 2019 root@thor) 
> oading /boot/defaults/loader.conf 
> oading /boot/device.hints 
> oading /boot/loader.conf 
> oading /boot/loader.conf.local 
> Loading kernel...
> /boot/kernel/kernel text=0xb005e8 \
> [...]
> 
> In the message taken from the serial console the first column of characters 
> is lost due to an
> error in the output which seems FreeBSD related.
> 

It certainly does look weird - sio_putc() is used in boot2 and it’s 
implementation is using same principe as comc_putchat() in comconsole.c (even 
if it is asm versus c code). Since the serial data is interpreted by terminal, 
it feels more about terminal emulator issue (line discipline, cabling, usb to 
serial dongle?)

rgds,
toomas


> 
> The file /boot/loader.conf.local contains these lines in both, working and 
> non-working,
> scenario:
> 
> [...]
> boot_serial="YES"
> # serial speed in bits/s
> comconsole_speed="115200"
> console="comconsole"
> 
> autoboot_delay="0"
> 
> verbose_loading="YES"
> loader_logo="orb"
> beastie_disable="YES"
> 
> ###  Microcode
> #cpu_microcode_load="YES"# Set this to YES to load and apply a
> #cpu_microcode_name="/boot/firmware/intel-ucode.bin" # Set this to the 
> microcode
> #cpu_microcode_type="cpu_microcode"  # Required for the kernel to find
> # the microcode update file.
> 
> 
> # disable Process Table Isolation
> #vm.pmap.pti=0
> 
> kern.geom.label.gptid.enable=0
> 
> # Limit the phys. memory
> #hw.physmem=1073741824  # 1 G
> #hw.physmem=536870912   # 512 MB
> #hw.physmem=268435456   # 256 MB
> 
> # Da mehr als 1 igb NIC an Bord! Siehe man igb(4)
> kern.ipc.nmbclusters=757350
> #kern.ipc.nmbjumbo9k=8192
> 
> # NIC
> #hw.em.max_interrupt_rate=32000
> hw.em.max_interrupt_rate=16000
> 
> #If non-zero, enable EXPERIMENTAL feature to improve concurrent Fortuna 
> performance
> kern.random.fortuna.concurrent_read="1"
> 
> # Forward Information Bases (FIBs)
> net.fibs=10
> net.add_addr_allfibs=0
> 
> [...]
> 
> 
> Again, with the exact same setting 12-STABLE r349288 boots fine, rr350274 
> doesn't. 
> FreeBSD 12-STABLE r
> 
> Can someone please help?
> 
> Thanks in advance, oh
> 
> 
> 
> - -- 
> O. Hartmann
> 
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> -BEGIN PGP SIGNATURE-
> 
> iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXTgStAAKCRA4N1ZZPba5
> R7YUAPsGg2mkFYPohDjTBoQEVPkJUsSIOM+s3oxsrYfQJ/RfYwD+LGp3jmC+PDML
> mhCtddjT7graxjMKIknflAKYFs6LMwU=
> =bU6X
> -END PGP SIGNATURE-
> ___
> 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: PCengines APU2C4, 12-STABLE: bootloader failure: Panic: free: guard2 fail @ 0x1000 + 2311663946 from

[Toomas Soome]

> On 24 Jul 2019, at 16:48, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Am Wed, 24 Jul 2019 12:06:53 +0200
> "O. Hartmann" mailto:o.hartm...@walstatt.org>> 
> schrieb:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> Am Wed, 24 Jul 2019 12:09:16 +0300
>> Toomas Soome  schrieb:
>> 
>>>> On 24 Jul 2019, at 11:11, O. Hartmann  wrote:
>>>> 
>>>> -BEGIN PGP SIGNED MESSAGE-
>>>> Hash: SHA256
>>>> 
>>>> Hallo,
>>>> 
>>>> on APU2C4 from PCengines with latest firmware apu2_v4.9.0.7.rom, SeaBIOS
>>>> rel-1.12.1.3-0-g300e8b7, booting via legacy MBR FreeBSD 12-STABLE r350274 
>>>> (the same with
>>>> r350115) fails to boot with an immediate loader error:
>>>> 
>>>> [...]
>>>> SeaBIOS (version rel-1.12.1.3-0-g300e8b7)
>>>> 
>>>> Press F10 key now for boot menu
>>>> 
>>>> Booting from Hard Disk...
>>>> /
>>>> 
>>>> onsoles: internal video/keyboard   
>>>> IOS drive C: is disk0 
>>>> IOS drive D: is disk1 
>>>> IOS 639kB/340kB available memory 
>>>> 
>>>> reeBSD/x86 bootstrap loader, Revision 1.1  
>>>> Mon Apr 15 21:28:11 CEST 2019 root@thor) 
>>>> anic: free: guard2 fail @ 0x1000 + 2311663946 from 
>>>> Xçu0ç}4çl$♦├í@┤♠:2106163957 
>>>> -> Press a key on the console to reboot <-- 
>>>> […]
>>> 
>>> 
>>> This is definitely something “funny”, we are apparently attempting to free 
>>> pointer 0x1000
>>> which is definitely wrong because our heap should be just below 4GB line. 
>>> Since we do get
>>> list of disks printed, also memory and version, it means we get error from 
>>> interpretator -
>>> it is possible the stack did clash with bss and hence the corruption.  
>> 
>> I realized that I have defined 
>> 
>> WITH_KERNEL_RETPOLINE=YES
>> 
>> and since I use to build NanoBSD with -DNO_CLEAN, I'm just now compiling a 
>> clean NanoBSD with
>> RETPOLINE mitigations disabled so far - trying to check whether either of 
>> the ways to build 
>> causes the issue.
>> 
>>> 
>>> You can try to press space on first spinner and enter alternate loader on 
>>> boot: prompt.
>>> (enter ?/boot on boot: prompt to see the file list).  
>> 
>> I try a soon as the build process has finished and if the problem is then 
>> still present.
> 
> 
> With a fresh build and no RETPOLINE mitigation (neither kernel nor world) the 
> phenomenon as
> described above is still the same. I tried an alternative loader as 
> requested, but without
> success. When choosing loader_4th, I get this error:
> 
> [...]
> FreeBSD/x86 boot
> Default: 0:ad(0p3)/boot/loader
> boot:  /boot/loader_4th/
> 
> onsoles: internal video/keyboard
> IOS drive C: is disk0
> IOS drive D: is disk1
> IOS 639kB/340kB available memory
> 
> reeBSD/x86 bootstrap loader, Revision 1.1
> Wed Jul 24 12:51:12 CEST 2019 root@thor)
> anic: No heap setup
> -> Press a key on the console to reboot <—
> 

Now this is bad. if my math is correct, this system is supposed to have 3GB of 
RAM, so are there specific build exceptions in place? see 
stand/i386/loader/main.c, function main, after call to bios_getmem().

rgds,
toomas

> 
> Loader loader_simp ends up in stuck console with no output:
> 
> [...]
> FreeBSD/x86 boot
> Default: 0:ad(0p3)/boot/loader
> boot:  /boot/loader_4th/
> 
> onsoles: internal video/keyboard
> IOS drive C: is disk0
> IOS drive D: is disk1
> IOS 639kB/340kB available memory
> 
> reeBSD/x86 bootstrap loader, Revision 1.1
> Wed Jul 24 12:59:23 CEST 2019 root@thor)
> [...]
> 
> regards
> oh
>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Booting 12.0-STABLE #78 r349288: Sat Jun 22 09:10:25 CEST 2019 amd64 works 
>>>> fine with
>>>> nothing changed except the OS version.
>>>> 
>>>> 
>>>> Booting 2.0-STABLE #78 r349288 works fine:
>>>> 
>>>> [...]
>>>> SeaBIOS (version rel-1.12.1.3-0-g300e8b7)
>>>> 
>>>> Press F10 key now for boot menu
>>>> 
>>>> Booting from Hard Disk...
>>>> |
>>>> 
>>>> onsoles: internal video/keyboard   
>>>> IOS drive C: is 

Re: PCengines APU2C4, 12-STABLE: bootloader failure: Panic: free: guard2 fail @ 0x1000 + 2311663946 from

[Toomas Soome]

> On 24 Jul 2019, at 21:30, Hartmann, O.  wrote:
> 
> On Wed, 24 Jul 2019 18:07:22 +0300
> Toomas Soome mailto:tso...@me.com>> wrote:
> 
>>> On 24 Jul 2019, at 16:48, O. Hartmann >> <mailto:ohartm...@walstatt.org>>
>>> wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> 
>>> Am Wed, 24 Jul 2019 12:06:53 +0200
>>> "O. Hartmann" mailto:o.hartm...@walstatt.org>
>>> <mailto:o.hartm...@walstatt.org <mailto:o.hartm...@walstatt.org>>> schrieb: 
>>>> -BEGIN PGP SIGNED MESSAGE-
>>>> Hash: SHA256
>>>> 
>>>> Am Wed, 24 Jul 2019 12:09:16 +0300
>>>> Toomas Soome  schrieb:
>>>> 
>>>>>> On 24 Jul 2019, at 11:11, O. Hartmann 
>>>>>> wrote:
>>>>>> 
>>>>>> -BEGIN PGP SIGNED MESSAGE-
>>>>>> Hash: SHA256
>>>>>> 
>>>>>> Hallo,
>>>>>> 
>>>>>> on APU2C4 from PCengines with latest firmware apu2_v4.9.0.7.rom,
>>>>>> SeaBIOS rel-1.12.1.3-0-g300e8b7, booting via legacy MBR FreeBSD
>>>>>> 12-STABLE r350274 (the same with r350115) fails to boot with an
>>>>>> immediate loader error:
>>>>>> 
>>>>>> [...]
>>>>>> SeaBIOS (version rel-1.12.1.3-0-g300e8b7)
>>>>>> 
>>>>>> Press F10 key now for boot menu
>>>>>> 
>>>>>> Booting from Hard Disk...
>>>>>> /
>>>>>> 
>>>>>> onsoles: internal video/keyboard   
>>>>>> IOS drive C: is disk0 
>>>>>> IOS drive D: is disk1 
>>>>>> IOS 639kB/340kB available memory 
>>>>>> 
>>>>>> reeBSD/x86 bootstrap loader, Revision 1.1  
>>>>>> Mon Apr 15 21:28:11 CEST 2019 root@thor) 
>>>>>> anic: free: guard2 fail @ 0x1000 + 2311663946 from
>>>>>> Xçu0ç}4çl$♦├í@┤♠:2106163957 -> Press a key on the console to
>>>>>> reboot <-- […]  
>>>>> 
>>>>> 
>>>>> This is definitely something “funny”, we are apparently
>>>>> attempting to free pointer 0x1000 which is definitely wrong
>>>>> because our heap should be just below 4GB line. Since we do get
>>>>> list of disks printed, also memory and version, it means we get
>>>>> error from interpretator - it is possible the stack did clash
>>>>> with bss and hence the corruption.
>>>> 
>>>> I realized that I have defined 
>>>> 
>>>> WITH_KERNEL_RETPOLINE=YES
>>>> 
>>>> and since I use to build NanoBSD with -DNO_CLEAN, I'm just now
>>>> compiling a clean NanoBSD with RETPOLINE mitigations disabled so
>>>> far - trying to check whether either of the ways to build causes
>>>> the issue. 
>>>>> 
>>>>> You can try to press space on first spinner and enter alternate
>>>>> loader on boot: prompt. (enter ?/boot on boot: prompt to see the
>>>>> file list).
>>>> 
>>>> I try a soon as the build process has finished and if the problem
>>>> is then still present.  
>>> 
>>> 
>>> With a fresh build and no RETPOLINE mitigation (neither kernel nor
>>> world) the phenomenon as described above is still the same. I tried
>>> an alternative loader as requested, but without success. When
>>> choosing loader_4th, I get this error:
>>> 
>>> [...]
>>> FreeBSD/x86 boot
>>> Default: 0:ad(0p3)/boot/loader
>>> boot:  /boot/loader_4th/
>>> 
>>> onsoles: internal video/keyboard
>>> IOS drive C: is disk0
>>> IOS drive D: is disk1
>>> IOS 639kB/340kB available memory
>>> 
>>> reeBSD/x86 bootstrap loader, Revision 1.1
>>> Wed Jul 24 12:51:12 CEST 2019 root@thor)
>>> anic: No heap setup  
>>> -> Press a key on the console to reboot <—  
>>> 
>> 
>> Now this is bad. if my math is correct, this system is supposed to
>> have 3GB of RAM, so are there specific build exceptions in place? see
>> stand/i386/loader/main.c, function main, after call to bios_getmem().
>> 
>> rgds,
>> toomas
> 
> I'm afraid I do not understand exactly the point. The base system is a
> PCengine APU2C4 - which has 4 GB of memory total. I

Re: PCengines APU2C4, 12-STABLE: bootloader failure: Panic: free: guard2 fail @ 0x1000 + 2311663946 from

[Toomas Soome]

> On 30 Jul 2019, at 15:43, O. Hartmann  wrote:
> 
> On Wed, 24 Jul 2019 18:07:22 +0300
> Toomas Soome  wrote:
> 
>>> On 24 Jul 2019, at 16:48, O. Hartmann  wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> 
>>> Am Wed, 24 Jul 2019 12:06:53 +0200
>>> "O. Hartmann" mailto:o.hartm...@walstatt.org>>
>>> schrieb: 
>>>> -BEGIN PGP SIGNED MESSAGE-
>>>> Hash: SHA256
>>>> 
>>>> Am Wed, 24 Jul 2019 12:09:16 +0300
>>>> Toomas Soome  schrieb:
>>>> 
>>>>>> On 24 Jul 2019, at 11:11, O. Hartmann  wrote:
>>>>>> 
>>>>>> -BEGIN PGP SIGNED MESSAGE-
>>>>>> Hash: SHA256
>>>>>> 
>>>>>> Hallo,
>>>>>> 
>>>>>> on APU2C4 from PCengines with latest firmware apu2_v4.9.0.7.rom, SeaBIOS
>>>>>> rel-1.12.1.3-0-g300e8b7, booting via legacy MBR FreeBSD 12-STABLE
>>>>>> r350274 (the same with r350115) fails to boot with an immediate loader
>>>>>> error:
>>>>>> 
>>>>>> [...]
>>>>>> SeaBIOS (version rel-1.12.1.3-0-g300e8b7)
>>>>>> 
>>>>>> Press F10 key now for boot menu
>>>>>> 
>>>>>> Booting from Hard Disk...
>>>>>> /
>>>>>> 
>>>>>> onsoles: internal video/keyboard   
>>>>>> IOS drive C: is disk0 
>>>>>> IOS drive D: is disk1 
>>>>>> IOS 639kB/340kB available memory 
>>>>>> 
>>>>>> reeBSD/x86 bootstrap loader, Revision 1.1  
>>>>>> Mon Apr 15 21:28:11 CEST 2019 root@thor) 
>>>>>> anic: free: guard2 fail @ 0x1000 + 2311663946 from
>>>>>> Xçu0ç}4çl$♦├í@┤♠:2106163957 -> Press a key on the console to reboot
>>>>>> <-- […]  
>>>>> 
>>>>> 
>>>>> This is definitely something “funny”, we are apparently attempting to
>>>>> free pointer 0x1000 which is definitely wrong because our heap should be
>>>>> just below 4GB line. Since we do get list of disks printed, also memory
>>>>> and version, it means we get error from interpretator - it is possible
>>>>> the stack did clash with bss and hence the corruption.
>>>> 
>>>> I realized that I have defined 
>>>> 
>>>> WITH_KERNEL_RETPOLINE=YES
>>>> 
>>>> and since I use to build NanoBSD with -DNO_CLEAN, I'm just now compiling a
>>>> clean NanoBSD with RETPOLINE mitigations disabled so far - trying to check
>>>> whether either of the ways to build causes the issue.
>>>> 
>>>>> 
>>>>> You can try to press space on first spinner and enter alternate loader on
>>>>> boot: prompt. (enter ?/boot on boot: prompt to see the file list).
>>>> 
>>>> I try a soon as the build process has finished and if the problem is then
>>>> still present.  
>>> 
>>> 
>>> With a fresh build and no RETPOLINE mitigation (neither kernel nor world)
>>> the phenomenon as described above is still the same. I tried an alternative
>>> loader as requested, but without success. When choosing loader_4th, I get
>>> this error:
>>> 
>>> [...]
>>> FreeBSD/x86 boot
>>> Default: 0:ad(0p3)/boot/loader
>>> boot:  /boot/loader_4th/
>>> 
>>> onsoles: internal video/keyboard
>>> IOS drive C: is disk0
>>> IOS drive D: is disk1
>>> IOS 639kB/340kB available memory
>>> 
>>> reeBSD/x86 bootstrap loader, Revision 1.1
>>> Wed Jul 24 12:51:12 CEST 2019 root@thor)
>>> anic: No heap setup  
>>> -> Press a key on the console to reboot <—  
>>> 
>> 
>> Now this is bad. if my math is correct, this system is supposed to have 3GB
>> of RAM, so are there specific build exceptions in place? see
>> stand/i386/loader/main.c, function main, after call to bios_getmem().
>> 
>> rgds,
>> toomas
> 
> 
> Hello Toomas,
> the PCengine APU2C4 is supposed to have 4GB of RAM - wouldn't have a 64bit
> system seen the whole range? On 32bit systems, there was a memory hole I 
> assume
> for memory mapped  I/O of several PCI devices. This is the first time I have a
> look at the memory reported by the kernel and its confusing me a bit.
> 

The BIOS loade

Re: Can't boot current under bhyve on current

[Toomas Soome]

Could you test with larger memory setup - instead of 512M, 1-2G?

rgds,
toomas

> On 16 Aug 2019, at 22:00, Sean Eric Fagan  wrote:
> 
>> I think vm-bhyve hides stderr output from bhyve by default, but there might
>> be a flag to make it display the stderr output.  Can you try doing that to 
>> see
>> if bhyve is reporting an error?  Alternatively, can you see if the bhyve
>> process is still running?
> 
> The log file from it is below.  bhyve was still running, looping on vm ioctls,
> until I killed it.
> 
>   starting bhyve (run 1)
>   bhyve exited with status 1
>   destroying network device tap1
>   stopped
>   initialising
>[loader: bhyveload]
>[cpu: 1]
>[memory: 512M]
>[hostbridge: standard]
>[com ports: com1]
>[uuid: ad7532de-bec1-11e9-8a55-d05099c38c95]
>[utctime: yes]
>[debug mode: no]
>[primary disk: disk0.img]
>[primary disk dev: file]
>   initialising network device tap0
>   failed to find virtual switch 'public'
>   booting
>   bhyveload -m 512M -e autoboot_delay=3 -d 
> /VMs/VM-TEST/../.iso/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso 
> VM-TEST
>[bhyve options: -c 1 -m 512M -AHP -U
> ad7532de-bec1-11e9-8a55-d05099c38c95 -u]
>[bhyve devices: -s 0,hostbridge -s 31,lpc -s
> 4:0,virtio-blk,/VMs/VM-TEST/disk0.img -s
> 5:0,virtio-net,tap0,mac=58:9c:fc:04:34:69]
>[bhyve console: -l com1,stdio]
>[bhyve iso device: -s
> 3:0,ahci-cd,/VMs/VM-TEST/../.iso/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso,ro]
>   starting bhyve (run 1)
>   bhyve exited with status 1
>   destroying network device tap0
>   stopped
> 
> Alan was trying to help me debug this yesterday, and I manually ran bhyve, but
> had no errors, and it still didn't work.
> 
> Thanks,
> 
> Sean.
> ___
> 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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Toomas Soome]

If you drop into efi shell, can you start efi/boot/bootx64.efi manually? you 
should have fs0: or like for ESP.

rgds,
toomas

> On 21 Aug 2019, at 20:58, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I ran into serious trouble booting several boxes off UEFI. On modern hardware,
> the ESP is around 200 - 300 MB in size and usually I install
> /efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On some older
> hardware, specifically on a Lenovo E540 with latest available firmware (2.28),
> which uses 12-STABLE and a ZFS-only installation, there seems no working 
> loader
> anymore!
> The installation of the Laptop has been performed using 12.0-PRERELEASE on an
> Samsung EVO 860 500GB SSD. The ESP is 200M in size and contained
> /efi/boot/BOOTx64.efi and /efi/boot/startup.nsh.
> 
> The ESP has been destroyed by accident. Now I tried to solve the problem by
> installing a new ESP and the proper loader, assuming that /boot/loader.efi
> (taken from a FreeBSD-13-CURRENT or from 12-STABLE of the same revision and
> sompiled on the same platform (Intel Haswell) as the lost laptop's revison of
> the OS is at. But I fail doing so. Somehow Lenovo's firmware is setting up a
> lot of UEFI boot numbers as provided via "efibootmgr -b 000X", X some Hex
> numer. -b 000A is usually denoted/labeld with "ATA HDD0".
> 
> Installing the proper boot/loader.efi loader file from 12-STABLE (r351108) and
> setting the EFI variable according the following steps:
> 
> mount -t msdosfs /dev/ada0p1 /mnt (ESP is on GPT partition 1, 0p2 is zroot)
> Install then loader.efi either as BOOTx64.efi or loader.efi under
> /mnt/efi/boot/ or /mnt/efi/freebsd/ and then set the boot environment
> accordingly via
> 
> delete 000A first:
> efibootmgr -B -b 000A
> 
> create the new efi boot var:
> efibootmgr -a -b 000A -c -l /mnt/efi/{freebsd|boot}/{loader.efi|BOOTx64.efi} 
> -L
> FreeBSD
> 
> The result is a non booting system, the Lenovo firmware jumps immediately into
> the menu for selecting a proper boot media.
> 
> The same happens with /boot/boot1.efi installed as loader.efi or BOOTx64.efi
> shown above.
> 
> In case I just brute-force flash the ESP with /boot/boot1.efifat, dd
> if=boot1.efifat of=/dev/ada0p1 (ESP) (taken from the propper 12-STABLE system 
> I
> spoeke of above), then booting fails again, but this time with an error I 
> watch
> on so many boxes recently:
> 
> [...]
> Ignoring Boot000a: Only one DP found
> Trying ZFS pool
> Setting currdev to zfs:zroot/ROOT/default:
> 
> Then the console freezes at that point and only RESET or POWER OFF is capable
> of a revive.
> 
> What is wrong here? What am I missing?
> 
> Thanks in advance,
> 
> oh
> 
> 
> - -- 
> O. Hartmann
> 
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> -BEGIN PGP SIGNATURE-
> 
> iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXV2GbQAKCRA4N1ZZPba5
> R8nBAP9GBNJGQV+Q6BD2BlMYDX1Toxu9ybQZc2uahniHNER6cAEA5TmHBDTu94eE
> fX+hTk4vDUkf8ga4EsrUDZflage6LAk=
> =3img
> -END PGP SIGNATURE-
> ___
> 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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Toomas Soome]

> On 21 Aug 2019, at 22:30, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Am Wed, 21 Aug 2019 22:14:46 +0300
> Toomas Soome mailto:tso...@me.com>> schrieb:
> 
>> If you drop into efi shell, can you start efi/boot/bootx64.efi manually? you 
>> should have
>> fs0: or like for ESP.
>> 
>> rgds,
>> toomas
> 
> Hello,
> 
> I can't even stop to gain access to the shell; there is no timeframe to hit 
> any key to stop by
> and access the efi shell. 
> 
> Kind regards,
> oh


hm? efi shell should be available from boot device menu, so you mean, you can 
not even get into firmware setup?

rgds,
toomas

> 
>> 
>>> On 21 Aug 2019, at 20:58, O. Hartmann  wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> 
>>> I ran into serious trouble booting several boxes off UEFI. On modern 
>>> hardware,
>>> the ESP is around 200 - 300 MB in size and usually I install
>>> /efi/freebsd/loader.efi, loader.efi taken from /boot/loader.efi. On some 
>>> older
>>> hardware, specifically on a Lenovo E540 with latest available firmware 
>>> (2.28),
>>> which uses 12-STABLE and a ZFS-only installation, there seems no working 
>>> loader
>>> anymore!
>>> The installation of the Laptop has been performed using 12.0-PRERELEASE on 
>>> an
>>> Samsung EVO 860 500GB SSD. The ESP is 200M in size and contained
>>> /efi/boot/BOOTx64.efi and /efi/boot/startup.nsh.
>>> 
>>> The ESP has been destroyed by accident. Now I tried to solve the problem by
>>> installing a new ESP and the proper loader, assuming that /boot/loader.efi
>>> (taken from a FreeBSD-13-CURRENT or from 12-STABLE of the same revision and
>>> sompiled on the same platform (Intel Haswell) as the lost laptop's revison 
>>> of
>>> the OS is at. But I fail doing so. Somehow Lenovo's firmware is setting up a
>>> lot of UEFI boot numbers as provided via "efibootmgr -b 000X", X some Hex
>>> numer. -b 000A is usually denoted/labeld with "ATA HDD0".
>>> 
>>> Installing the proper boot/loader.efi loader file from 12-STABLE (r351108) 
>>> and
>>> setting the EFI variable according the following steps:
>>> 
>>> mount -t msdosfs /dev/ada0p1 /mnt (ESP is on GPT partition 1, 0p2 is zroot)
>>> Install then loader.efi either as BOOTx64.efi or loader.efi under
>>> /mnt/efi/boot/ or /mnt/efi/freebsd/ and then set the boot environment
>>> accordingly via
>>> 
>>> delete 000A first:
>>> efibootmgr -B -b 000A
>>> 
>>> create the new efi boot var:
>>> efibootmgr -a -b 000A -c -l 
>>> /mnt/efi/{freebsd|boot}/{loader.efi|BOOTx64.efi} -L
>>> FreeBSD
>>> 
>>> The result is a non booting system, the Lenovo firmware jumps immediately 
>>> into
>>> the menu for selecting a proper boot media.
>>> 
>>> The same happens with /boot/boot1.efi installed as loader.efi or BOOTx64.efi
>>> shown above.
>>> 
>>> In case I just brute-force flash the ESP with /boot/boot1.efifat, dd
>>> if=boot1.efifat of=/dev/ada0p1 (ESP) (taken from the propper 12-STABLE 
>>> system I
>>> spoeke of above), then booting fails again, but this time with an error I 
>>> watch
>>> on so many boxes recently:
>>> 
>>> [...]
>>> Ignoring Boot000a: Only one DP found
>>> Trying ZFS pool
>>> Setting currdev to zfs:zroot/ROOT/default:
>>> 
>>> Then the console freezes at that point and only RESET or POWER OFF is 
>>> capable
>>> of a revive.
>>> 
>>> What is wrong here? What am I missing?
>>> 
>>> Thanks in advance,
>>> 
>>> oh
>>> 
>>> 
>>> - -- 
>>> O. Hartmann
>>> 
>>> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
>>> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
>>> -BEGIN PGP SIGNATURE-
>>> 
>>> iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXV2GbQAKCRA4N1ZZPba5
>>> R8nBAP9GBNJGQV+Q6BD2BlMYDX1Toxu9ybQZc2uahniHNER6cAEA5TmHBDTu94eE
>>> fX+hTk4vDUkf8ga4EsrUDZflage6LAk=
>>> =3img
>>> -END PGP SIGNATURE-
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send

Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Toomas Soome]

> On 22 Aug 2019, at 00:07, Clay Daniels Jr.  wrote:
> 
> I would agree with Karl & Steffen about using rEFInd. It really gives you a
> lot more control of your computers boot. Take a look at Rod Smith's pages:
> http://www.rodsbooks.com/refind/
> 
> I use it to triple boot Windows 10, MX Linux, and FreeBSD.
> 
> Clay


rEFInd is fancy menu to start real boot loader, it really does not help if your 
boot loader is broken. In worst case, you can get fragmented memory from having 
rEFInd and native boot loader (depending on how stupid/buggy the firmware is).

rgds,
toomas

> 
> On Wed, Aug 21, 2019 at 3:59 PM Karl Denninger  wrote:
> 
>> BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> 
>>> Am Wed, 21 Aug 2019 22:34:21 +0300
>>> Toomas Soome  schrieb:
>>> 
>>>>> On 21 Aug 2019, at 22:30, O. Hartmann  wrote:
>>>>> 
>>>>> -BEGIN PGP SIGNED MESSAGE-
>>>>> Hash: SHA256
>>>>> 
>>>>> Am Wed, 21 Aug 2019 22:14:46 +0300
>>>>> Toomas Soome mailto:tso...@me.com>> schrieb:
>>>>> 
>>>>>> If you drop into efi shell, can you start efi/boot/bootx64.efi
>>> manually? you should have
>>>>>> fs0: or like for ESP.
>>>>>> 
>>>>>> rgds,
>>>>>> toomas
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> I can't even stop to gain access to the shell; there is no
>>> timeframe to hit any key to
>>>>> stop by and access the efi shell.
>>>>> 
>>>>> Kind regards,
>>>>> oh
>>> 
>>> 
>>>> hm? efi shell should be available from boot device menu, so you
>>> mean, you can not even get
>>>> into firmware setup?
>>> 
>>>> rgds,
>>>> toomas
>>> 
>>> Sorry,
>>> I confused loader prompt and EFI shell.
>>> 
>>> I do not have a EFI shell on that type of laptop, not to know about
>>> it. I can access the
>>> firmware setup and already performed a reset and switched back to
>>> default settings. No effect.
>>> 
>>> I just downloaded the newest CURRENT mem stick and extracted both
>>> boot1.efi and loader.efi and
>>> installed those into the ESP as described, setting the efibootmgr env
>>> accordingly. Still the
>>> same error.
>>> 
>>> It seems that there is indeed no EFI/UEFI shell. There are Lenovo
>>> specific EFI boot options,
>>> like "diagnostics" and so on, if selected, the UEFI boots into a
>>> firmware embedded diagnostic
>>> menu. I tried several from the list given via efibootmgr show -v, but
>>> there is no shell from
>>> which I could access/boot an alternative loader.
>>> 
>>> How I'm supposed to achive the access to this EFI shell? I doubt that
>>> on the E540 (beware of
>>> the E, it is not a L or T model) does have such a shell.
>>> 
>>> Regards,
>>> oh
>> 
>> I would see if you can get REFIND loaded and use that.  I have a Lenovo
>> X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot
>> (e.g. Win10 and FreeBSD) easily.
>> 
>> I've not had trouble with 12.x on it, and I do use the
>> geli-encrypted-aware loader.efi.
>> 
>> If there's a way to get into the EFI shell on Lenovo's laptops from the
>> BIOS during the boot I've not found it yet.  There's supposed to be on
>> all EFI devices, but you know how "supposed to" works in many cases, right?
>> 
>> --
>> Karl Denninger
>> k...@denninger.net <mailto:k...@denninger.net>
>> /The Market Ticker/
>> /[S/MIME encrypted email preferred]/
>> 
>> 
>> 
> ___
> 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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Toomas Soome]

> On 22 Aug 2019, at 06:04, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Am Wed, 21 Aug 2019 22:29:29 +
> greg@unrelenting.technology schrieb:
> 
>> August 22, 2019 12:23 AM, "O. Hartmann"  wrote:
>> 
>>> Am Wed, 21 Aug 2019 15:58:24 -0500
>>> Karl Denninger  schrieb:
>>> 
 I would see if you can get REFIND loaded and use that.  I have a Lenovo
 X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot
 (e.g. Win10 and FreeBSD) easily.  
>>> 
>>> mmmhhh, Linux software to make FreeBSD boot? ;-)  
>> 
>> rEFInd is not "Linux software", I use it to get a nice menu to choose 
>> between FreeBSD and
>> Windows on my desktop. No Linux in sight. If anything, rEFInd has its roots 
>> in Macs :)
> 
> My apologizes; when searching the net, the first "logo" I see is this silly 
> penguine face. I'm
> sorry about making such simple implications.
> 
>> 
>>> This Lenovo firmware seems very reluctant or the efibootmgr doesn't operate 
>>> properly on
>>> setting variables: when trying to label the boot number (e.g. Boot000A) 
>>> with "-L FreeBSD",
>>> it is always set back to "Boot000A ATA HDD0". On other platforms, like 
>>> Fujitsu servers or
>>> even the cheap crap from ASRock a label once set is permenent until 
>>> deleted.  
>> 
>> Many laptops just ignore the boot variables outright. My X240 is the same.
>> I never switched to a proper efibootmgr setup on mine, I just have 
>> loader.efi as bootx64.efi
>> and that's it.
> 
> I tried copying loader.efi as bootx64.efi - but didn't help.
> 
 If there's a way to get into the EFI shell on Lenovo's laptops from the
 BIOS during the boot I've not found it yet.  There's supposed to be on
 all EFI devices, but you know how "supposed to" works in many cases, 
 right?  
>> 
>> You can just download the EFI Shell from the internet, it's a normal .efi 
>> executable you can
>> "boot". Put it as efi/boot/bootx64.efi onto a USB flash drive and enjoy.
> 
> I'll give this a chance as soon I have hands on the workitem again.
> 

The reason to try rEFInd and/or EFI shell is to see if we get extra error 
messages otherwise hidden by GUI.

In any case, to get to the root cause, we would need to start to insert more 
debug printouts and see what we will find. Once you are ready to go with it, 
you can poke me directly and then we can start…

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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Toomas Soome]

> On 27 Aug 2019, at 08:08, Warner Losh  wrote:
> 
> On Mon, Aug 26, 2019, 5:32 PM Rebecca Cran  > wrote:
> 
>> On 8/26/19 5:22 AM, O. Hartmann wrote:
>> 
>>> 
>>> the other thing is the weird Lenovo handling of the UEFI vars. The only
>> way to
>>> boot the E540 (after(!) disabling _BEARSSL in src.conf and rebuilding
>>> everything) was to set the loader's name to EFI/BOOT/BOOTx64.efi.
>> Setting the
>>> variable to contain EFI/BOOT/loader.efi failed as well as setting
>>> EFI/FreeBSD/loader.efi.
>> 
>> 
>> I've been suggesting FreeBSD should install the loader as
>> \EFI\BOOT\BOOTx64.efi for a while (as long as there's not already a
>> different vendor's loader there), without much success. Hopefully this
>> finding can cause us to reconsider.
>> 
> 
> That's the first machine I've seen where you have to set the name like
> that... there is a larger story here and we are getting incomplete reports
> because it doesn't quite make sense yet...
> 
> But there are enough reasons not to do that by default. For one thing, it
> messes up rEFInd, or can. Windows doesn't install there. At most we should
> prompt for older machines.  We shouldn't mortgage our future to cope with a
> legacy we know will sunset soon...
> 
> Warner
> 

For me it is still confusing if this is path versus upper-lower capital chars. 

If that vendor is using suggestion from UEFI Spec 2.7A section 3.5.1.1 (page 
91), then the file name should also end with .EFI. (and yes, I know, that 
section is talking about removable media).

Therefore the question is, does lenovo accept name like EFI/FREEBSD/LOADER.EFI? 
Or what form is used there for windows paths?

If we should or should not use EFI/BOOT path - perhaps the installer should 
prefer vendor path by default. But till there is confusion, there should be 
some notes in some documentation...

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: r352368 can't boot

[Toomas Soome]

> On 17 Sep 2019, at 08:30, KIRIYAMA Kazuhiko  wrote:
> 
> Hi,all
> 
> Yesterday I've updated latest head (r352368) and rebuild
> 13.0-CURRENT. All went fine, but when I boot, it's stopped
> at boot stage. Then I typed `boot', booted normally and put
> login prompt and login go ahead. But `shutdown -r now',
> stopped at loader prompt same as login case. What happened?
> All I've done is whithin bhyve VM.
> 
> 


> Consoles: userboot  
> 
> FreeBSD/amd64 User boot, Revision 1.1
> (Mon Jun 18 16:11:55 UTC 2018 r...@releng3.nyi.freebsd.org)
> Loading /boot/defaults/loader.conf
> xemit not found
> Error while including /boot/frames.4th, in the line:
>h_el @ xemit
> 
> can't load 'kernel'
> 
> Type '?' for a list of commands, 'help' for more detailed help.
> OK 
> 

This is unfortunate case where the guest image has more recent boot scripts 
than hosts /boot/userboot.so has. I did push the fix for that issue to 
stable/11 and stable/12. The patch does introduce xemit word.

Such situation is unfortunate, but accident waiting to happen with this method 
where we are attempting to use bootloader (userboot.so) from older system to 
load  guest vm. 

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: r352368 can't boot

[Toomas Soome]

> On 17 Sep 2019, at 13:09, Warner Losh  wrote:
> 
> 
> 
> On Tue, Sep 17, 2019, 6:47 AM Toomas Soome  <mailto:tso...@me.com>> wrote:
> 
> 
> > On 17 Sep 2019, at 08:30, KIRIYAMA Kazuhiko  > <mailto:k...@truefc.org>> wrote:
> > 
> > Hi,all
> > 
> > Yesterday I've updated latest head (r352368) and rebuild
> > 13.0-CURRENT. All went fine, but when I boot, it's stopped
> > at boot stage. Then I typed `boot', booted normally and put
> > login prompt and login go ahead. But `shutdown -r now',
> > stopped at loader prompt same as login case. What happened?
> > All I've done is whithin bhyve VM.
> > 
> > 
> 
> 
> > Consoles: userboot  
> > 
> > FreeBSD/amd64 User boot, Revision 1.1
> > (Mon Jun 18 16:11:55 UTC 2018 r...@releng3.nyi.freebsd.org 
> > <mailto:r...@releng3.nyi.freebsd.org>)
> > Loading /boot/defaults/loader.conf
> > xemit not found
> > Error while including /boot/frames.4th, in the line:
> >h_el @ xemit
> > 
> > can't load 'kernel'
> > 
> > Type '?' for a list of commands, 'help' for more detailed help.
> > OK 
> > 
> 
> This is unfortunate case where the guest image has more recent boot scripts 
> than hosts /boot/userboot.so has. I did push the fix for that issue to 
> stable/11 and stable/12. The patch does introduce xemit word.
> 
> Such situation is unfortunate, but accident waiting to happen with this 
> method where we are attempting to use bootloader (userboot.so) from older 
> system to load  guest vm. 
> 
> Can we provide a fallback to xemit builtin for old systems without it? I 
> believe we did this for other things as a transition. Forth has a way to do 
> this, though we need to make sure we properly constrain what we pass to 
> emit...
> 
> Warner
> 
> P.s. I'm at legoland this week, so I can't look at it for a bit.
> 

Well, the only way to avoid such issue is to make sure the guest environment is 
providing all the needed bits, but since we do have interpreter inside the 
userboot.so and userboot.so is in host, this does set rather unfortunate limits 
what we can do.

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: r352368 can't boot

[Toomas Soome]

> On 17 Sep 2019, at 14:21, Warner Losh  wrote:
> 
> 
> 
> On Tue, Sep 17, 2019, 11:24 AM Toomas Soome  <mailto:tso...@me.com>> wrote:
> 
> 
>> On 17 Sep 2019, at 13:09, Warner Losh > <mailto:i...@bsdimp.com>> wrote:
>> 
>> 
>> 
>> On Tue, Sep 17, 2019, 6:47 AM Toomas Soome > <mailto:tso...@me.com>> wrote:
>> 
>> 
>> > On 17 Sep 2019, at 08:30, KIRIYAMA Kazuhiko > > <mailto:k...@truefc.org>> wrote:
>> > 
>> > Hi,all
>> > 
>> > Yesterday I've updated latest head (r352368) and rebuild
>> > 13.0-CURRENT. All went fine, but when I boot, it's stopped
>> > at boot stage. Then I typed `boot', booted normally and put
>> > login prompt and login go ahead. But `shutdown -r now',
>> > stopped at loader prompt same as login case. What happened?
>> > All I've done is whithin bhyve VM.
>> > 
>> > 
>> 
>> 
>> > Consoles: userboot  
>> > 
>> > FreeBSD/amd64 User boot, Revision 1.1
>> > (Mon Jun 18 16:11:55 UTC 2018 r...@releng3.nyi.freebsd.org 
>> > <mailto:r...@releng3.nyi.freebsd.org>)
>> > Loading /boot/defaults/loader.conf
>> > xemit not found
>> > Error while including /boot/frames.4th, in the line:
>> >h_el @ xemit
>> > 
>> > can't load 'kernel'
>> > 
>> > Type '?' for a list of commands, 'help' for more detailed help.
>> > OK 
>> > 
>> 
>> This is unfortunate case where the guest image has more recent boot scripts 
>> than hosts /boot/userboot.so has. I did push the fix for that issue to 
>> stable/11 and stable/12. The patch does introduce xemit word.
>> 
>> Such situation is unfortunate, but accident waiting to happen with this 
>> method where we are attempting to use bootloader (userboot.so) from older 
>> system to load  guest vm. 
>> 
>> Can we provide a fallback to xemit builtin for old systems without it? I 
>> believe we did this for other things as a transition. Forth has a way to do 
>> this, though we need to make sure we properly constrain what we pass to 
>> emit...
>> 
>> Warner
>> 
>> P.s. I'm at legoland this week, so I can't look at it for a bit.
>> 
> 
> Well, the only way to avoid such issue is to make sure the guest environment 
> is providing all the needed bits, but since we do have interpreter inside the 
> userboot.so and userboot.so is in host, this does set rather unfortunate 
> limits what we can do.
> 
> Yes. I understand that we are limited in our scripts to somehow testing if 
> xemit is a forth word and if not providing a fallback implementation of it in 
> forth using emit.
> 
> 

done:)

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: ESXi VM does not boot in UEFI mode from 20190906 snapshot ISO

[Toomas Soome]

> On 18 Sep 2019, at 18:01, Yuri Pankov  wrote:
> 
> I have tested several snapshot ISOs available for download:
> 
> FreeBSD-13.0-CURRENT-amd64-20190822-r351363-disc1.iso - OK
> FreeBSD-13.0-CURRENT-amd64-20190829-r351591-disc1.iso - OK
> FreeBSD-13.0-CURRENT-amd64-20190906-r351901-disc1.iso - FAIL
> FreeBSD-13.0-CURRENT-amd64-20190913-r352265-disc1.iso - FAIL
> 
> FAIL being VM shutdown after loading kernel/modules and displaying "EFI 
> framebuffer information".  Relevant messages in the VM log are rather 
> unhelpful:
> 
> 2019-09-18T14:47:12.397Z| vcpu-0| I125: Guest: Firmware has transitioned to 
> runtime.
> 2019-09-18T14:47:12.434Z| vcpu-0| I125: Msg_Post: Error
> 2019-09-18T14:47:12.434Z| vcpu-0| I125: [msg.efi.exception] The firmware 
> encountered an unexpected exception. The virtual machine cannot boot.
> 
> Any hints on debugging this further?

Im not really sure about debugging; I can not tell about early kernel, but I’d 
check if the kernel/module locations conflict with efi memory map items… 

The same issue can be seen with vmware fusion, it is not 100% repeatable but 
I’d say, 95%, starting grab_faults, perhaps ls or some other random command, 
and boot -v may actually start the system up. 

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: Lockdown adaX numbers to allow booting ?

[Toomas Soome]

> On 19 Sep 2019, at 17:02, Kurt Jaeger  wrote:
> 
> Hi!
> 
> We have a system with 10 SATA disks. 2 disks are for the system,
> 8 disks drive a data pool 'bck', configured as raidz2, for backup purposes:
> 
> bck72.8T  38.7T  34.1T- - 1%53%  1.00x  ONLINE  -
> 
> The problem is that if all 10 disks are connected, the system
> looses track from where it should boot and fails to boot (serial boot log):
> 
> 
> /boot/config: -Dh -S115200
> 
> Consoles: internal video/keyboard  serial port
> BTX loader 1.00  BTX version is 1.02
> Consoles: internal video/keyboard  serial port
> BIOS drive C: is disk0
> BIOS drive D: is disk1
> BIOS drive E: is disk2
> BIOS drive F: is disk3
> BIOS drive G: is disk4
> BIOS drive H: is disk5
> BIOS drive I: is disk6
> BIOS drive J: is disk7
> BIOS drive K: is disk8
> BIOS drive L: is disk9
> //
> /
> 
> 
> The system disks are detected as ada4 and ada5, when all disks are
> plugged in.
> 
> The solution right now is this to unplug all disks of the 'bck' pool,
> reboot, and re-insert the data disks after the boot is finished.
> 
> I looked into the output to kenv(1), but did not find inspiration
> on how to fix this.
> 
> Now my questions:
> 
> - Shuffeling around SATA cables seems the wrong approach to fix this.
> - Can we somehow lock down the disk numbering so that the system disks
>  are detected as ada0 and ada1 ?


Why this order does change?  One would expect disks 0 and 1 to be OS disks and 
the rest for data…

Also the question is, what you mean with “system looses track”? disk4 becomes 
adaX? why it matters, are you using ufs on boot disks?

rgds,
toomas


> - Would
>  rootdev="disk4s1a"
>  in /boot/loader.conf work or is that the wrong approach ?
> - How could we configure two drivers as root devices in loader.conf ?
> 
> -- 
> p...@opsec.eu+49 171 3101372One year to go !
> ___
> 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: Lockdown adaX numbers to allow booting ?

[Toomas Soome]

> On 19 Sep 2019, at 18:57, Kurt Jaeger  wrote:
> 
> Hi!
> 
>>> We have a system with 10 SATA disks. 2 disks are for the system,
>>> 8 disks drive a data pool 'bck', configured as raidz2, for backup purposes:
>>> 
>>> bck72.8T  38.7T  34.1T- - 1%53%  1.00x  ONLINE  
>>> -
> 
>>> The problem is that if all 10 disks are connected, the system
>>> looses track from where it should boot and fails to boot (serial boot log):
> 
>> Why this order does change?  One would expect disks 0 and 1 to be OS disks 
>> and the rest for data???
> 
> 0+1 are 2.5", and the initial setup was:
> - we installed system disks as zroot 
> - shipped the box to the housing facility
> - booted and added the drives
> 
> At that time we did not do additional tests about the disk/boot sequence
> etc.
> 
>> Also the question is, what you mean with ???system looses track
> 
> I interpret the hang during boot as 'it looses track'. So I guess
> it tries to read the kernel from the wrong drives.


no, loader does probe disks to see which devices make up the pool and hung 
system is not about reading the kernel from wrong place.

I bet it is BIOS system? Since the raidz seems to be created partitionless, 
what version of freebsd are you using? BIOS up to date? can you test pool 
visibility in loader with  latest current usb/cd start - like press esc in menu 
and check lasdev -v (assuming you get to menu)… the same with uefi?

rgds,
toomas


> 
>> disk4 becomes adaX? why it matters, are you using ufs on boot disks?
> 
> No, zpool only.
> 
> I've made a few more details available here:
> 
> https://people.freebsd.org/~pi/host/dmesg.txt
> https://people.freebsd.org/~pi/host/devlist.txt
> https://people.freebsd.org/~pi/host/gpart.txt
> https://people.freebsd.org/~pi/host/pciconf.txt
> https://people.freebsd.org/~pi/host/zpool.txt
> 
> -- 
> p...@opsec.eu+49 171 3101372One year to go !
> ___
> 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: Lockdown adaX numbers to allow booting ?

[Toomas Soome]

> On 19 Sep 2019, at 21:48, Kurt Jaeger  wrote:
> 
> Hi!
> 
 Also the question is, what you mean with ???system looses track
> 
>>> I interpret the hang during boot as 'it looses track'. So I guess
>>> it tries to read the kernel from the wrong drives.
> 
>> no, loader does probe disks to see which devices make up the pool and hung 
>> system is not about reading the kernel from wrong place.
> 
>> I bet it is BIOS system?
> 
> If you mean: no UEFI boot ? Yes, it boots via BIOS, not UEFI.
> 
>> Since the raidz seems to be created partitionless, what version
>> of freebsd are you using?
> 
> FreeBSD 12.0p10, amd64.
> 
>> BIOS up to date?
> 
> The board is an X10SRi-F. dmidecode reports BIOS 3.1, supermicro
> has 3.1c, but the release notes do not mention things like that
> (or at least I don't understand them that way).
> 
> https://www.supermicro.com/en/products/motherboard/X10SRi-F
> 
>> can you test pool visibility in loader with latest current
>> usb/cd start - like press esc in menu and check lsdev -v
>> (assuming you get to menu) ? the same with uefi?
> 
> I will test this when I'm at the facility. Will take some time.
> 

Those data disks are 10TB 512e, I can not recall if loader in 12.0p10 does 
ignore partitionless disks in pools or not, if the bios is buggy about large 
disks, that does explain the hung system… in that case, the loader in current 
should be fine.

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: Can't boot current on Minnowboard

[Toomas Soome]

> On 24 Sep 2019, at 20:50, Renato Botelho  wrote:
> 
> As reported at pfSense ticket [1], we can't see console after booting
> FreeBSD installer iso on Minnowboard.  This video [2] demonstrates the
> problem.
> 
> Basically I can see all kernel messages but nothing from userland after
> kernel finishes to load.
> 
> I would be glad to collect any kind of data you need to help tracking it
> down.
> 
> Thanks!
> 
> [1] https://redmine.pfsense.org/issues/9488
> [2] https://imgur.com/a/V4IrQWo
> -- 
> Renato Botelho

Hi!

does it have bios emulation and does it behave there?

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: Can't boot current on Minnowboard

[Toomas Soome]

> On 24 Sep 2019, at 21:12, Renato Botelho  wrote:
> 
> On 24/09/19 15:10, Toomas Soome wrote:
>> 
>> 
>>> On 24 Sep 2019, at 20:50, Renato Botelho  wrote:
>>> 
>>> As reported at pfSense ticket [1], we can't see console after booting
>>> FreeBSD installer iso on Minnowboard.  This video [2] demonstrates the
>>> problem.
>>> 
>>> Basically I can see all kernel messages but nothing from userland after
>>> kernel finishes to load.
>>> 
>>> I would be glad to collect any kind of data you need to help tracking it
>>> down.
>>> 
>>> Thanks!
>>> 
>>> [1] https://redmine.pfsense.org/issues/9488
>>> [2] https://imgur.com/a/V4IrQWo
>>> -- 
>>> Renato Botelho
>> 
>> Hi!
>> 
>> does it have bios emulation and does it behave there?
> 
> No, this board is EFI only.
> 

Is it atom board? UEFI32 or UEFI64? 

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: SVN r354253 breaks buildworld

[Toomas Soome]

> On 2. Nov 2019, at 17:20, Michael Butler  wrote:
> 
> Something missing from SVN r354253?


Yes, the fix is coming soon, sorry about it.

rgds,
toomas

> 
> Building /usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue
> ld: error: undefined symbol: lz4_init
 referenced by spa_misc.c:2066
> (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2066)
  spa_misc.o:(spa_init) in archive
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a
> 
> ld: error: undefined symbol: lz4_fini
 referenced by spa_misc.c:2096
> (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2096)
  spa_misc.o:(spa_fini) in archive
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a
> cpp: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** [rescue] Error code 1
> 
> make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue
> .ERROR_TARGET='rescue'
> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue.meta'
> .MAKE.LEVEL='5'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose
> curdirOk=yes'
> _ERROR_CMD='cc -target x86_64-unknown-freebsd13.0
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -march=ivybridge
> -std=gnu99 -Wno-format-zero-length-Qunused-arguments -static
> -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo
> date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo
> kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo
> rm.lo rmdir.lo setfacl.lo sh.lo sleep.lo stty.lo sync.lo test.lo csh.lo
> camcontrol.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo
> fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo
> ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo
> ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo
> mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo
> mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo
> reboot.lo restore.lo rcorder.lo route.lo savecore.lo shutdown.lo
> spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo ccdconfig.lo
> ping6.lo rtsol.lo ipf.lo routed.lo rtquery.lo bectl.lo zfs.lo zpool.lo
> bsdlabel.lo fdisk.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo
> gzip.lo bzip2.lo less.lo xz.lo zstd.lo tar.lo nc.lo vi.lo id.lo
> iscsictl.lo zdb.lo chroot.lo chown.lo iscsid.lo
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/exec.o
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/getusershell.o
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/login_class.o
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/popen.o
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/rcmdsh.o
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/sysctl.o
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/system.o -lcrypt
> -ledit -ljail -lkvm -lelf -ll -ltermcapw -lutil -lxo -l80211 -lalias
> -lcam -lncursesw -ldevstat -lipsec -llzma -lavl -lzpool -lzfs_core -lzfs
> -lnvpair -lpthread -luutil -lumem -lbe -lgeom -lbsdxml -lkiconv -lmt
> -lsbuf -lufs -lz -lbz2 -lprivatezstd -larchive -lcrypto -lmd -lm;'
> .CURDIR='/usr/obj/usr/src/amd64.amd64/rescue/rescue'
> 
>   imb
> 

___
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: SVN r354253 breaks buildworld

[Toomas Soome]

Should be fixed by r354265.

rgds,
toomas

> On 2. Nov 2019, at 17:20, Michael Butler  wrote:
> 
> Something missing from SVN r354253?
> 
> Building /usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue
> ld: error: undefined symbol: lz4_init
 referenced by spa_misc.c:2066
> (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2066)
  spa_misc.o:(spa_init) in archive
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a
> 
> ld: error: undefined symbol: lz4_fini
 referenced by spa_misc.c:2096
> (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2096)
  spa_misc.o:(spa_fini) in archive
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a
> cpp: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** [rescue] Error code 1
> 
> make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue
> .ERROR_TARGET='rescue'
> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue.meta'
> .MAKE.LEVEL='5'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose
> curdirOk=yes'
> _ERROR_CMD='cc -target x86_64-unknown-freebsd13.0
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -march=ivybridge
> -std=gnu99 -Wno-format-zero-length-Qunused-arguments -static
> -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo
> date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo
> kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo
> rm.lo rmdir.lo setfacl.lo sh.lo sleep.lo stty.lo sync.lo test.lo csh.lo
> camcontrol.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo
> fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo
> ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo
> ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo
> mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo
> mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo
> reboot.lo restore.lo rcorder.lo route.lo savecore.lo shutdown.lo
> spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo ccdconfig.lo
> ping6.lo rtsol.lo ipf.lo routed.lo rtquery.lo bectl.lo zfs.lo zpool.lo
> bsdlabel.lo fdisk.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo
> gzip.lo bzip2.lo less.lo xz.lo zstd.lo tar.lo nc.lo vi.lo id.lo
> iscsictl.lo zdb.lo chroot.lo chown.lo iscsid.lo
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/exec.o
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/getusershell.o
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/login_class.o
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/popen.o
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/rcmdsh.o
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/sysctl.o
> /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/system.o -lcrypt
> -ledit -ljail -lkvm -lelf -ll -ltermcapw -lutil -lxo -l80211 -lalias
> -lcam -lncursesw -ldevstat -lipsec -llzma -lavl -lzpool -lzfs_core -lzfs
> -lnvpair -lpthread -luutil -lumem -lbe -lgeom -lbsdxml -lkiconv -lmt
> -lsbuf -lufs -lz -lbz2 -lprivatezstd -larchive -lcrypto -lmd -lm;'
> .CURDIR='/usr/obj/usr/src/amd64.amd64/rescue/rescue'
> 
>   imb
> 
> ___
> 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: SVN r354253 breaks buildworld

[Toomas Soome]

> On 2. Nov 2019, at 23:30, Michael Butler  wrote:
> 
> On 11/2/19 5:15 PM, Toomas Soome wrote:
>> Should be fixed by r354265.
> 
> The problem has moved .. now the kernel won't build ..
> 
> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/avl.o
> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/lz4.o
> --- lz4.o ---
> cc: error: no such file or directory:
> '/usr/src/sys/cddl/contrib/opensolaris/lz4/lz4.c'
> cc: error: no input files
> *** [lz4.o] Error code 1
> 
> That's brought in by sys/conf/files as follows ..
> 
> imb@vm01:/sys/conf> grep lz4 *
> files:cddl/contrib/opensolaris/lz4/lz4.c
>optional zfs compile-with "${ZFS_C}"
> kern.pre.mk:ZFS_CFLAGS+=-I$S/cddl/contrib/opensolaris/common/lz4
> 
>   imb
> 

Right. Thanks and sorry for the mess…

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: CURRENT October images do not create a bootable install

[Toomas Soome]

> On 7. Nov 2019, at 10:05, Chris  wrote:
> 
> On Thu, 7 Nov 2019 08:31:14 +0100 gljennj...@gmail.com said
> 
>> On Wed, 06 Nov 2019 17:23:08 -0800
>> Chris  wrote:
>> > I put a box together to test 13 about a mos ago.
>> > It's a second gen core i3. But whether choosing automatic
>> > disk layout, or choosing manual. When the install finishes, and
>> > boots to the drive. The BIOS reports no bootable media.
>> > I finally gave up, and grabbed the most recent RELENG-12. Which
>> > worked as expected.
>> > While I have no troubles booting (U)EFI. Isn't the so-called
>> > LEGACY boot option still supported?
>> > > Thank you for all your time, and consideration.
>> > 
> 
> Thanks for taking the time to respond, Gary.
> 
>> I installed the latest FreeBSD 13 memstick image (UEFI) yesterday
>> and had no problem booting it.  I used manual disk partitioning. In fact, 
>> when I added the / partition the installer automatically
>> created and populated the EFI boot partition for me.
> 
> Same here. But in spite of it. The reboot proved to be unsuccessful. :(
>> I used UEFI because that was already set in the BIOS and the
>> computer doesn't belong to me.
>> LEGACY mode should still work as long as the BIOS offers that. My main 
>> FreeBSD 13 box uses LEGACY booting.
> 
> My BIOS offers both. Yet neither option proved fruitful. :(
>> -- 
>> Gary Jennejohn
> 
> Thanks again, Gary! :)
> 

Do you have more detailed information? any error messages, screenshots?

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: CURRENT October images do not create a bootable install

[Toomas Soome]

> On 7. Nov 2019, at 10:38, Chris  wrote:
> 
> On Thu, 7 Nov 2019 10:15:49 +0200 Toomas Soome tso...@me.com 
> <mailto:tso...@me.com> said
> 
>> > On 7. Nov 2019, at 10:05, Chris  wrote:
>> > > On Thu, 7 Nov 2019 08:31:14 +0100 gljennj...@gmail.com said
>> > >> On Wed, 06 Nov 2019 17:23:08 -0800
>> >> Chris  wrote:
>> >> > I put a box together to test 13 about a mos ago.
>> >> > It's a second gen core i3. But whether choosing automatic
>> >> > disk layout, or choosing manual. When the install finishes, and
>> >> > boots to the drive. The BIOS reports no bootable media.
>> >> > I finally gave up, and grabbed the most recent RELENG-12. Which
>> >> > worked as expected.
>> >> > While I have no troubles booting (U)EFI. Isn't the so-called
>> >> > LEGACY boot option still supported?
>> >> > > Thank you for all your time, and consideration.
>> >> > > > Thanks for taking the time to respond, Gary.
>> > >> I installed the latest FreeBSD 13 memstick image (UEFI) yesterday
>> >> and had no problem booting it.  I used manual disk partitioning. In fact,
>> > when I added the / partition the installer automatically
>> >> created and populated the EFI boot partition for me.
>> > > Same here. But in spite of it. The reboot proved to be unsuccessful. :(
>> >> I used UEFI because that was already set in the BIOS and the
>> >> computer doesn't belong to me.
>> >> LEGACY mode should still work as long as the BIOS offers that. My main
>> > FreeBSD 13 box uses LEGACY booting.
>> > > My BIOS offers both. Yet neither option proved fruitful. :(
>> >> -- >> Gary Jennejohn
>> > > Thanks again, Gary! :)
>> > Do you have more detailed information? any error messages, screenshots?
> 
> Thanks for the reply, toomas.
> 
> It's just the standard BIOS report about non-bootable device, please inset
> bootable medium...
> 
> IOW it doesn't recognize the freshly installed 13-CURRENT on the hard drive
> as being a bootable OS.
> 
> I'm wondering what happened between RELENG-12, and 13 that made the change?
> 

If the BIOS does not find bootable disk, it likely does check the MBR, please 
use dd to read out sector 0 from your boot disk (something like dd if=/dev/da0 
of=mbr.dd count=1) and mail it to me directly so I can check what is there.

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: CURRENT October images do not create a bootable install

[Toomas Soome]

> On 7. Nov 2019, at 17:23, Daniel Nebdal  wrote:
> 
>> On Thu, 7 Nov 2019 09:49:52 +0100 gljennj...@gmail.com said
>> I chose GPT.
> 
> Maybe whoever wrote the EFI/BIOS code in your machine went all-in on
> "Legacy", and it only handles MBR disks (or disks < 2.2TB)?
> After all, it seems like "not booting" would be a standards-compliant
> way for a classic BIOS to handle a GPT disk.
> 

if your system is not booting from GPT disk, it means it is not standards 
compliant.

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: CURRENT October images do not create a bootable install

[Toomas Soome]

> On 7. Nov 2019, at 19:37, Chris.H  wrote:
> 
> On Thu, 7 Nov 2019 17:28:16 +0200 Toomas Soome tso...@me.com said
> 
>> > On 7. Nov 2019, at 17:23, Daniel Nebdal  wrote:
>> > >> On Thu, 7 Nov 2019 09:49:52 +0100 gljennj...@gmail.com said
>> >> I chose GPT.
>> > > Maybe whoever wrote the EFI/BIOS code in your machine went all-in on
>> > "Legacy", and it only handles MBR disks (or disks < 2.2TB)?
>> > After all, it seems like "not booting" would be a standards-compliant
>> > way for a classic BIOS to handle a GPT disk.
>> > if your system is not booting from GPT disk, it means it is not standards
>> compliant.
> Interesting. So then RELENG-12 is not "Standards" compliant. While 13-CURRENT 
> is?


Can not tell if you do not provide actual information, we can not really tell 
too much. However, based on the partition tables below, I can tell a bit.

Those disks are using GPT, there is EFI partition, which does suggest UEFI boot 
and not BIOS boot. There is no freebsd-boot partition, meaning the standard 
pmbr boot block does not work (if installed) — pmbr does search for 
freebsd-boot and will load its content and jumps on it. Without seeing your 
sector 0, I can not tell what code is there (if any), and based on partitions 
on that system, it is possible the BIOS boot is not installed at all. In a 
similar way, without seeing EFI partition content, we can not tell if UEFI boot 
is actually installed - EFI partition should have FAT file system with specific 
directory tree.

To make things better, the exact description would be helpful, so the devs 
taking care of installer could review the information and make fixes.

rgds,
toomas


> IOW I attempted in early October to install each of the (13-CURRENT) install
> images available. Both on a 500Gb disk, and a 1Tb disk. All w/o success. In
> desperation, I settled for the then (most recent) RELENG-12. 12 installed
> as all previous FreeBSD installs have done successfully.
> So something in (recent) 13' boot layout has changed. I can boot 
> Legacy/UEFI/GPT
> on 12. But cannot boot at all in recent 13.
> Following is the output of the RELENG-12 disk, as well as 13-CURRENT:
> 
> LIVE BOOTED DISK @FreeBSD 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 #0 
> r353409:
> Thu Oct 10 15:57:48 PDT 2019 amd64
> 
> Geom name: ada0
> modified: false
> state: OK
> fwheads: 16
> fwsectors: 63
> last: 976773127
> first: 40
> entries: 152
> scheme: GPT
> Providers:
> 1. Name: ada0p1
>  Mediasize: 209715200 (200M)
>  Sectorsize: 512
>  Stripesize: 0
>  Stripeoffset: 20480
>  Mode: r0w0e0
>  efimedia: HD(1,GPT,280cea32-eae6-11e9-ae21-4c72b9f5e07f,0x28,0x64000)
>  rawuuid: 280cea32-eae6-11e9-ae21-4c72b9f5e07f
>  rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
>  label: (null)
>  length: 209715200
>  offset: 20480
>  type: efi
>  index: 1
>  end: 409639
>  start: 40
> 2. Name: ada0p2
>  Mediasize: 27707572224 (26G)
>  Sectorsize: 512
>  Stripesize: 0
>  Stripeoffset: 209735680
>  Mode: r1w1e2
>  efimedia: HD(2,GPT,2856af2c-eae6-11e9-ae21-4c72b9f5e07f,0x64028,0x339c000)
>  rawuuid: 2856af2c-eae6-11e9-ae21-4c72b9f5e07f
>  rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
>  label: troot
>  length: 27707572224
>  offset: 209735680
>  type: freebsd-ufs
>  index: 2
>  end: 54525991
>  start: 409640
> 3. Name: ada0p3
>  Mediasize: 3984588800 (3.7G)
>  Sectorsize: 512
>  Stripesize: 0
>  Stripeoffset: 2147504128
>  Mode: r1w1e1
>  efimedia: HD(3,GPT,3c01ab9d-eae6-11e9-ae21-4c72b9f5e07f,0x3400028,0x76c000)
>  rawuuid: 3c01ab9d-eae6-11e9-ae21-4c72b9f5e07f
>  rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
>  label: tswap
>  length: 3984588800
>  offset: 27917307904
>  type: freebsd-swap
>  index: 3
>  end: 62308391
>  start: 54525992
> 4. Name: ada0p4
>  Mediasize: 68719476736 (64G)
>  Sectorsize: 512
>  Stripesize: 0
>  Stripeoffset: 1837125632
>  Mode: r1w1e2
>  efimedia: HD(4,GPT,4abf5d7c-eae6-11e9-ae21-4c72b9f5e07f,0x3b6c028,0x800)
>  rawuuid: 4abf5d7c-eae6-11e9-ae21-4c72b9f5e07f
>  rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
>  label: tvar
>  length: 68719476736
>  offset: 31901896704
>  type: freebsd-ufs
>  index: 4
>  end: 196526119
>  start: 62308392
> 5. Name: ada0p5
>  Mediasize: 289910292480 (270G)
>  Sectorsize: 512
>  Stripesize: 0
>  Stripeoffset: 1837125632
>  Mode: r1w1e2
>  efimedia: HD(5,GPT,58f639dd-eae6-11e9-ae21-4c72b9f5e07f,0xbb6c028,0x21c0)
>  rawuuid: 58f639dd-eae6-11e9-ae21-4c72b9f5e07f
>  rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
>  label: tusr
>  length: 289910292480
>  offset: 100621373440
>  type: freebsd-ufs
>  in

Re: CURRENT October images do not create a bootable install

[Toomas Soome]

> On 7. Nov 2019, at 21:07, Chris  wrote:
> 
> On Thu, 7 Nov 2019 20:09:12 +0200 Toomas Soome tso...@me.com 
> <mailto:tso...@me.com> said
> 
>> > On 7. Nov 2019, at 19:37, Chris.H  wrote:
>> > > On Thu, 7 Nov 2019 17:28:16 +0200 Toomas Soome tso...@me.com said
>> > >> > On 7. Nov 2019, at 17:23, Daniel Nebdal  wrote:
>> >> > >> On Thu, 7 Nov 2019 09:49:52 +0100 gljennj...@gmail.com said
>> >> >> I chose GPT.
>> >> > > Maybe whoever wrote the EFI/BIOS code in your machine went all-in on
>> >> > "Legacy", and it only handles MBR disks (or disks < 2.2TB)?
>> >> > After all, it seems like "not booting" would be a standards-compliant
>> >> > way for a classic BIOS to handle a GPT disk.
>> >> > if your system is not booting from GPT disk, it means it is not 
>> >> > standards
>> >> compliant.
>> > Interesting. So then RELENG-12 is not "Standards" compliant. While 
>> > 13-CURRENT
>> > is?
>> Can not tell if you do not provide actual information, we can not really tell
>> too much. However, based on the partition tables below, I can tell a bit.
>> Those disks are using GPT, there is EFI partition, which does suggest UEFI
>> boot and not BIOS boot. There is no freebsd-boot partition, meaning the
>> standard pmbr boot block does not work (if installed) — pmbr does search
>> for freebsd-boot and will load its content and jumps on it. Without seeing
>> your sector 0, I can not tell what code is there (if any), and based on
>> partitions on that system, it is possible the BIOS boot is not installed at
>> all. In a similar way, without seeing EFI partition content, we can not tell
>> if UEFI boot is actually installed - EFI partition should have FAT file
>> system with specific directory tree.
>> To make things better, the exact description would be helpful, so the devs
>> taking care of installer could review the information and make fixes.
> 
> Right. Sorry. I forgot you had asked for the output of dd(1).
> 
> I've done so, and will send you the output directly (off list).
> 

neither of disks had boot code in MBR block, so BIOS boot was definitely not 
going to happen there (the regular pmbr there would not help because there is 
no freebsd-boot partition). Therefore the question is if the ESP was set up 
properly.

My personal suggestion for x86 setups would be to set up both bios and efi boot.

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: CURRENT October images do not create a bootable install

[Toomas Soome]

> On 8. Nov 2019, at 20:34, Chris  wrote:
> 
> On Fri, 8 Nov 2019 10:32:25 +0100 gljennj...@gmail.com 
> <mailto:gljennj...@gmail.com> said
> 
>> On Thu, 07 Nov 2019 09:41:01 -0800
>> Chris  wrote:
>> > On Thu, 7 Nov 2019 17:28:16 +0200 Toomas Soome tso...@me.com said
>> > > > > On 7. Nov 2019, at 17:23, Daniel Nebdal  wrote:  
>> > > > > > > > > >> On Thu, 7 Nov 2019 09:49:52 +0100 gljennj...@gmail.com 
>> > > > > said  > > >> I chose GPT.  > > > > > Maybe whoever wrote the 
>> > > > > EFI/BIOS code in your machine went all-in on > > > > "Legacy", and 
>> > > > > it only handles MBR disks (or disks < 2.2TB)?
>> > > > After all, it seems like "not booting" would be a standards-compliant
>> > > > way for a classic BIOS to handle a GPT disk.  > > > >   > > if your 
>> > > > system is not booting from GPT disk, it means it is not standards
>> > > compliant.  > Interesting. So then RELENG-12 is not "Standards" 
>> > > compliant. While 13-CURRE
>> > NT is?
>> > IOW I attempted in early October to install each of the (13-CURRENT) instal
>> > l
>> > images available. Both on a 500Gb disk, and a 1Tb disk. All w/o success. In
>> > desperation, I settled for the then (most recent) RELENG-12. 12 installed
>> > as all previous FreeBSD installs have done successfully.
>> > So something in (recent) 13' boot layout has changed. I can boot Legacy/UEF
>> > I/GPT
>> > on 12. But cannot boot at all in recent 13.
>> >
>> I noticed that your 12 disk has Stripesize: 0 on all partitions
>> but 13 has Stripesize: 4096 on all partitions.
>> My bootable 13 disk has Stripesize: 0 on all partitions.
>> Whether that is the cause of your problem I can't say.
> 
> Thanks for the reply, Gary.
> Toomas also had some valuable input on my problem booting 13.
> In any case. I used the installer to create the disk layout. I didn't
> do anything different than I have for many years installing FreeBSD from
> the install sources. What puzzles me, is that RELENG-12 creates a
> bootable install, whereas 13-CURRENT won't.
> I've manually setup disks innumerable times in the past. I'll see
> if doing so produces bootable media doing it from a 13-CURRENT live
> DVD, or MEMSTICK, and report my findings.
> 
> Thanks again for taking the time to reply, Gary.
>> 

Did you manage to check what is in your efi (ESP) partition? Also, can you 
confirm if your system is set to boot in BIOS or UEFI mode? Note this may be 
tricky to figure, for example my AMI bios depends on which device is set for 
boot device. Also for UEFI boot, we do not support secure boot.

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"

Testing needed:)

[Toomas Soome]

Hi!

Can someone with arm media file path type of storage device and someone with 
apple UEFI 1.10 test https://reviews.freebsd.org/D22553 please:)

Other tests are also very welcome:)

thanks,
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: r 310850: buildworld failure due to: nandfs.c:1049:15: error: too many arguments to function call,

[Toomas Soome]

> On 30. dets 2016, at 21:35, Dimitry Andric  wrote:
> 
> On 30 Dec 2016, at 20:23, O. Hartmann  wrote:
>> 
>> Recent update of CURRENT to 2310850 fails with buildworld error:
>> 
>> [...]
>> ===> lib/atf/libatf-c++ (all)
>> --- all_subdir_lib/libstand ---
>> --- nandfs.o ---
>> /usr/src/lib/libstand/nandfs.c:1049:15: error: too many arguments to 
>> function call,
>> expected 6, have 7 buffer, NULL);
>>   ^~~~
>> /usr/obj/usr/src/tmp/usr/include/sys/_null.h:32:14: note: expanded from 
>> macro 'NULL'
>> #define NULL((void *)0)
>>   ^~~
>> 1 error generated.
>> *** [nandfs.o] Error code 1
> 
> This looks like the culprit to me:
> 
> On 30 Dec 2016, at 20:06, Toomas Soome  wrote:
>> Author: tsoome
>> Date: Fri Dec 30 19:06:29 2016
>> New Revision: 310850
>> URL: https://svnweb.freebsd.org/changeset/base/310850
>> 
>> Log:
>> dosfs support in libstand is broken since r298230
>> 
>> Apparently the libstand dosfs optimization is a bit too optimistic
>> and did introduce possible memory corruption.
>> 
>> This patch is backing out the bad part and since this results in
>> dosfs reading full blocks now, we can also remove extra offset argument
>> from dv_strategy callback.
>> 
>> The analysis of the issue and the backout patch is provided by Mikhail 
>> Kupchik.
>> 
>> PR:  214423
>> Submitted by:Mikhail Kupchik
>> Reported by: Mikhail Kupchik
>> Reviewed by: bapt, allanjude
>> Approved by: allanjude (mentor)
>> MFC after:   1 month
>> Differential Revision:   https://reviews.freebsd.org/D864
> 
> For some reason, your build seems to pick up an older stand.h header?
> 
> -Dimitry
> 


oh, apparently I *still* did miss one strategy call in nandfs..  Sorry, I’ll 
try to fix it asap.

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: r 310850: buildworld failure due to: nandfs.c:1049:15: error: too many arguments to function call,

[Toomas Soome]

> On 30. dets 2016, at 21:40, Toomas Soome  wrote:
> 
> 
>> On 30. dets 2016, at 21:35, Dimitry Andric  wrote:
>> 
>> On 30 Dec 2016, at 20:23, O. Hartmann  wrote:
>>> 
>>> Recent update of CURRENT to 2310850 fails with buildworld error:
>>> 
>>> [...]
>>> ===> lib/atf/libatf-c++ (all)
>>> --- all_subdir_lib/libstand ---
>>> --- nandfs.o ---
>>> /usr/src/lib/libstand/nandfs.c:1049:15: error: too many arguments to 
>>> function call,
>>> expected 6, have 7 buffer, NULL);
>>>  ^~~~
>>> /usr/obj/usr/src/tmp/usr/include/sys/_null.h:32:14: note: expanded from 
>>> macro 'NULL'
>>> #define NULL((void *)0)
>>>  ^~~
>>> 1 error generated.
>>> *** [nandfs.o] Error code 1
>> 
>> This looks like the culprit to me:
>> 
>> On 30 Dec 2016, at 20:06, Toomas Soome  wrote:
>>> Author: tsoome
>>> Date: Fri Dec 30 19:06:29 2016
>>> New Revision: 310850
>>> URL: https://svnweb.freebsd.org/changeset/base/310850
>>> 
>>> Log:
>>> dosfs support in libstand is broken since r298230
>>> 
>>> Apparently the libstand dosfs optimization is a bit too optimistic
>>> and did introduce possible memory corruption.
>>> 
>>> This patch is backing out the bad part and since this results in
>>> dosfs reading full blocks now, we can also remove extra offset argument
>>> from dv_strategy callback.
>>> 
>>> The analysis of the issue and the backout patch is provided by Mikhail 
>>> Kupchik.
>>> 
>>> PR: 214423
>>> Submitted by:   Mikhail Kupchik
>>> Reported by:Mikhail Kupchik
>>> Reviewed by:bapt, allanjude
>>> Approved by:allanjude (mentor)
>>> MFC after:  1 month
>>> Differential Revision:  https://reviews.freebsd.org/D864
>> 
>> For some reason, your build seems to pick up an older stand.h header?
>> 
>> -Dimitry
>> 
> 
> 
> oh, apparently I *still* did miss one strategy call in nandfs..  Sorry, I’ll 
> try to fix it asap.
> 

Please check: https://reviews.freebsd.org/D9003 
<https://reviews.freebsd.org/D9003>

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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Toomas Soome]

> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> Hi,
>   I tried upgrading one of my workstations and unfortunately the 
> freebsd-boot partition is too small (I follow manpage directions, exactly, 
> and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
> have enough space or ability to resize the partition and make it bigger. So, 
> I’m in need of a build knob to control the bloat, and/or having an 
> alternative boot loader without geli/skein/crypto support compiled in. Would 
> you be opposed to the work?
> Thanks,
> -Ngie


I do agree that since the geli knob is already there, it may do. Of course we 
also can think of additional knobs, but there is an issue - it wont help just 
to exclude some files, the additional features also do sit in the code, so the 
replacement stubs will be needed, also testing them all over will take some 
time. And the preprocessor spaghetti really is nasty thing to deal with;)

And then there is another issue (partly why I did the feature support in first 
place) - as the kernel does not block user from enabling the features, the user 
can end up facing non-bootable setup which is also not good, as user is using 
perfectly legal options, and still the whole thing is just rendered unusable…

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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Toomas Soome]

> On 27. jaan 2017, at 19:30, Allan Jude  wrote:
> 
> On 2017-01-27 12:05, Warner Losh wrote:
>> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome > <mailto:tso...@me.com>> wrote:
>>> 
>>>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
>>>>  wrote:
>>>> 
>>>> Hi,
>>>>  I tried upgrading one of my workstations and unfortunately the 
>>>> freebsd-boot partition is too small (I follow manpage directions, exactly, 
>>>> and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
>>>> have enough space or ability to resize the partition and make it bigger. 
>>>> So, I’m in need of a build knob to control the bloat, and/or having an 
>>>> alternative boot loader without geli/skein/crypto support compiled in. 
>>>> Would you be opposed to the work?
>>>> Thanks,
>>>> -Ngie
>>> 
>>> 
>>> I do agree that since the geli knob is already there, it may do. Of course 
>>> we also can think of additional knobs, but there is an issue - it wont help 
>>> just to exclude some files, the additional features also do sit in the 
>>> code, so the replacement stubs will be needed, also testing them all over 
>>> will take some time. And the preprocessor spaghetti really is nasty thing 
>>> to deal with;)
>>> 
>>> And then there is another issue (partly why I did the feature support in 
>>> first place) - as the kernel does not block user from enabling the 
>>> features, the user can end up facing non-bootable setup which is also not 
>>> good, as user is using perfectly legal options, and still the whole thing 
>>> is just rendered unusable…
>> 
>> I'm curious why you can't find the space for a bigger partition?
>> Almost all drives these days are partitioned with a little wasted
>> space, and that wasted space should be more than enough to cover us
>> here. Also, most drives have a swap partition that can be shrunk a
>> trivial amount to get space for this...
>> 
>> Warner
>> 
> 
> I need to do some testing to make a recipe that works for it, but the
> other option is to use the ZFS bootcode area.
> 
> ZFS it self, reserves something like 3.5 mb of space in the ZFS
> partition, for boot code. This is how we boot ZFS on MBR.
> 
> It should be possible to use this on GPT as well, we just don't.
> 
> 

Indeed it is. this is how the illumos is doing, except that what in illumos, we 
use also a bit different boot method - instead of browsing the partition table, 
we record the boot2 start and size in pmbr, and the partition start in 
gptzfsboot, and we always boot based on recorded location - that does simplify 
the boot code in pmbr, but needs install tool, to detect and record the LBA.

And for fbsd case, the bootblock install must be able to distinguish 
geli/non-geli setups, and .. well, there are some complications:)

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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Toomas Soome]

> On 27. jaan 2017, at 22:16, Ngie Cooper  wrote:
> 
> 
>> On Jan 27, 2017, at 09:05, Warner Losh  wrote:
> 
> ...
> 
>> I'm curious why you can't find the space for a bigger partition?
>> Almost all drives these days are partitioned with a little wasted
>> space, and that wasted space should be more than enough to cover us
>> here. Also, most drives have a swap partition that can be shrunk a
>> trivial amount to get space for this...
> 
> Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before 
> the swap partition.
> 
> We have a similar problem at work with sys/boot unfortunately, but that's a 
> side discussion for another time/place.
> 
> Thank you for the idea though -- I'll check when I get back to work.
> 
> -Ngie

Note the order of the partitions is not important, at least on paper anyhow. Of 
course there are preferences in sense that it does look nice if freebsd-boot is 
in front. Also, if you do have mirror setup, it is some work, but you can 
re-arrange mirror side partitioning (with usual cautions like having scrub 
done, having backup, having third disk would be helpful).

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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Toomas Soome]

> On 28. jaan 2017, at 18:56, Warner Losh  wrote:
> 
>> 
>> 
>> at $JOB we are just testing a script that expands the root zfs partition on
>> in-field appliances by shaving a bit off swap and cannibalising a small data
>> partition we don't really use. I see we only left 64K for the boot part.
>> It's big enough for us for now, but possibly we should fix that as well.
>> We have a mirror setup for system disks so we have the ability to take each
>> system drive offline one at a time and rearrange it and then re-add the root
>> partition to the mirror.
>> What are the chances a regular gpt+ZFS (no encrypt) bootblock will grow over
>> 64K?
> 
> Hard to say. Given boot1/boot2 growth over time, I'd peg that close to 100%.
> 
> 


There are few things to consider. First of all, the job of the boot2 is 
actually really small - read out the loader binary by using file system 
specific reader code and start it; and, on bios system, provide quite simple 
prompt for few options. Nothing more, nothing less. So in that sense, it should 
not grow too much.

The problem is, from historical reasons, the boot2 programs are using their own 
personal support functions for IO, and that means that boot loader has some 
duplication of the internal API. Mostly it does not disturb us too much, but 
zfs is complex software and bundling some other features like GELI, does not 
make things more easier. So thats one aspect where the “bloat” is appearing - 
to be able to implement some things, the “thin” implementations are just not 
enough, or some “unexpected” additions are needed.

For the illumos port I actually did something different - I did build one 
single gptzfsboot binary, capable of handling zfs, ufs and pcfs (as those are 
ones needed), and using libstand. Still it does use thin version of keyboard 
input and screen output.

The size of such combined boot2 is (this one is including both skein and edonr):

-r--r--r--   1 root sys   153600 jaan 24 14:08 gptzfsboot

Note, it does not have GELI, so if the same would be done for fbsd, the size 
would be a bit larger because of the crypto functions. But this setup also has 
a bit different strategy;  in case of zfs, the boot2 is *always* installed to 
3.5MB zfs bootblock area and in case of ufs, either boot partition (same idea 
as freebsd-boot) or if the MBR+VTOC schema is used, free space between MBR 
partition and VTOC. Since in most cases the default boot is zfs, it means the 
boot size is not an issue (3.5MB is more than enough;)

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"

review: loader: disk/part api needs to use uint64_t offsets

[Toomas Soome]

Hi!

I would like to have some eyes on https://reviews.freebsd.org/D8710 
 :)

thanks,
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"

review: Implement disk_ioctl() to support DIOCGSECTORSIZE and DIOCGMEDIASIZE.

[Toomas Soome]

Hi!

Looking for more eyes on: https://reviews.freebsd.org/D8594 


thanks,
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: gptzfsboot trouble

[Toomas Soome]

> On 7. veebr 2017, at 18:08, Thomas Sparrevohn 
>  wrote:
> 
> Hi all
> 
> 
> 
> Last week I decided to upgrade my FreeBSD installation - it's been a while
> (September 16 was last time). Unfortunately CURRENT does not boot and cash
> in a weird way. Both 11-RELEASE and 12 CURRENT boot loader seems to attempt
> to read blocks that exceeds the physical disk. Initially I through it was a
> hard disk error - but after a "oh" experience I realised that the
> "gptzfsboot: error 4 lba 921592" is actually beyond the physical boundaries
> of the disk (300GB disk). In order to rule out different options - I
> installed a vanilla 11-RELEASE on the 300G with a simple stripe - it also
> gives the error but does boot - the LBA of the error is slightly different
> on 11 CURRENT and comes up with LBA 921600
> 
> 
> 
> I have scanned all the disks for physical faults and there seems to be none
> and I have tried doing a single disk installation on each disk - they give
> the same error - Does anybody have any idea? Included Photos as sometimes it
> get through to the actual boot menu but then crash in another place
> 


The gptzfsboot does read the backup label from the disk and the GPT backup 
label is stored at the end of the disk. The location of the backup label is in 
the primary GPT table, alternate sector field. I wonder if that location is 
somehow set to bad value…

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: gptzfsboot trouble

[Toomas Soome]

> On 8. veebr 2017, at 14:26, Ronald Klop  wrote:
> 
> On Tue, 07 Feb 2017 17:08:44 +0100, Thomas Sparrevohn 
>  wrote:
> 
>> Hi all
>> 
>> 
>> Last week I decided to upgrade my FreeBSD installation - it's been a while
>> (September 16 was last time). Unfortunately CURRENT does not boot and cash
>> in a weird way. Both 11-RELEASE and 12 CURRENT boot loader seems to attempt
>> to read blocks that exceeds the physical disk. Initially I through it was a
>> hard disk error - but after a "oh" experience I realised that the
>> "gptzfsboot: error 4 lba 921592" is actually beyond the physical boundaries
>> of the disk (300GB disk). In order to rule out different options - I
>> installed a vanilla 11-RELEASE on the 300G with a simple stripe - it also
>> gives the error but does boot - the LBA of the error is slightly different
>> on 11 CURRENT and comes up with LBA 921600
>> 
>> 
>> I have scanned all the disks for physical faults and there seems to be none
>> and I have tried doing a single disk installation on each disk - they give
>> the same error - Does anybody have any idea? Included Photos as sometimes it
>> get through to the actual boot menu but then crash in another place
>> 
>> 
>> I have some images - but they are 2 bit for the mailing list ;-)
> 
> 
> Can it be related to this issue?
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144234
> 
> Would be nice if you tell more about the system. CPU? dmesg?
> The 11-RELEASE did that boot from the same disk? In the mentioned issue there 
> is the case that gptzfsboot does recognize a secondary disk (can be 
> configured as mirror), but not the first.
> 
> As you say UFS works, the bug might be in the gptzfsboot code, because that 
> is not used for UFS.
> 

There is another possible test scenario - to create pool on BSD labeled disk, 
so we can see if it is just about the zfs code itself or rather related to GPT. 
Or vice versa, try ufs on GPT labeled disk.

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: gptzfsboot trouble

[Toomas Soome]

> On 8. veebr 2017, at 14:51, Ronald Klop  wrote:
> 
> On Wed, 08 Feb 2017 13:40:25 +0100, Thomas Sparrevohn 
>  wrote:
> 
>> 
>> The bug in the bugzilla could be related - what is weird is I have been 
>> running this setup for years without issues - which I guess just shows how 
>> good ye'ol FreeBSD still is ;-) Tried to run through the svn log but could 
>> not immediately see anything that seemed to be related
> 
> I was triggered on that bugzilla issue because of the wrong lba number.


I would start from carte blanche.

1. extract/write down the GPT header content;  especially important/interesting 
ones are alternate LBA for backup label location (and therefore the disk end), 
the sector size used by GPT.

2. verify we do get the same sector size used with BIOS  INT13 and if we can 
actually read the last sectors. This one is with catch - it implies some coding 
with gptzfsboot just to try to extract the information, fortunately the BIOS 
interface is simple enough to use and it should not be too hard:)

Based on the results, we can try to figure out what really is happening there 
and why things break down.

One possible hypothesis is: as you wrote, your disk is 3TB; now it *may* be the 
actual BIOS INT13  interface to address higher sectors is just buggy, and it 
just can be so that the zfsloader binary is stored towards the disk end in case 
of zfs and therefore revealing the issue.

Another way to verify this hypothesis is to create separate (smaller) zroot 
partition at the beginning of the disk. Having older system sort of points 
towards the possibility.

Another thing - have you checked for BIOS updates? 

rgds,
toomas


> 
>> Would the photos of the screen help?
> 
> Everything helps.
> NB: please keep the mailinglist in the address list. There are more 
> knowledgeable people there.
> 
> Ronald.
> 
> 
>> -Original Message-
>> From: Ronald Klop [mailto:ronald-li...@klop.ws]
>> Sent: 08 February 2017 12:27
>> To: FreeBSD-current@freebsd.org; Thomas Sparrevohn 
>> 
>> Subject: Re: gptzfsboot trouble
>> 
>> On Tue, 07 Feb 2017 17:08:44 +0100, Thomas Sparrevohn 
>>  wrote:
>> 
>>> Hi all
>>> 
>>> 
>>> Last week I decided to upgrade my FreeBSD installation - it's been a
>>> while (September 16 was last time). Unfortunately CURRENT does not
>>> boot and cash in a weird way. Both 11-RELEASE and 12 CURRENT boot
>>> loader seems to attempt to read blocks that exceeds the physical disk.
>>> Initially I through it was a hard disk error - but after a "oh"
>>> experience I realised that the
>>> "gptzfsboot: error 4 lba 921592" is actually beyond the physical
>>> boundaries of the disk (300GB disk). In order to rule out different
>>> options - I installed a vanilla 11-RELEASE on the 300G with a simple
>>> stripe - it also gives the error but does boot - the LBA of the error
>>> is slightly different on 11 CURRENT and comes up with LBA 921600
>>> 
>>> 
>>> I have scanned all the disks for physical faults and there seems to be
>>> none and I have tried doing a single disk installation on each disk -
>>> they give the same error - Does anybody have any idea? Included Photos
>>> as sometimes it get through to the actual boot menu but then crash in
>>> another place
>>> 
>>> 
>>> I have some images - but they are 2 bit for the mailing list ;-)
>> 
>> 
>> Can it be related to this issue?
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144234
>> 
>> Would be nice if you tell more about the system. CPU? dmesg?
>> The 11-RELEASE did that boot from the same disk? In the mentioned issue 
>> there is the case that gptzfsboot does recognize a secondary disk (can be 
>> configured as mirror), but not the first.
>> 
>> As you say UFS works, the bug might be in the gptzfsboot code, because that 
>> is not used for UFS.
>> 
>> Regards,
>> Ronald.
> ___
> 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: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Toomas Soome]

> On 9. veebr 2017, at 16:36, Karl Denninger  wrote:
> 
> 
> On 2/8/2017 16:18, Karl Denninger wrote:
>> r313441 blows up on the Pi3 in /boot/loader.efi with:
>> 
>> FreeBSD/arm64 EFI loader, Revision 1.1
>> (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net)
>> Failed to start image provided by UFS (14)
>> "Synchronous Abort" handler, esr 0x9604
>> ELR: 3af62cec
>> LR:  3af61d60
>> x0 : 0001 x1 : 0001
>> x2 : 3afeb000 x3 : 003f
>> x4 : 0020 x5 : 0010
>> x6 :  x7 : 39b260a4
>> x8 : 3af61d48 x9 : 000d
>> x10: 0030 x11: 
>> x12:  x13: 0002
>> x14:  x15: 
>> x16:  x17: 
>> x18: 3ab30df8 x19: 37a16008
>> x20:  x21: 
>> x22: 39b28000 x23: 39b1d49c
>> x24: 39b28850 x25: 3ab3d740
>> x26: 3af839a0 x27: 39b2e3e8
>> x28:  x29: 3ab2ef60
>> 
>> Resetting CPU ...
>> 
>> If you copy in a loader.efi from an earlier build (e.g. r313109) then the 
>> system boots but complains about SMP problems, fails to start any of the 
>> other CPUs (although it sees them) and panics before it reaches a login 
>> prompt with what appears to be a problem reading the SD card (I also get a 
>> couple of lor's in here too. not sure if those are "real" or false 
>> positives)
>> 
>> B
> 
> This has been isolated to r31 in sys/boot/efi; reverting the EFI
> loader to a previous revision stops the crash.
> 
> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
> 
> 

Does it still crash with r313442? I think it does and this is why:

From your log above, the hint is "Failed to start image provided by UFS (14)”, 
so what we can guess here is that for some reason the loader.efi main() failed 
to detect the boot device, and did return back to boot1.

Boot1 did print out this error message and did call panic(). So, the question 
is, why it is failing to detect the root fs handle. I’ll try to check if I can 
replicate the issue with x86 + ufs.

BTW: sorry for trouble:)

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: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Toomas Soome]

> On 9. veebr 2017, at 17:05, Karl Denninger  wrote:
> 
> 
> On 2/9/2017 08:58, Toomas Soome wrote:
>>> On 9. veebr 2017, at 16:36, Karl Denninger  
>>> <mailto:k...@denninger.net> wrote:
>>> 
>>> 
>>> On 2/8/2017 16:18, Karl Denninger wrote:
>>>> r313441 blows up on the Pi3 in /boot/loader.efi with:
>>>> 
>>>> FreeBSD/arm64 EFI loader, Revision 1.1
>>>> (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net 
>>>> <mailto:free...@newfs.denninger.net>)
>>>> Failed to start image provided by UFS (14)
>>>> "Synchronous Abort" handler, esr 0x9604
>>>> ELR: 3af62cec
>>>> LR:  3af61d60
>>>> x0 : 0001 x1 : 0001
>>>> x2 : 3afeb000 x3 : 003f
>>>> x4 : 0020 x5 : 0010
>>>> x6 :  x7 : 39b260a4
>>>> x8 : 3af61d48 x9 : 000d
>>>> x10: 0030 x11: 
>>>> x12:  x13: 0002
>>>> x14:  x15: 
>>>> x16:  x17: 
>>>> x18: 3ab30df8 x19: 37a16008
>>>> x20:  x21: 
>>>> x22: 39b28000 x23: 39b1d49c
>>>> x24: 39b28850 x25: 3ab3d740
>>>> x26: 3af839a0 x27: 39b2e3e8
>>>> x28:  x29: 3ab2ef60
>>>> 
>>>> Resetting CPU ...
>>>> 
>>>> If you copy in a loader.efi from an earlier build (e.g. r313109) then the 
>>>> system boots but complains about SMP problems, fails to start any of the 
>>>> other CPUs (although it sees them) and panics before it reaches a login 
>>>> prompt with what appears to be a problem reading the SD card (I also get a 
>>>> couple of lor's in here too. not sure if those are "real" or false 
>>>> positives)
>>>> 
>>>> B
>>> This has been isolated to r31 in sys/boot/efi; reverting the EFI
>>> loader to a previous revision stops the crash.
>>> 
>>> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940> 
>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940> 
>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940>
>>> 
>> Does it still crash with r313442? I think it does and this is why:
>> 
>> From your log above, the hint is "Failed to start image provided by UFS 
>> (14)”, so what we can guess here is that for some reason the loader.efi 
>> main() failed to detect the boot device, and did return back to boot1.
>> 
>> Boot1 did print out this error message and did call panic(). So, the 
>> question is, why it is failing to detect the root fs handle. I’ll try to 
>> check if I can replicate the issue with x86 + ufs.
>> 
>> BTW: sorry for trouble:)
>> 
>> rgds,
>> toomas
>> 
> Yes.
> 
> It's isolated to that particular revision, which appears to have reworked the 
> enumeration of the available devices to boot from.  Reverting only 
> sys/boot/efi to anything before 31 (e.g. "svn update -r 313332 ." in 
> src/sys/boot/efi) and rebuilding results in a loader.efi that successfully 
> loads and starts the kernel.
> 

Well, the x86 version does not appear to have problems with finding the ufs 
devices. So this has to be some sort of corner case related to arm:( 
unfortunately I do not have much variants to test arm, except qemu… so some 
help would be needed there. Since the only crash is from boot1 call to panic, I 
am pretty sure the disk detection and setup was ok, so we should get disk list 
if we insert something like:

for (i = 0; devsw[i] != NULL; i++) {
if (devsw[i]->dv_print != NULL){
if (devsw[i]->dv_print(verbose))
break;
}
}

after dv_init() loop.

If thats true, then it should not take too much to find why we fail to get the 
handle for root fs in case of arm… 

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: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Toomas Soome]

> On 9. veebr 2017, at 23:39, Oleksandr Tymoshenko  wrote:
> 
> Toomas Soome (tso...@me.com) wrote:
>> 
>>> On 9. veebr 2017, at 17:05, Karl Denninger  wrote:
>>> 
>>> 
>>> On 2/9/2017 08:58, Toomas Soome wrote:
>>>>> On 9. veebr 2017, at 16:36, Karl Denninger  
>>>>> <mailto:k...@denninger.net> wrote:
>>>>> 
>>>>> 
>>>>> On 2/8/2017 16:18, Karl Denninger wrote:
>>>>>> r313441 blows up on the Pi3 in /boot/loader.efi with:
>>>>>> 
>>>>>> FreeBSD/arm64 EFI loader, Revision 1.1
>>>>>> (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net 
>>>>>> <mailto:free...@newfs.denninger.net>)
>>>>>> Failed to start image provided by UFS (14)
>>>>>> "Synchronous Abort" handler, esr 0x9604
>>>>>> ELR: 3af62cec
>>>>>> LR:  3af61d60
>>>>>> x0 : 0001 x1 : 0001
>>>>>> x2 : 3afeb000 x3 : 003f
>>>>>> x4 : 0020 x5 : 0010
>>>>>> x6 :  x7 : 39b260a4
>>>>>> x8 : 3af61d48 x9 : 000d
>>>>>> x10: 0030 x11: 
>>>>>> x12:  x13: 0002
>>>>>> x14:  x15: 
>>>>>> x16:  x17: 
>>>>>> x18: 3ab30df8 x19: 37a16008
>>>>>> x20:  x21: 
>>>>>> x22: 39b28000 x23: 39b1d49c
>>>>>> x24: 39b28850 x25: 3ab3d740
>>>>>> x26: 3af839a0 x27: 39b2e3e8
>>>>>> x28:  x29: 3ab2ef60
>>>>>> 
>>>>>> Resetting CPU ...
>>>>>> 
>>>>>> If you copy in a loader.efi from an earlier build (e.g. r313109) then 
>>>>>> the system boots but complains about SMP problems, fails to start any of 
>>>>>> the other CPUs (although it sees them) and panics before it reaches a 
>>>>>> login prompt with what appears to be a problem reading the SD card (I 
>>>>>> also get a couple of lor's in here too. not sure if those are "real" 
>>>>>> or false positives)
>>>>>> 
>>>>>> B
>>>>> This has been isolated to r31 in sys/boot/efi; reverting the EFI
>>>>> loader to a previous revision stops the crash.
>>>>> 
>>>>> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
>>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940> 
>>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940> 
>>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940>
>>>>> 
>>>> Does it still crash with r313442? I think it does and this is why:
>>>> 
>>>> From your log above, the hint is "Failed to start image provided by UFS 
>>>> (14)”, so what we can guess here is that for some reason the loader.efi 
>>>> main() failed to detect the boot device, and did return back to boot1.
>>>> 
>>>> Boot1 did print out this error message and did call panic(). So, the 
>>>> question is, why it is failing to detect the root fs handle. I’ll try to 
>>>> check if I can replicate the issue with x86 + ufs.
>>>> 
>>>> BTW: sorry for trouble:)
>>>> 
>>>> rgds,
>>>> toomas
>>>> 
>>> Yes.
>>> 
>>> It's isolated to that particular revision, which appears to have reworked 
>>> the enumeration of the available devices to boot from.  Reverting only 
>>> sys/boot/efi to anything before 31 (e.g. "svn update -r 313332 ." in 
>>> src/sys/boot/efi) and rebuilding results in a loader.efi that successfully 
>>> loads and starts the kernel.
>>> 
>> 
>> Well, the x86 version does not appear to have problems with finding the ufs 
>> devices. So this has to be some sort of corner case related to arm:( 
>> unfortunately I do not have much variants to test arm, except qemu… so some 
>> help would be needed there. Since the only crash is from boot1 call to 
>> panic, I am pretty sure the disk detection and setup was ok, so we should 

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Toomas Soome]

> On 10. veebr 2017, at 0:10, Oleksandr Tymoshenko  wrote:
> 
> Toomas Soome (tso...@me.com) wrote:
>> 
>>> On 9. veebr 2017, at 23:39, Oleksandr Tymoshenko  wrote:
>>> 
>>> Toomas Soome (tso...@me.com) wrote:
>>>> 
>>>>> On 9. veebr 2017, at 17:05, Karl Denninger  wrote:
>>>>> 
>>>>> 
>>>>> On 2/9/2017 08:58, Toomas Soome wrote:
>>>>>>> On 9. veebr 2017, at 16:36, Karl Denninger  
>>>>>>> <mailto:k...@denninger.net> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> On 2/8/2017 16:18, Karl Denninger wrote:
>>>>>>>> r313441 blows up on the Pi3 in /boot/loader.efi with:
>>>>>>>> 
>>>>>>>> FreeBSD/arm64 EFI loader, Revision 1.1
>>>>>>>> (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net 
>>>>>>>> <mailto:free...@newfs.denninger.net>)
>>>>>>>> Failed to start image provided by UFS (14)
>>>>>>>> "Synchronous Abort" handler, esr 0x9604
>>>>>>>> ELR: 3af62cec
>>>>>>>> LR:  3af61d60
>>>>>>>> x0 : 0001 x1 : 0001
>>>>>>>> x2 : 3afeb000 x3 : 003f
>>>>>>>> x4 : 0020 x5 : 0010
>>>>>>>> x6 :  x7 : 39b260a4
>>>>>>>> x8 : 3af61d48 x9 : 000d
>>>>>>>> x10: 0030 x11: 
>>>>>>>> x12:  x13: 0002
>>>>>>>> x14:  x15: 
>>>>>>>> x16:  x17: 
>>>>>>>> x18: 3ab30df8 x19: 37a16008
>>>>>>>> x20:  x21: 
>>>>>>>> x22: 39b28000 x23: 39b1d49c
>>>>>>>> x24: 39b28850 x25: 3ab3d740
>>>>>>>> x26: 3af839a0 x27: 39b2e3e8
>>>>>>>> x28:  x29: 3ab2ef60
>>>>>>>> 
>>>>>>>> Resetting CPU ...
>>>>>>>> 
>>>>>>>> If you copy in a loader.efi from an earlier build (e.g. r313109) then 
>>>>>>>> the system boots but complains about SMP problems, fails to start any 
>>>>>>>> of the other CPUs (although it sees them) and panics before it reaches 
>>>>>>>> a login prompt with what appears to be a problem reading the SD card 
>>>>>>>> (I also get a couple of lor's in here too. not sure if those are 
>>>>>>>> "real" or false positives)
>>>>>>>> 
>>>>>>>> B
>>>>>>> This has been isolated to r31 in sys/boot/efi; reverting the EFI
>>>>>>> loader to a previous revision stops the crash.
>>>>>>> 
>>>>>>> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
>>>>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940> 
>>>>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940> 
>>>>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940>
>>>>>>> 
>>>>>> Does it still crash with r313442? I think it does and this is why:
>>>>>> 
>>>>>> From your log above, the hint is "Failed to start image provided by UFS 
>>>>>> (14)”, so what we can guess here is that for some reason the loader.efi 
>>>>>> main() failed to detect the boot device, and did return back to boot1.
>>>>>> 
>>>>>> Boot1 did print out this error message and did call panic(). So, the 
>>>>>> question is, why it is failing to detect the root fs handle. I’ll try to 
>>>>>> check if I can replicate the issue with x86 + ufs.
>>>>>> 
>>>>>> BTW: sorry for trouble:)
>>>>>> 
>>>>>> rgds,
>>>>>> toomas
>>>>>> 
>>>>> Yes.
>>>>> 
>>>>> It's isolated to that particular revision, which appears to have reworked 
>>>>> the enumeration of

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Toomas Soome]

>> 
>> From reading U-Boot sources (lib/efi_loader/efi_disk.c) it looks like
>> names are in the form of typeN:M, where type is interface type,
>> N is disk id and M is partition id. So 3 disks in my setup
>> may be mmc0, mmc0:1, mmc0:2. 
>> 
>> -- 
>> gonzo
> 
> Okay, so in case of arm or MEDIA_FILEPATH_DP we need to keep the initial disk 
> handle till there is an disk switch, and use it as first argument for 
> registering the disk. So the name in last node is probably the same format 
> and we can identify the disk this way. Worth to check in any case:)
> 


Based on current knowledge, I did put together the first sketch of the fix:

https://reviews.freebsd.org/D9520

However, it needs to be tested on arm, so I do ask help there:)

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: two recent snapshot installer problems

[Toomas Soome]

> On 7. märts 2017, at 21:05, Michael W. Lucas  
> wrote:
> 
> Hi,
> 
> I want to open a bug report on this, but have no idea how to gather
> useful info.
> 
> Attempting to install
> FreeBSD-12.0-CURRENT-amd64-20170301-r314495-memstick.img onto an
> eight-drive iX system. This machine previously ran -current, but the
> OS has been sadly used by book testing and I decided to do a clean
> install.
> 
> Used the Guided ZFS install, no networking, no extra users, default
> security. 
> 
> I want a two-way mirror for the base install, and the BIOS didn't
> provide serial numbers for each disk, so I wound up doing multiple
> installs, thinking that once I installed to the disk that the BIOS
> expected to be a boot disk, it'd find the pool and boot.
> 
> Each of the four installs failed to boot, giving me:
> 
> gptzfsboot: error 1 lba 32
> error 1
> gptzfsboot: error 1 lba 4294967288
> gptzfsboot: error 1 lba 1
> gptzfsboot: No ZFS pools located, can't boot


The messages are from low level disk IO, INT13.

if (V86_CY(v86.efl)) {
printf("%s: error %u lba %u\n",
BOOTPROG, v86.eax >> 8 & 0xff, lba);
return (-1);
}

So the error 1 is:

01h Invalid Command

Which means the INT13 AX=0x4200  is not supported by this BIOS. So, the 
question is, does your HBA is set in bios to IDE or AHCI mode? Changing that  
may make an difference, also usual suggestion - check for bios update, and if 
the host supports it, check the uefi boot… Of course, the fact that it did run 
fbsd before, points towards bios settings change...

the invalid command from INT13 extended read is by itself quite odd, but there 
is also possible another reason - if by any reason somehow the memory buffer 
for this call is from memory above 640k and so the invalid memory area was 
provided…

rgds,
toomas


> 
> Old disklabels? gpart -F destroy da0 through ada3. and
> reinstall. Nope.
> 
> In frustration I did an eight-disk mirror install. Got the same
> message.
> 
> Fine, I'll install to the Intel RAID satadom. It's a raid config, but
> it'll get me a working system. Select a ZFS stripe on raid/r0.
> 
> gpart: arg0 'raid/r0': Invalid argument
> 
> Mirror on the individual satadom drives?
> 
> Same boot message.
> 
> Any suggestions on how to gather debugging info for this?
> 
> Thanks,
> ==ml
> 
> 
> -- 
> Michael W. LucasTwitter @mwlauthor 
> nonfiction: https://www.michaelwlucas.com/
> fiction: https://www.michaelwarrenlucas.com/
> blog: http://blather.michaelwlucas.com/
> ___
> 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

[Toomas Soome]

> 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

[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, &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"

NFSv2 boot & OLD_NFSV2

[Toomas Soome]

Hi!

The current boot code is building NFSv3, with preprocessor conditional 
OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?

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: NFSv2 boot & OLD_NFSV2

[Toomas Soome]

> On 20. märts 2017, at 23:53, Rick Macklem  wrote:
> 
> Baptiste Daroussin wrote:
>> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote:
>>> Hi!
>>> 
>>> The current boot code is building NFSv3, with preprocessor conditional 
>>> OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?
>>> 
>>> rgds,
>>> toomas
>> 
>> I vote burn
>> 
>> Bapt
> I would be happy to see NFSv2 go away. However, depending on how people 
> configure
> their diskless root fs, they do end up using NFSv2 for their root fs.
> 
> Does booting over NFSv3 affect this?
> 
> I think the answer is no for a FreeBSD server (since the NFSv2 File Handle is 
> the same as
> the NFSv3 one, except padded with 0 bytes to 32bytes long).
> However, there might be non-FreeBSD NFS servers where the NFSv2 file handle 
> is different
> than the NFSv3 one and for that case, the user would need NFSv2 boot code (or
> reconfigure their root fs to use NFSv3).
> 
> To be honest, I suspect few realize that they are using NFSv2 for their root 
> fs.
> (They'd see it in a packet trace or via "nfsstat -m", but otherwise they 
> probably
>  think they are using NFSv3 for their root fs.)
> 
> rick

if they do not suspect, they most likely use v3 - due to simple fact that you 
have to rebuild loader to use NFSv2 - it is compile time option.

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: Are textmode consoles/terminals still supported?

[Toomas Soome]

> On 20. märts 2017, at 23:58, Chris H  wrote:
> 
> I'm attempting to get a video card that DTRT on FreeBSD.
> I started with the graphics provided by an AMD A6-7470K,
> only to discover it's not yet supported. So I forked out
> for a recent nvidia card, and build/installed a new
> world/kernel.
> Everything seemed to be as one would expect, except there
> was an issue with loader.efi. So I had to move mine aside,
> and use the one off the install media (tho I understand
> the (u)efi has since been fixed). Now, I'm attempting to
> obtain textmode. The text stripped from a tty, and pasted
> to a new file in a textmode editor -- ee(1) for example;
> pads the line with spaces to EOL, and prefaces each line
> following the first line with rubbish (about 1 to 2
> characters worth).
> So "graphics mode" or vt(4) isn't going to get it, for me.
> Textmode, and syscons(4) has always worked as expected, and
> I thought I'd try to re-enable it, or get textmode via vt(4).
> But all attempts fail.
> excerpt from my KERNCONF
> 
> devicevga
> options   VESA
> 
> devicesc
> options   SC_PIXEL_MODE
> 
> devicevt
> devicevt_vga
> devicevt_efifb
> 
> However, following the advice on the freebsd wiki, querying
> the value in sysctl(8) returns:
> # sysctl hw.vga.textmode
> sysctl: unknown oid 'hw.vga.textmode'
> 
> OK how bout vidcontrol(1)
> # vidcontrol -i adapter
> vidcontrol: obtaining adapter information: Inappropriate ioctl for device
> 
> So, it appears from my standpoint that textmode is no longer
> supported?
> 
> FWIW:
> FreeBSD trump.whitehouse.gov.test 12.0-CURRENT FreeBSD 12.0-CURRENT #0 
> r314700:
> Sun Mar 5 09:01:30 PST 2017
> r...@trump.whitehouse.gov.test:/usr/obj/usr/src/sys/TESTKERN amd6
> 
> Thank you for anything that might help me obtain textmode again.
> 
> -

The problem with UEFI is that the fact if you can only get “text” aka VGA text 
mode if your card happens to have the proper firmware and you can set up the 
card… UEFI as such does only provide framebuffer based console, and that 
framebuffer is either linear memory mapped or pure software - in last case only 
KMS console framebuffer will do any good.

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: NFSv2 boot & OLD_NFSV2

[Toomas Soome]

> On 21. märts 2017, at 10:13, Baptiste Daroussin  wrote:
> 
> On Tue, Mar 21, 2017 at 09:58:21AM +0200, Daniel Braniss wrote:
>> 
>>> On 20 Mar 2017, at 23:55, Toomas Soome  wrote:
>>> 
>>>> 
>>>> On 20. märts 2017, at 23:53, Rick Macklem  wrote:
>>>> 
>>>> Baptiste Daroussin wrote:
>>>>> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote:
>>>>>> Hi!
>>>>>> 
>>>>>> The current boot code is building NFSv3, with preprocessor conditional 
>>>>>> OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?
>>>>>> 
>>>>>> rgds,
>>>>>> toomas
>>>>> 
>>>>> I vote burn
>>>>> 
>>>>> Bapt
>>>> I would be happy to see NFSv2 go away. However, depending on how people 
>>>> configure
>>>> their diskless root fs, they do end up using NFSv2 for their root fs.
>>>> 
>>>> Does booting over NFSv3 affect this?
>>>> 
>>>> I think the answer is no for a FreeBSD server (since the NFSv2 File Handle 
>>>> is the same as
>>>> the NFSv3 one, except padded with 0 bytes to 32bytes long).
>>>> However, there might be non-FreeBSD NFS servers where the NFSv2 file 
>>>> handle is different
>>>> than the NFSv3 one and for that case, the user would need NFSv2 boot code 
>>>> (or
>>>> reconfigure their root fs to use NFSv3).
>>>> 
>>>> To be honest, I suspect few realize that they are using NFSv2 for their 
>>>> root fs.
>>>> (They'd see it in a packet trace or via "nfsstat -m", but otherwise they 
>>>> probably
>>>> think they are using NFSv3 for their root fs.)
>>>> 
>>>> rick
>>> 
>>> if they do not suspect, they most likely use v3 - due to simple fact that 
>>> you have to rebuild loader to use NFSv2 - it is compile time option.
>>> 
>> 
>> old systems, 8.x, still use/boot v2, and so do old linux.
>> NetApp has discontinued support for v2, so we had to move this machines to 
>> use FreeBSD server and the day was
>> saved. So, till these machines get upgraded/discontinued we have a problem. 
>> There are several solutions
>> to this issue, but as long as it's a matter of getting rid for the sake of 
>> it, I would vote to keep it a while longer.
>> 
>> danny
>> 
>> 
> Given you are speaking of 8.x I suppose you are using the loader that comes 
> with
> it, meaning you are safe if we remove it from the loader in 12.0 (note as said
> by Toomas that is it is already off by default in the 12.0 loader) am I 
> missing
> something?
> 
> 


Indeed, we definitely are *not* talking about back porting the removal, there 
is no reason for that whatsoever. In fact at least 11 is distributing loader 
based on NFSv3, likely even 10 (I havent checked that). So yes, just talking 
about possible removal in current only.

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: NFSv2 boot & OLD_NFSV2

[Toomas Soome]

> On 21. märts 2017, at 10:50, Daniel Braniss  wrote:
> 
> 
>> On 21 Mar 2017, at 10:13, Baptiste Daroussin > <mailto:b...@freebsd.org>> wrote:
>> 
>> On Tue, Mar 21, 2017 at 09:58:21AM +0200, Daniel Braniss wrote:
>>> 
>>>> On 20 Mar 2017, at 23:55, Toomas Soome >>> <mailto:tso...@me.com>> wrote:
>>>> 
>>>>> 
>>>>> On 20. märts 2017, at 23:53, Rick Macklem >>>> <mailto:rmack...@uoguelph.ca>> wrote:
>>>>> 
>>>>> Baptiste Daroussin wrote:
>>>>>> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote:
>>>>>>> Hi!
>>>>>>> 
>>>>>>> The current boot code is building NFSv3, with preprocessor conditional 
>>>>>>> OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?
>>>>>>> 
>>>>>>> rgds,
>>>>>>> toomas
>>>>>> 
>>>>>> I vote burn
>>>>>> 
>>>>>> Bapt
>>>>> I would be happy to see NFSv2 go away. However, depending on how people 
>>>>> configure
>>>>> their diskless root fs, they do end up using NFSv2 for their root fs.
>>>>> 
>>>>> Does booting over NFSv3 affect this?
>>>>> 
>>>>> I think the answer is no for a FreeBSD server (since the NFSv2 File 
>>>>> Handle is the same as
>>>>> the NFSv3 one, except padded with 0 bytes to 32bytes long).
>>>>> However, there might be non-FreeBSD NFS servers where the NFSv2 file 
>>>>> handle is different
>>>>> than the NFSv3 one and for that case, the user would need NFSv2 boot code 
>>>>> (or
>>>>> reconfigure their root fs to use NFSv3).
>>>>> 
>>>>> To be honest, I suspect few realize that they are using NFSv2 for their 
>>>>> root fs.
>>>>> (They'd see it in a packet trace or via "nfsstat -m", but otherwise they 
>>>>> probably
>>>>> think they are using NFSv3 for their root fs.)
>>>>> 
>>>>> rick
>>>> 
>>>> if they do not suspect, they most likely use v3 - due to simple fact that 
>>>> you have to rebuild loader to use NFSv2 - it is compile time option.
>>>> 
>>> 
>>> old systems, 8.x, still use/boot v2, and so do old linux.
>>> NetApp has discontinued support for v2, so we had to move this machines to 
>>> use FreeBSD server and the day was
>>> saved. So, till these machines get upgraded/discontinued we have a problem. 
>>> There are several solutions
>>> to this issue, but as long as it's a matter of getting rid for the sake of 
>>> it, I would vote to keep it a while longer.
>>> 
>>> danny
>>> 
>>> 
>> Given you are speaking of 8.x I suppose you are using the loader that comes 
>> with
>> it, meaning you are safe if we remove it from the loader in 12.0 (note as 
>> said
>> by Toomas that is it is already off by default in the 12.0 loader) am I 
>> missing
>> something?
>> 
> 
> as usual, did not read the whole thread, I assumed - wrongly - that support 
> for v2 would be discontinued.
> removing v2 support from the boot process is fine! great, go for it. It will 
> only involve newer
> hosts, and simplifying the boot process is always a good idea.
> 
> sorry for the noise.
>   danny
> 


yes, just to clarify,  the current loader code (in current), is having NFS code 
implemented as:

#ifdef OLD_NFSV2

v2 implementation is here

#else

v3 implementation is here

#endif

Which does mean that pxeboot/loader.efi is built by default to use v3 only, but 
we do have 2 parallel implementations of the NFS readers. And yes, the question 
is just about boot loader reader code (we do not implement NFS writes) - and we 
are *not* talking about server side there.

Indeed it also is possible to merge those 2 version implementations, but to be 
honest, I see very little point of doing that either, even if there is some 
setup still with v2 only server, there is still an option just to use TFTP 
based boot - especially given that current boot loader does provide parallel 
option to use either NFS or TFTP (via dhcp option 150), with existing binaries 
- that is, without having to re-compile.

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: NFSv2 boot & OLD_NFSV2

[Toomas Soome]

> On 26. märts 2017, at 23:00, Rick Macklem  wrote:
> 
> Just in case it wasn't clear, I think this is a good idea and I think
> you have a handle on any potential problems.
> 
> Good luck with it, rick

aye, thanks, just wanted to give people some time to react. And got some stupid 
cold meanwhile:D

rgds,
toomas

> ________
> From: Toomas Soome mailto:tso...@me.com>>
> Sent: Tuesday, March 21, 2017 5:04:59 AM
> To: Daniel Braniss
> Cc: Baptiste Daroussin; Rick Macklem; FreeBSD Current
> Subject: Re: NFSv2 boot & OLD_NFSV2
> 
> On 21. märts 2017, at 10:50, Daniel Braniss  <mailto:da...@cs.huji.ac.il><mailto:da...@cs.huji.ac.il 
> <mailto:da...@cs.huji.ac.il>>> wrote:
> 
> 
> On 21 Mar 2017, at 10:13, Baptiste Daroussin  <mailto:b...@freebsd.org><mailto:b...@freebsd.org <mailto:b...@freebsd.org>>> 
> wrote:
> 
> On Tue, Mar 21, 2017 at 09:58:21AM +0200, Daniel Braniss wrote:
> 
> On 20 Mar 2017, at 23:55, Toomas Soome  <mailto:tso...@me.com><mailto:tso...@me.com <mailto:tso...@me.com>>> wrote:
> 
> 
> On 20. märts 2017, at 23:53, Rick Macklem  <mailto:rmack...@uoguelph.ca><mailto:rmack...@uoguelph.ca 
> <mailto:rmack...@uoguelph.ca>>> wrote:
> 
> Baptiste Daroussin wrote:
> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote:
> Hi!
> 
> The current boot code is building NFSv3, with preprocessor conditional 
> OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?
> 
> rgds,
> toomas
> 
> I vote burn
> 
> Bapt
> I would be happy to see NFSv2 go away. However, depending on how people 
> configure
> their diskless root fs, they do end up using NFSv2 for their root fs.
> 
> Does booting over NFSv3 affect this?
> 
> I think the answer is no for a FreeBSD server (since the NFSv2 File Handle is 
> the same as
> the NFSv3 one, except padded with 0 bytes to 32bytes long).
> However, there might be non-FreeBSD NFS servers where the NFSv2 file handle 
> is different
> than the NFSv3 one and for that case, the user would need NFSv2 boot code (or
> reconfigure their root fs to use NFSv3).
> 
> To be honest, I suspect few realize that they are using NFSv2 for their root 
> fs.
> (They'd see it in a packet trace or via "nfsstat -m", but otherwise they 
> probably
> think they are using NFSv3 for their root fs.)
> 
> rick
> 
> if they do not suspect, they most likely use v3 - due to simple fact that you 
> have to rebuild loader to use NFSv2 - it is compile time option.
> 
> 
> old systems, 8.x, still use/boot v2, and so do old linux.
> NetApp has discontinued support for v2, so we had to move this machines to 
> use FreeBSD server and the day was
> saved. So, till these machines get upgraded/discontinued we have a problem. 
> There are several solutions
> to this issue, but as long as it's a matter of getting rid for the sake of 
> it, I would vote to keep it a while longer.
> 
> danny
> 
> 
> Given you are speaking of 8.x I suppose you are using the loader that comes 
> with
> it, meaning you are safe if we remove it from the loader in 12.0 (note as said
> by Toomas that is it is already off by default in the 12.0 loader) am I 
> missing
> something?
> 
> 
> as usual, did not read the whole thread, I assumed - wrongly - that support 
> for v2 would be discontinued.
> removing v2 support from the boot process is fine! great, go for it. It will 
> only involve newer
> hosts, and simplifying the boot process is always a good idea.
> 
> sorry for the noise.
> danny
> 
> 
> 
> yes, just to clarify,  the current loader code (in current), is having NFS 
> code implemented as:
> 
> #ifdef OLD_NFSV2
> 
> v2 implementation is here
> 
> #else
> 
> v3 implementation is here
> 
> #endif
> 
> Which does mean that pxeboot/loader.efi is built by default to use v3 only, 
> but we do have 2 parallel implementations of the NFS readers. And yes, the 
> question is just about boot loader reader code (we do not implement NFS 
> writes) - and we are *not* talking about server side there.
> 
> Indeed it also is possible to merge those 2 version implementations, but to 
> be honest, I see very little point of doing that either, even if there is 
> some setup still with v2 only server, there is still an option just to use 
> TFTP based boot - especially given that current boot loader does provide 
> parallel option to use either NFS or TFTP (via dhcp option 150), with 
> existing binaries - that is, without having to re-compile.
> 
> rgds,
> toomas
> 
> ___

D10203: loader: zfs reader should check all labels

[Toomas Soome]

Hi!

Sorry about forward, but this patch is something a bit more complicated and if 
we have some people willing to test, it would be really nice:) I have had it 
around for my illumos port for some time now, but those small details about the 
zfsboot/gptzfsboot etc sometimes do count a lot… 

thanks,
toomas

> Begin forwarded message:
> 
> From: "tsoome (Toomas Soome)" 
> Subject: [Differential] D10203: loader: zfs reader should check all labels
> Date: 30. märts 2017 18:39.44 GMT+3
> To: tso...@me.com
> Reply-To: d10203+574+d76c8a36ba3c3...@reviews.freebsd.org
> 
> tsoome created this revision.
> Herald added a subscriber: delphij.
> 
> REVISION SUMMARY
>  The current zfs reader is only checking first label from each device, 
> however,
>  we do have 4 labels on device and we should check all 4 to be protected
>  against disk failures and incomplete label updates.
> 
>  The difficulty is about the fact that 2 label copies are in front of the
>  pool data, and 2 are at the end, which means, we have to know the size of
>  the pool data area.
> 
>  Since we have now the mechanism from common/disk.c to use the partition
>  information, it does help us in this task; however, there are still some
>  corner cases.
> 
>  Namely, if the pool is created without partition, directly on the disk,
>  and firmware will give us the wrong size for the disk, we only can check
>  the first two label copies.
> 
> REPOSITORY
>  rS FreeBSD src repository
> 
> REVISION DETAIL
>  https://reviews.freebsd.org/D10203
> 
> AFFECTED FILES
>  sys/boot/efi/boot1/zfs_module.c
>  sys/boot/efi/loader/main.c
>  sys/boot/i386/common/drv.h
>  sys/boot/i386/loader/main.c
>  sys/boot/i386/zfsboot/zfsboot.c
>  sys/boot/zfs/libzfs.h
>  sys/boot/zfs/zfsimpl.c
> 
> EMAIL PREFERENCES
>  https://reviews.freebsd.org/settings/panel/emailpreferences/
> 
> To: tsoome, allanjude, imp, avg
> Cc: delphij

___
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: problem with ls, not show a correct list

[Toomas Soome]

> On 7. apr 2017, at 11:29, Andrey Chernov  wrote:
> 
>>  Hi Allan, the ls show all files without case match
>> 
>> ls [a-z]*
>> 
>> show all files beginning with a and A  like this [aA-zZ]*
> 
> No, last "Z" is not included.
> 

This is to define set of chars: { a, A-z, Z } ? A-z of course does not make any 
sense;) Of course note that in few locales z is sorted after s, meaning that 
list like that can be rather short;)

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: r316677:EFI boot failure: Can't load kernel

[Toomas Soome]

> On 10. apr 2017, at 15:58, Hartmann, O.  wrote:
> 
> After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740
> XEON) reject to boot properly. They die immediately after
> loading /boot/loader.efi and jump into loader prompt:
> 
> [...]
> \
> can't load 'kernel'
> 
> 
> I had to investigate with an USB flashdrive the filesystem, but
> everything seems to be properly in place and installed.
> 
> I need advice how to revive the system after this.
> 


hm, this implies that r316676 was ok? If so, the only logical conclusion is 
that it hast to do about the kernel size and if there is enough space in UEFI 
memory to place the kernel.

You can fetch the current memory map from loader OK prompt with memmap command, 
I hope this will help to identify the issue.

rgds,
toomas

___
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: r316677:EFI boot failure: Can't load kernel

[Toomas Soome]

> On 10. apr 2017, at 21:04, O. Hartmann  wrote:
> 
> Am Mon, 10 Apr 2017 16:14:21 +0300
> Toomas Soome  schrieb:
> 
>>> On 10. apr 2017, at 15:58, Hartmann, O.  wrote:
>>> 
>>> After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740
>>> XEON) reject to boot properly. They die immediately after
>>> loading /boot/loader.efi and jump into loader prompt:
>>> 
>>> [...]
>>> \
>>> can't load 'kernel'
>>> 
>>> 
>>> I had to investigate with an USB flashdrive the filesystem, but
>>> everything seems to be properly in place and installed.
>>> 
>>> I need advice how to revive the system after this.
>>> 
>> 
>> 
>> hm, this implies that r316676 was ok? If so, the only logical conclusion is 
>> that it
>> hast to do about the kernel size and if there is enough space in UEFI memory 
>> to place
>> the kernel.
>> 
>> You can fetch the current memory map from loader OK prompt with memmap 
>> command, I hope
>> this will help to identify the issue.
>> 
>> rgds,
>> toomas
> 
> 
> And?
> 
> Regrads,
> 
> oh
> 

Well, the memory needed is starting from the:

#define KERNEL_PHYSICAL_BASE (2*1024*1024)

and it should be large enough for kernel. But it feels a bit like barking under 
the random tree; the problem is that the error is not telling us anything why 
it did happen:(

This message you get is coming from sys/boot/common/boot.c, as part of the 
autoload sequence; did you try to load kernel manually with load command? also 
if you have old kernel around, does old kernel get loaded?

rgds,
toomas




___
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: r316677:EFI boot failure: Can't load kernel

[Toomas Soome]

> On 11. apr 2017, at 17:42, Masachika ISHIZUKA  wrote:
> 
>> replaced /boot/loader with /boot/loader.old (which was from end of
>> March)
>> 
>> copied /boot/loader.efi from the r315864 snapshot USB image
>> into /boot/loader.efi of the broken systems.
>> 
>> Aprt from the fact that I don't know which one is broken, the boxes are
>> booting again.
>> 
>> Conclusion: UEFI loader is broken!
> 
>  Hi.
> 
>  I'm using dell xps12 9q33 (core i7-4500U) with an internal SSD.
>  As reporting Bug 218473, I cannot boot /boot/loader.efi after
> r316585.  Replacing only loader.efi before r316584, I can boot
> again.
> -- 
> Masachika ISHIZUKA


Yea, it seems to be the same issue for both of you, now have some work to do to 
identify why this does happen.

from loader prompt the lsdev -v output would be helpful - you can send it 
directly, we do not need to spam the list:)

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: r316677:EFI boot failure: Can't load kernel

[Toomas Soome]

> On 12. apr 2017, at 22:48, Chris H  wrote:
> 
> On Tue, 11 Apr 2017 23:42:52 +0900 (JST) Masachika ISHIZUKA
> mailto:i...@amail.plala.or.jp>> wrote
> 
>>> replaced /boot/loader with /boot/loader.old (which was from end of
>>> March)
>>> 
>>> copied /boot/loader.efi from the r315864 snapshot USB image
>>> into /boot/loader.efi of the broken systems.
>>> 
>>> Aprt from the fact that I don't know which one is broken, the boxes are
>>> booting again.
>>> 
>>> Conclusion: UEFI loader is broken!
>> 
>>  Hi.
>> 
>>  I'm using dell xps12 9q33 (core i7-4500U) with an internal SSD.
>>  As reporting Bug 218473, I cannot boot /boot/loader.efi after
>> r316585.  Replacing only loader.efi before r316584, I can boot
>> again.
> 
> I was going to also report similar findings.
> After reporting the problem && submitting additional info to help
> diagnose the situation.
> I found that the most efficient way to overcome the issue, was to
> move loader.efi aside, and copy loader.efi from the install DVD.
> I've since lowered the priority of (u)efi in the BIOS, taking
> legacy as the higher priority. Because I had additional problems
> with vt. In the end, I find I have no issues simply booting to
> syscons(4) -- Xorg even works more harmoniously with it. :-)
> 

We have progress with investigation, but testing has to confirm if the suspect 
is really it or not.

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: r316677:EFI boot failure: Can't load kernel

[Toomas Soome]

> On 12. apr 2017, at 22:48, Chris H  wrote:
> 
> On Tue, 11 Apr 2017 23:42:52 +0900 (JST) Masachika ISHIZUKA
> mailto:i...@amail.plala.or.jp>> wrote
> 
>>> replaced /boot/loader with /boot/loader.old (which was from end of
>>> March)
>>> 
>>> copied /boot/loader.efi from the r315864 snapshot USB image
>>> into /boot/loader.efi of the broken systems.
>>> 
>>> Aprt from the fact that I don't know which one is broken, the boxes are
>>> booting again.
>>> 
>>> Conclusion: UEFI loader is broken!
>> 
>>  Hi.
>> 
>>  I'm using dell xps12 9q33 (core i7-4500U) with an internal SSD.
>>  As reporting Bug 218473, I cannot boot /boot/loader.efi after
>> r316585.  Replacing only loader.efi before r316584, I can boot
>> again.
> 
> I was going to also report similar findings.
> After reporting the problem && submitting additional info to help
> diagnose the situation.
> I found that the most efficient way to overcome the issue, was to
> move loader.efi aside, and copy loader.efi from the install DVD.
> I've since lowered the priority of (u)efi in the BIOS, taking
> legacy as the higher priority. Because I had additional problems
> with vt. In the end, I find I have no issues simply booting to
> syscons(4) -- Xorg even works more harmoniously with it. :-)
> 

I believe we did identify the problem, the fix is posted as 
https://reviews.freebsd.org/D10381  please 
review, if you can confirm the fix by testing, it would also be really helpful 
- the issue is, the problem appears to be system specific and not always 
manifesting itself.

thanks,
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"

https://reviews.freebsd.org/D10232

[Toomas Soome]

Hi!

The network code rework still needs good people to test out the work, 
especially the non-x86 platforms:)  the url is still: 
https://reviews.freebsd.org/D10232

Once it checks out, we can go for next phase and get some boost for network 
loading.

thanks,
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: old snapshot install images?

[Toomas Soome]

> On 3. mai 2017, at 19:52, Ngie Cooper  wrote:
> 
> 
>> On May 3, 2017, at 09:41, Michael W. Lucas  wrote:
>> 
>>> On Wed, May 03, 2017 at 09:37:04AM -0700, Ngie Cooper (yaneurabeya) wrote:
>>> Ok. I was curious because there has been a period of time when 512b/sector 
>>> disks have been broken and vice versa.
>>> 
>>> I’m going to operate under the impression that one of tsoome’s recent 
>>> changes to zfsboot fixed things (there was some breakage over the past 
>>> couple months based on posts to current@ and svn-src-*@), but I can’t count 
>>> on it 100%.
>> 
>> 
>> The most recent installer snapshot has the exact same problem.
>> 
>> Every installer snapshot on the FTP site has the exact same problem.
>> 
>> I've gotten some installer snapshots from October and from
>> mid-2015. Trying those.
>> 
>> My goal is to find out when the problem appeared and include the time
>> window in the PR.
> 
> Ok. How big is your freebsd-boot partition?
> Thanks,
> -Ngie


There was many issues fixed step by step and some fixes for particular problem 
did reveal next one (at least in some systems), and indeed, it can cause some 
problems if you are caught in middle of updates. From my point of view, the 
most important question is if the current “current” is ok:)

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: old snapshot install images?

[Toomas Soome]

> On 3. mai 2017, at 21:06, Michael W. Lucas  wrote:
> 
> On Wed, May 03, 2017 at 08:03:21PM +0300, Toomas Soome wrote:
>> There was many issues fixed step by step and some fixes for particular 
>> problem did reveal next one (at least in some systems), and indeed, it can 
>> cause some problems if you are caught in middle of updates. From my point of 
>> view, the most important question is if the current “current” is ok:)
> 
> 
> Agreed 500%.
> 
> The latest snapshot is NOT ok.
> 

What is the error there?

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"