You are here
host:
pveversion
pve-manager/7.4-3/9002ab8a (running kernel: 5.15.104-1-pve)
turnkey template:
nextcloud 17.2.1
container is unprivilidged and has nesting enabled both at creation time and runtime.
When logging in for the first time using the console feature of the procmox GUI. The first init sequence starts and I am asked to enter a password for adminer.
As soon as I hit enter after typing the password the screen freezes. Only hitting backspace will show the following;
Traceback (most recent call last): File │
│ "/usr/lib/python3/dist-packages/libinithooks/dialog_wrap │
│ per.py", line 82, in wrapper retcode = method(" │
│ " + text, *args, **kws) File │
│ "/usr/lib/python3/dist-packages/dialog.py", line 3130, │
│ in passwordbox return │
│ self._widget_with_string_output( File │
│ "/usr/lib/python3/dist-packages/dialog.py", line 1719, │
│ in _widget_with_string_output code, output = │
│ self._perform(args, **kwargs) File │
│ "/usr/lib/python3/dist-packages/dialog.py", line 1518, │
│ in _perform exit_code, output = │
│ self._handle_program_exit(child_pid, File │
│ "/usr/lib/python3/dist-packages/dialog.py", line 1484, │
│ in _handle_program_exit │
│ self._wait_for_program_termination(child_pid, File │
│ "/usr/lib/python3/dist-packages/dialog.py", line 1430, │
│ in _wait_for_program_termination raise DialogError( │
│ dialog.DialogError: dialog-like terminated due to an │
│ error: the dialog-like program exited with status 3 │
│ (which was passed to it as the DIALOG_ERROR environment │
│ variable). Sometimes, the reason is simply that dialog │
│ was given a height or width parameter that is too big │
│ for the terminal in use. Its output, with leading and │
│ trailing whitespace stripped, was:
I have been troubled by something similar in the past and then the conclusion was to enable nesting. But the fact that I have this time around whilst still running into this wall suggests there is mroe wrong with my setup than obvious at first glance.
I have enough resources allocated to the container so that should not be a bottleneck.
Any suggestions on how to proceed in determining the root cause would be much welcomed ;)
Unfortunately the error message isn't helpful
Firstly, apologies for slow response. I've been away and am still catching up...
The error message (python stacktrace) relates to the "dialog" program crashing, most likely because it (automatically) resized to an invalid valid. So I'm fairly sure that it is unrelated.
I just tried to recreate your issue locally (applied all available PVE updates and downloaded a fresh copy of the TurnKey Nextcloud 17.2.1 template first). I just used the defaults and it "just works" for me?! FWIW (after updates and before my test) I have the same Proxmox version as you:
I do have a newer kernel version than you. Whilst I wouldn't expect the kernel version to cause this, perhaps it's worth updating just in case it's some weird edge case bug?
Also, out of interest, here is the config for my container:
You can find the same thing by catting /etc/pve/local/lxc/VM_ID.conf - where VM_ID is the VM ID number (i.e. mine is 127).
As you can see, mine is both nested and unprivileged.
Looking back at your past posts, this seems very similar to the previous issues you have reported. The specific issue you've reported here (hanging when setting Adminer user password) is consistent with MySQl (actually MariaDB) not running. TBH, unless you made a mistake (and it's not actually nested when you thought it was) I'm stumped on what could be causing this issue for you.
To try to troubleshoot, you could try getting into the container from the PVE host via the CLI. I.e.:
Again, where VM_ID is the VM ID of your container. Then check to see if my guess is right (that MariaDB isn't running) via systemctl. FWIW here's all the output of those commands on my system:
root@pve ~# pct enter 127 root@JED-TEST-nextcloud ~# systemctl status mariadb * mariadb.service - MariaDB 10.5.18 database server Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2023-05-03 00:57:38 UTC; 30min ago Docs: man:mariadbd(8) https://mariadb.com/kb/en/library/systemd/ Main PID: 393 (mariadbd) Status: "Taking your SQL requests now..." Tasks: 8 (limit: 38418) Memory: 121.9M CPU: 1.574s CGroup: /system.slice/mariadb.service `-393 /usr/sbin/mariadbd May 03 00:57:38 JED-TEST-nextcloud mariadbd[393]: 2023-05-03 0:57:38 0 [Note] Server socket created on IP: '127.0.0.1'. May 03 00:57:38 JED-TEST-nextcloud mariadbd[393]: 2023-05-03 0:57:38 0 [Note] Reading of all Master_info entries succeeded May 03 00:57:38 JED-TEST-nextcloud mariadbd[393]: 2023-05-03 0:57:38 0 [Note] Added new Master_info '' to hash table May 03 00:57:38 JED-TEST-nextcloud mariadbd[393]: 2023-05-03 0:57:38 0 [Note] /usr/sbin/mariadbd: ready for connections. May 03 00:57:38 JED-TEST-nextcloud mariadbd[393]: Version: '10.5.18-MariaDB-0+deb11u1' socket: '/run/mysqld/mysqld.sock' port: 3306 Debian 11 May 03 00:57:38 JED-TEST-nextcloud systemd[1]: Started MariaDB 10.5.18 database server. May 03 00:57:38 JED-TEST-nextcloud mariadbd[393]: 2023-05-03 0:57:38 0 [Note] InnoDB: Buffer pool(s) load completed at 230503 0:57:38 May 03 00:57:38 JED-TEST-nextcloud /etc/mysql/debian-start[420]: Upgrading MySQL tables if necessary. May 03 00:57:38 JED-TEST-nextcloud /etc/mysql/debian-start[455]: Checking for insecure root accounts. May 03 00:57:38 JED-TEST-nextcloud /etc/mysql/debian-start[465]: Triggering myisam-recover for all MyISAM tables and aria-recover for all Aria tablesIf the "Active:" line of your output is anything other than "active (running)", then please share the output of:
Plus also the output of the container config as I noted above.
details after pve upgrade
I finally found some time to upgrade the host and I am ending up in the same situation I am afraid.
I have some more time now to try a vanila debian container and see how that goes.
#pveversion
pve-manager/7.4-3/9002ab8a (running kernel: 5.15.107-1-pve)
#cat /etc/pve/local/lxc/301.conf
arch: amd64
cores: 4
features: nesting=1
hostname: nextcloud2
memory: 2048
net0: name=eth0,bridge=vmbr0,hwaddr=C6:B5:CB:95:5B:2B,ip=dhcp,ip6=dhcp,tag=5,type=veth
ostype: debian
rootfs: local-zfs:subvol-301-disk-0,size=8G
swap: 512
unprivileged: 1
#on first boot / init of container
the symtom and error message is simalor to my first post
#systemctl status mariadb
It's running fine in that output!?
Deep apologies for my super slow turnaround on this. I've had some (non-TurnKey related) crisis to deal with and I've really only been able to keep up with paid support and a bit of dev work behind the scenes to unblock some other team members. But I'm back at the desk now and hopefully should be back on top of things within the next day or 2.
Anyway, the weirdest part is that the most recent output you've shared looks like it's running fine!? (Albeit it's only been running about 3 minutes).
I wonder if it's a ZFS issue? Perhaps I'm getting confused, but I recall someone else having issues with our templates on PVE (which I also couldn't reproduce) was also using ZFS? Perhaps there is something weird going on there?
Also, if you want to test TKL against vanilla Debian, be sure to install MariaDB etc too.
Add new comment