Debian "wheezy": inetd.conf is missing

Like the North Star, the /etc/inetd.conf file has always been there for me on every Linux system I've ever run . . . until now. "Where is inetd.conf?" I asked myself the other day.

The quick answer is, "nowhere." It appears that in Debian "wheezy" inetd is not installed by default. You have to do:

# apt-get update
# apt-get install inetutils-inetd

That will get you where you need to be. After you configured at least one service in /etc/inetd.conf, you can do:

# dpkg-reconfigure inetutils-inetd
Stopping internet superserver: inetd.
Starting internet superserver: inetd.

And then:

# ps ax | grep inetd
 5005 ?        S      0:00 /usr/sbin/inetutils-inetd
 5008 pts/0    S+     0:00 grep inetd

Note that the inetd daemon has been renamed.

Iceweasel downloads window: "Open" doesn't do anything

An annoying problem has developed with Iceweasel on my main desktop work machine. When I download, e.g., a PDF file using Iceweasel and then try to open it in the Downloads window, nothing happens. Similarly, when I right-click on the file and choose "Open containing folder", nothing happens.

Looking around, I found the following somewhat cryptic advice from hubi over on http://aptosid.com :

In about:config you should see helpers.global_mime_type_file which should be set to /etc/mime.types, and latter file should be available. And there should be a /etc/mime.types.

My installation passes this test, so the problem has to be somewhere else. I ran out of things to try, so I posted the following plea for help to the Debian User Forums :

Ran into a strange problem. I follow the "testing" distribution, so up until yesterday I was using Iceweasel 8.0 and now I have 9.0.1 installed.

At some point, the "Open" and "Open containing folder" options in the "Downloads" window stopped working. They used to work, I think, but now they do nothing. They are not "greyed out", yet choosing them elicits no reaction.

Based on a web search, I looked at "about:config", and confirmed that "helpers.global_mime_type_file" is set to "/etc/mime.types" - that file seems to be OK. I'm not sure about the /etc/mailcap file - the entry for "image/pdf" refers to the program "display", which is part of ImageMagick and does not (AFAIK) know how to display PDF files. Obviously, I would rather have it run "evince".

Also, I noticed that the file "/etc/mailcap" does not seem to belong to any package. Instead, there's a file "/usr/lib/mime/mailcap" which belongs to the "mime-support" package. On my system, that file contains nothing but comment lines.

I tried running "update-mime" but this has no effect on the problem.

I have both "nautilus" and "pcmanfm" installed. If Iceweasel would run either of these when I click on "Open containing folder", that would be fine, but it does nothing.

I ran "sudo grep iceweasel *" in /var/log, but saw nothing that would indicate that Iceweasel writes anything (like, say, an error message) to the log when I click on "Open" or "Open containing folder".

All replies greatly appreciated.

So, hopefully someone will reply.

Update

secipolla replied:

You can look in ~/.xsession-errors if it gives any output (or open iceweasel from the terminal and look for the output when you click on those actions).

Debian "wheezy": How to report a bug

Bug reporting always gives me a sense of satisfaction, and today I had occasion to report a bug in Debian "wheezy". As has happened to me again and again while using Debian, I was pleasantly surprised by how easy it was. The only glitch was that I didn't have the python-vte installed, so reportbug fell back to text mode, which was fine.

Here's the drill:

# apt-get install reportbug python-vte
# reportbug

Then, follow the instructions carefully. What really bowled me over was that I didn't need to do any MTA (exim4) setup!

Debian "wheezy" ncurses package for "make menuconfig" (kernel compilation)

Once again, I tried to run make menuconfig to configure a kernel, and it complained that it didn't have the ncurses development library installed. But what was the Debian package name for that again?
So I tried the obvious and. . . it worked!

# apt-get install ncurses-dev
Reading package lists... Done
Building dependency tree      
Reading state information... Done
Note, selecting 'libncurses5-dev' instead of 'ncurses-dev'
The following extra packages will be installed:
  libtinfo-dev
Suggested packages:
  ncurses-doc
The following NEW packages will be installed:
  libncurses5-dev libtinfo-dev
0 upgraded, 2 newly installed, 0 to remove and 38 not upgraded.
Need to get 508 kB of archives.
...

