UPDATE 2012-11-30: The problem described in this post no longer applies since yesterday 2012-11-29, as the ia32-libs* multiarch transitionals have finally landed in Testing. Installing libgl1-nvidia-glx:i386 after previously installing the rest of the NVIDIA stack from Experimental appears to work flawlessly.

From my previous post:

Quite notably, everything is working fine with the latest Debian wheezy packages (although I compiled my own newer kernel later anyway) except for the onboard sound controller.

Ah! But not so fast! I had forgotten that Debian wheezy’s half-baked multiarch support has serious implications for 32-bit OpenGL-based software on the amd64 platform (a.k.a. x86_64 for everyone else), regardless of whether one is using a proprietary (e.g. NVIDIA) or free (Mesa) stack. In Reicore’s (Mesa) case, this meant that I had to stick to the version from ia32-libs in Testing, which is Mesa 7.7.1 — contrast with the native version, which is 8.0.4.

In Nanacore’s case, the implications span even more packages. The description of the libgl1-nvidia-glx-ia32 package in Testing (amd64 arch) says:

This is an empty transitional package to aid switching to multiarch. Run the following commands to install the multiarch library:

• dpkg --add-architecture i386 ; apt-get update
• apt-get install libgl1-nvidia-glx:i386

And, surprise, surprise. That doesn’t work in Testing because of bug #686033 — fortunately for me, apt-get was wiser in blocking the operation due to some perceived conflicts.

In an attempt to solve this, I pulled the NVIDIA driver packages from Unstable and then tried to install libgl1-nvidia-glx:i386 again to no avail — it requires me to upgrade ia32-libs from the version in Testing to the one in Unstable, which is really a multiarch transition metapackage. After watching multiarch in Debian wheezy become such a major disappointment over time, I decided to do something different with libgl1-nvidia-glx:i386.

I decided to install it by hand.

The procedure was a little convoluted and involved a lot of symbolic links, and I’m not completely sure whether what I did works because I don’t have Wine installed right now and I don’t really want to install Debian’s packages because—again—they use multiarch support to pull nearly 92 MiB worth of redundant crap:

shadowm@nanacore:~$ sudo apt-get install wine
[sudo] password for shadowm: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  gcc-4.7-base:i386 libasound2:i386 libc6:i386 libc6-i686:i386 libdbus-1-3:i386 libdrm-intel1:i386 libdrm-nouveau1a:i386 libdrm-radeon1:i386
  libdrm2:i386 libexpat1:i386 libffi5:i386 libfontconfig1:i386 libfreetype6:i386 libgcc1:i386 libgcrypt11:i386 libgl1-mesa-dri:i386
  libgl1-mesa-glx:i386 libglapi-mesa:i386 libglu1-mesa:i386 libgnutls26:i386 libgpg-error0:i386 libgpm2:i386 libgsm1:i386 libice6:i386
  libjbig0:i386 libjpeg8:i386 libltdl7:i386 liblzma5:i386 libmpg123-0:i386 libncurses5:i386 libodbc1:i386 libp11-kit0:i386 libpciaccess0:i386
  libpng12-0:i386 libsm6:i386 libssl1.0.0:i386 libstdc++6:i386 libtasn1-3:i386 libtiff4:i386 libtinfo5:i386 libuuid1:i386 libv4l-0:i386
  libv4lconvert0:i386 libwine:i386 libwine-alsa:i386 libwine-bin:i386 libwine-gecko-1.4 libwine-gl:i386 libx11-6:i386 libx11-xcb1:i386 libxau6:i386
  libxcb-glx0:i386 libxcb1:i386 libxcomposite1:i386 libxcursor1:i386 libxdamage1:i386 libxdmcp6:i386 libxext6:i386 libxfixes3:i386 libxi6:i386
  libxinerama1:i386 libxml2:i386 libxrandr2:i386 libxrender1:i386 libxslt1.1:i386 libxxf86vm1:i386 uuid-runtime wine-bin:i386 zlib1g:i386
Suggested packages:
  libasound2-plugins:i386 glibc-doc:i386 locales:i386 rng-tools:i386 libglide3:i386 gpm:i386 libmyodbc:i386 odbc-postgresql:i386 tdsodbc:i386
  unixodbc-bin:i386 wine-doc:i386 libwine-cms:i386 libwine-sane:i386 libwine-ldap:i386 libwine-print:i386 libwine-openal:i386 libwine-gphoto2:i386
Recommended packages:
  uuid-runtime:i386 ttf-liberation:i386 xml-core:i386
