Debian an Dell Latitude D830

Random January 12th, 2010

The Dell Lattitude D830 is a quite capable business notebook. While the notebook itself is not considered high-end it still allows for good configurations. A definite downside is the battery which lasted only for 1 year and had to be replaced with a new battery pack (not part of warrenty of course).

All the following descriptions refer to the current Debian Squeeze (testing) using Linux Kernel 2.6.32 (trunk-5) from unstable repository.

As Dell allows different setups of the same hardware model here are the specs:

Hardware Status
CPU: Intel Core 2 Duo T7500 (2.2GHz)
2MB/4MB L2 Cache, 800MHz FSB
Works
All cores recognized. Hardware Virtualisation (VT extensions) working (must be enabled in the BIOS).
Memory: 2GB (2×1GB) 667MHz DDR2 SDRAM Works
Storage: Intel SATA IDE Controller Works
Using ata_piix module. AHCI untested.
Graphics: Nvidia Quadro NVS 135M Works
Using binary nvidia driver (nvidia-kernel-source from testing)
LAN: Integrated Broadcom Gigabit Ethernet Works
Uses in kernel tg3 driver.
WLAN: Broadcom BCM4328 802.11a/b/g/n Wireless Works
Uses broadcom-sta module, also working with ndiswrapper
Audio: Intel HD Audio Controller Works
Works using ALSA
Keyboard: Hotkeys Partially Working
Most Fn keys work, except those not producing key codes (Volume, Display Highlight, Sleep is working)

For a different hardware configuration see this post.

Hardware List (as shown by lspci):

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 0c)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 02)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 135M (rev a1)
03:01.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 21)
03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02)
09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5755M Gigabit Ethernet PCI Express (rev 02)
0c:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n (rev 03)

As most stuff works out of the box I will refer here only to the setup of the graphics controller and the wireless device.

Setup Nvidia Quadro NVS135M

First install the required packages (as root):

sh# aptitude install nvidia-kernel-common nvidia-kernel-source nvidia-glx

Then create the required kernel module (this assumes you have booted into the kernel already):

sh# m-a a-i nvidia
sh# modprobe nvidia

Be sure to configure your X server accordingly (here is a shortened xorg.conf):

Section "ServerLayout"
    Identifier     "Default Layout"
    Screen      0  "Screen0" 0 0
EndSection

Section "ServerFlags"
    Option         "Xinerama" "0"
EndSection

Section "Monitor"
    Identifier     "Generic Monitor"
    HorizSync       28.0 - 84.0
    VertRefresh     43.0 - 60.0
    Option         "DPMS"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Seiko"
    HorizSync       30.0 - 75.0
    VertRefresh     60.0
EndSection

Section "Device"
    Identifier     "Videocard0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "Quadro NVS 135M"
    Option         "AllowGLXWithComposite" "true"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Videocard0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "TwinView" "0"
    Option         "metamodes" "1680x1050 +0+0; 1280x800 +0+0; 1024x768 +0+0; 800x600 +0+0; 640x480 +0+0"
    Option         "AddARGBGLXVisuals" "True"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Setup Broadcom BCM4328 driver

First install the required packages (as root):

sh# aptitude install broadcom-sta-common broadcom-sta-source

Then create the required kernel module (this assumes you have booted into the kernel already):

sh# m-a a-i broadcom-sta
sh# modprobe wl

This will install and enable the broadcom-sta driver, which is known as the “wl.ko” kernel module. Be sure the unload all drivers using the device (e.g. ndiswrapper) beofre loading the wl.ko module.
Using the network-manager package a good mobile network configuration utility is available for CLI and desktop (system tray).

Enjoy!

Browsers benchmarked on Linux

Random May 13th, 2009

The system itself is a Dell D830 laptop with a nvidia NV135 chip and an Intel Core2 Duo T7500 CPU with 2GB RAM. For actual benchmarking the new futuremark paecekeeper browser benchmark has been put to use.

