Re: В ответ на: Re: editors/libreoffice PDF export/printing broken

[Jesper Schmitz Mouridsen]

Accidentally found on twitter

Colin Percival
@cperciva


In case anyone else (including future-me) runs into the same problem: If 
LibreOffice"export to PDF" produces pages without any text, set 
"SAL_VCL_QT5_USE_CAIRO=true" in the environment. No, I have no idea why. 
Ran into this on FreeBSD; found the fix on the Lubuntu forum.

On 22.06.2020 20.26, Kostya Berger wrote:

No need to pkg upgrade. They are all freshly installed from official repo. 
Clean install, new fresh user.
The same in my second install, Synth built local repo. Same thing.
And I'm talking about the PDF button in LO interface. Or File> Export to PDF.


Отправлено из Yahoo Почты для Android
  
   пн, 22 июн. 2020 в 20:22 Gleb Popov<6year...@gmail.com> написал(-а):   On Mon, Jun 22, 2020 at 9:04 PM Kostya Berger  wrote:



r362292In editors/libreoffice 6.4.4 PDF export is broken, including also
PDF print to file. Tried with locally built 6.4.4 and pre-built package
6.4.4.2 from official repo (separate installation for testing purposes).
Symptoms: of all content only graphics/tables elements get exported to
PDF. No text. PS printing is all right.As regards PDF printing to file in
general, it still works fine in Firefox. Only LO is affected. I filed a bug
report as well.

With kindest regards,
Kostya Berger


Hum, can't reproduce this on my side. Can you do `pkg upgrade`, maybe some
dependency is out of date?
___
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"

vidcontrol < /dev/console -i active ioctl error

[Jesper Schmitz Mouridsen]

FreeBSD build.freebsd.lan 13.0-ALPHA1 FreeBSD 13.0-ALPHA1 #0 
main-c255938-g7ae27c2d6c4: Thu Jan 14 06:29:55 UTC 2021 
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

jesper@build:~ $ su
Password:
root@build:~ # vidcontrol < /dev/console -i active
vidcontrol: getting active vty: Inappropriate ioctl for device

build is virtualized in bhyve, it happens as well on my pinebook pro.

This is annoying to sysutils/consolekit2

on 12.2 it works (not tested on same HW)

___
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: vidcontrol < /dev/console -i active ioctl error

[Jesper Schmitz Mouridsen]

On 28.01.2021 08.33, Toomas Soome wrote:



On 28. Jan 2021, at 01:35, Jesper Schmitz Mouridsen <mailto:j...@freebsd.org>> wrote:


FreeBSD build.freebsd.lan 13.0-ALPHA1 FreeBSD 13.0-ALPHA1 #0 
main-c255938-g7ae27c2d6c4: Thu Jan 14 06:29:55 UTC 2021 
r...@releng1.nyi.freebsd.org 
<mailto:r...@releng1.nyi.freebsd.org>:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64

jesper@build:~ $ su
Password:
root@build:~ # vidcontrol < /dev/console -i active
vidcontrol: getting active vty: Inappropriate ioctl for device

build is virtualized in bhyve, it happens as well on my pinebook pro.

This is annoying to sysutils/consolekit2

on 12.2 it works (not tested on same HW)



it should work for local console:

root@freebsd:/usr/src #vidcontrol -i active < /dev/console
1

may it be your “primary” is actually serial console?

rgds,
toomas



Oh that makes sense, I added console="vidconsole,comconsole" to my 
/boot/loader.conf on the Pinebook Pro


and consolekit2 works.

Thanks

/Jsm

___
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: Today's 13-STABLE panic on boot

[Jesper Schmitz Mouridsen]

From man rtsx

  •   RTS522A on Lenovo P50s and Lenovo T470p, card detection and read-only
   switch are reversed.  This is sovled by adding in loader.conf(5):

    dev.rtsx.0.inversion=1

Perhaps this applies to Thinkpad T440p as well?

On 06.02.2021 13.51, Oleh Hushchenkov wrote:

As a workaround I disabled Realtek SD card reader RTS5227 in BIOS. Now
system boots fine. However not all laptops have the setting to disable
integrated devices...

On Sat, Feb 6, 2021, 1:23 PM Oleh Hushchenkov 
wrote:


Looks like attached image was removed from the message. I uploaded it
https://imgur.com/a/Kv1l1pB

On Sat, Feb 6, 2021, 11:42 AM Oleh Hushchenkov 
wrote:


On cold boot I got this panic, photo attached. Strange thing. After
enabling verbose logging system successfully booted and next reboots also
works without verbose logging. My hardware is ThinkPad T440p.


___
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: Problems with realtek NIC

[Jesper Schmitz Mouridsen]

On 01.05.2021 21.09, Nilton Jose Rizzo wrote:

Hi all

