LINUX.ORG.RU

При обновлении: No space left on device

 , ,


0

1

Друзья,

Использую на серверной машинке, установленно в образной Тьму-Таракани вот такую Ubuntu:

Linux version 3.13.0-59-generic (buildd@lgw01-43) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #98-Ubuntu SMP Fri Jul 24 21:05:26 UTC 2015

Машинка живет в полуавтономном режиме и подглючена к Интернет. Иногда она обновляется через WebMin, но в один прекрастный летний день обновляться перестала.

Полез разбраться, оказалось, что выдает вот, что:

root@J1800:/# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  linux-image-extra-3.13.0-52-generic
The following packages will be upgraded:
  apport bash-completion binutils bsdutils irqbalance libblkid1 libcomerr2
  libfreetype6 libldap-2.4-2 libmount1 libnss-winbind libpam-smbpass
  libpam-winbind libsmbclient libss2 libuuid1 libwbclient0 mount python-samba
  python3-apport python3-problem-report samba samba-common samba-common-bin
  samba-doc samba-dsdb-modules samba-libs samba-vfs-modules smbclient sudo
  uuid-runtime winbind
32 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
5 not fully installed or removed.
Need to get 0 B/11.6 MB of archives.
After this operation, 152 MB disk space will be freed.
Do you want to continue? [Y/n]
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 323433 files and directories currently installed.)
Removing linux-image-extra-3.13.0-52-generic (3.13.0-52.86) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.13.0-52-generic /boot/vmlinuz-3.13.0-52-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.13.0-52-generic /boot/vmlinuz-3.13.0-52-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-52-generic

gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-3.13.0-52-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-extra-3.13.0-52-generic (--remove):
 subprocess installed post-removal script returned error exit status 1
Errors were encountered while processing:
 linux-image-extra-3.13.0-52-generic
E: Sub-process /usr/bin/dpkg returned an error code (1)

Соответственно и вполне разумно, что ничего не обновляется. Наиболее подозрительным пунктом мне тут какжется строка «gzip: stdout: No space left on device».

Пробовал делать autoremove и прочие -f => результат все тот же одинаковый - ошибка - места нет.

Попробовал посмотреть, что у нас с местом в /boot:

root@J1800:/home/vlad# df
Filesystem                 1K-blocks      Used Available Use% Mounted on
/dev/mapper/J1800--vg-root 957052572 189570480 718843528  21% /
none                               4         0         4   0% /sys/fs/cgroup
udev                         1958744        12   1958732   1% /dev
tmpfs                         394000      1144    392856   1% /run
none                            5120         0      5120   0% /run/lock
none                         1969988      2464   1967524   1% /run/shm
none                          102400         0    102400   0% /run/user
/dev/sda1                     240972    237298         0 100% /boot
root@J1800:/home/vlad# df -h
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/J1800--vg-root  913G  181G  686G  21% /
none                        4.0K     0  4.0K   0% /sys/fs/cgroup
udev                        1.9G   12K  1.9G   1% /dev
tmpfs                       385M  1.2M  384M   1% /run
none                        5.0M     0  5.0M   0% /run/lock
none                        1.9G  2.5M  1.9G   1% /run/shm
none                        100M     0  100M   0% /run/user
/dev/sda1                   236M  232M     0 100% /boot
root@J1800:/home/vlad# df -i
Filesystem                   Inodes  IUsed    IFree IUse% Mounted on
/dev/mapper/J1800--vg-root 60784640 354106 60430534    1% /
none                         492497      2   492495    1% /sys/fs/cgroup
udev                         489686    435   489251    1% /dev
tmpfs                        492497    411   492086    1% /run
none                         492497      3   492494    1% /run/lock
none                         492497     10   492487    1% /run/shm
none                         492497      2   492495    1% /run/user
/dev/sda1                     62248    338    61910    1% /boot

Видим что на физическом разделе /dev/sda1 есть логический раздел /boot и какими-то неведомыми силами она весь чем-то засран.

Посмотрел, что лежит в boot:

