FreeBSD – The Ignorant Hack http://blog.ignoranthack.me Surprising facts to me, completely obvious to you Tue, 04 Jul 2023 21:58:33 +0000 en-US hourly 1 https://wordpress.org/?v=6.2.8 http://blog.ignoranthack.me/wp-content/uploads/2022/11/FrankNBeansCan_400x400-150x150.png FreeBSD – The Ignorant Hack http://blog.ignoranthack.me 32 32 A bit of #ZFS Faff on Ubuntu 22.04 http://blog.ignoranthack.me/?p=694 Tue, 04 Jul 2023 21:55:30 +0000 http://blog.ignoranthack.me/?p=694 I’m a ZFS on Root guy, so I get to be my own support on most days. Today, I wanted to see how hard common tasks that I once did on #FreeBSD with ZFS tools would be. Namely, I wanted to pluck out a 250G drive from my Root Pool and replace it with a 1TB drive, live, with a minimal of fuss.

I think I was successful, and it wasn’t that hard. I did have to teach myself a bit about how sgdisk(8) works and what not to do, but in the end I came up with the following bit of notes that seemed to work for me. A lot of my previous ZFS experience was applicable here, but I have spent decades being oblivious to the magic of Grub and boot loaders on x86 Linux ports.

Thank you to the fine folks over at OpenZFS for having a VERY easy to follow 22.04 install guide, which I definitely stole things from.

The following is just my notes and if you see some things that will bite me, let me know on Mastodon, you can find me over at infosec.exchange

# sgdisk -p /dev/sda
Disk /dev/sda: 781422768 sectors, 372.6 GiB
Model: MK0400GCTZA     
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): DFE9708A-6076-4E24-B683-64A286A1E751
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 781422734
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI system partition
   2         1050624         5244927   2.0 GiB     8200  Linux swap
   3         5244928         9439231   2.0 GiB     BE00  Solaris boot
   4         9439232       781422734   368.1 GiB   BF00  Solaris root
# sgdisk -p /dev/sdb
Disk /dev/sdb: 537234768 sectors, 256.2 GiB
Model: Crucial_CT275MX3
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): AC04D23F-E1FD-4B88-9880-B9679DCF4BBD
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 537234734
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System Partition
   2         1050624         5244927   2.0 GiB     8200  
   3         5244928         9439231   2.0 GiB     BE00  
   4         9439232       537234734   251.7 GiB   BF00
---------------------------------------------------------------------------------
   
# sgdisk -d 1 /dev/nvme0n1
# sgdisk -n 1:2048:1050623 -t 1:ef00 -c1:"EFI system partition" /dev/nvme0n1
# sgdisk -n 2:1050624:5244927 -t 2:8200 -c2:"Linux swap" /dev/nvme0n1
# sgdisk -n 3:5244928:9439231 -t 3:be00 -c3:"Solaris boot" /dev/nvme0n1
# sgdisk -N 4 -t 4:bf00 -c4:"Solaris root" /dev/nvme0n1

# sgdisk -p /dev/nvme0n1
Disk /dev/nvme0n1: 500118192 sectors, 238.5 GiB
Model: WDC WDS256G1X0C-00ENX0                  
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): F2E3AFF0-5C0C-4A03-BE8C-83EC2DEDB914
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 500118158
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI system partition
   2         1050624         5244927   2.0 GiB     8200  Linux swap
   3         5244928         9439231   2.0 GiB     BE00  Solaris boot
   4         9439232       500118158   234.0 GiB   BF00  Solaris root
--------------------------------------------------------------------------------
# cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md127 : active raid1 sdb2[0] sda2[1]
      2094080 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>
root@hattie:~# mdadm --manage /dev/md127 --fail /dev/sda2
mdadm: set /dev/sda2 faulty in /dev/md127
root@hattie:~# mdadm --manage /dev/md127 --remove /dev/sda2
mdadm: hot removed /dev/sda2 from /dev/md127
root@hattie:~# cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md127 : active raid1 sdb2[0]
ex      2094080 blocks super 1.2 [2/1] [U_]
      
