Categories
Uncategorized

The Short List #4: p4 foo

change a file in perforce to be executable on checkout.

 

p4 edit -t <type>+x <file name>
p4 submit <file name>
Categories
FreeBSD

You need to construct additional pylons. Building wine for #FreeBSD

I’ve been playing Blizzards’s Starcraft 2 on Linux via wine emulation lately and thought I’d see if I can get the same thing working on FreeBSD via the emulators/i386-wine-devel port.  After talking with the fine folks in #bsdports on EFNet, I finally found a recipe that is poudriere friendly and seems to spit out something that sort of works.

David Naylor (dbn@freebsd.org) has a working method for constructing wine on FreeBSD and this should work in most cases for using current.  The method is really designed for building a binary package for releases, most folks wouldn’t want to go down this route.

In order to begin, get poudriere configured and ready to go.  You’ll need to construct an i386 jail for the first part of this process.  Something like I show in my poudiere blog post

poudriere jail -c -j 11i386 -v head -a i386 -m svn

This will give you a build environment to get the 32bit binaries for wine built and packaged up for step 2.

poudriere builk -j 11i386 emulators/i386-wine-devel

If all goes well, you now have an i386 package of wine that will be consumed as a distfile for the amd64 package build.  I redefine PORTSDIR=/usr/local/poudriere/ports/default in /etc/make.conf.

If you are like me and use poudriere for everything, copy it to /usr/local/poudriere/ports/defaults/distfiles/freebsd:11:x86:64/

Now you’ll need to edit the emulators/i386-wine-devel distfile with the appropriate information generated from a sha256 and ls -l of your packagefile in your local i386 repo:

sha256 i386-wine-devel-1.7.7,1.txz

SHA256 (i386-wine-devel-1.7.7,1.txz) = 8d0073d1c10be9afbe7c3c9874a31ac110c1f96cf6ddcda74ca16d31bad55d1b

Modify this with the following to make it compatible with your system:

SHA256 (freebsd:11:x86:64/i386-wine-devel-1.7.7,1.txz) = 8d0073d1c10be9afbe7c3c9874a31ac110c1f96cf6ddcda74ca16d31bad55d1b

Modify the Makefile.inc to exclude checks for the OS version:

Index: Makefile.inc
===================================================================
— Makefile.inc    (revision 335346)
+++ Makefile.inc    (working copy)
@@ -41,10 +41,10 @@

.include <bsd.port.pre.mk>

-.if !(${OSVERSION} >= 803000 && ${OSVERSION} < 900000) && !(${OSVERSION} >= 901000 && ${OSVERSION} < 1000000)
-IGNORE=        binaries compiled for FreeBSD 8.3+ and 9.1+ only
-DISTFILES=
-.endif
+#.if !(${OSVERSION} >= 803000 && ${OSVERSION} < 900000) && !(${OSVERSION} >= 901000 && ${OSVERSION} < 1000000)
+#IGNORE=        binaries compiled for FreeBSD 8.3+ and 9.1+ only
+#DISTFILES=
+#.endif

.if ${PORT_OPTIONS:MGECKO}
RUN_DEPENDS+=   ${DATADIR}/gecko/wine_gecko-2.24-x86.msi:${PORTSDIR}/emulators/wine-gecko-devel

And now, you can try building the package in your *AMD64* poudriere build with:

poudriere bulk -j 11amd64 emulators/i386-wine-devel

If my instructions have succeeded, you now have a package suitable for installation on your amd64 machine that will now let you do wine things.

Now, I need to figure out what the Blizzard Network Installer is trying to do as it runs, self-updates and hangs.

Categories
FreeBSD

Moving forward by going slightly backwards and to the right, UEFI booting on #FreeBSD

The FreeBSD Foundation has been working towards the future of booting in x86 and catching up to our friends in Linux-land by sponsoring work on a UEFI enabled boot loader.  This work was taken on by Benno Rice (benno@freebsd.org) and Ed Maste (emaste@freebsd.org).

So far, it appears that one can indeed boot FreeBSD as I will demonstrate on my Thinkpad T520.

Starting with the UEFI project branch, one must build a 64bit version of libstand in tree.

cd uefi/lib/libstand && make

Modify the makefile in sys/boot/amd64

Index: amd64/efi/Makefile
===================================================================
— amd64/efi/Makefile    (revision 258775)
+++ amd64/efi/Makefile    (working copy)
@@ -77,8 +77,8 @@
LIBEFI=        ${.OBJDIR}/../../efi/libefi/libefi.a
CFLAGS+=    -I${.CURDIR}/../../common

-DPADD=        ${LIBFICL} ${LIBEFI} ${LIBSTAND}
-LDADD=        ${LIBFICL} ${LIBEFI} ${LIBSTAND}
+DPADD=        ${LIBFICL} ${LIBEFI} ../../../../lib/libstand/libstand.a
+LDADD=        ${LIBFICL} ${LIBEFI} ../../../../lib/libstand/libstand.a

.include <bsd.prog.mk>

Now you can build loader.efi and get it to link against the 64bit version of libstand:

cd sys/boot && make