The compared browsers are:

  • Midori 0.1.4 (lightweight GTK browser using webkit)
  • Iceweasel 3.0.9 (the debian rebranded Firefox 3.0.9)
  • FIrefox 3.5b4 (latest beta of firefox 3.5)

Sunspider results are:

RESULTS (means and 95% confidence intervals) for SunSpider 0.9
--------------------------------------------
Firefox 3.5b4:               2405.6ms +/- 4.0%
Midori 0.1.4:                3917.2ms +/- 2.6%
Iceweasel 3.0.9:             4465.6ms +/- 1.6%

Here are the results for the Futuremark Peacekeeper browser benchmark:
browser-bench-midori-014browser-bench-firefox-35b4browser-bench-iceweasel-309

The results are quite unexpected, as working with the browser show a different perceived quality. Although midori scores highest in the peacekeeper benchmark, the rendering on some sites is sometimes flaky and seem to take longer as with both firefox version. On the other hand the sunspider benchmark shows midori far behind firefox, which also is strange as SunSpider is from the webkit project and should therefor be quite fast on a browser using webkit.

Setting up your own simple debian repository

Random April 27th, 2009

In the process of getting a debian repostiry ready to allow easy installtion with debian’s apt, a small series of posts are going to be created here. So here is the initial post describing a very simple debian repository layout.

All that’s required to setup your own debian repository is the dpkg-dev package and a web or ftp server for serving the files. For a local deployement (e.g. within a company) also a file-system based approch is possible through a NFS mounted directory.

Make sure the dpkg-dev package is installed:

sh# aptitude install dpkg-dev

Copy all files into a directory binary on the server. So the layout will look something like this:

(webserver-root)
+-- debian
    +-- binary
    |   +-- myweb-2.0-1_i386.deb
    |   +-- myweb-utils-2.0-1_i386.deb
    +-- source

Here the packages in the binary directory can new be used to create the repository index and serve this then as a debian repository. To scan the packages and create the index use:

$ cd webserver-root
$ dpkg-scanpackages binary /dev/null | gzip -9c > binary/Packages.gz
$ dpkg-scansources source /dev/null | gzip -9c > source/Sources.gz

Now the repository can be used by adding the following to /etc/apt/sources.list:

deb http://my.server.com/debian/binary ./
deb-src http://my.server.com/debian/source ./

See http://www.debian.org/doc/manuals/repository-howto/repository-howto for more details.

Howto resize a qcow2 disk image

Random November 8th, 2008

Resizing of the file-based qcow2 format for handling disk images is possible by performing the resize on a different format and use the conversion capabilities of qemu-img.

Having created a 1GB disk image in qcow2 format like this:

quikit:/var/kvm# qemu-img create -f qcow2 mydisk.qcow2 1G
Formatting 'mydisk.qcow2', fmt=qcow2, size=1048576 kB
quikit:/var/kvm# qemu-img info mydisk.qcow2
image: mydisk.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 16K
cluster_size: 4096

The resize existing images the following steps are required:

  1. Convert the qcow2 disk image to raw format

    qemu-img convert -f qcow2 mydisk.qcow2 -O raw mydisk.raw
  2. Resize the raw image using dd (the file contents is not touched)

    dd if=/dev/zero of=mydisk.raw bs=1M count=0 seek=4096
  3. Convert back to the qcow2 format (only used blocks will take up diskspace)

    qemu-img convert -f raw mydisk.raw -O qcow2 newmydisk.qcow2

After conversion the qcow2 info now shows:

quikit:/var/kvm# qemu-img info newmydisk.qcow2
image: newmydisk.qcow2
file format: qcow2
virtual size: 4.0G (4294967296 bytes)
disk size: 28K
cluster_size: 4096

So resizing a partition can be as simple as that. Now try to boot the resized image, if it is not working you may have to reinstall the bootloader.

If you are using a NTFS partition you have to take special care. See the qemu forum for details.

Building proprietary ATI fglrx driver on Debian Lenny x86_64

Random August 25th, 2008

