- Печать
Страницы: [1] Вниз
Тема: проблемы при загрузке обновлений (Прочитано 3850 раз)
0 Пользователей и 1 Гость просматривают эту тему.
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
ferrari
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
gantellus
можно попробовать сменить сервер
Придумайте ещё более дружественный интерфейс, и мир породит ещё более тупого юзера (с)
С2Duo 2.4 Ghz, Geforce 8800, Maya 44 PCI
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
ferrari
я так понял, что проблема в моём компе, а не в серваке, так как раньше (два дня назад) всё обновлялось
вот что мне выдал менеджер обновлений
E: dpkg was interrupted, you must manually run ‘dpkg —configure -a’ to correct the problem.
E: _cache->open() failed, please report.
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
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 все повисло намертво, а после перезагрузки система вообще не грузилась
Наше желание помочь прямопропорционально вашему желанию решить проблему
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
gantellus
а место свободное на винте есть? имею в виду раздел /
потмоу что пишет что его нет
можно попробовать sudo apt-get clean (удалит все пакеты из кэша) или sudo apt-get autoremove (удалит ненужные)
Придумайте ещё более дружественный интерфейс, и мир породит ещё более тупого юзера (с)
С2Duo 2.4 Ghz, Geforce 8800, Maya 44 PCI
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
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 »
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
jel
Ну пишет же черным по белому — (28 No space left on device). Нету свободного места. Освободить надобно. Для начала метров 100-200 руками. Потом уже разновсяческими clean, им ведь тоже место понадобится для временных файлов, а его-то и нету.
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
Kwah
Проверь размеры логов в /var/log а вообще baobab в руки, он наглядно покажет, куда протерялось место.
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
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. а спойлеры не работают что ли?
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
wl
товарищи, поподробнее можно? совет одним словом для новичка в линуксе это почти и не совет.
Проверь размеры логов в /var/log
зашёл в вар лог — там много файлов разных и что? где смотреть, какой размер должен быть?
вот что у меня в вар логе
Расшифровываю.
df — покажет, сколько свободного места на разных устройствах.
sudo du -s /* — покажет, сколько занимает каждый из корневых каталогов
sudo du -s /var/* — —//— сколько весит содержимое /var (в том числе, /var/log)
baobab (под Gnome) и filelight (под KDE) — утилиты ставятся отдельно и рисуют красивые окошки, показывающие, куда делось место на диске.
На свете феньки есть такие, брат Горацио, которых лохи просто не секут. (Шекспир, «Гамлет», вольный перевод)
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
ferrari
проблема решена, всем спасибо
помогло manually run ‘dpkg —configure -a’
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
Salim
Привет ferari мог бы поподробней описать что делал ? у меня таже проблема хотелось узнать что ты удалил из /var/lib/dpkg/status ; там всё удалать можно или часть информации используется. по man ‘dpkg —configure -a’
Нет справочного руководства для dpkg —configure -a поэтому прошу помощи. заранее спасибо
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
ferrari
не задумываясь написал dpkg —configure -a в командной строке, там само всё проверилось и исправилось, без моего участия.
![Оффлайн](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%200%200'%3E%3C/svg%3E)
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:
- Enough space to write that file.
- 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)“:
- Deleting excess files.
- Increasing the space availability.
- 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:
- 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.
- 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.
- 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.
- 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:
- User’s space/inode quota exhaustion.
- Inode exhaustion in session directory.
- 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.
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.
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
-
#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:~ $
-
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”