корневые файловые системы ext3 идут только для чтения с прерванным журналом даже после восстановлений
"ii" и "ООН" являются состоянием пакета. Первая буква означает действие, что должно быть сделано к этому пакету, ("i" установка, "u" удаляют), вторым является текущий статус ("i": установленный, "n": не установленный). Посмотрите dpkg-query страница справочника для получения дополнительной информации.
Таким образом, у Вас есть 2 установленные ядра (linux-image-2.6.32-5-486 и его метапакет linux-image-2.6-486 и linux-image-2.6.30-vortex86mx-apm).
Если Ваше текущее ядро работает без каких-либо проблем, безопасно удалить другой. Но в некоторых ситуациях это практично, чтобы иметь резервное ядро.
Обычно Вы хотите, также удаляют также любой конфигурационный файл, который связан с пакетами, так использование apt-get purge <packagename> или apt-get --purge remove <packagename>.
В этой точке я думаю, что это вероятно экземпляр Ошибки Debian 637234. Поскольку это - облачный VM, ядро гипервизора за пределами моего управления. Обходное решение использует barrier=0 в /etc/fstab для корневой файловой системы. Долгосрочная фиксация должна восстановить поле как rackspace облачный экземпляр следующего поколения вместо первого генерала находящийся в Xen экземпляр.
"barrier=0" в/etc/fstab является propably слишком поздним (и просто играет роль после того, как файловые системы смонтированы RW на более позднем этапе начальной загрузки).
"barrier=off" как дополнительный параметр ядра должен работать ранее и лучше.
Попробуйте. Если Ваш DomU запускается pygrub с Dom0 (который является "обычным" путем), можно поместить это в grub-kernel-konfiguration-line в DomU.