Arch Install over Existing Linux (Mint) Installation with Windows 8 UEFI

Wow, that title sounds like fun.

Well, it wasn't bad at all.  After using Mint for a couple years I started to get frustrated with the outdated packages in APT (to name a few: scilab, hplip, freemind, bluez).  I liked Mint just fine, and keeping the system up to date is quite painless, which is a lot more than I can say for the several years I spent with Gentoo.

That being said, as I Googled for problems I was having with my Bluetooth setup, I noted that most of the hits were generated by archlinux.org.  I read a little about the distro and I decided to try it out.

For installers, there is so much information available on the Arch wiki it isn't even funny.  There's the 30,000 foot installation guide, which for experts is more of a checklist if you've done it a lot.  For everyone else but the sysadmins and hard-core experts, I recommend their beginner's guide.  This will have you going in no time.

The first thing I noticed was how small the LiveCD was -- it's only 500MB or so.  This is because Arch gives you a bare, and I mean BARE bones setup.  You won't find photo managers, a word processor, solitaire, and mine sweeper.  You won't find ANYTHING except the bare basics to boot the system and get you going.  Everything after that is what YOU add, and this can sometimes be shocking.  For example, if you think you might connect to a secure wifi network with your laptop, you might want to install wpa_supplicant.

Before installing Arch, I spent some time cleaning out my Mint system.  Not unlike moving day, you've got to pack your crap and move out.  This takes some time.

Once I thought I was ready to go, I knew I wasn't going to follow the beginner's guide to a T.  All I really needed to do was wipe my root partition, install the new kernel, set up the new environment, and reboot.

So, I didn't need to know about partitioning or formatting.  I knew I needed to start somewhere in that area of the guide.

After booting the LiveCD I quickly realized I needed to have some knowledge about the existing partitions.  I used lsblk:

$ lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465.8G  0 disk 
|-sda1   8:1    0   500M  0 part
|-sda2   8:2    0    40M  0 part 
|-sda3   8:3    0   128M  0 part 
|-sda4   8:4    0   500M  0 part 
|-sda5   8:5    0   232G  0 part 
|-sda6   8:6    0   7.2G  0 part 
|-sda7   8:7    0 190.8M  0 part
|-sda8   8:8    0 220.3G  0 part
`-sda9   8:9    0   4.9G  0 part

Well, I know the 200+ GB partitions are my Windows 8 drive and my Linux drive, but I wasn't sure which.  I just had to mount them and take a look around to figure out what was what.

I ended up scribbling the following down on a scrap of nearby paper:

/sda8 --> data/root
/sda9 --> swap
/sda7 --> boot/grub

I think it is obvious, but I want to note, that if you follow any instructions here you'd better be damn sure you know what you're doing.  Computer configuration can be UNFORGIVING.  If you are attached to any data on your hard drive, you'd better back everything up right now.  The computer doesn't particularly care if it blows all of your wedding pictures away.  You have been warned.

Now then -- I formatted /sda8 as ext4 (it already was formatted ext4, but I basically wanted to wipe it).  I did a "swapon /sda9", I mounted sda7 as /boot, and I chrooted into sda8.  (Okay, there was a little more to it than that but I basically followed the beginner's guide after the part about partitioning your system.)

Boom, I was in my new Linux system.  Now the tricky part was setting up GRUB.  There is a lot of info about GPT, UEFI, etc all over the Arch Wiki.  In particular see the excellent grub guide.  Most of the guides are taking you from ground zero, where you're starting with a blank drive.  In my case, I had a drive that was already populated.

In particular there are some warnings about checking for a GPT and an ESP here.

I didn't see a GPT when I tried using parted as described above.  In fact this is what I've got:

[root@marquette /]# parted /dev/sda print
Model: ATA ST500LM012 HN-M5 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name                          Flags
 1      1049kB  525MB   524MB   fat32           EFI system partition          boot
 2      525MB   567MB   41.9MB  fat32           Basic data partition          hidden
 3      567MB   701MB   134MB                   Microsoft reserved partition  msftres
 4      701MB   1226MB  524MB   ntfs            Basic data partition          hidden, diag
 5      1226MB  250GB   249GB   ntfs            Basic data partition
 7      250GB   251GB   200MB   ext4
 8      251GB   487GB   237GB   ext4
 9      487GB   492GB   5264MB  linux-swap(v1)
 6      492GB   500GB   7765MB  ntfs            Microsoft recovery partition  hidden, diag

So there's my ESP, partition 1 or /sda1.  I don't see "Partition Table: GPT" as the wiki mentions.  The article also mentions:  "An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article."

Okay then, I don't think I have it, and I'm not messing around with these existing partitions lest I break my Windows 8 installation.

Check out the UEFI Alternative Method.  Here we are getting into some interesting commands.  What I noticed while I was poking around on /boot is that I already have a directory called /boot/efi.  FURTHER, I noticed while poking around the EFI parition (sda1 for me), that there was /Boot, /EFI, /Microsoft, /linuxmint directories.  Inside these I would drill down and eventually find some *.efi files.  Presumably this is where the booting magic happens.

I ended up mounting /dev/sda1 at /boot/efi:

[root@marquette /]# mount /dev/sda1 /boot/efi

Following the alternative instructions on the Arch grub wiki, I did this (modified what was on the wikipage and copied below):

# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch --boot-directory=/boot --recheck --debug

Don't forget the equal signs after the command line arguments!  You might get errors without some of them.  If all was successful, you'll see some stuff like this at the end:

grub-install: info: executing efibootmgr -c -d /dev/sda -p 1 -w -L arch -l \EFI\arch\grubx64.efi.

BootCurrent: 0008

Timeout: 0 seconds

BootOrder: 0008,0001,0002,0003,0000,0004,0005,0006,0007

Boot0000* mint

Boot0001* Realtek PXE B09 D00

Boot0002* P4: HL-DT-ST DVD+-RW GT80N    

Boot0003* P0: ST500LM012 HN-M500MBB     

Boot0004* Windows Boot Manager

Boot0005* UEFI: IP4 Realtek PCIe FE Family Controller

Boot0006* UEFI: IP6 Realtek PCIe FE Family Controller

Boot0007* linuxmint

Boot0008* arch

Installation finished. No error reported.

It turns out all of the crap above will be visible by the BIOS -- these *are* your UEFI boot options.  You'll want "arch" to be your main entry point.  (I still have to figure out how to get rid of some the old mint stuff.)

Next do: 

# grub-mkconfig -o /boot/grub/grub.cfg

[root@marquette boot]# grub-mkconfig -o /boot/grub/grub.cfg

Generating grub configuration file ...

Found linux image: /boot/vmlinuz-linux

Found initramfs image: /boot/initramfs-linux.img

Found fallback initramfs image: /boot/initramfs-linux-fallback.img

Found linux image: /boot/vmlinuz-linux

Found initrd image: /boot/initramfs-linux.img

Found linux image: /boot/vmlinuz-3.12.7-031207-generic

Found initrd image: /boot/initrd.img-3.12.7-031207-generic

Found linux image: /boot/vmlinuz-3.12.6-031206-generic

Found initrd image: /boot/initrd.img-3.12.6-031206-generic

  /dev/cdrom: open failed: No medium found

Found Windows Boot Manager on /dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi

done

Now, reboot and see if it worked.  If all went well you should see the grub boot screen.

If you get a grub command line, something went wrong.  You can try following these instructions to see if you can get up and running again.

Good luck.

Wii Remote Plus and Linux

I've had this happen to me several times:

• Find some cool project on the internet involving some piece of hardware
• Run out and buy the hardware
• Can't get hardware to work as advertised
• Discover that the hardware I bought is revision "d" and I needed revision "c or lower"

Welp, if you're trying to get a Wiimote to work, you're might be here because you can't get it working or you don't know what to do next.

The first thing I learned is that there are several types of Wiimote controllers.  The basic one looks like this:

Wiimote, image from http://metroid.wikia.com/wiki/Wii_Remote

Now, I ran down to Best Buy to get one of these, and I found about FIFTY of these (at least) hanging on a rack, in all different colors.  Except they were slightly different.  What I got was the Wii Remote Plus:

Wii Remote Plus, image from Amazon.com

This is all confusing since my Wii Remote Plus says "MotionPlus Inside".  Turns out the MotionPlus was a little plugin/add-on for the first Wiimote that gave it higher resolution and more sensing capabilities.  This device is built-in to the Wii Remote Plus, so almost certainly for marketing reasons they had to give this device a new name and a rubber case.  Behind the rubber case the device looks basically identical to the original Wiimote above but it INCLUDES the higher-resolution sensing.  It cost me $31 at Best Buy.

There are add-ons, like nunchucks, drums, guitars, etc.

Now, there is lots of information available about hacking these devices.

Maybe the most well-known is wmgui, part of Donnie Smith's cwiid project:

wmgui, part of the cwiid project

The wmgui program (shown above) runs in Linux and displays the Wiimote sensor outputs.  I didn't get it to work, apparently because I have a Wii Remote Plus.  From what I gather support for the Wii Remote Plus wasn't added.  

Further, this program  requires that you pair to the device directly from the app in userspace, something that seemed to annoy David Hermann:

The XWiimote software stack is a very recent approach to write Linux drivers for the Nintendo Wii Remote. Long time cwiid and wiiuse were the only choices to use Wii Remotes under Linux. However, both tools very badly designed. They require the application that uses the device to perform a Bluetooth inquiry, connect to the device and run a user-space driver instead of adding the device to the Linux input devices and let applications use them with well-defined APIs like linux-input / evdev. An application does not need to connect to keyboards by itself so why should it need to connect to Wii Remotes? Also the libraries provided by both projects either required threads or global objects which is horrible to use in most applications. This is why the XWiimote project was created.

While calling cwiid and wiiuse "very badly designed", David seems to have picked up the torch and created a proper driver (hid-wiimote.ko) for the Wiimote that has been in the Linux kernel since verson 3.1.  

There's also a BlueZ plugin since version 4.96.  This is perhaps why my installed version of bluez was able to pair with the Wii Remote Plus immediately, and for that I give David (and the other project authors) thanks:

wskellenger@marquette ~ $ dpkg --list | grep bluez

ii  bluez                                    4.98-2ubuntu7

I also found that once paired, the arrow keys on the Wii Remote Plus are also used immediately by X.Org (for example to position a cursor), just as described here, although I haven't installed xwiimote-tools yet...  So because I'm suing a kernel 3.12 the support is already there.  This is cool.  I assume I'm already using xwiimote, so I didn't even get to look at wiiuse.  The rest of the article will thus talk about xwiimote and accompanying tools.

Now, I want to see more about the data that is coming from this controller and David describes the xwiimote-tools package that goes with the kernel driver.  This is easy enough to acquire and build from source:

wskellenger@marquette ~/Projects $ git clone https://github.com/dvdhrm/xwiimote.git

Cloning into 'xwiimote'...

remote: Reusing existing pack: 1249, done.

remote: Total 1249 (delta 0), reused 0 (delta 0)

Receiving objects: 100% (1249/1249), 705.21 KiB | 952 KiB/s, done.

Resolving deltas: 100% (604/604), done.

wskellenger@marquette ~/Projects $ cd xwiimote/

wskellenger@marquette ~/Projects/xwiimote $ ./autogen.sh 

...bunch of output skipped...

wskellenger@marquette ~/Projects/xwiimote $ make

At this point the code is compiled and you could run "make install", but I wasn't ready to do that yet, I just wanted to see xwiishow.

wskellenger@marquette ~/Projects/xwiimote $ find | grep xwiishow

./doc/xwiishow.1

./tools/xwiishow-xwiishow.o

./tools/.deps/xwiishow-xwiishow.Po

./tools/xwiishow.c

./xwiishow

./.libs/xwiishow

There she is (bold above).  I tried to run it:

wskellenger@marquette ~/Projects/xwiimote $ ./xwiishow

Usage:

xwiishow [-h]: Show help

xwiishow list: List connected devices

xwiishow <num>: Show device with number #num

xwiishow /sys/path/to/device: Show given device

UI commands:

q: Quit application

f: Freeze/Unfreeze screen

s: Refresh static values (like battery or calibration)

k: Toggle key events

r: Toggle rumble motor

a: Toggle accelerometer

i: Toggle IR camera

m: Toggle motion plus

n: Toggle normalization for motion plus

b: Toggle balance board

p: Toggle pro controller

g: Toggle guitar controller

d: Toggle drums controller

1: Toggle LED 1

2: Toggle LED 2

3: Toggle LED 3

4: Toggle LED 4

Cool, there's a ton of stuff you can play with.  First I'll try 'list':

wskellenger@marquette ~/Projects/xwiimote $ ./xwiishow list

Listing connected Wii Remote devices:

  Found device #1: /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:12/0005:057E:0330.000B

End of device list

That being accomplished with success, it sees a device #1 which looks like it works with the xwiishow <1> command above:

wskellenger@marquette ~/Projects/xwiimote $ ./xwiishow 1

What I got was a warning that I wasn't running as root, something that looked like this:

Running xwiishow as a normal user.  Press 'q' to exit.

Just press 'q' to exit and try again as root.  Note the warning above "screen smaller than 80x24; no view" -- if you see this you should enlarge your terminal window before you try this:

wskellenger@marquette ~/Projects/xwiimote $ sudo ./xwiishow 1

Now I got a warning that the window still wasn't large enough, so make it at least 160x48 and you'll get this:

Cool! As you move the device around you can see all of the data that it spits out.  You can also see some awesome ASCII art, the likes and caliber of which I haven't seen since my Telix days in the early 90s.  

Now you can play with the other features, like using the keyboard buttons 1-4 to enable/disable the LEDs on the device, or the 'R' key to enable/disable the feedback motor (vibrator) inside.

Thanks to David Hermann (xwiimote), Donnie Smith (cwiid), and Michael LaForest (wiiuse) for their hours of hacking to bring us these cool tools!

Depending on what you want to do, you may need to figure out which package you need.  For the project I've got in mind I'm hoping I can just use xwiimote, since it is already there in the kernel, there isn't any need to install anything else.

Dell Inspiron 3520 + Broadcom 43142 Bluetooth Not Visible/Not Pairing (Linux Mint/Ubuntu)

I started to write a much longer post here but I deleted the whole thing and started over.  Instead I'll just describe what I've done in the past 24 hours to get wireless working on my Inspiron 3520 with the ugly duckling Broadcom 43142 Wifi+Bluetooth card:

• I updated the Bluetooth drivers *in Windows 8* first.  I saw this recommended somewhere in my research, that the firmware would be updated through Windows first.  I got the latest drivers from dell.com.
• I updated the BIOS using the update file I found at dell.com for my machine.
• While I was at it I updated the wifi driver in Windows also (the file was also from dell.com).

Still, after all of that, I didn't have any luck with Bluetooth.  The adapter was simply not visible.

Then:

I upgraded the kernel version from 3.4.x to 3.12.x.  

Boom.  Suddenly the Bluetooth adapter was visible and I could actually use it to connect with devices.  This was something I hadn't seen before yesterday:

I was able to pair devices and everything was spendid.

Unfortunately, wifi stopped working.

At this point I just went to bed, I was tired of messing with this and it was about midnight or so.

Jump forward about 18 hours and I started working on the wifi issue.

This thread was the most help in solving that problem.  The long and short of it is, for this card I've only found that the "wl" kernel module will work to support this thing.  I used this file (available at the above linked thread):

bcmwl-kernel-source_6.30.223.141+bdcom-0ubuntu1_amd64.deb

I installed it with the Package Installer, despite the warning that this version was newer than the 'official' one.  Wifi works now.  All is great, except:

Now bluetooth stopped recognizing devices.

At least I can still see the adapter, where before I couldn't:

wskellenger@marquette ~ $ hciconfig -a
hci0: Type: BR/EDR  Bus: USB
BD Address: C0:18:85:CB:56:42  ACL MTU: 1021:8  SCO MTU: 64:1
UP RUNNING PSCAN 
RX bytes:1575 acl:0 sco:0 events:96 errors:0
TX bytes:1918 acl:0 sco:0 commands:84 errors:0
Features: 0xff 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
Link policy: RSWITCH HOLD SNIFF 
Link mode: SLAVE ACCEPT 
Name: 'marquette-0'
Class: 0x7e0100
Service Classes: Networking, Rendering, Capturing, Object Transfer, Audio, Telephony
Device Class: Computer, Uncategorized
HCI Version: 4.0 (0x6)  Revision: 0x0
LMP Version: 4.0 (0x6)  Subversion: 0x210b
Manufacturer: Broadcom Corporation (15)

Now, I can't confirm that installing the wifi driver caused my bluetooth issue.  To be honest, since it was a full day later, I don't know why I couldn't see devices any longer.  After all, it worked last night!  I tried un-installing the driver, re-installing the kernel, rebooting several times, but no dice, I could not get bluetooth to recognize anything at all.  In fact, all I was trying to do was get back to the performance from last night, where Bluetooth pairing worked.  I didn't care about wifi anymore.

Then I found this post.

Basically it instructs you to install this package:

bt-bcm43142-onereic_0.0+20111116somerville2_amd64.deb

And after restarting the bluetooth daemon, I was in business:

marquette wskellenger # service bluetooth restart
bluetooth stop/waiting
bluetooth start/running, process 7070

I don't think it is working perfectly.  I'm noticing a lot of glitchy behavior, like after pairing my Wii MotionPlus, I notice notifications from the Power Manager that my laptop battery is charging...?  I'll make updates here if I find anything else unusual.  For now I'm happy to see this, native pairing of the MotionPlus without any additional software:

Now, for anyone that reads this:  This Broadcom card is a pain in the ass for Linux users.  I've had nothing but trouble with this thing under Linux and it has poor performance (poor reception, dropping connections) in Windows as well.  In researching these issues, I came across posts marked [WORKAROUND], where the proposed workaround included purchasing a different adapter and being done with this Broadcom nonesense.  I'm seriously considering going that route also.

But then again:  this device seems to work with much less hassle in Windows.

UPDATE (18-Jan-2014): I've got better results with Arch Linux and Bluez5.  I'll write a new post on that.


(Philosophy follows)

A Harley rider once told me that working on the bike and making modifications are part of the experience, part of the fun.

And, to some extent I think that comparison rings true for Linux users.  It is frustrating to me that I can't just start working on my next diversion involving this Nintendo controller + Bluetooth, but at the same time I am motivated to stay up until 2 and 3 in the morning tinkering around trying to get it to work!  Why?  Over the last few years, I've spend countless hours messing around with stuff like this and I sometimes look back and wonder if it was worth it.

If you're trying to bake a cake for the first time, do you assemble the recipe ingredients and then expect that some obscure unused feature of your oven won't work at the last minute?  Of course not.

But at the same time there is something fun about this that I can't explain it to anyone else.  I've got a computer running on 100% free software, and with that brings the ability to examine in great detail how everything works.  I've learned so much from >10 years of messing around that I think at the end of the day, it has all been worth the struggle.

Current time: 12:20 am.

Using Two Monitors with xfce4 (Linux Mint)

I just switched to xfce4 from Cinnamon and the first thing I needed was dual monitor support.  From what I can gather reading the forums, newer versions of xfce4 have dual monitor support included.

Unfortunately, the version I installed from apt-get doesn't.

Workaround:

$ sudo apt-get install arandr

Now from a terminal:

$ arandr

You'll get something like this:

Notice my laptop display (LVDS1) and my monitor (VGA1) are superimposed on top of each other, and this is exactly how my display looks right now:  the larger monitor has the most content, and the smaller laptop display shows the portion of the content as represented by the rectangle above.

To get dual monitor support just drag one of the rectangles to where you want it, i.e.:

Now click the green checkmark at the upper left.

In a few moments you should be enjoying dual displays.