Translation(s): English - Italiano - Français

(!) Discussion


This page is meant to collect frequently asked questions from the debian-user mailing list. The contents are licenced under the terms of GPLv2 or, in the event a DFSG compatible licence is applied to wiki.debian.org at large, then under that licence. Posting material to this page is an acceptance of this.

Contents

  1. Why bother
    1. Why should I post to this list? I want to ask the developer/post to debian-devel/file a bug.
  2. Using Debian
    1. Should I be running Testing/Unstable(Sid) instead of Stable/Testing?
    2. How dangerous is it to run a mixed system?
    3. How different is Ubuntu from Debian?
    4. My harddisks/usb sticks/external drives don't always have the same device name. How can I prevent this from happening?
    5. My ethernet card is named ethX instead of eth0, what's going on?
  3. Software Packages
    1. Which is the best package manager?
    2. Where is the foo package?
    3. Program foo is looking for (or lacking) file bar. Where is it?
    4. What package contains file foo?
    5. How can I prevent a specific package from being installed on upgrades?
    6. Should I be using upgrade/safe-upgrade or dist-upgrade/full-upgrade to keep my system updated?
    7. Does Debian have Firefox/What is Iceweasel?
    8. Firefox/Iceweasel has strange problems (segfaults, crashes, ...)
    9. Ubuntu/some other distro already has a newer kernel/Gnome/KDE/Firefox/other. When will Debian have it?
    10. I found this .deb package for a software I need, can I just install it on Debian?
    11. I am running a mixed system. How can I find out what packages are from which distribution?
    12. I tried to remove a package and now many other packages are scheduled for (auto)remove
  4. Multiarch
    1. How can I enable Multiarch
    2. Do I still need ia32-libs/ia32-libs-gtk ?
    3. If I'm trying to upgrade ia32-libs/ia32-libs-gtk I get a lot of i386 libraries installed
    4. My non-Debian software has an amd64 package that depends on ia32-libs/ia32-libs-gtk, how can I get rid of ia32-libs/ia32-libs-gtk ?
    5. But APT wants to install a lot of i386 libraries now
    6. Will this break my system?
    7. But I don't want all those libraries / I want to keep the all-in-one ia32-libs/ia32-libs-gtk packages
    8. Are cross-grades possible?
    9. Google-earth and Multiarch
  5. systemd
    1. How can I prevent systemd from being installed on upgrades?
    2. How can I temporarily boot with another init on Jessie?
    3. How can I prevent systemd to run as PID 1 (init) on Jessie?
    4. How can I remove the systemd package from my Jessie system?
    5. How can I remove any traces of systemd from my Jessie system?
  6. Posting on debian-user
    1. How should I post/reply to debian-user?
    2. I asked my question according to the directions written at the "How should I post" question, but I still don't get an answer
    3. Should I be subscribed to post to debian-user?
    4. Help! My e-mail address is available in your list archives for the spam-bots to harvest/Why aren't e-mail addresses scrambled?
    5. This list is littered with spam, do something about it!
    6. How can I get my postings/e-mail removed from the archives?
    7. I subscribed to the list, but my mailbox is flooded with mail
    8. What is top-posting (and why shouldn't I do it)?
    9. Why doesn't this list facilitate easy replies to the list (a.k.a. reply-to-munging)?
    10. Can I ask a question about foo?
    11. What is considered offtopic for debian-user?
    12. Is it ok if I attach/include bigfile in my message or should I use a pastebin instead?
    13. My posts are considered spam and rejected (or never show up)
    14. I'm posting via gmail's servers, but I never receive my own posts (other list mail is fine)

Why bother

Why should I post to this list? I want to ask the developer/post to debian-devel/file a bug.

Of course, you are free to do this. Almost all debian lists (including debian-devel) are open for anyone to post and Debian encourages users to file bugs in the Debian Bug Tracking System (BTS). BUT, please consider the following points first:

Remember, Debian is created by volunteers in their spare time. Distracting them with other problems will leave less time to do actual work, like solving known bugs, package new versions of software we are all waiting for, packaging software not yet present in Debian and improving or creating Debian specific software. Even if you know you have a really difficult problem, debian-user is read by some very knowledgeable people (including some Debian developers), and they might have a solution for your problem.

Sometimes even the most experienced people can do stupid things. Having other people look over your problem may help.

That means you should search the archives of debian-user (or other relevant lists) and especially the BTS. Chances are somebody else has experienced the same (or similar) problem and workarounds may be known. Even if you searched thoroughly, you should post to debian-user first (stating what you already tried/researched).

If you considered all above points and still want to address debian-devel, then please make sure:

In case you have doubts just post to debian-user, sometimes answers come within minutes.

Using Debian

Should I be running Testing/Unstable(Sid) instead of Stable/Testing?

This is something that you as a user and administrator of your system have to decide for yourself. If you just need a few newer packages try http://backports.debian.org before considering an upgrade. If you have Debian on a desktop machine, testing might be an option, but it's not really recommended for production machines. If you want all the newest software Debian can provide and don't mind/can handle breakage then you could try unstable. If you are in doubt always use stable. Each Debian distribution has its pros and cons. Here are some:

Stable

stable is the currently supported Debian GNU/Linux distribution.

Testing

testing is slowly evolving to become the next stable release, but until then it is still testing ground. As the release approaches ("testing freeze") it becomes more and more like a newer stable release (with all pros and cons):

Unstable (a.k.a. Sid, a.k.a Still In Development, the character in Toy Story who broke toys)

unstable contains packages uploaded by the developers for the next release, but will never be released. Instead, packages will usually migrate to testing if no release-critical bugs are found in 10 days (and there are no dependency problems).

Experimental (a.k.a. rc-buggy)

This is not a regular distribution (you cannot run on experimental), but it is mentioned here for completeness.

Oldstable

When a new version of Debian GNU/Linux is released the current stable becomes oldstable.

How dangerous is it to run a mixed system?

That depends on how many and what packages you are using, but it can be more dangerous than running pure unstable. Installing packages from different releases can cause complex problems which are less likely to occur with packages from a single release. One example is that existing packages may become uninstalled due to internal restructuring of central components within the testing or unstable branches.

Try backports first. If you can't find what you need there you can also backport a package yourself.

How different is Ubuntu from Debian?

There are lots of differences: some big, some small but all may be significant.

Rationale/design goals

Packages in Ubuntu main are very highly polished, very well maintained and Canonical/Ubuntu go the extra mile to make the experience easy for the user. That comes at one or more of several costs:

Choice

Lack of choice - you get one mail client rather than a choice of several "out of the box", for example. Choices are made for you - it is an issue of supportability. Debian offers you more flexibility at the price of complexity or being willing to support your choices.

Architectures

Lack of architectures: if you're not on Intel/AMD64 or, possibly, ARM/Sparc/PPC (depending on release) - you can't run Ubuntu. Debian running on 11 or so architectures does mean that a) the process is sometimes slow b) the code gets debugged c) is made portable/fixes are contributed upstream.

Developer/user ratio

Canonical has relatively few paid developers, a highly motivated volunteeer developer community, a much larger community advocacy and marketing budget and a vast number of new users. This does mean that their developers are massively outnumbered by their users and priorities have to be set. Packages in universe/multiverse may therefore receive less attention than those in main in Ubuntu.

At least in theory, every package in Debian is equal and has a known named maintainer who takes an interest :) It does mean that Debian does much of the heavy lifting of packaging and initial support for out of the way packages - it also means that, if I want support for R and CRAN, for example, I'd go straight to Debian because the maintainer has a personal and professional interest for seeing it work well as an integrated system.

Release cycles

"We demand rigidly defined areas of doubt and uncertainty" - Canonical has those because it releases once every six months. This consistency comes at a price: users expect new whizzy features with each release and the development cycle is very short indeed. Long term support releases happen every other year and are supported for three years on the desktop/five years on the server. That's hard. It's very hard to support new hardware with long term releases. "Normal" releases may mix packages from Debian stable with testing, unstable or even experimental (whizzy features) but get only a short testing time.

Debian "releases when ready" but then supports that release until about a year after the next release. 22 months to release Etch, 22 months to release Lenny + 12 months = 56 months. Slow moving progress through testing to release, regular point updates with security fixes.

Freeness vs. pragmatism

Ubuntu may sometimes take a pragmatic attitude for "software that works" for users. They also have the ability, which Debian does not, to enter into commercial agreements for third party apps e.g. Oracle/VMWare. [DFSG - not "licence just for Debian"]. Canonical benefits from Debian idealism but it can't flow the other way :(

Upgrades between releases

You'll hear lots of views on this. Ubuntu is generally considered harder to upgrade cleanly between releases and it may actually be quicker to reinstall. You certainly can't skip a release (it's not even supported) so you'd need to do 8.04, 8.10, 9.04, 9.10 (for example). This is partly a consequence of short release cycles above. Debian doesn't support skipping a release either, but you have about 1 year to prepare for the upgrade and it's mostly smooth, especially if you take the time to read the Release Notes.

Summary

All of this is very well explained by The Official Ubuntu Book and Mark Shuttleworth's latest interview for "Linux Format" magazine. It's also worth reading newsgroups/fora and planet.debian.org / planet.ubuntu.com to get a better appreciation of the similarities and differences in approach. Debian and Ubuntu each have strengths: it's a (sometimes uneasy) symbiosis - both distributions share many of the same developers, for example, but not necessarily end goals - but Debian would gain as much as Ubuntu if they'd just fix their bloody bug #1 :)

My harddisks/usb sticks/external drives don't always have the same device name. How can I prevent this from happening?

You can't prevent it; this happens due to the way the kernel does device detection, but there are several methods to not let it be a problem. It seems the easiest method is to use labels instead of device names. Basically in fstab you just replace the /dev/sda1 (or hda2 or whatever) with a LABEL=mylabel. If you also have problems booting (because your / partition is assigned a different device name) you will also have to edit /boot/grub/menu.lst. Don't edit the real stanza because your changes will be overwritten on the next kernel upgrade. Instead find the line:

# kopt=root=/dev/hda1

and replace it with

# kopt=root=LABEL=my_root_label

After you are done you must run update-grub as root.

Another alternative to using labels is to use UUIDs. You can find the UUID of a device with blkid(8).

As of squeeze all new instalations will have /etc/fstab written with UUIDs and grub2 also deals with this correctly.

My ethernet card is named ethX instead of eth0, what's going on?

Udev is assigning the same device name to a card (based on its MAC), even if you removed every other card in the system. If you don't want this, you can:

Software Packages

Debian is known for its robust, extensive and easy to use package system. The operations that can be performed with regard to package management are sophisticated, easily scripted, and make running Debian a relatively simple and mistake-proof experience. The following questions all deal with some aspect of the package management.

Which is the best package manager?

While "the best" package manager is a matter of personal opinion, the Debian project and many Debian developers and users recommend aptitude. See here for more details.

Where is the foo package?

A variety of tools exists to answer this very frequent question: apt-cache search foo bar will return all the packages with both foo and bar in the name or description; aptitude search foo will return all packages with foo in the package name. These are just two of the many methods. Read man apt-cache or man aptitude as appropriate. Finally, http://packages.debian.org also features a handy search engine and don't forget your friend http://www.google.com.

Program foo is looking for (or lacking) file bar. Where is it?

This is simple: apt-file update && apt-file search bar. grep as appropriate. man apt-file.

What package contains file foo?

See previous question. If the file is already on your system dpkg should know about it (usually faster as well).

$ dpkg -S /path/to/foo

Please note that files under /home/, /usr/local/ and a few other places are not under the control of the package management. See the Filesystem Hierarchy Standard (also available as man page hier(7) ) for an explanation of how the files are organized on your system.

How can I prevent a specific package from being installed on upgrades?

Put something like

Package: unwanted-package
Pin: version *
Pin-Priority: -1
Explanation: prevent unwanted-package from being installed

in a file under /etc/apt/preferences.d/

Note that Package (and version obviously) accept patterns. See apt_preferences(5) for more information.

Should I be using upgrade/safe-upgrade or dist-upgrade/full-upgrade to keep my system updated?

It may help to understand what each command does:

Of course, all these actions will actually ask for confirmation, so you might want to review the proposed actions before proceeding ;).