I using a FreeBSD 14-Current and get random error with my NIC. The watchdog 
timer send a timeout message and I loose connection temporaly. In logs show 
only this message:

May  1 14:24:18 valfenda kernel: re0: watchdog timeout
May  1 14:24:18 valfenda kernel: re0: link state changed to DOWN
May  1 14:24:22 valfenda kernel: re0: link state changed to UP
May  1 14:46:12 valfenda kernel: re0: watchdog timeout
May  1 14:46:12 valfenda kernel: re0: link state changed to DOWN
May  1 14:46:16 valfenda kernel: re0: link state changed to UP
May  1 14:58:58 valfenda kernel: re0: watchdog timeout
May  1 14:58:58 valfenda kernel: re0: link state changed to DOWN
May  1 14:59:02 valfenda kernel: re0: link state changed to UP
May  1 15:06:20 valfenda kernel: re0: watchdog timeout
May  1 15:06:20 valfenda kernel: re0: link state changed to DOWN
May  1 15:06:25 valfenda kernel: re0: link state changed to UP
May  1 15:25:32 valfenda kernel: re0: watchdog timeout
May  1 15:25:32 valfenda kernel: re0: link state changed to DOWN
May  1 15:25:36 valfenda kernel: re0: link state changed to UP
May  1 15:28:24 valfenda kernel: re0: watchdog timeout
May  1 15:28:24 valfenda kernel: re0: link state changed to DOWN
May  1 15:28:28 valfenda kernel: re0: link state changed to UP

This occur frequently when i use a Mozilla Firefox in meet session, but not 
only in this case.

My box:

% uname -a
FreeBSD valfenda 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-7ea3223c7: Thu Apr 
22 13:24:05 -03 2021 
rizzo@valfenda:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
% pkg info -a | grep firefox
firefox-88.0,2 Web browser based on the browser portion of 
Mozilla
% kldstat
Id Refs AddressSize Name
  1   85 0x8020  2131010 kernel
  21 0x82333000 91d0 cryptodev.ko
  31 0x8233d000   7cae50 zfs.ko
  41 0x8301 d940 geom_eli.ko
  51 0x8301e000 3530 fdescfs.ko
  61 0x83022000 3378 acpi_wmi.ko
  71 0x83026000 3218 intpm.ko
  81 0x8302a000 2180 smbus.ko
  91 0x8302d000   10b310 nvidia-modeset.ko
101 0x8320  1e834a8 nvidia.ko
112 0x83139000378f8 linux.ko
123 0x83171000 db70 linux_common.ko
131 0x8317f000 3238 filemon.ko
141 0x83183000 5730 cuse.ko
151 0x83189000 3160 amdtemp.ko
161 0x8318d000 2138 amdsmn.ko
171 0x8319 e538 snd_uaudio.ko
181 0x8319f000 2340 uhid.ko
191 0x831a2000 2380 usbhid.ko
201 0x831a5000 31f8 hidbus.ko
211 0x831a9000 3320 wmt.ko
221 0x831ad000 4350 ums.ko
231 0x831b200027040 ipfw.ko
241 0x831da0001ae88 ext2fs.ko
251 0x8508400011f10 fusefs.ko
261 0x831f5000 5354 geom_linux_lvm.ko
271 0x8509600056ec0 vboxdrv.ko
%

TIA,
Rizzo
___
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"

Back on 12 net/realtek-re-kmod solved it for me.

With the following in /boot/loader.conf

if_re_load="YES"
if_re_name="/boot/modules/if_re.ko"
___
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 crashes at early boot on Lenovo T540p: rtsx to blame

[Jesper Schmitz Mouridsen]

On 07.05.2021 13.33, Lev Serebryakov wrote:


Several versions of 14-CURRENT (including 
FreeBSD-14.0-CURRENT-amd64-20210506-49c894ddced-246502-memstick.img) 
can not boot on Lenovo T540p 19 times out of 20.


