They are available via the same link… just need to search through.
Installed on 5 U61 systems without incident.
installed on my system, i create a new jail (only 13.3-release available) and stuck there:
root@truenas[~]# iocage start xxx
No default gateway found for ipv6.
- Starting xxx
- Started OK
- Using devfs_ruleset: 1010 (iocage generated default)
ELF interpreter /libexec/ld-elf.so.1 not found, error 2- Configuring VNET OK
- Using IP options: vnet
ELF interpreter /libexec/ld-elf.so.1 not found, error 2- Starting services FAILED
ERROR:
[b’']Refusing to start xxx: exec_start failed
old jails on 13.2 working good
Something was introduced in 13.3 that makes some jails not work properly on a 13.1 host.
There is some trick to create a jail as 13.2? This jail that dont start is basically only created from gui
iocage fetch 13.2-RELEASE
I believe
13.2 is EOL. It’s probably no longer available on the download server.
Since you already fetched the base OS, you should be able to choose which version of FreeBSD upon jail creation using the command-line.
Something like this (with root or sudo):
iocage create -r 13.2-RELEASE -b -n myawesomejail
1 Like
iocage fetch 13.2-RELEASE
unlucky don’t show 13.2 
iocage create -r 13.2-RELEASE -b -n myawesomejail
this works, thanks!
Does this makes the jail appear in the WebUI as well?
Yup!
1 Like
I am running truenas inside a proxmox-guest with 8 GB ram (without issues). But after having done the update my memory-consumption of the guest jumped up from 71% to 92%.
Can you imagine the reason?
Does 13.0-U6.2 require a reboot? I have several VMs using it as the datastore they run off and it is hard to get Engineering to let us shut those VMs down for a TrueNas patch and bounce. thanks! Ken
Yes, every TrueNAS upgrade requires a reboot.
2 Likes
It’s only an SSH vulnerability patch.
Their call.
I’m running TrueNAS-13.0-U6.7 but vulnerability team is telling me I still have this nessus vulnerability plugin 201194 [CVE-2024-6387]. Their scan reports:
version source : ssh-2.0-openssh_8.8-hpn14v15
installed version : 8.8-hpn14v15
fixed version : 9.8p1 / 9.8
On the NAS shell, i ran “ssh -V” to get version and it confirms OpenSSH_8.8p1.
Am I doing something wrong?
(Forgive bump in advance, if mistake; first post thought I would use the search function and found reference to this CVE. welcome feedback if should be new thread. hello community!)
Without looking up the details, my suggestion is to double-check that it’s not a false positive from a version unaffected by the recent xz debacle.
1 Like
The details from openssh are here:
https://www.openssh.com/txt/release-9.8
It does say:
This bug does not affect connections when ObscureKeystrokeTiming
was disabled or sessions where no TTY was requested.
The other bug says:
Successful exploitation has been demonstrated on 32-bit Linux/glibc
systems with ASLR. Under lab conditions, the attack requires on
average 6-8 hours of continuous connections up to the maximum the
server will accept. Exploitation on 64-bit systems is believed to be
possible but has not been demonstrated at this time. It’s likely that
these attacks will be improved upon.
1 Like
i found a bug ticket for this issue. Jira
it sounds like it was resolved by backporting while is not the latest version of openssh and I have to work with my vulnerability team.
1 Like
That’s a false positive for Nessus. Our ssh version is the same as the version listed in the CVE, but our code was built with options that leave out the vulnerable code.
The fixed version started with CORE 13.0-u6.2, per this link:
2 Likes