root@J1800:/boot# ls -l
total 228404
-rw-r--r-- 1 root root  1164671 May  4 08:09 abi-3.13.0-52-generic
-rw-r--r-- 1 root root  1164671 May 20 14:11 abi-3.13.0-53-generic
-rw-r--r-- 1 root root  1164806 May 26 23:11 abi-3.13.0-54-generic
-rw-r--r-- 1 root root  1164806 Jun 18 04:03 abi-3.13.0-55-generic
-rw-r--r-- 1 root root  1164984 Jun 19 13:04 abi-3.13.0-57-generic
-rw-r--r-- 1 root root  1165129 Jul  8 06:53 abi-3.13.0-58-generic
-rw-r--r-- 1 root root  1165129 Jul 25 01:19 abi-3.13.0-59-generic
-rw-r--r-- 1 root root  1165204 Aug 15 02:07 abi-3.13.0-63-generic
-rw-r--r-- 1 root root   165762 May  4 08:09 config-3.13.0-52-generic
-rw-r--r-- 1 root root   165762 May 20 14:11 config-3.13.0-53-generic
-rw-r--r-- 1 root root   165762 May 26 23:11 config-3.13.0-54-generic
-rw-r--r-- 1 root root   165762 Jun 18 04:03 config-3.13.0-55-generic
-rw-r--r-- 1 root root   165762 Jun 19 13:04 config-3.13.0-57-generic
-rw-r--r-- 1 root root   165762 Jul  8 06:53 config-3.13.0-58-generic
-rw-r--r-- 1 root root   165762 Jul 25 01:19 config-3.13.0-59-generic
-rw-r--r-- 1 root root   165763 Aug 15 02:07 config-3.13.0-63-generic
drwxr-xr-x 5 root root     1024 Sep 18 11:10 grub
-rw-r--r-- 1 root root 20151135 May  7 05:56 initrd.img-3.13.0-52-generic
-rw-r--r-- 1 root root 20154124 May 30 17:40 initrd.img-3.13.0-53-generic
-rw-r--r-- 1 root root 20154748 Jun 11 05:44 initrd.img-3.13.0-54-generic
-rw-r--r-- 1 root root 20156536 Jun 20 05:49 initrd.img-3.13.0-55-generic
-rw-r--r-- 1 root root 20152690 Jul  7 06:00 initrd.img-3.13.0-57-generic
-rw-r--r-- 1 root root 20156341 Jul 23 05:34 initrd.img-3.13.0-58-generic
-rw-r--r-- 1 root root 20153936 Jul 28 05:33 initrd.img-3.13.0-59-generic
-rw-r--r-- 1 root root  3466709 Sep 18 11:10 initrd.img-3.13.0-61-generic
-rw-r--r-- 1 root root  3466390 Sep 18 11:10 initrd.img-3.13.0-62-generic
drwx------ 2 root root    12288 Mar 20 09:42 lost+found
-rw-r--r-- 1 root root   176500 Mar 12  2014 memtest86+.bin
-rw-r--r-- 1 root root   178176 Mar 12  2014 memtest86+.elf
-rw-r--r-- 1 root root   178680 Mar 12  2014 memtest86+_multiboot.bin
-rw------- 1 root root  3389875 May  4 08:09 System.map-3.13.0-52-generic
-rw------- 1 root root  3390132 May 20 14:11 System.map-3.13.0-53-generic
-rw------- 1 root root  3390881 May 26 23:11 System.map-3.13.0-54-generic
-rw------- 1 root root  3390881 Jun 18 04:03 System.map-3.13.0-55-generic
-rw------- 1 root root  3391581 Jun 19 13:04 System.map-3.13.0-57-generic
-rw------- 1 root root  3391763 Jul  8 06:53 System.map-3.13.0-58-generic
-rw------- 1 root root  3391616 Jul 25 01:19 System.map-3.13.0-59-generic
-rw------- 1 root root  3392068 Aug 15 02:07 System.map-3.13.0-63-generic
-rw------- 1 root root  5818592 May  4 08:09 vmlinuz-3.13.0-52-generic
-rw------- 1 root root  5821152 May 20 14:11 vmlinuz-3.13.0-53-generic
-rw------- 1 root root  5821664 May 26 23:11 vmlinuz-3.13.0-54-generic
-rw------- 1 root root  5821984 Jun 18 04:03 vmlinuz-3.13.0-55-generic
-rw------- 1 root root  5820800 Jun 19 13:04 vmlinuz-3.13.0-57-generic
-rw------- 1 root root  5823136 Jul  8 06:53 vmlinuz-3.13.0-58-generic
-rw------- 1 root root  5822880 Jul 25 01:19 vmlinuz-3.13.0-59-generic
-rw------- 1 root root  5821152 Aug 15 02:07 vmlinuz-3.13.0-63-generic

Как я понимаю именно этими файлами все и загажено.

Пробую в ручном режиме (ибо autoremove не помогает) почикать лишнее, примерно вот так:

root@J1800:/boot# dpkg --remove linux-image-3.13.0-52-generic
(Reading database ... 323433 files and directories currently installed.)
Removing linux-image-3.13.0-52-generic (3.13.0-52.86) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.13.0-52-generic /boot/vmlinuz-3.13.0-52-generic
update-initramfs: Deleting /boot/initrd.img-3.13.0-52-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.13.0-52-generic /boot/vmlinuz-3.13.0-52-generic
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-3.13.0-63-generic
Found linux image: /boot/vmlinuz-3.13.0-59-generic
Found initrd image: /boot/initrd.img-3.13.0-59-generic
Found linux image: /boot/vmlinuz-3.13.0-58-generic
Found initrd image: /boot/initrd.img-3.13.0-58-generic
Found linux image: /boot/vmlinuz-3.13.0-57-generic
Found initrd image: /boot/initrd.img-3.13.0-57-generic
Found linux image: /boot/vmlinuz-3.13.0-55-generic
Found initrd image: /boot/initrd.img-3.13.0-55-generic
Found linux image: /boot/vmlinuz-3.13.0-54-generic
Found initrd image: /boot/initrd.img-3.13.0-54-generic
Found linux image: /boot/vmlinuz-3.13.0-53-generic
Found initrd image: /boot/initrd.img-3.13.0-53-generic
Found memtest86+ image: /memtest86+.elf
Found memtest86+ image: /memtest86+.bin
done
The link /initrd.img is a damaged link
Removing symbolic link initrd.img
 you may need to re-run your boot loader[grub]
The link /initrd.img.old is a damaged link
Removing symbolic link initrd.img.old
 you may need to re-run your boot loader[grub]

Но как-то не помогает.

Диск разбит при помощи LVM.

lvm> lvscan
  ACTIVE            '/dev/J1800-vg/root' [927.39 GiB] inherit
  ACTIVE            '/dev/J1800-vg/swap_1' [3.83 GiB] inherit
lvm> lvs
  LV     VG       Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert
  root   J1800-vg -wi-ao--- 927.39g
  swap_1 J1800-vg -wi-ao---   3.83g
lvm> pvs
  PV         VG       Fmt  Attr PSize   PFree
  /dev/sda5  J1800-vg lvm2 a--  931.27g 44.00m
lvm> pvscan
  PV /dev/sda5   VG J1800-vg   lvm2 [931.27 GiB / 44.00 MiB free]
  Total: 1 [931.27 GiB] / in use: 1 [931.27 GiB] / in no VG: 0 [0   ]

Что делать дальше не понятно.... Буду рад полезным мыслям.

Ответ на: комментарий от roman77

Удали вручную старые ядра в boot, потом через apt-get пакеты удали.

Перед столь опасной, на мой взгляд, операцией, лучше уточню: Т.е. замочить руками все файлы в корне /boot в которых нет 3.13.59 (номер актуальной установленной версии)?

kvv213 ()
Ответ на: комментарий от roman77

Грохнул, осталось:

root@J1800:/boot# ls -l
total 30643
-rw-r--r-- 1 root root  1165129 Jul 25 01:19 abi-3.13.0-59-generic
-rw-r--r-- 1 root root   165762 Jul 25 01:19 config-3.13.0-59-generic
drwxr-xr-x 5 root root     1024 Sep 18 11:47 grub
-rw-r--r-- 1 root root 20153936 Jul 28 05:33 initrd.img-3.13.0-59-generic
drwx------ 2 root root    12288 Mar 20 09:42 lost+found
-rw-r--r-- 1 root root   176500 Mar 12  2014 memtest86+.bin
-rw-r--r-- 1 root root   178176 Mar 12  2014 memtest86+.elf
-rw-r--r-- 1 root root   178680 Mar 12  2014 memtest86+_multiboot.bin
-rw------- 1 root root  3391616 Jul 25 01:19 System.map-3.13.0-59-generic
-rw------- 1 root root  5822880 Jul 25 01:19 vmlinuz-3.13.0-59-generic

Вродебы место появилось:

root@J1800:/boot# df -a -T
Filesystem                 Type       1K-blocks      Used Available Use% Mounted on
/dev/mapper/J1800--vg-root ext4       957052572 189241384 719172624  21% /
proc                       proc               0         0         0    - /proc
sysfs                      sysfs              0         0         0    - /sys
none                       tmpfs              4         0         4   0% /sys/fs/cgroup
none                       fusectl            0         0         0    - /sys/fs/fuse/connections
none                       debugfs            0         0         0    - /sys/kernel/debug
none                       securityfs         0         0         0    - /sys/kernel/security
udev                       devtmpfs     1958744         4   1958740   1% /dev
devpts                     devpts             0         0         0    - /dev/pts
tmpfs                      tmpfs         394000      1012    392988   1% /run
none                       tmpfs           5120         0      5120   0% /run/lock
none                       tmpfs        1969984      3552   1966432   1% /run/shm
none                       tmpfs         102400         0    102400   0% /run/user
none                       pstore             0         0         0    - /sys/fs/pstore
systemd                    cgroup             0         0         0    - /sys/fs/cgroup/systemd
/dev/sda1                  ext2          240972     39535    188996  18% /boot

Сейчас попробую перезагрузиться и установить обновления.

