<div dir="ltr"><div>OK. Looks like the former issue was due to a weird behaviour of the javascript-common package. The package wasn't properly configured and extracted (missing /etc/apache2/conf-available/javascript-common.conf). I probably should try debugging this and report against javascript-common if it happens to be a real bug in the package.</div><div><br></div><div><br></div><div>Meanwhile, I hacked the problem by manually extracting the offending file and moving it in the right place (BAAAAAAAAAAAAD thing to do, right? ;-) )</div><div><br></div><div>Then it seems that the setup phase goes a little further :</div><div><br></div><div>janv. 15 14:19:41 kheops /usr/bin/plinth[4789]: Running first setup.<br>janv. 15 14:19:41 kheops /usr/bin/plinth[4789]: Running setup for modules, essential - True, selected modules - None<br>janv. 15 14:19:41 kheops /usr/bin/plinth[4789]: Running module setup - storage<br>janv. 15 14:19:42 kheops /usr/bin/plinth[4789]: Running step for module - storage, step - post<br>janv. 15 14:19:42 kheops /usr/bin/plinth[4789]: # storage setup<br>janv. 15 14:19:42 kheops sudo[5863]:   plinth : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/share/plinth/actions/storage setup<br>janv. 15 14:19:42 kheops sudo[5863]: pam_unix(sudo:session): session opened for user root by (uid=0)<br>janv. 15 14:19:42 kheops sudo[5863]: pam_unix(sudo:session): session closed for user root<br>janv. 15 14:19:42 kheops /usr/bin/plinth[4789]: Running step for module - storage, step - post<br>janv. 15 14:19:42 kheops /usr/bin/plinth[4789]: # storage usage-info<br>janv. 15 14:19:42 kheops sudo[5866]:   plinth : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/share/plinth/actions/storage usage-info<br>janv. 15 14:19:42 kheops sudo[5866]: pam_unix(sudo:session): session opened for user root by (uid=0)<br>janv. 15 14:19:42 kheops sudo[5866]: pam_unix(sudo:session): session closed for user root<br>janv. 15 14:19:42 kheops /usr/bin/plinth[4789]: Error running setup - invalid literal for int() with base 10: 'cifs'<br>                                                Traceback (most recent call last):<br>                                                  File "/usr/lib/python3/dist-packages/plinth/setup.py", line 78, in run<br>                                                    self.module.setup(self, old_version=current_version)<br>                                                  File "/usr/lib/python3/dist-packages/plinth/modules/storage/__init__.py", line 273, in setup<br>                                                    disks = get_disks()<br>                                                  File "/usr/lib/python3/dist-packages/plinth/modules/storage/__init__.py", line 77, in get_disks<br>                                                    disks_from_df = _get_disks_from_df()<br>                                                  File "/usr/lib/python3/dist-packages/plinth/modules/storage/__init__.py", line 130, in _get_disks_from_df<br>                                                    disk['size'] = int(disk['size'])<br>                                                ValueError: invalid literal for int() with base 10: 'cifs'<br>janv. 15 14:19:42 kheops /usr/bin/plinth[4789]: Error running setup - invalid literal for int() with base 10: 'cifs'</div><div><br></div><div>Given that the problem now seems to lie with analyzing the output of "df", here is the output of "df" on my system :</div><div><br></div><div>root@kheops:/etc/apache2# df -k<br>Sys. de fichiers     blocs de 1K   Utilisé Disponible Uti% Monté sur<br>/dev/root               61110996  17934484   40658316  31% /<br>devtmpfs                 1827800         0    1827800   0% /dev<br>tmpfs                    1959896         0    1959896   0% /dev/shm<br>tmpfs                    1959896    116484    1843412   6% /run<br>tmpfs                       5120         4       5116   1% /run/lock<br>tmpfs                    1959896         0    1959896   0% /sys/fs/cgroup<br>/dev/loop1                 43136     43136          0 100% /snap/certbot/795<br>/dev/loop0                 45056     45056          0 100% /snap/certbot/891<br>/dev/loop2                 52608     52608          0 100% /snap/core20/876<br>/dev/loop3                 52608     52608          0 100% /snap/core20/906<br>/dev/loop4                 85248     85248          0 100% /snap/core/10579<br>/dev/loop5                 85248     85248          0 100% /snap/core/10584<br>/dev/mmcblk0p1            258095     46274     211822  18% /boot<br>/dev/sda1              672734512 608501768   30036728  96% /var/archives<br>/dev/sda3             1057232008  72666704  930837984   8% /var/backups/srv<br>/dev/sda2              288238944 192235056   81339084  71% /home<br>/dev/sdb1              960379920  72671624  838853872   8% /srv<br>//freebox/Disque dur   239216096 134956128   92085384  60% /music<br>tmpfs                     391976         0     391976   0% /run/user/1000</div><div><br></div><div>The "cifs" keyword rang a bell in my head......as you can see, I DO have a CIFS file system mount (
//freebox/Disque dur on /music) and, even worse......the CIFS UNC name has a space in it....:-)</div><div><br></div><div>So, just to check it hat helps, I unmounted the share and.....freedombox setup could continue.....</div><div><br></div><div>And complete....:-)</div><div><br></div><div>So, to summarize :</div><div>Problem nr1 : missing php-fpmpackage. SOlved by installing the package</div><div>Problem nr2 : wrongly installed javascript-common package. Quite likely more a problem in javascript-common itself</div><div>Problem nr3 : wrong analysis of "df" output when a CIFS share is mounted (maybe only when the share name has a space in it</div><div><br></div><div>Problems 1 and 3 seems to belong to the FreedomBox ecosystem (likely the plinth package, I'd guess)</div><div><br></div><div>Hope this helps! Please feel free to ask for more details in case I can still help....indeed contributing again a bit more to Debian is something that makes me very happy...:-)<br></div><div><br></div><div><br></div></div>