It crashes on device detection, after detecting sound subsystem, with 
traps 9 and 12 (9 is more often) and mostly with this stacktrace (9 
out of 10 crashes have this stacktrace:


Perhaps similar to bug reported here 
https://forums.freebsd.org/threads/boot-timeout-error-on-rtsx-freebsd-13-0-hp-840-g3.80031/#post-508072 



https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255130

Do you happen to have an empty adapter (sd->micro sd) inserted in the 
slot. That causes a card-inserted interrupt, on all the realtek sd-card 
readers I have touched.


Regards


-- trap
run_interrupt_driven_config_hooks()
boot_run_interrupt_driven_config_hooks()
mi_startup()
btext()


But twice I've got more interesting stacktraces:

-- trap
strlen()
kvprintf()
vsnprintf()
vpanic()
panic()
__mtx_lock_flags()
_sleep()
mmc_wait_for_request()
mmc_wait_for_cmd()
mmc_go_discovery()
mmc_delayed_attach()
run_interrupt_driven_config_hooks()
boot_run_interrupt_driven_config_hooks()
mi_startup()
btext()

--- trap
__mtx_lock_sleep()
__mtx_lock_flags()
mmc_wakeup()
rtsx_intr()
ithread_loop()
fork_exit()
fork_trampoline()

 Looks like there is problem with rtsx driver!

 I've checked memory with memtest86+ for 24 hours (4.5 passes) without 
any problems.



___
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"

bsddialog cannot crosscompile to arm64 from amd64 -lformw not found.

[Jesper Schmitz Mouridsen]

/usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/lib/libbsddialog/.depend, 
1: ignoring stale .depend for 
/usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/tmp/usr/lib/libformw.a




--- libprivatebsddialog.so.0.full ---
building shared library libprivatebsddialog.so.0
cc -target aarch64-unknown-freebsd14.0 
--sysroot=/usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/tmp 
-B/usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/tmp/usr/bin 
   -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings 
-Wl,--warn-shared-textrel  -o libprivatebsddialog.so.0.full 
-Wl,-soname,libprivatebsddialog.so.0 barbox.pico commandbox.pico 
editorbox.pico filebox.pico formbox.pico infobox.pico lib_util.pico 
libbsddialog.pico menubox.pico messagebox.pico textbox.pico theme.pico 
timebox.pico  -lncursesw  -ltinfow  -lformw

--- all_subdir_lib/ofed ---
--- all_subdir_lib/ofed/libibnetdisc ---
===> lib/ofed/libibnetdisc (all)
--- all_subdir_lib/libbsddialog ---
ld: error: unable to find library -lformw


Same error here
https://github.com/freebsd/freebsd-src/runs/4314231703

/jsm

Re: bsddialog cannot crosscompile to arm64 from amd64 -lformw not found.

[Jesper Schmitz Mouridsen]

fixed by emaste in 483a226238ed8949c6d280ae0757a0683962a74b

On 24.11.2021 19.29, Jesper Schmitz Mouridsen wrote:
/usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/lib/libbsddialog/.depend, 
1: ignoring stale .depend for 
/usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/tmp/usr/lib/libformw.a 





--- libprivatebsddialog.so.0.full ---
building shared library libprivatebsddialog.so.0
cc -target aarch64-unknown-freebsd14.0 
--sysroot=/usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/tmp 
-B/usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/tmp/usr/bin 
    -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings 
-Wl,--warn-shared-textrel  -o libprivatebsddialog.so.0.full 
-Wl,-soname,libprivatebsddialog.so.0 barbox.pico commandbox.pico 
editorbox.pico filebox.pico formbox.pico infobox.pico lib_util.pico 
libbsddialog.pico menubox.pico messagebox.pico textbox.pico theme.pico 
timebox.pico  -lncursesw  -ltinfow  -lformw

--- all_subdir_lib/ofed ---
--- all_subdir_lib/ofed/libibnetdisc ---
===> lib/ofed/libibnetdisc (all)
--- all_subdir_lib/libbsddialog ---
ld: error: unable to find library -lformw


Same error here
https://github.com/freebsd/freebsd-src/runs/4314231703

/jsm

Re: randomdev hangs during initial boot of -current on Raspberry Pi

[Jesper Schmitz Mouridsen]

On 31.01.2022 22.20, Mark Millard wrote:

Mike Karels  wrote on
Date: Mon, 31 Jan 2022 12:27:41 -0600 :


A bisect
would be rather laborious, building a modified SD card each time,
even if just testing kernel changes.  Any other suggestions?


Historically I've used:

https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D

and the likes of kernel.txz (or more) from, for example:

https://artifact.ci.freebsd.org/snapshot/main/b4cc5d63b6112746598d21413c9800a43171da52/arm64/aarch64/?C=M&O=D

to update just the kernel (or whatever) and rebooted.
(It can help to have a somewhat older world that is
left in place instead of running newer worlds on older
kernels. Avoiding needing got update world as well has
been helpful when testing for kernel issues.)

This avoids building the kernels and allows a somewhat
bisect like activity until some subrange has no
arm64/aarch64 artifacts available.

One can sometimes run into the dates for the sort for:

https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D

not matching up well with the dates on the files of
interest in specific sub directoreis. (Some sort of
directory update?) This can make the bisect far more
difficult, given the choice to not have the directory
names prefixed with text that would sort by a
date/time estimate when sorted by name. (Only using
the commit id/hash completely randomizes the naming.)


===
Mark Millard
marklmi at yahoo.com



Hi
My bisect gives:
The latest working is:
dda9847275da79ccbb2f0b7079b250e28b3b3b2a
The excact following commit:
74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is bad.
So  74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is where the problem starts 
for me.
Hope that someone can explain why 
74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 does block entropy/random 
seeding on first boot around growfs invocation on arm64

/Jsm

d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks sys/arm64/iommu/iommu_pmap.c

[Jesper Schmitz Mouridsen]

Hi
d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks arm64 with options IOMMU.

grep -nir vm_page.h sys/arm64/iommu/iommu_pmap.c
sys/arm64/iommu/iommu_pmap.c:50:#include 


/usr/src/sys/arm64/iommu/iommu_pmap.c:539:52: error: implicit 
declaration of function 'UINT64_C' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]

