Register for the iXsystems Community to get an ad-free experience

TrueNAS 13.0-U2 is now available

MortyMars

Cadet
Joined
Aug 14, 2022
Messages
9
Hello,
I realize too late, that is to say after having launched the update, that the Realtek 2.5 GigE network cards are not supported by the version 13.0-U2...
So I can't access the web interface or my data anymore :-(((
I hope I can get out of this mess by reinstalling TrueNAS 13.0-U1.1 and importing my configuration.

The problem is that I can't find where to download this previous version knowing that the official site only offers 12.0-U8.1 which is too far away for my taste.
Thank you for your help and for a download link.
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
13,530

Volts

Contributor
Joined
May 3, 2021
Messages
113
I guess the question now is, why doesn't it carry over like before, and how do I fix it?

Did you see @Samuel Tai 's request to share netstat -rn from the host and a jail, and ifconfig -a from the host?

Perhaps interface hardware was discovered in a different order, and the auto-generated bridges are behaving differently.

Might be easiest to create a bridge interface manually on the physical interface you want, and specify that in the jail config.
 

MortyMars

Cadet
Joined
Aug 14, 2022
Messages
9
Thanks for the quick answer and the link :smile:
But how am I supposed to choose my 13.0-U1 boot environment?
I couldn't find the corresponding option in the boot console (knowing that I have an external display that wildly removes the first letters of each line...)
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
4,841
Thanks for the quick answer and the link :smile:
But how am I supposed to choose my 13.0-U1 boot environment?
I couldn't find the corresponding option in the boot console (knowing that I have an external display that wildly removes the first letters of each line...)

If you can boot to the system menu, then select 9 to get to the Shell. From the Shell, run beadm activate 13.0-U1.1. Ctrl-D to return back to the system menu. You can then reboot from the system menu to return your system to 13.0-U1.1.
 

MortyMars

Cadet
Joined
Aug 14, 2022
Messages
9
If you can boot to the system menu, then select 9 to get to the Shell. From the Shell, run beadm activate 13.0-U1.1. Ctrl-D to return back to the system menu. You can then reboot from the system menu to return your system to 13.0-U1.1.
Strangely I have the message "13.0-U1.1" does not exist and in the beadm list I am only offered default, initial-install, and 13.0-U2.
Is this one of the first two choices I should choose?
 
Joined
May 2, 2017
Messages
206
Can you provide the output of netstat -rn from both the host and from inside a non-working jail?

Also, the output of ifconfig -a on the host. I'm curious if you have multiple bridges, and iocage ended using the wrong bridge after the upgrade.
Created a bug report...

 

joeschmuck

Old Man
Moderator
Joined
May 28, 2011
Messages
9,547
I just updated from TrueNAS 12.0-U8.1 to 13.0-U2 via the GUI, no issues on my side. Still running TrueNAS on ESXi with 16GB RAM allocated and pass-through SATA controllers. Mine is basically used as a NAS alone, Plex is there too to provide content that the grandkids may want to watch. Streaming has become such a bit hit that Plex gets very little use these days.
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
4,841
Strangely I have the message "13.0-U1.1" does not exist and in the beadm list I am only offered default, initial-install, and 13.0-U2.
Is this one of the first two choices I should choose?

Use default. That's your 13.0-U1.1 original install. (Initial-install is the same, but before you performed any configuration.)
 

kiriak

Explorer
Joined
Mar 2, 2020
Messages
86
Another smooth update here for my home setup, from TrueNAS 12.0-U8.1 to 13.0-U2 via the GUI, including my two plugins, NextCloud and Unifi controller.
Many thanks to iXSystems and iX Community for this fine software and support.
 

MortyMars

Cadet
Joined
Aug 14, 2022
Messages
9
Use default. That's your 13.0-U1.1 original install. (Initial-install is the same, but before you performed any configuration.)
Yessssss :smile::smile: Here we go again !!!
You just saved my life (at least my day or my week :wink: )
Thanks again, to you first, but also to the other active members who proposed solutions.
Long life to the forum !
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
4,841
@MortyMars, if you want to try again with 13.0-U2, note the Release Notes. The driver is present, but disabled by default. If you're not sharing via iSCSI, you can re-enable the driver from the system menu. Just go to option 9 to start a Shell, and type midclt call tunable.create '{ "var": "if_re_load", "value": "YES", "type": "LOADER", "enabled": true }' and midclt call tunable.create '{ "var": "if_re_name", "value": "/boot/modules/if_re.ko", "type": "LOADER", "enabled": true }'. Reboot, and the driver should now load on boot.
 

MortyMars

