kernel update issues on ubu 14.04

[hamish]

Hi,

just a placeholder ticket.

apt-get upgrade fails with

Failed to symbolic-link boot/initrd.img-3.13.0-24-generic to
 initrd.img:File exists at
 /var/lib/dpkg/info/linux-image-3.13.0-24-generic.postinst
 line 629.

leaving dpkg in a broken state. you can still install packages but apt-get always exits with a failure code.

upstream ticket:

​https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1317602

Hamish

[hamish]

Replying to hamish:

leaving dpkg in a broken state. you can still install packages but apt-get always exits with a failure code.

upstream ticket:

​https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1317602

Hi,

nothing new to report here as no activity in the upstream ticket, just to note that this has ground our production to a halt.

Hamish

[hamish]

the latest thing in build 445 is libpam-systemd having issues.

one the resulting (broken) iso, 'apt-get -f install' + 'apt-get upgrade' gets past that one after redownloading it, but the kernel issue remains.

but then the problem (when booting from the iso) is:

update-initramfs is disabled since running on read-only media

maybe we should try 'update-initramfs -c' or 'update-initramfs -u' at the start of the setup.sh script to try and get the initrd.img built in /boot?

Hamish

[hamish]

good news in the latest build log (r11451): running update-initramfs manually at the start of setup.sh will get around the broken initrd.img symlink.

there's still a problem with libpam-systemd, will have to download the iso and explore. In the last iso a simple 'apt-get -f install', 'apt-get update' and 'apt-get upgrade' made it better. Maybe systemd-services needs to update first but the hard version dependency is missing?

Preparing to unpack .../libpam-systemd_204-5ubuntu20.2_i386.deb ...
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
dpkg: warning: subprocess old pre-removal script returned error exit status 100
dpkg: trying script from the new package instead ...
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
dpkg: error processing archive /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb (--unpack):
 subprocess new pre-removal script returned error exit status 100
/bin/df: no file systems processed
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 100

Hamish

[hamish]

re. libpam-systemd & resolv.conf issues, see discussion here between NikTh and pitti:

​http://irclogs.ubuntu.com/2014/04/23/%23ubuntu-devel.html

maybe the two are related..

I suggest someone look for them on #ubuntu-devel and see if they found a solution, while it's still fresh. our nightly iso the the best debugging tool an upstream author who can't reproduce the problem could have!

g'nite, Hamish

[hamish]

work-around for the libpam-systemd package install-order breakage issue committed in r11452, which hopefully puts us back in business build-wise. (simply band-aids, I suspect it's up to ubuntu to fix the root cause).

Hamish

[kalxas]

The build process now asks for confirmation at some point.

[hamish]

Replying to kalxas:

The build process now asks for confirmation at some point.

(fixed by kalxas in r11454)

but it's still not fixed, there seems to be a dependency loop between systemd-services and libpam-systemd, where systemd-services needs to be installed first, but libpam-systemd is a dependency so insists on going first, but depends on systemd-services.

may need to force systemd-services to go first, but will experiment a bit in the VM.

Hamish

[hamish]

If r11459 doesn't fix the libpam-systemd trouble we're going to have to edit the prerm script with sed to bypass the error. Luckily it's a trivial stop service. Same commands seem ok from within the iso, so maybe a chroot state issue.

Hamish

[hamish]

ok, 'apt-get -f install' didn't help. let's try again with r11460 forcing the problematic pre-rm script to exit with success.

filed in launchpad with additional details as

​https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142

Hamish

[kalxas]

The new build seems to complete fine

[hamish]

Hi, the new build is better, but not yet all the way working. At least now it's just the one package that's uninstallable instead of the entire dpkg system being broken.

A number of scripts check to see that apt-get finished with a successful error code, so those ones bail out early due to the uninstalled package.

For libpam-systemd (,systemd logind service) I'll try a similar adjustment to the post-install script as I did for the pre-remove script to make the script's error into just a warning message (r11463). Interesting that the last step of the libpam-systemd post-install script is to forcibly remove the logind service (which is what it's complaining about not being able to find).

try try again :-), Hamish

[hamish]

I hesitate to call this "fixed" as the two upstream bugs remain in ubuntu and we've simply worked around them, but as of the r11465 build I'm happy to report that we are finally back in business and building a full iso again. To be seen if USB boots, etc.

cheers, Hamish

[hamish]

Now whoopsie is failing with the same missing init.d script bug. launchpad ticket notified and package unceremoniously dropped from our disc in r11517.

Hamish

[kalxas]

Unfortunately whoopsie is still not behaving right after 14.04.1 release. The patch remains for now...

[hamish]

Replying to kalxas:

Unfortunately whoopsie is still not behaving right after 14.04.1 release. The patch remains for now...

you mean it would not cleanly remove? the libpam-systemd stuff is unrelated and could stay commented out AFAIK, it's just the sed patch to whoopsie.prerm on lines 85-86 that would need to be reenabled in that case.

thanks, Hamish

[kalxas]

I reverted the comments and it is now building fine again.