installation via curl failed about nextcloudpi HOT 30 CLOSED

Then why does the installer check resolvconf and crashes if the service isn't there?

It first checks for systemd-resolved and if that's not found checks for resolvconf. If that's not found either, the installation fails.

In that case, the installer shouldn't be installing resolvconf like in my PR and instead check for different DNS resolvers for better compat with different systems, no?

Yes, exactly, but that's basically what it's doing in dnsmasq.conf. It doesn't seem to find neither resolvconf nor systemd-resolved so maybe Raspberry Pi OS is using something different still? I will check next week when I'm home and have a Raspberry Pi available for testing.

Like I said, I am using the official, unmodified image of Raspberry Pi OS Lite (64-bit). So nothing out of the ordinary for a Raspberry Pi

Generally, because of how hard it is to test images that are meant to run on specific hardware, we don't have installation tests for those boards, but rather provide readily built images (that are, of course, tested) in the releases.
That means that the installer will always be more likely to fail when installing on a custom OS for single board computers (other than Armbian, because that's the one we use to build everything).
It's still something I intend to support, but I can only react to issues once users found them, while I can actively test the official NCP images.

from nextcloudpi.

Just for the record. Had the same issue (aborting install at resolve dns) with Debian 12 clean in a VM.
Only thing. I use an own dns specified in /etc/network/interfaces.
This seesm to cause some trouble. Installed systemd-resolved manually an restarted "networking". Now everything works fine.

from nextcloudpi.

Thank you, that will be very helpful. However, I will focus on issues with the upgrade script first (I prioritize preventing breakage of existing installations over issues with setting up new ones, I hope you understand :) )

from nextcloudpi.

I'm closing this issue for now, because it's an unsupported use case and I'm not sure, if there's actually an issue with the installer if run on a fresh debian system as supposed to.

Feel free to post here again, if you try installing in a supported environment

from nextcloudpi.

Getting the same error with a clean install of the latest Raspberry Pi OS Lite (Bookworm) that I flashed using the Raspberry Pi Imager:

Applying workaround for dnsmasq bug (compare issue #1446)
+ mkdir -p /etc/systemd/resolved.conf.d
+ systemctl status systemd-resolved
Unit systemd-resolved.service could not be found.
+ systemctl stop resolvconf
Failed to stop resolvconf.service: Unit resolvconf.service not loaded.

it stops after that with an unfinished install just like with @ksd73429udmn. I'm using a Raspberry Pi 4.

from nextcloudpi.

@NuclearPhoenixx

For whatever reason you specify --no-install-recommends, however this results in resolvconf not being installed

Because that wasn't necessary in any tested scenario and would break (not fix) most installations, because it collides with alternative DNS resolvers like systemd-resolved. NCP favors systemd-resolved over resolvconf, because it's the standard for most non-VM/non-cloud setups nowadays, however resolvconf also works.
Generally though, the installer expects you to already have a working network configuration.

How things like this aren't tested even once before pushing a new release is beyond me
Behind me lie about two weeks of nonstop testing this release. I don't think you understand the complexity of testing entire operating system setups. However, for your information:

There are automatic tests which are ran on every release (and prevent a release to be published if they fail) which cover the following scenarios:

• NCP installed on a new debian VM
• NCP updated from a debian VM running the previous release of NCP
• NCP updated from a debian VM running the last NCP version on a previous debian release, including distribution upgrade
• NCP installed on a new debian LXD container
• NCP updated from a debian LXD container running the previous release of NCP
• NCP updated from a debian LXD container running the last NCP version on a previous debian release, including distribution upgrade
• all built armbian images using an ARM emulator (qemu)

Running the installer in Raspberry Pi OS is not one of them, because the official support for the Raspberry Pi is provided via the prebuilt images. However, I will still try to fix your configuration.

These automatic tests cover the following:

• Startup of all relevant services
• Availability of relevant tools and binaries
• Successful activation of NCP
• Successful login into Nextcloud without errors being shown in the admin section
• Various configuration checks
• Successful ncp-update to a newer (fake) NCP release

There are more tests planned, but that's what we have now.

Additional, before a release like this, I'm running countless manual tests on various configurations (aided by volunteers within the NCP community) to see if there are issues that might not be covered by the automatic tests. I'm sorry to hear that the installer didn't work for your specific system configuration, but that risk always exists, especially shortly after swapping the used OS version, which changes lots of services, packages and configurations.

from nextcloudpi.

It doesn't seem to find neither resolvconf nor systemd-resolved so maybe Raspberry Pi OS is using something different still?

That's my best bet now too. Uninstalling resolvconf after the install did not break anything either, so I presume some package is simply not checked for at install that's being used in Raspberry Pi OS. From what I can tell, Raspberry Pi OS uses the network-manager package. Any chance you can re-open the issue to get more attention to this problem?

@ksd73429udmn Did you try to replicate my method by any chance? Would be good to hear a second opinion on this, if not don't worry about it.

from nextcloudpi.

That likely means that there was a previous error in the installation process. Can you check that or share the full installation log?

Other than that, feel free to use the available, readily built and tested image for the RPi5 from the official release page

from nextcloudpi.

Sure.
ncp.log

from nextcloudpi.

The logs look strange in some places... Could you run the installation (on a fresh system) again with the following command:

curl -sSL https://raw.githubusercontent.com/nextcloud/nextcloudpi/master/install.sh | bash |& /var/log/ncp-install.log

That will result in a full installation log file at /var/log/ncp-install.log

from nextcloudpi.

Sorry for my noobism, but

sudo curl -sSL https://raw.githubusercontent.com/nextcloud/nextcloudpi/master/install.sh | bash |& /var/log/ncp-install.log
zsh: permission denied: /var/log/ncp-install.log

I can create the file manually and also permissions seem right, but I can not manage to write the logfile

from nextcloudpi.

Ah, sorry, my bad! The correct command is:

curl -sSL https://raw.githubusercontent.com/nextcloud/nextcloudpi/master/install.sh | bash |& sudo tee /var/log/ncp-install.log

from nextcloudpi.

❯ curl -sSL https://raw.githubusercontent.com/nextcloud/nextcloudpi/master/install.sh | bash |& sudo tee /var/log/ncp-install.log

WARNING: existing mysqld configuration will be changed <<<
The 'nextcloud' database already exists. Aborting

from nextcloudpi.

The nextcloud installtion seems to be in place, all folders are in /var/www/nextcloud, but ncp-config looks like this and the web-ui is also not accesible.

from nextcloudpi.

You need to reflash the sd with a clean debian installation before attempting the installation of NCP again

from nextcloudpi.

Hmm, still no luck.
ncp-install.log

systemctl status systemd-resolved
Unit systemd-resolved.service could not be found.

from nextcloudpi.

https://forums.debian.net/viewtopic.php?p=790454&sid=c78c1b2ca4badc26978cd4d656f63dbf#p790454

from nextcloudpi.

Manually installed systemd-resolved . Problem seems resolved. Unfortunatly running into this now:

Running nc-init
Setting up a clean Nextcloud instance... wait until message 'NC init done'
Setting up database...

*** FATAL CONFIG FILE ERROR (Redis 7.0.15) ***
Reading the configuration file, at line 2277

'maxmemory'
wrong number of arguments

from nextcloudpi.

Hmm, still no luck. ncp-install.log

systemctl status systemd-resolved Unit systemd-resolved.service could not be found.

You're still not installing into a fresh Debian system according to these logs, so you I'm not surprised that this breaks again

from nextcloudpi.

Ok, I see, you are right. I will try flashing the provided image. Thanks for your help so far!

from nextcloudpi.

You're welcome and good luck! :)

from nextcloudpi.

Same here. I also tried flashing the provided image (NextcloudPi_RaspberryPi5_v1.54.0.zip). It installed and did the inital setup. I was not able to access via SSH though.

from nextcloudpi.

Ah, sorry, my bad! The correct command is:

curl -sSL https://raw.githubusercontent.com/nextcloud/nextcloudpi/master/install.sh | bash |& sudo tee /var/log/ncp-install.log

Here is the log file:
ncp-install.log

This is the same error as described above:

+ systemctl status systemd-resolved
Unit systemd-resolved.service could not be found.
+ systemctl stop resolvconf
Failed to stop resolvconf.service: Unit resolvconf.service not loaded.

Notably, look at these lines just before that, relating to the dnsmasq install:

+ apt-get install --no-install-recommends -y dnsmasq
Reading package lists...
Building dependency tree...
Reading state information...
Suggested packages:
  resolvconf
The following NEW packages will be installed:
  dnsmasq
0 upgraded, 1 newly installed, 0 to remove and 36 not upgraded.

For whatever reason you specify --no-install-recommends, however this results in resolvconf not being installed as well, so obviously it can neither start nor stop the service and stops the install.

I ended up nuking mysql using sudo apt purge mysql* to get rid of the WARNING: existing mysqld configuration will be changed.

Then I manually installed resolvconf and ran the installer again. This time it successfully concluded the install. I'm guessing this whole problem is a result of the new Debian version either not pre-installing resolvconf or no longer requiring it for the install of dnsmasq. Whatever it is, once again, just manually installing resolvconf fixed everything for me. I have opened a PR for this: #1917

How things like this aren't tested even once before pushing a new release is beyond me. Please just run the installer once before release to mitigate issues like this. I wanted to migrate from Bullseye to Bookworm today, which would've been an easy process mainly just re-installing NCP on a fresh image since using a new install is the recommended way for Debian to upgrade. Instead we all had to deal with this now.

from nextcloudpi.

There is no need to be upset.

from nextcloudpi.

@ksd73429udmn You need to activate NCP via the web browser (go to https://nextcloudpi.local or https://[ncp-ip]). After that you can enable SSH from the admin webinterface

from nextcloudpi.

Because that wasn't necessary in any tested scenario and would break (not fix) most installations, because it collides with alternative network managers like systemd-resolved. NCP favors systemd-resolved over resolvconf, because it's the standard for most non-VM/non-cloud setups nowadays, however resolvconf also works.

I see, so does adding resolvconf to the installer break other installs by any chance? Don't want to cause more harm than good.

Generally though, the installer expects you to already have a working network configuration.

I would expect so too if I'm able to curl the installer. If I understand correctly now, resolvconf is not necessarily the best way to go with new installs, because systemd-resolved is favored. Then why does the installer check resolvconf and crashes if the service isn't there? Sounds like a deeper issue in that it shouldn't be absolutely expecting resolvconf to be there in order to work.

In that case, the installer shouldn't be installing resolvconf like in my PR and instead check for different DNS resolvers for better compat with different systems, no?

I'm sorry to hear that the installer didn't work for your specific system configuration, but that risk always exists, especially shortly after swapping the used OS version, which changes lots of services, packages and configurations.

Like I said, I am using the official, unmodified image of Raspberry Pi OS Lite (64-bit). So nothing out of the ordinary for a Raspberry Pi. I'd have fully expected this issue to get caught in any of the automatic tests. Of course there is always a risk of breakage, more so with a new OS version. However, I'm not running some weird edge case or something, so I'm guessing then this is only a problem with Raspberry Pi OS?

from nextcloudpi.

Yes, I did exactly the same. But could not get it running on my RP5 like you on RP4. I had another Redis error afterwards. Will try again though with a fresh image and report back.

from nextcloudpi.

*also running the latest Raspberry Pi OS Lite (64-bit), like you. Vanilla.

from nextcloudpi.

So I tried again with installing systemd-resolved prior to runnning the script and ran into this now:
...

• echo 'Starting mariaDB'
  Starting mariaDB
• :
• sudo -u mysql mysqld
• [[ -S /run/mysqld/mysqld.sock ]]
• sleep 0.5
  2024-05-06 9:10:05 0 [Note] Starting MariaDB 10.11.6-MariaDB-0+deb12u1 source revision as process 14189
  2024-05-06 9:10:05 0 [Note] InnoDB: Compressed tables use zlib 1.2.13
  2024-05-06 9:10:05 0 [Note] InnoDB: Number of transaction pools: 1
  2024-05-06 9:10:05 0 [Note] InnoDB: Using ARMv8 crc32 + pmull instructions
  2024-05-06 9:10:05 0 [Note] InnoDB: Using liburing
  2024-05-06 9:10:05 0 [Note] InnoDB: Initializing buffer pool, total size = 256.000MiB, chunk size = 4.000MiB
  2024-05-06 9:10:05 0 [Note] InnoDB: Completed initialization of buffer pool
  2024-05-06 9:10:05 0 [ERROR] InnoDB: The Auto-extending data file './ibdata1' is of a different size 767 pages than specified by innodb_data_file_path
  2024-05-06 9:10:05 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
  2024-05-06 9:10:05 0 [Note] InnoDB: Starting shutdown...
  2024-05-06 9:10:05 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
  2024-05-06 9:10:05 0 [Note] Plugin 'FEEDBACK' is disabled.
  2024-05-06 9:10:05 0 [ERROR] Could not open mysql.plugin table: "Table 'mysql.plugin' doesn't exist". Some plugins may be not loaded
  2024-05-06 9:10:05 0 [Warning] 'innodb-large-prefix' was removed. It does nothing now and exists only for compatibility with old my.cnf files.
  2024-05-06 9:10:05 0 [Warning] 'innodb-file-format' was removed. It does nothing now and exists only for compatibility with old my.cnf files.
  2024-05-06 9:10:05 0 [Warning] 'innodb-buffer-pool-instances' was removed. It does nothing now and exists only for compatibility with old my.cnf files.
  2024-05-06 9:10:05 0 [ERROR] Unknown/unsupported storage engine: InnoDB
  2024-05-06 9:10:05 0 [ERROR] Aborting
• :
• [[ -S /run/mysqld/mysqld.sock ]]
• sleep 0.5
• :
• [[ -S /run/mysqld/mysqld.sock ]]
• sleep 0.5
• :
  ...

from nextcloudpi.

@ksd73429udmn That still sounds like there are some remnants from a previous installation of mariadb/mysql - are you running the installer on a system where you tried to run it (or something else) before?

from nextcloudpi.