Ubuntu

libc6 upgrade fails: illegal instruction

Reported by Martin-Éric Racine on 2010-05-29
112
This bug affects 13 people
Affects Status Importance Assigned to Milestone
binutils (Fedora)
Unknown
Unknown
binutils (Ubuntu)
High
Unassigned
Maverick
Undecided
Unassigned
Natty
High
Unassigned
eglibc (Ubuntu)
High
Unassigned
Maverick
Undecided
Unassigned
Natty
High
Unassigned
gcc-4.4 (Ubuntu)
High
Unassigned
Maverick
Undecided
Unassigned
Natty
High
Unassigned
gcc-4.5 (Ubuntu)
Medium
Unassigned
Maverick
Undecided
Unassigned
Natty
Medium
Unassigned
update-manager (Ubuntu)
Medium
Michael Vogt
Maverick
Undecided
Michael Vogt
Natty
Medium
Michael Vogt

Bug Description

Preparing to replace libc6 2.11.1-0ubuntu9 (using .../libc6_2.12~20100519-0ubuntu1_i386.deb) ...
Checking for services that may need to be restarted...
Checking init scripts...
Unpacking replacement libc6 ...
dpkg: warning: subprocess old post-removal script killed by signal (Illegal instruction)
dpkg - trying script from the new package instead ...
dpkg: error processing /var/cache/apt/archives/libc6_2.12~20100519-0ubuntu1_i386.deb (--unpack):
 subprocess new post-removal script killed by signal (Illegal instruction)
dpkg: error while cleaning up:
 subprocess installed pre-installation script killed by signal (Illegal instruction)

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: libc6 2.11.1-0ubuntu9
ProcVersionSignature: Ubuntu 2.6.32-10.14+bug396286v2-generic
Uname: Linux 2.6.32-10-generic i586
Architecture: i386
Date: Sat May 29 12:34:01 2010
ProcEnviron:
 LANGUAGE=fi_FI:fi:en_US:en
 PATH=(custom, user)
 LANG=fi_FI.UTF-8
 SHELL=/bin/bash
SourcePackage: eglibc

Martin-Éric Racine (q-funk) wrote :
Matthias Klose (doko) wrote :

which processor is this? anything older than i686 isn't supported in maverick

Changed in eglibc (Ubuntu):
status: New → Incomplete
Martin-Éric Racine (q-funk) wrote :

Mattias Klose, it would be a good idea to read the data attached to the bug. This is a Geode LX800, therefore i586 generic.

Changed in eglibc (Ubuntu):
status: Incomplete → New
Matthias Klose (doko) wrote :

> it would be a good idea to read the data attached to the bug.

there was none.

> This is a Geode LX800, therefore i586 generic.

ok, closing as won't fix.

Changed in eglibc (Ubuntu):
status: New → Won't Fix
Jeremy Visser (jeremy-visser) wrote :

If this is going to be the case, then producing a libc6-i586 package compiled for i586 processors wouldn’t be a bad idea.

Martin-Éric Racine (q-funk) wrote :

Mattias, please look again. There was a name line and it clearly said i586.

Matthias Klose (doko) wrote :

> There was a name line and it clearly said i586.

Matin-Eic, the line did state the machine, not the processor.

> producing a libc6-i586 package compiled for i586 processors

no, as discussed at UDS we are dropping support for anything older than i686 for maverick.

Martin-Éric Racine (q-funk) wrote :

Bear in mind that dropping support for i586 also means that Ubuntu cannot install on the OLPC and that most thin client hardware meant for for LTSP won't be able to run on Ubuntu either, given how the chipsets used in thin client hardware tends to be i586-compatible. As such, I honestly think that if Ubuntu is serious about dropping support for i586, then a MUCH louder and formal announcement should be made NOW, well ahead of time, so that OLPC and LTSP users have enough time to consider other distributions to switch to.

Simon Huerlimann (huerlisi) wrote :

Well, we're exactly one of those companies having chosen to use Ubuntu LTSP with i586 compatible hardware (PC-Engines ALIX boards). Mmh, good that Martin-Éric did blog about this, now at least I know that we can't upgrade anymore...

Matthias Klose (doko) wrote :

> now at least I know that we can't upgrade anymore...

lucid and all lucid point release are unaffected by this.

Mario Limonciello (superm1) wrote :

it would probably be worthwhile to have update manager try to detect this scenario so ppl w/ boxes like this are not allowed to dist-upgrade past lucid (and break their boxes)

Alan Bell (alanbell) wrote :

Ubuntu doesn't install on the OLPC anyway. It runs a very hacked Fedora kernel. I really wouldn't worry about the hordes of Ubuntu running OLPC users. There is a Debian build that does run and there is an old version of Ubuntu based on the stock kernel. It is devices such as the Viglen MPC-L and thin client boxes that will be more of a concern, however pretty much everything new and low powered is based on the Atom chipset, and everything next year will be ARM (perhaps). Lucid is LTS so will be supported to 2013 so these platforms will have a supported Ubuntu system for several years to come. LTS releases don't offer to dist-upgrade to anything but the next LTS, so something might need to be done in the um. . . Quivering Quail cycle to stop them upgrading to a broken state. If anyone would like to help me get Lucid on my OLPC then you would get a big hug.

Martin-Éric Racine (q-funk) wrote :

Actually, the proper way to refuse to upgrade would be to follow what Debian did when they bumped the minimal platform requirement on SPARC. IIRC there was a preinst maintainer script segment that checked the machine type and exited dpkg with an error. Doing this would be the only totally foolproof method, since it cannot be assumed that someone will be using update-manager to upgrade. Instead they could very well use apt-get, aptitude other other tools, so foolproofing at the preinst level is the only truly safe option.

Colin Watson (cjwatson) wrote :

We should definitely have a preinst fragment here - it's only sane, and there's plenty of precedent for it.

Changed in eglibc (Ubuntu):
importance: Undecided → Medium
status: Won't Fix → Triaged
importance: Medium → High
Martin-Éric Racine (q-funk) wrote :

As discussed with the Ubuntu developers, it appears that this could be fixed by adding "-mtune=generic32" to the compiler defaults, to avoid generating code that includes the undocumented NOPL instruction. This would restore compatibility with at least some single-chip architectures such as recent Geode products whose instruction set is nearly 686-compatible.

Changed in gcc-4.4 (Ubuntu):
importance: Undecided → High
Changed in gcc-4.4 (Ubuntu):
status: New → Triaged

On 02.06.2010 18:21, Martin-Éric Racine wrote:
> As discussed with the Ubuntu developers, it appears that this could be
> fixed by adding "-mtune=generic32" to the compiler defaults,

that would be wrong. the correct fix is the one mentioned in
http://lkml.org/lkml/2008/9/8/296

Matthias Klose (doko) wrote :

fixed in 4.4.4-4ubuntu1

Changed in gcc-4.4 (Ubuntu):
status: Triaged → Fix Released
Martin-Éric Racine (q-funk) wrote :

Thanks for patching GCC. Anxiously awaiting for the rebuilt libc6 to test whether this does the trick.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eglibc - 2.12-0ubuntu3

---------------
eglibc (2.12-0ubuntu3) maverick; urgency=low

  * Merge with Debian (r4318, trunk).
  * Rebuild for i386. LP: #587186.
 -- Matthias Klose <email address hidden> Fri, 04 Jun 2010 14:32:19 +0200

Changed in eglibc (Ubuntu):
status: Triaged → Fix Released
Matthias Klose (doko) wrote :

fixed in gcc-4.5 4.5.0-5ubuntu1

Changed in gcc-4.5 (Ubuntu):
status: New → Fix Released
Martin-Éric Racine (q-funk) wrote :

I'm afraid that the patch selected by Mattias didn't fix it:

Preparing to replace libc6 2.11.1-0ubuntu9 (using .../libc6_2.12-0ubuntu3_i386.deb) ...
Checking for services that may need to be restarted...
Checking init scripts...
Unpacking replacement libc6 ...
dpkg: warning: subprocess old post-removal script killed by signal (Illegal instruction)
dpkg - trying script from the new package instead ...
dpkg: error processing /var/cache/apt/archives/libc6_2.12-0ubuntu3_i386.deb (--unpack):
 subprocess new post-removal script killed by signal (Illegal instruction)
dpkg: error while cleaning up:
 subprocess installed pre-installation script killed by signal (Illegal instruction)
Errors were encountered while processing:
 /var/cache/apt/archives/libc6_2.12-0ubuntu3_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Changed in eglibc (Ubuntu):
status: Fix Released → Triaged
Changed in gcc-4.4 (Ubuntu):
status: Fix Released → Triaged
Changed in gcc-4.5 (Ubuntu):
status: Fix Released → Triaged
Changed in gcc-4.5 (Ubuntu):
importance: Undecided → Medium
Changed in update-manager (Ubuntu):
importance: Undecided → Medium
Matthias Klose (doko) wrote :

Matin-Eic, did you verify that this is the same instruction?

Changed in eglibc (Ubuntu):
status: Triaged → Incomplete
Martin-Éric Racine (q-funk) wrote :

Can you please provide instructions for checking which instruction caused the error?

Martin-Éric Racine (q-funk) wrote :

As found by Fedora, the real issue is with GAS: https://bugzilla.redhat.com/show_bug.cgi?id=579838

Changed in binutils (Ubuntu):
importance: Undecided → High
Matthias Klose (doko) on 2010-06-14
Changed in binutils (Ubuntu):
status: New → Invalid
Changed in gcc-4.4 (Ubuntu):
status: Triaged → Invalid
Changed in gcc-4.5 (Ubuntu):
status: Triaged → Invalid
Martin-Éric Racine (q-funk) wrote :

Matthias, sorry, but in what way is this bug suddenly invalid?

Matthias Klose (doko) wrote :

the bug isn't closed, just kept the eglibc task open

Martin-Éric Racine (q-funk) wrote :

Noted. Is the bug still incomplete, then? If yes, can you please provide me with instructions on how to get a trace on a package being unpacked, in a situation when the package happens to be libc6, which affects the operation of everything else on top?

Matthias Klose (doko) wrote :

well, somehwat ;) there was a request to provide a list of packages which are required from your point of view to be runnable on this platform. Please could you open a separate bug report for this and reference it here?

Martin-Éric Racine (q-funk) wrote :

That's completely unrelated to this bug and besides the point. You had asked me to track down which instruction causes the illegal error and I asked for instructions on how to do that. I'm asking if, given the existing information on the FC bug, this still needs testing and, if yes, how.

Matthias Klose (doko) wrote :

On 14.06.2010 17:08, Martin-Éric Racine wrote:
> That's completely unrelated to this bug and besides the point.

No. we have more than option to resolve this issue. One of them is to ignore
the request and provide a PPA with packages explicitly optimized for i586 for a
project.

Changed in eglibc (Ubuntu):
status: Incomplete → Confirmed
Martin-Éric Racine (q-funk) wrote :

Then my answer has to be "everything" since I'm running a Geode host with a normal hard-disk and packages that occasionally get installed or removed as needed.

Martin-Éric Racine (q-funk) wrote :

GCC seems to offer -march=geode and -mtune=geode since GCC 4.3, so I'm wondering if using these in combination with i686 optimization might accomplish what we need?

Martin-Éric Racine (q-funk) wrote :

The "upstream" Fedora bug just saw an attachment added a few days ago. What it does is disable the -mtune options for i686 in libc6 build scripts.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eglibc - 2.12-0ubuntu4