unused devices: <none>
# mdadm --manage /dev/md127 --add /dev/nvme0n1p2
mdadm: added /dev/nvme0n1p2
root@hattie:~# cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md127 : active raid1 nvme0n1p2[2] sdb2[0]
      2094080 blocks super 1.2 [2/1] [U_]
      [===>.................]  recovery = 18.7% (392832/2094080) finish=0.2min speed=130944K/sec
      
unused devices: <none>
-------------------------------------------------------------------------------------
# zpool status bpool
  pool: bpool
 state: ONLINE
  scan: scrub repaired 0B in 00:00:01 with 0 errors on Sun Jul  2 00:00:02 2023
config:

	NAME                                      STATE     READ WRITE CKSUM
	bpool                                     ONLINE       0     0     0
	  mirror-0                                ONLINE       0     0     0
	    2ae2089b-40b0-1944-9c6d-a436c8ba3295  ONLINE       0     0     0
	    b2bbd1e6-7b68-4d90-bf9c-f6d6bb13daac  ONLINE       0     0     0

# ls -l /dev/disk/by-partuuid/
total 0
lrwxrwxrwx 1 root root 10 Jul  4 12:59 0240b02b-5a83-45f7-b209-de850d66cc48 -> ../../sda4
lrwxrwxrwx 1 root root 10 Jul  4 13:01 26050a01-81fa-df4c-bb64-b825072a4cb5 -> ../../sdb2
lrwxrwxrwx 1 root root 15 Jul  4 13:04 277066fd-6087-45d3-bc21-36e2be379a7a -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 10 Jul  4 13:01 2ae2089b-40b0-1944-9c6d-a436c8ba3295 -> ../../sdb3
lrwxrwxrwx 1 root root 15 Jul  4 13:00 76e8a1b2-3877-4732-8b6b-2c4f47615733 -> ../../nvme0n1p4
lrwxrwxrwx 1 root root 10 Jul  4 12:59 83437572-9020-4945-8354-47d99f2de483 -> ../../sda2
lrwxrwxrwx 1 root root 15 Jul  4 13:00 86c776d9-9aa6-47de-8d45-26dc8833cea8 -> ../../nvme0n1p3
lrwxrwxrwx 1 root root 10 Jul  4 13:01 8a0ac60b-20ed-4bde-a27d-dd4f4160fa29 -> ../../sdb1
lrwxrwxrwx 1 root root 15 Jul  4 13:00 a963a8f4-3765-477c-bc08-6ea53f71b22b -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 10 Jul  4 12:59 b2bbd1e6-7b68-4d90-bf9c-f6d6bb13daac -> ../../sda3
lrwxrwxrwx 1 root root 10 Jul  4 12:59 d8132cf7-b5f7-4721-8340-3ce42d4b918e -> ../../sda1
lrwxrwxrwx 1 root root 10 Jul  4 13:01 e70d10dd-f1bd-f345-b5a9-e285acd26d8a -> ../../sdb4

# zpool replace bpool /dev/disk/by-partuuid/b2bbd1e6-7b68-4d90-bf9c-f6d6bb13daac /dev/disk/by-partuuid/86c776d9-9aa6-47de-8d45-26dc8833cea8
# zpool status
  pool: bpool
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
	continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Tue Jul  4 13:08:52 2023
	305M scanned at 102M/s, 125M issued at 41.6M/s, 305M total
	121M resilvered, 40.89% done, 00:00:04 to go
config:

	NAME                                        STATE     READ WRITE CKSUM
	bpool                                       ONLINE       0     0     0
	  mirror-0                                  ONLINE       0     0     0
	    2ae2089b-40b0-1944-9c6d-a436c8ba3295    ONLINE       0     0     0
	    replacing-1                             ONLINE       0     0     0
	      b2bbd1e6-7b68-4d90-bf9c-f6d6bb13daac  ONLINE       0     0     0
	      86c776d9-9aa6-47de-8d45-26dc8833cea8  ONLINE       0     0     0  (resilvering)