In practice the above means that running apt-get upgrade or aptitude safe-upgrade might be enough to keep your system updated, depending on whether you run stable, testing or unstable (or a mixed system). Because of this it is generally recommended to not use apt-get dist-ugprade or aptitude full-upgrade unless it's really needed (packages have not been upgraded because installing or removing packages is needed).

Note that aptitude in visual mode does not have an equivalent for aptitude safe-upgrade and pressing Shift-u will always prepare the equivalent of aptitude full-upgrade. This is because in the preview screen you still have the chance to review and adjust individual actions as needed.

Does Debian have Firefox/What is Iceweasel?

You really should see Where is the foo package? above, but Debian ships with Iceweasel, a rebranded Firefox.

Firefox/Iceweasel has strange problems (segfaults, crashes, ...)

First try running with all extensions disabled by running

$ iceweasel -safe-mode

and see if that fixes your problem. Something else you can try is to (re)move your .mozilla directory or create a new user account.

Ubuntu/some other distro already has a newer kernel/Gnome/KDE/Firefox/other. When will Debian have it?

Short answer: most probably with the next release. See above for a quick explanation of how Debian releases work.

Long answer: Debian Developers are doing their best to package the software released upstream as soon as they consider it stable enough to be included in Debian so your package might already be available in testing, unstable or experimental. Unless testing is in the frozen stage (similar to a „Release Candidate”) new software is migrating from unstable to testing as soon as possible (which will then become stable on the next release), but it will never be included in the current stable release, because by definition the release must not change (apart from security fixes and some serious bugs).

If you still want to stick with stable (instead of testing or unstable) your best bet is to look at http://backports.debian.org for the packages you need.

You might think Debian is doing it wrong and should adopt the release policy of some other distro, but this system has proven its value over many years and it gives users a lot of choice. Various alternatives have been proposed over the years, but all of them have some disadvantages over the current scheme. Please do search the archives (also for the debian-devel and debian-project lists) before starting a new discussion over this issue.

I found this .deb package for a software I need, can I just install it on Debian?

That depends. If the package was created specifically for Debian (which version?) it might work, but you can't expect any support from Debian if it doesn't. If the package was created for Ubuntu or some other derivated distro chances are a lot smaller. You could try recompiling it (if the sources are also available) on Debian.

I am running a mixed system. How can I find out what packages are from which distribution?

You definitely like to play with fire if you got this far, but can't answer this simple question. OK, enough patronizing :) , try apt-show-versions.

I tried to remove a package and now many other packages are scheduled for (auto)remove

This usually happens because you are trying to remove a package that is a dependency of a metapackage. In such a situation all package managers will try to remove the metapackage as well, but as a consequence all dependencies of the metapackage are now considered unused and scheduled for (auto)removal. There are various solutions to this problem:

  1. Mark the other dependencies as manually installed and let the package manager remove the metapackage.

This will keep the other packages installed, but it has the downside that new dependencies of the metapackage will not be installed. This is not an issue for stable, only for testing, unstable or upgrades to a new release.

  1. Force the package manager to ignore the missing dependency and keep the metapackage installed.

This is dangerous unless you know exactly what you are doing and the package manager will keep complaining about broken packages. See next point for a better solution.

  1. Use equivs to create a dummy package.

The package equivs can be used to ?create a dummy package to fullfil the missing dependency. This way you can keep the metapackage installed and the package manager will be happy. This however may not be worth the trouble compared to just keeping the package installed that you tried to remove in the first place.

  1. Ask the package Maintainer to use Recommends: instead of Depends:.

If you think the package you are trying to remove should be optional you could ask the Maintainer to change the Depends: to a Recommends: via a wishlist bug. As usual when filling bugs, make sure it has not been asked before and also consider that the package Maintainer may have valid reasons to do it like this.

