The Short List: #3 #FreeBSD

Sandybridge/Ivybridge/Haswell boxes take upwards of 10 minutes to just GET TO THE BOOT LOADER now.  When I want to get a box into single user, and not miss the loader prompt when using FreeBSD:
nextboot -o “-s” -k kernel

ZFS based systems will emit a terrifying warning of:

WARNING: loader(8) has only R/O support for ZFS
nextboot.conf will NOT be reset in case of kernel boot failure

Which means you need to pay attention if your system panics on restart.


The Short List: #2

Migrating a system from its UFS installation to a new shiny ZFS pool:
cd / && tar –exclude=zroot/ –exclude=dev/ –exclude=proc/ -cvf – * | ( cd /zroot; tar xfp – )

Embedded FreeBSD

How to fry a router in X-1 steps, The Serial Console complete

If you saw my first post  regarding my attempts to use a DLink DIR-825 with FreeBSD, you noted that I was busily trying to get the serial console working.  I won’t go over the reasons for it in this new post, but get straight into the fun and games.

My motivation here is to make the serial console available without ripping open the case every time there is an issue.  FreeBSD in a OpenWRT/DD-WRT style configuration is a very open universe right now and there will be lots of changes to come.

For now, let’s start with the ingredient list:

  1. DLink DIR-825 rev. B1
  2. Soldering Iron, solder, solder braid, good tweezers, scissors, exacto-knife
  3. Jumper wire leads, F-F
  4. OSEPP FTDI Breakout Board kit
  5. Circuit Board safe superglue

Step 1 of this operation is to open the DIR-825, remove the main board and solder on pins to JP1 on the board.

Once that is secure and you’ve validated that you can use your USB TTL adapter to get a serial console then you can move forward to setup the internal mounting and give yourself an external connector.

The case is used in 2 and 3 antenna models.  This unit leaves us the center antenna mount as a  very convient place to secure our TTL USB adapter.  Get your exacto-knife and cut out the black label area covering this hole.  Then gently cut out the top half of the innner plastic ring as I have shown in this photo.

DLink_USB_Mod_CaseSee how nicely the USB connector presents itself?  Its as though we planned this out!

Next, I modified the TTL adapter itself.  I needed to remove the jumper at the center of the adapter as it collides with the capacitor directly adjacent to the mounting point.

DIR825-USB-solderingI then was able to solder a very small length of wire to short the 3.3v selector permanently.  You’ll need a steady hand and the tweezers to pull out the pins and insert the wire.DIR825-USB-33v

You’ll note that I’ve removed the pin header that comes with the adapter.  This was accomplished with a sharp pair of scissors and then using the soldering iron to extract the remainder of the pins with judicious use of tweezers.

Once that was done, I soldered on individual pins for TX, RX and ground. Note that I’ve bent the pins at a 45 degree angle.  This will avoid any issues with the pins making contact with the mainboard.

Now that you have all the pieces ready to go, its time to break out the superglue and mount the thing.  When choosing a glue, you’ll need to get one that is safe for PCB and plasitc in general, your local electronics and hobby shop can direct you to the proper stuffs.

I mounted the TTL adapter upside down so that the connector can reach the opening on the case and there are two lower points of contact for the glue to set correctly.DIR825-USB-mount

I applied glue to the two corners next to the USB header, flipped it over and brought it into firm contact with the antenna mount.  After about 1 minute, I released pressure and applied a line of glue across the surface of the TTL adapter such that it sealed against the case of the router.

DIR825-USB-GLUE2Now … WALK AWAY for at least 6 hours.  If you’re using the right kind of glue, there’s some science happening here and you need to let the glue/plastic cure to get a secure mount.DIR825-USB-FINAL

Wire up your TX, RX and ground leads, reattach the case housing and connect up your new USB serial interface to a PC.  On FreeBSD, you should see a new serial port appear.

ugen5.2: <FTDI> at usbus5
uftdio0: <FT232R USB UART> on usbus5

Go ahead, open it with your handy, dandy comm utility, cu:

cu -l /dev/ttyU0 -s 115200

If you’ve done everything right, congrats, you’ll now see the embedded linux distribution boot up.  You are now at Step 0 getting your FreeBSD based home router running.


The Short List: #1

Like the subtitle says, these should be obvious, but I’m forever looking them up.