---------------
eglibc (2.12-0ubuntu4) maverick; urgency=low

  * Update to the eglibc 2.12 branch (r10817).
    - patches/any/cvs-flush-cache-textrels.diff: Remove.
    - patches/any/cvs-redirect-throw.diff: Remove.
  * Merge with Debian (r4360, trunk, 2.11.2-2).
  * On i386, don't build with -Wa,-mtune=i686. LP: #587186.
 -- Matthias Klose <email address hidden> Mon, 28 Jun 2010 00:47:05 +0200

Changed in eglibc (Ubuntu):
status: Confirmed → Fix Released
Martin-Éric Racine (q-funk) wrote :

I confirm that eglibc 2.12-0ubuntu4 apparently fixes it. There is no more "Illegal instruction" error during upgrade.

Matthias Klose (doko) wrote :

On 28.06.2010 06:21, Martin-Éric Racine wrote:
> I confirm that eglibc 2.12-0ubuntu4 apparently fixes it. There is no
> more "Illegal instruction" error during upgrade.

just to note that while we may have this patch in maverick, it's no guarantee to
have it in later releases as well.

Martin-Éric Racine (q-funk) wrote :

Why wouldn't it be included?

Matthias Klose (doko) wrote :

now works with the Geode-LX. No need to fix it in the update-manager

Changed in update-manager (Ubuntu):
status: New → Won't Fix
Nick Lowe (n-lowe) wrote :

Is it worth revisting this as it can be optimised for i686 now and not fail?

https://bugzilla.redhat.com/show_bug.cgi?id=579838xx

Quentin Neill 2010-09-03 00:38:02 EDT
"FYI the Linux binutils 2.20.51.0.11 release contains a fix that no longer
generates the offending NOPs for i686.

2010/08/06 patch
   http://sourceware.org/ml/binutils-cvs/2010-08/msg00057.html
2010/08/11 release
   http://gcc.gnu.org/ml/gcc/2010-08/msg00194.html"

Martin-Éric Racine (q-funk) wrote :

Nick: thank you for this information.

Yes, it would be worth including those fixes into Maverick and trying to see if rebuilding the toolchain, then libc6 and the 686 kernel would provide something that remains usable on a Geode LX and, hopefully, also on a Geode GX2 (which, for marketing reasons, AMD calls a GX, even though it's a second-generation Geode whose design was bough as-is from NSC).

Nick Lowe (nick-int-r) wrote :

It should do!

The basic semantics for choosing the NOP sequence were completely wrong. This has been fixed now.
The NOPL instruction is not supported by all i686 processors, the coded assumption was that they did. This has been changed by the recent AMD patches so that it is not assumed and it's specified as an extension where it is supported.

Examples of such processors that would otherwise run i686 code are the AMD Geode LX, Via C3, Via Eden and Transmeta Crusoe.

The benefit of full i686 optimisation, which do have real performance implications, are things like bswap (useful in networking), cmpxchg/xadd (used in atomics) and cmov (useful in compiler generated code).

Nick Lowe (nick-int-r) on 2010-09-07
Changed in eglibc (Ubuntu):
status: Fix Released → Incomplete
Matthias Klose (doko) wrote :

please don't reopen bug reports without any comment. closing again. if you think that something is missing, then please point out the omission.

Changed in eglibc (Ubuntu):
status: Incomplete → Fix Released
Martin-Éric Racine (q-funk) wrote :

Mattias Klose: please don't close bug reports without reading the comments that were recently added and acting upon the new information.

Changed in eglibc (Ubuntu):
status: Fix Released → Incomplete
Matthias Klose (doko) wrote :

The issue "libc6 upgrade fails: illegal instruction" is fixed. I don't intend to change anything else for maverick.

Changed in eglibc (Ubuntu):
status: Incomplete → Fix Released
Nick Lowe (nick-int-r) wrote :

Why did you close the other bug report I opened then and linked to from here as being a duplicate of this?
The 'fix' you've committed is a workaround and doesn't fix the actual issue! Read above! :)

Matthias Klose (doko) wrote :

what exactly is missing in binutils?

Nick Lowe (nick-int-r) wrote :

Either this bug should be marked as incomplete as the present 'fix' is a workaround and not a resolution to the actual issue or the other bug I opened about a suboptimal fix being committed should be reopened? Which is it? :)

