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 :

• the 7 previous days backup
• the first day of each weeks of the current month
• the first day of each previous monthes

I know this is a complex case, but there should be a way to let the user make a custom backup plan.

Thanks!

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!

Ok, I managed to make the application working from a backup.
The issue appears as soon as I connect to phpmyadmin.
I don't really understand why and what happens, but as long as I stay away from phpmyadmin, everything works fine.

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:

• Backup of Cloudron A (running on Ubuntu 16.04)
• Installation of same version Cloudron on ther fresh server B (Ubuntu 18.04)
• Copying Cloudron A backup on server B
• Setting up the DNS of Cloudron B
• Using "Looking to restore" and providing all information
• Near the end, a message saying "Not found" is displayed
• Going to my.<server B>, login prompt is displayed, but it redirects to my.<server A>/login_callback.html?token=<??>&state=<??>
• Subdomains B are unreachable, returning 404 errors
• After rebooting, my.<server B>/#/apps is reachable
• Cloudron B has the same Cloudron ID as Cloudron A
• Subdomains are reachable, but all application are in "Restoring (pending)" status
• When doing cloudron inspect:
  • apiEndpoint is <server B>
  • every <app>.domain is set to <server A> and <app>.fqdn are <app>.<server A>
• Users on server B are correct as well as groups
• When going to "Domains & Certs", an "Internal Error" message appears and "Domains" section is empty
• When adding domain <server B> with a wildcard DNS API provider, it still displays "Internal Error" and an empty domain list
• When repairing applications and setting their domain to <server B>, they are still in "error" status
• When changing all database entries where <server A> was mentionned to <server B>, they are still in "error" status
• Deleting all application then restoring one by one from backup seemed to work, but not for a long time. After a few day, more than half of the applications were in "error" status.

One 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.

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.

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.

Yes, this would be really great!

Ok, I managed to make the application working from a backup.
The issue appears as soon as I connect to phpmyadmin.
I don't really understand why and what happens, but as long as I stay away from phpmyadmin, everything works fine.

@girish @msbt Thanks! This helped greatly.
But I still have my increment issue.
In the CLI, I can do ANALYZE TABLE <my_table> after an insert and it updates the information_schema fields (TABLE_ROWS, AUTO_INCREMENT,...).
But when I insert again, nothing changes. I have to always make the ANALYZE TABLE to update the info.
Have you ever encounter this?

Hi,
I have the exact same problem after updating my Cloudron to v6.2.8.
It's been looping for more than an hour now.
I tried to restart Cloudron and even reboot my server.
How can I solve this problem?

Thanks.

Hi,

I have a strange behaviour with mysql in a Lamp container.
Here is the backgroud:

• I want to have this project https://partkeepr.org/ on my 2 servers
• I requires php <= 7.1
• I use lamp v1.4.0 https://git.cloudron.io/cloudron/lamp-app/-/tags/v1.4.0

On one of my server (cloudron v6.0.1) it works fine.
But on the other one (cloudron v6.2.8), I have many problems :

• In the terminal, when I try to connect to mysql CLI, I've got the error ERROR 2026 (HY000): SSL connection error: unknown error number so I have to use phpmyadmin to make database manipulation,
• When I insert a line in a table, the new id (an AUTOINCREMENT field) is correctly incremented, but in the information_schema fields, neither table_rows nor auto_increment etc... fields are modified. I have a trigger on before insert which needs the auto_increment value.

I have never seen such a behaviour and don't really know what to do.

Does anyone has any idea?

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.