#1:  Find files in a perforce checkout that are not checked in or are modified:
for file in `p4 diff -f -sa`; do p4 diff -f $file; done

#2 Crosscompile FreeBSDi386 on amd64, its stupid simple, but I can never remember:
TARGET=i386 TARGET_ARCH=i386 MAKEOBJDIRPREFIX=/var/tmp make -s -j16 buildworld
TARGET=i386 TARGET_ARCH=i386 MAKEOBJDIRPREFIX=/var/tmp make -s -j16 buildkernel KERNCONF=PAE



AllMost There — Intel AMT on my ThinkPad T520

Spent some time this week screwing around with the “serial” port on my laptop.  Serial consoles are one of those things that you seem to always need when doing o/s development.  Its the only reliable way to get debugging information and on PC architectures, its really the best way to find and resolve serious problems in the kernel or drivers.

Laptops dropped their DB-9, RS-232 connection years ago and up until recently, you couldn’t really do much with debugging except take pictures of your laptop’s console when it had crashed.  I discovered that my laptop has AMT features built into it and decided to see if I could make FreeBSD use it as a serial console for debugging and diagnostics.  Turns out, its mostly functional and seems to do what I want.

Turning AMT on is a bit goofy, mainly do to some fairly strict password requirements, but lets start from the beginning.  I’m using my Lenovo T520 as an example, so your BIOS will vary based on your laptop vendor.

Hit your “enter the bios key command” which on my ThinkPad is the blue “ThinkVantage” button, but for the rest of the universe is probably F10, DEL or some other normal key.  This should bring up your bios selection menu and now enter your bios configuration menus.

Turn AMT on in BIOS

AMT_BIOS2 I left the values, more or less, at the defaults here.

AMT_BIOS1Save, reboot.  Now when you hit your bios configuration button:


Hit <ctrl-P> now to enter the AMT configuration screens.  AMT_Boot2

The first time you do this, there will only be one option, so hit “1” to enter the AMT configuration screens.  We’ll come back to this menu list later.

AMT_MainIf this is your first time entering this machine’s AMT device, its going to force you to reset the password from “admin” to something else.  The password requirements on the AMT device are pretty strict, but this should explain it for you.

You’ll need to adjust one or two settings and activate the AMT configuration’s IPv4 settings.

AMT_TimeoutSelect SOL/IDRR/KVM.  We’re going to activate Legacy Serial Redirection here

AMT_Conf0Select SOL

AMT_Conf1Obviously, Enable is what we want here.

AMT_Conf2Select Legacy Redirection Mode, then select Enable


Back to Main Menu and Select Network Setup

AMT_Conf3TCP/IP Settings and Setup Wired Lan IPv4 Configuration

AMT_Conf4I’m going to set DHCP mode for this test.  You can set static IP if you wish.

AMT_Conf5Yet another Enable here.

AMT_Conf6At this point, you’re ready to save/exit/reboot.  To test that the DHCP settings are working, toggle your BIOS button again (F10/DEL/ThinkVantage) and hit <ctrl-P> to get the AMT menu again.

AMT_DHCPHit “2” to check that the AMT can indeed get an IP address.  Note that this address is the same as your laptop IP, at least it should be.  There is some magic going on here that allows the AMT device to share the MAC address and the IP address of your host.  Its interesting but also causes odd things to happen that we’ll dig into a little bit later in the post.

Now that you’ve gotten an IP address, you can boot normally into FreeBSD.  We now need to modify FreeBSD to boot up onto a non-standard (COM1,2,3,4) and get the serial console working.  This is pretty standard stuff, /etc/ttys, /boot/loader.conf, /etc/make.conf things.

Determine what the pci bus address of the UART is in your system via:
pciconf -l | grep uart
uart0@pci0:0:22:3: class=0x070002 card=0x21cf17aa chip=0x1c3d8086 rev=0x04 hdr=0x00
dmesg | grep uart
uart0: <Intel AMT – KT Controller> port 0x6070-0x6077 mem 0xf522c000-0xf522cfff irq 19 at device 22.3 on pci0
uart0: console (115200,n,8,1)
uart0: fast interrupt


comconsole_pcidev=”0:22:3″ #Determine this value from the pciconf -l

If you have a device.hints file, comment out the hints for hw.uart settings.  Leave only the setting for the flags:”isa”

add the -Dh for dual console support

Enable ttyu0
ttyu0 “/usr/libexec/getty std.115200” vt100 on secure

