dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
2596
LLigetfa
join:2006-05-15
Fort Frances, ON

LLigetfa

Member

Sources, Backports, and apt.conf

I have two Debian machines both on Lenny but they seem to have a mind of their own as to what updates come in what order. They both started out as Etch originally and were dist-upgraded. Both have the one line:
APT::Default-Release "testing";
in the apt.conf but one of them I added itanix.rutgers.edu to the sources.list file.
# 
 
# deb cdrom:[Debian GNU/Linux testing _Etch_ - Official Beta i386 NETINST Binary-1 20070329-08:46]/ etch contrib main 
deb http://debian.yorku.ca/debian/ lenny main non-free 
deb-src http://debian.yorku.ca/debian/ lenny main non-free 
deb http://security.debian.org/ lenny/updates main contrib non-free 
deb-src http://security.debian.org/ lenny/updates main contrib non-free 
deb http://http.us.debian.org/debian/ lenny main non-free 
deb http://www.debian-multimedia.org lenny main 
 
# Backports 
deb http://itanix.rutgers.edu/rumba lenny backport non-free 
deb http://www.backports.org/debian etch-backports main contrib non-free 
 
# Unstable 
deb http://ftp.us.debian.org/debian unstable main contrib non-free 
deb-src http://ftp.us.debian.org/debian unstable main contrib non-free 
 

Now, the one with rutgers in its sources is my FTP server which has a bunch more stuff on it that the other, a laptop doesn't have. I generally update the laptop first as a precaution although it is comparing apples to oranges since the hardware is so different as are the installed apps.

Still, I noticed that my FTP server was offered the 2.6.21 kernel while my laptop was not. Maybe I'm not understanding how backports work nor how the apt.conf is supposed to pin the version of kernel???

What am I doing wrong?
How can I tell what source is offering the new kernel?
LLigetfa

LLigetfa

Member

K, well... answered one of my own questions. I added rutgers to my sources on my lappy and it now offers up the newer kernel too. I still don't understand why though.
LLigetfa

LLigetfa

Member

Did I stump the experts or bore them with a stupid question?
Is the answer simply to don't trust backport sources?
LLigetfa

LLigetfa

Member

Today I removed rutgers from my sources using Synaptic and then reloaded but the kernel update persists. When I checked yesterday in »packages.debian.org/testing/ there was no mention of a kernel update, nor is there any today.
Anyone care to throw me a hint?
LLigetfa

LLigetfa

Member

Not sure if it's Debian or me that's not well liked here. There is a rumor that Lenny has a new kernel but I'm too much a noob to know for sure. If the rumor is true, I'm guessing then, to rationalize what I saw, that the rutgers repo was the first out of the starting blocks to offer it and the others followed close behind.

rexbinary
MOD King
Premium Member
join:2005-01-26
Plano, TX

rexbinary to LLigetfa

Premium Member

to LLigetfa
Well it's not you in my case. I'm just not experienced with Debian at all, sorry.

Joe Blow
@cableone.net

Joe Blow to LLigetfa

Anon

to LLigetfa
I'm slightly confused by your first couple of posts. You talk about apt.conf but post a copy of your /etc/apt/sources.list file.

The first thing I would try would be to use "apt-cache search linux-image" to see if the newer kernel image can be found in the repository. It's been my experience that not all apt repositories are always up-to-date and that sometimes what can be found on one repository will not be found in another. For that reason I always use either mirrors.kernel.org, ftp.debian.org, or ftp.us.debian.org. They seem to be the best at having current packages.

The second thing I would look at is if the kernel-image/linux-image package you're looking for has been updated with a new release number such 2.6.21-1-486 to a 2.6.21-2-486. If it has and you try the first version you will be told the package doesn't exist.

One thing to be aware of in using apt-cache search is that if a package is installed a computer it will show up even if that package is not to be found in the repositories any more. That one had me scratching my head the first time I ran across that particular situation. I wasn't aware apt-cache searched locally and so couldn't figure out why one machine could find a package and another newer installation couldn't. The way to verify this situation is to use dpkg -l | grep package_name on the machine that can find the package. If dpkp reports it as installed you can know that the package version has changed or that it has been dropped from the repository.
LLigetfa
join:2006-05-15
Fort Frances, ON

2 edits

LLigetfa

Member

I didn't mean to confuse anyone but since apt.conf is a one-liner, I didn't think it necessary to post it in code tags.

I did do that apt-cache search thingy and it did find it and rightfully so since I have mixed repos. What my limited experience could not do for me is determine from what repo it was being offered.

Thanks for the heads-up on the apt-cache local caching.

As for being cautious wrt the version of kernel, I just want to be sure it is an official release for Lenny and that I wasn't getting it from Sid or by accident. I'm too much a noob to worm my way out of trouble that mixing versions could get me into. In fact, I added the Sid repos with the thought of grabbing the newer kernel from there but then chickened out.
yazdzik
MVM
join:2000-07-26
Honesdale, PA

yazdzik to LLigetfa

MVM

to LLigetfa
Dear Friends,

this is a case of two things that interact - the list itself and the pinning.

If server a has a higher pin number than server b, the way-over-simplified explanation is that server a will be used to grab updates, unless otherwise specified by a -t option in the command.

