Re: 20220519 snapshot: loader fails to find bootable partition of zfs-root system
On Mon, May 23, 2022 at 8:40 PM Yasuhiro Kimura wrote: > > Hello, > > I made clean install of zfs-root 14-CURRENT amd64 system with install > image of 20220519 snapshop. After installation completed and system is > rebooted, boot fails as loader fails to find bootable partition as > following. > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220519snapshot.png > > If I use 20220512 snapshop instead, then system starts up > successfully. You need a loader with commit 9cd45772a44f268ccb3e20caf7f3f764f6b5e1a1 to deal with the latest OpenZFS. Regards, Navdeep
20220519 snapshot: loader fails to find bootable partition of zfs-root system
Hello, I made clean install of zfs-root 14-CURRENT amd64 system with install image of 20220519 snapshop. After installation completed and system is rebooted, boot fails as loader fails to find bootable partition as following. https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220519snapshot.png If I use 20220512 snapshop instead, then system starts up successfully. --- Yasuhiro Kimura
Re: Bulld failure of editors/libreoffoce only on main (aka -current)
On 5/23/22 12:49, Dima Panov wrote: My recent -current jail is also have LLVM_DEFAULT=14 and not hit any serious issue yet:) tcberner was initiated exp-run to make llvm13 as default some time ago https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263456 I'd caution against adopting llvm14 for the moment. One apparently architecturally-specific problem with llvm14 on rocketlake (Intel Xeon E-2334 here) is a never-ending compilation in devel/boost-libs if CPUTYPE is set. The file libs/atomic/src/find_address_sse41.cpp causes c++ to run forever :-( It also seems to spin forever with CPUTYPE set to "native". I just found this last night but setting CPUTYPE to "ivybridge" or leaving it unset allows it to run to completion, Michael
Re: Bulld failure of editors/libreoffoce only on main (aka -current)
Moin! On 23.05.2022 19:03, Dimitry Andric wrote: On 23 May 2022, at 17:53, Tomoaki AOKI wrote: After some discussion with Mark Millard on Bug 263976 and some tests, I've changed the subject of it to "editors/libreoffice: Fails to build if LLVM_DEFAULT=90 (default) and LTO=on (non-default)". With LTO option enabled, port default devel/llvm* (now it's 90 according to Mk/bsd.default-versions.mk) is forcibly used, thus causing this problem. llvm90 is too old to support LTO as intended :( My own build farm for libreoffice and company have LTO disabled at all, so any good suggestions how to deal with LTO with minimal issues will be appreciated. Maybe it's time to bump the LLVM_DEFAULT version to 13 or 14 now? Although this would probably require an ex-run first. Brooks, do you think bumping to devel/llvm14 is too ambitious? My recent -current jail is also have LLVM_DEFAULT=14 and not hit any serious issue yet:) tcberner was initiated exp-run to make llvm13 as default some time ago https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263456 -- Sincerely, Dima (flu...@freebsd.org,https://t.me/dima_panov) (desktop, kde, x11, office, ports-secteam)@FreeBSD team OpenPGP_0xFB8BA09DD5398F29_and_old_rev.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Bulld failure of editors/libreoffoce only on main (aka -current)
On 23 May 2022, at 17:53, Tomoaki AOKI wrote: > > After some discussion with Mark Millard on Bug 263976 and some tests, > I've changed the subject of it to "editors/libreoffice: Fails to build > if LLVM_DEFAULT=90 (default) and LTO=on (non-default)". > > With LTO option enabled, port default devel/llvm* (now it's 90 > according to Mk/bsd.default-versions.mk) is forcibly used, thus causing > this problem. Maybe it's time to bump the LLVM_DEFAULT version to 13 or 14 now? Although this would probably require an ex-run first. Brooks, do you think bumping to devel/llvm14 is too ambitious? -Dimitry signature.asc Description: Message signed with OpenPGP
Re: Bulld failure of editors/libreoffoce only on main (aka -current)
After some discussion with Mark Millard on Bug 263976 and some tests,
I've changed the subject of it to "editors/libreoffice: Fails to build
if LLVM_DEFAULT=90 (default) and LTO=on (non-default)".
With LTO option enabled, port default devel/llvm* (now it's 90
according to Mk/bsd.default-versions.mk) is forcibly used, thus causing
this problem.
So overriding LLVM_DEFAULT to something safe should be needed on
editors/libreoffice/Makefile.
Currently, I've tried only 13 by putting
if ${.CURDIR:M/usr/ports/editors/libreoffice}
DEFAULT_VERSIONS+= llvm=13
.endif
lines on /etc/make.conf and it helped.
As some other giants such as www/chromium and www/firefox are using 13,
I suggest 13 here, too.
See details on Bug 263976, please.
On Sun, 22 May 2022 13:21:06 +0300
Dima Panov wrote:
> Moin!
>
> As maintainer of libreoffice I have my 2〓 to say.
>
> It builds fine on a recent -current with clang14,
> https://build.dimapanov.com/poudriere//data/140amd64-dimaports/2022-05-21_19h50m37s/logs/libreoffice-7.3.3.2_1.log
>
> However, all my own builds run without LTO enabled, it might matters
>
> On 22.05.2022 02:29, Tomoaki AOKI wrote:
> > Hi.
> > (CC'ing dim@ as dim@ would be the best person if it's base llvm
> > problem.)
> >
> > I've filed Bug 263976 [1] as Ports & Packages / Individual Port(s)
> > last week.
> >
> > But I'm still confusing whether...
> >*it is because of intentional change(s) on base llvm/clang
> > that editors/libreoffice team should chase,
> >
> >*or problem on base llvm/clang14 accidentally introduced.
> >
> > There were no feedback at all until now.
> > Any ideas?
> >
> > The failure mode is
> >
> >error: no viable conversion from 'StrictNumeric' to 'float'
> >
> > The workaround without editing port Makefile is to set
> >DEFAULT_VERSIONS+= llvm=13
> > for editors/libreoffice on /etc/make.conf with conditinal.
> >
> > Please visit the mentioned PR for more detail.
> >
> >
> > [1]https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263976
> >
> > Regards.
> >
> --
> Sincerely,
> Dima (flu...@freebsd.org,https://t.me/dima_panov)
> (desktop, kde, x11, office, ports-secteam)@FreeBSD team
>
--
青木 知明 [Tomoaki AOKI]
Re: no hw.acpi.video.lcd0 with graphics/drm-510-kmod
On 5/23/22 00:37, Emmanuel Vadot wrote: On Sun, 22 May 2022 09:08:12 -0700 Pete Wright wrote: hello, i have a lenovo P43s laptop running current. i've noticed that since graphics/drm-510-kmod became available hw.acpi.video.lcd0 ceases to exist (which makes it impossible to adjust screen brightness). i've installed graphics/drm-54-kmod and things work as expected. previously i was running drm-devel-kmod without issues, so i think it's probably an issue with the 5.10 driver? i can file a bug report for this (or just test out patches here if that's easier), but wanted to see if anyone here had observed this on other laptops first. cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA Not sure what's happening as this sysctl is exposed by acpi_video(4) and not related to drm. But you shouldn't need this, backlight(8) should work everywhere once drm is loaded. yea that's why i was confused, i investigated acpi_video changes and didn't see anything obvious. before i started trying to bisect recent acpi changes i thought it would be a good idea to test the drm-54-kmod port, which restored that sysctl knob. sounds like i should continue to try to bisect the acpi kernel changes under 5.10 and see what i can find though. cheers, -p -- Pete Wright p...@nomadlogic.org @nomadlogicLA
Re: no hw.acpi.video.lcd0 with graphics/drm-510-kmod
On Sun, 22 May 2022 09:08:12 -0700 Pete Wright wrote: > hello, > i have a lenovo P43s laptop running current. i've noticed that since > graphics/drm-510-kmod became available hw.acpi.video.lcd0 ceases to > exist (which makes it impossible to adjust screen brightness). i've > installed graphics/drm-54-kmod and things work as expected. previously > i was running drm-devel-kmod without issues, so i think it's probably an > issue with the 5.10 driver? > > i can file a bug report for this (or just test out patches here if > that's easier), but wanted to see if anyone here had observed this on > other laptops first. > > cheers, > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > Not sure what's happening as this sysctl is exposed by acpi_video(4) and not related to drm. But you shouldn't need this, backlight(8) should work everywhere once drm is loaded. Cheers, -- Emmanuel Vadot
Re: no hw.acpi.video.lcd0 with graphics/drm-510-kmod
Il giorno dom 22 mag 2022 alle ore 18:08 Pete Wright ha scritto: > hello, > i have a lenovo P43s laptop running current. i've noticed that since > graphics/drm-510-kmod became available hw.acpi.video.lcd0 ceases to > exist (which makes it impossible to adjust screen brightness). i've > installed graphics/drm-54-kmod and things work as expected. previously > i was running drm-devel-kmod without issues, so i think it's probably an > issue with the 5.10 driver? > > i can file a bug report for this (or just test out patches here if > that's easier), but wanted to see if anyone here had observed this on > other laptops first. > > cheers, > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > > Hello, to adjust screen brightness, on a Lenovo ThinkPad T450, I use the graphics/intel-backlight port. Regards, Maurizio