UEFI will look for a FAT formatted partition with the “efi” signature on it.  FreeBSD’s gpart can create this partition for you, so do the following foo:

gpart create -s gpt da0

gpart add -t efi da0

gpart add -t freebsd-ufs da0

$ gpart show da0
=>     34  2013117  da0  GPT  (983M)
34   131072    1  efi  (64M)
131106  1882045    2  freebsd-ufs  (919M)

newfs -t msdosfs /dev/da0p1

newfs /dev/da0p2

Mount the fat formatted partition, create the EFI directory structure(this is mandatory) and copy the loader.efi binary into place as bootx64.efi

mount -t msdosfs /dev/da0p1 /mnt

mkdir -p /mnt/efi/boot

cp uefi/sys/boot/amd64

Because the kernel currently needs to be aware of the new style UEFI memory map, you can’t run stock -current in this configuration.  You’ll need to use a kernel from the projects/uefi branch when constructing your bootable device.  I used a 1G usb thumbdrive for this test, so mount the UFS partition and use it as a DESTDIR for your installworld/installkernel:

make -s buildworld

make -s buildkernel

mount /dev/da0p2 /mnt

DESTDIR=/mnt make -s installworld

DESTDIR=/mnt make -s installkernel

DESTDIR=/mnt make -s distribution

Setup an /etc/fstab on this stick:

/dev/da0p2             /               ufs     rw,              1       1

At this point, your USB disk is ready for its first booting attempt.

EFI_BIOS

EFI_LOADER1

I have to toggle UEFI/Legacy BIOS mode in my laptop.  For your entertainment, here it is.  This has the convient side effect of not booting from my other disk devices in my laptop as they do not have the “proper” fat formatted EFI partition on them.  This actually yeilds a pretty quick boot to the loader.

Amazing!  It did!  Sort of.

Now we have the entertainment of trying to figure out how to get here to multiuser.

 

 

 

EFI_LOADER2

With a “show” we find out that the loader has selected the EFI partition “part6” as the boot device.  “lsdev” shows us all the partitions that we could boot from, but I have chosen well in this example and can easily see that the one I really want is tagged with a “(removable)”.

In this case executing a “set currdev=part7” sets up the loader to boot and executing “boot” will get this system into multiuser.

Many thanks to the folks at the FreeBSD Foundation for these initial steps into UEFI.  The project branch in subversion is publicly available and I highly encourage folks to engage the community to get this closer to production grade.

Categories
FreeBSD

The Unusual Suspects, #FreeBSD Vendor Summit 2013

I was fortunate enough this year to be able to help the FreeBSD Foundation host the 2013 Fall Vendor Summit at my workplace, Yahoo.  Our facilities in Sunnyvale are very first class and I like to help out with my non-technical resources whenever possible (because, frankly, if you’ve seen my code, you would prefer it that way).

George Neville-Neil of the FreeBSD Project and FreeBSD Foundation had asked if Yahoo could host again this year and we agreed to a one day presentation and get together at the main campus.

Lots of folks who don’t normally go for conferences showed up to this invitation only event, and for once it felt like we had a strong showing.  I had booked a conference room for 55 people and we had close to 70 show up.  It was really close to bordering on overflow into the hallway at one point.

I think my biggest takeaways this year was the fact that “FreeBSD Doesn’t Have Visualization” is now just a myth and doesn’t really match reality.  The Bhyve project has taken a good direction and now can spin up other o/s instances, like Linux, via the ACPI framework implemented during the Google Summer of Code projects.  It was also very good to see VMWare and Google Compute folks showing up and asking for “what we need to help you folks support FreeBSD in our cloud things.”