kvv213 ()
Ответ на: комментарий от roman77

Физический доступ к машине есть?

Часа за полтора его смогу получить - открутить ее от туда где она стоит, приволочь туда, где есть клавиатура и монитор.

kvv213 ()
Ответ на: комментарий от roman77

Снял, подключил.

Загружается сразу в GRUB. Там версию ядра не пишет. Однако если перейти в Advanced Options, то там верхняя версия 3.13.0-63-Generic

kvv213 ()
Ответ на: комментарий от NightOperator

Да, именно так и сделал. Загрузился в 59-ю, потом подключился к сети, проапдейтился до 63-й. Теперь все работает. Спасибо.

Но вопрос остается открытым - почему так boot загадилс старыми версиями? И ведь не удалялись же.

kvv213 ()
Ответ на: комментарий от kvv213

почему так boot загадилс старыми версиями?

Так Ubuntu устроена. Ни разу не видел, чтобы она при обновлении удаляла старые ядра. Видимо, никто не расчитывал на отдельный /boot.

i-rinat ★★★★★ ()
Ответ на: комментарий от kvv213

И еще странно. При загрузке показывается 59-ю версию. А в GRUB мне не давало загрузиться в 63-ю....

kvv213 ()
Ответ на: комментарий от kvv213

Стоит метапакет linux-image-amd64 (или что-то в этом роде). Он и ставит свежие версии ядер, и старые остаются на диске. Как уже сказали, на отдельный boot расчета не было.

Удали данный метапакет, и ставь нудные версии ядер руками.

roman77 ★★★★★ ()
Ответ на: комментарий от kvv213
apt-cache show  linux-image-generic-lts-trusty
Package: linux-image-generic-lts-trusty
Priority: optional
Section: metapackages
Installed-Size: 29
Maintainer: Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>
Architecture: amd64
Source: linux-meta-lts-trusty
Version: 3.13.0.63.55
Depends: linux-image-3.13.0-63-generic, linux-firmware
Filename: pool/main/l/linux-meta-lts-trusty/linux-image-generic-lts-trusty_3.13.0.63.55_amd64.deb
Size: 2384
MD5sum: 85854481ed79f824544d32248fae64a1
SHA1: bcc70f82b5e397ad9ad040d4c2386d0acc61db80
SHA256: 2ac9ca62c2eafe2d67815617110a7ea3c9427acf9fd52efdd553599c5b8d19fe
Description-en: Generic Linux kernel image
 This metapackage will always depend on the latest generic 14.04 LTS kernel image
 available.
Description-md5: a59b2056a0cda868e3c80db36a984e71
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Supported: 18m

Ну из Description, думаю понятно в чем суть.

Если бы ты был достаточно внимательным и при очередном запуске apt-get upgrade /dist-upgrade/install/remove посмотрел на вывод, то увидел бы список пакетов, которые были поставлены по зависимостям и более не требуются, так как нет более зависимостей от них и их дескать можно удалить, среди них были и твои старые ядра.

Это всегда можно сделать либо вручную либо с помощью apt-get autoremove.

Ip0 ★★★★ ()
Ответ на: комментарий от roman77

Удали данный метапакет, и ставь нудные версии ядер руками.

Не думаю, что пользователю, который сталкивается с обозначенными в топике проблемами, это полезный совет и он знает о «нужных» ему версиях:)

Ip0 ★★★★ ()
Ответ на: комментарий от i-rinat

почему так boot загадилс старыми версиями?

Так Ubuntu устроена.

а зачем удалять старую версию. Если с новой беда на железе - у тебя есть шанс грузить со старой.

Удалять надо не руками

aptitude search '~i linux-image'

uname -a

и лишние через aptitude remove

anonymous ()
Ответ на: комментарий от anonymous

а зачем удалять старую версию. Если с новой беда на железе - у тебя есть шанс грузить со старой.

Достаточно сохранять 1-2 предыдущие версии.

anonymous ()
Ответ на: комментарий от anonymous

Совершенно верно, достаточно сохранять одну-две предыдущие заведомо рабочие версии ядра.

lucentcode ★★★★★ ()

А потом надо мной смеются когда я даю разделу под /boot «цельный гиг!!!111». Хаха, это же так смешно.

targitaj ★★★★★ ()
Ответ на: комментарий от i-rinat

так ubuntu всегда после обновления ядра пишет что старые версии больше не требуются и предлагает сделать apt-get autoremove. Остаются только текущая и предыдущая версии

tm4ig ()
Ответ на: комментарий от tm4ig

Вполне возможно. Если у меня установка Ubuntu живёт достаточно долго, я обычно перехожу от штатного обновлятора к использованию aptitude. Вот ядра и копятся.

i-rinat ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.