Nick Lowe (nick-int-r) wrote :

http://sourceware.org/ml/binutils-cvs/2010-08/msg00057.html
^- That - with the proper fix, you'll no longer get NOPLs emitted for generic i686 via binutils (GAS).

NOPL is not standard i686, it was undocumented and has just been de facto supported since the Pentium Pro.

The correct solution is surely to ensure that when something is compiled for generic i686, NOPL is nowhere to be seen...

Nick Lowe (nick-int-r) wrote :

Once the AMD patches that fix the bad semantics for NOPL and i686 in binutils have been applied, the build of eglibc should be changed to restore -Wa,-mtune=i686 :)

Martin-Éric Racine (q-funk) wrote :

Applying the above patches to binutils and rebuilding eglibc would not only allow removing the kludge that was applied to 2.12-0ubuntu4, it would also allow building i686 kernels that actually run on a Geode LX, on the Transmeta Crusoe and on a number of VIA products.

Nick Lowe (n-lowe) wrote :

The frustrating thing is that broken semantics for i686 have led to absurd patches such as the following being proposed as a workaround:

http://groups.google.com/group/linux.kernel/browse_thread/thread/c1ec68f5498236dc/617726bec31595ed?show_docid=617726bec31595ed

The point that gets missed there is that, abstractly, a NOP is meant to be exactly as it says on the tin, a No Operation.

It's meant to do nothing at all - for a predefined number of clock cycles.
A NOP is commonly used for timing purposes, that completely breaks that contract.

Again, NOPL is not standard i686 - it's an extension supported by the vast, vast majority of i686 class processors. If you're compiling generically for i686, you cannot assume that it is present.

Bad patches like the above to work around broken compilation cause more harm than good, plastering over the real problem.

Nick Lowe (n-lowe) wrote :

I've also had a brief look at the kernel.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/x86/Makefile_32.cpu;hb=HEAD

… special cases the GX1 to -march=pentium-mmx and the LX to -march=geode,-march=pentium-mmx.

There is also a special case for the bug in binutils we're disussing here that has just been fixed for !CONFIG_X86_P6_NOP where -mtune=generic32 is set.

And what about [x86: do not promote TM3x00/TM5x00 to i686-class] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a7ef94e6889186848573a10c5bdb8271405f44de - that patch is based on the bad assumption that i686 includes NOPL when it does not.

I haven't looked thoroughly, there might be more places!

Matthias Klose (doko) wrote :

> http://sourceware.org/ml/binutils-cvs/2010-08/msg00057.html

this is fixed in maverick. so, no bug report needed, and even if, then the bug should have been reported to the binutils package.

Nick Lowe (n-lowe) wrote :

Sorry, of course, my momentary slip up. And I hadn't checked the change log for binutils.

Are you going to restore proper i686 compilation to eglibc then?

Matthias Klose (doko) wrote :

On 07.09.2010 20:48, Nick Lowe wrote:
> Sorry, of course, my momentary slip up. And I hadn't checked the change
> log for binutils.
>
> Are you going to restore proper i686 compilation to eglibc then?

no, no time for testing. If you can build the packages, test them, publish them
so that other can confirm the fix, then yes. Else it has to wait for the next
release cycle.

Oloryn (oloryn) wrote :

I'm seeing the same error upgrading to Maverick on a machine with a K6-2/450 cpu. I'll agree with earlier comments that I wish that this change had been made much more clear, and the upgrade mechanism had been changed to abort the upgrade, as now it looks like I'll have to wipe and re-install this machine with Lucid.

Paul Sladen (sladen) wrote :

A user has just reported this on the ubuntu-users list; any chance we could get a fix into 'update-manager' to at least not hose people's previously working systems?

Martin-Éric Racine (q-funk) wrote :

As previously stated, the only correct place to prevent an upgrade from taking place is in libc6's preinst script.

Oloryn (oloryn) wrote :

