I still have it all in the queue, just the paid work is taking its toll and
then FreeBSD and illumos :)
Next week I am on vacation trip but then I’ll be back and kicking.
Rgds,
Toomas
Sent from my iPhone
> On 20 Sep 2018, at 02:37, Warner Losh wrote:
>
>> On Wed, Sep 19, 2018 at 4:33 P
> On 9/19/18 3:53 AM, Greg V wrote:
>
> >
> > Yes, of course it was 64-bit.
> >
> > I don't think I ever downloaded the 32-bit one...
>
>
> And are you sure it was booted via EFI and not the BIOS emulation CSM
> (Compatibility Support Module)? I'm fairly sure we _don't_ support
> booting a 64-
>
> On 9/19/18 9:06 AM, Rodney W. Grimes wrote:
> > Yes, that is one of the catagories of rare, a EFI-32 bit system that
> > was originally shipped with a 32 bit only CPU, that later got upgraded
> > in the field with a 64 bit CPU, that still runs a EFI-32 bios.
> > Are you sure the 2007 firmware
On Wed, Sep 19, 2018 at 4:33 PM Rebecca Cran wrote:
> Oh, that's a really good point - thanks! I happen to have a Minnowboard
> Turbot currently sitting unused.
>
One other idea, unrelated to the 32-bit UEFI to boot 64-bit kernel, is to
see about mining tsoome@'s port of FreeBSD boot loader to O
On 9/19/18 5:13 PM, Ed Maste wrote:
The Minnowboard Turbot has an Atom E3826, and has four precompiled
Tianocore UEFI firmware releases available: 32 and 64 bit in release
and debug builds. It's probably the most approachable development
platform for UEFI work on FreeBSD.
Oh, that's a really
On 09/19/18 09:22, Glen Barber wrote:
> The 12.0-RELEASE schedule will slip while we wait for some last-minute
> work-in-progress to be completed before branching stable/12.
>
> The most notable work-in-progress is upgrading the in-tree OpenSSL to
> version 1.1.1, to avoid being stuck with an ou
On 19 September 2018 at 10:34, Rodney W. Grimes
wrote:
>
> You would be hard pressed to find a system with a 64 bit CPU that
> could run 64 bit FreeBSD that had a 32 bit EFI implementation.
The Minnowboard Turbot has an Atom E3826, and has four precompiled
Tianocore UEFI firmware releases availab
On Wed, 19 Sep 2018 09:58:19 -0400, Ed Maste wrote:
> On 19 September 2018 at 09:28, Jeffrey Bouquet
> wrote:
> > /usr/ports/security/lockdown [ sorry if this is a PR or for ports- ]
>
> Unfortunately this port has no maintainer, so fixing this is going to
> need someone to take an interest
On 9/19/18 3:53 AM, Greg V wrote:
Yes, of course it was 64-bit.
I don't think I ever downloaded the 32-bit one...
And are you sure it was booted via EFI and not the BIOS emulation CSM
(Compatibility Support Module)? I'm fairly sure we _don't_ support
booting a 64-bit kernel from 32-bit EF
On 9/19/18 9:06 AM, Rodney W. Grimes wrote:
Yes, that is one of the catagories of rare, a EFI-32 bit system that
was originally shipped with a 32 bit only CPU, that later got upgraded
in the field with a 64 bit CPU, that still runs a EFI-32 bios.
Are you sure the 2007 firmware is EFI32? I woul
On Wed, Sep 19, 2018 at 02:11:56PM -0700, Steve Kargl wrote:
> On Wed, Sep 19, 2018 at 05:02:11PM -0400, Mark Johnston wrote:
> > On Wed, Sep 19, 2018 at 01:01:52PM -0700, Steve Kargl wrote:
> > > I have the kernel and core file if more information is needed.
> > >
> > > % cat info.2
> > > Dump he
On Wed, Sep 19, 2018 at 05:02:11PM -0400, Mark Johnston wrote:
> On Wed, Sep 19, 2018 at 01:01:52PM -0700, Steve Kargl wrote:
> > I have the kernel and core file if more information is needed.
> >
> > % cat info.2
> > Dump header from device: /dev/ada0p3
>Architecture: amd64
> > Architecture
On Wed, Sep 19, 2018 at 01:01:52PM -0700, Steve Kargl wrote:
> I have the kernel and core file if more information is needed.
>
> % cat info.2
> Dump header from device: /dev/ada0p3
Architecture: amd64
> Architecture Version: 2
> Dump Length: 2348281856
> Blocksize: 512
> Compression: n
I have the kernel and core file if more information is needed.
% cat info.2
Dump header from device: /dev/ada0p3
Architecture: amd64
Architecture Version: 2
Dump Length: 2348281856
Blocksize: 512
Compression: none
Dumptime: Wed Sep 19 12:29:59 2018
Hostname: troutmask.apl.washington.
On 2018-Sep-19, at 9:14 AM, Sean Bruno wrote:
> On 9/18/18 8:48 PM, Mark Millard wrote:
>> A problem here is that the references should be to usr.bin instead
>> of usr/bin . See:
>>
>> https://lists.freebsd.org/pipermail/svn-src-head/2018-September/118426.html
>>
>> which reports for svn commit
> On 19 Sep 2018, at 18:31, Rodney W. Grimes
> wrote:
>
>> On Wed, Sep 19, 2018 at 6:06 PM, Rodney W. Grimes
>> wrote:
On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
wrote:
>> On 9/18/18 4:11 AM, Greg V wrote:
>>
>>>
>>> I can confirm that the kernel already
The 12.0-RELEASE schedule will slip while we wait for some last-minute
work-in-progress to be completed before branching stable/12.
The most notable work-in-progress is upgrading the in-tree OpenSSL to
version 1.1.1, to avoid being stuck with an outdated OpenSSL when 1.0.x
reaches end of life on J
On 9/18/18 8:48 PM, Mark Millard wrote:
> A problem here is that the references should be to usr.bin instead
> of usr/bin . See:
>
> https://lists.freebsd.org/pipermail/svn-src-head/2018-September/118426.html
>
> which reports for svn commit: r336601 - head:
>
> QUOTE
> Looks like this head/Ob
On Wed, Sep 19, 2018 at 6:31 PM, Rodney W. Grimes
wrote:
On Wed, Sep 19, 2018 at 6:06 PM, Rodney W. Grimes
wrote:
>> On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
>> wrote:
>> >> On 9/18/18 4:11 AM, Greg V wrote:
>> >>
>> >> >
>> >> > I can confirm that the kernel alre
> On Wed, Sep 19, 2018 at 6:06 PM, Rodney W. Grimes
> wrote:
> >> On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
> >> wrote:
> >> >> On 9/18/18 4:11 AM, Greg V wrote:
> >> >>
> >> >> >
> >> >> > I can confirm that the kernel already worked fine when booted
> >> from
> >> >> > 32-b
On Wed, Sep 19, 2018 at 6:06 PM, Rodney W. Grimes
wrote:
On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
wrote:
>> On 9/18/18 4:11 AM, Greg V wrote:
>>
>> >
>> > I can confirm that the kernel already worked fine when booted
from
>> > 32-bit EFI.
>> >
>> > I booted an old M
> On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
> wrote:
> >> On 9/18/18 4:11 AM, Greg V wrote:
> >>
> >> >
> >> > I can confirm that the kernel already worked fine when booted from
> >> > 32-bit EFI.
> >> >
> >> > I booted an old Mac into HardenedBSD using a 32-bit-EFI build of
> >>
On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
wrote:
On 9/18/18 4:11 AM, Greg V wrote:
>
> I can confirm that the kernel already worked fine when booted from
> 32-bit EFI.
>
> I booted an old Mac into HardenedBSD using a 32-bit-EFI build of
GRUB2 :)
Was that a 64-bit version
> On 9/18/18 4:11 AM, Greg V wrote:
>
> >
> > I can confirm that the kernel already worked fine when booted from
> > 32-bit EFI.
> >
> > I booted an old Mac into HardenedBSD using a 32-bit-EFI build of GRUB2 :)
>
>
> Was that a 64-bit version of FreeBSD? My understanding is the 32-bit
> FreeBSD
On 19 September 2018 at 09:28, Jeffrey Bouquet
wrote:
> /usr/ports/security/lockdown [ sorry if this is a PR or for ports- ]
Unfortunately this port has no maintainer, so fixing this is going to
need someone to take an interest in the port. I had a quick look at
the script and it looks like it s
/usr/ports/security/lockdown [ sorry if this is a PR or for ports- ]
altered fstab, login.conf and ttys locking me out of my main machine, probably
due
to the password hash, but only a daily backup helped me login again and fix the
damages, with a few files "hardened" maybe but at a cost of unce
On 09/18, Rebecca Cran wrote:
On 9/18/18 4:11 AM, Greg V wrote:
I can confirm that the kernel already worked fine when booted from
32-bit EFI.
I booted an old Mac into HardenedBSD using a 32-bit-EFI build of GRUB2 :)
Was that a 64-bit version of FreeBSD? My understanding is the 32-bit
Free
On Wed, Sep 19, 2018 at 1:40 AM Patrick McMunn
wrote:
> I filed a bug about this issue:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231441 I have
> encountered
> it with the run USB wireless driver. I haven't tested it with ethernet.
> Does this issue only affect wireless devices, only ce
28 matches
Mail list logo