Cadet
Joined
Aug 14, 2022
Messages
9
@MortyMars, if you want to try again with 13.0-U2, note the Release Notes. The driver is present, but disabled by default. If you're not sharing via iSCSI, you can re-enable the driver from the system menu. Just go to option 9 to start a Shell, and type midclt call tunable.create '{ "var": "if_re_load", "value": "YES", "type": "LOADER", "enabled": true }' and midclt call tunable.create '{ "var": "if_re_name", "value": "/boot/modules/if_re.ko", "type": "LOADER", "enabled": true }'. Reboot, and the driver should now load on boot.
Thank you for this solution, which I will keep preciously warm for the time being, at least until my cold sweats have dried up... o_Oo_O:wink:
 

MortyMars

Cadet
Joined
Aug 14, 2022
Messages
9
@MortyMars, if you want to try again with 13.0-U2, note the Release Notes. The driver is present, but disabled by default. If you're not sharing via iSCSI, you can re-enable the driver from the system menu. Just go to option 9 to start a Shell, and type midclt call tunable.create '{ "var": "if_re_load", "value": "YES", "type": "LOADER", "enabled": true }' and midclt call tunable.create '{ "var": "if_re_name", "value": "/boot/modules/if_re.ko", "type": "LOADER", "enabled": true }'. Reboot, and the driver should now load on boot.
I do have one question though :confused: :
Can I run these commands BEFORE the upgrade, then run the upgrade to 13.0-U2, reboot, and have the driver activated to access the interface and data directly without any further manipulation?
Thank you for a confirmation :wink:
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
4,841
I do have one question though :confused: :
Can I run these commands BEFORE the upgrade, then run the upgrade to 13.0-U2, reboot, and have the driver activated to access the interface and data directly without any further manipulation?
Thank you for a confirmation :wink:

Sorry, no. However, you don't need to upgrade again. Just reactivate the 13.0-U2 boot environment and reboot. Once the system menu is up, you can proceed with the CLI tunables creation.
 

MortyMars

Cadet
Joined
Aug 14, 2022
Messages
9
Sorry, no. However, you don't need to upgrade again. Just reactivate the 13.0-U2 boot environment and reboot. Once the system menu is up, you can proceed with the CLI tunables creation.
OK, thank you :wink:
I was hoping to be able to run commands comfortably from the web interface console :cool:, and not with my config connected to an external monitor that truncates the console and an external AZERTY keyboard, which is far from reassuring given recent experience:eek:
So I'll hold off for now and wait for a future update that will support the driver natively...
The main thing is that I have my interface and my data back and for that I thank you again :smile::smile:
 
Joined
May 2, 2017
Messages
206
Did you see @Samuel Tai 's request to share netstat -rn from the host and a jail, and ifconfig -a from the host?

Perhaps interface hardware was discovered in a different order, and the auto-generated bridges are behaving differently.

Might be easiest to create a bridge interface manually on the physical interface you want, and specify that in the jail config.
Well, that would be another thing I need to learn to do. LOL

Right now, I created a bug report. The nameservers are carrying over on 13.0-RELEASE, but not in 13.0-U2. I think your suggestion would be a good thing to implement if it isn't crazy hard, because I'd like to have a standard way the jails go out to the world to avoid issues like this. I have one NIC specifically for the jails, and I want them all to use that interface. Rather than let TrueNAS figure it out, it might be helpful to manually configure each jail to do exactly what I want.

Takes out the guesswork when things break...
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
4,841
@Steven Wormuth, in your case, you should stop your jails and:
  1. Manually create bridge0 and bridge1 interfaces.
    1. Make em0 a member of bridge0. (I assume this is the 172.16.1.0/24 subnet.)
    2. Make em1 a member of bridge1. (I assume this is the 172.16.2.0/24 subnet.)
  2. Move the IP info from the respective physical interfaces to the respective bridge interfaces.
  3. Clear ARP on the other devices on both subnets, so they pick up the new MAC for your TrueNAS interfaces.
  4. For each jail, change the VNET interface in the Network Properties tab to vnet0:bridge1.
  5. Start up each jail. They should now have the correct resolv.conf, since they'll pick up the 172.16.2.1 DNS server from the global configuration that's on their bridge interface.
 

pkerwien

Cadet
Joined
Aug 31, 2022
Messages
3
core_pcpu_init() function is a part of hwpmc(4) CPU profiling subsystem. It seems Proxmox virtualizes most of the PMC hardware, but not
MSR_DEBUGCTLMSR CPU register, that got used in 13.0-U2 to get more accurate profiles. It can be that switching CPU model you change emulation of that register. I've tested my work on VMware and had no problems there. But just to be safe I think I'll just block that new functionality when inside VMs. Any way profiling inside VM is not the best idea, it can't be very precise.

PS: Should be patched in next nightly build. Confirmation would be good.
I'm unsure where to find these nightly builds, but if the patch was included in:


Then I can confirm that it solves the boot issue on Proxmox 7.2 with VMs using CPU type=host.
 
Top