Instead of the hallway track at normal conferences, we had the “back of the room on the floor” track this year where there was much debating over the validity of git as a FreeBSD source management tool.  The thing is, the project already exports FreeBSD SVN src to a self hosted git repo (http://git.freebsd.org) and a github instance (https://github.com/freebsd).   The debate swirls around the archaic “email patches to mailing lists” mentality instead of the “send pull request” things that the git world now has.

Interesting point from this discussion, perhaps we should now take the time to assign people who are more involved to important sections of kernel and source code.  The FreeBSD ports system has direct maintainers and a system to timeout maintainers who are AFK.  The FreeBSD base system has a more liberal approach as any committer can and does commit to any aspect of the tree.  Its common practice to not do this without review, but its no a true formal review process.  This leads to some cases where patches go to mailing lists and never get picked up and reviewed.

Otherwise, a fine time was had and I certainly look forward to the next conference, AsiaBSDCon 2014.

Categories
FreeBSD

How I learned to stop worrying and love the powderkeg. #FreeBSD

FreeBSD has grown up a lot in this release cycle.  The most useful tool from the 10.0/11.0 world in a long time, poudriere (powder keg in French) has made my ports usage almost trivial now.

More or less, poudriere is a tool that allows you to build ports packages compatible with the new PKGNG format without contaminating your working system.  It uses a series of jails and build environments to do what a lot of more savvy FreeBSD developers and engineers have been doing for years.

Even using portmaster to maintain my systems seems archaic in comparison, not to mention error prone.  More or less, my 3 or 4 systems have been converted to use themselves as a repository for packages and they build their own packages.  This is a bit redundant to be honest, and it makes the most sense to use one host as a repository and have your other machines pull in packages from it.  My implementation is due to running 11-current and being having machines I control on very different and restrictive networks.

poudriere setup for 11-current (head builds)

Start by install poudriere from ports or a package that you can get your hands on.  Then command poudriere to setup its basejail on FreeBSD SVN HEAD:

poudriere jail -c -j 11-amd64 -v head -a amd64 -m svn

This will create a jail on your local machine based on SVN head at the time of execution (yes, its going to compile everything from source and will take a while, get a cup of coffee, perhaps a sandwich).  The thing is, your machine is still available for other things while this is going on.  You are not going to crash X or other applications while this is happening.  Its building a separate jail for the purpose of creating packages.

Once its build, you can update your jail world trivially via:

poudriere jail -u -j 11-amd64

Now, grab the ports tree via:

poudriere ports -c

Updates to your ports tree via portsnap are easy with a :

poudriere ports -u

At this point, you are ready to configure poudriere to build your package via the “bulk” command.  I copied /usr/local/etc/poudriere.conf.sample to /usr/local/etc/poudriere.conf and made exactly one change to the default settings.  I use ZFS ( which I highly recommend, see my post on the Bacon of Filesystems ) and my ZPOOL is a different name than the default.

Creating your list of ports for your builds is a trial and error endeavor to be honest.  I suspect, there are easier ways to do it, but I determined my list below based on the list I had installed already and some questions to various mailing lists.  I created a /usr/local/etc/myports file with the following in it as a list of ports that I want built.  Poudriere will build all required dependencies for me, build-time and run-time and create nice little packages for me.

x11/xorg
x11/xdm
x11/xsm
x11-wm/xfce4
x11/xfce4-screenshooter-plugin
x11/xscreensaver
shells/bash
www/firefox
www/linux-f10-flashplugin11
www/nspluginwrapper
graphics/evince
net-im/finch
editors/vim
sysutils/tmux
comms/amtterm
ports-mgmt/dialog4ports
ports-mgmt/pkg
ports-mgmt/poudriere
java/openjdk7
editors/vim-lite
sysutils/synergy-devel
devel/git
emulators/qemu-devel

At this point, I was read to do the build run via:

poudriere bulk -f /usr/local/etc/myports -j 11-amd64

This builds all the things for me, caching packages when needed for reuse.  Very handy for me to be honest.

Setting up the pkg repo couldn’t be simpler either.  I copied /usr/local/etc/pkg.conf.sample to /usr/local/etc/pkg.conf and made a single change to point the system to use the locally build packages in a locally generated repo:

PACKAGESITE        : file:///usr/local/poudriere/data/packages/11-amd64-default

The final step was to initialize my repository via:

pkg repo /usr/local/poudriere/data/packages/11-amd64-default

I then updated my system via the newly built packages:

pkg update

pkg upgrade -f

This refreshed all the packages on my system with ones that are cleanly built by poudriere.  This allowed me to now audit what I had installed and to see what I could remove or what else I needed to have built:

pkg version -R

Anything with a “=” means that it comes from the repository and is up to date.  Anything with a “?” means it comes from an unknown source.   I learned I had a lot of dependencies installed for builds that I didn’t need for runtime cases:

pkg autoremove

Many, many, many thanks to the FreeBSD portmgr team (portmgr@freebsd.org), Baptiste Daroussin, Bryan Drewery and the others who have deadlifted the FreeBSD ports system into the future. Now I can look at whats left and I have never been more content with FreeBSD ports.  *boom*

*edit* reference to poudriere official docs and such:

https://fossil.etoilebsd.net/poudriere/doc/trunk/doc/index.wiki

*edit* after pkg-1.2.1 release.

The pkg.conf config and locations have moved around and become incompatible with this blog post.  You’ll want to do two things if you are using this as a guide for updates:

1.  Disable the FreeBSD repo configuration in /etc/pkg/FreeBSD.conf

2. Move your local repo config to /etc/pkg/my_repo.conf and give it the following syntax:

me: {
url: file:///usr/local/poudriere/data/packages/11-amd64-default,
signature_type: none,
enabled: yes
}

Categories
FreeBSD

The Short List #7: wpa_passphrase on #FreeBSD. Because plaintext passwords are dumb.

If you have configured wireless networks on your FreeBSD laptop/pc. You can use wpa_passphrase to make the password entries more obscure with the use of wpa_passphrase.

For example, given the following network entry in wpa_supplicant.conf:

network={
ssid=”BRUNO”
scan_ssid=1
priority=5
key_mgmt=WPA-PSK
psk=”Super Secret Plain Text Password”
}

wpa_passphrase can give you a psk entry that is more obscure:

$ wpa_passphrase BRUNO
# reading passphrase from stdin
Super Secret Plain Text Password
network={
ssid=”BRUNO”
#psk=”Super Secret Plain Text Password”
psk=536ac6450b5874686e33122f80d39ad633b59613389f123d149c76fef4f3c877
}

Just remember to delete the plain text version when you copy paste it into your config.