./machine/pte.h:53:21: note: expanded from macro 'ATTR_MASK'
#define ATTR_MASK   (ATTR_MASK_H | ATTR_MASK_L)
 ^
./machine/pte.h:51:22: note: expanded from macro 'ATTR_MASK_H'
#define ATTR_MASK_H UINT64_C(0xfffc)


How best to fix this? #include  in iommu_pmap.c?

Thanks
/jsm

Re: d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks sys/arm64/iommu/iommu_pmap.c

[Jesper Schmitz Mouridsen]

On 03.02.2022 11.59, Konstantin Belousov wrote:

On Thu, Feb 03, 2022 at 11:52:48AM +0100, Jesper Schmitz Mouridsen wrote:

Hi
d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks arm64 with options IOMMU.

Which kernel config is it?  Or is it your custom config?
If the later, please provide it to me.


grep -nir vm_page.h sys/arm64/iommu/iommu_pmap.c
sys/arm64/iommu/iommu_pmap.c:50:#include 


/usr/src/sys/arm64/iommu/iommu_pmap.c:539:52: error: implicit declaration of
function 'UINT64_C' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
./machine/pte.h:53:21: note: expanded from macro 'ATTR_MASK'
#define ATTR_MASK   (ATTR_MASK_H | ATTR_MASK_L)
  ^
./machine/pte.h:51:22: note: expanded from macro 'ATTR_MASK_H'
#define ATTR_MASK_H UINT64_C(0xfffc)


How best to fix this? #include  in iommu_pmap.c?

If the issue is with UINT64_C() only, perhaps something like sys/stdint.h
inclusion is enough.


That was enough.

https://reviews.freebsd.org/D34155

Thanks

/jsm

Re: randomdev hangs during initial boot of -current on Raspberry Pi

[Jesper Schmitz Mouridsen]

On 03.02.2022 02.06, Kyle Evans wrote:

On Wed, Feb 2, 2022 at 10:50 AM Kyle Evans  wrote:

On Wed, Feb 2, 2022 at 3:41 AM Jesper Schmitz Mouridsen  
wrote:



On 31.01.2022 22.20, Mark Millard wrote:

Mike Karels  wrote on
Date: Mon, 31 Jan 2022 12:27:41 -0600 :


A bisect
would be rather laborious, building a modified SD card each time,
even if just testing kernel changes.  Any other suggestions?

Historically I've used:

https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D

and the likes of kernel.txz (or more) from, for example:

https://artifact.ci.freebsd.org/snapshot/main/b4cc5d63b6112746598d21413c9800a43171da52/arm64/aarch64/?C=M&O=D

to update just the kernel (or whatever) and rebooted.
(It can help to have a somewhat older world that is
left in place instead of running newer worlds on older
kernels. Avoiding needing got update world as well has
been helpful when testing for kernel issues.)

This avoids building the kernels and allows a somewhat
bisect like activity until some subrange has no
arm64/aarch64 artifacts available.

One can sometimes run into the dates for the sort for:

https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D

not matching up well with the dates on the files of
interest in specific sub directoreis. (Some sort of
directory update?) This can make the bisect far more
difficult, given the choice to not have the directory
names prefixed with text that would sort by a
date/time estimate when sorted by name. (Only using
the commit id/hash completely randomizes the naming.)


===
Mark Millard
marklmi at yahoo.com



Hi
My bisect gives:
The latest working is:
dda9847275da79ccbb2f0b7079b250e28b3b3b2a
The excact following commit:
74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is bad.
So  74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is where the problem starts
for me.
Hope that someone can explain why
74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 does block entropy/random
seeding on first boot around growfs invocation on arm64
/Jsm


That seems odd, but CC'ing jhb@ -- maybe there's something hinky going
on since this is before AP startup for arm.

I poked jhb out-of-band and we tracked it down to callouts having been
a major source of entropy for early boot via SWI; tentative fix
pending here: https://reviews.freebsd.org/D34150

Thanks,

Kyle Evans


I can confirm it works on  arm64 (Pinebook Pro)

Thanks!

Re: archivers/arj fails to build on jail

[Jesper Schmitz Mouridsen]