errors: No known data errors
-------------------------------------------------------------------------------------------------

~# update-initramfs -c -k all
update-initramfs: Generating /boot/initrd.img-5.19.0-45-generic
cp: cannot stat '/lib/firmware/updates/amdgpu': No such file or directory
W: Possible missing firmware /lib/firmware/amdgpu/ip_discovery.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega10_cap.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_cap.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_cap.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/psp_13_0_10_sos.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_cap.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_sjt_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_sjt_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_imu.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_me.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_pfp.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_0_toc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sdma_6_0_3.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes1.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mes1.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/smu_13_0_10.bin for module amdgpu
I: The initramfs will attempt to resume from /dev/md127
I: (UUID=514a7d66-c1d7-41c2-86e1-b072f30e2dd6)
I: Set the RESUME variable to override this.
update-initramfs: Generating /boot/initrd.img-5.19.0-46-generic
cp: cannot stat '/lib/firmware/updates/amdgpu': No such file or directory
W: Possible missing firmware /lib/firmware/amdgpu/ip_discovery.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega10_cap.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_cap.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_cap.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/psp_13_0_10_sos.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_cap.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_sjt_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_sjt_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_imu.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_me.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_pfp.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_0_toc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sdma_6_0_3.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes1.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mes1.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/smu_13_0_10.bin for module amdgpu
I: The initramfs will attempt to resume from /dev/md127
I: (UUID=514a7d66-c1d7-41c2-86e1-b072f30e2dd6)
I: Set the RESUME variable to override this.

--------------------------------------------------------------------------------------
# grub-install --target=x86_64-efi --efi-directory=/boot/efi \
    --bootloader-id=ubuntu --recheck --no-floppy
Installing for x86_64-efi platform.
Installation finished. No error reported.
]]>
More #FreeBSD Power Saving Notes http://blog.ignoranthack.me/?p=686 Tue, 22 Nov 2022 18:36:50 +0000 http://blog.ignoranthack.me/?p=686 Its been a while since I needed to be mobile with FreeBSD again. I remembered that there’s several out of the box tuning things that you should do in /etc/rc.conf and a few modules you should load for your mobile workstation.

/etc/rc.conf:
powerd_enable="YES"
economy_cx_lowest="LOW"
economy_cpu_freq="LOW"

These will slow your laptop down when running of battery and should give you the needed juice to take notes and update your remote projects. I wouldn’t recommend them for a machine you need to do buildworlds upon. 🙂

/boot/loader.conf
acpi_video_load="YES"

This one is a module that I forgot about for some time. If you load it, you’ll get a couple of new tunables that can be used to turn down the backlight, which is useful even if all you want is to not disturb your better-half when you are reading at night.

sysctl hw.acpi.video
hw.acpi.video.lcd0.economy: 50
hw.acpi.video.lcd0.fullpower: 80

You can throw these into your /etc/sysctl.conf at whatever value you like. See the man page, man 4 acpi_video for more information.

% acpiconf -i0|less
Design capacity:        3900 mAh
Last full capacity:     3827 mAh
Technology:             secondary (rechargeable)
Design voltage:         11100 mV
Capacity (warn):        390 mAh
Capacity (low):         118 mAh
Low/warn granularity:   39 mAh
Warn/full granularity:  39 mAh
Model number:           DELL 9C26T33
Serial number:          48476
Type:                   LION
OEM info:               SMP
State:                  discharging
Remaining capacity:     52%
Remaining time:         3:07
Present rate:           640 mA (6935 mW)
Present voltage:        10837 mV

