Re: When will the FreeBSD (u)EFI work?

On 30/03/2020 06:11, 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. I don't think that we ever did that, consciously. Installi

Re: When will the FreeBSD (u)EFI work?

On Sun, Mar 29, 2020 at 08:11:16PM -0700, 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

FreeBSD CI Weekly Report 2020-03-29

(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-03-29 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-03-23 to 2020-03-29. During this period, we have: * 1811 buil

Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

On Sat, Mar 28, 2020 at 02:15:29AM +0100, Julian H. Stacey wrote: > Ed Maste wrote: > > On Fri, 27 Mar 2020 at 20:48, Julian H. Stacey wrote: > > > > > > l /usr/src/contrib/kyua/doc/manbuild.sh > > > -rw-r--r-- 1 jhs staff 5187 Mar 25 12:34 > > > /usr/src/contrib/kyua/doc/manbuild.sh

Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

On Mon, 30 Mar 2020 at 11:33, Brooks Davis wrote: > > FWIW, we don't generally rely on +x and invoke the interperter directly > (to enable storing src on a noexec filesystm). I fixed the bug that > caused direct invocation of the script in r359426. Good point, we should probably add a CI run to

Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

Brooks Davis wrote: > > On Sat, Mar 28, 2020 at 02:15:29AM +0100, Julian H. Stacey wrote: > > Ed Maste wrote: > > > On Fri, 27 Mar 2020 at 20:48, Julian H. Stacey wrote: > > > > > > > > l /usr/src/contrib/kyua/doc/manbuild.sh > > > > -rw-r--r-- 1 jhs staff 5187 Mar 25 12:34 /usr/src/c

ZFS: lost the ability to boot a BE

I lost the ability to boot the environment named 'r357746', I suspect this occurred after I set it to use OpenZFS in lieu of ZFS. I would like to edit its /boot/loader.conf (revert to zfs_load="YES") but re: https://github.com/openzfs/zfs/issues/4553 I can not think of a way to mount the datas

Re: USB microphones with FreeBSD-CURRENT

On 28/03/2020 12:45, Jan Beich wrote: Graham Perrin writes: I can't get web browsers to recognise USB microphones. USB output (e.g. to my headphones) is OK. USB input (e.g. from the microphone part of the headphones) is not. Any suggestions? Firefox uses "pulse-rust" cubeb backend *by defa

Re: USB microphones with FreeBSD-CURRENT

On 2020-03-30 15:06, Graham Perrin wrote: Worth noting: if I attempt to suspend the system whilst the device at 3 (SteelSeries Siberia 350 headphones with integral microphone ) is physically connected, suspend sometimes fails; it becomes nece

ZFS: OpenZFS: lost the ability to boot a BE

On 30/03/2020 19:47, Graham Perrin wrote: I lost the ability to boot the environment named 'r357746', I suspect this occurred after I set it to use OpenZFS in lieu of ZFS. I would like to edit its /boot/loader.conf (revert to zfs_load="YES") but re: https://github.com/openzfs/zfs/issues/4553 I

Re: ZFS: OpenZFS: lost the ability to boot a BE

To temporarily mount a ZFS filesystem: mount -t zfs poolname/data/set /path/here On 2020-03-30 19:53, Graham Perrin wrote: > On 30/03/2020 19:47, Graham Perrin wrote: >> I lost the ability to boot the environment named 'r357746', I suspect >> this occurred after I set it to use OpenZFS in lieu o

USB microphones with FreeBSD-CURRENT: bug 194727, r358629

On 30/03/2020 20:36, Theron wrote: On 2020-03-30 15:06, Graham Perrin wrote: Worth noting: if I attempt to suspend the system whilst the device at 3 (SteelSeries Siberia 350 headphones with integral microphone ) is physically connected, sus

Re: USB microphones with FreeBSD-CURRENT: bug 194727, r358629

On 2020-03-30 20:08, Graham Perrin wrote: Theron, thank you! That might explain a recent sense of randomness with the symptoms. I've been testing in three different boot environments, only one of which is above the 358629 at : I do