docs: http://www.soum.co.jp/~jun/OSC2017tokyospring.pdf http://www.soum.co.jp/~jun/asiabsdcon2017.pdf

Comment by jun early Thursday morning, March 9th, 2017
Community might take https://github.com/conformal/xombrero?files=1 and make NetBrowser.
Comment by jaypatelani terribly early Thursday morning, February 23rd, 2017
Agreed. And Lumina doesn't rely on dbus.
Comment by jaypatelani terribly early Thursday morning, February 23rd, 2017

I can't imagine the specified /boot.cfg entry, with a path going into /usr/pkg/... can really be found by boot. All previous tutorials and how-to's specify copying .../xen*-kernel/xen.gz into the root directory.

The number of users having problems following the advice on the boot.cfg entry suggests that /boot can't traverse the directory tree deep enough to find xen.gz, even assuming /usr/pkg is on the same filesystem as /.

Comment by schnoebe in the wee hours of Sunday night, February 20th, 2017

See Jun Ebihara's GitHub page where lots of stuff regarding NetBSD on RPI is collected: https://github.com/ebijun/NetBSD/blob/master/RPI/RPIimage/Image/README

Comment by Fredrik Pettai late Saturday evening, February 4th, 2017

I forgot to add that Truecrypt had a version for Linux and at one time had a BSD version which I believe no longer is around or operative. Truecrypt was anonymously written and he closed up shop and just disappeared one day. Truecrypt has also had extensive code verification leading to additions in Veracrypt.

Here's a link for tcplay(derivative or Truecrypt).

https://github.com/bwalex/tc-play

Veracrypt

https://veracrypt.codeplex.com/

and the Dragonfly BSD I linked above where it's use of tcplay is described.

I hope this is helpful All the questions that you asked in the summary have been answered on other systems with TC and VC. I know they're not Net but it could be a good start on how they've managed it.

Comment by Sam early Wednesday morning, January 4th, 2017

I think you should do something that no one wants to do. Take as much as you can from a long term existing system. There's a program that started on win98(name change)(scramdisk) and moved to Win 2000(ECM) then on Win XP,...etc(Truecrpyt). It now is rewritten and called (Veracrypt) for Windows, Linux, Mac OS and Raspberry Pi ARMv7. The only thing stopping me from moving to one of the BSD's is reading truecrypt files. DragonflyBSD reads Truecrypt through tcplay a rewrite of truecrypt but DF is a little more experimental than I want for a desktop.

https://www.dragonflybsd.org/features/#index5h2

So there's two versions from the same Truecrypt source. Tcplay and Veracrypt. Veracrypt is a newer version that is audited and has corrected some small deficiencies of TC so is better but bigger, more complete and complex. The MacOS works through FUSE specifically OSXFUSE 2.5. Linux I think through DMcrypt. Here's what so good about Veracrypt/Truecrypt. It has encryption on the fly for not only regular drives but the OS system drive also, after it's running. This means not setting up encryption but encrypting the drive as the OS runs, then writing the boot with password enabled. It's very, very nice. I'm not saying that all these things need to be in place at once but using the code they have already written shows a pathway. Too start just use the code for equivalent encryption to Veracrypt(which has a compatibility function for Truecrypt). The important thing is Truecrypt has been around a long, long time and lots of people have this format and it works. For some reason people keep reinventing the wheel and will not use that which a lot of work has gone into already. Now I KNOW that porting this will not be easy but maybe NetBSD's FUSE can be used the same way that Veracrypt uses MacFUSE. Strip out the GUI stuff but know that it can be added and most of it is already set up for GTK in the MAC so the possibility remains to have it on a desktop with GUI using the lower level already done. Sorry so long but it complicated.

Comment by Sam early Wednesday morning, January 4th, 2017

There is a good chance there is a bug that causes us to not deal with the smaller block size of sd correctly.

  • A 2GB SD card fails in the BPI.
  • A 8GB SDHC card with the same image (dd'ed) works correctly in the same BPI.

I did not test 32GB or 64GB (SDXC).

Comment by cyber early Friday morning, December 2nd, 2016

I've had a go at installing NetBSD on a Macbook Pro (mid 2012 model). I'm using NetBSD current as of 2016-10-25.

The NetBSD installer from current can install to the whole disk, but it doesn't use GPT. Regardless, it boots ok after a ~20 second delay. In order to remove the delay, I've followed the above instructions.

I had issues with running newfs_msdos from NetBSD. I rebooted to MacOS recovery ran newfs_msdos and then did the rEFInd install.

Assuming that rEFInd has been installed, when changing to hybrid mode, GPT fdisk now has a EFI module that can be copied to the EFI/tools directory. Then you can run gdisk directly from rEFInd. There is, now, no need to install MacOS to a USB stick.

The instructions seem to leave out installing the bootloader on the NetBSD slice.

Comment by Patrick at midnight, October 27th, 2016

Hello, nice news (even if published almost 2 years ago :)) ) and information. I would like to ask you how complex could be the porting on the Odroid U3. Do you have some hints or links to find some information? Is there any work in progress? Many thanks in advance for your support.

Comment by Luca early Monday morning, August 22nd, 2016
Add a comment
Contact | Disclaimer | Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
NetBSD® is a registered trademark of The NetBSD Foundation, Inc.