Depends on linux-ubuntu-modules-386

Bug #148586 reported by Loye Young
12
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
Fix Released
Medium
Unassigned
apt (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: apparmor

I have a server that runs the linux-image-server. I upgraded to gutsy. On reboot, "uname -r" showed that the server was running the 386 kernel. On investigation I found:
ubuntu-standard depends on apparmor
apparmor depends on linux-ubuntu-modules-386
linux-ubuntu-modules-386 depends on linux-image-386

Best behavior would be for dependency to be to whatever image flavor the machine is running (unless there is something about apparmor that requires a 386 kernel, but I can't think of what that might be).

Second best behavior would be to depend on generic kernel instead of 386.

Finally, if all else fails, apparmor should not be part of ubuntu-standard (perhaps a suggest dependency would be appropriate).

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

Revision history for this message
In , Matt Zimmerman (mdz) wrote : merge

# ordering of packages on the command line matters
severity 122304 normal
merge 196021 122304
thanks

--
 - mdz

Revision history for this message
In , Matt Zimmerman (mdz) wrote : retitle

retitle 122304 Order is significant when specifying packages to install
thanks

--
 - mdz

Revision history for this message
In , Daniel Miles (daniel-t-miles) wrote : bug-fix patch

The problem we were having was that the order of the arguments specified
mattered.

If you tried to run:
apt-get install package1 package2
it put in a different package set than it did when you ran
apt-get install package2 package1

The problem came when package2 had a single dependency that was a
secondary member of an Or group for package1.

IE
Package: Package1
...
Depends: Package3 | Package4

Package: Package2
..
Depends: Package4, PackageX...

By the time it started processing dependencies for Package2 (the second
user-specified argument) it had already decided to install Package3 to
satisfy the (Package3 | Package4) Or group. Then when it saw that
Package2 depends on Package4, it marked that one for install but did not
un-mark Package3.

Since the problem was that the decision was being made to early, what I
did was postpone the decision. I modified
apt-pkg/depcache.cc::MarkInstall to skip Or groups instead of finding a
package to satisfy and recursing. Next I added a new function
apt-pkg/depcache.cc::MarkOrsInstall that is to be called after ALL of
the user-specified arguments had been through MarkInstall. At that point
I could tell if a secondary member of an Or group had already been
marked for install (in other words if it existed as a single dependency
elsewhere). Or groups that have a member already marked are considered
satisfied and only MarkOrsInstall is called for that package. Or groups
that do NOT have a member already marked are satisfied with their first
member and both MarkInstall and MarkOrsInstall are called for that
package.

In order to make this work I also had to make trivial modications to
cmdline/apt-get.cc. The loop in DoInstall now stores each package name
that it processes in a vector so that it may be passed to
TryToInstallOrs (made just for design-consistancy). TryToInstallOrs
calls MarkOrsInstall in apt-pkg/depcache.cc

At any rate, I've attached a diff file for your consideration.
Thank you.

Revision history for this message
In , Daniel Miles (daniel-t-miles) wrote :

tags 122304 + patch

Revision history for this message
In , Matt Zimmerman (mdz) wrote : Re: Bug#122304: bug-fix patch

On Tue, Jun 01, 2004 at 03:21:56PM -0600, Daniel Miles wrote:

> Since the problem was that the decision was being made to early, what I
> did was postpone the decision. I modified apt-pkg/depcache.cc::MarkInstall
> to skip Or groups instead of finding a package to satisfy and recursing.
> Next I added a new function apt-pkg/depcache.cc::MarkOrsInstall that is to
> be called after ALL of the user-specified arguments had been through
> MarkInstall. At that point I could tell if a secondary member of an Or
> group had already been marked for install (in other words if it existed as
> a single dependency elsewhere). Or groups that have a member already
> marked are considered satisfied and only MarkOrsInstall is called for that
> package. Or groups that do NOT have a member already marked are satisfied
> with their first member and both MarkInstall and MarkOrsInstall are called
> for that package.

Thanks for this. If I understand it correctly, it means that the apt
frontends (aptitude, synaptic, etc.) will need to change the way that they
install packages. Because of this, and also because it changes the ABI, we
can't do this in the 0.5.x branch of apt: the dependencies of the base
system have been frozen for some time now.

I am interested in testing this change on the 0.6.x branch, though.

--
 - mdz

Revision history for this message
In , Matt Zimmerman (mdz) wrote : Branch in arch for MarkOrsInstall

I've imported this patch into arch:

<email address hidden>/apt--mark-ors--0

--
 - mdz

Revision history for this message
In , Paul Brossier (piem) wrote : more about apt

reassign 305746 apt
merge 305746 122304
thanks

Revision history for this message
In , Eric Lavarde (debian-bugs-nospam) wrote : Simpler case where apt currently install unnecessary packages.

Package: apt
Version: 0.6.45
Followup-For: Bug #122304

Hi,

reading through the bug thread, I've understood the problem description
but I think the bug catches in ever simpler cases, as I get the
following phenomena:

# apt-get -s install nvidia-glx nvidia-kernel-2.6.16-2-k7
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  nvidia-kernel-2.6.16-2-486 nvidia-kernel-common
Suggested packages:
  nvidia-settings nvidia-kernel-source
Recommended packages:
  linux-image-2.6.16-2-486
The following NEW packages will be installed
  nvidia-glx nvidia-kernel-2.6.16-2-486 nvidia-kernel-2.6.16-2-k7
  nvidia-kernel-common
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
[...]

# apt-get -s install nvidia-kernel-2.6.16-2-k7 nvidia-glx
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  nvidia-kernel-common
Suggested packages:
  nvidia-settings nvidia-kernel-source
The following NEW packages will be installed
  nvidia-glx nvidia-kernel-2.6.16-2-k7 nvidia-kernel-common
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
[...]

The reason being that nvidia-glx is dependent on nvidia-kernel-1.0.8762,
provided by the whole nvidia-kernel-2.6.16-2-* family.
As I'm not sure to understand exactly the scope of the patch, I just
wanted to be sure that this usecase is covered as well.

Hope this helps, Eric

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-k7
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)

Versions of packages apt depends on:
ii libc6 2.3.6-15 GNU C Library: Shared libraries
ii libgcc1 1:4.1.1-5 GCC support library
ii libstdc++6 4.1.1-5 The GNU Standard C++ Library v3

Versions of packages apt recommends:
pn debian-archive-keyring <none> (no description available)

-- no debconf information

Revision history for this message
Loye Young (loyeyoung) wrote :

Binary package hint: apparmor

I have a server that runs the linux-image-server. I upgraded to gutsy. On reboot, "uname -r" showed that the server was running the 386 kernel. On investigation I found:
ubuntu-standard depends on apparmor
apparmor depends on linux-ubuntu-modules-386
linux-ubuntu-modules-386 depends on linux-image-386

Best behavior would be for dependency to be to whatever image flavor the machine is running (unless there is something about apparmor that requires a 386 kernel, but I can't think of what that might be).

Second best behavior would be to depend on generic kernel instead of 386.

Finally, if all else fails, apparmor should not be part of ubuntu-standard (perhaps a suggest dependency would be appropriate).

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

Revision history for this message
Mathias Gug (mathiaz) wrote : Re: [Bug 148586] Depends on linux-ubuntu-modules-386

On Wed, Oct 03, 2007 at 03:05:03PM -0000, Loye Young wrote:
>
> I have a server that runs the linux-image-server. I upgraded to gutsy. On reboot, "uname -r" showed that the server was running the 386 kernel.

You mean -generic ?

> On investigation I found:
> ubuntu-standard depends on apparmor
> apparmor depends on linux-ubuntu-modules-386
> linux-ubuntu-modules-386 depends on linux-image-386

apparmor doesn't depend on linux-ubuntu-modules. It recommends
apparmor-modules | apparmor-modules-2.1, which is provided by
linux-ubuntu-modules.

 status incomplete
 importance medium

Changed in apparmor:
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
Loye Young (loyeyoung) wrote :

On Wednesday, October 10, 2007 6:57:27 pm Mathias Gug wrote:
> You mean -generic ?
Nope. I mean 386. The upgrade to Gutsy installed the 386 kernel on my server.
The only reason I can see was the dependency issue to apparmor.

> apparmor doesn't depend on linux-ubuntu-modules. It recommends
> apparmor-modules | apparmor-modules-2.1, which is provided by
> linux-ubuntu-modules.
>
Whatever. The net result is that the 386 kernel got installed on the server
and was placed in the first position in the grub boot list. Consequently,
when I rebooted the server (thinking I was going to get the latest-greatest
server kernel), the 386 kernel was loaded. The only package that had a
dependency on linux-ubuntu-modules-386 was apparmor. I myself had trouble
accepting that such a thing would happen, but there you have it.

It is the general philosophy of Ubuntu that packages have sensible defaults.
Per Debian policy manual, "The Recommends field should list packages that
would be found together with this one in all but unusual installations."
Installing the 386 module, which depends on the kernel, is exactly the
opposite: It should NOT be installed except in unusual installations.

The solution should be figured out ASAP to prevent the problem from arising
when Gutsy is rolled out. Many, if not most, server implementations are
command-line only, which means that the users will be using a command-line
package manager instead of Synaptic. The admins of servers are also likely to
be aware of the definitions of "Recommends" and "Suggests" and thus will
normally be installing Recommends, which is the default for aptitude.

If we roll out Gutsy as a production server platform and leave this
unresolved, there will be enterprise-class users who will be . .
uh . . . "disaapointed" about getting a 386 kernel when they were expecting
an upgraded server kernel.

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

>
> status incomplete
> importance medium
>
>
> ** Changed in: apparmor (Ubuntu)
> Importance: Undecided => Medium
> Status: New => Incomplete

Revision history for this message
Mathias Gug (mathiaz) wrote :

On Thu, Oct 11, 2007 at 05:45:44AM -0000, Loye Young wrote:
> On Wednesday, October 10, 2007 6:57:27 pm Mathias Gug wrote:
> > You mean -generic ?
> Nope. I mean 386. The upgrade to Gutsy installed the 386 kernel on my server.
> The only reason I can see was the dependency issue to apparmor.

How did you upgrade to gutsy (with apt-get, aptitude, do-release-upgrade) ?

--
Mathias

Revision history for this message
Loye Young (loyeyoung) wrote :

On Thursday, October 11, 2007 3:59:50 pm Mathias Gug wrote:
> On Thu, Oct 11, 2007 at 05:45:44AM -0000, Loye Young wrote:
> > On Wednesday, October 10, 2007 6:57:27 pm Mathias Gug wrote:
> > > You mean -generic ?
> >
> > Nope. I mean 386. The upgrade to Gutsy installed the 386 kernel on my
> > server. The only reason I can see was the dependency issue to apparmor.
>
> How did you upgrade to gutsy (with apt-get, aptitude, do-release-
> upgrade) ?
>
> --
> Mathias

do-release-upgrade didn't work, in part because my servers are behind a
firewall and use a local network mirror.

So I edited sources.list, replacing feisty with gutsy. Then,
# aptitude update
# aptitude full-upgrade

Because of some pre-depends, it tooks a couple or three rounds of upgrades.
But it all got upgraded and the kruft got removed. (Aptitude is a beautiful
thing.) To work around the bug, I manually edited /boot/grub/menu.list to
move the server kernel to the first position. Reboot, and I have gutsy
running.

Loye

Revision history for this message
Mathias Gug (mathiaz) wrote :

On Thu, Oct 11, 2007 at 10:26:34PM -0000, Loye Young wrote:
> do-release-upgrade didn't work, in part because my servers are behind a
> firewall and use a local network mirror.

Did you file a bug report about this ? update-manager (which
do-release-upgrade is part of) is the official and supported way to
upgrade from one release to another. It should work nicely with a local
network mirror.

>
> So I edited sources.list, replacing feisty with gutsy. Then,
> # aptitude update
> # aptitude full-upgrade
>

Using aptitude to upgrade to a new release is not fully supported in Ubuntu.

Revision history for this message
Loye Young (loyeyoung) wrote :

> Did you file a bug report about this ? update-manager (which
> do-release-upgrade is part of) is the official and supported way to
> upgrade from one release to another. It should work nicely with a local
> network mirror.

yes I did. No response.

Revision history for this message
Mathias Gug (mathiaz) wrote :

Was the linux-server package installed before upgrading ?

Revision history for this message
Loye Young (loyeyoung) wrote :

On Friday, October 12, 2007 1:30:16 pm Mathias Gug wrote:
> Was the linux-server package installed before upgrading ?

yes

Revision history for this message
Loye Young (loyeyoung) wrote :

Update:
I Just had the same problem on a KDE desktop that was running the generic
kernel. On reboot, ended up with 386 kernel.

Followed instructions on wiki
do-release-upgrade returned "no updates found" or similar lingo
edited /etc/apt/sources.list by changing feistly >> gutsy
aptitude full-upgrade
<snip lots of downloading and installing>
roboot

Once again, a 386 kernel is what booted.

Revision history for this message
Oliver Grawert (ogra) wrote :

apparently some nvidia-glx users have a similar prob (with a Provides: in l-r-m instead of l-u-m), during examination i found the following:

ogra@laptop:~$ LANG=C sudo apt-get install nvidia-glx linux-restricted-modules-2.6.22-14-generic
...
The following extra packages will be installed:
  linux-image-2.6.22-14-386 linux-restricted-modules-2.6.22-14-386 nvidia-kernel-common

versus .....

ogra@laptop:~$ LANG=C sudo apt-get install linux-restricted-modules-2.6.22-14-generic nvidia-glx
...
The following extra packages will be installed:
  nvidia-kernel-common

apparently apt-get wants a special order to make sure the right deps are there, that doesnt seem right to me, assignong to apt-get as well.

Revision history for this message
Daniel Hahler (blueyed) wrote :

The apt bug is bug 78563 already. So closing the apt task here as invalid. (Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=122304)

Changed in apt:
status: New → Incomplete
Revision history for this message
Daniel Hahler (blueyed) wrote :

Loye,
> do-release-upgrade returned "no updates found" or similar lingo
You have to use "do-release-upgrade --devel-release" (or "... -d"), because it's not yet released.

Changed in apt:
status: Incomplete → Invalid
Revision history for this message
Loye Young (loyeyoung) wrote : Re: [Bug 148586] Re: Depends on linux-ubuntu-modules-386

I suspect that it tries to puts the 386 module in because it's the first one
in alphanumberical order. It looks like that for some reason, it's not
checking the entire list; instead, it's just installing the first one on the
list.

This may be a dpkg issue, not apt-get. I always use the aptitude and I'm
getting similar behavior.

On Sunday, October 14, 2007 7:26:50 am Oliver Grawert wrote:
> apparently some nvidia-glx users have a similar prob (with a Provides:
> in l-r-m instead of l-u-m), during examination i found the following:
>
> ogra@laptop:~$ LANG=C sudo apt-get install nvidia-glx
> linux-restricted-modules-2.6.22-14-generic ...
> The following extra packages will be installed:
> linux-image-2.6.22-14-386 linux-restricted-modules-2.6.22-14-386
> nvidia-kernel-common
>
> versus .....
>
> ogra@laptop:~$ LANG=C sudo apt-get install
> linux-restricted-modules-2.6.22-14-generic nvidia-glx ...
> The following extra packages will be installed:
> nvidia-kernel-common
>
> apparently apt-get wants a special order to make sure the right deps are
> there, that doesnt seem right to me, assignong to apt-get as well.
>
> ** Also affects: apt (Ubuntu)
> Importance: Undecided
> Status: New

Revision history for this message
Loye Young (loyeyoung) wrote :

On Sunday, October 14, 2007 8:02:51 am dAniel hAhler wrote:
> You have to use "do-release-upgrade --devel-release" (or "... -d"), because
> it's not yet released.

Instruction added to the wiki. See
https://help.ubuntu.com/community/GutsyUpgrades

Revision history for this message
In , Loye Young (loyeyoung) wrote : Not fundamentally an apt-get problem

I don't think this is an apt-get problem. I use aptitude exclusively, and I
get the same problem. The behavior started only recently, so I think the
problem lies in some package that both apt-get and aptitude depend on. The
issue won't really be solved until the real source of the issue is discovered
and corrected.

Loye Young

Revision history for this message
In , Otavio Salvador (otavio) wrote : Re: Bug#122304: Not fundamentally an apt-get problem

Loye Young <email address hidden> writes:

> I don't think this is an apt-get problem. I use aptitude exclusively, and I
> get the same problem. The behavior started only recently, so I think the
> problem lies in some package that both apt-get and aptitude depend on. The
> issue won't really be solved until the real source of the issue is discovered
> and corrected.

What's your linux kernel?

--
        O T A V I O S A L V A D O R
---------------------------------------------
 E-mail: <email address hidden> UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Revision history for this message
Mathias Gug (mathiaz) wrote :

I don't think that this is a duplicate of bug 78563. What oliver described in https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/148586/comments/10 probably is.

However the original report is for a simple apt-get dist-upgrade, thus there isn't any order of command line options.

Reopening the apt task.

Changed in apt:
status: Invalid → Incomplete
Changed in apparmor:
status: Unknown → New
Revision history for this message
In , Daniel Burrows (dburrows) wrote :

On Mon, Oct 15, 2007 at 09:03:18AM -0500, Loye Young <email address hidden> was heard to say:
> I don't think this is an apt-get problem. I use aptitude exclusively, and I
> get the same problem. The behavior started only recently, so I think the
> problem lies in some package that both apt-get and aptitude depend on. The
> issue won't really be solved until the real source of the issue is discovered
> and corrected.

  Could you please post the command that behaves differently if you
change the ordering of the packages, and the change that affects the
behavior?

    Thanks,
  Daniel

Revision history for this message
Daniel Hahler (blueyed) wrote :

bug 188579 appears to be the same, where also the 386 kernel gets pulled in. That bug provides an easier test case and I've just added a rdepends graph over there to visualize the problem.

Revision history for this message
In , Jeffrey Ratcliffe (jeffreyratcliffe) wrote : Another case where apt currently installs unnecessary packages.

   apt-get install tesseract-ocr tesseract-ocr-ita

installs tesseract-ocr-deu unnecessarily

  apt-get install tesseract-ocr-ita tesseract-ocr

or just

  apt-get install tesseract-ocr-ita

has the desired effect

Revision history for this message
In , Eugene V. Lyubimkin (jackyf-devel) wrote : forcibly merging 122304 283874

forcemerge 122304 283874

Revision history for this message
In , Eugene V. Lyubimkin (jackyf-devel) wrote : forcibly merging 122304 380566

forcemerge 122304 380566

Revision history for this message
In , Eugene V. Lyubimkin (jackyf-devel) wrote : forcibly merging 122304 155915

forcemerge 122304 155915

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Marking the apparmor task as Fix Released. As of 8.04 LTS, there is no 'Recommends
apparmor-modules | apparmor-modules-2.1' and Ubuntu 7.10 has been end-of-lifed.

Changed in apparmor (Ubuntu):
status: Incomplete → Fix Released
Revision history for this message
Steve Beattie (sbeattie) wrote :

Closing the AppArmor upstream project task, as the issue was with the Ubuntu packaging.

Changed in apparmor:
importance: Unknown → Critical
status: New → Invalid
importance: Critical → Medium
Changed in apparmor:
importance: Medium → Unknown
status: Invalid → New
Steve Beattie (sbeattie)
affects: apparmor → null
Revision history for this message
Julian Andres Klode (juliank) wrote :

The ordering is important stuff has been fixed and the rest is not an APT problem.

Changed in apt (Ubuntu):
status: Incomplete → Invalid
Changed in null:
status: New → Fix Released
Curtis Hovey (sinzui)
no longer affects: null
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.