Error writing to output file write 28 no space left on device

Не удалось загрузить Ошибка записи в выходной файл - write (28 No space left on device) [IP: 77.88.19.68 80] Не удалось загрузить Неверный заголовок [IP: 77.88.19.68 80] Не удалось загрузить Неверный заголовок [IP: 77.88.19.68 80] Не удалось загрузить Ошибка записи в выходной файл - write (28 No space left on device) [IP: 77.88.19.74 80] Не удалось загрузить Ошибка записи в выходной файл - write (28 No space left on device) [IP: 77.88.19.74 80] Не удалось загрузить Время ожидания для соединения истекло [IP: 77.88.19.74 80] Не удалось загрузить Ошибка записи в выходной файл - write (28 No space left on device) [IP: 87.250.239.69 80] Не удалось загрузить Время ожидания для соединения истекло [IP: 87.250.239.69 80] Не удалось загрузить Ошибка записи в выходной файл - write (28 No space left on device) [IP: 77.88.19.68 80] Не удалось загрузить Ошибка записи в выходной файл - write (28 No space left on device) [IP: 77.88.19.68 80] Не удалось загрузить Ошибка записи в выходной файл - write (28 No space left on device) [IP: 77.88.19.68 80] Не удалось загрузить Ошибка записи в выходной файл - write (28 No space left on device) [IP: 77.88.19.68 80] Не удалось загрузить Ошибка записи в выходной файл - write (28 No space left on device) [IP: 77.88.19.68 80] Некоторые индексные файлы не загрузились, они были проигнорированы или вместо них были использованы старые версии
  • Печать

Страницы: [1]   Вниз