The following NEW packages will be installed:
  gcc-4.7-base:i386 libasound2:i386 libc6:i386 libc6-i686:i386 libdbus-1-3:i386 libdrm-intel1:i386 libdrm-nouveau1a:i386 libdrm-radeon1:i386
  libdrm2:i386 libexpat1:i386 libffi5:i386 libfontconfig1:i386 libfreetype6:i386 libgcc1:i386 libgcrypt11:i386 libgl1-mesa-dri:i386
  libgl1-mesa-glx:i386 libglapi-mesa:i386 libglu1-mesa:i386 libgnutls26:i386 libgpg-error0:i386 libgpm2:i386 libgsm1:i386 libice6:i386
  libjbig0:i386 libjpeg8:i386 libltdl7:i386 liblzma5:i386 libmpg123-0:i386 libncurses5:i386 libodbc1:i386 libp11-kit0:i386 libpciaccess0:i386
  libpng12-0:i386 libsm6:i386 libssl1.0.0:i386 libstdc++6:i386 libtasn1-3:i386 libtiff4:i386 libtinfo5:i386 libuuid1:i386 libv4l-0:i386
  libv4lconvert0:i386 libwine:i386 libwine-alsa:i386 libwine-bin:i386 libwine-gecko-1.4 libwine-gl:i386 libx11-6:i386 libx11-xcb1:i386 libxau6:i386
  libxcb-glx0:i386 libxcb1:i386 libxcomposite1:i386 libxcursor1:i386 libxdamage1:i386 libxdmcp6:i386 libxext6:i386 libxfixes3:i386 libxi6:i386
  libxinerama1:i386 libxml2:i386 libxrandr2:i386 libxrender1:i386 libxslt1.1:i386 libxxf86vm1:i386 uuid-runtime wine wine-bin:i386 zlib1g:i386
0 upgraded, 70 newly installed, 0 to remove and 0 not upgraded.
Need to get 91.9 MB of archives.
After this operation, 265 MB of additional disk space will be used.
Do you want to continue [Y/n]? 

Not to mention that by pulling Mesa it might as well break my little patchwork setup with NVIDIA’s 32-bit libGL here. This is not something I’m too keen on trying out while stuck on shitty 3.5G mobile broadband.

I intend to revisit and unravel this conundrum at a later point and try to understand and document my libGL installation solution but, again, I have bigger fish to fry.

Six machines. Six plus one equals seven. My current laptop is named Reicore, where rei れい is a possible reading of zero in Japanese.

It was only fitting that the seventh machine—a desktop—would be Nanacore (nana なな) then.

Quite notably, everything is working fine with the latest Debian wheezy packages (although I compiled my own newer kernel later anyway) except for the onboard sound controller.

00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)

The Intel HDA codec for these controllers is apparently not quite ready yet; as a result, the mixer sliders are slightly broken in that there is no master channel, the speaker channel has no actual volume slider, changing the PCM channel’s volume causes some slight noise, and I suspect some features are missing as well. Despite this, the driver works for basic usage given some precautions with the KDE sound system to choose the correct (PCM) channel for audio instead of the sliderless (speaker) channel. I would not mind to spend some additional time researching the situation later, but I really need to get back to work on non-audio stuff (a.k.a. AtS) right now, so that will have to wait.

Incidentally, the Debian KDE desktop task includes PulseAudio now (I believe this wasn’t the case with Squeeze). Rather unsurprisingly, PA continues to be a considerable annoyance for my usage (e.g. lockup during KDE login, 1% extra CPU usage during playback from any application), so I ditched it after a day or two for plain ALSA. I don’t really have a need for the extra layer of indirection since PA uses ALSA anyway and my sound needs are very basic — basically, just playing sound from media players, games, and application notifications.

For graphics I’m using a decidedly inexpensive NVIDIA graphics card for the sake of having an NVIDIA graphics card and parting ways with Mesa for a good while. And while I had intended from the get-go to install the proprietary drivers, a forced and thankfully short Nouveau intermission confirmed that Nouveau indeed eats kittens. And that’s really all there is to say on the matter.

Both the machine and Debian wheezy can do UEFI, but I quickly stumbled upon a couple of issues:

• Using the EFI version of GRUB means the only way to get a working text console on Linux is to use a framebuffer console driver such as efifb. This is not supported by NVIDIA and the driver complains quite loudly about it.
• The machine appears to enumerate my (USB) 3G modem’s built-in storage as the first and second hard disks when it is connected, breaking GRUB’s expectations about the location of the disk from which it will boot, which becomes the third (SATA) hard disk in such a situation. The PC BIOS version of GRUB only gets to see the real hard disk drive.

Since this is my first time dealing with an UEFI-based system yet, I don’t really know whether the second point is a bug in GRUB, or the platform itself. Regardless, the first point pretty much convinced me to not spend any further time on that and just go back to the BIOS flavor of GRUB. This doesn’t seem to have done anything for my broken Windows 7 installation, which I probably don’t really need.

I have been working on transferring my configuration and files from Reicore since this Monday, approximately, and I think I’m nearly ready to get back to business now.

(I actually wanted to post this on the 7th but I got sidetracked by the system migration and testing.)