Multiarch

As of Debian 7.0 (wheezy) it is possible to install packages from different architetures on the same system. The most common use is installing i386 packages on amd64 (or vice-versa).

See Multiarch for more information ...

How can I enable Multiarch

If you are using a custom Linux kernel for 64-bit PC and want to run 32-bit programs, then you have to set the CONFIG_IA32_EMULATION Linux build configuration option, otherwise you won't be able to run 32-bit binaries.

As soon as you have APT and dpkg from wheezy installed you can do the following to activate Multiarch (assuming an amd64 system that needs i386 packages):

# dpkg --add-architecture i386
# apt-get update

Do I still need ia32-libs/ia32-libs-gtk ?

Probably no, see below.

If I'm trying to upgrade ia32-libs/ia32-libs-gtk I get a lot of i386 libraries installed

This is expected. ia32-libs/ia32-libs-gtk used to contain all those libraries. In order to ensure the same functionality now it depends on the corresponding i386 packages instead. You might be able to get rid of some of them, see below.

My non-Debian software has an amd64 package that depends on ia32-libs/ia32-libs-gtk, how can I get rid of ia32-libs/ia32-libs-gtk ?

If an amd64 package depends on ia32-libs/ia32-libs-gtk it is actually 32bit software and the vendor will probably also have an i386 package. Activate Multiarch, install the i386 package instead of the amd64 package and let APT handle the dependencies.

But APT wants to install a lot of i386 libraries now

Yes, this is expected, but unless your package has a lot of dependencies these should still be fewer than the libraries contained in the former (all-in-one) ia32-libs/ia32-libs-gtk packages, or the libraries depended on by ia32-libs/ia32-libs-gtk.

Will this break my system?

Probably not, but if you want to be on the safe side don't upgrade to wheezy before it is released.

But I don't want all those libraries / I want to keep the all-in-one ia32-libs/ia32-libs-gtk packages

You will have to stay with squeeze for this.

Are cross-grades possible?

In theory yes, see CrossGrading. For Wheezy it is probably still safer to just re-install.

Google-earth and Multiarch

As of 2012-12-18 installing Google-earth with Multiarch is impossible because of missing i386 binaries, and Multiarch only allows co-installation of libraries.

At least for 7.1.2.2041-r0 google-earth-stable (arch i386) you can, at Debian Sid (20140712), remove lsb-core dependency following EditingBinaryPackageMetadata, and having Multiarch activated (if you have amd64 arch). With such package installed, google-earth works fine

systemd

As of Jessie systemd is the default init system in Debian.

How can I prevent systemd from being installed on upgrades?

See the question above on how to prevent installation of a specific package on upgrades.

How can I temporarily boot with another init on Jessie?

Install the package sysvinit if not already present and boot with the parameter.

init=/lib/sysvinit/init

How can I prevent systemd to run as PID 1 (init) on Jessie?

Remove the package systemd-sysv and install one of the alternative Pre-Depends: of the package init (either sysvinit-core or upstart as of 2014-10-22)

Please note that some applications need components of systemd (mainly systemd-logind) and will therefore depend on the package libpam-systemd (which needs the package systemd to function properly and therefore depends on it). If you don't want to use systemd as PID 1, but want to be able to use applications that need systemd-logind you will also need to install the package systemd-shim. All of this can be done with just one command:

apt-get install sysvinit-core systemd-shim systemd-sysv-

(the '-' behind systemd-sysv means remove)

How can I remove the systemd package from my Jessie system?

If you want to remove the package systemd from your system you will also have to remove any package depending (directly or indirectly) on libpam-systemd. Your prefered APT tool should do this automatically if you try to remove the package systemd. See above for a different approach that requires keeping the systemd package, though only a few of its components will be used.

How can I remove any traces of systemd from my Jessie system?

Removing any traces of systemd from your system is going to be a bit more difficult, since many packages, including Essential ones, link against libsystemd (the systemd shared library, package libsystemd0 in Jessie). Removing this package will require recompilation of every package depending on it.

