problems in a net upgrade to Debian 8.1
One of my systems has had Debian 7.x (AMD64) installed from 3 DVD's and subsequently it has been upgraded over the internet to testing a number of times. The last of these upgrades was sometime back (6 months or so). This was upgraded to 8.1 yesterday. Unfortunately its left the package system in a poor state. Note, previous experience doing this shows Debian's package system does not like this combination (install from cd/dvd and update via the internet) to go beyond the next version number. Aptitude wants to remove a large number of packages like blender, gimp, exiv2, the list going on and on. dselect how ever is much more on the ball, it only wanting to remove imagemagik and graphicsmagik. Apt does not appear to know what its doing, for instance it wishs to remove blender for 2 unmet dependencies. Curiously dselect, dpkg AND looking in the /var/lib/dpkg/info directory shows these dependcies ARE on the system. It's distinctly possible apt is not getting on well with a system thats been instaled from DVD's. I have suffered from similar package system corruption from this cause in the past. The problem being as almost (iff not all) debian developers use a net install and upgrade the CD/DVD install does not get tested very well. Its generally possible to resolve a situation like this with dpkg, it does require though much mucking around. Note: Both the apt package lists and the dpkg package lists have been updated, experience that these being out of sync can cause weird problems. Anyone have any ideas, it looks as though I may have to install 8.1 from scratch, something I am NOT really looking forward to due to what packages I like to select, package selection taking forever. Lindsay
On 18.06.15 16:30, zlinw@mcmedia.com.au wrote:
Aptitude wants to remove a large number of packages like blender, gimp, exiv2, the list going on and on. dselect how ever is much more on the ball, it only wanting to remove imagemagik and graphicsmagik. Apt does not appear to know what its doing, for instance it wishs to remove blender for 2 unmet dependencies. Curiously dselect, dpkg AND looking in the /var/lib/dpkg/info directory shows these dependcies ARE on the system.
If apt only wants to remove a few packages, what happens when you do that and then use apt to reinstall them? It won't take long, and could obviate the need for a complete system reinstall. Nothing lost, plenty to gain, maybe. I have to admit that my recent debian 7.8.0 install is piling up notifications of recommended package upgrades, which I ignore because it doesn't provide a list of them I can aim apt at. I'm only willing to use one package upgrade method, and that's not blindly clicking "OK" on a nameless GUI surrender icon.
It's distinctly possible apt is not getting on well with a system thats been instaled from DVD's. I have suffered from similar package system corruption from this cause in the past.
But even a net install is an install from DVD, here at least, since I've always burnt the downloaded iso to DVD. I must admit that I've _never_ ventured a dist_upgrade. That does seem to be asking for trouble. I just update what's really needed, piecemeal, for minimum disturbance, then install from scratch every five years or so, whether it's needed or not. More often would be masochistic, I think, having just discovered that the new debian 7.8.0 install a couple of months ago lost awareness of the HP Laserjet 3050 printer, which had worked fine for years. Each new upgrade seems to confirm that they're a bad idea. Erik -- A Ponzi Scheme is any investment where returns are derived, not from earnings of the investment itself, but from capital injected by new investors. When you look at the yield on rental property in Sydney it is around 3.5%. Price growth has been around 10.2% over the last 20 years. Smells like a Ponzi scheme to me. - Richard, http://www.abc.net.au/news/2015-06-15/verrender--a-ponzi-scheme-that-could-r...
On Thu, 18 Jun 2015 07:20:56 PM Erik Christiansen wrote:
I have to admit that my recent debian 7.8.0 install is piling up notifications of recommended package upgrades, which I ignore because it doesn't provide a list of them I can aim apt at.
Isn't that what "apt-get dist-upgrade" is for? If you are really serious about checking things then you can install apt-listchanges and set: confirm=1 in /etc/apt/listchanges.conf and then apt will download the changeslogs and ask you to confirm whether you wish to apply them before proceeding. If you say 'n' then it will abort. Best of luck, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On 18.06.15 19:20, Chris Samuel wrote:
On Thu, 18 Jun 2015 07:20:56 PM Erik Christiansen wrote:
I have to admit that my recent debian 7.8.0 install is piling up notifications of recommended package upgrades, which I ignore because it doesn't provide a list of them I can aim apt at.
Isn't that what "apt-get dist-upgrade" is for?
Yes, but as mentioned in the post, I refuse to click on a surrender icon, to buy a pig in a poke.
If you are really serious about checking things then you can install apt-listchanges and set:
confirm=1
in /etc/apt/listchanges.conf and then apt will download the changeslogs and ask you to confirm whether you wish to apply them before proceeding. If you say 'n' then it will abort.
Done. Thanks, Chris. Mind you, that merely listed maybe sixty packages, and provided one confirmation check, as it does on any large install, even with confirm=0. Perhaps there's a difference in behaviour on one small package, which otherwise is just slipped in?
Best of luck,
May need it. I've never been willing to do dist-upgrade before. Erik -- Looking into the UN's crystal ball predicts that population will continue to grow and then plateau around 10 billion by 2100. This is the middle estimate. The lower estimate suggests a peak of about 8 billion around 2050. The high estimate is for a staggering 16 billion by 2100 and still climbing! - http://www.abc.net.au/radionational/programs/ockhamsrazor/preparing-for-popu...
On Thu, 18 Jun 2015 08:31:32 PM Erik Christiansen wrote:
On 18.06.15 19:20, Chris Samuel wrote:
On Thu, 18 Jun 2015 07:20:56 PM Erik Christiansen wrote:
I have to admit that my recent debian 7.8.0 install is piling up notifications of recommended package upgrades, which I ignore because it doesn't provide a list of them I can aim apt at.
Isn't that what "apt-get dist-upgrade" is for?
Yes, but as mentioned in the post, I refuse to click on a surrender icon, to buy a pig in a poke.
Sorry, I don't get it. You said you weren't getting a list of packages that were wanting to be upgraded, and that's just what apt-get dist-upgrade will tell you. Just add the -d option (download only) if you want to be really sure it won't touch anything. [apt-listchanges]
Done. Thanks, Chris.
No worries. Also check out etckeeper to keep /etc under git revision control, it's fantastic (on Ubuntu it's less easy as you have to make sure you install etckeeper either at the same time as git or after without having bzr installed otherwise it'll configure itself to use bzr and commit automatically before you can fix it to use git).
Mind you, that merely listed maybe sixty packages, and provided one confirmation check, as it does on any large install, even with confirm=0. Perhaps there's a difference in behaviour on one small package, which otherwise is just slipped in?
File a bug, it shouldn't happen, this is why people running Debian stable. If it was RHEL I'd be a lot more concerned. You trade off possible (unlikely) behaviour changes with definite security vulnerabilities. The answer depends on your risk assessment.
Best of luck,
May need it. I've never been willing to do dist-upgrade before.
Been using it for years on many systems. I'd be a bit more nervous of that with debian-lts (squeeze) but we avoided the kernel regression in the 12 release and haven't been hit by other issues (yet). All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On 18 June 2015 at 23:49, Chris Samuel <chris@csamuel.org> wrote:
No worries. Also check out etckeeper to keep /etc under git revision control, it's fantastic (on Ubuntu it's less easy as you have to make sure you install etckeeper either at the same time as git or after without having bzr installed otherwise it'll configure itself to use bzr and commit automatically before you can fix it to use git).
Install from puppet to manage dependencies? e.g. https://github.com/NeCTAR-RC/puppet-etckeeper Regards, Marcus. -- Marcus Furlong
Hiya Marcus, On Fri, 19 Jun 2015 12:38:58 AM Marcus Furlong wrote:
Install from puppet to manage dependencies?
I was really talking about single desktops/laptops there; we don't use Ubuntu on servers, only Debian (well, aside from one exception which you know all about :-) ). All the best! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
Chris Samuel <chris@csamuel.org> writes:
on Ubuntu it's less easy as you have to make sure you install etckeeper either at the same time as git or after without having bzr installed otherwise it'll configure itself to use bzr and commit automatically before you can fix it to use git).
Here are my old notes, for Ubuntu 10.04. This assumes bzr isn't installed already (bzr: not bzr_). In 14.04 you probably need to change "git-core" to "git". | aptitude install -Ryq etckeeper git-core+M bzr: | sed -i '/^VCS/s/bzr/git/' /etc/etckeeper/etckeeper.conf | etckeeper init | | Avoid spurious noise in etckeeper:: | | cd /etc | printf %s\\n lvm/archive lvm/backup >>.gitignore | git rm -rf --cached lvm/backup | git rm -rf --cached lvm/archive | | On a roaming DHCP client (i.e. laptop), also ignore resolv.conf:: | | printf %s\\n resolv.conf >>.gitignore | git rm -f --cached resolv.conf
On Thu, 18 Jun 2015 04:30:04 PM zlinw@mcmedia.com.au wrote:
Aptitude wants to remove a large number of packages like blender, gimp, exiv2, the list going on and on. dselect how ever is much more on the ball, it only wanting to remove imagemagik and graphicsmagik. Apt does not appear to know what its doing, for instance it wishs to remove blender for 2 unmet dependencies. Curiously dselect, dpkg AND looking in the /var/lib/dpkg/info directory shows these dependcies ARE on the system.
I've had ongoing problems with aptitude insisting on removing things I want. Usually I just use "apt-get dist-upgrade" to upgrade. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Thu, 18 Jun 2015 04:30:04 PM zlinw@mcmedia.com.au wrote:
One of my systems has had Debian 7.x (AMD64) installed from 3 DVD's and subsequently it has been upgraded over the internet to testing a number of times. The last of these upgrades was sometime back (6 months or so). This was upgraded to 8.1 yesterday.
I'm puzzled by what you say here, you seem to imply the sequence is: 1) Install 7.x from DVD 2) Upgrade to Debian testing 3) Downgrade from testing to 8.1 When you said testing, did you mean you set it to testing or to jessie? If it was testing then that could explain your issues as you'd have had newer packages appearing there once Jessie was released than you would have when you later downgraded to 8.1. On the other hand, if you set it to jessie thenthat transitioned from testing to stable when it was released. As you were running testing at some stage (either as testing or jessie) then could it be that you had packages that were removed due to release blocker bugs? Best of luck! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
Quoting zlinw@mcmedia.com.au (zlinw@mcmedia.com.au):
One of my systems has had Debian 7.x (AMD64) installed from 3 DVD's and subsequently it has been upgraded over the internet to testing a number of times. The last of these upgrades was sometime back (6 months or so). This was upgraded to 8.1 yesterday. Unfortunately its left the package system in a poor state. Note, previous experience doing this shows Debian's package system does not like this combination (install from cd/dvd and update via the internet) to go beyond the next version number.
Aptitude wants to remove a large number of packages like blender, gimp, exiv2, the list going on and on. dselect how ever is much more on the ball, it only wanting to remove imagemagik and graphicsmagik. Apt does not appear to know what its doing, for instance it wishs to remove blender for 2 unmet dependencies. Curiously dselect, dpkg AND looking in the /var/lib/dpkg/info directory shows these dependcies ARE on the system.
It's distinctly possible apt is not getting on well with a system thats been instaled from DVD's.
You really should not use both aptitude and apt-get, as they will in that case store separate 'hinting' records, i.e., they don't share that data. Thus, it's better to pick one tool or the other, rather than using both. I'm guessing the attraction of aptitude for you is its full-screen ncurses mode, reminiscent of dselect's. The apt suite (apt-get, apt-cache, etc.) admittedly has nothing quite like that, which is fine for some of us (e.g., yr. present correspondent) but not others. Also, the apt tools are faster and lighter-weight. In general I concur with the people who've been advising you to eschew dselect on grounds of it being ancient/unmaintained/deprecated/whatever, but FWIW, if you really like the tool and want to keep using it, many of its drawbacks can be eliminated by selecting the apt 'method' within dselect. (IIRC, that still leaves dselect handling dependency resolution, which I personally would consider a deal-breaker. Disclaimer: I don't think I've actually used dselect since Debian 3.0 'woody' days, so please cross-check anything I say about it at this very late date.) So, anyway, I'd recommend picking either apt-get or aptitude, making a note of the packages your preferred tool wants to remove, letting it remove them, and then reinstalling those when it's done. Warning: On the Debian 'testing' branch, at any given time, some packages just aren't installable because of missing dependencies, generally required libs for which the necessary version hasn't yet cleared package quarantine from the 'unstable' repos, whereas the package that requires the new lib has cleared quarantine. This is an inherent consequence of tracking 'testing', and you should follow 'testing' only if you're prepared to deal with that problem. The usual suspects are GNOME and KDE4 packages, as those are the worst dependency hairballs. I _have_ successfully deployed as a workaround adding to the /etc/apt/sources.list[.d/*] files lines for the 'unstable' branch _with_ pin-priority for those sources set to 50 (way below the default priority of 100), ensuring that the 'unstable' sources are never consulted _by default_. The idea is that, if package foo is currently uninstallable on 'testing' because the new version of lib bar hasn't yet cleared quarantine, you can specify installation of _just_ foo and its immediate dependencies from the 'unstable' branch without moving the rest of your system off stable: # apt-get -t unstable install foo Don't act on any of this advice without reliable and fresh backups. ;->
Rick Moen <rick@linuxmafia.com> writes:
You really should not use both aptitude and apt-get, as they will in that case store separate 'hinting' records, i.e., they don't share that data. Thus, it's better to pick one tool or the other, rather than using both.
That was the case in Debian 6 (and maybe 7). Isn't it fixed as at Debian 8? viz. apt-mark.
I'm guessing the attraction of aptitude for you is its full-screen ncurses mode, reminiscent of dselect's.
See also: http://luv.asn.au/overheads/aptitude/aptitude-intro.html
Quoting Trent W. Buck (trentbuck@gmail.com):
Rick Moen <rick@linuxmafia.com> writes:
You really should not use both aptitude and apt-get, as they will in that case store separate 'hinting' records, i.e., they don't share that data. Thus, it's better to pick one tool or the other, rather than using both.
That was the case in Debian 6 (and maybe 7). Isn't it fixed as at Debian 8?
viz. apt-mark.
I'd not heard previously about apt-mark. I see that it's a tool to toggle the record about whether a package was installed as result of satifying a dependency or not. Sounds useful, but I'm not seeing how that solves problems inherently caused by apt-get and aptitude keeping separate records. (I could easily be missing something, and will readily confess to carrying forward old practices and prejudices out of habit because they have worked well for many years in the past. I'd feel more awkward about this frame of mind if it weren't for the vast amount of trouble it's helped me avoid encountering.)
I'm guessing the attraction of aptitude for you is its full-screen ncurses mode, reminiscent of dselect's.
See also: http://luv.asn.au/overheads/aptitude/aptitude-intro.html
Very nice overview. My thanks to the presenter (you?). I still prefer apt-get over aptitude, but that's a Religious Question. ;->
participants (7)
-
Chris Samuel -
Erik Christiansen -
Marcus Furlong -
Rick Moen -
Russell Coker -
trentbuck＠gmail.com -
zlinw＠mcmedia.com.au