08 February 2012

60. i18n_translation and no Package:Header error on Debian Testing 32 bit

I'm doing this via an apt-cache server (i.e. the 192.168.1.1 rather than ftp.au.debian.org) -- but the problem is unrelated to the apt-cache server.

Symptom:

Get:1 http://192.168.1.1 testing InRelease [179 kB]
Ign http://192.168.1.1 testing/contrib TranslationIndex
Get:2 http://192.168.1.1 testing/main TranslationIndex [2,154 B]
Ign http://192.168.1.1 testing/non-free TranslationIndex
Get:3 http://192.168.1.1 testing/main i386 Packages [7,146 kB]
Get:4 http://192.168.1.1 testing/contrib i386 Packages [48.9 kB]
Get:5 http://192.168.1.1 testing/non-free i386 Packages [87.5 kB]
Ign http://192.168.1.1 testing/contrib Translation-en_AU
Get:6 http://192.168.1.1 testing/contrib Translation-en [34.8 kB]
Get:7 http://192.168.1.1 testing/main Translation-en [3,722 kB]
Ign http://192.168.1.1 testing/non-free Translation-en_AU                                
Get:8 http://192.168.1.1 testing/non-free Translation-en [62.5 kB]
Fetched 11.3 MB in 2s (4,348 kB/s)                                                          
W: Failed to fetch copy:/var/lib/apt/lists/partial/192.168.1.1:3142_ftp.au.debian.org_debian_dists_testing_main_i18n_Translation-en  Encountered a section with no Package: header

E: Some index files failed to download. They have been ignored, or old ones used instead.

Reason:
ftp://ftp.au.debian.org/debian/dists/wheezy/main/i18n/
All the files in that directory are compressed (bz2) -- you need to enable apt-get to decompress .bz2 files.

Solution:
Install bzip2

sudo apt-get install bzip2

at this point gives

Reading package lists... Error!
E: Encountered a section with no Package: header
E: Problem with MergeList /var/lib/apt/lists/192.168.1.1:3142_ftp.au.debian.org_debian_dists_testing_contrib_i18n_Translation-en
E: The package lists or status file could not be parsed or opened.

So remove the offending files (2 lines):
sudo rm  /var/lib/apt/lists/192.168.1.1:3142_ftp.au.debian.org_debian_dists_testing_contrib_i18n_Translation-en
sudo rm /var/lib/apt/lists/192.168.1.1:3142_ftp.au.debian.org_debian_dists_testing_non-free_i18n_Translation-en

Now you can 

sudo apt-get install bzip2

followed by

sudo apt-get update
Hit http://192.168.1.1 testing InRelease
Get:1 http://192.168.1.1 testing/main i386 Packages/DiffIndex [2,038 B]
Get:2 http://192.168.1.1 testing/contrib i386 Packages/DiffIndex [2,023 B]
Get:3 http://192.168.1.1 testing/non-free i386 Packages/DiffIndex [2,023 B]
Ign http://192.168.1.1 testing/contrib TranslationIndex
Hit http://192.168.1.1 testing/main TranslationIndex
Ign http://192.168.1.1 testing/non-free TranslationIndex
Get:4 http://192.168.1.1 testing/contrib Translation-en [34.8 kB]
Get:5 http://192.168.1.1 testing/main Translation-en [3,722 kB]
Get:6 http://192.168.1.1 testing/non-free Translation-en [62.5 kB]
Ign http://192.168.1.1 testing/contrib Translation-en_AU        
Ign http://192.168.1.1 testing/non-free Translation-en_AU
Fetched 103 kB in 4s (25.3 kB/s)
Reading package lists... Done

Done indeed!

07 February 2012

59. Some problems with a headless box with four ethernet cards

I'll put this here more as general information rather than a solution to anything.

The situation:
I got my hands on a tiny WAN server with four ethernet cards (Intel Pro 100). Two of the ports light up when attaching CAT5 cables (eth3 and eth4), two of them remain dead (eth0 and eth1).

I thought I was clever:

/etc/network/interfaces

auto eth0
iface eth0 inet static
address 192.168.1.103
netmask 255.255.255.0
gateway 192.168.1.1
auto eth1
iface eth1 inet static
address 192.168.1.104
netmask 255.255.255.0
gateway 192.168.1.1
auto eth2
iface eth2 inet static
address 192.168.1.105
netmask 255.255.255.0
gateway 192.168.1.1
auto eth3
iface eth3 inet static
address 192.168.1.106
netmask 255.255.255.0
gateway 192.168.1.1

/etc/hosts
127.0.0.1 localhost
192.168.1.103 garfish
192.168.1.104 salmon
192.168.1.105 wallaby
192.168.1.106 kookaburra
192.168.1.1 beryllium
192.168.1.101 boron
192.168.1.102 tantalum
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Well, here's what happened:
I installed Debian Stable on the HDD using virtualbox -- it's a tried an tested method by which instead of creating a virtual HD you attach an external HD via USB and pass it through to a new virtualbox instance which only has a CD or DVD image of a Debian installation medium mounted. I might explain this in more detail in a separate post.

