hardy2lucid: hwcap index 0 already defined

[Scott Moser]

I tried do-release-upgrade on hardy ec2 in us-east-1
- ami-59b35f30 ubuntu-hardy-8.04-i386-server-20100128

That resulted in:
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
/sbin/ldconfig.real: /etc/ld.so.conf.d/xen.conf:6: hwcap index 0 already defined as nosegneg
dpkg: subprocess installed post-installation script returned error exit status 1
Exception during pm.DoInstall(): E:Sub-process /usr/bin/dpkg returned an error code (2)

Could not install the upgrades

The upgrade is now aborted. Your system could be in an unusable
state. A recovery will run now (dpkg --configure -a).

[Scott Moser (smoser)]

I found 2 things:
a.) after installation/upgrade 'sudo /sbin/ldconfig' will show the problem
b.) /etc/ld.so.conf.d/libc6-xen.conf has
hwcap 0 nosegneg

  That should be 'hwcap 1 nosegneg', as is duplicated in
/etc/ld.so.conf.d/xen.conf . My guess is that libc6-xen.conf is written by the automated ec2 build, or some other non-package-managed mechanism.

[Scott Moser (smoser)]

The source of /etc/ld.so.conf.d/libc6-xen.conf is vmbuilder:

$ cat VMBuilder/plugins/ubuntu/templates/xen-ld-so-conf.tmpl
hwcap 0 nosegneg

Then, in ./VMBuilder/plugins/ubuntu/hardy.py
def install_ec2(self):
   ...
   if self.context.arch == 'i386':
      self.install_from_template('/etc/ld.so.conf.d/libc6-xen.conf', 'xen-ld-so-conf')

That code will only run on hardy vmbuilder builds (not intrepid or later), and is only an issue when release-upgrading from an image built by vmbuilder.

I don't see anything obvious in bzr history as to why this was added (came in revno: 306.1.10 , with comment "Move suite specific ec2 stuff to ubuntu/plugins/*", but it doesn't seem like it was moved from anywhere).

[Scott Moser (smoser)]

My guess is that vmbuilder is writing 'hwcap 0 nosegneg' is written by vmbuilder because of bug 246625 and other similar/duplicate bugs there. However, as far as I can tell there is no affect of writing that file other than that it breaks the upgrade as I reported here.

Ie:

$ sudo rm /etc/ld.so.conf.d/libc6-xen.conf
$ sudo /sbin/ldconfig
$ sudo reboot
...
$ sudo do-release-upgrade -d

The reboot are just to show a generally functional system after removal of that file (also shown by the ablility to do-release-upgrade).

The do-release-upgrade finished successfully. A reboot of the system is a bad idea, though on ec2 as the old kernel simply isn't going to work for upstart/mountall/udev of lucid.

[Scott Moser (smoser)]

Marking 'Invalid' for glibc right now. glibc didn't write the problematic file. We could potentiall fix it there, though with a work around.

[Soren Hansen (soren)]

VMBuilder may have put it there, but a user could have also done taht on his own. I don't see any reason why this should fail. glibc should handle this case gracefully.