Yeah, that user was me. I'm also wondering how this will affect Lubuntu, which is geared exactly towards these types of systems. I presume a 586-compatible version of libc would be needed for Lubuntu? If so, could we have some way of having that available for server installs (yes, there are some of us who still use these class machines as servers. They do fine for home network uses). I'm wondering if the Lubuntu people have already dealt with this, as I have a K6-2/500 desktop I had planned to move to Lubuntu, but now I'm wondering if the Maverick-level Lubuntu will even install.

Oloryn (oloryn) wrote :

I'm showing my ignorance of installation internals I guess, but will a libc6 preinst script that prevents an upgrade cause upgrade-manager to roll everything back to the previous release(i.e. it looks to me like by the time you've downloaded the upgrades so you can get to the preinst script, apt has been set to the new release - will the preinst 'failing' cause apt settings to be rolled back)?

Jeremy Visser (jeremy-visser) wrote :

Oloryn said:
> I'm showing my ignorance of installation internals I guess, but will a
> libc6 preinst script that prevents an upgrade cause upgrade-manager to
> roll everything back to the previous release?

Given that Ubuntu hasn't made a single release since 7.04 that hasn't
had major regressions on at least one of the PCs in my house (as of
10.10, there is this bug, as well as broken wireless on my laptop that
previously worked in 10.04) every release cycle, what makes you think
they would be smart enough to do that?

The quality control in Ubuntu is a joke. It really is.

Oloryn (oloryn) wrote :

Well, if the preinst script *doesn't* cause a roll-back, I'd have to question if a libc6 preinst script is the 'only correct' place to prevent an upgrade. You want to leave the machine in pretty much the same state as before do-release-upgrade was called, so that, e.g. the machine can at least continue to handle Lucid updates. Otherwise the machine is just about as borked.

Sergio Zanchetta (primes2h) wrote :

@Jeremy
Hello, if you want to give a hand feel free to join the testing team.
https://edge.launchpad.net/~ubuntu-testing

New testers are always welcome.:-)

Matthias Klose (doko) wrote :

On 14.10.2010 23:23, Jeremy Visser wrote:
> Oloryn said:
>> I'm showing my ignorance of installation internals I guess, but will a
>> libc6 preinst script that prevents an upgrade cause upgrade-manager to
>> roll everything back to the previous release?
>
> Given that Ubuntu hasn't made a single release since 7.04 that hasn't
> had major regressions on at least one of the PCs in my house (as of
> 10.10, there is this bug, as well as broken wireless on my laptop that
> previously worked in 10.04) every release cycle, what makes you think
> they would be smart enough to do that?
>
> The quality control in Ubuntu is a joke. It really is.

everybody should read the release notes before upgrading. See
https://wiki.ubuntu.com/MaverickMeerkat/ReleaseNotes

   "With 10.10 we have also dropped support for i586 and lower
    processors, as well as i686 processors without cmov support."

The notice is there. This is expected behaviour, not a regression.

Martin-Éric Racine (q-funk) wrote :

Mattias: The release notes are a piss-poor excuse for having shoved the i686 blueprint via the backdoor after a UDS hallway conversation and without properly polling the community at large BEFORE blueprinting it and implementing it. It is also a piss-poor excuse for not implementing safeguards in preinst, despite having been recommended to do so.

Michael Vogt (mvo) wrote :

I'm happy to add a update-manager check for this and SRU that, from what I understand its enough to check if "/proc/cpuinfo" has "cmov" in flags on i386 or is that not sufficient?

Accepted update-manager into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in update-manager (Ubuntu):
status: Won't Fix → Fix Committed
Changed in binutils (Ubuntu Maverick):
status: New → Invalid
Changed in eglibc (Ubuntu Maverick):
status: New → Invalid
Changed in gcc-4.4 (Ubuntu Maverick):
status: New → Invalid
Changed in update-manager (Ubuntu Maverick):
status: New → Fix Committed
tags: added: verification-needed
Changed in gcc-4.5 (Ubuntu Maverick):
status: New → Invalid
Michael Vogt (mvo) wrote :

