Re: When will the FreeBSD (u)EFI work?
On Sun, Mar 29, 2020 at 9:44 PM Simon J. Gerraty wrote: > Warner Losh wrote: > > True, but as we move from boot1.efi to loader.efi, the need will > > grow... Even if we keep boot1.efi, loader.efi will be needed for > > interesting secure systems, so we can't cop-out like we have in the > > past. > > Sigh, that would force me to have to add verification to boot1.efi ;-) > > Personally I'm quite happy with installing loader.efi as bootx64.efi > to avoid that. > Yea. That's why we really want to move in this direction > I treat it as a separately published component, independent of the > loaders used on non-uefi platforms. So the fact that I have to build it > from head, matters little. > > The loader should be largely independent of the rest of the system, and > was until lua came along. Eg we can successfully verify and load a > stable/6 based system using loader built from stable/11. > For at least some platforms we cannot use lua, as it takes up headroom > we need for verifying modules. > I think the Forth loader can still load old kernel binaries, at least back to the ELF cut-over, though the Forth words have changed a bit over time, so there may be some issues there... Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: When will the FreeBSD (u)EFI work?
Warner Losh wrote: > True, but as we move from boot1.efi to loader.efi, the need will > grow... Even if we keep boot1.efi, loader.efi will be needed for > interesting secure systems, so we can't cop-out like we have in the > past. Sigh, that would force me to have to add verification to boot1.efi ;-) Personally I'm quite happy with installing loader.efi as bootx64.efi to avoid that. I treat it as a separately published component, independent of the loaders used on non-uefi platforms. So the fact that I have to build it from head, matters little. The loader should be largely independent of the rest of the system, and was until lua came along. Eg we can successfully verify and load a stable/6 based system using loader built from stable/11. For at least some platforms we cannot use lua, as it takes up headroom we need for verifying modules. ___ 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: kernel build failed
29.03.20 14:55, Dimitry Andric пишет: On 29 Mar 2020, at 13:02, Alexandr Krivulya wrote: 28.03.20 18:32, Dimitry Andric пишет: On 28 Mar 2020, at 13:48, Alexandr Krivulya wrote: ... This typically happens if you don't run "make buildworld", or at least "make kernel-toolchain" before running "make buildkernel", and your userland is missing those headers, for some reason. (Usually people seem to do a WITHOUT_CLANG installation or strip out 'unnecessary' stuff manually...) I have updated source tree to r359419 and now make builworld failed with an error: --- Basic/Targets.o --- c++ -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm -I/usr/src/contrib/llvm-project/clang/lib/Basic -I/usr/src/contrib/llvm-project/clang/lib/Driver -I/usr/src/contrib/llvm-project/clang/include -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections -fdata-sections -gline-tables-only -MD -MF.depend.Basic_Targets.o -MTBasic/Targets.o -Wno-format-zero-length -Qunused-arguments -include ../freebsd_cc_version.h -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -fno-exceptions -fno-rtti -gline-tables-only -std=c++14 -stdlib=libc++ -Wno-c++11-extensions -c /usr/src/contrib/llvm-project/clang/lib/Basic/Targets.cpp -o Basic/Targets.o --- Basic/SourceManager.o --- /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228:10: fatal error: 'emmintrin.h' file not found #include ^ If this happens during the cross-tools stage (stage 3), then your base system's toolchain is missing some components. Can you check whether the directory /usr/lib/clang/x.y.z exists, where x.y.z is the version printed by "cc -v" ? If that directory does not exist, the easiest fix is probably to use a toolchain port to bootstrap, or alternatively restore the toolchain directories from a 13-CURRENT snapshot. You are absolutely right. The directory /usr/lib/clang was empty. Thank you! ___ 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: When will the FreeBSD (u)EFI work?
On Sun, Mar 29, 2020 at 9:24 PM Kyle Evans wrote: > On Sun, Mar 29, 2020 at 10:16 PM Rebecca Cran wrote: > > > > > > > On Mar 29, 2020, at 9:11 PM, Nathan Whitehorn > wrote: > > > > > > The problem then is that we have treated loader as a > > > continuously-updatable part of the OS, like the kernel, and the update > > > system and development process assumes they get updated in sync. > > > > But at the moment how often do users mount the ESP and update loader.efi > on it? So it seems it rarely _needs_ to be updated at the moment. > > > > The interpreter developer in me wants this to be more frequent than it > probably is. =-) Right now, we have to plan on optionally supporting > any new features that we end up adding to the interpreter itself (e.g. > lua C modules). I can think of one at the moment that will be joining > us in the coming months -- while a bad example because this particular > module will only be presented if the system supports it, it'd be nice > to not have to have optional shims for old loaders for years on end. > Yes. This is why we need to bite the bullet, update the docs, etc and come up with a firm plan for this like we did for gcc removal. It's lingered about 3 years too long at this point (much of it my fault for not wanting to push the issue and upset the apple cart, but that complacency has done the project no favors). Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: When will the FreeBSD (u)EFI work?
On Sun, Mar 29, 2020 at 9:14 PM Nathan Whitehorn wrote: > > > On 2020-03-29 20:02, Simon J. Gerraty wrote: > > Nathan Whitehorn wrote: > >> It's basically this that has been the problem: we need a way to manage > >> updates of the EFI loader in this situation, which we don't currently > >> have. The ESP needs to be mounted at a standard point, > >> installworld/freebsd-update/etc. need to know to replace files there, we > >> need to fall back cleanly on older systems, etc. The original (failed -- > > Actually if you are doing secure boot, the *last* thing you want is to > > update /efi/boot with an unsigned update. > > > > So I would think it should be done as a unique operation - do you don't > > do it accidentally. > > > > At least that's how I'm handling it for embedded devices. > > ___ > > 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" > > > > The problem then is that we have treated loader as a > continuously-updatable part of the OS, like the kernel, and the update > system and development process assumes they get updated in sync. > It's thorny issues like this which have led me to believe we need to have an install-loader target and separate it out just like we separate out world from kernel because the loader has become more like a kernel and it may need to be updated asynchronously to all other parts of the system. However, this also breaks all the instructions in the world, and often times will make things worse, not better. Things like etcupdate shouldn't be used to paper over this problem, though: it needs to be solved systematically. Ideally, we'd impose a one true location for the ESP, have a make variable to override that one true location, and have a WITHOUT_LOADER_INSTALL or somesuch flag if we don't go the install-loader router. This would make it safe to do automatically because the unsafe installations can just turn it off. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: When will the FreeBSD (u)EFI work?
On Sun, Mar 29, 2020 at 9:23 PM Rebecca Cran wrote: > > > On Mar 29, 2020, at 9:11 PM, Nathan Whitehorn > wrote: > > > > The problem then is that we have treated loader as a > > continuously-updatable part of the OS, like the kernel, and the update > > system and development process assumes they get updated in sync. > > But at the moment how often do users mount the ESP and update loader.efi > on it? So it seems it rarely _needs_ to be updated at the moment. > True, but as we move from boot1.efi to loader.efi, the need will grow... Even if we keep boot1.efi, loader.efi will be needed for interesting secure systems, so we can't cop-out like we have in the past. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: When will the FreeBSD (u)EFI work?
On Sun, Mar 29, 2020 at 10:16 PM Rebecca Cran wrote: > > > > On Mar 29, 2020, at 9:11 PM, Nathan Whitehorn > > wrote: > > > > The problem then is that we have treated loader as a > > continuously-updatable part of the OS, like the kernel, and the update > > system and development process assumes they get updated in sync. > > But at the moment how often do users mount the ESP and update loader.efi on > it? So it seems it rarely _needs_ to be updated at the moment. > The interpreter developer in me wants this to be more frequent than it probably is. =-) Right now, we have to plan on optionally supporting any new features that we end up adding to the interpreter itself (e.g. lua C modules). I can think of one at the moment that will be joining us in the coming months -- while a bad example because this particular module will only be presented if the system supports it, it'd be nice to not have to have optional shims for old loaders for years on end. ___ 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: When will the FreeBSD (u)EFI work?
> On Mar 29, 2020, at 9:11 PM, Nathan Whitehorn wrote: > > The problem then is that we have treated loader as a > continuously-updatable part of the OS, like the kernel, and the update > system and development process assumes they get updated in sync. But at the moment how often do users mount the ESP and update loader.efi on it? So it seems it rarely _needs_ to be updated at the moment. — Rebecca Cran ___ 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: When will the FreeBSD (u)EFI work?
Nathan Whitehorn wrote: > It's basically this that has been the problem: we need a way to manage > updates of the EFI loader in this situation, which we don't currently > have. The ESP needs to be mounted at a standard point, > installworld/freebsd-update/etc. need to know to replace files there, we > need to fall back cleanly on older systems, etc. The original (failed -- Actually if you are doing secure boot, the *last* thing you want is to update /efi/boot with an unsigned update. So I would think it should be done as a unique operation - do you don't do it accidentally. At least that's how I'm handling it for embedded devices. ___ 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: When will the FreeBSD (u)EFI work?
On 2020-03-29 20:02, Simon J. Gerraty wrote: > Nathan Whitehorn wrote: >> It's basically this that has been the problem: we need a way to manage >> updates of the EFI loader in this situation, which we don't currently >> have. The ESP needs to be mounted at a standard point, >> installworld/freebsd-update/etc. need to know to replace files there, we >> need to fall back cleanly on older systems, etc. The original (failed -- > Actually if you are doing secure boot, the *last* thing you want is to > update /efi/boot with an unsigned update. > > So I would think it should be done as a unique operation - do you don't > do it accidentally. > > At least that's how I'm handling it for embedded devices. > ___ > 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" > The problem then is that we have treated loader as a continuously-updatable part of the OS, like the kernel, and the update system and development process assumes they get updated in sync. -Nathan ___ 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: When will the FreeBSD (u)EFI work?
Rebecca Cran wrote: > That's another thing: we should be installing loader.efi as > \efi\boot\bootx64.efi (as well as \boot\freebsd\loader.efi) since it's > entirely possible to lose the Boot Manager entry and end up with an > unbootable system as a result. Unfortunately people have had bad > experiences with other operating systems overwriting bootx64.efi and > don't believe we should do that. FWIW I use loader.efi from head, installed as /efi/boot/bootx64.efi and it works just fine, by simply defining PATH_BOOTABLE_TOKEN to something that marks our (junos) bootable filesystems, no other change is needed. >From secure boot point of view, that's perfect. bootx64.efi has to be signed specially for the BIOS, and it verifies everything else, so the same ESP content "just works" with stable/11,12,... ___ 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: When will the FreeBSD (u)EFI work?
On 2020-03-29 19:09, Kyle Evans wrote: > On Sun, Mar 29, 2020 at 6:19 PM Rebecca Cran wrote: >> On 3/29/20 6:11 AM, Tomoaki AOKI wrote: >> >>> 3. based solution looks good to me. >>> >>> IMHO, assuming /efi/bootx[64|32].efi is boot1.efi or loader.efi >>> or EFI environment pointing to either one is properly used, >> >> That's another thing: we should be installing loader.efi as >> \efi\boot\bootx64.efi (as well as \boot\freebsd\loader.efi) since it's >> entirely possible to lose the Boot Manager entry and end up with an >> unbootable system as a result. Unfortunately people have had bad >> experiences with other operating systems overwriting bootx64.efi and >> don't believe we should do that. >> > I have mixed feelings about this -- symlinks don't exist on FAT, > right? So then the maintenance overhead goes up, as you can always > replace \EFI\FreeBSD\ bits, but you need to make sure \EFI\BOOT > components are actually 100% without-a-doubt yours before you replace > them. > > I'd be in favor of installing to \EFI\BOOT\... as well if and only if > the file doesn't already exist, assuming we can figure out how to make > it not a maintenance nightmare -- which I suspect would just mean that > we have some tool that users use to update the ESP rather than > instructing them to examine/replace files manually. > > Thanks, > > Kyle Evans > ___ > 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" > It's basically this that has been the problem: we need a way to manage updates of the EFI loader in this situation, which we don't currently have. The ESP needs to be mounted at a standard point, installworld/freebsd-update/etc. need to know to replace files there, we need to fall back cleanly on older systems, etc. The original (failed -- and I wrote it) concept with boot1.efi was that we could install a shim that never needs updates, which avoids needing to think about these things, but that didn't work ideally. -Nathan ___ 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: When will the FreeBSD (u)EFI work?
On 3/29/20 8:09 PM, Kyle Evans wrote: I'd be in favor of installing to \EFI\BOOT\... as well if and only if the file doesn't already exist, assuming we can figure out how to make it not a maintenance nightmare -- which I suspect would just mean that we have some tool that users use to update the ESP rather than instructing them to examine/replace files manually. Or if, as you say, we can determine that it's _our_ bootx64.efi! That's pretty simple, since we have strings such as "FreeBSD/amd64 EFI loader, Revision 1.1" in the binary. We'll also want to embed a better version string to determine that it's our bootx64.efi _and_ for a version of FreeBSD that we're wanting to update. -- Rebecca Cran ___ 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: When will the FreeBSD (u)EFI work?
On Sun, Mar 29, 2020 at 6:19 PM Rebecca Cran wrote: > > On 3/29/20 6:11 AM, Tomoaki AOKI wrote: > > > > > 3. based solution looks good to me. > > > > IMHO, assuming /efi/bootx[64|32].efi is boot1.efi or loader.efi > > or EFI environment pointing to either one is properly used, > > > That's another thing: we should be installing loader.efi as > \efi\boot\bootx64.efi (as well as \boot\freebsd\loader.efi) since it's > entirely possible to lose the Boot Manager entry and end up with an > unbootable system as a result. Unfortunately people have had bad > experiences with other operating systems overwriting bootx64.efi and > don't believe we should do that. > I have mixed feelings about this -- symlinks don't exist on FAT, right? So then the maintenance overhead goes up, as you can always replace \EFI\FreeBSD\ bits, but you need to make sure \EFI\BOOT components are actually 100% without-a-doubt yours before you replace them. I'd be in favor of installing to \EFI\BOOT\... as well if and only if the file doesn't already exist, assuming we can figure out how to make it not a maintenance nightmare -- which I suspect would just mean that we have some tool that users use to update the ESP rather than instructing them to examine/replace files manually. Thanks, Kyle Evans ___ 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: When will the FreeBSD (u)EFI work?
> On 3/29/20 6:11 AM, Tomoaki AOKI wrote: > > > > > 3. based solution looks good to me. > > > > IMHO, assuming /efi/bootx[64|32].efi is boot1.efi or loader.efi > > or EFI environment pointing to either one is properly used, > > > That's another thing: we should be installing loader.efi as > \efi\boot\bootx64.efi (as well as \boot\freebsd\loader.efi) since it's > entirely possible to lose the Boot Manager entry and end up with an > unbootable system as a result. Unfortunately people have had bad > experiences with other operating systems overwriting bootx64.efi and > don't believe we should do that. > > > Perhaps I just need to come up with a proof of concept or demo to show > that it is possible without breaking other OSes. Yes please. > Rebecca Cran -- Rod Grimes rgri...@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: When will the FreeBSD (u)EFI work?
On 3/29/20 6:11 AM, Tomoaki AOKI wrote: 3. based solution looks good to me. IMHO, assuming /efi/bootx[64|32].efi is boot1.efi or loader.efi or EFI environment pointing to either one is properly used, That's another thing: we should be installing loader.efi as \efi\boot\bootx64.efi (as well as \boot\freebsd\loader.efi) since it's entirely possible to lose the Boot Manager entry and end up with an unbootable system as a result. Unfortunately people have had bad experiences with other operating systems overwriting bootx64.efi and don't believe we should do that. Perhaps I just need to come up with a proof of concept or demo to show that it is possible without breaking other OSes. -- Rebecca Cran ___ 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: FYI: artifact-based head bisect and OPi+2e (an armv7): -r359311 fails to boot but -r359309 boots (kernel substitutions)
On Sun, 2020-03-29 at 09:44 -0700, Thomas Skibo wrote: > On Sun, Mar 29, 2020 at 12:29:00AM -0700, Mark Millard via freebsd- > arm wrote: > > While trying to update the head version > > in use I ran into boot hangups on the > > OrangePi+ 2e and did an approximate > > bisect of artificact.freebsd.org kernels > > to find approximately which kernel > > version the issue started at. > > > > I found that head -r359309 boots and > > -r359311 fails (shown later below). > > The original update attempt was from > > -r359966 to -r359376 and -r359376 > > stopped there as well. (I kept world > > there and varied the kernel version > > for the approximate bisect activity.) > > > > It seems that at least one of the > > "MI-namespace" atomics added do not work > > in all its usage-contexts on the cortexA7 > > (armv7) involved. > > It looks like my previous reply didn't go to the mailing lists. I'm > new to > mutt. > > Anyway, I looked at this problem yesterday and it seems r359311 > enables > using some atomic operations that were not being used until now. In > particular, atomic_fcmpset_8() seems broken and hangs up > in vm_page_bits_swap(). I think I have a fix but I want to run it > by Ian. > > --Thomas > > Index: sys/arm/include/atomic-v6.h > === > --- sys/arm/include/atomic-v6.h (revision 359412) > +++ sys/arm/include/atomic-v6.h (working copy) > @@ -196,7 +196,7 @@ >\ > __asm __volatile( \ > "1: ldrex" SUF " %[tmp], [%[ptr]] \n" \ > - " ldr%[ret], [%[oldv]] \n" \ > + " ldr" SUF " %[ret], [%[oldv]] \n" \ > " teq%[tmp], %[ret]\n" \ > " ittee ne\n" \ > " str" SUF "ne %[tmp], [%[oldv]] \n" \ > I've committed this fix as r359423, thanks! -- Ian ___ 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"
Build world error with PIE option
Hello, I am trying to build -CURRENT with some custom build options, which are the following: WITH_EXTRA_TCP_STACKS=1 WITH_BEARSSL=1 WITH_PIE=1 WITH_RETPOLINE=1 But WITH_PIE=1 seems to break the build while linking sbin/veriexec with the following error messages. ===> sbin/veriexec (all) ===> lib/libkvm/tests (all) ld: error: unable to find library -lveriexec_pie ld: error: unable to find library -lsecureboot_pie ld: error: unable to find library -lbearssl_pie cc: error: linker command failed with exit code 1 (use -v to see invocation) --- veriexec.full --- *** [veriexec.full] Error code 1 make[4]: stopped in /boiler/nfs/src/sbin/veriexec 1 error make[4]: stopped in /boiler/nfs/src/sbin/veriexec --- all_subdir_sbin/veriexec --- *** [all_subdir_sbin/veriexec] Error code 2 Has anyone experienced the same error and was able to solve it? Or has anyone an idea how to solve this problem? Best regards, Gordon ___ 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: When will the FreeBSD (u)EFI work?
On Sat, 28 Mar 2020 12:57:21 -0700 Chris wrote: > On Sat, 28 Mar 2020 11:07:38 +0200 Toomas Soome tso...@me.com said > (snip) > Thank you very much for your reply, Toomas. > > How loader is working is that it does search for *first* “usable” freebsd > > partition and will use it. Usable is defined as having /boot/loader.efi. > Yes, I understand how this is currently implemented. :) Some explanation about the boot order by boot1.efi. 1. Try the drive where running boot1.efi is read from. 2. If failed, try drives as recognized by UEFI firmware. On each drive, ZFS pool is tried first, and if all fail, or nonexistent, UFS partitions are tried in partition No.order. > > Therefore, you may have 2 or more freebsd instances on the disk, it really > > does not matter, only first is used. If you have multiple disks, you can > > have > > different order on second disk. > Just a thought along these lines... If, for every install, an additional efi > ESP were created (how it's done now). If the search were for the *first* > usable freebsd slice/partition were done incrementally, that is, counting > from the ESPs current location on disk. It would more often than not, > find the install that created ESP it's working from. Just one possibility > that could be done at near zero cost. IIUC, UEFI firmware recognizes ESP only on first partition on the disk. Some implementation could recongnize first non-top ESP, or even multiple ESPs, but it's NOT promissing for ALL FIRMWARES IN THE WILD. At worst, some firmwares could hesitate to boot from disk having non-top ESP or multiple ESPs. > > Why it is so? We do build loader.efi and we do copy it to the ESP, and > > currently there is no way to tell where is the root file system. > See above. > > > > How could we tell where from to load the OS? Well, there are few options to > > think about: > > > > 1. record the hint into the loader.efi binary - this would need special > > installer and would break signing. > > 2. record EFI variable - it should reflect OS instance version and that > > version should be bound with specific loader binary. Coordination is pain > > there. > > 3. record partition to loader.env file > > > > The current loader code is reading "/efi/freebsd/loader.env” from ESP. IMO > > this sounds most promising, but would need support from installer or manual > > setup. Would work as is with multiple ESP instances. Would need versioned > > /efi/freebsdXX directories for single shared ESP and installer update. > > > > 4. We still do have BE menu in loader, populated automatically from zfs > > snapshots. It can be complemented with entries from file based index (I > > wrote > > about that idea already). This would allow to create simple switch to > > different instance or initiate chain load of third party boot loader. > Only drawback is that it is limited to zfs(8). > Other thoughts that come to mind: > - embedding the GUID hash into the loader that points to the new install. > - menu, similar to the BE menu you indicated above. > - adding an additional jump in the UEFI entry already created for the install > that points to the install associated with the newly added loader. 3. based solution looks good to me. IMHO, assuming /efi/bootx[64|32].efi is boot1.efi or loader.efi or EFI environment pointing to either one is properly used, *Use single ESP on the top of drive. *loader.env in unversioned /efi/freebsd contains common settings, including partition / pool list for loader menu. *loader.env in versioned /efi/freebsd** contains version-specific settings only and should not contain partition / pool list. This is because settings there could be missed on upgrading base. *Whichever boot1.efi or loader.efi reads loader.env in unversioned /efi/freebsd and show boot partition selection menu. would be fine. As Warner noted, lua code could be used for loader.efi case. > Lastly. It appears that much of what we're currently using was simply > hijacked from Linux. Why? We're not a Linux. The UEFI spec is fairly broad, > and gives much leeway for implementing something quite exotic, if we were > so inclined. > > Thanks again, for all the time you put into your reply, Toomas! :) > > --Chris > > > > just few bits, > > toomas > > > > >> > > > > That is; not without dropping (snip) > > >> > > Again, not needed. Though there may be a few things that need to be > > > MFC'd > > >> > if you want 11 on that list... > > >> > > > > There *may* be hope in the future ( > > >> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940) > > >> > > > > >> > > This would require you to stop to select on the way up... Or am I not > > >> > understanding what you want? Current patch has 10 seconds timeout and defaults to in-tree boot1.efi behavior, if not user specified one. IIRC, last version applicable to stable/11 has it, too. > > >> > > We should add that functionality to loader.efi, since boot1.efi is in > > > the > > >> > process of being
Trying to compiles today Current
I keep getting errors in building my ports from portsbuilder. But it is with Current/Clang10. So I'm trying to get a server at that level, but building world keeps giving me: --- all_subdir_cddl --- ld: error: /usr/obj/usr/srcs/head/amd64.amd64/tmp/usr/lib/libuutil.so: undefined reference to __assfail cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [zfs.full] Error code 1 Completely cleared src and obj, but the error persists. Current on this system is: FreeBSD 13.0-CURRENT #0 r358358: Thu Feb 27 04:40:39 UTC 2020 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC How to fix this? --WjW ___ 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: kernel build failed
On 29 Mar 2020, at 13:02, Alexandr Krivulya wrote: > > 28.03.20 18:32, Dimitry Andric пишет: >> On 28 Mar 2020, at 13:48, Alexandr Krivulya wrote: ... >> This typically happens if you don't run "make buildworld", or at least >> "make kernel-toolchain" before running "make buildkernel", and your >> userland is missing those headers, for some reason. (Usually people >> seem to do a WITHOUT_CLANG installation or strip out 'unnecessary' >> stuff manually...) >> > > I have updated source tree to r359419 and now make builworld failed with an > error: > > --- Basic/Targets.o --- > c++ -O2 -pipe > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm > -I/usr/src/contrib/llvm-project/clang/lib/Basic > -I/usr/src/contrib/llvm-project/clang/lib/Driver > -I/usr/src/contrib/llvm-project/clang/include -I/usr/src/lib/clang/include > -I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" > -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" > -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" > -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser > -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter > -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler > -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target > -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo > -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections > -fdata-sections -gline-tables-only -MD -MF.depend.Basic_Targets.o > -MTBasic/Targets.o -Wno-format-zero-length -Qunused-arguments -include > ../freebsd_cc_version.h -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include > -fno-exceptions -fno-rtti -gline-tables-only -std=c++14 -stdlib=libc++ > -Wno-c++11-extensions -c > /usr/src/contrib/llvm-project/clang/lib/Basic/Targets.cpp -o Basic/Targets.o > --- Basic/SourceManager.o --- > /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228:10: > fatal error: 'emmintrin.h' file not found > #include > ^ If this happens during the cross-tools stage (stage 3), then your base system's toolchain is missing some components. Can you check whether the directory /usr/lib/clang/x.y.z exists, where x.y.z is the version printed by "cc -v" ? If that directory does not exist, the easiest fix is probably to use a toolchain port to bootstrap, or alternatively restore the toolchain directories from a 13-CURRENT snapshot. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: kernel build failed
29.03.20 14:12, David Wolfskill пишет: On Sun, Mar 29, 2020 at 02:02:02PM +0300, Alexandr Krivulya wrote: 28.03.20 18:32, Dimitry Andric пишет: ... This typically happens if you don't run "make buildworld", or at least "make kernel-toolchain" before running "make buildkernel", and your userland is missing those headers, for some reason. (Usually people seem to do a WITHOUT_CLANG installation or strip out 'unnecessary' stuff manually...) I have updated source tree to r359419 and now make builworld failed with an error: ... --- Basic/SourceManager.o --- /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228:10: fatal error: 'emmintrin.h' file not found #include ^ 1 error generated. *** [Basic/SourceManager.o] Error code 1 Perhaps it would be helpful for you specify precisely what commands you invoked once the source tree was updated. For example, the process I use is documented in http://www.catwhisker.org/~david/FreeBSD/upgrade.html Nothing specific, I use this scenario for years: svnlite up /usr/src rm -rf /usr/obj cd /usr/src make buildworld make kernel mergemaster -p make installworld mergemaster -Ui reboot make delete-old make delete-old-libs ___ 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: kernel build failed
On Sun, Mar 29, 2020 at 02:02:02PM +0300, Alexandr Krivulya wrote: > 28.03.20 18:32, Dimitry Andric пишет: > ... > > This typically happens if you don't run "make buildworld", or at least > > "make kernel-toolchain" before running "make buildkernel", and your > > userland is missing those headers, for some reason. (Usually people > > seem to do a WITHOUT_CLANG installation or strip out 'unnecessary' > > stuff manually...) > > > > I have updated source tree to r359419 and now make builworld failed with an > error: > > ... > --- Basic/SourceManager.o --- > /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228:10: > fatal error: 'emmintrin.h' file not found > #include > ^ > 1 error generated. > *** [Basic/SourceManager.o] Error code 1 > Perhaps it would be helpful for you specify precisely what commands you invoked once the source tree was updated. For example, the process I use is documented in http://www.catwhisker.org/~david/FreeBSD/upgrade.html Peace, david -- David H. Wolfskill da...@catwhisker.org Trump on sale of GM's Lordstown, OH plant: "GREAT NEWS FOR OHIO!" May 2019 "MUST immediately open their stupidly abandoned Lordstown " March 2020 See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: kernel build failed
28.03.20 18:32, Dimitry Andric пишет: On 28 Mar 2020, at 13:48, Alexandr Krivulya wrote: 28.03.20 14:35, David Wolfskill пишет: On Sat, Mar 28, 2020 at 02:01:39PM +0200, Alexandr Krivulya wrote: Hello, on latest CURRENT kernel fails to build: ===> aesni (all) [Creating objdir /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/aesni...] ... /usr/src/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 'wmmintrin.h' file not found #include ^ 1 error generated. *** Error code 1 I had no issues updating from r359325 to r359356 yesterday, or from r359356 to r359389 today (using META_MODE). So what may be a reason? I tried: - remove and checkout source tree - remove /usr/obj wmmintrin.h is present under /usr/src/contrib/llvm-project/clang/lib/Headers/wmmintrin.h /etc/make.conf: KERNCONF=GENERIC-NODEBUG MALLOC_PRODUCTION=yes no /etc/src.conf This typically happens if you don't run "make buildworld", or at least "make kernel-toolchain" before running "make buildkernel", and your userland is missing those headers, for some reason. (Usually people seem to do a WITHOUT_CLANG installation or strip out 'unnecessary' stuff manually...) I have updated source tree to r359419 and now make builworld failed with an error: --- Basic/Targets.o --- c++ -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm -I/usr/src/contrib/llvm-project/clang/lib/Basic -I/usr/src/contrib/llvm-project/clang/lib/Driver -I/usr/src/contrib/llvm-project/clang/include -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections -fdata-sections -gline-tables-only -MD -MF.depend.Basic_Targets.o -MTBasic/Targets.o -Wno-format-zero-length -Qunused-arguments -include ../freebsd_cc_version.h -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -fno-exceptions -fno-rtti -gline-tables-only -std=c++14 -stdlib=libc++ -Wno-c++11-extensions -c /usr/src/contrib/llvm-project/clang/lib/Basic/Targets.cpp -o Basic/Targets.o --- Basic/SourceManager.o --- /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228:10: fatal error: 'emmintrin.h' file not found #include ^ 1 error generated. *** [Basic/SourceManager.o] Error code 1 make[4]: stopped in /usr/src/lib/clang/libclang 1 error make[4]: stopped in /usr/src/lib/clang/libclang *** [all_subdir_lib/clang/libclang] Error code 2 make[3]: stopped in /usr/src/lib/clang 1 error make[3]: stopped in /usr/src/lib/clang *** [cross-tools] Error code 2 make[2]: stopped in /usr/src 1 error make[2]: stopped in /usr/src *** [_cross-tools] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src ___ 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"
FYI: artifact-based head bisect and OPi+2e (an armv7): -r359311 fails to boot but -r359309 boots (kernel substitutions)
While trying to update the head version in use I ran into boot hangups on the OrangePi+ 2e and did an approximate bisect of artificact.freebsd.org kernels to find approximately which kernel version the issue started at. I found that head -r359309 boots and -r359311 fails (shown later below). The original update attempt was from -r359966 to -r359376 and -r359376 stopped there as well. (I kept world there and varied the kernel version for the approximate bisect activity.) It seems that at least one of the "MI-namespace" atomics added do not work in all its usage-contexts on the cortexA7 (armv7) involved. [I also ran into boot problems on the RPi4 (arch64 CortexA72) for the original upgrade in that context. But the RPi4 is incomplete and is not a long-established FreeBSD context. I've not tested it specifically against -r359309 and -r359311 . I'll otherwise ignore the RPi4 here, at least for now.] The OPi+2e hangups look like (a boot -v example): . . . Release APs CPU(1) applied BP hardening: not necessary CPU(3) applied BP hardening: not necessary CPU(2) applied BP hardening: not necessary regulator: shutting down unused regulators regulator: shutting down vcc3v0... Trying to mount root from ufs:/dev/gpt/BPIM3root []... ok Root mount waiting for:regulator: shutting down vcc3v3... usbus0busy usbus2regulator: shutting down vcc5v0... usbus4ok usbus6regulator: shutting down gmac-3v3... CAMbusy uhub1: 1 port with 1 removable, self powered uhub3: 1 port with 1 removable, self powered uhub4: 1 port with 1 removable, self powered uhub6: 1 port with 1 removable, self powered Root mount waiting for: usbus6 CAM ugen6.2: at usbus6 umass0 on uhub6 umass0: on usbus6 umass0:0:0: Attached to scbus0 Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM GEOM: new disk da0 pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Direct Access SPC-4 SCSI device pass0: Serial Number REPLACED pass0: 40.000MB/s transfers da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number REPLACED da0: 40.000MB/s transfers da0: 228936MB (468862128 512 byte sectors) da0: quirks=0x2 da0: Delete methods: mountroot: waiting for device /dev/gpt/BPIM3root... random: unblocking device. rtc0: providing initial system time start_init: trying /sbin/init (And that is as far as it gets. I can break into the debugger on the console.) Notes: vfs.root.mountfrom= is used in /boot/loader.conf to direct the root file system to be from the USB SSD. The original kernel and world were non-debug builds. But the artifact kernels are debug builds. They did not report anything odd. (The /dev/gpt/BPIM3* based naming is from repurposing media without bothering to rename things.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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"