Issue a kill -HUP 1 to let init fire up your getty instance.  If all is well, you can now go to the computer you want to use to as a console device for this laptop.  Using FreeBSD ports, install comms/amtterm. In order to connect to your laptop and validate that its working correctly, issue the following command:
amtterm -p <password you set in the AMT> <IP address of laptop>

If you get a tty login, you’ve suceeded!amtterm: NONE -> CONNECT (connection to host)
ipv4 [] 16994 open
amtterm: CONNECT -> INIT (redirection initialization)
amtterm: INIT -> AUTH (session authentication)
amtterm: AUTH -> INIT_SOL (serial-over-lan initialization)
amtterm: INIT_SOL -> RUN_SOL (serial-over-lan active)
serial-over-lan redirection ok
connected now, use ^] to escape

FreeBSD/amd64 (powernoodle) (ttyu0)



The last steps are fairly trivial.  You need to rebuild your kernel to pickup the changes to /etc/make.conf.  If you do an installkernel and reboot, you’ll now be able to capture the boot up sequence (no boot0 support) once loader starts.  You’ll get to see the beastie menu in all its glory.

The machine I’m using uses a Intel Ethernet chipset via the em(4) driver, this has some very strange behavior that I will take a look at over the next couple of weeks.

With AMT enabled, the ethernet connection only negotiates to 100Mbit.  This is very amusing to me as it acts a lot like IPMI in this regard.  When em(4) initializes it *will* drop your amtterm connection.  Irritating, but em(4) hasn’t been taught enough logic to deal with the connection to the AMT device.

Rebooting the laptop will disconnect your AMT session.  AMT is not a server grade thing like IPMI, so there’s no garauntee of reliability at all.  AMT is sniffing packets that are addressed to the laptop and snipping them out of the air.  Its a very delicate hardware hack but it does to the trick.

Since AMT presents itself as a non-standard COM port, I’m pretty sure that the boot0 and boot2 loaders can’t use AMT as a serial console.  This means that things like gptzfsboot might have issues that you cannot debug.  As far as I can tell however, this is the one of the most likely to work mechanisms for administration of your laptop and development for things like suspend/resume support.


Vertically Integrating Synergy … no really, this is a technical post

Because I couldn’t find any help from the Internet-O-Tron today, let me put this little bit of quality suffering out there for your entertainment.

I just completed murdering my linux box at the office and converted it over to FreeBSD Current with all the lovely Xorg goodness that I need it for.  Really, I only use it to run finch in a screen session and ssh into it from outside, but it does have its value in that.

The last … LAST little bit of my desktop at the office is the synergy tool from ports.  Its a tiny little bit of computer software glue that makes using a laptop as my primary work machine much more useful.  When I dock my T520 (also running FreeBSD Current), the synergy application connects over to my work desktop and I can control/login to it with my mouse and keyboard from my laptop.  Super Effective!

One tiny nit today that really burned out my brain cells.  I had changed the hostname of the box without restarting X.  This caused all kinds of grief that I had never seen before and was super confusing.  I would have been completely lost except for the wonder that is “telnet <hostname> <port>” that I learned way back in the mists of time to troubleshoot firewall and networking issues.

Try it for yourself on a *nix box.  While logged into Gnome, XFCE, KDE or whatever, change the hostname to something other than the one that was set when X started.  <takei>OH MY</takei>

synergy cannot open secondary screen

Breaking down and running the synergy server with -f so that I could see what’s going on, I noted that there appeared to never be a live connection to the host from my client.  Icky.  I assumed initially that there was a firewalling/network problem and started looking at hosts.allow and running truss on synergyc to see what was going on.  I noted, after a long time of grinding through truss output, that synergyc was never even opening a socket to begin with, I fired off a quick “telnet <server> 24800”

When that *DID* connect to the synergys server and I saw the logs it generated, I’ll be honest, I was super confused for like 15 minutes.  The only clue that drug me out of the confusion was the check for .Xauthority stuffs in the truss output.  Geezus, if that hadn’t have been there, I’d have never remembered that I had changed my hostname after I logged in.

The simple answer, not unlike the three finger salute in windows, was to log out of X and back in.  And just like Disco in the 90s, synergy was back.

To whomever in my distant past taught me the trick to telnet as a trouble shooting aid, THANK GOD FOR YOUR EXISTENCE ON THIS PLANET.