Please note the library is only used by other packages when they need to interact with systemd (or one of its components) and is otherwise inert.

Posting on debian-user

How should I post/reply to debian-user?

Please see the Code of conduct for Debian mailing lists. It is also helpful if you ask your questions in a smart way and answer by quoting properly.

I asked my question according to the directions written at the "How should I post" question, but I still don't get an answer

I don't think you really read this faq referenced above (this question is answered there, I just double-checked :) ).

Should I be subscribed to post to debian-user?

Debian has a policy of open mailing lists. This means most lists are open for anyone to write to (the occasional spam resulting from this is unavoidable, but only a minor inconvenience - the list has excellent filters). However, list subscribers can not guess if you are subscribed or not, so you should request replies to be CC'd to you (or set Reply-To accordingly).

Help! My e-mail address is available in your list archives for the spam-bots to harvest/Why aren't e-mail addresses scrambled?

Such a measure does not really help to fight the spam, just a symptom. See http://www.interhack.net/pubs/munging-harmful for a detailed explanation.

This list is littered with spam, do something about it!

Actually it is not. For every spam that makes it through the filters there are many thousands blocked. Besides, the filters are tuned to avoid any false positives. If you want to help (or at least not make it more difficult) please:

How can I get my postings/e-mail removed from the archives?

Short answer: you can't. Even if the archive administrators would do it for the official Debian archives, this list is available in several other places (gmane, googlegroups, ...) over which the Debian Project has no control. See also the official policy for more info.

I subscribed to the list, but my mailbox is flooded with mail

The debian-user mailing list has a very high volume of traffic, you should expect to get around 150 mails per day, but there are ways to cope with it:

What is top-posting (and why shouldn't I do it)?

Both questions can be answered with this example (seen in some sig):

A: Because it messes up the way you read

Q: Why is top-posting bad?

A: Writing your answer before the question

Q: What is top-posting?

Why doesn't this list facilitate easy replies to the list (a.k.a. reply-to-munging)?

Short answer: it's against the standards. See this document for a thorough explanation. In case your email client doesn't support List-reply then please use Reply-to-all and delete all but the list address.

Can I ask a question about foo?

Don't ask to ask, just go ahead and post your question, but see also the question about offtopic.

What is considered offtopic for debian-user?

Generally anything that has no relation to Debian is offtopic on debian-user. If you really, really want to post about it:

Asking questions about any software packaged for Debian is generally ok, especially if you can't tell if your problem is Debian specific or not (but do mention this).

Asking general usage questions about any software is generally discouraged since most projects have their own dedicated user lists.

It is of course acceptable to discuss Debian specific configurations/customizations (did you read /usr/share/doc/<package>/README.Debian first?) or ask for help with a version that is available in a current Debian release, but upstream does not support anymore.

Is it ok if I attach/include bigfile in my message or should I use a pastebin instead?

Many subscribers are receiving list messages via slow or expensive or unreliable connections. On the other hand email is not guaranteed to arrive in a specific order (just think about greylisting).

If possible, always make your post self-contained (consider users reading off-line and connecting only to send and receive messages).

Computer generated output of tens of lines should always be included or attached (beware to not break the lines). Log files (or dmesg output) will also be ok in most cases, but try to include only the relevant parts. Documents or images (screenshots) should never be posted and will probably be discarded by the list server anyway.

My posts are considered spam and rejected (or never show up)

Try subscribing to the whitelist. See also this question in case you post from a gmail account.

I'm posting via gmail's servers, but I never receive my own posts (other list mail is fine)

Gmail has a somewhat different view of how a mail server should behave. Because there is already a copy of your mail in the Sent folder the incoming copy from the mailing list is silently discarded. But if another party responds to the message then this new message will be seen in the Inbox. And because it does it will pull in the original because it is a reply to it. Result? You don't see your own postings back from a mailing list until someone else responds to the thread.

If you still want to use Gmail for posting, here are a few possible workarounds:

It seems Gmail considers this to be a feature and is not willing to change it, although requested by many users. You could try writing them about this as well, maybe they will eventually listen.


FAQs