Checksum Error on installer (3 iso images in CURRENT)
Hi FreeBSD mailing list, I have recently started to look at the CURRENT isos, for installation in a virtualbox, and while trying to install these images I have received verification issues with the checksums. Problem: FreeBSD installer will error out of the installer upon verification of checksums, they do not align with the checksum files in the directory: https://download.freebsd.org/snapshots/amd64/amd64/ISO-IMAGES/15.0/ Steps to replicate: 1. Create a virtualbox profile with freebsd 2. Attach one of the below iso images 3. Run the installation 4. Select keymap 5. Select partition setup (UFS) 6. Select packages to install 7. Program starts verifying the base package and comes back with the error message I have confirmed this with some people on the libera.chat IRC server, under #freebsd and this is not an isolated event. The 3 iso images in question are: * FreeBSD-15.0-CURRENT-amd64-20231216-ca39f23347e1-266973-bootonly.iso * FreeBSD-15.0-CURRENT-amd64-20231228-fb03f7f8e30d-267242-disc1.iso * FreeBSD-15.0-CURRENT-amd64-20231223-dac33a65b965-267058-bootonly.iso Here are the respective checksums for each of these files: CHECKSUM.SHA256-FreeBSD-15.0-CURRENT-amd64-20231216-ca39f23347e1-266973 SHA256 (CHECKSUM.SHA256-FreeBSD-15.0-CURRENT-amd64-20231216-ca39f23347e1-266973) = 827182ccbfbce984c969790e7aac43828dffc4a21d43e855c91bac03f29dc74e SHA256 (FreeBSD-15.0-CURRENT-amd64-20231216-ca39f23347e1-266973-bootonly.iso) = fdd8870549474f38d35665c330d209df7733aa8608630845471685b291c06746 CHECKSUM.SHA256-FreeBSD-15.0-CURRENT-amd64-20231223-dac33a65b965-267058 SHA256 (CHECKSUM.SHA256-FreeBSD-15.0-CURRENT-amd64-20231223-dac33a65b965-267058) = 60f01c27aa02acb47cab7dec58119f34e7215c3656b8486854bc64217cdfe3bb SHA256 (FreeBSD-15.0-CURRENT-amd64-20231223-dac33a65b965-267058-bootonly.iso) = abdd81c253c651bbc10e3db1b97b8b111f73b3f657f729e37cdbe975de0dc056 CHECKSUM.SHA256-FreeBSD-15.0-CURRENT-amd64-20231228-fb03f7f8e30d-267242 SHA256 (CHECKSUM.SHA256-FreeBSD-15.0-CURRENT-amd64-20231228-fb03f7f8e30d-267242) = 83698ee594d56108b29e40d635671c7a2de6ada2af636ef5254eafbd35e95e96 SHA256 (FreeBSD-15.0-CURRENT-amd64-20231228-fb03f7f8e30d-267242-disc1.iso) = 2deb850673f148cf1ab269175ddf40448e6a96b331b4ca0027f8abe16b3edfa0 If any further information/clarification is required, please do let me know. Kind Regards, Chris
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
I am still using the same workaround: instead of rv =
efi_global_getenv("ConOut", buf, &sz); I have rv =
efi_global_getenv("ConIn", buf, &sz);
Happy New Year!
On Mon, May 15, 2023 at 8:41 AM Oleg Lelchuk wrote:
> I got it.
>
> On Mon, May 15, 2023, 8:32 AM Toomas Soome wrote:
>
>>
>>
>> On 15. May 2023, at 15:22, Oleg Lelchuk wrote:
>>
>> Adding screen.font="16×32" to loader.conf fixed that tiny issue mentioned
>> in the previous email message... I find it a bit surprising that I only had
>> to make one tiny change to the source code of stand to make the graphical
>> logo appear, to start playing with the EFI resolution, and etc.
>>
>>
>> The font size/resolution is difficult topic. The implementation itself
>> can choose “good enough” variant and then some people are happy and some
>> people are unhappy.
>>
>> The current loader UI is built on terminal dimensions (which depend on
>> glyph size and resolution), and there the traditional assumption is that we
>> have 80x24 terminal. With different fonts and depending on how much screen
>> space we want to leave unused, we can get different dimensions for terminal.
>>
>> And since there is quite a variation of displays, the challenge is to get
>> decent enough visual on most commonly used displays - so there can be
>> pressure to use fixed resolution etc. And this is also the reason, why you
>> see very simple boot screens with something like spinning wheel on some
>> other systems.
>>
>> rgds,
>> toomas
>>
>>
>> On Sun, May 14, 2023, 8:58 AM Oleg Lelchuk wrote:
>>
>>> Okay, so I edited /usr/src/stand/efi/loader/main.c , and I replaced
>>> ConOut with ConIn in this line: rv = efi_global_getenv("ConIn", buf, &sz);
>>> . Now I am able to see the beautiful graphical logo in the efi boot menu!
>>> But why are the boot menu and the logo shown in the top left corner of my
>>> computer screen? My monitor is 1080p and the setting
>>> efi_max_resolution=1080p in loader.conf only affects what happens after the
>>> kernel starts booting up, but it doesn't affect what happens before it: the
>>> boot menu and the logo remain in the top left corner of the screen. Why is
>>> this the case? You can see the photo in the provided attachment... And
>>> thank you, guys, for your work!
>>>
>>> On Sat, May 13, 2023 at 9:35 AM Warner Losh wrote:
>>>
On Sat, May 13, 2023, 6:26 AM Oleg Lelchuk
wrote:
> I've been reading the documentation for loader.efi and it says this:
> "If there is no ConOut variable, both serial and video are attempted.
> loader.efi uses the "efi" console for the video (which may or may
> not
> work) and "comconsole" for the serial on COM1 at the default baud
> rate.
> The kernel will use a dual console, with the video console
> primary if a
> UEFI graphics device is detected, or the serial console as
> primary if
> not."
> I find this language confusing because I don't know what is meant by
> "a UEFI graphics device". In my situation, is my Intel Integrated Graphics
> card an UEFI graphics device? Does it mean that once i915kms is loaded, I
> no longer deal with UEFI graphics? I think lots of people whose native
> language is English will find the documentation describing loader.efi
> confusing. The documentation page also mentions this: "BUGS
> Systems that do not have a ConOut variable set are not conformant
> with
> the standard, and likely have unexpected results." But I think
> you guys already implied that the UEFI specification doesn't mandate
> having
> such a variable.
>
That's unclear. The standard refers to it many times. Earlier versions
especially. It doesn't say it's optional, unlike some other variables. Yet
later versions don't say it's mandatory. I've yet to own or use a system
without it... such systems exist but they are quite new...
Warner
On Fri, May 12, 2023 at 7:55 PM Oleg Lelchuk
> wrote:
>
>> I got it. Thanks.
>>
>> On Fri, May 12, 2023 at 7:45 PM Ed Maste wrote:
>>
>>> On Fri, 12 May 2023 at 09:26, Oleg Lelchuk
>>> wrote:
>>> >
>>> > I don't want to go through the hassle of filling a bug with my
>>> vendor. I will just wait for you, guys, to update the stand
>>> implementation.
>>> Thank you for explaining to me what causes this issue.
>>>
>>> This issue is tracked in PR 265980 if you want to follow it.
>>> https://bugs.freebsd.org/265980
>>>
>>
>>
Re: Problem building world on current
Seems that it was related to PR273661. I follow this https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273661#c5 and its now building Thanks Santi On 12/28/23 20:32, Santiago Martinez wrote: Hi David, - I'm running 14.0R-P3 - Last commit: 5f71f9636efa25f6de1a832202bae7c78ad013aa (HEAD -> main, origin/main, origin/HEAD) Author: rilysh Date: Thu Dec 28 02:34:32 2023 -0500 - Just a clean build, no options on command line or src.conf/make - Kernel builds without a problem ( just in case). Thanks. Santi On 12/28/23 16:23, David Wolfskill wrote: On Thu, Dec 28, 2023 at 04:05:49PM +0100, Santiago Martinez wrote: Hi Everyone, I'm having issues building world from current (just now). Same header missing on multiple parts. Best regards. Santiago It might be useful to know: * What you are running at the time; * what the most recent commit in your source tree is; * whether this is a clean build, you are using make's META_MODE, or you are just setting -DNO_CLEAN. I have not seen the issue you cite; my most recent builds of head: FreeBSD 15.0-CURRENT #22 main-n267169-5bc10feacc9d: Tue Dec 26 12:14:41 UTC 2023 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 158 158 FreeBSD 15.0-CURRENT #23 main-n267215-3334a537ed38: Wed Dec 27 15:52:04 UTC 2023 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 158 158 FreeBSD 15.0-CURRENT #24 main-n267279-789480702e49: Thu Dec 28 12:18:34 UTC 2023 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 158 158 (in my case, using make's META_MODE). More details at https://www.catwhisker.org/~david/FreeBSD/history/. Peace, david
Re: Problem building world on current
Hi David, - I'm running 14.0R-P3 - Last commit: 5f71f9636efa25f6de1a832202bae7c78ad013aa (HEAD -> main, origin/main, origin/HEAD) Author: rilysh Date: Thu Dec 28 02:34:32 2023 -0500 - Just a clean build, no options on command line or src.conf/make - Kernel builds without a problem ( just in case). Thanks. Santi On 12/28/23 16:23, David Wolfskill wrote: On Thu, Dec 28, 2023 at 04:05:49PM +0100, Santiago Martinez wrote: Hi Everyone, I'm having issues building world from current (just now). Same header missing on multiple parts. Best regards. Santiago It might be useful to know: * What you are running at the time; * what the most recent commit in your source tree is; * whether this is a clean build, you are using make's META_MODE, or you are just setting -DNO_CLEAN. I have not seen the issue you cite; my most recent builds of head: FreeBSD 15.0-CURRENT #22 main-n267169-5bc10feacc9d: Tue Dec 26 12:14:41 UTC 2023 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 158 158 FreeBSD 15.0-CURRENT #23 main-n267215-3334a537ed38: Wed Dec 27 15:52:04 UTC 2023 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 158 158 FreeBSD 15.0-CURRENT #24 main-n267279-789480702e49: Thu Dec 28 12:18:34 UTC 2023 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 158 158 (in my case, using make's META_MODE). More details at https://www.catwhisker.org/~david/FreeBSD/history/. Peace, david
Re: Problem building world on current
On Thu, Dec 28, 2023 at 04:05:49PM +0100, Santiago Martinez wrote: > Hi Everyone, I'm having issues building world from current (just now). > > Same header missing on multiple parts. > > Best regards. > > Santiago > It might be useful to know: * What you are running at the time; * what the most recent commit in your source tree is; * whether this is a clean build, you are using make's META_MODE, or you are just setting -DNO_CLEAN. I have not seen the issue you cite; my most recent builds of head: FreeBSD 15.0-CURRENT #22 main-n267169-5bc10feacc9d: Tue Dec 26 12:14:41 UTC 2023 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 158 158 FreeBSD 15.0-CURRENT #23 main-n267215-3334a537ed38: Wed Dec 27 15:52:04 UTC 2023 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 158 158 FreeBSD 15.0-CURRENT #24 main-n267279-789480702e49: Thu Dec 28 12:18:34 UTC 2023 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 158 158 (in my case, using make's META_MODE). More details at https://www.catwhisker.org/~david/FreeBSD/history/. Peace, david -- David H. Wolfskill da...@catwhisker.org Do these ends really justify those means? See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Problem building world on current
Hi Everyone, I'm having issues building world from current (just now). Same header missing on multiple parts. Best regards. Santiago """ In file included from /usr/src/contrib/llvm-project/llvm/lib/Demangle/ItaniumDemangle.cpp:13: In file included from /usr/src/contrib/llvm-project/llvm/include/llvm/Demangle/Demangle.h:13: /usr/include/c++/v1/string:561:10: fatal error: '__string/char_traits.h' file not found #include <__string/char_traits.h> ^~~~ 1 error generated. *** Error code 1 """
