karmic upgrade screwed mtab on reboot

[Antoine Martin]

Binary package hint: update-manager

Updated 2 machines to karmic via "update-manager -d"
After the successful upgrade (had to remove openoffice on one of the machines to make it happen),
I rebooted only to find the system unable to boot. It complained about mtab early on in the boot process, could not mount, etc..

Googled it a bit, mounted the filesystem from a live cd and simply deleted a bunch of files named "/etc/mtab*"
Then all went fine.

An inexperienced user would have no chance of solving that, ever.

Maybe, just move them out of the way after doing the upgrade?

[Michael Vogt (mvo)]

Thanks for your bugreport.

Did the same happen on both machines? Could you please attach the logs in /var/log/dist-upgrade/* to this bugreport? Do you happen to have the output of ls -l /etc/mtab or a memory if it was a file or a symlink?

[Antoine Martin (antoine-nagafix)]

Yes, the exact same thing happened on both machines.

I am pretty sure that /etc/mtab was a file and not a symlink. (no record unfortunately)

Attached are the logs you requested.

As a bonus, you can find the openoffice error in there:
"Exception during pm.DoInstall(): E:Couldn't configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle."

FYI: the 4am upgrade failed because the internet line goes down every night at 4am, got resumed later.

[Michael Vogt (mvo)]

Thanks for the logs, the openoffice.org pre-depends problem isfixed now.

The logs show the following problem:

Setting up linux-image-2.6.31-13-generic (2.6.31-13.44) ...^M
Running depmod.^M
update-initramfs: Generating /boot/initrd.img-2.6.31-13-generic^M
The link /initrd.img is a dangling linkto /boot/initrd.img-2.6.28-15-generic^M
The link /vmlinuz is a dangling linkto /boot/vmlinuz-2.6.28-15-generic^M
Running postinst hook script /sbin/update-grub.^M
Searching for GRUB installation directory ... found: /boot/grub^M
Searching for default file ... Generating /boot/grub/default file and setting the default boot entry to 0^M
Searching for GRUB installation directory ... found: /boot/grub^M
Testing for an existing GRUB menu.lst file ... ^M
^M
Could not find /boot/grub/menu.lst file. Would you like /boot/grub/menu.lst generated for you? (y/N) n^M
^M
Not creating /boot/grub/menu.lst as you wish^M
^M
User postinst hook script [/sbin/update-grub] exited with value 1^M
dpkg: error processing linux-image-2.6.31-13-generic (--configure):^M
 subprocess installed post-installation script returned error exit status 1^M

I suspect the actual problem is something with the grub configuration. How do you boot the system? It
appears that there is no menu.lst and no grub2 or lilo on the system.

[Antoine Martin (antoine-nagafix)]

Hah, my /boot partition is not mounted automatically, so I generally end up having to "dpkg --configure -a" after I mount it when there are failed kernel updates.

I don't think this is the cause of the problem though.
The second box has /boot always mounted and still had the same problem. Logs attached.

BTW, I had filed a bug about this with the update-manager but the bug report has vanished. I stand by my belief that the update manager (since it is running as root) should be clever enough to mount /boot if needed.
Just because this is not the way the "default" install sets up /boot, does not mean that good sysadmins won't end up doing just that.

I am quite unhappy to see that this bug report I made seems to have completely vanished, without addressing my comments.
Saying "we're not going to deal with this yet" is one thing, ignoring/dismissing valid arguments and hiding the discussion is another.

[Launchpad Janitor (janitor)]

[Expired for update-manager (Ubuntu) because there has been no activity for 60 days.]