Not too shabby for power savings. Not sure if .6 Amp is really enough to make this solid. I think this gives me a solid 4 hours of note taking and walking around.

]]>
FAT32 on FreeBSD http://blog.ignoranthack.me/?p=684 Mon, 21 Nov 2022 03:11:53 +0000 http://blog.ignoranthack.me/?p=684 I couldn’t find any examples of executing a newfs_msdos for a FAT32 filesystem while I was working on some FPGA stuffs here at the house tonight. The fine folks in the FreeBSD Discord were able to guide me to the following in order to build a working file system on my 2GB SD Card.

# newfs_msdos -F 32 -c32 -C 2G /dev/da0

As of today’s FreeBSD 14CURRENT, you have to massage the numbers around even though this should have just worked right out of the box. I suspect the math inside of sector and cluster calculation may not be correct.

]]>
The Shortlist #10: PHP modules http://blog.ignoranthack.me/?p=376 Fri, 31 Jul 2020 18:55:15 +0000 http://blog.ignoranthack.me/?p=376 I really just meant to post a quick note this morning on two gotchas I tripped over when trying to integrate the cell phone and my FreeBSD Jail of WordPress.

Bah. Good luck with that.

Error #1: WordPress detonates when I try to post and becomes unresponsive. /var/log/nginx/error.log shows:

PHP message: PHP Fatal error: Uncaught Error: Call to undefined function ctype_digit()

Bah, why did the WP->Twitter plugin explode on this today? I’m assuming that PHP 7.2 has changed its packaging on FreeBSD so … build and install php72-ctype. Let’s try this again.

Error #2: WordPress detonates when I try to post and becomes unresponsive. /var/log/nginx/error.log shows:

PHP message: PHP Fatal error: Uncaught Error: Call to undefined function filter_var()

Same kind of deal. More explosions in the WP->Twitter plugin. Build and install php72-filter. Excellent. I can now annoy everyone with my ignorance again.

]]>
Sometimes less is more. Checkout individual #FreeBSD ports for testing. http://blog.ignoranthack.me/?p=241 Thu, 21 Jul 2016 15:41:03 +0000 http://blog.ignoranthack.me/?p=241 I needed to test a single FreeBSD port today for a specific release.  The FreeBSD project maintains a series of reference build machines for this type of work, but normally I maintain an entire ports tree checkout for this type of work.

The FreeBSD ports tree has 20k+ individual software packages maintained in it, and I was not in the mood to checkout all of that onto a host for the purpose of validating a build of QEMU on FreeBSD 10.

Turns out, if you pay attention, you can indeed do some individual checkouts of things in a sparse fashion and get results that are useful.  Your mileage may vary here depending on the needed dependencies, but this should be a useful hint to getting started.

I will only address how to do this with Subversion, but I’m sure that the folks who use git will have no trouble seeing how to duplicate this scenario.

  • svn co –depth files svn+ssh://repo.freebsd.org/ports/head fbsd_ports
  • cd fbsd_ports
  • svn co svn+ssh://repo.freebsd.org/ports/head/Mk
  • svn co svn+ssh://repo.freebsd.org/ports/head/Templates
  • svn co –depth files svn+ssh://repo.freebsd.org/ports/head/lang
  • cd lang
  • svn co svn+ssh://repo.freebsd.org/ports/head/lang/perl5.20
  • svn co svn+ssh://repo.freebsd.org/ports/head/lang/python27
  • cd ..
  • svn co –depth files svn+ssh://repo.freebsd.org/ports/head/emulators
  • cd emulators
  • svn co svn+ssh://repo.freebsd.org/ports/head/emulators/qemu-user-static
  • svn co svn+ssh://repo.freebsd.org/ports/head/emulators/qemu-sbruno

My goal, was to build qemu-user-static for FreeBSD 10.  There’s a bunch of dependencies here, so I’ll try and unwind them a bit.

In order to build any port, you need the files contained in the top of tree.  The support Makefiles in Mk/ and Templates/ are required to do a lot of things and may or may not be used as short cuts/helpers in the Makefiles of individual ports.

The Makefile of any directory that you traverse to get to your port will need to exist (emulators/Makefile for example)

The lang/perl and lang/python ports are needed here as there is some pollution in the Makefiles that requires something to be parsed during builds.  This probably shouldn’t be there, but is beyond the scope of what I wanted to get done this morning.

Checking out the individual ports into their proper locations and setting PORTSDIR in your environment to your new directory structure (/home/sbruno/fbsd_ports) will now allow you to use your new checkout in some fashion to build.

]]>
The EEPROM you have reached is no longer in service, #FreeBSD recovery of em(4) devices http://blog.ignoranthack.me/?p=239 Thu, 29 Oct 2015 17:44:57 +0000 http://blog.ignoranthack.me/?p=239 Ran into a very strange error with legacy em(4) devices on FreeBSD this week.  Something I was doing while working on the EM_MULTIQUEUE kernel config option for em(4) seems to have blown up the PXE configuration in the EEPROM of one of my lem(4) devices.  Else, cosmic rays did it:

em3: <Intel(R) PRO/1000 Legacy Network Connection 1.1.0> port 0xe880-0xe8bf mem 0xfeb80000-0xfeb9ffff,0xfeb60000-0xfeb7ffff irq 19 at device 6.0 on pci5
em3: The EEPROM Checksum Is Not Valid
device_attach: em3 attach returned 5

It took me a while, but it seems when this happens, you can sometimes recover the device with Intel’s Ethernet Connections Boot Utility.

There is a DOS utility in this self-extracting CAB file called “bootutil” that can be used to reset your device to defaults.  After prepping a DOS usb stick, I booted my host from it and ran the tool against all devices as I couldn’t quite tell which device was actually having the issues:

bootutil -all -defcfg

This cleared the error and now I get a successful attach.  I literally have no idea what the problem was in the first place, but solved.

Props to the IPXE folks for having a great HOWTO on generically manipulating the firmware flash that gave me the clue on what to do.

]]>
The Short List #8: fetchmailrc/gmail/ssl … grrr #FreeBSD http://blog.ignoranthack.me/?p=228 Thu, 18 Dec 2014 21:48:14 +0000 http://blog.ignoranthack.me/?p=228 Didn’t realize that a fetchmail implementation I was using was actually *not* using SSL for a month.  I had installed security/ca_root_nss but FreeBSD doesn’t assume that you want to use the certificates in this package.  I don’t understand it, but whatever.

So, add this to your fetchmailrc to actually use the certificate authorities in there and really do SSL to your gmail account:

sslcertfile /usr/local/share/certs/ca-root-nss.crt

]]>
Using the xdev target with qemu-user-static on #FreeBSD http://blog.ignoranthack.me/?p=221 Thu, 31 Jul 2014 16:12:06 +0000 http://blog.ignoranthack.me/?p=221 I’ve been playing with building ports for ARM on an AMD64 machine via a bunch of tools.  The duct tape and bailing wire is a bit thick with this method, but if you keep at it, this should work.

1. build armv6 chroot:
make buildworld TARGET=arm TARGET_ARCH=armv6
make installworld TARGET=arm TARGET_ARCH=armv6 DESTDIR=/armv6
make distribution TARGET=arm TARGET_ARCH=armv6 DESTDIR=/armv6

2. build xdev
make xdev TARGET=arm TARGET_ARCH=armv6 NOSHARED=y

3. move xdev into chroot
mv /usr/armv6-freebsd /armv6/usr/

4. add toolchain to make.conf:
CFLAGS+=-integrated-as
CC=/usr/armv6-freebsd/usr/bin/cc
CPP=/usr/armv6-freebsd/usr/bin/cpp
CXX=/usr/armv6-freebsd/usr/bin/c++
AS=/usr/armv6-freebsd/usr/bin/as
NM=/usr/armv6-freebsd/usr/bin/nm
LD=/usr/armv6-freebsd/usr/bin/ld
OBJCOPY=/usr/armv6-freebsd/usr/bin/objcopy
SIZE=/usr/armv6-freebsd/usr/bin/size
STRIPBIN=/usr/armv6-freebsd/usr/bin/strip
5. Install qemu-static-user from ports and copy into jail:
pkg instlal qemu-static-user
mkdir -p /armv6/usr/local/bin
cp /usr/local/bin/qemu-arm /armv6/usr/local/bin/

6. setup binmiscctl to handle armv6 translations:
binmiscctl add armv6 –interpreter “/usr/local/bin/qemu-arm” –magic “x7fx45x4cx46x01x01x01x00x00x00x00x00x00x00x00x00x02x00x28x00” –mask “xffxffxffxffxffxffxffx00xffxffxffxffxffxffxffxffxfexffxffxff” –size 20 –set-enabled

7. mount devfs and ports if needed
mount -t devfs devfs /armv6/dev
mount -t nullfs /usr/ports /armv6/usr/ports

8. chroot
chroot /armv6

]]>
Using qemu-user to chroot and bootstrap other architectures on #FreeBSD http://blog.ignoranthack.me/?p=218 Sat, 19 Jul 2014 22:18:32 +0000 http://blog.ignoranthack.me/?p=218 My last post spawned enough feedback that I thought I would dump some notes here for those interested in building a chroot on FreeBSD that allows you to test and prototype architectures, e.g. ARMv6 on AMD64.

The FreeBSD buildsys has many targets used for many things, the two we care about here are buildworld and distribution.  We will also be changing the output architecture through the use of TARGET and TARGET_ARCH command line variables.  I’ll assume csh is your shell here, just for simplicity.  You’ll need 10stable or 11current to do this, as it requires the binary activator via binmiscctl(8) which has not appeared in a release version of FreeBSD yet.

Checkout the FreeBSD source tree somewhere, your home directory will be fine and start a buildworld.  This will take a while, so get a cup of tea and relax.

make -s -j <number of cpus on your machine> buildworld TARGET=mips TARGET_ARCH=mips64 MAKEOBJDIRPREFIX=/var/tmp

Some valid combinations of TARGET/TARGET_ARCH are:

mips:mips

mips:mip64

arm:armv6

sparc64:sparc64

powerpc:powerpc

powerpc:powerpc64

i386:i386

amd64:amd64

Once this is done, you have an installable tree in /var/tmp.  You need to be root for the next few steps, su now and execute these steps:

make -s installworld TARGET=mips TARGET_ARCH=mips64 MAKEOBJDIRPREFIX=/var/tmp DESTDIR=/opt/test

DESTDIR is where you intend on placing the installed FreeBSD system.  I chose /opt/test here only because I wanted to be FAR away from anything in my running system.  Just to be clear here, this will crush and destroy your host computer without DESTDIR set.

Next, there are some tweaks that have to be done by the buildsys, so run this command as root:

make -s distribution TARGET=mips TARGET_ARCH=mips64 MAKEOBJDIRPREFIX=/var/tmp DESTDIR=/opt/test

Now we need to install the emulator tools (QEMU) to allow us to use the chroot on our system.  I suggest using emulators/qemu-user-static for this as Juergen Lock has set it up for exactly this purpose.  It will install only the tools you need here.

Once that is installed, via pkg or ports, setup your binary activator module for the architecture of your chroot.  Use the listed options on the QEMU user mode wiki page for the architecture you want.  I know the arguments are not straight forward, but there should be examples for the target that you are looking for.

For this mips/mips64 example:

binmiscctl add mips64elf –interpreter “/usr/local/bin/qemu-mips64-static”
–magic “x7fx45x4cx46x02x02x01x00x00x00x00x00x00x00x00x00x00x02x00x08”
–mask “xffxffxffxffxffxffxffx00xffxffxffxffxffxffxffxffxffxfexffxff”
–size 20 –set-enabled