To build the ATI proprietary driver (version 8.8, being reported as 8.522) on Debian Lenny 2.6.26-1-amd64 (probably the same for testing/unstable) on x86_64 I ran into 2 subtle problems which requried a little tricking to get the driver compiled and loaded. The following issues apply only to the x86_64 version of linux.

The first issue is a library problem with a very misleading description .

shell# sh /home/random/ati-driver-installer-8-8-x86.x86_64.run --buildpkg Debian/testing
... build fails with library libXext.so.6 missing ...

The solution is to install the ia32-libs, which contain the correct libs for ia32. Building with the above command work fine afterwards. Then it was possible to install the packages

shell# dpkg -i fglrx-amdcccle_8.522-1_amd64.deb fglrx-driver_8.522-1_amd64.deb fglrx-kernel-src_8.522-1_amd64.deb

The second issue happened during loading of the kernel module after building, installing and loading it with

shell# m-a build fglrx
shell# dpkg -i /usr/src/fglrx-kernel-2.6.26-1-amd64_8.522-1+2.6.26-3_amd64.deb
shell# modprobe fglrx


fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
fglrx: Unknown symbol flush_tlb_page

The patch is basically to remove the defined(__SMP__) from a preprocessor rule (this is not my patch, please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485605 for details).

-#if defined(__x86_64__) && defined(__SMP__) && (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,25))
+#if defined(__x86_64__) && (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,25))

After applying the patch, rebuilding the packages, recreating the module, installing the resulting kernel-module package and loading the kernel module everything worked like a charm. Of course you need to correctly configure the driver for your X server.

System backup vs. system images

Random October 13th, 2006

Creating a system image is IMHO different from creating a level 0 backup.

A backup is destined for the one host it was taken from, no other. MBR, partitioning, filesystems will all stay the same. Whereas a system image is used to multiply an installation to different hosts, with probably different partitioning, eventually different mount points. Differences of configuration is not part of this post, so yes, there are definitly different setting for network, hostname, …, but that has to be handled after restoring the image.

Target systems are Intel-based, so a Rescue-CD like RIP (Rescue Is Possible) can be used. The whole system is to be backed up, so unmounting of the root partition is going to be hard, meaning a boot from external media (e.g. CD) is required. We sure want to have a consistant state, so changes to the running filesystem must not be possible during backup. The backup destination is either an external storage like a DVD burner, tape or USB harddisk, but can also be a network storage like nfs directory, netcat tcp backup, …

Let’s take a closer look at the steps involved for either of the possibilities:

Blockbased

Operates on the block level. Similar to saving bit by bit from the blockdevice in question. This should never ever be done on a mounted filesystem.

Procedure:

  1. Boot from CD
  2. Prepare backup destination
  3. Backup MBR(s)
  4. Backup partition table(s)
  5. Backup whole disk(s) or required block devices
  6. Reboot

Advantages:

  • independence of the filesystem used (so indirectly all filesystem features are supported)
  • can be used for non-linux filesystems (e.g. backup NTFS partitions)

Disadvantages:

  • inflexible
  • unable to restore single files or directories
  • no listing / index possible

Tools:

Filesystem based

Operates on the filesystem level. The supported filesystems are known, usually with all the features they offer (e.g. extended attributes, ACLs). This should never ever be done on a mounted filesystem.

Procedure:

  1. Boot from CD
  2. Prepare backup destination
  3. Backup MBR(s)
  4. Backup partition table(s)
  5. Backup required filesystems
  6. Reboot

Advantages:

  • independence of the blockdevice
  • all filesystem features supported
  • only a limited number of filesystems supported (mostly linux)

Disadvantages:

  • some flexibility
  • unable to restore single files or directories
  • no listing / index possible
  • partition sizes must be at least as large as the original one

Tools:

Filebased

to be written

Blockbased backups are definitly more suitable for level 0 backups, as we definitly restore to the same host, and everything should be the same, bit by bit.
That leaves filebased archives for system images, as they are extremly flexible.

References

http://www.halfgaar.net/backing-up-unix

Next »