Please remember that this fix needs to be tested with "update-manager --proposed" when doing a lucid -> maverick upgrade (or do-release-upgrade --proposed)

Steve Langasek (vorlon) wrote :

So this SRU is an update for the release upgrader that will used by update-manager when upgrading from lucid to maverick, correct? Could someone affected by this bug please do such a test, so that we can publish this SRU for the benefit of the other users?

Verification for Lucid

I've verified update-manager 1:0.142.21 in maverick-proposed and it failed for 2 reasons:
1. The function _test_and_fail_on_non_i686 is called in the wrong quirk handler (lucidPostInitialUpdate instead of maverickPostInitialUpdate)
2. in _test_and_fail_on_non_i686 the test self.arch == "i386" always fails because self.arch ends with a new line (output of dpkg --print-architecture). This is a bug in update-manager.

With those 2 fixes the upgrade is aborted as expected.

Marking as verification-failed.

tags: added: verification-failed
removed: verification-needed

On Wed, Nov 3, 2010 at 12:06 PM, Jean-Baptiste Lallement wrote:
> Verification for Lucid
>
> I've verified update-manager 1:0.142.21 in maverick-proposed and it failed for 2 reasons:
> 1. The function _test_and_fail_on_non_i686 is called in the wrong quirk handler (lucidPostInitialUpdate instead of maverickPostInitialUpdate)
> 2. in _test_and_fail_on_non_i686 the test self.arch == "i386" always fails because self.arch ends with a new line (output of dpkg --print-architecture). This is a bug in update-manager.
>
> With those 2 fixes the upgrade is aborted as expected.

It should be noted that upgrades from Lucid to LTS+1 also need to be handled.

Changed in update-manager (Ubuntu Maverick):
assignee: nobody → Michael Vogt (mvo)
status: Fix Committed → In Progress
Steve Langasek (vorlon) wrote :

ok, dropped update-manager 1:0.142.21 from maverick-proposed. Thanks for testing!

tags: removed: verification-failed
Michael Vogt (mvo) wrote :

Thanks a bunch Jean-Baptiste for your detailed testing! I fixed the bugs and upload a new version (that also fixes #631328).

Accepted update-manager into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in update-manager (Ubuntu Maverick):
status: In Progress → Fix Committed
tags: added: verification-needed
Mark Eichin (eichin-gmail) wrote :

Apparently this:

~$ cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 7
model name : VIA Samuel 2
stepping : 3
cpu MHz : 399.000
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow up
bogomips : 799.92
clflush size : 32
cache_alignment : 32
address sizes : 32 bits physical, 32 bits virtual
power management:

also somehow fits the description "i586 and lower processors, as well as i686 processors without cmov support"? Because I just tried to do-release-upgrade -d and got the

 subprocess new post-removal script killed by signal (Illegal instruction)
Exception during pm.DoInstall(): E:Sub-process /usr/bin/dpkg returned an error code (1)

failure. (The machine is a 2003-era "Martian Netdrive" which originally shipped as a Debian box, and makes a fine wireless printer+scanner server under Ubuntu, or did until just now...

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package update-manager - 1:0.142.22

---------------
update-manager (1:0.142.22) maverick-proposed; urgency=low

  [ Barry Warsaw ]
  * Add required details to .emit() call when running with
    synaptic as the backend (LP: #631328)

  [ Michael Vogt ]
  * DistUpgrade/DistUpgradeQuirks.py:
    - fixes in the cmov quirks handler (LP: #587186)
      (thanks to Jean-Baptiste Lallement)
 -- Michael Vogt <email address hidden> Fri, 12 Nov 2010 09:30:28 +0100

Changed in update-manager (Ubuntu Maverick):
status: Fix Committed → Fix Released
Michael Vogt (mvo) on 2011-04-12
Changed in update-manager (Ubuntu Natty):
assignee: nobody → Michael Vogt (mvo)
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related blueprints

Remote bug watches

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