Hi!
On the subscription invoices, could it be possible to add the cloudron ID or the domain name or anything that can identify a server from another? We have 3 servers, thus 3 invoices every month, and we can not which invoice goes with which server.
Thanks!
Hello,
It could be great and really usefull for many apps (Nextcloud, DokuWiki, Git...) to make the Cloudron groups accessible on LDAP.
Could it be possible?
Thanks!
Hi,
I think there should be more options to plan the server backuping. Instead of pre-defined options for delays, let the user choose the hours / days both for backup interval and conservation delay, and the moment it should backup.
And even more, make an option to delete old backup except some.
For example, I would like to backup my server every day at 10pm, and keep only :
I know this is a complex case, but there should be a way to let the user make a custom backup plan.
Thanks!
Hi,
I've got an issue when I want to restore a Cloudron backup on another server. I want to clone my Cloudron server A on another server B : it's what the doc calls "migration" .
I did that to test a complete backup of my main server, while keeping it alive.
What is going on:
my.<server B>, login prompt is displayed, but it redirects to my.<server A>/login_callback.html?token=<??>&state=<??>my.<server B>/#/apps is reachable<server B><app>.domain is set to <server A> and <app>.fqdn are <app>.<server A><server B> with a wildcard DNS API provider, it still displays "Internal Error" and an empty domain list<server B>, they are still in "error" status<server A> was mentionned to <server B>, they are still in "error" statusOne should be able to clone a Cloudron server easily from a backup, even if the DNS is different. And what are the issue of having two different Cloudron servers with the same ID ?
I submit a new issue for this.
Yes, this would be really great!
I patch the my.domainname.fr.conf with the missing part (taken from my other Cloudron server).
I then uninstalled and re-installed jingo, and everything seems to work fine now.
I didn't thought of any specific LDAP server. It would be great to connect Cloudron to any external LDAP server, that would manage groups and users. For example, connect a Cloudron server to another one so that only one Cloudron server manages the users and groups for both servers.
Hi,
I have a major issue on both my GitLab servers.I just updated them to 1.43.0 and both are not responding.
Here is the full log :
Dec 02 08:07:22 ==> Enabling LDAP integration
Dec 02 08:07:22 ==> Reusing existing host keys
Dec 02 08:07:22 ==> Fixing secrets
Dec 02 08:07:22 ==> Initializing gitlab shell
Dec 02 08:07:22 ==> Copying schema file
Dec 02 08:07:22 ==> Setting up tmp
Dec 02 08:07:23 ==> Fixing permissions
Dec 02 08:07:23 ==> Creating pg_trgm extension
Dec 02 08:07:23 NOTICE: extension "pg_trgm" already exists, skipping
Dec 02 08:07:23 ==> Upgrading existing db
Dec 02 08:07:23 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
Dec 02 08:07:23 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
Dec 02 08:07:23 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:29: warning: constant Gem::ConfigMap is deprecated
Dec 02 08:07:23 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:30: warning: constant Gem::ConfigMap is deprecated
Dec 02 08:07:23 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
Dec 02 08:07:23 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
Dec 02 08:07:24 `/home/git` is not writable.
Dec 02 08:07:24 Bundler will use `/tmp/bundler20201202-44-14wdz8y44' as your home directory temporarily.
Dec 02 08:07:24 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
Dec 02 08:07:24 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
Dec 02 08:07:24 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
Dec 02 08:07:28 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
Dec 02 08:07:32 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
Dec 02 08:07:34 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
Dec 02 08:07:36 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
Dec 02 08:07:37 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/acts-as-taggable-on-6.5.0/lib/acts_as_taggable_on/tagging.rb:9: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call
Dec 02 08:07:37 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/associations.rb:1657: warning: The called method `belongs_to' is defined here
Dec 02 08:07:37 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/marginalia-1.9.0/lib/marginalia.rb:94: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call
Dec 02 08:07:37 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/connection_adapters/postgresql_adapter.rb:648: warning: The called method `execute_and_clear_without_marginalia' is defined here
Dec 02 08:07:43 == 20201008013434 GenerateCiJwtSigningKey: migrating ==========================
Dec 02 08:07:43 rake aborted!
Dec 02 08:07:43 StandardError: An error has occurred, this and all later migrations canceled:
Dec 02 08:07:43
Dec 02 08:07:43 key must be 32 bytes or longer
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/encryptor-3.0.0/lib/encryptor.rb:60:in `crypt'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/encryptor-3.0.0/lib/encryptor.rb:36:in `encrypt'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/attr_encrypted-3.1.0/lib/attr_encrypted.rb:266:in `encrypt'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/attr_encrypted-3.1.0/lib/attr_encrypted.rb:350:in `encrypt'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/attr_encrypted-3.1.0/lib/attr_encrypted.rb:165:in `block (2 levels) in attr_encrypted'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/attr_encrypted-3.1.0/lib/attr_encrypted/adapters/active_record.rb:77:in `block in attr_encrypted'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activemodel-6.0.3.3/lib/active_model/attribute_assignment.rb:50:in `public_send'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activemodel-6.0.3.3/lib/active_model/attribute_assignment.rb:50:in `_assign_attribute'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activemodel-6.0.3.3/lib/active_model/attribute_assignment.rb:43:in `block in _assign_attributes'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activemodel-6.0.3.3/lib/active_model/attribute_assignment.rb:42:in `each'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activemodel-6.0.3.3/lib/active_model/attribute_assignment.rb:42:in `_assign_attributes'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/attribute_assignment.rb:21:in `_assign_attributes'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activemodel-6.0.3.3/lib/active_model/attribute_assignment.rb:35:in `assign_attributes'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/attr_encrypted-3.1.0/lib/attr_encrypted/adapters/active_record.rb:29:in `perform_attribute_assignment'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/attr_encrypted-3.1.0/lib/attr_encrypted/adapters/active_record.rb:36:in `assign_attributes'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/persistence.rb:620:in `block in update'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/transactions.rb:375:in `block in with_transaction_returning_status'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/connection_adapters/abstract/database_statements.rb:278:in `transaction'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/transactions.rb:212:in `transaction'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/transactions.rb:366:in `with_transaction_returning_status'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/persistence.rb:619:in `update'
Dec 02 08:07:43 /home/git/gitlab/db/migrate/20201008013434_generate_ci_jwt_signing_key.rb:21:in `block in up'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/relation/batches.rb:70:in `block (2 levels) in find_each'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/relation/batches.rb:70:in `each'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/relation/batches.rb:70:in `block in find_each'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/relation/batches.rb:136:in `block in find_in_batches'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/relation/batches.rb:238:in `block in in_batches'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/relation/batches.rb:222:in `loop'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/relation/batches.rb:222:in `in_batches'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/relation/batches.rb:135:in `find_in_batches'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/relation/batches.rb:69:in `find_each'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/querying.rb:21:in `find_each'
Dec 02 08:07:43 /home/git/gitlab/db/migrate/20201008013434_generate_ci_jwt_signing_key.rb:20:in `up'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:831:in `exec_migration'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:812:in `block (2 levels) in migrate'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:811:in `block in migrate'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:471:in `with_connection'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:810:in `migrate'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:1002:in `migrate'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:1310:in `block in execute_migration_in_transaction'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:1361:in `block in ddl_transaction'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/connection_adapters/abstract/database_statements.rb:280:in `block in transaction'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/connection_adapters/abstract/transaction.rb:280:in `block in within_new_transaction'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activesupport-6.0.3.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:26:in `block (2 levels) in synchronize'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activesupport-6.0.3.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activesupport-6.0.3.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activesupport-6.0.3.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activesupport-6.0.3.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/connection_adapters/abstract/transaction.rb:278:in `within_new_transaction'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/connection_adapters/abstract/database_statements.rb:280:in `transaction'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/transactions.rb:212:in `transaction'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:1361:in `ddl_transaction'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:1309:in `execute_migration_in_transaction'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:1281:in `block in migrate_without_lock'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:1280:in `each'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:1280:in `migrate_without_lock'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:1229:in `block in migrate'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:1382:in `with_advisory_lock'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:1229:in `migrate'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:1061:in `up'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/migration.rb:1036:in `migrate'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/tasks/database_tasks.rb:238:in `migrate'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/railties/databases.rake:86:in `block (3 levels) in <top (required)>'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/railties/databases.rake:84:in `each'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.0.3.3/lib/active_record/railties/databases.rake:84:in `block (2 levels) in <top (required)>'
Dec 02 08:07:43 /home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/rake-13.0.1/exe/rake:27:in `<top (required)>'
I'm filling a support ticket right now, but if anyone has an idea on that issue...
Hi,
I just updated my NextCloud to 20.0.2, and it's not responding.
Logs said :
Nov 30 08:17:29 Check primary keys.
Nov 30 08:17:29 Adding primary key to the filecache_extended table, this can take some time...
Nov 30 08:17:29
Nov 30 08:17:29 In AbstractPostgreSQLDriver.php line 51:
Nov 30 08:17:29
Nov 30 08:17:29 An exception occurred while executing 'ALTER TABLE oc_filecache_extended AD
Nov 30 08:17:29 D PRIMARY KEY (fileid)':
Nov 30 08:17:29
Nov 30 08:17:29 SQLSTATE[23505]: Unique violation: 7 ERROR: could not create unique index
Nov 30 08:17:29 "oc_filecache_extended_pkey"
Nov 30 08:17:29 DETAIL: Key (fileid)=(169141) is duplicated.
Nov 30 08:17:29
Nov 30 08:17:29
Nov 30 08:17:29 In PDOConnection.php line 83:
Nov 30 08:17:29
Nov 30 08:17:29 SQLSTATE[23505]: Unique violation: 7 ERROR: could not create unique index
Nov 30 08:17:29 "oc_filecache_extended_pkey"
Nov 30 08:17:29 DETAIL: Key (fileid)=(169141) is duplicated.
Nov 30 08:17:29
Nov 30 08:17:29
Nov 30 08:17:29 In PDOConnection.php line 78:
Nov 30 08:17:29
Nov 30 08:17:29 SQLSTATE[23505]: Unique violation: 7 ERROR: could not create unique index
Nov 30 08:17:29 "oc_filecache_extended_pkey"
Nov 30 08:17:29 DETAIL: Key (fileid)=(169141) is duplicated.
Nov 30 08:17:29
Nov 30 08:17:29
Nov 30 08:17:29 db:add-missing-primary-keys
And it's restarting every minutes.
Could someone help me on that?
Thanks,
@msbt Well, any call to apt-get tells me that
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
linux-image-generic
Which of course I can't do because of the lack of space in /boot.
I followed parts of this link :
dpkg --list 'linux-image*'|awk '{ if($1=="ii") print $2}'|grep -vuname -r``
rm -rf /boot/*-4.4.0-{161,164,178,179,184,185,186,187}-*
apt-get -f install
apt-get autoremove
And it worked fine!
Hi,
Cloudron update are failing for some day, and the message is update exited with code 1 signal null
I went to journalctl -u cloudron-updater and found:
Nov 15 21:23:43 my.domain.com installer.sh[354]: dpkg: dependency problems prevent configuration of linux-image-generic:
Nov 15 21:23:43 my.domain.com installer.sh[354]: linux-image-generic depends on linux-image-4.4.0-190-generic | linux-image-unsigned-4.4.0-190-generic; however:
Nov 15 21:23:43 my.domain.com installer.sh[354]: Package linux-image-4.4.0-190-generic is not installed.
Nov 15 21:23:43 my.domain.com installer.sh[354]: Package linux-image-unsigned-4.4.0-190-generic is not installed.
Nov 15 21:23:43 my.domain.com installer.sh[354]: linux-image-generic depends on linux-modules-extra-4.4.0-190-generic; however:
Nov 15 21:23:43 my.domain.com installer.sh[354]: Package linux-modules-extra-4.4.0-190-generic is not configured yet.
Nov 15 21:23:43 my.domain.com installer.sh[354]: dpkg: error processing package linux-image-generic (--configure):
Nov 15 21:23:43 my.domain.com installer.sh[354]: dependency problems - leaving unconfigured
Nov 15 21:23:43 my.domain.com installer.sh[354]: Processing triggers for linux-image-4.4.0-189-generic (4.4.0-189.219) ...
Nov 15 21:23:44 my.domain.com installer.sh[354]: /etc/kernel/postinst.d/initramfs-tools:
Nov 15 21:23:44 my.domain.com installer.sh[354]: update-initramfs: Generating /boot/initrd.img-4.4.0-189-generic
Nov 15 21:23:49 my.domain.com installer.sh[354]: cat: write error: No space left on device
Nov 15 21:23:49 my.domain.com installer.sh[354]: update-initramfs: failed for /boot/initrd.img-4.4.0-189-generic with 1.
Nov 15 21:23:49 my.domain.com installer.sh[354]: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Nov 15 21:23:49 my.domain.com installer.sh[354]: dpkg: error processing package linux-image-4.4.0-189-generic (--configure):
Nov 15 21:23:49 my.domain.com installer.sh[354]: subprocess installed post-installation script returned error exit status 1
Nov 15 21:23:49 my.domain.com installer.sh[354]: Errors were encountered while processing:
Nov 15 21:23:49 my.domain.com installer.sh[354]: linux-modules-extra-4.4.0-190-generic
Nov 15 21:23:49 my.domain.com installer.sh[354]: linux-image-generic
Nov 15 21:23:49 my.domain.com installer.sh[354]: linux-image-4.4.0-189-generic
Nov 15 21:23:49 my.domain.com installer.sh[354]: ==> installer: Failed to fix packages. Retry
I saw the line No space left on device and indeed df -h said /dev/md2 487M 482M 0 100% /boot
What is weird is that uname -nar says 4.4.0-154-generic but in /boot I have
initrd.img-4.4.0-104-generic
initrd.img-4.4.0-112-generic
initrd.img-4.4.0-154-generic
initrd.img-4.4.0-161-generic
initrd.img-4.4.0-164-generic
initrd.img-4.4.0-178-generic
initrd.img-4.4.0-179-generic
initrd.img-4.4.0-184-generic
initrd.img-4.4.0-185-generic
initrd.img-4.4.0-186-generic
initrd.img-4.4.0-187-generic
initrd.img-4.4.0-189-generic.new
Finally, I tired dpkg --confiure -a and my dpkg is locked : dpkg: error: dpkg frontend is locked by another process . Using lsof and ps, I found it is used by root 1213 0.0 0.0 65512 3000 ? Ss 2019 37:23 /usr/sbin/sshd -D
So, what should I do? Remove every files that are not 4.4.0-154-generic? Can I kill this sshd process that is locking dpkg?
@girish Well, this issue still happens and for both our servers. I just went to my AWS console to remove a backup made the 5th which were no more existing in the Cloudron dashboard (I have a retention of 1 week).
@nebulon Well, as this is production servers, I'd rather not remove our daily backups.
@nebulon It's tarball backup.
Hi,
I just went to my aws dashboard and I was surprised by the size taken by my Cloudron backups. I told Cloudron to make a backup every day and have a retention of a week.
After further investigations, all my backups still appears in aws, although only the last seven days appears in Cloudron.
It seems that Cloudron just "forget" about backups that passed retention, but does not remove it from AWS.
Well, a technician from Kimsufi just told me that there are no upload limit on my server. I don't really understand what's going on, because on more or less the same setup on a different server, it works fine.
Is there a way to track it down and find out where the issue come from?
@girish I tried to backup only the nextcloud, which generated the same error.
I have no idea on any upload limitation. My server is hosted by Kimsufi, an OVH discounter.