I have freshly installed TrueNAS-13.0-U3.1 on a (quite old) Fujitsu TX140 S1p server. Let me add that I'm with Free/Truenas since it's very beginnings (was it 0.69) and using it on work and private machines ever since.
The onboard 6 channel SAS/SATA mpt is used here (and this thread is not about the lurking mpt issue that might be seen in the logs below).
Then while trying to import a pool via dialogue that was created with Ubuntu 19.04 (ZFS 0.8.3) the things went wrong.
After answering the questions in the import dialogue (import existing pool, unencrypted) => IMPORT
The procedure hung and failed after a while.
The first import went wrong, because the mountpoint the pool was mounted previously was /zpn and not /mnt/zpn as truenas expects it.
No pool at all has been importet.
After reading this thread and manually on the shell importing the pool to /mnt/zpn and then exporting again made the GUI import process differered in that the pool was imported on a zfs level (zpool and zfs commands on shell working as expected) but is shown like this in the GUI:
Despite being shown as `OFFLINE` (whatever that acutally means in the GUI) I could create shares to the network and so on.
At the same time I noted that in the dmesg numerous errors like this:
Now looking at `/var/log/messages` (attached) I recognized that happens quite often, often in conjunction with some action in the GUI.
I leave the file complete because it may be helpful to see when that error happens - also during normal startup without touching anything except from opening the web-gui actually.
Whenever a gui operation does not finish or hangs, one or multiply of the core dump lines get added to dmesg.
This thread is solely about the core dumps provoked by python3.9 actually.
How to debug the reason further or to get rid of it?
There is some relation to this thread no root cause was sorted out at that time.
- Mainboard D3049-B1x, onboard 1064E SAS/Raid
- Xeon E3-1260L,
- 16 GB ECC RAM
- 6x SATA DRIVES)
The onboard 6 channel SAS/SATA mpt is used here (and this thread is not about the lurking mpt issue that might be seen in the logs below).
Then while trying to import a pool via dialogue that was created with Ubuntu 19.04 (ZFS 0.8.3) the things went wrong.
After answering the questions in the import dialogue (import existing pool, unencrypted) => IMPORT
The procedure hung and failed after a while.
The first import went wrong, because the mountpoint the pool was mounted previously was /zpn and not /mnt/zpn as truenas expects it.
No pool at all has been importet.
After reading this thread and manually on the shell importing the pool to /mnt/zpn and then exporting again made the GUI import process differered in that the pool was imported on a zfs level (zpool and zfs commands on shell working as expected) but is shown like this in the GUI:
Despite being shown as `OFFLINE` (whatever that acutally means in the GUI) I could create shares to the network and so on.
At the same time I noted that in the dmesg numerous errors like this:
Code:
Feb 28 10:23:52 truenas kernel: pid 3934 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped) Feb 28 10:23:55 truenas kernel: pid 3969 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped) Feb 28 10:24:48 truenas kernel: pid 3999 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped) Feb 28 10:24:52 truenas kernel: pid 4026 (python3.9), jid 0, uid 0: exited on signal 11 (core dumped)
Now looking at `/var/log/messages` (attached) I recognized that happens quite often, often in conjunction with some action in the GUI.
I leave the file complete because it may be helpful to see when that error happens - also during normal startup without touching anything except from opening the web-gui actually.
Whenever a gui operation does not finish or hangs, one or multiply of the core dump lines get added to dmesg.
This thread is solely about the core dumps provoked by python3.9 actually.
How to debug the reason further or to get rid of it?
There is some relation to this thread no root cause was sorted out at that time.
Last edited:
