Помилкова помилка диска: apt-get не може встановити чи видалити


24

Під час оновлення сервера Ubuntu 12.04 я зіткнувся з такою помилкою. Зараз apt-getне вдається встановити або видалити жоден пакет.

Розпакування linux-заголовків-3.13.0-62 (від ... / linux-headers-3.13.0-62_3.13.0-62.102 ~ preci1_all.deb) ...
dpkg: обробка помилок /var/cache/apt/archives/linux-headers-3.13.0-62_3.13.0-62.102~precise1_all.deb (--unpack):
 не вдається створити `/usr/src/linux-headers-3.13.0-62/arch/arm/include/asm/ptrace.h.dpkg-new ' 
(при обробці `./usr/src/linux-headers-3.13.0-62/arch/arm/include/asm/ptrace.h '): На пристрої 
не залишилось місця, не записано звіт про довідку, оскільки повідомлення про помилку вказує на диск повна помилка
 dpkg-deb: помилка: папка підпроцесуру була вбита сигналом (Зламана труба)
Помилки під час обробки:
 /var/cache/apt/archives/linux-headers-3.13.0-62_3.13.0-62.102~precise1_all.deb
E: Підпроцес / usr / bin / dpkg повернув код помилки (1)

Хоча мені й справді не вистачає місця на диску,

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       6.8G  4.7G  1.8G  69% /  

Як би там не було, мої вкладки повні

# df -i
Filesystem     Inodes   IUsed  IFree IUse% Mounted on
/dev/sda1      458752  455214   3538  100% /

У мене є більше десяти старих ядер, але я не в змозі їх видалити, оскільки мій apt-getсам кульгавий. Тому я не в змозі дотримуватися цієї публікації, яка повідомляє про подібну проблему.

Здається, єдиний варіант видалити кілька старих ядер вручну. Чи це спричинить якісь проблеми?

Чи є кращий вихід? Чи можу я заздалегідь використовувати зарезервований простір для root та видалити старіші ядра?


1
Дійсно, я вручну видалив пару старих ядер, /usr/srcщоб позбутися ситуації. На щастя, все пройшло добре і aptзнову почали працювати. Але я попрошу вас взяти назад, перш ніж робити таку річ на виробничій машині. Я зробив це на віртуальній машині, яка мала повне резервне копіювання.
souravc

Це працює! Я зробив те саме тут (ubutu 14.04.1), щоб оновити до ядра 4.4.0-51-generic. Я просто не впевнений, чи це спричинить якісь проблеми в майбутньому. Спасибі.
Морено

Відповіді:


36

Я знаю, що цей пост трохи старий, але я знайшов тут відповідь для всіх, хто може натрапити на цю публікацію: https://help.ubuntu.com/community/RemoveOldKernels

Якщо посилання розірвано, ось відповідний фрагмент:

Безпечне видалення старих ядер

Для користувачів систем LVM, зашифрованих систем або систем обмеженого зберігання найчастішою проблемою є те, що розділ / boot просто заповнений. Менеджер пакунків не може встановити очікуване оновлення через брак місця. Крім того, apt-get не може видалити пакунок через зламану залежність.

Цю проблему можна швидко та легко усунути з оболонки. Просто визначте одне або два старі ядра, які потрібно видалити вручну, що забезпечить менеджеру пакунків достатньо місця для встановлення оновлення в чергу.


$ sudo rm -rv ${TMPDIR:-/var/tmp}/mkinitramfs-*  
                                  ## In Ubuntu 16.04 and earlier there may be leftover temporary
                                  ## files to delete.
                                  ## See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814345

$ uname -r                        ## This command identifies the currently-running kernel
4.2.0-21-generic                  ## This is the current kernel.
                                  ## DO NOT REMOVE it!

$ dpkg -l | tail -n +6 | grep -E 'linux-image-[0-9]+' | grep -Fv $(uname -r)
                                  ## This command lists all the kernels excluding the booted
                                  ## kernel in the package database, and their status.
rc  linux-image-4.2.0-14-generic  ## The oldest kernel in the database
                                  ## Status 'rc' means it's already been removed
ii  linux-image-4.2.0-15-generic  ## The oldest installed kernel. Eligible for removal.
                                  ## Status 'ii' means Installed.
ii  linux-image-4.2.0-16-generic  ## Another old installed kernel. Eligible for removal
ii  linux-image-4.2.0-18-generic  ## Another old installed kernel. Eligible for removal
ii  linux-image-4.2.0-19-generic  ## The previous good kernel. Keep
iU  linux-image-4.2.0-22-generic  ## DO NOT REMOVE. Status 'iU' means it's not installed,
                                  ## but queued for install in apt.
                                  ## This is the package we want apt to install.

                                  ## Purge the oldest kernel package using dpkg instead of apt.
                                  ## First you need to remove the image initrd.img file manually
                                  ## due to Bug #1678187.
$ sudo update-initramfs -d -k 4.2.0-15-generic
$ sudo dpkg --purge linux-image-4.2.0-15-generic linux-image-extra-4.2.0-15-generic
                                  ## If the previous command fails, some installed package
                                  ## depends on the kernel. The output of dpkg tells the name
                                  ## of the package. Purge it first.

                                  ## Also purge the respective header package.
$ sudo dpkg --purge linux-headers-4.2.0-15-generic
                                  ## Try also purging the common header package.
$ sudo dpkg --purge linux-headers-4.2.0-15
                                  ## Do not worry, if the previous command fails.

$ sudo apt-get -f install         ## Try to fix the broken dependency.

Я слідував за цим із:

sudo apt-get autoremove --purge

9

Зараз я знайшов вихід із ситуації і видалив пару старих ядер, /usr/srcщоб позбутися ситуації. На щастя, все пішло добре, і вдалий почав працювати знову.

Настійно рекомендується зробити резервну копію перед видаленням старих ядер на виробничій машині.


Будь-яке краще рішення все ж вітається. Я публікую цей коментар як відповідь, оскільки він може комусь допомогти.
souravc

1
Після видалення старих ядер і запуску apt-get autoremove та встановлення деяких apt-get -f installпроблем виправили мої проблеми
Thamaraiselvam

ДЯКУЮ ТОБІ. Я видалив усе linux- * under, /bootале не користувався, dkpgтому *-headerфайли все ще були у/usr/src
Ділан Пірс,
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.