Notice that apt-get corrects the bogus package name I gave it (ncurses-dev) to the real package name, libncurses5-dev. Neat.

udev[566]: renamed network interface eth0 to eth3

---

This came up when I moved a disk containing an existing Debian 6.0 installation to a different machine. The original machine had two NICs and at one point I had tried a third. At boot-time, udev looked for the MAC addresses of these three NICs, but didn't find them. Instead, it found a *fourth* (the integral NIC in the new machine). Since it already had MAC addresses registered for eth0, eth1, and eth2, it went on to register the NIC to the next number in line (eth3).

Now, in my case, this is not really desirable. I'd rather have udev forget the old NICs and assign the new NIC to eth0.

Here's how to do it. Whenever udev detects a new NIC, it writes an entry to /etc/udev/rules.d/70-persistent-net.rules. So, edit that file, deleting the old, stale entries and leaving the latest one (as eth0).

(This works on Debian and openSUSE, and presumably on all other modern Linuxes.)

Force console resolution in Debian 6.0

This is a two-step process, and there is a pre-requisite: KMS (Kernel Mode Setting) has to be enabled. To enable it, refer to the Debian KMS Wiki.

Step 1

The first problem I faced was how to modify the kernel command line. I knew the parameter I wanted to add, but I didn't know how to add it. Theoretically, I knew this was done by modifying the GRUB2 configuration, but even after reading around in the GRUB2 documentation, this seemed daunting.

However, it was easy. All I needed to do was to edit the file "/etc/default/grub" and add the parameter to the following line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

So, in my case, after editing the line now reads:

GRUB_CMDLINE_LINUX_DEFAULT="video=1920x1200 quiet"

Then, run update-grub as root. Optionally, you can reboot now.

Step 2

If you rebooted after Step 1, you will notice that the kernel switches to the 1920x1200 resolution properly (assuming your hardware supports it), but doesn't change the console font. As a result, the font becomes ludicrously small.

Let's take care of that. The console-setup package is installed by default, I think, but check to make sure it's installed anyway, to be sure:

# apt-get install console-setup

Then, edit /etc/default/console-setup. Credit to the Changing Console Fonts In Debian Squeeze blog entry over at Tiger Computing for this. As they say, the file is well-documented. I changed FONTFACE to "Terminus" and FONTSIZE to "28x14".

Then reboot. If you already rebooted after step 1, then a invoke-rc.d console-setup restart, as root, will suffice.

Remote X via ssh: Can't open display

Remote X has been sacrificed in the name of better security from the get-go. Typically there are several hurdles to overcome in getting it to work. In short, getting remote X sessions to work is a pain. Here's what I came up with on Debian 6.0. All of this has to be done on the machine running the X server.

# Put this one in .xsession or similar startup script
$ xhost +

# It will say "nolisten tcp", but that isn't right
$ ps ax | grep X

# Get rid of "nolisten tcp"
$ sudo vim /etc/gdm/gdm.conf
[security]
DisallowTCP=false

# Throw up an xterm
$ ssh -X pavla /usr/bin/lxterminal

# In the xterm
$ xclock

Voila!

Can't deactivate volume group "vg-main" with 1 open logical volume(s)

Can't deactivate volume group "vg-main" with 1 open logical volume(s) ... failed!

After moving to LVM2 on my Debian boxen, I began seeing this disturbing error message (with the word "failed!" in red) at shutdown. Apparently, with the root filesystem in an LVM volume, the volume group cannot be deactivated.

Failed or not, the system seemed to work normally - I shut it down at least once a day and it always comes right back up when I turn the computer on. I noticed a bug has been reported concerning this message:

#466141 lvm2: error message during shutdown (Can't deactivate volume group...)

Feri's reply (message #25) to that bug report explains it:

If a volume group contains mounted (even ro) logical volumes, it can't
be deactivated. On the other hand, deactivating a volume group does
not entail writing to the disk, so powering off with an active volume
group isn't bad in itself, if all of its logical volumes are "clean"
(eg. mounted read-only). If root is on a logical volume, you will
always get a warning about its logical volume being in use during
shutdown.

The question is, would it not be better to change the warning to something that doesn't generate fear? How about this:

Deactivating volume groups: root filesystem in logical volume detected - mounted read-only. All other logical volumes unmounted.