Тема: проблемы при загрузке обновлений  (Прочитано 3850 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн
ferrari


Оффлайн
gantellus

можно попробовать сменить сервер

Придумайте ещё более дружественный интерфейс, и мир породит ещё более тупого юзера (с)
С2Duo 2.4 Ghz, Geforce 8800, Maya 44 PCI


Оффлайн
ferrari

я так понял, что проблема в моём компе, а не в серваке, так как раньше (два дня назад) всё обновлялось

вот что мне выдал менеджер обновлений
E: dpkg was interrupted, you must manually run ‘dpkg —configure -a’ to correct the problem.
E: _cache->open() failed, please report.


Оффлайн
satch

я так понял, что проблема в моём компе, а не в серваке, так как раньше (два дня назад) всё обновлялось

вот что мне выдал менеджер обновлений
E: dpkg was interrupted, you must manually run ‘dpkg —configure -a’ to correct the problem.
E: _cache->open() failed, please report.

у меня тоже такое было :( … после dpkg —configure -a все повисло намертво, а после перезагрузки система вообще не грузилась :(

Наше желание помочь прямопропорционально вашему желанию решить проблему


Оффлайн
gantellus

а место свободное на винте есть? имею в виду раздел /
потмоу что пишет что его нет :)

можно попробовать sudo apt-get clean (удалит все пакеты из кэша) или sudo apt-get autoremove (удалит ненужные)

Придумайте ещё более дружественный интерфейс, и мир породит ещё более тупого юзера (с)
С2Duo 2.4 Ghz, Geforce 8800, Maya 44 PCI


Оффлайн
ferrari

а место свободное на винте есть? имею в виду раздел /

подозрение есть что из кэша не удаляются пакеты и он забивается, но тогда возникает вопрос почему это происходит?

sudo apt-get autoremove ——- не прошла, пишет E: dpkg was interrupted, you must manually run ‘dpkg —configure -a’ to correct the problem.
sudo apt-get clean —————- прошла, но ни какого эффекта, проблема осталась

« Последнее редактирование: 10 Июня 2008, 00:09:40 от ferrari »


Оффлайн
jel

Ну пишет же черным по белому — (28 No space left on device). Нету свободного места. Освободить надобно. Для начала метров 100-200 руками. Потом уже разновсяческими clean, им ведь тоже место понадобится для временных файлов, а его-то и нету. :)


Оффлайн
Kwah

Проверь размеры логов в /var/log а вообще baobab в руки, он наглядно покажет, куда протерялось место.


Оффлайн
ferrari

товарищи, поподробнее можно? совет одним словом для новичка в линуксе это почти и не совет.

Проверь размеры логов в /var/log

зашёл в вар лог — там много файлов разных и что? где смотреть, какой размер должен быть?
вот что у меня в вар логе


/var/log# ls
acpid            dmesg.4.gz                       samba
acpid.1.gz       dpkg.log                         scrollkeeper.log
acpid.2.gz       dpkg.log.1                       scrollkeeper.log.1
apparmor         faillog                          scrollkeeper.log.2
apt              fontconfig.log                   syslog
auth.log         fsck                             syslog.0
auth.log.0       gdm                              syslog.1.gz
auth.log.1.gz    installer                        syslog.2.gz
boot             kern.log                         syslog.3.gz
bootstrap.log    kern.log.0                       syslog.4.gz
btmp             kern.log.1.gz                    syslog.5.gz
btmp.1           lastlog                          syslog.6.gz
clamav           lpr.log                          udev
cups             mail.err                         unattended-upgrades
daemon.log       mail.info                        user.log
daemon.log.0     mail.log                         user.log.0
daemon.log.1.gz  mail.warn                        user.log.1.gz
debug            messages                         wtmp
debug.0          messages.0                       wtmp.1
debug.1.gz       messages.1.gz                    wvdialconf.log
dist-upgrade     news                             Xorg.0.log
dmesg            ntpstats                         Xorg.0.log.old
dmesg.0          pm-suspend.log                   Xorg.20.log
dmesg.1.gz       pycentral.log                    Xorg.20.log.old
dmesg.2.gz       qtparted-20080606-23h50m45s.log  Xorg.21.log
dmesg.3.gz       qtparted-20080607-20h07m53s.log


вот как используется место на дисках, если я правильно посмотрел
df
Файловая система           1K-блоков      Исп  Доступно  Исп% смонтирована на
/host/ubuntu/disks/root.disk
                       3681640   3221772    274324  93% /
varrun                  192764       104    192660   1% /var/run
varlock                 192764         0    192764   0% /var/lock
udev                    192764        48    192716   1% /dev
devshm                  192764        52    192712   1% /dev/shm
lrm                     192764     38176    154588  20% /lib/modules/2.6.24-17-generic/volatile

P.S. а спойлеры не работают что ли?


Оффлайн
wl

товарищи, поподробнее можно? совет одним словом для новичка в линуксе это почти и не совет.

Проверь размеры логов в /var/log

зашёл в вар лог — там много файлов разных и что? где смотреть, какой размер должен быть?
вот что у меня в вар логе

Расшифровываю.
df — покажет, сколько свободного места на разных устройствах.
sudo du -s  /*  — покажет, сколько занимает каждый из корневых каталогов
sudo du -s /var/* — —//— сколько весит содержимое /var (в том числе, /var/log)
baobab (под Gnome) и filelight (под KDE)  — утилиты ставятся отдельно и рисуют красивые окошки, показывающие, куда делось место на диске.

На свете феньки есть такие, брат Горацио, которых лохи просто не секут. (Шекспир, «Гамлет», вольный перевод)


Оффлайн
ferrari

проблема решена, всем спасибо


помогло manually run ‘dpkg —configure -a’


Оффлайн
Salim

Привет ferari мог бы поподробней описать что делал ? у меня таже проблема хотелось узнать что ты удалил из  /var/lib/dpkg/status ; там всё удалать можно или часть информации используется. по  man  ‘dpkg —configure -a’
Нет справочного руководства для dpkg —configure -a поэтому прошу помощи. заранее спасибо :)


Оффлайн
ferrari

не задумываясь написал dpkg —configure -a в командной строке, там само всё проверилось и исправилось, без моего участия.


Оффлайн
Salim

Спасибо ! В прошлый раз и я так сделал и все исправилось но сейчас этот номер непроходит . Показалось что ты по другому исправлял . Спасибо что окликнулся , ищу решение проблемы. ;)


  • Печать

Страницы: [1]   Вверх

No space left on device (28) is a common error in Linux servers.

As a Server Administration Service provider, we see this error very often in VPSs, Dedicated Servers, AWS cloud instances and more.

It could happen seemingly for no reason at all (like refreshing a website), or when updating data (like backup sync, database changes, etc.).

What is the error “No space left on device (28)”?

For Linux to be able to create a file, it needs two things:

  1. Enough space to write that file.
  2. A unique identification number called “inode” (much like a social security number).

Most server owners look at and free up the disk space to resolve this error.

But what many don’t know is the secret “inode limit“.

What is “inode limit”, you ask? OK, lean in.

Linux identifies each file with a unique “inode number”, much like a Social Security number. It assigns 1 inode number for 1 file.

But each server has only a limited set of inode numbers for each disk.  When it uses up all the unique inode numbers in a disk, it can’t create a new file.

Quite confusingly, it shows the error : No space left on device (28) and people go hunting for space usage issues.

Now that you know what to look for, let’s look at how to fix this issue.

In reality, there’s no single best way to resolve this error.

Our Dedicated Server Administrators maintain Linux servers of web hosts, app developers and other online service providers.

We’ve seen variations of this error in MySQL servers, PHP sites, Magento stores and even plain Linux servers.

Going over our support notes, we can say that an ideal solution that’s right for one server might cause unintended issues in another server.

So, before we go over the solutions, carefully study all options and choose the best for you.

Broadly, here are the ways in which we resolve “No space left on device (28)“:

  1. Deleting excess files.
  2. Increasing the space availability.
  3. Fixing service configuration.

Now let’s look at the details of each case.

Fixing Magento error session_start(): failed: No space left on device

Our Dedicated Server Administrators support several high traffic online shops that use Magento.

In a couple of these sites, we have seen the error “session_start(): failed: No space left on device” when the site traffic suddenly goes up during marketing campaigns, seasonal sales, etc.

That happens when Magento creates a lot of session and cache files to store visitor data and to speed up the site.

In all the cases, we’ve seen the inode count to be maxed out, while the was still disk space.

Here, deleting the session or cache files might look like a good idea, but those files will come back in a few minutes.

So, after we as a pemanent solution, we do these:

  1. Setup cache expiry and auto-cleaning – These servers uses PHP cache and Magento cache, whcih created a lot of files during high traffic hours. So, we configured cache expiry, and setup a script to clear all cache files older than 24 hours.
  2. Configure log rotation – Some logs grew to more than 50 GB, which posed a threat to the disk space. So, we configured the log rotate service to limit log size to 500 MB, and to delete all logs older than 1 week.
  3. Auto-clear session files – The session files were set to tbe auto-deleted with a custom script so that inode numbers are not used up.
  4. Audit disk usage periodically – On top of all this, our admins audit these servers every couple of weeks to make sure the systems are working properly, and if needed make corrections.

If you need help fixing this error in your Magento server, click here to talk to our Magento experts. We are online 24/7.

Resolving WordPress “Warning: sessionstart(): open(/tmp/mysite/tempfile) failed: No space left on device (28)”

WordPress is another popular web platform where we’ve seen this error.

When updating content or logging into the admin panel, a user sees the error:

Warning: sessionstart(): open(/tmp/mysite/tempfile) failed: No space left on device (28)

The most common reasons for this are:

  1. User’s space/inode quota exhaustion.
  2. Inode exhaustion in session directory.
  3. Space/Inode exhaustion in the server.

Fixing quota issues

If the site is hosted in a shared server or a VPS, there’ll be account default limits to storage space and inode counts.

In many cases, we’ve found large files (such as backup, videos, DB dumps, etc.) in the user’s home directory itself. But there are other locations that are not so obvious:

  • Trash or Spam mail folders
  • Catch-all mail accounts
  • Web app log files (eg. WordPress error log)
  • Old log files (eg. access_log.bak)
  • Old uncompressed backups (from a previous site restore for eg.)
  • Un-used web applications

The first step in such situations is to look at these locations, and remove all files that are not necessary. That’ll resolve the error in the website, but that is not enough.

An important part of our support philosophy is to implement fixes such that an issue won’t come back.

So, our server admins then dig in and figure out why the space exceeded in the first place.

Some common reasons and the permanent resolutions we implement are:

  • Abandoned mailboxes – Unused mail accounts can easily become a spam dump, and eat up all the disk space. We set up disk usage alert mails to the site owner so that once any mail account exceeds the normal size, the account owner can investigate and delete unwanted mails or accounts.
  • Unmaintained IMAP accounts – We’ve seen IMAP accounts with over 10 GB of mails in Trash. To avoid such issues, we setup fixed email quotas and alert mails so that users and site owners can take action before the quota tuns out.
  • Old applications and files – In some websites we’ve seen old applications that were once used or installed to test features. These apps not only waste disk space, but are also a security threat. In the sites we maintain for our customers, we prevent such issues through periodic website/server audits where we detect and remove unused files.

Fixing inode exhaustion in session directory

WordPress plugins store session files in the home directory by default.

But some servers might have this set to an external directory like /tmp or /var depending on the application used to setup PHP and WordPress.

Since session files aren’t too large or numerous, it’ll usually be something else that’s taking up space in those directories.

For instance, in one server, the session directoy was set to /var/apps/users/path/to/tmpsession. The space in /var directory was exhausted by discarded backup dumps.

In that particular server, the solution was to delete old backups, but it can be something else in other servers.

So, we follow a top-down approach by looking at the inode count for each main folder, and then drill down to the directory that consumes the most inodes.

No space left on device (28)

An example of a command used to find inode usage.

Fixing Space or Inode exhaustion in a server

This is a variation of the issue mentioned above.

Unoptimized backup processes or cache systems or log services can leave a lot of files lying around.

That’ll quickly consume the available space and inode quota.

So,

  • We first sort the directories in a server based on their space and inode usage.
  • Then we figure out which ones are not really needed, and delete the excess files.
  • And last, we tweak the services that created those files to clear out the files after a fixed limit.

If your WordPress site or web application is currently showing this error, we can help you fix it. Click here to talk to our experts. We are online 24/7.

How to fix rsync: mkstemp “/path/to/file” no space left on device (28)

Many backup software use rsync tool to transfer backup files between servers.

We’ve seen many backup processes fail with the error rsync: mkstemp "/path/to/file" no space left on device (28).

Among the many reasons for this error, these are the most common:

  • Double space issue – In its default setting, Rsync needs double the space to update a file. So, if rsync is trying to update a 20 GB file, it needs another 20 GB free space to hold the temporary file while the new version is being transferred from the source server. In some servers, this fails due to reaching space or quota limits.
  • Quota exhaustion – In VPS servers there could be account level limits on number of inodes and space available. During transfer of large directories, this quota could get exhausted.
  • Inode / Space limit on drive – Backup folders or database directories are sometimes mounted on a separate directory with limited space. So, when moving large archives, the space or inode limits can get exhausted.

To solve these issues, first we figure out exactly which limit is getting hit, and if there’s a way to implement an alternate solution.

For instance if we find that rsync is trying to update a large file of many GBs in size (eg. database dump or backup archive), we use an option called --inplace in the rsync command.

This will skip creating the temporary file, and will just update those parts of the file that were changed. In this way we avoid the need to upgrade disk quota.

Fixing space or inode overage

By far, the most common cause for inode or space exhaustion is all the good space being taken up by files that the server owner doesn’t need.

It could be old uncompressed backups, cache files, spam files and more.

So, the first step in our troubleshooting is always to sort all folders based on their space and inode usage.

Once we know the top folders that contributed to the disk overage, we can then drill down to weed out those that are not needed.

no space left on device - finding space usage

Here’s an example of a command that lists folders by space usage.

The second, and more important step in this resolution is to find out which process caused the junk file build-up and then reconfigure the service to automatically clean out old files.

Are you facing an rsync error right now? We can help you fix it in a few minutes. Click here to talk to our experts. We are online 24/7.

Fixing MySQL Errcode: 28 – No space left on device

MySQL servers sometimes run into this error when executing complex queries. An example is:

ERROR 3 (HY000) at line 1: Error writing file '/tmp/MY4Ei1vB' (Errcode: 28 - No space left on device)

When executing complex queries that merges several tables together, MySQL builds temporary tables in /tmp drive.

If the space or inodes are exhausted for any reason in these folders, MySQL will exit with this error.

Temporary drive can get quickly filled up with cache files, session files or other temporary files that was never cleaned up.

To resolve and prevent this from happening, we setup /tmp cleaning programs that’ll prevent junk files from piling up, and will be run every time the usage raises above 80%.

If you need help in resolving this error in your MySQL server, we can help you. Click here to talk to our experts. We are online 24/7.

How Bobcares helps prevent disk errors

All of what we have said here today is more “reactive” that “proactive”.

We said how we would RECOVER a server once a service fails with this error.

Here at Bobcares, our aim is to PREVENT such errors from happenig in the first place.

How do we do it? By being proactive.

We maintain production servers of web hosts, app developers, SaaS providers and other online businesses.

An important part in this maintenance service is Periodic Server Audits.

During audits, expert server administrators manually check every part of the server and fix everything that can affect the uptime of services.

Some of the checks to prevent disk errors are:

  • Inode and Space usage – We check the available disk space and inodes in a server, and compare it with previous audit results. If we see an abnormal increase in the usage, we investigate in detail and regulate the service that’s causing the file growth.
  • Temp folder auto-clearence – We setup scripts that keep the temp folders clean, and during the audits make sure that the program is working fine.
  • Spam and catchall folders – We look for high volume mail directories, and delete accounts that are no longer maintained. This is has many times helped us prevent quota overage.
  • Unused accounts deletion – Old user accounts that were either canceled or migrated out sometimes remain back in the server. We find and delete them.
  • Old backups deletion – Sometimes people can leave uncompressed backups lying around. We detect such unused archives and delete them.
  • Log file maintenance – We setup log rotation services that clears our old log files as it reaches a certain size limit. During our periodic audit we make sure these services are working well.
  • Old packages deletion – Linux can leave old application installation packages even after an application is setup. We clear out old unused installation archives.
  • Old application deletion – We scan for application folders that are no longer accessed, and delete unused apps and databases.

Of course, there are many more ways in which the disk space could be used up.

So, we customize the service for each of our customers, and make sure no part is left unchecked.

Over time this has helped us achieve close to 100% uptime for our customer servers.

Conclusion

No space left on device (28) is a common error in Linux servers that is caused either due to lack of disk space or due to exhaustion of inodes. Today we’ve seen the various reasons for this error to occur while using Magento, WordPress, MySQL and Rsync.

  • #1

Hello,

I can’t find a way to gain space on my Proxmox server.

My containers are working properly but I can’t do any update:

apt-get update

Code:

 Error writing to output file - write (28: No space left on device) Error writing to file - write (28: No space left on device)

Syslog

Code:

Jun 14 00:57:44 climaxweb pveproxy[1749]: worker 12314 started
Jun 14 00:57:44 climaxweb pveproxy[1749]: worker 12315 started
Jun 14 00:57:44 climaxweb pveproxy[12312]: Warning: unable to close filehandle GEN4 properly: No space left on device at /usr/share/perl5/PVE/APIServer/AnyEvent.pm line 1572.
Jun 14 00:57:44 climaxweb pveproxy[12312]: error writing access log
Jun 14 00:57:44 climaxweb pveproxy[12312]: worker exit
Jun 14 00:57:44 climaxweb pveproxy[1749]: worker 12312 finished
Jun 14 00:57:44 climaxweb pveproxy[1749]: starting 1 worker(s)
Jun 14 00:57:44 climaxweb pveproxy[1749]: worker 12317 started
Jun 14 00:57:44 climaxweb pveproxy[12315]: Warning: unable to close filehandle GEN4 properly: No space left on device at /usr/share/perl5/PVE/APIServer/AnyEvent.pm line 1572.
Jun 14 00:57:44 climaxweb pveproxy[12315]: error writing access log

Here is the result of a df -h :

Code:

Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  314M  2.9G  10% /run
/dev/md1        467G  455G     0 100% /
tmpfs            16G   34M   16G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            16G     0   16G   0% /sys/fs/cgroup
/dev/md0        282M   53M  210M  20% /boot
/dev/fuse        30M   20K   30M   1% /etc/pve
tmpfs           3.2G     0  3.2G   0% /run/user/1000

I do not understand why my /dev/md1 indicates 100% of use (cross-multiplication should indicates 97% isn’t it ?).

I tried to erase some containers but, unfortunately, the available space stays at zero…

Do you have an idea / trick to resolve this weird problem ?

Kindest regards,

Rémi

dcsapak


  • #2

you could use ‘du’ or ‘ncdu’ to see which are the biggest files and delete them

  • #3

Thanks for your help Dominik.

Unfortunately, even if I a delete a file (it was the case with a 16Gb Debian container), the «Available space» stays at «0». And I do not understand why ..

  • #4

If after deletion disk space does not become available, then some process must be accessing that file.
Try: «lsof -n| grep FILENAME» to find out, what process access it, and restart this process.
If lsof is not available, then «apt install lsof»

  • #5

Hi,

Take in account that on most linux fs (ext*) around 2% of total space is reserved for root only. So delete as many file you can, and after that try to restart yours CTs.

  • #6

Hi,

Thanks gallew for your assistance. No luck, the problem continues to occur even after a reboot.

Thanks gultez for this idea. I’ve deleted all the files that I can but I still can’t do any updates. I can create files manually, I can wget files in my «/dev/md1» partition, but no apt-get.

The thing that I can’t understand is that a df -h gives :

Code:

Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  306M  2.9G  10% /run
/dev/md1        467G  455G     0 100% /
tmpfs            16G   34M   16G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            16G     0   16G   0% /sys/fs/cgroup
/dev/md0        282M   53M  210M  20% /boot
/dev/fuse        30M   20K   30M   1% /etc/pve
tmpfs           3.2G     0  3.2G   0% /run/user/1000

Why 100% of available space for /dev/md1 ? 455G used on a total of 467G should give 97%, with 12G of free space to run my updates.

I think that apt-get reads this «100%» value and refuses to do the updates, even if there are 12G of free space. I would like to find a way to work around this issue.

Thanks for your kind assistance,

Rémi

  • #7

Hi,

Thanks gallew for your assistance. No luck, the problem continues to occur even after a reboot.

Thanks gultez for this idea. I’ve deleted all the files that I can but I still can’t do any updates. I can create files manually, I can wget files in my «/dev/md1» partition, but no apt-get.

The thing that I can’t understand is that a df -h gives :

Code:

Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  306M  2.9G  10% /run
/dev/md1        467G  455G     0 100% /
tmpfs            16G   34M   16G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            16G     0   16G   0% /sys/fs/cgroup
/dev/md0        282M   53M  210M  20% /boot
/dev/fuse        30M   20K   30M   1% /etc/pve
tmpfs           3.2G     0  3.2G   0% /run/user/1000

Why 100% of available space for /dev/md1 ? 455G used on a total of 467G should give 97%, with 12G of free space to run my updates.

I think that apt-get reads this «100%» value and refuses to do the updates, even if there are 12G of free space. I would like to find a way to work around this issue.

Thanks for your kind assistance,

Rémi

… like I said do not count of free space under < 3%. Think that you have a file with size = 2 k, but for hdd perspective the space usage is 4k (this is minimum).

  • #8

What filesystem type do you have on /dev/md1? Is it BTRFS by chance? If it is and you’re using snapshots, they will continue to reference any files you delete from the live filesystem. So to clear space you would need to remove files from the live filesystem AND delete any snapshots that were made when the files existed.

If this is an ext3/4 filesystem, then your symptoms are a mystery. It’s possible to run into these types of issues under LVM with snapshots but I don’t see any indication that you’re using LVM.

  • #9

If you’re deleting files but they’re not freeing up space its either because you’re using a cow file system (zfs) or you’re deleting them from another (mounted) filesystem.

to ignore other filesystems use:

du -hsx /*

then drill down to the directories that appear to be oversized and repeat, eg

du -hsx /var/*

until you find what killed your free space. the most obvious places to start looking into is /var and /home (/root if you’re logging in that way; if you do- stop that)

A suggestion to the proxmox devs- make /var and /home their own partitions on default install.

  • #10

… like I said do not count of free space under < 3%. Think that you have a file with size = 2 k, but for hdd perspective the space usage is 4k (this is minimum).

Thanks guletz. It’s maybe that.. I will try to backup then delete another (huge) container to see if the magic happens. :)

  • #11

If this is an ext3/4 filesystem, then your symptoms are a mystery. It’s possible to run into these types of issues under LVM with snapshots but I don’t see any indication that you’re using LVM.

My /dev/md1 is an ext3/4 filesystem. I’m not using LVM. Thanks!

  • #12

If you’re deleting files but they’re not freeing up space its either because you’re using a cow file system (zfs) or you’re deleting them from another (mounted) filesystem.

to ignore other filesystems use: …

Thanks for your help. My containers (1 raw & 2 qcow2) are taking up all the space in /var/lib/vz/images/ … The problem is that I need to shrink them.. and it seems to be a difficult task.

Kindest regards,

Rémi

  • #13

Thanks Guletz for your previous reply : I backup, shrink then restore / reinstall my Windows Server 2K16. With 80Gb left, it’s now working perfectly :)

Thread is solved.

Kindest regards,

Rémi

  • #14

Good to know. You can optimise your vHDD(zfs volblocksize) if you know how big are most of your files(many small files -> 8-16 K, bigger files 32-64K, and so on)

fir3drag0n

Posts: 4
Joined: Mon Aug 05, 2019 7:18 pm

Upgrade to Buster fails

Hi,

when I do want to upgrade my rpi1, I get the messages:

Code: Select all

Get: 305 http://raspbian.raspberrypi.org/raspbian buster/main armhf libpython2.7                                                                       -dev armhf 2.7.16-2 [30.9 MB]
Err http://raspbian.raspberrypi.org/raspbian buster/main armhf libpython2.7-dev                                                                        armhf 2.7.16-2
  Error writing to output file - write (28: No space left on device) Error writi                                                                       ng to file - write (28: No space left on device) [IP: 2a00:1098:0:80:1000:75:0:3                                                                        80]
Get: 306 http://raspbian.raspberrypi.org/raspbian buster/main armhf libpython2.7                                                                        armhf 2.7.16-2 [873 kB]
Err http://raspbian.raspberrypi.org/raspbian buster/main armhf libpython2.7 armh                                                                       f 2.7.16-2
  Error writing to output file - write (28: No space left on device) Error writi                                                                       ng to file - write (28: No space left on device) [IP: 2a00:1098:0:80:1000:75:0:3                                                                        80]
Get: 307 http://raspbian.raspberrypi.org/raspbian buster/main armhf python2.7 ar                                                                       mhf 2.7.16-2 [305 kB]
Err http://raspbian.raspberrypi.org/raspbian buster/main armhf python2.7 armhf 2                                                                       .7.16-2
  Error writing to output file - write (28: No space left on device) Error writi                                                                       ng to file - write (28: No space left on device) [IP: 2a00:1098:0:80:1000:75:0:3                                                                        80]
[...]

What can I do in order to solve this?



fir3drag0n

Posts: 4
Joined: Mon Aug 05, 2019 7:18 pm

Re: Upgrade to Buster fails

Tue Aug 06, 2019 4:46 am

Okay, and what is your solution?

Code: Select all

Linux raspberrypi 4.19.57-v7+ 
pi@raspberrypi:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        15G  2.5G   12G  18% /
devtmpfs        459M     0  459M   0% /dev
tmpfs           464M  1.9M  462M   1% /dev/shm
tmpfs           464M   30M  434M   7% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           464M     0  464M   0% /sys/fs/cgroup
tmpfs           150M     0  150M   0% /var/cache/apt/archives
tmpfs            20M     0   20M   0% /var/tmp
tmpfs            70M   23M   48M  33% /var/log
tmpfs           100M   16K  100M   1% /tmp
/dev/mmcblk0p1   41M   40M  1.9M  96% /boot
tmpfs            93M     0   93M   0% /run/user/999
tmpfs            93M     0   93M   0% /run/user/1000
pi@raspberrypi:~ $

How can I clean /boot?

Code: Select all

Last login: Tue Aug  6 06:53:12 2019 from 192.168.1.51
pi@raspberrypi:~ $ ls -la /boot
total 39536
drwxr-xr-x  4 root root    3584 Aug  5 20:06 .
drwxr-xr-x 22 root root    4096 Mar  9  2018 ..
-rwxr-xr-x  1 root root   23946 Aug  5 20:06 bcm2708-rpi-b.dtb
-rwxr-xr-x  1 root root   24205 Aug  5 20:06 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x  1 root root   23723 Aug  5 20:06 bcm2708-rpi-cm.dtb
-rwxr-xr-x  1 root root   23671 Aug  5 20:06 bcm2708-rpi-zero.dtb
-rwxr-xr-x  1 root root   24407 Aug  5 20:06 bcm2708-rpi-zero-w.dtb
-rwxr-xr-x  1 root root   25293 Aug  5 20:06 bcm2709-rpi-2-b.dtb
-rwxr-xr-x  1 root root   26463 Aug  5 20:06 bcm2710-rpi-3-b.dtb
-rwxr-xr-x  1 root root   27082 Aug  5 20:06 bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x  1 root root   25261 Aug  5 20:06 bcm2710-rpi-cm3.dtb
-rwxr-xr-x  1 root root   40284 Aug  5 20:06 bcm2711-rpi-4-b.dtb
-rwxr-xr-x  1 root root   52296 Aug  5 20:03 bootcode.bin
-rwxr-xr-x  1 root root     142 Jan  1  1980 cmdline.txt
-rwxr-xr-x  1 root root    1590 Nov 29  2017 config.txt
-rwxr-xr-x  1 root root   18693 Aug  5 20:06 COPYING.linux
-rwxr-xr-x  1 root root    3030 Aug  5 20:03 fixup4cd.dat
-rwxr-xr-x  1 root root    6068 Aug  5 20:03 fixup4.dat
-rwxr-xr-x  1 root root    9146 Aug  5 20:03 fixup4db.dat
-rwxr-xr-x  1 root root    9148 Aug  5 20:03 fixup4x.dat
-rwxr-xr-x  1 root root    2649 Aug  5 20:03 fixup_cd.dat
-rwxr-xr-x  1 root root    6724 Aug  5 20:03 fixup.dat
-rwxr-xr-x  1 root root    9802 Aug  5 20:03 fixup_db.dat
-rwxr-xr-x  1 root root    9798 Aug  5 20:03 fixup_x.dat
-rwxr-xr-x  1 root root     145 Nov 29  2017 issue.txt
-rwxr-xr-x  1 root root 5299240 Aug  5 20:06 kernel7.img
-rwxr-xr-x  1 root root 5600072 Aug  5 20:06 kernel7l.img
-rwxr-xr-x  1 root root 5017424 Aug  5 20:06 kernel.img
-rwxr-xr-x  1 root root    1494 Aug  5 20:03 LICENCE.broadcom
-rwxr-xr-x  1 root root   18974 Nov 29  2017 LICENSE.oracle
drwxr-xr-x  2 root root   15360 Aug  5 20:07 overlays
-rwxr-xr-x  1 root root  762880 Aug  5 20:03 start4cd.elf
-rwxr-xr-x  1 root root 4716552 Aug  5 20:03 start4db.elf
-rwxr-xr-x  1 root root 2759172 Aug  5 20:03 start4.elf
-rwxr-xr-x  1 root root 3672712 Aug  5 20:03 start4x.elf
-rwxr-xr-x  1 root root  685412 Aug  5 20:03 start_cd.elf
-rwxr-xr-x  1 root root 4854088 Aug  5 20:03 start_db.elf
-rwxr-xr-x  1 root root 2878052 Aug  5 20:03 start.elf
-rwxr-xr-x  1 root root 3791560 Aug  5 20:03 start_x.elf
drwxr-xr-x  2 root root     512 Dec 24  2017 System Volume Information
pi@raspberrypi:~ $


User avatar

DougieLawson

Posts: 42328
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK

Re: Upgrade to Buster fails

Tue Aug 06, 2019 7:05 pm

As long as you’ve got a rescue system you can delete everything in /boot except config.txt and cmdline.txt.
With Buster you need /boot to be 256MB.

With gparted you can’t resize FAT32 partitions, you can only delete and recreate them. So copy /boot/cmdline.txt and /boot/config.txt to a safe place (/root or /home/pi) before resizing the /boot partition.

You can use rpi-update (this time only) to repopulate /boot.

If you trash things then lose power you will need a Linux rescue system to recover it. Your Raspberry with another SDCard and a USB reader is perfect as a rescue system.

Languages using left-hand whitespace for syntax are ridiculous

DMs sent on https://twitter.com/DougieLawson or LinkedIn will be answered next month.
Fake doctors — are all on my foes list.

The use of crystal balls and mind reading is prohibited.


fir3drag0n

Posts: 4
Joined: Mon Aug 05, 2019 7:18 pm

Re: Upgrade to Buster fails

Thu Aug 08, 2019 11:47 am

The thing is, I already did the upgrade from stretch to buster on a rpi2 without any errors. And the rpi2’s /boot drive is now 95% full.

So I guess the error with the rpi1 must be related to something else.


Return to “Raspberry Pi OS”

Понравилась статья? Поделить с друзьями:
  • Error writing to file python38 dll
  • Error writing to file python310 dll
  • Error writing to file python
  • Error writing to file gameguard
  • Error writing to file c config msi