So, with a one line apt.conf file, apt-get update will pull allsources, apt-get upgrade will use the latest numberical version(although there are exceptions if deps are not available)

Now, depending upon the server, either testing is testing or lenny(I am not making this up), but, since the conf file merely sets up the default release, rather than pinning the realtive order of imnportance, whichever "testing has the most, the latest, the cutest will be used for a given package, assuming the deps can be met.

At any rate, as of 09:35;53 on the twelfth of July, 2007, testing has linux image 2.6.21-5 as the linux image, and, if the repos and pinning are correct, this will be available as an update.

All good wishes,
'
Martin

Joe Blow
@cableone.net

Joe Blow to LLigetfa

Anon

to LLigetfa
said by LLigetfa:

I didn't mean to confuse anyone but since apt.conf is a one-liner, I didn't think it necessary to post it in code tags.

I did do that apt-cache search thingy and it did find it and rightfully so since I have mixed repos. What my limited experience could not do for me is determine from what repo it was being offered.

Thanks for the heads-up on the apt-cache local caching.

As for being cautious wrt the version of kernel, I just want to be sure it is an official release for Lenny and that I wasn't getting it from Sid or by accident. I'm too much a noob to worm my way out of trouble that mixing versions could get me into. In fact, I added the Sid repos with the thought of grabbing the newer kernel from there but then chickened out.
What you might want to look at is doing this with an /etc/apt/preferences file and apt-pinning by package name, version and release. I've done that and it seemed to work pretty well for me. I'll give you a couple of links. One that shows the basics, and one on how to pin a single package at a time. The apt.conf way of doing things seems to be, to me anyway, a sort of shotgun approach to versioning while apt-pinning can be either a shotgun approach or a very fine-grained way of approaching version management.

I ran one system of mine with a combination of stable, testing, and unstable for about a year just to learn how to play with apt-pinning and ran into very few problems. I don't know if everyone else has had the same kind of results doing this but my experience certainly was positive.

»www.debian.org/doc/manua ··· ml#s-pin

»jaqque.sbih.org/kplug/ap ··· ing.html
Joe Blow

Joe Blow to LLigetfa

Anon

to LLigetfa
I don't know why I didn't think of this earlier(musta had a brain fart), but your best tool for finding out which release a certain package came from is apt-cache policy package_name. This will report installed version number, if a newer package is available, and the complete url for the repository in which it is to be found, which includes the release name such as stable, testing, unstable, etc.... It is very handy when using apt-pinning.

Here is an example of the output.

 apt-cache policy bsdgames
 bsdgames:
  Installed: 2.17-8
  Candidate: 2.17-9
  Version table:
     2.17-9 0
        500 http://ftp.debian.org sid/main Packages
 *** 2.17-8 0
        100 /var/lib/dpkg/status
 
yazdzik
MVM
join:2000-07-26
Honesdale, PA

yazdzik to Joe Blow

MVM

to Joe Blow
said by Joe Blow :

The apt.conf way of doing things seems to be, to me anyway, a sort of shotgun approach to versioning while apt-pinning can be either a shotgun approach or a very fine-grained way of approaching version management.

That is the best and funniest way of putting it I have ever heard.

For example, though, and a simple preferences file could be

 
Explanation: Martin's foolproof
Explanation: File: /etc/apt/preferences
 
Package: *
Pin: release o=Debian,a=experimental
Pin-Priority: 800
 
Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 900
 
Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 850
 
Package: *
Pin: release o=Debian,a=stable
Pin-Priority: 500
 
 

for someone wanting to run unstable, but pull dependencies whence they are necessary.

Now, one could drop the pin number for experimental to 100, or unstable to 100, and end up with pure lenny, but able to draw other versions at will by using, let us say:

apt-get install -t unstable dog and the deps for dog from stable or testing would be pulled in. One hopes.

Best,
m
LLigetfa
join:2006-05-15
Fort Frances, ON

LLigetfa to Joe Blow

Member

to Joe Blow
Hey ja, thanks for that. Apt-cache policy whatever is just what I was looking for.

I did look into pinning a while back and filed it under round-to-it thinking the one-liner will work for now and that I'd get around to it (pinning) when the need arose. I've yet to have the intestinal fortitude to pull something from Sid.

I just panicked a bit when the kernel update appeared to come from a backport and I remembered reading somewhere that one should not trust backports. When I check in »packages.debian.org/testing/ now, the kernel update is listed there so I know now it is legit.

My two computers on Lenny are in my office and I'm at home this week and remoting to them with VNC so I will do the update next week when I am back to work.

Thanks again,

Les
LLigetfa

LLigetfa

Member

When I got to my office this morning, the new KVM I ordered was sitting outside my door so I took straight to rearranging my office. Lenny was tucked back in a corner connected to its own 19" LCD because I ran out of ports on my old KVM.

So, eager to see Lenny running on my 24" Dell 2405FPW, I hooked it up to my new KVM but xorg just didn't want to play nice with it. After more than a dozen dpkg-reconfigure xserver-xorg attempts, I decided to give the new kernel a go and did a apt-get dist-upgrade. The new bits sure look nice now at 1920x1200.