Here are the 3 use cases I tested:
1. The first disk, the one on which I have tried installboot,
had FreeBSD on it using ZFS and I had trouble reusing it. The
partition table was MBR.
2. The second disk had OpenBSD and installing NetBSD worked
perfectly. The partition table was also MBR.
3. The
On Tue, Apr 28, 2020 at 09:31:31AM +0200, Vincent DEFERT wrote:
> My first installation attempt consisted in deleting the FreeBSD
> partition but keeping the EFI one. I went through the whole
> installation without any trouble, but the system refused to
> reboot (can't remember the message).
This
On 28/04/2020 09:26, Martin Husemann wrote:
Now you deleted the FreeBSD boot stuff, and everything worked fine.
Should be totally unrelated to the partition size.
There is no limitation in NetBSD. My 9 STABLE machine EFI booting off an
nvme device has a 256MB EFI partition and boots with n
On 27.04.2020 23:02, Vincent DEFERT wrote:
>
> I have also installed NetBSD on a server (Dell R610) previously running
> FreeBSD.
> The problem I had there is that NetBSD does not support EFI partition
> sizes greater than 128 MB.
> In this case also, I had to wipe the partition table, but I could
On 28/04/2020 11:23, Ilia Zykov wrote:
I had such a case. The efi of my old server(it was Intel MB) only
supported a 16 bit vfat boot partition. And if during installation I
selected it over 128MiB, then the installer formatted it at 32 bit vfat
and I could not boot in EFI mode. See the defaul
What does dumpfs -a /dev/rdk0
show?
christos
> On Apr 27, 2020, at 9:16 PM, Michael Cheponis
> wrote:
>
> There is some progress. The trick is the -N flag to newfs, which shows
> plenty of super-block backups:
>
> S# newfs -N -O 2 dk0
> /dev/rdk0: 9537535.0MB (19532871680 sectors) block si
Whenever I open up use of sip/webrtc to users, as far as possible I don't
want them to be bothered with yet another password and preferably not even
ask to enter the same password when using the webrtc app.
How is authentication handled on Asterisk's side? And if that's WebRTC, could
a reverse
Also, as you test, you may want to look into whether the kernel is using
AES instructions, with or without /dev/crypto offload. I have not paid
attention to these details in quite a few years. As wikipedia notes,
while twofish and rijndael were competitive in speed, twofihs is slower
on computer
Pierre-Philipp Braun writes:
> Of course, the only symmetric cipher that can compete with hardware
> accelerated AES in terms of throughput is Chacha20 and we don't have
> it in setkey. It's there in the OpenSSH code, though, it's even
> builtin without OpenSSL.
I'm not clear on if Chacha20 is
I'm not clear on if Chacha20 is specified for IPsec.
It was not there originally of course, but it's coming (proposed standards)
ChaCha20 & Poly1305 for IPsec
https://tools.ietf.org/html/rfc7634
and it is mentioned as SHOULD, there in section 5
ESP and AH Algorithm Requirements
https://tools.
Yep for the record, on a netbsd-9 guest with hw accel I get
(devcrypto) /dev/crypto engine
(rdrand) Intel RDRAND engine
(dynamic) Dynamic engine loading support
that was OpenSSL 1.1.1c 28 May 2019
while on another netbsd-9 w/o hw accel I get
(cryptodev) BSD cryptodev engine
(dynamic) Dynami
Pierre-Philipp Braun writes:
>> I'm not clear on if Chacha20 is specified for IPsec.
>
> It was not there originally of course, but it's coming (proposed standards)
>
> ChaCha20 & Poly1305 for IPsec
> https://tools.ietf.org/html/rfc7634
Well, I guess you have an opportunity to add support :-) In
On Tue, Apr 28, 2020 at 06:20:44PM +0300, Pierre-Philipp Braun wrote:
> How is authentication handled on Asterisk's side? And if that's WebRTC,
> could a reverse proxy take care of it in the middle?
Not sure, does it mean modifying with asterisk's webrtc server?
> A original way to approach the
Hi,
some calls to read(2) or write(2) take almost exactly 0.5 seconds, while
most other syscalls are fast as usual. What could be the reason?
I'm running NetBSD 8.0 x86_64 inside VirtualBox 6.1 on a Windows 10
host. Add hard disks in that VM are added via a SCSI controller. One one
of the disks
On Wed, 29 Apr 2020 06:57:28 +0200
Roland Illig wrote:
> How can I further research where this artificial delay comes from, and
> finally fix it?
I've always experienced slow disk I/O with NetBSD on VirtualBox, even
with fast SSD disks. Not sure if this is a NetBSD bug, or some
interaction with
15 matches
Mail list logo