Copy the binary qemu that you setup in this step *into* the chroot environment:

mkdir -p /opt/tmp/usr/local/bin

cp /usr/local/bin/qemu-mips64-static /opt/tmp/usr/local/bin/

Mount devfs into the chroot:

mount -t devfs devfs /opt/tmp/dev

Want to try building ports in your chroot?  Mount the ports tree in via nullfs:

mkdir /opt/tmp/usr/ports

mount -t nullfs /usr/ports /opt/tmp/usr/ports

And now, through the QEMU and FreeBSD, you can simply chroot into the environment:

chroot /opt/tmp

Hopefully, you can now “do” things as though you were running on a MIPS64 or whatever architecture machine you have as a target.

arm:armv6, mips:mips, mips:mips64 are working at about %80-90 functionality.  powerpc:powerpc64 and powerpc:powerpc are still a work in progress and need more work.  sparc64:sparc64 immediately aborts and probably needs someone with an eye familiar with the architecture to give QEMU a look.  If you are interested in further development of the qemu-user targets, please see my github repo and clone away.

If you are looking to see what needs to be done, Stacey Son has kept an excellent log of open item on the FreeBSD Wiki

]]>
Cross building ports with qemu-user and poudriere-devel on #FreeBSD http://blog.ignoranthack.me/?p=212 Sat, 19 Jul 2014 19:36:13 +0000 http://blog.ignoranthack.me/?p=212 I’ve spent the last few months banging though the bits and pieces of the work that Stacey Son implemented for QEMU to allow us to more or less chroot into a foreign architecture as though it were a normal chroot.  This has opened up a lot of opportunities to bootstrap the non-x86 architectures on FreeBSD.

Before I get started, I’d like to thank Stacey Son, Ed Maste, Juergen Lock, Peter Wemm, Justin Hibbits, Alexander Kabaev, Baptiste Daroussin and Bryan Drewery for the group effort in getting us the point of working ARMv6, MIPS32 and MIPS64 builds.  This has been a group effort for sure.

This will require a 10stable or 11current machine, as this uses Stacey’s binary activator patch to redirect execution of binaries through QEMU depending on the ELF header of the file.  See binmiscctl(8) for more details.

Mechanically, this is a pretty easy setup.  You’ll need to install ports-mgmt/poudriere-devel with the qemu-user option selected.  This will pull in the qemu-user code to emulate the environment we need to get things going.

I’ll pretend that you want an ARMv6 environment here.  This is suitable to build packages for the Rasberry PI and Beagle Bone Black.  Run this as root:

binmiscctl add armv6 –interpreter “/usr/local/bin/qemu-arm” –magic
“x7fx45x4cx46x01x01x01x00x00x00x00x00x00x00x00x00x02
x00x28x00″ –mask “xffxffxffxffxffxffxffx00xffxffxffxff
xffxffxffxffxfexffxffxff” –size 20 –set-enabled

This magic will load the imgact_binmisc.ko kernel module.  The rest of the command line instructs the kernel to redirect execution though /usr/local/bin/qemu-arm if the ELF header of the file matches an ARMv6 signature.

Build your poudriere jail (remember to install poudriere-devel for now as it has not been moved to stable at the time of this writing) with the following command:

poudriere jail -c -j 11armv632 -m svn -a armv6 -v head

Once this is done, you will be able to start a package build via poudriere bulk as you normally would:

poudriere bulk -j 11armv632 -a

or

poudriere bulk -j 11armv632 -f <my_file_of_ports_to_build>

Currently, we are running the first builds in the FreeBSD project to determine what needs the most attention first.  Hopefully, soon we’ll have something that looks like a coherent package set for non-x86 architectures.

For more information, work in progress things and possible bugs in qemu-user code, see Stacey’s list of things at:

https://wiki.freebsd.org/QemuUserModeHowTo

https://wiki.freebsd.org/QemuUserModeToDo

]]>