On 29.08.2022 17.29, Renato Botelho wrote:
There is a PR [1] opened for years reporting arj fails to build on a 
jail.  Recently I reproduced it on a system running CURRENT.


I just launched a jail and tried to build it, and got the error as 
described:

Did you use ezjail?

I tried to replicate and I think the error is triggered by
the nullfs usage of ezjail. I copied the settings of ezjail without
nullfs usage (using the basejail as path adding etc from the failing 
jail to it and removing the fstab from jail.conf) and arj did get a 
working msgbind.


gmake[3]: *** [GNUmakefile:258: freebsd12.1/en/rs/msg_crp.h] Abort trap

msgbind binary built inside arj, when called, ends like this.  I has no 
clue about what could be the root cause here.  I also don't understand 
why arj builds fine on poudriere, which uses jail as well.


If anyone has any idea about what could be causing this, please let me 
know.


[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235636

Re: archivers/arj fails to build on jail

[Jesper Schmitz Mouridsen]

On 30.08.2022 13.17, Renato Botelho wrote:

On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote:



On 29.08.2022 17.29, Renato Botelho wrote:
There is a PR [1] opened for years reporting arj fails to build on a 
jail.  Recently I reproduced it on a system running CURRENT.


I just launched a jail and tried to build it, and got the error as 
described:

Did you use ezjail?

I tried to replicate and I think the error is triggered by
the nullfs usage of ezjail. I copied the settings of ezjail without
nullfs usage (using the basejail as path adding etc from the failing 
jail to it and removing the fstab from jail.conf) and arj did get a 
working msgbind.


Yes, I also use ezjail.  I'm cc'ing ezjail's maintainer to see if we 
can get some advice.


Thanks!


Hi again.


I narrowed this down to  symlinks ,wiithin the jail, to the nullfs 
mountpoint.


Replacing symlinks to the basejail mount point with dirs and setting 
this in the fstab of the jail


and msgbind is a valid executable

/usr/jails/basejail/bin /usr/jails/test1/bin nullfs ro 0 0
/usr/jails/basejail/boot /usr/jails/test1/boot nullfs ro 0 0
/usr/jails/basejail/lib /usr/jails/test1/lib nullfs ro 0 0
/usr/jails/basejail/libexec /usr/jails/test1/libexec nullfs ro 0 0
/usr/jails/basejail/rescue /usr/jails/test1/rescue nullfs ro 0 0
/usr/jails/basejail/sbin /usr/jails/test1/sbin nullfs ro 0 0
/usr/jails/basejail/usr/bin /usr/jails/test1/usr/bin nullfs ro 0 0
/usr/jails/basejail/usr/lib /usr/jails/test1/usr/lib nullfs ro 0 0
/usr/jails/basejail/usr/include /usr/jails/test1/usr/include nullfs ro 0 0
/usr/jails/basejail/usr/lib32 /usr/jails/test1/usr/lib32 nullfs ro 0 0
/usr/jails/basejail/usr/ports /usr/jails/test1/usr/ports nullfs ro 0 0
/usr/jails/basejail/usr/libdata /usr/jails/test1/usr/libdata nullfs ro 0 0
/usr/jails/basejail/usr/sbin /usr/jails/test1/usr/sbin nullfs ro 0 0
/usr/jails/basejail/usr/share /usr/jails/test1/usr/share nullfs ro 0 0
/usr/jails/basejail/usr/libexec /usr/jails/test1/usr/libexec nullfs ro 0 0
/usr/jails/basejail/usr/src /usr/jails/test1/usr/src nullfs ro 0 0

It should be further narrowed down but nullfs alone is not the issue.



gmake[3]: *** [GNUmakefile:258: freebsd12.1/en/rs/msg_crp.h] Abort trap

msgbind binary built inside arj, when called, ends like this. I has 
no clue about what could be the root cause here.  I also don't 
understand why arj builds fine on poudriere, which uses jail as well.


If anyone has any idea about what could be causing this, please let 
me know.


[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235636

Re: archivers/arj fails to build on jail

[Jesper Schmitz Mouridsen]

On 30.08.2022 18.03, Renato Botelho wrote:

On 30/08/22 12:39, Renato Botelho wrote:

On 30/08/22 11:35, Jesper Schmitz Mouridsen wrote:


On 30.08.2022 13.17, Renato Botelho wrote:

On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote:



On 29.08.2022 17.29, Renato Botelho wrote:
There is a PR [1] opened for years reporting arj fails to build 
on a jail.  Recently I reproduced it on a system running CURRENT.


I just launched a jail and tried to build it, and got the error 
as described:

Did you use ezjail?

I tried to replicate and I think the error is triggered by
the nullfs usage of ezjail. I copied the settings of ezjail without
nullfs usage (using the basejail as path adding etc from the 
failing jail to it and removing the fstab from jail.conf) and arj 
did get a working msgbind.


Yes, I also use ezjail.  I'm cc'ing ezjail's maintainer to see if 
we can get some advice.


Thanks!


Hi again.


I narrowed this down to  symlinks ,wiithin the jail, to the nullfs 
mountpoint.


Replacing symlinks to the basejail mount point with dirs and setting 
this in the fstab of the jail


and msgbind is a valid executable

/usr/jails/basejail/bin /usr/jails/test1/bin nullfs ro 0 0
/usr/jails/basejail/boot /usr/jails/test1/boot nullfs ro 0 0
/usr/jails/basejail/lib /usr/jails/test1/lib nullfs ro 0 0
/usr/jails/basejail/libexec /usr/jails/test1/libexec nullfs ro 0 0
/usr/jails/basejail/rescue /usr/jails/test1/rescue nullfs ro 0 0
/usr/jails/basejail/sbin /usr/jails/test1/sbin nullfs ro 0 0
/usr/jails/basejail/usr/bin /usr/jails/test1/usr/bin nullfs ro 0 0
/usr/jails/basejail/usr/lib /usr/jails/test1/usr/lib nullfs ro 0 0
/usr/jails/basejail/usr/include /usr/jails/test1/usr/include nullfs 
ro 0 0

/usr/jails/basejail/usr/lib32 /usr/jails/test1/usr/lib32 nullfs ro 0 0
/usr/jails/basejail/usr/ports /usr/jails/test1/usr/ports nullfs ro 0 0
/usr/jails/basejail/usr/libdata /usr/jails/test1/usr/libdata nullfs 
ro 0 0

/usr/jails/basejail/usr/sbin /usr/jails/test1/usr/sbin nullfs ro 0 0
/usr/jails/basejail/usr/share /usr/jails/test1/usr/share nullfs ro 0 0
/usr/jails/basejail/usr/libexec /usr/jails/test1/usr/libexec nullfs 
ro 0 0

/usr/jails/basejail/usr/src /usr/jails/test1/usr/src nullfs ro 0 0

It should be further narrowed down but nullfs alone is not the issue.


Interesting.  And just to add a note here, I copied msgbind from jail 
to host and tried to execute it to confirm binary was really bad and 
I got the same Abort trap message.




And one more interesting information is it builds fine with gcc. I 
just added USE_GCC=yes to the port and it worked.


if you inspect the output of realpath /usr/bin/cc i think we are close 
to a cause.. it includes /basejail in my setup.. if you copy cc out of 
basejail e.g /usr/local/bin and make CC=/usr/local/bin it also works..


perhaps some linking  of msgbind fails because of "wrong" realpath...

Re: archivers/arj fails to build on jail

[Jesper Schmitz Mouridsen]

On 30.08.2022 18.45, Jesper Schmitz Mouridsen wrote:


On 30.08.2022 18.03, Renato Botelho wrote:

On 30/08/22 12:39, Renato Botelho wrote:

On 30/08/22 11:35, Jesper Schmitz Mouridsen wrote:


On 30.08.2022 13.17, Renato Botelho wrote:

On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote:



On 29.08.2022 17.29, Renato Botelho wrote:
There is a PR [1] opened for years reporting arj fails to build 
on a jail.  Recently I reproduced it on a system running CURRENT.


I just launched a jail and tried to build it, and got the error 
as described:

Did you use ezjail?

I tried to replicate and I think the error is triggered by
the nullfs usage of ezjail. I copied the settings of ezjail without
nullfs usage (using the basejail as path adding etc from the 
failing jail to it and removing the fstab from jail.conf) and arj 
did get a working msgbind.


Yes, I also use ezjail.  I'm cc'ing ezjail's maintainer to see if 
we can get some advice.


Thanks!


Hi again.


I narrowed this down to  symlinks ,wiithin the jail, to the nullfs 
mountpoint.


Replacing symlinks to the basejail mount point with dirs and setting 
this in the fstab of the jail


and msgbind is a valid executable

/usr/jails/basejail/bin /usr/jails/test1/bin nullfs ro 0 0
/usr/jails/basejail/boot /usr/jails/test1/boot nullfs ro 0 0
/usr/jails/basejail/lib /usr/jails/test1/lib nullfs ro 0 0
/usr/jails/basejail/libexec /usr/jails/test1/libexec nullfs ro 0 0
/usr/jails/basejail/rescue /usr/jails/test1/rescue nullfs ro 0 0
/usr/jails/basejail/sbin /usr/jails/test1/sbin nullfs ro 0 0
/usr/jails/basejail/usr/bin /usr/jails/test1/usr/bin nullfs ro 0 0
/usr/jails/basejail/usr/lib /usr/jails/test1/usr/lib nullfs ro 0 0
/usr/jails/basejail/usr/include /usr/jails/test1/usr/include nullfs 
ro 0 0

/usr/jails/basejail/usr/lib32 /usr/jails/test1/usr/lib32 nullfs ro 0 0
/usr/jails/basejail/usr/ports /usr/jails/test1/usr/ports nullfs ro 0 0
/usr/jails/basejail/usr/libdata /usr/jails/test1/usr/libdata nullfs 
ro 0 0

/usr/jails/basejail/usr/sbin /usr/jails/test1/usr/sbin nullfs ro 0 0
/usr/jails/basejail/usr/share /usr/jails/test1/usr/share nullfs ro 0 0
/usr/jails/basejail/usr/libexec /usr/jails/test1/usr/libexec nullfs 
ro 0 0

/usr/jails/basejail/usr/src /usr/jails/test1/usr/src nullfs ro 0 0

It should be further narrowed down but nullfs alone is not the issue.


Interesting.  And just to add a note here, I copied msgbind from jail 
to host and tried to execute it to confirm binary was really bad and 
I got the same Abort trap message.




And one more interesting information is it builds fine with gcc. I 
just added USE_GCC=yes to the port and it worked.


if you inspect the output of realpath /usr/bin/cc i think we are close 
to a cause.. it includes /basejail in my setup.. if you copy cc out of 
basejail e.g /usr/local/bin and make CC=/usr/local/bin it also works..


perhaps some linking  of msgbind fails because of "wrong" realpath...


That even manifests without a jail so moving /usr/bin to 
/something/usr/bin and having /usr/bin as a śyḿlink to 
/something/usr/bin breaks the port

Re: archivers/arj fails to build on jail

[Jesper Schmitz Mouridsen]

A rude patch.

--- Makefile.orig   2022-08-30 22:43:09.142346000 +0200
+++ Makefile2022-08-30 22:44:54.509741000 +0200
@@ -60,6 +60,7 @@
@${REINPLACE_CMD} -e 's!-O2!!' -e 's!ALIGN_POINTERS!&,1,desc!' \
-e 's!USE_COLORS!&,1,desc!' ${WRKSRC}/gnu/configure.in
@${REINPLACE_CMD} -e 's!^static !!' ${WRKSRC}/integr.c
+   @${REINPLACE_CMD} -e s/'LD_STRIP="gnu\/stripgcc.lnk"'/''/ 
${WRKSRC}/gnu/configure.in


 post-install:
@${MKDIR} ${STAGEDIR}${DOCSDIR}


On 30.08.2022 18.45, Jesper Schmitz Mouridsen wrote:


On 30.08.2022 18.03, Renato Botelho wrote:

On 30/08/22 12:39, Renato Botelho wrote:

On 30/08/22 11:35, Jesper Schmitz Mouridsen wrote:


On 30.08.2022 13.17, Renato Botelho wrote:

On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote:



On 29.08.2022 17.29, Renato Botelho wrote:
There is a PR [1] opened for years reporting arj fails to build 
on a jail.  Recently I reproduced it on a system running CURRENT.


I just launched a jail and tried to build it, and got the error 
as described:

Did you use ezjail?

I tried to replicate and I think the error is triggered by
the nullfs usage of ezjail. I copied the settings of ezjail without
nullfs usage (using the basejail as path adding etc from the 
failing jail to it and removing the fstab from jail.conf) and arj 
did get a working msgbind.


Yes, I also use ezjail.  I'm cc'ing ezjail's maintainer to see if 
we can get some advice.


Thanks!


Hi again.


I narrowed this down to  symlinks ,wiithin the jail, to the nullfs 
mountpoint.


Replacing symlinks to the basejail mount point with dirs and setting 
this in the fstab of the jail


and msgbind is a valid executable

/usr/jails/basejail/bin /usr/jails/test1/bin nullfs ro 0 0
/usr/jails/basejail/boot /usr/jails/test1/boot nullfs ro 0 0
/usr/jails/basejail/lib /usr/jails/test1/lib nullfs ro 0 0
/usr/jails/basejail/libexec /usr/jails/test1/libexec nullfs ro 0 0
/usr/jails/basejail/rescue /usr/jails/test1/rescue nullfs ro 0 0
/usr/jails/basejail/sbin /usr/jails/test1/sbin nullfs ro 0 0
/usr/jails/basejail/usr/bin /usr/jails/test1/usr/bin nullfs ro 0 0
/usr/jails/basejail/usr/lib /usr/jails/test1/usr/lib nullfs ro 0 0
/usr/jails/basejail/usr/include /usr/jails/test1/usr/include nullfs 
ro 0 0

/usr/jails/basejail/usr/lib32 /usr/jails/test1/usr/lib32 nullfs ro 0 0
/usr/jails/basejail/usr/ports /usr/jails/test1/usr/ports nullfs ro 0 0
/usr/jails/basejail/usr/libdata /usr/jails/test1/usr/libdata nullfs 
ro 0 0

/usr/jails/basejail/usr/sbin /usr/jails/test1/usr/sbin nullfs ro 0 0
/usr/jails/basejail/usr/share /usr/jails/test1/usr/share nullfs ro 0 0
/usr/jails/basejail/usr/libexec /usr/jails/test1/usr/libexec nullfs 
ro 0 0

/usr/jails/basejail/usr/src /usr/jails/test1/usr/src nullfs ro 0 0

It should be further narrowed down but nullfs alone is not the issue.


Interesting.  And just to add a note here, I copied msgbind from jail 
to host and tried to execute it to confirm binary was really bad and 
I got the same Abort trap message.




And one more interesting information is it builds fine with gcc. I 
just added USE_GCC=yes to the port and it worked.


if you inspect the output of realpath /usr/bin/cc i think we are close 
to a cause.. it includes /basejail in my setup.. if you copy cc out of 
basejail e.g /usr/local/bin and make CC=/usr/local/bin it also works..


perhaps some linking  of msgbind fails because of "wrong" realpath...

Re: FreeBSD 14.0-BETA5 Now Available

[Jesper Schmitz Mouridsen]

On 16.10.2023 13.53, Ed Maste wrote:

On Sat, 7 Oct 2023 at 13:35, György Pásztor  wrote:


Hi Glen,

The new betas broke the functionality to boot from ventoy.


Unfortunately the way Ventoy handles FreeBSD booting is somewhat
fragile and this sort of breakage is not surprising. I suspect the
Ventoy authors will have to release an update to support 14.0.

I am interested in looking for a way to make Ventoy support more
reliable, but that will not happen for 14.0.


If you build the
Ventoy/Unix/ventoy_unix_src/FreeBS/geom_ventoy_src/13.x/sys/

on 14.0 and compress it with xz and place it in place in the 
ventoy/ventoy_unix.cpio archive it boots FreeBSD 14.0-RC2


Note that my ventoy iso partition is reformatted to fat32.

Without the rebuild I get

KDB: stack backtrace:
#0 0x80b8ff9d at kdb_backtrace+0x5d
#1 0x80b430a2 at vpanic+0x132
#2 0x80b42f63 at panic+0x43
#3 0x80eb24a5 at vm_fault+0x15c5
#4 0x80eb0e10 at vm_fault_trap+0xb0
#5 0x8100ca19 at trap_pfault+0x1d9
#6 0x80fe3268 at calltrap+0x8
#7 0x8037b023 at btext+0x23
Uptime: 1s

/Jsm

evdev no /dev/input FreeBSD 12.0-CURRENT #0 r311461

[Jesper Schmitz Mouridsen]

Hello.

I'm new to using current and to posting here. 
I've  a old spare T60 1951-FEG wiith Intel Graphics Media Accelerator 950 
(info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0).

Intel Core 2 Duo (Merom) T5600.
My goal is to try out weston /wayland from xserver-mesa-next-udev [2]
but on offical branch current
$ kldstat
Id Refs AddressSize Name
1   40 0x8020 202f8a0  kernel
21 0x82231000 1051b0   i915kms.ko
32 0x82337000 55b0 iicbb.ko
45 0x8233d000 7050 iicbus.ko
52 0x82345000 45d0 iic.ko
62 0x8234a000 8a8c8drm2.ko
71 0x823d5000 d1f0 evdev.ko
81 0x82621000 36f6 ums.ko
91 0x82625000 4fca ng_ubt.ko
105 0x8262a000 ce99 netgraph.ko
111 0x82637000 a67e ng_hci.ko
123 0x82642000 10e7 ng_bluetooth.ko
131 0x82644000 e24e ng_l2cap.ko
141 0x82653000 1dff9ng_btsocket.ko
151 0x82671000 3c28 ng_socket.ko
(and cuse4bsd when using webcamd for input)
It works but I have to use webcamd for mouse and keyboard input through 
/dev/input/event* as in the "test plan" [3] e.g without evdev.


I'm on FreeBSD 12.0-CURRENT #0 r311461. My understanding is that 
evdev.ko evdev-enables the kernel, but I've got no /dev/input without

webcamd and cuse4bsd and webcamd -N 

TL;DR is FreeBSD 12.0-CURRENT #0 r311461 evdev enabled ?


1 [http://www.thinkwiki.org/wiki/Category:T60]
2 https://github.com/FreeBSDDesktop/freebsd-ports-graphics
3 https://reviews.freebsd.org/D7588
FreeBSD 12.0-CURRENT #0 r311461:\
Thu Jan  5 22:46:38 UTC 2017  \
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

___
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"