Anyway, installation was fine. I installed the basic tools, ssh-server, file-server etc., but no desktop environment.

I knew that I had to manually set the IP address since the server would be attached to a switch, not a router, so I attached the HDD as an external USB HDD to a tower with a display attached to it, hit F9 during boot to boot from the external harddrive, and things looked ok. Well, the network card hadn't been brought up  -- I guess this is normally done by network-manager even if you don't configure your /etc/network/interfaces

sudo ifconfig eth0 192.168.1.103 netmask 255.255.255.0 up

was enough to get me connected, after which I edited the /etc/apt/sources.list, upgraded to testing, and installed a few network tools and a collecting of non-free drivers for good luck.

I edited the /etc/hosts and /etc/network/interfaces as shown above

What I saw (using tshark -i eth1 on another box on the same local network):
23.630357 192.168.1.103 -> 130.194.1.99 DNS 69 Standard query AAAA
garfish
 23.631220 130.194.1.99 -> 192.168.1.103 DNS 144 Standard query
response, No such name

Anyway, odd, but let's leave it at that.

I put the HDD in the server, then tried to log in via ssh. Nothing. And no response to pinging. Can't reach the apache server running.

Hmm...pulled out the hdd put a crontab script to run once every minute which would run lspci, ip addr and ping back to one of my boxes. Put the hdd back in, started and listened with tshark. Well, the server was pinging away, but I couldn't ping back, nor ssh in, nor connect to port 80.

Looking at the ip addr output:
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.103/24 brd 192.168.1.255 scope global eth0
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/etherxx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.104/24 brd 192.168.1.255 scope global eth1
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.105/24 brd 192.168.1.255 scope global eth2
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.106/24 brd 192.168.1.255 scope global eth3
    inet6 fe80::20e:b6ff:fe2a:a830/64 scope link
       valid_lft forever preferred_lft forever

Not too shabby looking - eth0 and eth1 are down, but at least the server isn't turning green and projectile vomiting.

But /var/mail/me:
Date: Mon, 06 Feb 2012 17:28:04 +1100
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>From 192.168.1.103 icmp_seq=1 Destination Host Unreachable
Odd, since I could SEE the pings using wireshark/tshark - but from 192.168.1.106.

Anyway, to make a very long story short -- the solution was to remove eth0 and eth1 from /etc/network/interfaces -- they are dead, and initialising them were causing odd behaviour.


There isn't much of a moral to this story, and the usefulness to other people is perhaps limited, but just in case you do recognise the situation, try limiting yourself to good ethernet ports, then take it from there...




58. Higher resolution on a Dell E177FPb monitor using modelines in xorg.conf on Debian Testing

Update 24 May 2013: this still works fine on the optiplex (with intel onboard graphics) but when trying it on a different machine with an external nvidia card I couldn't get it to work. There only "xrandr --output VGA-0 --scale 1.1x1.1" worked.

Original post:
I've hooked up my fancy new-ish optiplex 990 to an old Dell E177FPb monitor which I bought back in 2007. For various reasons I've also removed the nvidia quattro graphics card that the optiplex 990 came with -- the main reasons being 1) I hate displayport and _need_ vga and 2) the bios forces you to press 'any key' on each boot if you leave the card in, even though you've configured the OS to use the integrated onboard graphics.

At any rate, hooking my old screen to my dell lead to a less than overwhelming experience -- and querying the 'Displays' setting in gnome showed only two resolution options: 1024x768 and 800x600. Well, I knew for a fact that the maximum resolution should be 1280x1024.

This was a bit of a surprise given that the same xorg.conf had been used together with a fancy widescreen 1920x1080 display -- yet it would not handle a 1280x1024 display? I guess this might say more about my lack of understanding how display drivers work, but whatever.

Well, in the end it turned out to be easy to enable the missing resolution mode.

First, a minimal amount of googling told me that the max resolution was 1280x1024 at 75 Hz.
"Preset Resolution: 1280 x 1024 @ 75 Hz"

Next, using gtf I generated a Modeline line.

gtf 1280 1024 75
Modeline     "1280x1024_75.00" 138.54 1280 1368 1504 1728 1024 1025 1028 1069 -HSync +Vsync

Finally, I then edited the xorg.conf (again, see this post for the entire xorg.conf), changing


Section "Monitor"
Identifier   "Monitor0"
VendorName   "Monitor Vendor"
ModelName    "Monitor Model"
EndSection

to


Section "Monitor"
Identifier   "Monitor0"
VendorName   "Monitor Vendor"
ModelName    "Monitor Model"
Modeline     "1280x1024_75.00" 138.54 1280 1368 1504 1728 1024 1025 1028 1069 -HSync +Vsync
EndSection

Doing startx to start up gnome, followed by selecting Displays, then selecting Resolution: 1280x1024 (5:4) yielded a beautifully satisfying  user experience.

I'm not one to fiddle with xorg.conf, but this time it turned out that the fix was easy once I had figured out what to do.